| *** openstack has joined #zuul | 09:56 | |
| *** ChanServ sets mode: +o openstack | 09:56 | |
| *** dpawlik has joined #zuul | 09:56 | |
| *** rpittau is now known as rpittau|bbl | 10:23 | |
| *** ysandeep is now known as ysandeep|afk | 10:37 | |
| *** ysandeep|afk is now known as ysandeep|rover | 10:53 | |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: WIP: tox: allow tox to be upgraded https://review.opendev.org/690057 | 10:54 |
|---|---|---|
| *** jcapitao is now known as jcapitao_lunch | 10:57 | |
| *** bhavikdbavishi has quit IRC | 11:11 | |
| tristanC | zuul-maint, could you please have a look at the zk-tls changes, https://review.opendev.org/712733 and https://review.opendev.org/712531 . They already have 2 +2, would it be ok to merge them soon? | 11:18 |
| *** cdearborn has joined #zuul | 11:30 | |
| *** jpena is now known as jpena|lunch | 11:36 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add schema validation error message https://review.opendev.org/718999 | 11:38 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add a zuul-ensure-database-passwords role https://review.opendev.org/717880 | 11:38 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add zuul-registry deployment https://review.opendev.org/710650 | 11:38 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add TLS configuration to ZooKeeper service https://review.opendev.org/712759 | 11:38 |
| *** ysandeep|rover is now known as ysandeep|coffee | 11:39 | |
| *** gtema has quit IRC | 11:46 | |
| *** gtema has joined #zuul | 11:51 | |
| *** ysandeep|coffee is now known as ysandeep | 11:51 | |
| *** ysandeep is now known as ysandeep|rover | 11:56 | |
| *** hashar has joined #zuul | 12:02 | |
| *** bhavikdbavishi has joined #zuul | 12:04 | |
| *** rlandy has joined #zuul | 12:14 | |
| *** jcapitao_lunch is now known as jcapitao | 12:17 | |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: tox: allow tox to be upgraded https://review.opendev.org/690057 | 12:28 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor the input in schemas files https://review.opendev.org/719932 | 12:30 |
| *** rpittau|bbl is now known as rpittau | 12:31 | |
| zbr | tristanC: clarkb: can we do the update of create-react-app? https://review.opendev.org/#/c/716305/ | 12:36 |
| *** jpena|lunch is now known as jpena | 12:40 | |
| tristanC | zbr: that change seems to be broken | 12:45 |
| *** gtema has left #zuul | 12:57 | |
| zbr | tristanC: how did you get to that error? | 13:05 |
| zbr | your comment may explain why my own patch did not work, but i want to see the error on that patch. | 13:06 |
| *** Goneri has joined #zuul | 13:10 | |
| tristanC | zbr: i clicked the preview website link | 13:15 |
| *** sgw has quit IRC | 13:16 | |
| zbr | interesting, now I get a not found error but minutes ago it was loading correctly. | 13:16 |
| zbr | the multi-site one is loading | 13:18 |
| tristanC | zbr: you need to load it from the zuul build page, direct access result in not found error because of the way react router works | 13:25 |
| *** gtema_ has joined #zuul | 13:34 | |
| *** sgw has joined #zuul | 13:34 | |
| *** gtema has joined #zuul | 13:46 | |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 13:47 |
| mordred | tristanC: updating redux as well fixed it for me locally ^^ | 13:47 |
| mordred | let's see if it fixes it in the gate | 13:48 |
| *** gtema_ has quit IRC | 13:48 | |
| *** evgenyl has quit IRC | 13:50 | |
| *** stevthedev has quit IRC | 13:50 | |
| *** rpittau has quit IRC | 13:50 | |
| *** stevthedev has joined #zuul | 13:51 | |
| *** evgenyl has joined #zuul | 13:51 | |
| *** rpittau has joined #zuul | 13:51 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor file creation to function files https://review.opendev.org/719965 | 13:54 |
| tristanC | mordred: nice, let see | 13:55 |
| *** gtema has left #zuul | 13:55 | |
| tristanC | corvus: mordred: tobiash: clarb: i've started to refactor the dhall files with https://review.opendev.org/719932 and https://review.opendev.org/719965 . I think it's better like that, but that's not necessary, it's purely cosmetic. what do you think? Should i continue to split the resources.dhall file? | 13:57 |
| *** zxiiro has joined #zuul | 14:00 | |
| mordred | tristanC: I like the second one (the files one) better than the first. for the second one, it's nice because you get the main file content in context that looks a bit more like the final file rather than indented in the middle of the page ... for the first one, the original resources file just seems easier to read all together to my eyeball. but I don't have strong opinions one way or the other | 14:03 |
| corvus | are those alternatives, or are they two steps in the same process? | 14:04 |
| tristanC | corvus: they are atomic | 14:05 |
| corvus | (because the second one seems to depend on the first) | 14:05 |
| corvus | tristanC: so the choices you are offering are (a) 932 or (b) 932+965 ? | 14:06 |
| tristanC | corvus: it doesn't have too, it's just easier for me to keep a single stack | 14:06 |
| tristanC | corvus: (a) keep only input and resources, (b) split all the schemas with 932, (c) split the configuration files, (d) b+c | 14:07 |
| tristanC | but i agree (b) requires being able to have many files open at once, and i don't mind keeping the single `input` file | 14:07 |
| tristanC | then i'd like to work on (e) move KubernetesComponent to their own file, so that we have conf/zuul/Components/{Scheduler,Executor,Registry,...} | 14:08 |
| *** bhavikdbavishi has quit IRC | 14:09 | |
| corvus | i think i agree with mordred, which i think means i like (c). mostly i think about if i'm looking at a schema, and i see that it requires a 'gerrit' i don't have to go to the gerrit file to see what that looks like. but also, i am generally more comfortable with big files than other folks. :) | 14:15 |
| tristanC | alright, thank you for the feedback, i'll drop 932 | 14:18 |
| tristanC | i figured big files are not an issue, considering the zuul/executor and web modules :) but it's also nice to isolate objects that are independent | 14:18 |
| corvus | tristanC: sounds good, but also you may get feedback from clarkb if you wait another 30-60 minutes :) | 14:19 |
| *** sshnaidm has joined #zuul | 14:29 | |
| *** sshnaidm has quit IRC | 14:30 | |
| clarkb | I'm distracted by the osf board call but pulling up those changes now to see | 14:40 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor file creation to function files https://review.opendev.org/719965 | 14:44 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor kubernetes resources constructor to the function file https://review.opendev.org/719991 | 14:44 |
| clarkb | corvus: tristanC mordred I think Itoo prefer the second change over the first. I don't mind either though. One thing with splitting though is you lose a bit of context so we may need a bit more commentary in some places? https://review.opendev.org/#/c/719965/1/conf/zuul/files/nodepool.yaml.dhall for example seems like the identity function on its own | 14:48 |
| clarkb | without context it seems unnecessary (and maybe it is?) | 14:48 |
| tristanC | clarkb: sure i can add comment. thank you for the review | 14:49 |
| *** ysandeep|rover is now known as ysandeep|away | 14:50 | |
| *** bhavikdbavishi has joined #zuul | 15:17 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor deployment and statefulset functions https://review.opendev.org/720007 | 15:29 |
| tobiash | corvus: re topic 'where to configure allow-cyclyc-deps' did we we decide to change cdep to be allowed in the project pipeline in a config project or shall we leave that in the tenant config? | 15:37 |
| corvus | mnaser: https://review.opendev.org/717371 has a WIP title and 2x +2s -- is it ready to go? | 15:38 |
| corvus | tobiash: ah, let me catch up on that | 15:38 |
| fungi | tobiash: (and armstrongs if he sees this in the web log) opendev manages to peak at around 80-100 concurrent builds per executor, but it likely depends on the characteristics of the executors themselves, the typical workloads, and maybe other factors as well | 15:40 |
| corvus | mnaser, tristanC, mordred: i think i see potential problems with https://review.opendev.org/717817 | 15:41 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor backend services https://review.opendev.org/720019 | 15:43 |
| tristanC | corvus: indeed. It seems like using include_role from a role should be explicit in the role documentation | 15:44 |
| corvus | tobiash: based on what we wrote in the spec: https://zuul-ci.org/docs/zuul/reference/developer/specs/circular-dependencies.html i think that maybe putting the allow-circular-dependencies setting on the new Queue object may work and be intuitive. what do you think? | 15:45 |
| corvus | tobiash: specifically "Changes with cross-repo circular dependencies are required to share the same change queue." makes me think this makes sense | 15:45 |
| tristanC | corvus: mordred: tobiash: clarb: (e) is proposed in https://review.opendev.org/720019 for Backend service. I'd like to do the same for Zuul and Nodepool too, does that seems right to you? | 15:45 |
| tobiash | hrm, interesting thought | 15:46 |
| corvus | tristanC: lgtm | 15:49 |
| tobiash | corvus: I think that's a good idea, I'll discuss it tomorrow with Simon | 15:50 |
| corvus | tobiash: i like the queue change | 15:51 |
| tobiash | corvus: cool, then I'll finish up that change with docs and reno | 15:54 |
| *** rpittau is now known as rpittau|afk | 16:02 | |
| tobiash | corvus: re cdep and the flag on the queue object, how would we handle independent pipelines with this? | 16:10 |
| tobiash | would we allow cyclic deps on those in any case? | 16:10 |
| *** sanjayu__ has quit IRC | 16:10 | |
| corvus | tobiash: hrm, good q; let me think about that | 16:10 |
| *** rlandy is now known as rlandy|brb | 16:14 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor backend services https://review.opendev.org/720019 | 16:23 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor Zuul services https://review.opendev.org/720024 | 16:23 |
| corvus | tobiash: maybe this does need to be a tenant-level config :/ | 16:32 |
| *** rlandy|brb is now known as rlandy | 16:35 | |
| *** evrardjp has quit IRC | 16:37 | |
| *** evrardjp has joined #zuul | 16:37 | |
| tobiash | corvus: ok, so then this matches the current implementation | 16:48 |
| corvus | tobiash: because i think we shouldn't allow a cycle in a check pipeline unless it's at least possible that the same cycle could be enqueued in gate. however, even if we make it a tenant-level config, we can still have a case where it can't be enqueued in gate if all the projects don't share a queue. i don't think there's anything we can do about that. but it seems like if we put the setting on the queue | 16:49 |
| corvus | objects, then in addition to that potential problem, we would also have the potential problem where they might share a queue in gate, but the queue doesn't actually allow cycles. so we've doubled the number of cases where the configuration in check wouldn't match gate. | 16:49 |
| *** hashar has quit IRC | 16:49 | |
| corvus | the only way i could see to make that work would be to attach the queue object to gate as well. | 16:50 |
| corvus | and that would be weird because we won't actually share the queue there. we would just use it to get those settings. | 16:50 |
| corvus | okay, we *could* move the queue from the pipeline to the project | 16:50 |
| corvus | so that you can't have different shared queues for different dependent pipelines | 16:51 |
| corvus | which, to be honest, probably makes more sense anyway. but it's a bigger change (it would actually mean a deprecation in zuul config syntax) | 16:51 |
| tobiash | hrm, that sounds like a lot of effort | 16:53 |
| corvus | tobiash: okay, so i think our choices are (a) make it a tenant config option as written in the spec; (b) put in on the queue object, move the queue object to be a project-level config, depcreate the pipeline level "queue" attribute. then the queue object determines shared queue membership for dependent pipelines, and determines whether projects can have cyclic dependencies (and with which other projects) in | 16:53 |
| corvus | all pipelines. | 16:53 |
| *** jcapitao has quit IRC | 16:54 | |
| corvus | (b) is a lot of work for us, but honestly, probably not that much more work than we're going to do anyway. it's a little work for users too, but we can make the upgrade seamless (and we have a bunch of major version bumps coming up, so we can probably even remove the old queue pipeline attribute by zuul v5) | 16:54 |
| tobiash | corvus: let me think about it, since (a) is already fully implemented and battle tested in our deployment with several projects | 16:55 |
| corvus | (b) may be better because it makes it easier for 'check' to be a proper simulation of 'gate' in these complex situations | 16:56 |
| corvus | tobiash: yeah, we did also write a spec, which we do to try to avoid design-after-the-fact | 16:56 |
| tobiash | yeah, the implementation matches the spec :) | 16:57 |
| corvus | tobiash: i'm not sure this would be worth it for either feature on its own, but when you consider them both together, they touch 95% of what would be needed for this, so suddenly it may be worth it | 16:57 |
| tobiash | corvus: so your suggestion would be to change 718531 to match per project queue instead of per pipeline and then rebase cdep on top of this and adapt it to use that? | 16:58 |
| corvus | tobiash: i think so | 16:58 |
| tobiash | how would we handle the (unlikely) case of two dependent pipelines with different queues on the same project? | 16:59 |
| corvus | tobiash: during the backwards compat period, we might be able to keep the current scheme (and have those pipelines have different queues) | 17:00 |
| tobiash | ok, so pipeline takes precedence with a fall-back to project and later pipeline is ignored | 17:01 |
| corvus | yeah | 17:01 |
| tobiash | (or better config error) | 17:01 |
| tobiash | ok, I think I would even do this logic as its own change on top of 718531 which introduces the queue element | 17:03 |
| tobiash | and then on top of this cdep | 17:04 |
| tristanC | mordred: create-react-update still failed, and this time the unit test also found an issue (the expected links where not there) | 17:05 |
| *** jpena is now known as jpena|off | 17:05 | |
| *** sgw has quit IRC | 17:07 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor file creation to function files https://review.opendev.org/719965 | 17:08 |
| mordred | tristanC: yeah. I'm not sure yet what's up with it :( | 17:10 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor file creation to function files https://review.opendev.org/719965 | 17:12 |
| tristanC | mordred: perhaps updating the main redux dependency would help (it seems to be pined at <4.0.0) | 17:13 |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: Improve 404 error message on download-logs.sh https://review.opendev.org/720035 | 17:13 |
| mordred | tristanC: maybe - I'll try | 17:21 |
| *** Goneri has quit IRC | 17:23 | |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Update to create-react-app 3.4.1 https://review.opendev.org/716305 | 17:25 |
| *** sgw has joined #zuul | 17:29 | |
| *** Goneri has joined #zuul | 17:52 | |
| *** dpawlik has quit IRC | 18:02 | |
| *** bhavikdbavishi has quit IRC | 18:02 | |
| *** tobiash has quit IRC | 18:16 | |
| *** tobiash has joined #zuul | 18:17 | |
| tristanC | zuul-maint , it would be really nice if https://review.opendev.org/719932 operator change and its parent can be reviewed and/or merged, or at least https://review.opendev.org/718999 where there are a few branches that grow from it. | 19:08 |
| tristanC | the registry, zookeeper tls, cert-manager and today's refactor are kind of stuck until those key changes are integrated. Thanks in advance! | 19:09 |
| *** armstrongs has joined #zuul | 19:12 | |
| *** armstrongs has quit IRC | 19:17 | |
| *** Goneri has quit IRC | 19:57 | |
| *** Goneri has joined #zuul | 19:58 | |
| *** tobberydberg_ has quit IRC | 20:17 | |
| *** fdegir4 has quit IRC | 20:19 | |
| *** fdegir4 has joined #zuul | 20:19 | |
| *** gtema has joined #zuul | 20:20 | |
| *** fdegir4 has quit IRC | 20:20 | |
| *** tobberydberg has joined #zuul | 20:22 | |
| *** gtema has quit IRC | 20:27 | |
| *** tobberydberg has quit IRC | 20:30 | |
| *** tobberydberg has joined #zuul | 20:36 | |
| *** tobberydberg has quit IRC | 20:37 | |
| *** tobberydberg has joined #zuul | 20:42 | |
| *** tobberydberg has quit IRC | 20:43 | |
| *** tobberydberg has joined #zuul | 20:45 | |
| *** tobberydberg has quit IRC | 20:45 | |
| *** tobberydberg has joined #zuul | 20:46 | |
| *** tobberydberg has quit IRC | 20:46 | |
| *** tobberydberg has joined #zuul | 20:46 | |
| *** tobberydberg has quit IRC | 20:47 | |
| *** tobberydberg has joined #zuul | 20:47 | |
| *** tobberydberg has quit IRC | 20:47 | |
| *** tobberydberg has joined #zuul | 20:51 | |
| openstackgerrit | Merged zuul/zuul-registry master: config: add environment variable substitution https://review.opendev.org/710644 | 20:52 |
| *** tobberydberg has quit IRC | 20:55 | |
| *** tobiash has quit IRC | 21:18 | |
| *** tobiash has joined #zuul | 21:20 | |
| *** y2kenny has joined #zuul | 21:21 | |
| y2kenny | If I want to specify an executor only job, what do I use for nodeset? | 21:22 |
| clarkb | y2kenny: [] an empty list | 21:23 |
| y2kenny | clarkb: Ah ok. thanks. I tried taking out nodeset entirely but I think it ended up just waiting. | 21:24 |
| corvus | clarkb, tristanC, mordred: this looks like a real openstack failure of the nodepool job: https://zuul.opendev.org/t/zuul/build/1ca928db99d84a22aa9382576ff556c5/console | 21:33 |
| corvus | both nodepool-functional-openstack and nodepool-functional-openstack-src broke on that change, but they previously passed | 21:33 |
| corvus | i wonder if openstack changed out from under us | 21:34 |
| corvus | ianw: ^ | 21:34 |
| openstackgerrit | Merged zuul/zuul master: Add TLS support for ZooKeeper https://review.opendev.org/712531 | 21:35 |
| openstackgerrit | Merged zuul/zuul master: Move zuul-quick-start requires to pipeline and reparent https://review.opendev.org/713545 | 21:35 |
| clarkb | corvus: 2020-04-14 21:13:36,408 INFO nodepool.NodeLauncher: [e: 2349321546eb43b3a2e134177fbae37b] [node_request: 900-0000000000] [node: 0000000000] Node is ready from the nodepool log | 21:38 |
| tristanC | not sure to understand what is the failure, is this because the cloud-init content is incorrect? | 21:38 |
| corvus | yeah, if i'm reading the log right, it sort of looks like we're checking cloud config output or something? | 21:39 |
| corvus | tristanC: that's what it looks like to me but i also am not sure | 21:39 |
| openstackgerrit | Merged zuul/zuul master: Add release note for zookeeper tls support https://review.opendev.org/717312 | 21:39 |
| clarkb | oh I see its failing after sshing into the host | 21:39 |
| y2kenny | clarkb: I tried having [] for nodes but looks like the job is stuck just like not defining nodeset | 21:42 |
| corvus | clarkb, tristanC: yeah, that's exactly what's going on: https://opendev.org/zuul/nodepool/src/branch/master/tools/functional-test-check.sh#L70-L75 | 21:42 |
| clarkb | y2kenny: it should be nodeset: [] iirc | 21:42 |
| clarkb | y2kenny: let me see if I can find an example | 21:42 |
| y2kenny | also... Is there a way to kill a stuck job? (do I just dequeue?) | 21:43 |
| corvus | y2kenny, clarkb: nodeset: {nodes: []} | 21:43 |
| corvus | we usually put that on 2 lines like: | 21:43 |
| corvus | nodeset: | 21:43 |
| corvus | nodes: [] | 21:43 |
| clarkb | corvus: tahnks | 21:43 |
| y2kenny | um... I tried that, but I got a stuck job... | 21:43 |
| corvus | y2kenny: dequeue is best; another option would be stop the executor | 21:44 |
| clarkb | corvus: ah its testing that the userdata set by nodepool ends up on the node | 21:44 |
| clarkb | https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openstack/templates/nodepool.yaml.j2#L37-L42 that comes from there | 21:45 |
| corvus | clarkb, tristanC, ianw: so somehow either devstack stopped passing that through, or glean isn't writing it? | 21:47 |
| clarkb | corvus: in this case it is cloud-init not glean, but ya | 21:47 |
| corvus | oh, we use cloud-init in that test? | 21:47 |
| clarkb | corvus: or I suppose it could be that openstacksdk stopped giving it to the service | 21:48 |
| clarkb | corvus: ya glean doesn't support that functionality | 21:48 |
| corvus | ah | 21:48 |
| clarkb | I seem to recall we dump the console logs somewhere? that might give us a clue if I can find it | 21:48 |
| clarkb | https://zuul.opendev.org/t/zuul/build/1ca928db99d84a22aa9382576ff556c5/log/instances/2c6ceb1c-47f9-492e-9459-6a713dab3588/console.log is the log | 21:49 |
| clarkb | ok that image did run glean | 21:49 |
| clarkb | so that probably explains it | 21:49 |
| corvus | oh but wait -- it looks like that check is comparing what's in the nova user data with the expected value | 21:50 |
| corvus | so we're not checking what's on disk, the data is missing from 'nova show' | 21:50 |
| clarkb | corvus: aha that woudl explain why it works even when not using cloud-init before. Ok so we aren't checking cloud-init ran just that nova did the appropriate things | 21:50 |
| corvus | that narrows it down to nodepool/sdk not submitting the data, or the nova show output not showing it (or devstack/openstack losing it) | 21:50 |
| corvus | that's the only time we run nova show, and we don't save the whole output | 21:51 |
| corvus | so we can't see what it looked like (either now or before) | 21:52 |
| clarkb | was just going to ask if we have that output anywhere | 21:52 |
| clarkb | maybe we should add a nova show to just before that and capture the output? | 21:52 |
| corvus | ++ | 21:52 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: WIP: run nova show https://review.opendev.org/720088 | 21:53 |
| ianw | yeah it makes sense as a "does this config in .yaml get through to nova" test | 21:53 |
| corvus | i'm guessing 'nova show' is from python-novaclient? | 21:54 |
| ianw | it probably just predates more extensive use of "openstack"? | 21:56 |
| corvus | there was a release on april 11 | 21:56 |
| clarkb | corvus: yes re nova show | 21:57 |
| corvus | that was the date of the last time this job passed | 21:57 |
| corvus | i see some changes in re dropping python 2 support | 21:57 |
| corvus | is it possible we're installing that in a py2 env, and the error we're going to see is "this doesn't support py2 anymore"? | 21:57 |
| clarkb | its possible that openstack server show would work too, but may need fiddling to get the user data back (I've never had good luck with osc and getting back specific api fields) | 21:57 |
| clarkb | corvus: oh heh that could be | 21:58 |
| ianw | corvus: very likely | 21:58 |
| corvus | what's the solution for that? do we need to set some devstack flag? or switch to 'openstack server show'? | 21:59 |
| clarkb | corvus: well if it was installed by devstack I would expect it to just work | 22:02 |
| clarkb | corvus: judging by the devstack output I think it installed under python 3.6 | 22:04 |
| clarkb | ya it installed a py3 only wheel too | 22:05 |
| clarkb | My guess is that hte output simply changed | 22:05 |
| ianw | ahh yes a recheck i did before the dib gate now shows it too | 22:09 |
| clarkb | reading the git diff its possible this is a python string handling change? thats the bulk of the difference | 22:09 |
| clarkb | transform_userdata was updated | 22:11 |
| corvus | oh cool that sounds promising | 22:12 |
| corvus | clarkb: what's the sha of that change? | 22:12 |
| clarkb | corvus: c4c44bcb2df01b77089139b267b1219008f9421e | 22:14 |
| clarkb | change to remove six | 22:15 |
| clarkb | it should be noted that I think the input to the api side is all handled by openstacksdk and doesn't touch this. So this would just be read out the otherside problems? | 22:15 |
| corvus | looks like it at least wasn't intending to change the output | 22:16 |
| ianw | corvus/clarkb: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_3e2/720088/1/check/nodepool-functional-openstack/3e282ea/job-output.txt | 22:49 |
| ianw | it does seem user_data is ... gone | 22:49 |
| corvus | ayup | 22:51 |
| corvus | mordred, clarkb, ianw: ^ what do you think the next step is? | 22:51 |
| ianw | OS-EXT-SRV-ATTR:user_data | 22:52 |
| ianw | is it something to do with versions, and that extra bit on it | 22:52 |
| corvus | ianw: is that from a prod system or something? | 22:53 |
| ianw | i'm just grepping nova source | 22:53 |
| ianw | do we think the openstackclient will show it? | 22:56 |
| ianw | doh, or even https://opendev.org/openstack/python-novaclient/commit/03dca4bc823c82054869dfaf6925d5e1e068ac51 | 22:57 |
| ianw | Don't print user_data for 'nova show' | 22:57 |
| ianw | which is exactly the problem ... | 22:57 |
| corvus | how did i miss that one | 22:59 |
| ianw | i'm asking on -nova if maybe there's a better way to check | 23:00 |
| *** rlandy has quit IRC | 23:00 | |
| ianw | i guess it's not worth a flag in the client, it sounds like generically it's not useful -- just in this case when we're doing end-to-end testing it is | 23:01 |
| ianw | corvus: to get thing back on track, maybe just update that wip to comment out the check, until we come up with something else? | 23:02 |
| corvus | ianw: yep -- though i was just going to remove it and we can revert it back in later -- that ok? | 23:03 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Stop checking user_data in func test https://review.opendev.org/720088 | 23:04 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Add ZooKeeper TLS support https://review.opendev.org/712733 | 23:04 |
| ianw | either or, it seems like we probably still want to test it if we can? | 23:04 |
| corvus | ianw: yeah, i'd be happy to test it | 23:04 |
| corvus | i just removed it to avoid ending up with comment detritus if it doesn't make it back in | 23:04 |
| ianw | probably a few lines calling the nova client binding directly | 23:04 |
| *** sanjayu__ has joined #zuul | 23:05 | |
| corvus | or maybe 'openstack server show' has a way for that | 23:05 |
| corvus | honestly, i think putting it behind a flag makes a lot of sense | 23:05 |
| corvus | "real users" are going to want to know "did my userdata really make it to nova?" just like we do | 23:05 |
| corvus | also, it's not really binary data, right? | 23:06 |
| corvus | it's base64 data | 23:06 |
| corvus | (so i don't see a problem with showing it on the cli) | 23:06 |
| corvus | makes sense if the idea is "dont show it by default because it's big" | 23:06 |
| ianw | yeah, although i see the argument that it's an interactive focused tool, so dumping base64 isn't helpful to a human, and tests like us should probably go via api calls | 23:08 |
| corvus | i get "don't dump base64 by default" but i totally think that *some* tool (likely openstackclient) should output it when asked | 23:09 |
| corvus | because it's a legit debug tool for users | 23:09 |
| corvus | "confirm garbage out == garbage in" is a pretty basic debug tool in all situations | 23:09 |
| corvus | so if i set some user data to install a key, and the key isn't there, the first thing i want to know is "did the user data make it to the cloud?" | 23:10 |
| corvus | it's actually the same debugging process we just went through :) | 23:11 |
| ianw | doesn't look like it will be too hard to add a -- flag, i'll take a look | 23:11 |
| *** tosky has quit IRC | 23:20 | |
| mordred | corvus: openstacksdk totally retrives and shows user data in the server record | 23:23 |
| mordred | so if osc doesn't have it ... we should add it - at least behind a flag | 23:24 |
| mordred | there's already a user-data flag in openstack server show | 23:25 |
| corvus | cool, so this should be a one-liner fix | 23:25 |
| mordred | oh - no - I take that back | 23:26 |
| mordred | there's a flag to set it | 23:26 |
| mordred | still looking | 23:26 |
| mordred | confirms openstacksdk has it | 23:27 |
| mordred | I don't see it in the osc output - but I don't know if that's just because I don't have a server booted with user data | 23:32 |
| mordred | osc isn't stripping it from the return struct | 23:33 |
| mordred | but - osc is using novaclient for this - and god only knows what that's doing | 23:33 |
| openstackgerrit | Ian Wienand proposed zuul/nodepool master: diskimage.username setting was not read from configuration file https://review.opendev.org/719191 | 23:52 |
| openstackgerrit | Ian Wienand proposed zuul/nodepool master: Test alternative username in unit tests https://review.opendev.org/720101 | 23:52 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor kubernetes resources constructor to the function file https://review.opendev.org/719991 | 23:53 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor deployment and statefulset functions https://review.opendev.org/720007 | 23:57 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor backend services https://review.opendev.org/720019 | 23:57 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor Zuul services https://review.opendev.org/720024 | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!