| dmsimard | jeblair: lgtm just a small comment | 00:12 |
|---|---|---|
| dmsimard | sorry for responsiveness today, haven't been very productive day for me T_T | 00:12 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: DNM: test nodeset error https://review.openstack.org/505856 | 00:15 |
| jeblair | dmsimard: yeah ^ we should make a special exception for that | 00:16 |
| jeblair | it's not a problem with the current code, just a good idea for an enhancement | 00:16 |
| dmsimard | Ah so just a friendly exception message then | 00:16 |
| dmsimard | jeblair: FWIW I was discussing with fungi the other day -- I unexpectedly ran into a depends-on loop and had wished Zuul v3 was able to tell me instead of just not doing anything at all | 00:17 |
| jeblair | dmsimard: regarding the executor/json thing -- maybe see if you can pair with pabelanger, fungi, or mordred tomorrow morning; if not, we can try again tomorrow afternoon | 00:17 |
| dmsimard | yup | 00:17 |
| *** olaph1 has joined #zuul | 00:17 | |
| jeblair | dmsimard: i think zuulv3 might be able to do that, or if not, is close. | 00:18 |
| * dmsimard nods | 00:18 | |
| dmsimard | just something to keep at the back of our heads | 00:18 |
| *** olaph has quit IRC | 00:18 | |
| jeblair | remote: https://review.openstack.org/505856 Report friendly errors when nodeset/secrets missing | 00:37 |
| *** openstackgerrit has quit IRC | 00:41 | |
| jeblair | dmsimard: ^ | 00:42 |
| jeblair | i restarted zuulv3 to pick up the, erm, don't infinite loop fix. | 01:38 |
| jeblair | it should be safe to recheck and merge any changes to zuul config now | 01:39 |
| *** openstackgerrit has joined #zuul | 01:40 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Report friendly errors when nodeset/secrets missing https://review.openstack.org/505856 | 01:40 |
| dmsimard | mordred: found something a bit weird in the migration script output | 01:43 |
| dmsimard | mordred: looking at a puppet-openstack-integration patch, e.g: https://review.openstack.org/#/c/505736/ | 01:43 |
| dmsimard | you'll see for example gate-puppet-openstack-integration-4-scenario001-tempest-centos-7 and the ubuntu equivalent gate-puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial | 01:44 |
| dmsimard | these are migrated respectively as legacy-puppet-openstack-integration-4-scenario001-tempest-centos-7 and legacy-puppet-openstack-integration-4-scenario001-tempest | 01:44 |
| dmsimard | notice the lack of 'ubuntu-xenial' in the job name -- there's also no node associated with it so I guess it ends up defaulting to ubuntu-xenial (which is probably fine) | 01:44 |
| dmsimard | not a huge deal but I don't know whether or not the 'ubuntu-xenial' is being taken out of the job name on purpose | 01:45 |
| dmsimard | http://paste.openstack.org/raw/621580/ | 02:03 |
| dmsimard | "parent: publish-openstack-artifacts" for a tripleo job doesn't seem right | 02:04 |
| dmsimard | Do we have a v3 equivalent for "legacy-announce-release" ? | 02:06 |
| dmsimard | same question for "legacy-releasenotes" | 02:08 |
| mordred | dmsimard: yes - ubuntu-xenial taken out on purpose - legacy-announce-release should be taken care of, so we should add a mapping if you're seeing that somewhere | 02:26 |
| mordred | dmsimard: I thought I made a releasenotes already - but maybe didn't and we should make one | 02:26 |
| mordred | dmsimard: parent: publish-openstack-artifacts happens if the job needs to publish things ot tarballs.o.o at the end of the job | 02:26 |
| dmsimard | I'm about to propose a project-config patch to test drive two puppet-openstack projects, I'll ask mwhahaha and mnaser for input | 02:27 |
| *** yolanda has quit IRC | 02:34 | |
| *** yolanda has joined #zuul | 02:35 | |
| dmsimard | mordred: hmm, there probably should be required projects somewhere in there | 02:47 |
| dmsimard | mordred: required projects is necessary for "zuul cloning" things, right ? | 02:48 |
| dmsimard | jlk, mordred: btw this thing exists: http://docs.ansible.com/ansible/latest/porting_guide_2.4.html | 03:02 |
| jlk | huzahh | 03:02 |
| dmsimard | It's not exhaustive but better than nothing | 03:04 |
| dmsimard | There's no mention of includes -> imports for example | 03:04 |
| *** tobiash has joined #zuul | 03:10 | |
| mordred | dmsimard: legacy jobs will use zuul-cloner to clone things - we're not reworking them via migration to be new-style - only making sure they physically work | 03:36 |
| dmsimard | mordred: oh, right, so I'll remove the required projects thing. | 03:40 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Update roadmap in the README https://review.openstack.org/502188 | 05:26 |
| *** xinliang has quit IRC | 06:57 | |
| *** xinliang has joined #zuul | 07:10 | |
| *** xinliang has quit IRC | 07:10 | |
| *** xinliang has joined #zuul | 07:10 | |
| *** ChanServ sets mode: +o openstack | 07:13 | |
| *** hashar has joined #zuul | 07:29 | |
| *** electrofelix has joined #zuul | 08:24 | |
| *** hashar has quit IRC | 08:38 | |
| *** hashar has joined #zuul | 08:39 | |
| *** smyers has quit IRC | 09:02 | |
| *** smyers has joined #zuul | 09:04 | |
| *** hashar has quit IRC | 10:16 | |
| *** jesusaur has quit IRC | 10:36 | |
| *** jkilpatr has quit IRC | 10:38 | |
| *** jesusaur has joined #zuul | 10:40 | |
| *** jkilpatr has joined #zuul | 11:10 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Improve test case node_assignment_at_quota https://review.openstack.org/506134 | 11:46 |
| mnaser | dmsimard that would be great (re: test driving puppet-openstack projects) | 11:48 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Remove unreachable code https://review.openstack.org/506137 | 12:11 |
| mnaser | if i remember correctly, /usr/local/jenkins wont be there in zuulv3 nodes right? | 12:53 |
| dmsimard | mnaser: those are provided by the image regardless of v2 or v3 | 12:53 |
| dmsimard | mnaser: it's in a nodepool element | 12:53 |
| mnaser | okay cool, so us calling '/usr/local/jenkins/slave_scripts/install-distro-packages.sh' is okay | 12:53 |
| dmsimard | I don't think there's anything in our current migration items to change that for the time being although it may become deprecated in favor of putting such scripts inside proper ansible things | 12:54 |
| dmsimard | just like we translated a lot of devstack-gate things to proper ansible | 12:55 |
| dmsimard | (from bash) | 12:55 |
| mnaser | it looks good to me, reading the info about it, i understand that we should be putting our common puppet stuff in openstack-zuul-jobs (or zuul-jobs if we manage to make it really generic) and then add .zuul.yaml per project (per puppet module in this case?) | 13:03 |
| dmsimard | mnaser: any components (nodesets, jobs, templates, etc.) can be shared between any project | 13:04 |
| dmsimard | the only thing that is restricted is putting jobs in pipelines for projects | 13:04 |
| mnaser | so does that mean we can have puppet-openstack-zuul-jobs and make infra's life asier | 13:04 |
| mnaser | easier* | 13:05 |
| dmsimard | this can only be done by trusted projects, which right now is $self and project-config | 13:05 |
| dmsimard | mnaser: personally I'd probably put common things in puppet-openstack-integration ? | 13:05 |
| dmsimard | and as required, you can also have a zuul.d folder to split things if it gets too cumbersome | 13:05 |
| mnaser | so the only thing we'd need infra for is pretty much.. pipeline changes? | 13:05 |
| mnaser | hm, we can do that too | 13:05 |
| dmsimard | mnaser: https://review.openstack.org/#/c/504782/ | 13:06 |
| dmsimard | you can change pipeline items as well | 13:06 |
| dmsimard | except, for example, the puppet-nova pipeline can only be set by itself | 13:06 |
| dmsimard | you can't have the puppet-nova pipelines set in the p-o-i zuul.yaml | 13:06 |
| mnaser | ah i see unless we request p-o-i to be "trusted" i guess | 13:07 |
| dmsimard | not going to happen I don't think | 13:07 |
| dmsimard | right now it's black or white afaik, trusted projects can do everything, it's not a subset | 13:07 |
| mnaser | we can put all the jobs in p-o-i and then the pipelines in the repo | 13:07 |
| mnaser | or maybe pipelines in project-config would be better | 13:08 |
| dmsimard | something like that makes sense I think, yeah | 13:08 |
| mnaser | in case we want to do a massive change to something non voting | 13:08 |
| dmsimard | going through project-config means you'll need -infra to merge things | 13:08 |
| mnaser | yeah but that saves us the ~40-50 possible changesets if we need to set something to nv | 13:08 |
| mnaser | or add a new job for example | 13:08 |
| dmsimard | hm, that's a good point | 13:09 |
| dmsimard | jeblair, mordred ^ interesting imo | 13:09 |
| mordred | dmsimard, mnaser: you can set voting: False on a job definition itself | 13:15 |
| mordred | dmsimard, mnaser (sorry, reading scrollback in a weird sequence) | 13:15 |
| mnaser | mordred sure, but for cases like.. we want to add puppet 5 jobs, or some experimental puppet nightly job | 13:16 |
| mordred | dmsimard, mnaser: /usr/local/jenkins/slave_scripts/ is DEFINITELY deprecated | 13:16 |
| mordred | and most things you need, like install_distro_packages already have new roles | 13:16 |
| mordred | mnaser: yah - that's a case where we'll have to explore best practices for a little while | 13:16 |
| mordred | mnaser: we don't have a way to make a puppet-openstack-zuul-jobs that you could use to set pipeline config for other projects at the moment - we could certainly make an puppet-openstack-zuul-jobs where you could put shared jobs | 13:18 |
| mnaser | i assume the concept of job groups still exist | 13:18 |
| mordred | but giving a repo access to put jobs into other projects pipelines currently also give the peopel who can land changes there the ability to land changes that do trusted things on the executors | 13:18 |
| mordred | absolutely! | 13:18 |
| mnaser | we can have a very simplistic zuul file that literally points to "puppet-jobs" | 13:19 |
| mnaser | or some iteration of that | 13:19 |
| mordred | yup | 13:19 |
| mnaser | and we can play with what we need globally in a centralized repo so one switch can change them all | 13:19 |
| mordred | yes. that's a great call! | 13:20 |
| mordred | that should work really nicely | 13:20 |
| mordred | and not require any new things | 13:20 |
| mordred | (this is why I'm really looking forward to getting everybody else playing) | 13:20 |
| mnaser | cool, well im looking forward to it because seeing that duplicated translated code is killing me :D | 13:21 |
| *** pbrobinson has quit IRC | 13:29 | |
| *** pbrobinson has joined #zuul | 13:30 | |
| *** weshay is now known as weshay_bbiab | 13:30 | |
| openstackgerrit | zhangyangyang proposed openstack-infra/nodepool master: Cleanup test-requirements https://review.openstack.org/506181 | 13:49 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: make console-stream tenant scoped https://review.openstack.org/505452 | 14:08 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /{source}/{project}.pem route https://review.openstack.org/502530 | 14:09 |
| pabelanger | okay, nl01 is in emergency file while we land new nodepool.yaml configuration. I've also set max-servers for providers that will be removed to 0 in hopes that we don't leak anything | 14:22 |
| jeblair | dmsimard, mordred: we *do* need required-projects set for any jobs that are currently using zuul-cloner | 14:26 |
| dmsimard | jeblair: doh | 14:26 |
| *** hashar has joined #zuul | 14:26 | |
| dmsimard | this is a big issue for the migration then, is it not ? | 14:26 |
| jeblair | it should be fairly straightforward for devstack-gate jobs, we can search for PROJECTS= lines in the shell snippets and parse them | 14:28 |
| jeblair | but jobs that use zuul-cloner internally are less straightforward. and those that do so in scripts in their own repos (as opposed to project-config jjb) even less so. | 14:29 |
| jeblair | the jobs will still call zuul-cloner, it's just that zuul-cloner will now be a simple shim that copies already set-up git repos into place. | 14:29 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: make console-stream tenant scoped https://review.openstack.org/505452 | 14:31 |
| *** openstackgerrit has quit IRC | 14:33 | |
| dmsimard | jeblair: ok, but does that require setting up required-projects ? | 14:34 |
| dmsimard | jeblair: required-projects prepares the cached repos inside the workspace with an updated ref (i.e, depends-on) right ? | 14:34 |
| dmsimard | or wait, no, there's a role for that I guess | 14:35 |
| jeblair | dmsimard: zuul sets up the repos listed in required-projects inside the jobdir on the executor. the role just copies that onto remote hosts. | 14:38 |
| dmsimard | jeblair: ok so if legacy-puppet-job-xyz zuul-clones puppet-nova and puppet-nova isn't in required-projects, it won't work ? | 14:40 |
| jeblair | yep | 14:43 |
| dmsimard | I guess this is a new thing in v3. In v2, you did not need to "forecast" which projects you might need to do a Depends-On on from | 14:44 |
| jeblair | dmsimard: http://lists.openstack.org/pipermail/openstack-infra/2017-August/005570.html | 14:44 |
| jeblair | dmsimard: it's not forecasting what you need to depends-on, it's forecastang what you need to *run*. *that* should be pretty straightforward for any job. :) | 14:45 |
| dmsimard | right, I'm mixing up depends-on and single/standalone zuul-cloner executions | 14:46 |
| mordred | jeblair, dmsimard: ah - so we do need to do a thing for this in the migration script | 14:46 |
| mordred | right? | 14:47 |
| jeblair | mordred: ya | 14:47 |
| mordred | jeblair: goodie. welp, I guess that's my task for the day - unless dmsimard wants to pla :) | 14:47 |
| jeblair | mordred: parsing PROJECTS will get us a lot. heuristics like "does it say neutron in the name? include neutron" is another good chunk. | 14:47 |
| dmsimard | I had manually done this (see the 'required-projects' job) in a previous patchset which is probably very horrible and maybe even doesn't work https://review.openstack.org/#/c/505921/3/zuul.d/v3-testing-puppet-jobs.yaml | 14:48 |
| jeblair | dmsimard: at least that should be caught by a PROJECTS search | 14:51 |
| dmsimard | where does this PROJECTS search occur ? there's no notion of PROJECTS in any puppet-openstack or openstack-ansible things, they don't even run devstack-gate | 14:52 |
| mordred | jeblair: what does PROJECTS start as? | 14:55 |
| mordred | jeblair: is it the list of projects that share the same implied pipeline? | 14:55 |
| mordred | jeblair: (there are lots of things like export PROJECTS="openstack/python-zunclient $PROJECTS" | 14:55 |
| mordred | in fact, that's BY FAR the most common form | 14:56 |
| jeblair | mordred: starts as nothing | 14:57 |
| jeblair | mordred: (it's not a zuul thing) | 14:57 |
| jeblair | (so the first copy-pastad PROJECTS="foo $PROJECTS" line is just going to eval as PROJECTS="foo " | 14:58 |
| mordred | jeblair: gotcha | 14:58 |
| jeblair | and i don't think we have to actually bash eval these things, just grep for "something that looks like a project name" in those lines and always add it to the set | 14:59 |
| mordred | yup | 14:59 |
| jeblair | (but do handle the case where there's more than one) | 14:59 |
| jeblair | PROJECTS="foo bar $PROJECTS" | 14:59 |
| mordred | we will likely have issues with scripts called from people's repos that call zuul-cloner - including devstack-gate | 15:00 |
| mordred | I'll do thejjb parsing first, then see what we can figure out about devstack-gate (altohugh maybe it's just add the maximal set?) | 15:00 |
| mordred | it's POSSIBLE of course to follow breadcrumbs to find PROJECTS lines in in-repo scripts - but I doubt that's doable in the short term | 15:01 |
| mordred | dmsimard: btw - thank you for finding that - that's a great catch | 15:01 |
| jeblair | there's some more potential issues raised in the ml post; it's probably worth reading again | 15:03 |
| jeblair | there's some more potential issues raised in the ml post; it's probably worth reading again | 15:13 |
| jeblair | ga, sorry | 15:13 |
| dmsimard | mordred: that's the kind of stuff I want to find by test-driving something that isn't devstack :p | 15:15 |
| dmsimard | so what's the solution here, should there be a 'required-projects' "template" stanza just like we have jobs, nodesets, job-templates and so on and then be able to refer to that inside a job ? | 15:15 |
| mordred | dmsimard: I don't think we need a template stanza - it's a feature of a job and it is additive via inheritance | 15:18 |
| mordred | dmsimard: so for migratoin script we can just add required-projects to the emitted job definitions | 15:18 |
| mordred | dmsimard: but as people write native jobs, they can make, for instance, a "puppet-openstack-base" job that has a required-projects list, then have jobs thatuse puppet-openstack-base that need an additional project add it in that job definition | 15:19 |
| mordred | it's a much more tractable issue on a per-project basis than on a global from-infra basis | 15:19 |
| mordred | jeblair: speaking of - you may enjoy the scrollback between dmsimard and mnaser in #openstack-infra from early this morning and then my brief follow up to it | 15:19 |
| jeblair | mordred: which topic? | 15:21 |
| dmsimard | mordred: it was probably here in #zuul unless you mean the third party CI | 15:21 |
| mordred | jeblair: mnaser was asking questions about having something like a puppet-openstack-jobs repo but as a config-project so that they could set jobs in project-pipelines for all thepuppet-openstack jobs - I mentioned that woulnd't work (for the reasons) and then mnaser realized he can make a project-template and just update that for the same effect | 15:21 |
| mordred | oh - you're right - it was here in #zuul | 15:21 |
| jeblair | mordred: yeah, i read that :) | 15:21 |
| mordred | in any case - I thought it was great that mnaser came up with that solution not even having used the new system yet :) | 15:22 |
| jeblair | imagine what will happen when he can! :) | 15:22 |
| * dmsimard nods | 15:22 | |
| dmsimard | jeblair: so did the job "puppet-required-projects" in https://review.openstack.org/#/c/505921/3/zuul.d/v3-testing-puppet-jobs.yaml (and setting it as parent of most jobs) make sense, then ? | 15:25 |
| dmsimard | I'm not sure if this would even work because there's no pre-run/run/post-run on that job | 15:25 |
| jeblair | dmsimard: yeah that works | 15:26 |
| dmsimard | ok, I'll restore that patchset then. | 15:26 |
| jeblair | of course, having the migration script do that is an extra cycle of factoring | 15:26 |
| dmsimard | for puppet it was fairly straightforward to do by hand because it's limited | 15:27 |
| dmsimard | to just other puppet modules (and tempest, actually) | 15:28 |
| jeblair | that's okay for testing, but we shouldn't count on doing that when we run for real since we may need to be able to update something and run again | 15:28 |
| dmsimard | ah.. come to think of it (I'm mixing up depends-on and zuul-cloner again) OSA probably only zuul-clones roles. | 15:28 |
| dmsimard | jeblair: right, I'm doing this exercise to test the migration result, basically.. and find issues such as this one | 15:29 |
| dmsimard | I'm a bit concerned about the seeming lack of v3 testing on project-config fwiw | 15:30 |
| jeblair | dmsimard: can you clarify your concern? | 15:32 |
| dmsimard | For the migration test patch I sent, I'm not 100% confident I cherry-picked everything I needed but I guess I didn't see zuul complain about any syntax errors or missing things | 15:33 |
| dmsimard | I guess I'm not touching any base jobs so worst case scenario there'll be failing (non-voting) jobs on puppet-openstack-integration and puppet-nova | 15:34 |
| *** openstackgerrit has joined #zuul | 15:36 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: web: add /{source}/{project}.pem route https://review.openstack.org/502530 | 15:36 |
| mnaser | dmsimard once something is converted, does the migration tools have that knowledge (aka, could we start rewriting p-o-i code in zuulv3) or will we still have to do the big cutover | 15:41 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul feature/zuulv3: encrypt_secret: remove the trailing '/' when building url https://review.openstack.org/506271 | 15:48 |
| dmsimard | mnaser: the projects aren't whitelisted and thus can't really start building things | 15:57 |
| dmsimard | mnaser: (ahead of the cutover) | 15:57 |
| dmsimard | mnaser: the migration script converts anything it finds under jenkins/jobs and zuul/layout.yaml | 15:57 |
| jeblair | dmsimard: zuul performs project-config syntax checks; it will -1 the patch if there's an error | 16:01 |
| jeblair | mordred: can you +3 https://review.openstack.org/505845 and i'll start work on the nodes->nodeset transition | 16:04 |
| mordred | jeblair: done | 16:06 |
| mordred | jlk, jamielennox, SpamapS: ^^ the patch above is an important breaking change you should be aware of | 16:06 |
| mordred | or, rather, the follow up | 16:06 |
| jeblair | mordred: is https://review.openstack.org/504624 current or does it need rework due to our docs-draft discussion yesterday? | 16:07 |
| *** weshay_bbiab is now known as weshay | 16:07 | |
| mordred | jeblair: it's probably going to change, but I think it's fine to land it - I think buldling on top of that stack rather than reworking from within is likely easier | 16:09 |
| jeblair | ok | 16:10 |
| mordred | jeblair: we'll need to idenfity the things using docs-draft to set up their copy tasks nad set success-url anyway | 16:10 |
| jeblair | good point | 16:10 |
| * SpamapS looks | 16:12 | |
| SpamapS | btw, side note: gertty works fine on OS X ;) | 16:12 |
| mordred | SpamapS: tl;dr - job.nodes is changing to job.nodeset | 16:12 |
| SpamapS | ohmy | 16:12 |
| jeblair | (and getting indented; so "job: nodeset: nodes:") | 16:12 |
| mordred | yah- if you're not reusing an existing nodeset in the job but are defining an anonymous one | 16:13 |
| SpamapS | mmk. Should be easy enough to adapt to once it lands | 16:13 |
| mordred | yah | 16:13 |
| mordred | transition should be easy enough | 16:13 |
| mordred | SpamapS: we're landing it in two steps - so enabling the new conf just got +3d | 16:13 |
| mordred | once that's landed you can transition | 16:13 |
| mordred | (and so can we) | 16:14 |
| mordred | then we'll land the "remove old conf" once transition is done | 16:14 |
| SpamapS | fun fact about Ansible 2.4 + CentOS 7 ... the sftp method it tries to use doesn't work. scp_if_ssh=true seems to be required for performance (it will automatically fall back to scp) | 16:14 |
| clarkb | re gertty there is a github issue on Go about dumping gerrit for github and one of the complaints is "cli tools are bad" and both git-review (not sure if Gos or ours yay) and gertty have been mentioned as "uh cli is great" | 16:14 |
| mordred | clarkb: woot! | 16:14 |
| SpamapS | yeah, wow | 16:14 |
| SpamapS | hub is attrocious | 16:15 |
| mordred | clarkb: (I'm guessing our git-review - they renamed theirs to git-codereview thanks to pleia2) | 16:15 |
| clarkb | oh neat | 16:15 |
| SpamapS | Maybe we should add a terrible issue tracker to gerrit so it can compete with github. | 16:15 |
| clarkb | one of my favorite comments was from someone who said basically "I avoided gerrit for years because it is different, but then I gave in and tried it and it was easy and only took a few minutes" | 16:16 |
| SpamapS | yep | 16:16 |
| SpamapS | same reason I'm powering through my OS X hell right now. "Maybe it's just my problem and it works fine." | 16:16 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Removed unused 'status: ' string from log line https://review.openstack.org/505378 | 16:18 |
| *** hashar has quit IRC | 16:18 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add job.nodeset parameter to supercede job.nodes https://review.openstack.org/505845 | 16:19 |
| SpamapS | can somebody explain to me zuul-web? I'm trying to adapt my thing to using it but I don't _really_ understand. | 16:20 |
| SpamapS | (in a panic I sort of got it working but I want to understand its relation to the old port 8001 webapp) | 16:21 |
| SpamapS | is the idea that I won't need an nginx in front of it? because I would very much like zuul to be like Jenkins in that respect.. just let people use it on the port that sucks until you need the speed from a static webserver. | 16:22 |
| jeblair | SpamapS: yes, a proxy will be optional | 16:22 |
| SpamapS | \o/ | 16:22 |
| SpamapS | jeblair: but that's not quite done yet? | 16:22 |
| jeblair | SpamapS: zuul-web contains the log streaming code | 16:22 |
| jeblair | SpamapS: it couldn't fit in the old app because it needs asyncio for websockets | 16:23 |
| SpamapS | I'm wrestling the BonnyCI hoist ansible to setup nginx for streaming + status is why I"m asking. | 16:23 |
| jeblair | SpamapS: but it's the future. we'll port everything to it | 16:23 |
| jeblair | SpamapS: currently, proxy is effectively required (i mean, you could hand out http://serevr:port urls, but that's ugly) to mask the fact we have 2 webservers | 16:23 |
| jeblair | SpamapS: once everything is zuul-web, it's simple again | 16:24 |
| SpamapS | yeah that's what I figured. | 16:24 |
| SpamapS | Ok, so I just need to proxy status to 8001 and streaming to 9001, which is what I did in a panic. ;) | 16:24 |
| jeblair | that'll be a fairly high-priority post-openstack-cutover thing i think. especially since tristanC and jlk have much done already. | 16:24 |
| SpamapS | And I assume zuul-web will get status data via gearman? | 16:25 |
| tobiash | Yes | 16:25 |
| SpamapS | cool | 16:26 |
| jeblair | jlk, tobiash: can we get a little wider discussion about patches that introduce new concepts like https://review.openstack.org/502188 ? | 16:36 |
| jeblair | i would like us not to have merged that patch | 16:36 |
| jeblair | and i have no idea how to undo that | 16:37 |
| jeblair | since reverting it isn't going to change the fact that there's something in some commit message there | 16:37 |
| jeblair | the only way i know to undo that is to rewrite the git repo history | 16:38 |
| SpamapS | ooo nice new feature in ansible 2.4 | 16:41 |
| SpamapS | [WARNING]: While constructing a mapping from /Users/cbyrum/src/BonnyCI/hoist/roles/common/tasks/main.yml, line 13, column 3, found a duplicate dict key (when). Using last defined value only. | 16:41 |
| SpamapS | jeblair: sounds like a new pbr feature is needed: respect reverts of Sem-Ver headers. | 16:42 |
| jeblair | SpamapS: maybe it does that? i don't know? | 16:43 |
| SpamapS | Well it should. I suppose it's easy enough to test. | 16:43 |
| SpamapS | btw, do we really want to have a 3.0.0.devXXX, and does pip know that's << than 3.0.0 ? | 16:43 |
| jeblair | i just believe that all mistakes should be correctible. this doesn't seem to be the case. | 16:43 |
| jeblair | (or if it is the case, it's not obvious) | 16:44 |
| tobiash | jeblair: sorry, didn't know this was a new concept | 16:44 |
| mordred | SpamapS: yes - 3.0.0.devXXX is understood by pip to be << 3.0.0 - dev is pip's version of debian's ~ | 16:46 |
| SpamapS | mordred: excellent | 16:46 |
| * SpamapS is testing what happens when one reverts | 16:46 | |
| mordred | jeblair, tobiash, SpamapS, jlk, pabelanger: I had a thought from the above ^^ which is that there are times when I want to toss up a patch to get thoughts from jeblair, but I also don't want to bug him about it because it's not urgent | 16:46 |
| mordred | so I'm thinking about starting to tag such patches by setting their topic to "jeblair" | 16:47 |
| tobiash | If that cannot be undone a rebase and force push would be needed and reupload the two changes above | 16:47 |
| * mordred apologizes to everyone - had intended to put that patch up for jeblair's input and then honestly forgot to point it out to, well, anyone | 16:49 | |
| *** logan- has joined #zuul | 16:49 | |
| SpamapS | reverts do not affect pbr | 16:49 |
| SpamapS | confirmed | 16:49 |
| jeblair | mordred: it "worked" :) | 16:50 |
| SpamapS | mordred: you can set them to WIP. I take that as "DNM" | 16:50 |
| * SpamapS looks to see how hard this might be in pbr | 16:51 | |
| mordred | SpamapS: yah - the specific set of inputs that have caused me to want to invent a jeblair topic is a) WIP tends to get ignored unless pointed to by someone b) not important enough to justify sending a "would you look at this" interrupt | 16:52 |
| mordred | we could also use a different topic (untill we get gerrit hashtags) like "needs-consensus" or something | 16:52 |
| SpamapS | mordred: You could subscribe him as a reviewer. | 16:52 |
| jeblair | SpamapS: i look at all zuul changes | 16:52 |
| SpamapS | In vanilla gerrit, that shows up in "my changes" | 16:53 |
| mordred | SpamapS: does that communiate anyting to gertty though? | 16:53 |
| mordred | and yah - all the zuul patches are already in his queue | 16:53 |
| jeblair | i've just been laser focused on migration, so i'm ignoring others | 16:53 |
| jeblair | it's not a standard workflow | 16:53 |
| mordred | anywho - once the migration is done it's likely a thing that'll come up less, as I won't be trying to avoid bothering folks | 16:53 |
| SpamapS | or yeah, that's not in "My Changes" but in your subscribed changes | 16:53 |
| SpamapS | so yeah wouldn't bump it up | 16:53 |
| SpamapS | It would email him tho | 16:54 |
| SpamapS | if he read emails on it | 16:54 |
| jeblair | SpamapS: i get emails on all zuul patches too :) | 16:54 |
| * mordred gets emails on no patches | 16:54 | |
| SpamapS | I only get emails on subscribed patches | 16:54 |
| jeblair | (i read emails on no patches) | 16:54 |
| SpamapS | meaning ones I touched | 16:54 |
| jeblair | at any rate, i think the signal isn't for *me* it's for others :) | 16:54 |
| SpamapS | aye | 16:54 |
| jeblair | or at least, not just me | 16:55 |
| SpamapS | Also I tend to read comments before +A'ing.. so if there's one that says "please don't merge this until jeblair looks at it" ... | 16:55 |
| SpamapS | This feels like a corner case that is worth lightweight communication. | 16:55 |
| SpamapS | the topic is probably fine too | 16:55 |
| SpamapS | now.. pbr | 16:56 |
| SpamapS | jeblair: could we fix this by tagging 2.5.2.dev1250 or something? | 16:58 |
| * SpamapS tries that locally | 16:58 | |
| dmsimard | jlk, tristanC: FYI 'nodes' will go through a quick deprecation to be replaced by 'nodeset' -- need to adjust Software Factory and Bonny | 16:58 |
| dmsimard | See: https://review.openstack.org/#/c/505845/ | 16:59 |
| *** electrofelix has quit IRC | 16:59 | |
| jeblair | i'm deleting and recreating the feature/zuulv3 branch now | 17:01 |
| jeblair | oh right, open changes | 17:02 |
| SpamapS | wwwwhhhat? | 17:04 |
| dmsimard | that sounded overly casual ? | 17:04 |
| SpamapS | jeblair: so I tried tagging with 2.5.3.dev1213 (1 higher than the last known 2.5.3.dev) and the next commit becomes 2.5.4.dev1 | 17:04 |
| SpamapS | not ideal, but it does roll back the problem. | 17:05 |
| SpamapS | and seems simpler than deleting the branch? :-P | 17:05 |
| jeblair | fundamentally, i'm opposed to the fact that semver commit comments are irreversible. patching over them isn't reversing, it's just adding complexity and confusion. | 17:07 |
| jeblair | it should always be safe to land a patch because it should always be possible to revert it. this is a non-revertible patch. | 17:08 |
| jeblair | okay, so what i'm actually going to have to do is abandon all open changes on feature/zuulv3; recreate the branch at the correct commit, then restore those changes | 17:13 |
| SpamapS | jeblair: this is a bug in pbr's Sem-Ver, but getting it fixed may take a little while. | 17:13 |
| SpamapS | what? | 17:13 |
| SpamapS | is that really necessary? | 17:13 |
| SpamapS | vs. just adding a tag to skip a never-going-to-be-made release? | 17:14 |
| tobiash | A rebase -i and push should work withou abandoning all changes | 17:15 |
| SpamapS | yeah | 17:15 |
| SpamapS | but still | 17:15 |
| SpamapS | feels like overkill for something we can workaround | 17:15 |
| jeblair | tobiash: clarkb prefers the branch recreate method. i'm happy to push if he's okay with that. | 17:15 |
| SpamapS | or just ignore me. | 17:16 |
| jeblair | SpamapS: i'm not ignoring you :) | 17:16 |
| jeblair | SpamapS: i'm writing a reply to you | 17:16 |
| jeblair | SpamapS: i don't think we can work around it. that's why i feel so strongly about this. we *must* be able to undo mistakes made in development. no amount of patching to pbr or additional semver tags can undo this commit. | 17:16 |
| clarkb | ya its mostly bcause branch delete create is somethibg cores are likely to maybe get access to in some way | 17:17 |
| clarkb | but not force push | 17:17 |
| clarkb | (so seems like the more general process to use) | 17:17 |
| jeblair | the semver in commit messages are fundamentally flawed and no one should ever use them. | 17:17 |
| SpamapS | I'd prefer to patch pbr to allow ignoring them if that's the case. | 17:17 |
| SpamapS | but meh. it's a feature branch. a 1200+ commit feature branch, but still, it's just us in here. | 17:18 |
| jeblair | SpamapS: you mean ignore them by a flag in setup.cfg? | 17:18 |
| SpamapS | Yeah, if they're that problematic (I haven't thought through it). | 17:19 |
| SpamapS | also worth a linter step maybe to disallow them | 17:19 |
| jeblair | if that's possible, i think that's a fine idea | 17:20 |
| SpamapS | though commit message based jobs are always wonky | 17:20 |
| jeblair | (to clarify: i think the option to disable is a fine idea) | 17:21 |
| jeblair | but as you say, that's bound to be a ways out | 17:21 |
| SpamapS | yeah, versions are important and I think many pbr users may want to maintain stronger control of them. | 17:21 |
| jeblair | in the mean time, i'd like to procede with the branch rewind plan | 17:22 |
| jeblair | clarkb hasn't said "oh, just force-push :)" so i'll go with abandon/delete/create/restore | 17:23 |
| jeblair | i'm going to send an email about it, take a short break, then execute that plan | 17:24 |
| jeblair | feel free to push up feature/zuulv3 changes for the next little while, but please don't merge any. i'll make an announcement here when i need to freeze the open changes. | 17:24 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Migrate docs-draft jobs to emit to logs/html https://review.openstack.org/506316 | 17:27 |
| jeblair | okay, mail sent to openstack-infra; back in about 30m to do that. | 17:38 |
| pabelanger | jeblair: Shrews: okay, both nl01 and nl02 are running again, each with site specific configuration | 17:49 |
| pabelanger | I'm now going to bump max-server to 10 for all providers so we don't have the wedge again | 17:50 |
| jlk | re nodeset and nodes, can I in a job add nodeset: nodes: - name: whatever | 18:15 |
| jlk | label: something_nodepool_knows | 18:15 |
| jlk | without defining the nodeset elsewhere? | 18:15 |
| dmsimard | ouch, I didn't know that sem-ver thing even existed | 18:16 |
| jeblair | jlk: yes, named nodesets are entirely optional. | 18:20 |
| jeblair | everything you can do in a nodeset, you can do in an individual job defn. | 18:20 |
| jlk | kk | 18:21 |
| mordred | jlk: this all came up from trying to make an anonymous nodeset on a job that needed groups - and not having any way to add groups there - whoops | 18:23 |
| jlk | heh | 18:23 |
| jeblair | even the documentation said you could do that. :) | 18:23 |
| mordred | yup! | 18:24 |
| kklimonda | looking at the zuulv3, can scheduler distribute jobs to zuul executors running in different private OS clouds as long as they can connect to gearman? | 19:00 |
| dmsimard | kklimonda: executors or nodepool nodes ? the jobs are executed from an executor but typically ran against nodepool virtual machine | 19:02 |
| kklimonda | dmsimard: in general, nodepool nodes | 19:03 |
| mordred | kklimonda: right now there is no way to tie an executor to a given nodepool cloud | 19:04 |
| mordred | kklimonda: so while it is currently physically possible to run executors in different private OS clouds if they can reach gearman, they might be handed nodes from other clouds | 19:05 |
| kklimonda | mhm | 19:06 |
| pabelanger | Ya, I think it is a great idea to look into for road map. I think we could apply it to infracloud today, since it suffers from badish networking. | 19:06 |
| mordred | this isn't the first time the question has come up for sure | 19:06 |
| pabelanger | Ya, keeping the git-repos cached on images does help with infracloud | 19:07 |
| kklimonda | https://storyboard.openstack.org/#!/story/2001125 <- is that the related story? | 19:13 |
| jeblair | kklimonda: yes | 19:16 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Extract required-projects from job content https://review.openstack.org/506335 | 19:26 |
| mordred | jeblair, dmsimard: ^^ that does the first-pass of grabbing required-projects - still need 'infer from job name' and 'something something devstack-gate' | 19:27 |
| mnaser | mordred https://github.com/openstack/puppet-openstack-integration/blob/master/functions#L15-L48 hi we're here breaking your stuff -- we'd have to manually do it for our side of things? | 19:40 |
| * Shrews apologizes for his absence today and is working to rid his body of the evil illness-causing bug | 19:40 | |
| mnaser | puppetfile0 comes from us splitting Puppetfile at "## External modules" so its the list of everything there | 19:41 |
| mnaser | which is autogen'd from https://github.com/openstack/puppet-openstack-integration/blob/master/openstack_modules.txt | 19:41 |
| mordred | mnaser: yup. in good news - in v3 that openstack_modules.txt file can just be a list on a base job definition in your .zuul.yaml file | 19:45 |
| mnaser | :D | 19:45 |
| mnaser | which is why id like to have a tiny little head start in converting puppet jobs in zuul if possible | 19:46 |
| mordred | wow. you totally install cloudkitty :) | 19:47 |
| mnaser | i think we clone the modules but i dont see any integration jobs.. would be good to add a job for that :-P | 19:47 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Allow dict-based new jobs to have templated names https://review.openstack.org/506344 | 19:48 |
| *** weshay is now known as weshay_bbiab | 19:50 | |
| *** olaph1 has quit IRC | 19:51 | |
| dmsimard | mordred: parsing PROJECTS will be helpful for devstack/devstack-gate based jobs, but what about jobs that don't use either ? | 20:04 |
| dmsimard | (was reviewing your patch) | 20:04 |
| mordred | dmsimard: you have example? | 20:08 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Use publish-docs-draft base job for docs-draft publishers https://review.openstack.org/504624 | 20:11 |
| jeblair | okay that's another change i have to restack | 20:13 |
| jeblair | please don't approve (or recheck approved changes) untir further notice | 20:14 |
| dmsimard | mordred: http://git.openstack.org/cgit/openstack/puppet-openstack-integration/tree/run_tests.sh#n102 | 20:15 |
| dmsimard | http://git.openstack.org/cgit/openstack/openstack-ansible-os_designate/tree/tests/tests-repo-clone.sh#n61 | 20:15 |
| dmsimard | are two examples (which are repeated in different projects within puppet-openstack and openstack-ansible) | 20:15 |
| dmsimard | and it's probably even worse than that in the context of puppet -- if we take for example (mnaser keep me honest here) puppet-nova, the puppet-nova job will zuul-clone puppet-openstack-integration and then puppet-openstack-integration will zuul-clone things | 20:16 |
| dmsimard | I'm not all too familiar with the OSA usage of zuul-cloner, maybe odyssey4me can help | 20:17 |
| dmsimard | I wrote an email on openstack-infra a while back to highlight that http://lists.openstack.org/pipermail/openstack-infra/2017-September/005572.html | 20:17 |
| jeblair | and now please don't push up any more zuul patches until further notice | 20:20 |
| dmsimard | we have the zuul-cloner script which some projects use to detect if they're running in the gate, great -- but now we need to figure out what they end up cloning to make sure it's in required projects | 20:20 |
| mordred | dmsimard: yah - I think a few of these are tractable and I can get them knocked out quickly | 20:23 |
| jeblair | abandoning 64 open changes | 20:24 |
| jeblair | i'm going to stop zuulv3 so it misses the restore events later | 20:25 |
| jeblair | deleting feature/zuulv3 | 20:28 |
| jeblair | creating feature/zuulv3 | 20:28 |
| jeblair | restoring 64 changes | 20:29 |
| * jlk pours one out for feature/zuulv3 | 20:29 | |
| jeblair | feature/zuulv3 is dead; long live feature/zuulv3 | 20:29 |
| mnaser | dmsimard actually, we run the puppet-openstack-integration job which does the zuul-clone, and because the ZUUL_ env variables are preserved, the zuul-clone naturally checks out the change to be tested | 20:31 |
| mnaser | so all jobs will zuul-clone puppet-openstack-integration repo and then that repo's testing entry point will clone the modules | 20:32 |
| pabelanger | jeblair: did you copypasta 64 times or is there a mass abandon / open function some place? | 20:34 |
| jeblair | pabelanger: gertty | 20:34 |
| *** maxamillion has quit IRC | 20:35 | |
| jeblair | i starred all open changes to keep track of them, then marked all of them and abandoned them, then restored them | 20:35 |
| tobiash | Sorry again, it was not clear to me that this could have such an impact | 20:36 |
| pabelanger | jeblair: thanks! | 20:37 |
| mordred | tobiash: it's honestly my fault - I should have attached some sort of something to alert people | 20:37 |
| jeblair | no worries; mostly i want to make sure we do feel comfortable merging things and don't have to do everything perfectly all the time. :) it's ironic. | 20:38 |
| *** maxamillion has joined #zuul | 20:38 | |
| jeblair | reinstalling zuulv3 | 20:39 |
| jeblair | and restarting | 20:39 |
| jeblair | okay, we should be back to normal now; i'll re-propose the 3 other patches that got backed out | 20:39 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Removed unused 'status: ' string from log line https://review.openstack.org/506356 | 20:42 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add job.nodeset parameter to supercede job.nodes https://review.openstack.org/506357 | 20:42 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use publish-docs-draft base job for docs-draft publishers https://review.openstack.org/506358 | 20:42 |
| jeblair | those are just cherry-picks with the commit message amended to get a new change-id while linking to the old one | 20:42 |
| jeblair | if folks could approve those now, we'll be back in business | 20:42 |
| jeblair | and it's now fine to propose or merge changes to feature/zuulv3 again | 20:43 |
| jlk | looks like I didn't pull during the danger time. | 20:44 |
| mordred | done | 20:44 |
| *** jkilpatr has quit IRC | 20:47 | |
| mordred | jeblair: lucky for us, one can ALSO pass a list of repos to zuul-cloner on the command line - and in one case someone decided to do that | 20:57 |
| jeblair | mordred: i think that's actually the only way; we just invoke it with $PROJECTS or ${project_names} in the puppet case | 20:58 |
| mordred | jeblair: oh - well, what I mean is that they made the clonemap be: | 20:59 |
| mordred | clonemap: | 20:59 |
| mordred | - name: 'openstack/(.*)' | 20:59 |
| mordred | dest: '\1' | 20:59 |
| mordred | \o/ | 20:59 |
| jeblair | mordred: maybe we should have the zuul-cloner shim output an error message that says "you specified a repo not in required-projects -- here's the full list of repos i was given, add this to required-projects" | 20:59 |
| jeblair | yeah, clonemaps are probably not generally going to list individual repos; they're much more useful as name transformations. | 21:00 |
| mordred | jeblair: well - that's the only one in the jjb jobs that does that - the rest list individual repos | 21:01 |
| mordred | jeblair: repo org question/issue ... the intent is to put the converted jobs into openstack-zuul-jobs - but I'm about to add devstack-legacy as a parent to a large pile ofthem | 21:02 |
| mordred | jeblair: should we switch the order of devstack-gate and opentsack-zuul-jobs in main.yaml? or move devstack-legacy to openstack-zuul-jobs? | 21:02 |
| jeblair | let's move it | 21:02 |
| mordred | kk | 21:02 |
| jeblair | the job | 21:02 |
| mordred | yah | 21:02 |
| mordred | I somehow got that :) | 21:03 |
| jeblair | he | 21:03 |
| *** jkilpatr has joined #zuul | 21:04 | |
| jlk | so.. now that the branch thing is done, is there any high priority things I could help on for the migration? | 21:09 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Removed unused 'status: ' string from log line https://review.openstack.org/506356 | 21:10 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add job.nodeset parameter to supercede job.nodes https://review.openstack.org/506357 | 21:11 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Use publish-docs-draft base job for docs-draft publishers https://review.openstack.org/506358 | 21:11 |
| mordred | jeblair, jlk: gerritbot seems unpleased - but I just pushed 9 new migratoin script changes to zuulv3 | 21:20 |
| mordred | ah- they emitted into #openstack-infra | 21:20 |
| mordred | gah. foiled by pep8 | 21:39 |
| jeblair | i'm going to restart zuulv3 now to pick up the nodeset change | 21:42 |
| pabelanger | jeblair: mordred: Shrews: do we have a possible race condition with creating requests in nodepool? http://paste.openstack.org/show/621662/ | 21:42 |
| mordred | jeblair: cool | 21:42 |
| pabelanger | I see creating 1 request, but we then build 2 nodes | 21:42 |
| jeblair | pabelanger: the other request came from the other launcher | 21:45 |
| jeblair | launcher-debug.log:2017-09-21 21:40:00,688 INFO nodepool.NodePool: Creating requests for 1 debian-jessie nodes | 21:45 |
| *** jkt has joined #zuul | 21:46 | |
| pabelanger | Hmm, checking | 21:46 |
| jkt | hi there, I have an existing setup with zuul v2 (not v2.5), and I'm thinking about moving to v3 | 21:46 |
| jkt | one use case which we have is that we're developing some custom code using 3rd-party libraries which we mirror to our Gerrit | 21:47 |
| jkt | this mirroring is automatic, mneaning that we have no control over the stability of their respective masters | 21:47 |
| jkt | I see that zuul v3 has some support for cloning of several repositories, and I wonder if it's something that might help me | 21:48 |
| jkt | is it smart enough to e.g. handle git submodules? | 21:48 |
| pabelanger | jeblair: I'm a little confused, why would nl02 create a request to build debian-jessie in rax-ord? If rax-ord is not a provider in nl02.o.o? | 21:48 |
| pabelanger | Or is it because we have debian-jessie in both nl01 and nl02 | 21:49 |
| mordred | jkt: it very well might be helpful - although I do not believe we have any current support for git submodules | 21:49 |
| jeblair | jkt: we were actually talking about this earlier; the short answer is that it may eventually be able to help with that, though at the moment, the internal mirroring is not failure tolerant enough for that. but probably could be made to be. | 21:49 |
| jlk | Can we make it not handle submodules? :D | 21:49 |
| jkt | right now I use a poor man's solution with a bash script in my code repo which hardcodes the respective sha1s | 21:50 |
| jeblair | pabelanger: the request is for a label, it's not scoped to the provider. any provider is capable of noticing we're under min-ready and putting out a request for a node. in this case, they both did and raced. | 21:50 |
| jkt | https://docs.openstack.org/infra/zuul/user/jobs.html#git-repositories looks like it will prefer master, but that I could at least pin them to some branch like mycompany/myproduct | 21:51 |
| jeblair | pabelanger: perhaps the min-ready watcher can be made less racy? i'm not sure. | 21:51 |
| jeblair | oh neat, we accidentally published v3 jobs to the master location again | 21:52 |
| jeblair | mordred, pabelanger: ^ | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Extract required-projects from job content https://review.openstack.org/506335 | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Allow dict-based new jobs to have templated names https://review.openstack.org/506344 | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Extract required projects from embedded clonemaps https://review.openstack.org/506377 | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Support zuul-cloner command line arguments https://review.openstack.org/506378 | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Use legacy-dsvm-base as base job for dsvm jobs https://review.openstack.org/506379 | 21:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Add support for puppet-openstack-integration based jobs https://review.openstack.org/506389 | 21:52 |
| jkt | also. there's that situation where a libA changes API, and I need to adapt to that API change, so I very likely will require either: a) cross-repo atomic change items, or b) dependencies tracked in my code repo | 21:52 |
| mordred | jeblair: yay! | 21:53 |
| mordred | jeblair: I'll look in to that in just a sec- it's probably my fault with all of the doc-job dance | 21:53 |
| jkt | jeblair: "not failure tolerant enough"? | 21:53 |
| jeblair | jkt: zuul makes sure all repos are up to date before doing anything with them, so if the authoritative source is down, it will fail. | 21:54 |
| pabelanger | jeblair: Hmm, okay. Should we be concerned about the race right now or leave it for a late point in time? | 21:54 |
| jeblair | pabelanger: worry about it later. it'll probably manifest as essentially an off-by-one error for min-ready. :) | 21:55 |
| pabelanger | looking at publishing logs now | 21:55 |
| jkt | jeblair: actually, my source is always our internal Gerrit. It's "just" that I want to specify a ref to use for this dependency from within my other project | 21:55 |
| pabelanger | jeblair: okay | 21:55 |
| jeblair | jkt: then this may be helpful: https://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#attr-job.required-projects.override-branch | 21:56 |
| jkt | jeblair: thanks, I read that; what I would prefer even more was to specify a particular sha1 of each dependency from within my own project (not zuul's config, from within the code) | 21:58 |
| pabelanger | jeblair: mordred: I believe that content is old for https://docs.openstack.org/infra/zuul/ (I'm showing Sept. 6th) Maybe we can re-trigger a post jobs manually for zuul master branch and have it republish? | 21:58 |
| pabelanger | actually, we had new commits 2 days ago | 21:59 |
| pabelanger | Hmm | 21:59 |
| jeblair | jkt: it's fundamental that zuulv3 sets up the repos so that it can prepare the proposed future state. however, you can always just have the job check out that sha1 | 21:59 |
| mordred | pabelanger: oh - so that isn't that it did it again - that's that it did it back when it did it and we just haven't published master docs since? | 21:59 |
| pabelanger | mordred: ya, we should have something publish to master but didn't it seems. looking at why now | 21:59 |
| mordred | pabelanger: lovely | 22:00 |
| jkt | jeblair: thanks, yup, it's great that I won't at least need to take care of credential forwarding with v3, that alone is a nice improvement | 22:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul-jobs master: Switch job.nodes to nodeset https://review.openstack.org/506396 | 22:00 |
| pabelanger | mordred: Oh, haha. Is it because we are missing a .zuul.yaml for zuul master branch? | 22:02 |
| pabelanger | actually, we have master | 22:03 |
| mordred | yah - but it's out of date and doesn't have post | 22:03 |
| mordred | good call | 22:03 |
| pabelanger | Yup | 22:03 |
| pabelanger | I can update now | 22:03 |
| mordred | pabelanger: well - hang on just a sec | 22:03 |
| pabelanger | holding | 22:03 |
| mordred | pabelanger: there's a couple of more doc related patches floating - let's get them landed before we do that one | 22:04 |
| pabelanger | kk | 22:04 |
| mordred | pabelanger: https://review.openstack.org/#/c/504785 is one | 22:04 |
| mordred | pabelanger: https://review.openstack.org/#/c/506305/ is the other | 22:05 |
| mordred | pabelanger: and then once those two land we'll want a third to remove openstack-doc-build from p-c again (what a fun dance this was!!!) :) | 22:05 |
| pabelanger | k, +2 to both | 22:07 |
| mordred | pabelanger: thanks! | 22:07 |
| mordred | jeblair, clarkb, fungi: any chance y'all could +3 those two patches? | 22:07 |
| jeblair | mordred: i actually just found and +3d 785 since it's blocking nodeset work | 22:07 |
| mordred | yay! | 22:08 |
| jeblair | looking at other now | 22:08 |
| jeblair | i'm going to beg for quick nodeset reviews so i'm not chasing this down forever: | 22:09 |
| jeblair | https://review.openstack.org/506394 https://review.openstack.org/506396 https://review.openstack.org/506399 | 22:09 |
| jeblair | pabelanger, mordred: ^ | 22:10 |
| jeblair | also: running zuulv3 now supports job.nodeset, so please don't land any more changes with job.nodes | 22:10 |
| mordred | jeblair: on it | 22:11 |
| mordred | jeblair: I have started workingon update the migration script to do nodeset instead of nodes as well | 22:11 |
| pabelanger | +2 all around | 22:11 |
| jeblair | mordred: great, thanks! | 22:12 |
| jlk | so good news about ANsible 2.4, it'll fix retries with synchronize: https://github.com/ansible/ansible/issues/18281 | 22:14 |
| jlk | (I found that in a comment in migrate.py) | 22:14 |
| clarkb | my fix finally made it into a release? | 22:14 |
| mordred | clarkb: \o/ | 22:17 |
| jlk | It appears so by following the breadcrumbs | 22:18 |
| *** yolanda has quit IRC | 22:18 | |
| SpamapS | lurvely | 22:19 |
| *** yolanda has joined #zuul | 22:20 | |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Migrate node information to nodeset instead of nodes https://review.openstack.org/506405 | 22:21 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Fixed a few earlier review nits https://review.openstack.org/506406 | 22:21 |
| mordred | jlk: fixed your review nits from https://review.openstack.org/#/c/506316/ in https://review.openstack.org/506406 | 22:21 |
| jlk | Viewing | 22:21 |
| mordred | jlk: thanks for looking at that stack, btw | 22:22 |
| jlk | *hattip* | 22:22 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Switch job.nodes to nodeset https://review.openstack.org/506396 | 22:23 |
| * SpamapS updates his local mirror | 22:24 | |
| jeblair | i +3d a lot of things. biab. | 22:31 |
| mordred | jeblair: yay! | 22:31 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Don't emit net-info macro https://review.openstack.org/506412 | 22:46 |
| SpamapS | hm, why are my jobs failing with RETRY_LIMIT instead of a real failure? | 22:48 |
| jlk | because they're failing in the pre jobs, and Zuul retries those a few times | 22:48 |
| jlk | because it's expected that those parent pre jobs are maintained by the zuul admin and are rock solid, rather than random dirty code from hippy project developers. | 22:48 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Emit shell instead of script tasks https://review.openstack.org/505379 | 22:55 |
| SpamapS | ahhh | 22:55 |
| SpamapS | jlk: my pre jobs are zuul-jobs .. so hrm | 22:56 |
| SpamapS | I just don't have a tox.ini | 22:56 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Omit some jobs from shared queue calculation https://review.openstack.org/505380 | 22:56 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Deal with link-logs macro https://review.openstack.org/505387 | 22:56 |
| SpamapS | so tox-linters is unhappy | 22:56 |
| SpamapS | I bet its something else | 22:56 |
| mordred | SpamapS: I mean - it SHOULD still give you error logs | 22:59 |
| SpamapS | mordred: Yeah it's 'sploding | 23:02 |
| pabelanger | SpamapS: is your zuulv3 logs public? | 23:02 |
| SpamapS | nope :( | 23:02 |
| pabelanger | kk | 23:02 |
| SpamapS | But I was just more wondering :) | 23:02 |
| jlk | it carries on the "no valid host" fun from Nova | 23:02 |
| mordred | that's my favorite error | 23:02 |
| jlk | I've been thinking about getting it tattooed somewhere | 23:03 |
| jlk | or maybe just T-shirts that say "Not a valid host" | 23:03 |
| * SpamapS is a valid host | 23:06 | |
| clarkb | beware the botflies | 23:06 |
| clarkb | (also don't google that) | 23:06 |
| SpamapS | question on the tenant prefixes for status | 23:08 |
| SpamapS | is the openstack zuulv3 using them? | 23:08 |
| SpamapS | or is it just being tacked on in the apache rules? | 23:08 |
| jeblair | SpamapS: apache rules | 23:08 |
| SpamapS | they're giving me fits | 23:08 |
| SpamapS | ok, I'll just do that then | 23:08 |
| jeblair | (cause we only have one tenant... for now) | 23:09 |
| SpamapS | will be easier to handle once zuul-web is done | 23:09 |
| SpamapS | yeah I only have one tenant now too :) | 23:09 |
| SpamapS | and nginx doesn't want to play nice with a regex that might match inside another one and proxy..I think | 23:09 |
| SpamapS | just simpler to not hand out the tenant urls | 23:09 |
| mordred | SpamapS: yah - that's what we're doing - zuulv3.openstack.org gets you to zuul-web:9000/tenant/openstack/status or whatever the actual url is | 23:12 |
| SpamapS | Yeah I just reworked my stuff to do that | 23:17 |
| SpamapS | ah.. my nodes aren't reachable | 23:18 |
| SpamapS | which I can see now that I have log streaming :) | 23:18 |
| SpamapS | oh that's something else | 23:19 |
| SpamapS | NODE_FAILURE ;) | 23:20 |
| jeblair | mordred: can you +3 https://review.openstack.org/505846 now? | 23:20 |
| mordred | jeblair: yes | 23:22 |
| mordred | jeblair: it says cannot merge | 23:22 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Remove Job.nodes https://review.openstack.org/505846 | 23:22 |
| mordred | meh - I think gerrit was just confused | 23:22 |
| mordred | jeblair: done | 23:23 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Report friendly errors when nodeset/secrets missing https://review.openstack.org/505856 | 23:23 |
| mordred | rebased and re-+3'd that one too | 23:23 |
| SpamapS | aaaaand I've made the 2nd most deadly mistake in zuul (the first is never get involved in a flame war with mordred), but the _SECOND_, is never go in with TWO nodepools on ONE project. | 23:24 |
| SpamapS | We may want to make some kind of meta UUID per nodepool for situations like these | 23:25 |
| SpamapS | so they don't fight | 23:25 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Correctly apply irrelevant-files to simple job names https://review.openstack.org/506415 | 23:27 |
| jlk | SpamapS: didn't you make that mistake once before, in Bonny? | 23:30 |
| mordred | SpamapS: well - I thought we added some kind of meta UUID per nodepool | 23:32 |
| mordred | SpamapS: but I could be wrong | 23:33 |
| * jlk gone for the day | 23:34 | |
| SpamapS | jlk: jamielennox did ;) | 23:38 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Correctly apply irrelevant-files to simple job names https://review.openstack.org/506415 | 23:38 |
| SpamapS | mordred: doesn't seem so. The two were fighting, deleting eachothers' instances. | 23:38 |
| SpamapS | and images | 23:38 |
| SpamapS | which is why I'm node failing now, because I have no images | 23:38 |
| * SpamapS waits patiently for images | 23:38 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove Job.nodes https://review.openstack.org/505846 | 23:45 |
| Shrews | SpamapS: i *think* there's protection mechanisms in nodepool for that? i implemented your uuid idea, and i thought we stored that in the node metadata | 23:48 |
| SpamapS | hm... dib problems | 23:48 |
| SpamapS | Shrews: Ah, could have been something else then | 23:48 |
| SpamapS | Shrews: maybe I have to set some config option right to use that. | 23:48 |
| SpamapS | Does anyone know if maybe dib doesn't work with python3.5? | 23:49 |
| SpamapS | http://paste.openstack.org/show/621667/ | 23:50 |
| Shrews | SpamapS: oh, this is the thing i was thinking of: http://git.openstack.org/cgit/openstack-infra/nodepool/tree/doc/source/configuration.rst?h=feature/zuulv3#n19 | 23:50 |
| Shrews | for the builders | 23:51 |
| SpamapS | Shrews: right, I had separate ZK's | 23:51 |
| SpamapS | spun up two allinones | 23:51 |
| SpamapS | but sharing the same openstack creds | 23:51 |
| Shrews | oh | 23:51 |
| SpamapS | we could put that UUID on the instances as metadata | 23:52 |
| SpamapS | could have the same effect | 23:52 |
| SpamapS | and images actually | 23:52 |
| pabelanger | SpamapS: http://git.openstack.org/cgit/openstack-infra/nodepool/tree/doc/source/configuration.rst?h=feature/zuulv3#n319 should help with multiple nodepools. That's what we do with nodepool.o.o and nl01.o.o / nl02.o.o | 23:52 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Report friendly errors when nodeset/secrets missing https://review.openstack.org/505856 | 23:53 |
| SpamapS | Default None | 23:53 |
| SpamapS | should be Default {uuid} maybe? ;) | 23:54 |
| Shrews | pabelanger: ah yes, that was the other thing. i was mixing up the two things | 23:54 |
| SpamapS | anyway, now dib is t3h borked | 23:54 |
| SpamapS | :-/ | 23:54 |
| pabelanger | Oh, yes. ubuntu-xenial DIBs are also broken | 23:54 |
| pabelanger | next dib will fix that too | 23:55 |
| SpamapS | how does that slip through?? | 23:55 |
| pabelanger | well, upstream broke it :) | 23:55 |
| pabelanger | let me find bug | 23:55 |
| pabelanger | https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1700972 | 23:56 |
| openstack | Launchpad bug 1700972 in linux-azure (Ubuntu Xenial) "Please only recommend or suggest initramfs-tools | linux-initramfs-tool for kernels able to boot without initramfs" [Low,Fix committed] - Assigned to Marcelo Cerri (mhcerri) | 23:56 |
| pabelanger | sadly, I have to run now. | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!