| openstackgerrit | James E. Blair proposed openstack-infra/nodepool: Add files for zuul-nodepool integration test https://review.openstack.org/422284 | 00:07 |
|---|---|---|
| openstackgerrit | Merged openstack-infra/nodepool: Move to fedora-25 for devstack testing https://review.openstack.org/420197 | 00:19 |
| *** jamielennox is now known as jamielennox|away | 01:02 | |
| *** saneax is now known as saneax-_-|AFK | 01:06 | |
| *** jamielennox|away is now known as jamielennox | 01:17 | |
| *** harlowja has quit IRC | 02:44 | |
| *** harlowja has joined #zuul | 06:34 | |
| *** abregman has joined #zuul | 07:04 | |
| *** harlowja has quit IRC | 07:26 | |
| *** openstackgerrit has quit IRC | 08:03 | |
| *** saneax-_-|AFK is now known as saneax | 08:16 | |
| *** hashar has joined #zuul | 08:23 | |
| *** abregman has quit IRC | 08:27 | |
| *** abregman has joined #zuul | 08:34 | |
| jkt | hi there, I'm happy to see the progress on v3 | 09:53 |
| jkt | I've been running a setup with turbo-hipster at KDE for a few years, and now I'm about to build some CI at another workplace and I wonder about what tool to use | 09:54 |
| jkt | I've read through various mailing list posts and presentations, and it seems that v2.5 already uses Ansible in place of TH, which is nice, I guess | 09:55 |
| jkt | if I'm starting now, and if I don't mind about stability etc that much right now, should I give this "OpenStack infra only on purpose" thing a try, or should I just use the old zuul with TH? | 09:56 |
| * jkt waits for the west coast to wake up | 09:56 | |
| *** abregman has quit IRC | 11:29 | |
| *** abregman has joined #zuul | 11:35 | |
| *** abregman is now known as abregman|mtg | 12:18 | |
| *** abregman|mtg has quit IRC | 12:18 | |
| *** saneax is now known as saneax-_-|AFK | 12:22 | |
| Shrews | jkt: well, the general answer has been "you probably shouldn't use it b/c 2.5 is temporary, there's no documentation, no real support, and there's no migration path to v3". but that being said, it is open source and you can do whatever you want :) | 12:53 |
| Shrews | but v3 is getting really close (still no set timeframe) | 12:53 |
| *** isaacb has joined #zuul | 13:00 | |
| *** isaacb_ has joined #zuul | 13:00 | |
| *** isaacb has quit IRC | 13:06 | |
| jkt | Shrews: thanks; I'm mostly OK with redoing some plumbing in a few weeks/months | 13:17 |
| jkt | and anyway, I think I'll be fine with a static set of hosts for now as well, so TH and an old Zuul it is | 13:17 |
| *** abregman has joined #zuul | 13:45 | |
| *** isaacb_ has quit IRC | 13:50 | |
| *** saneax-_-|AFK is now known as saneax | 13:52 | |
| *** isaacb_ has joined #zuul | 13:59 | |
| *** isaacb_ has quit IRC | 14:42 | |
| *** abregman is now known as abregman|afk | 15:30 | |
| jeblair | jkt: hi! it sounds like you're probably familiar enough with it that you probably won't dig yourself into a hole. there's just a couple of things to be aware of: | 15:51 |
| jeblair | jkt: unlike TH, the zuul ansible launch server in v2.5 behaves like jenkins -- the launch server acts like a jenkins master, so it doesn't run on the worker nodes themselves. nodepool assigns nodes to it, it ssh's into the nodes to run jobs, then nodepool deletes the nodes when complete. | 15:54 |
| jeblair | jkt: the jobs are written in a subset of jjb (basically just 'shell' builder), which the launcher automatically translates into ansible. we're not going to support more of jjb because this component is temporary -- we wrote just enough to make openstack work. | 15:55 |
| jeblair | jkt: and finally, v2.5 should still work fine with turbo hipster, so if you wanted to start out with that, that should continue to work until v3. | 15:55 |
| jkt | jeblair: thanks | 16:02 |
| *** abregman|afk has quit IRC | 16:09 | |
| *** saneax is now known as saneax-_-|AFK | 16:46 | |
| *** saneax-_-|AFK is now known as saneax | 16:47 | |
| *** dmsimard is now known as dmsimard|off | 16:48 | |
| *** hashar is now known as hasharAway | 17:01 | |
| *** yolanda has quit IRC | 17:19 | |
| *** yolanda has joined #zuul | 17:22 | |
| *** openstackgerrit has joined #zuul | 17:27 | |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: WIP: Assign node set to node requests https://review.openstack.org/423502 | 17:27 |
| *** saneax is now known as saneax-_-|AFK | 17:28 | |
| *** hashar has joined #zuul | 17:37 | |
| *** hashar has quit IRC | 17:38 | |
| openstackgerrit | James E. Blair proposed openstack-infra/nodepool: Add files for zuul-nodepool integration test https://review.openstack.org/422284 | 17:46 |
| jeblair | clarkb: for the nodepool integration test, what i want to do is write a zuul unit test that uses the real nodepool. this way, we benefit from all the zuul fakes, but are able to test the zuul<->nodepool interaction. but of course, i don't want this to run during the normal py27 job. | 17:50 |
| jeblair | clarkb: how should i accomplish that... a skip based on an env variable? or update tox.ini to tell testr to exclude a test class? or some other idea? | 17:50 |
| jeblair | Shrews: ^ | 17:50 |
| jeblair | if there's a tox.ini way to do it, that sounds like the right approach to me... | 17:51 |
| clarkb | jeblair: nova has a nova/tests/unit and nova/tests/functioanl | 17:52 |
| jeblair | yeah, it's probably similar to that pattern | 17:52 |
| clarkb | jeblair: then regular py27 job runs everything under unit/ and the functional job runs the tests under functional/ I kinda like that separate as it makes it clear what is what | 17:52 |
| clarkb | I'd have to look up what the specific selection mechanism is though | 17:53 |
| Shrews | similarly, shade has unit/functional/ansible | 17:53 |
| jeblair | OS_TEST_PATH = ./shade/tests/functional | 17:54 |
| jeblair | and then in .testr.conf: subunit.run discover -t ./ ${OS_TEST_PATH:-./shade/tests/unit} | 17:54 |
| jeblair | clarkb, Shrews: same mechanism in nova | 17:55 |
| jeblair | so i guess i'll shift everything down a directory and branch :) | 17:55 |
| jeblair | thanks! | 17:55 |
| *** hasharAway has quit IRC | 18:05 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul: Add nodepool integration test script https://review.openstack.org/422288 | 18:19 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul: Move tests into test/unit https://review.openstack.org/424787 | 18:19 |
| jeblair | clarkb, Shrews: ^ | 18:19 |
| Shrews | everyone working on tests is going to conflict with that :) | 18:21 |
| clarkb | sometimes C git can figure moves like that out iirc. But ya jgit not so much | 18:21 |
| jeblair | yep. :| | 18:21 |
| clarkb | I need caffeine will review after i have that | 18:22 |
| Shrews | jeblair: you don't have to change anything in tox.ini? | 18:22 |
| Shrews | oh, i guess not until you add the new dirs | 18:23 |
| jeblair | Shrews: not yet, since that's the default. i'll need to add something for the nodepool test | 18:23 |
| Shrews | right | 18:23 |
| clarkb | thinking about C git and how zuul may eventually do merges for us, does gerrit properly close out reviews when they are pushed by another entity into gerrit target branch? does it clean up the merge failure detection on its side? | 18:35 |
| clarkb | probably things that we want to test on review-dev | 18:35 |
| jeblair | clarkb: yes, i previously tested those things, aside from merge failure detection cleanup (which didn't exist yet). | 18:35 |
| clarkb | jeblair: mostly worried if something is in a cannot merge state and then it gets merged by external entity that may trip up Gerrit | 18:36 |
| jeblair | yeah, that's worth seeing what happens. but you'd probably be pushing a new patchset in that case (not a fast-forward), so i assume it would recalculate. | 18:37 |
| jlk | oh? Theres talk of having zuul directly merge, instead of asking gerrit to do it? | 18:38 |
| clarkb | I thought it would be a merge commit + old existing patchset | 18:38 |
| jlk | (well, gerrit or some other connection) | 18:38 |
| clarkb | jlk: there has been talk of it for a long time due to jgits behavior, its just never been a high priority because jgit works most of the time | 18:39 |
| jlk | jgit is what gerrit uses? | 18:39 |
| clarkb | yup | 18:39 |
| jlk | ah, so this is being approached as a possible workaround/solution to a gerrit problem? | 18:40 |
| jlk | not necessarily a design model that other connections should follow? | 18:40 |
| clarkb | yes, though I imagine if gerrit did it we would try to switch other systems to it to for consistency | 18:40 |
| jlk | fair enough. | 18:41 |
| jeblair | two reasons: 1) jgit is not as good as cgit in performing merges. 2) this would be required for bi-directional cross-repo dependency | 18:41 |
| jlk | I _think_ it kind of works okay with github, but it requires a different set of rights to directly push instead of using the API to request a merge. | 18:41 |
| jeblair | (in that case, zuul wants to control the two-phase commit process) | 18:41 |
| clarkb | jlk: same situation with gerrit | 18:41 |
| jlk | also I think it would require reproducing all the github branch protection things downstream which would be annoying. | 18:42 |
| clarkb | jlk: current setup is request merge via the submit api, pushing code requires (force) push access | 18:42 |
| clarkb | jlk: branch protection things? | 18:42 |
| jlk | Yeah, github allows you to create branch protections for specific branches in a repo | 18:42 |
| Shrews | jeblair: So, in studying the current use of ProviderManager in nodepoold, I'm a bit perplexed how it doesn't cause problems when a provider definition is changed, and the manager is changed/stopped out from underneath other threads using it. | 18:42 |
| clarkb | right what does that mean? | 18:42 |
| jlk | where merging is blocked until PR Reviews are in place, specific status checks on PR HEAD are in place, or even specific users doing the merge | 18:43 |
| jlk | clarkb: the web UI prevents merging until the "protection" barriers are met | 18:43 |
| clarkb | jlk: thats basically what zuul does | 18:43 |
| clarkb | and gerrit does too | 18:43 |
| jlk | (and presumably you aren't allowed to push directly either) | 18:43 |
| jlk | yeah, but end users control github protections | 18:43 |
| jeblair | yeah, those should all be do-able in zuul | 18:43 |
| jlk | whereas they don't have direct control over zuul/gerrit | 18:44 |
| clarkb | ya zuul had support for that before github did I think | 18:44 |
| jlk | indeed | 18:44 |
| jeblair | zuul needs to support all of that anyway, regardless of whether it pushes | 18:44 |
| jlk | Totally can be done in zuul, but what I worry about is github endusers modifying protections behind zuul's back, and then there is a mismatch | 18:44 |
| jeblair | Shrews: the existing threads maintain a reference to the old provider manager. if they then attempt to use it after it has stopped, it may throw an error. that may send the node into 'deleting' state. a delete thread will pick that up and start cleaning it up (with a new provider manager). | 18:46 |
| clarkb | jlk: but that is the case regardless right? | 18:46 |
| jeblair | Shrews: short version: it *does* cause problems, but nodepool expects *everything* to cause a problem (hi openstack!) so it's no big deal. :) | 18:46 |
| Shrews | jeblair: oh, so we don't try to avoid the errors, but expect proper cleanup | 18:46 |
| jeblair | Shrews: yep. | 18:47 |
| clarkb | yes lots of cleanup | 18:47 |
| jeblair | we're really good at that now. | 18:47 |
| jlk | clarkb: yeah, I think so? I can't put my finger on it, but trying to push directly to github instead of using the API just feels weird to me. I'd have to play with it to get a better feeling on what all it changes. | 18:48 |
| Shrews | jeblair: ok. i think i still may need to make changes to ProviderManager. I don't want it to manage EVERY provider listed, but only a single provider. | 18:51 |
| Shrews | otherwise, each ProviderWorker thread will have threads for all providers rather than just the one | 18:52 |
| jeblair | Shrews: that's kind of a strange class. an actual *instance* of providermanager only deals with a single provider. however, that class has two static methods which operate on all provider managers -- creating and stopping the real per-provider instances as needed. | 18:54 |
| jeblair | Shrews: if you wanted to pull those static methods out to be more clear about what they are doing, i would be on board with that. :) | 18:55 |
| jhesketh | Morning | 18:58 |
| *** hashar has joined #zuul | 18:58 | |
| openstackgerrit | Jan Kundrát proposed openstack-infra/zuul: Fix passing labels to Gerrit when they are not defined in All-Projects https://review.openstack.org/424806 | 19:19 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: Manage providers in ProviderWorker threads https://review.openstack.org/424808 | 19:24 |
| jkt | is it always required to list a project explicitly within the projects: stanza? | 19:26 |
| jkt | in other words, can I somehow get by without revealing an existence of a given project in my layout.yaml and still have that project covered by some default set of jobs? | 19:26 |
| *** harlowja has joined #zuul | 19:41 | |
| Shrews | jeblair: for https://review.openstack.org/424808, it seems we have some shade integration tests poking into nodepool private structures (the config provider managers) and now failing with my change: http://logs.openstack.org/08/424808/1/check/gate-nodepool-python27-ubuntu-xenial/bcc81c9/testr_results.html.gz | 20:15 |
| Shrews | jeblair: not entirely sure what we should do with those | 20:15 |
| jeblair | Shrews: maybe change that to nodepool._provider_threads['real-provider'].manager ? | 20:20 |
| Shrews | jeblair: i guess we could extend the poking down to the threads, but these tests really just seem to be testing ProviderManager. maybe i can refactor the nodepool stuff out | 20:22 |
| jeblair | Shrews: alternatively, change those tests ... | 20:22 |
| jeblair | Shrews: yes, i was just writing that :) | 20:23 |
| jeblair | ++ | 20:23 |
| Shrews | jeblair: fixed 2 of the 3. the test_nodepool_osc_config_reload test is an odd one in that it really just seems to test that the config is actually reloaded. Not sure that test is really necessary, but... what do you think? | 20:41 |
| Shrews | oy, this one is a PITA | 20:56 |
| jeblair | Shrews: yah, i'm going to say that one is of dubious value | 20:58 |
| Shrews | i mean, i tried passing the buck down to the threads, but it requires actually starting nodepool (it currently does not) which makes it bomb out on the clouds.yaml | 20:59 |
| jeblair | if you wanted to skip that one for now, i would not be opposed | 21:00 |
| jeblair | then later we can see if anything else covers it, and if so, drop it. or if not, figure out a better way of testing whatever it uniquely tests. | 21:00 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: Manage providers in ProviderWorker threads https://review.openstack.org/424808 | 21:01 |
| Shrews | oh, i deleted it. i can add it back and @skip it. 1 sec | 21:01 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: Manage providers in ProviderWorker threads https://review.openstack.org/424808 | 21:03 |
| jeblair | it looks like the latest version of the integration test patch has both the builder and launcher running: http://logs.openstack.org/88/422288/7/experimental/gate-zuul-nodepool/bf5ca54/console.html | 21:11 |
| clarkb | jeblair: does that mean the scripts are ready for review? or do you want to keep iterating on that? | 21:12 |
| jeblair | clarkb: i think ready -- i will continue work (running zuul tests and collecting logs, etc) in further patches now. | 21:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul: Add nodepool integration test https://review.openstack.org/424859 | 21:39 |
| clarkb | jeblair: is there a navigation map for reviewing the integration test stuff? | 21:45 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul: Rename nodepool integration script https://review.openstack.org/424863 | 21:46 |
| jeblair | clarkb: let me make one | 21:46 |
| clarkb | tyty | 21:47 |
| jeblair | clarkb: "topic:nodepool-integration" | 21:49 |
| jeblair | clarkb: but also, there should be links backwards from the end: 424863 (either depends-on or git commits) | 21:49 |
| jeblair | clarkb: i'm going to update 424863 | 21:51 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul: Rename nodepool integration script https://review.openstack.org/424863 | 21:51 |
| jeblair | clarkb: ^ | 21:51 |
| jeblair | clarkb, Shrews: i think all of that is ready to go, and if we land it, we should see it sucessfully fail! :) | 21:52 |
| clarkb | the best kind of failure | 21:52 |
| openstackgerrit | Adam Gandelman proposed openstack-infra/zuul: Move and re-enable test_build_configuration_branch tests https://review.openstack.org/409376 | 22:42 |
| *** hashar has quit IRC | 22:51 | |
| clarkb | jeblair: please see comments on https://review.openstack.org/#/c/424859/1 | 22:59 |
| *** harlowja has quit IRC | 23:08 | |
| *** SpamapS has quit IRC | 23:27 | |
| jeblair | clarkb: replied! | 23:31 |
| *** SpamapS has joined #zuul | 23:31 | |
| jeblair | okay, i've approved all of those except the last one | 23:32 |
| jeblair | i'll keep that around for testing after the others land | 23:33 |
| jeblair | adam_g, SpamapS: you may want to rebase your test fixes on https://review.openstack.org/424787 | 23:33 |
| clarkb | thanks | 23:33 |
| openstackgerrit | Merged openstack-infra/nodepool: Add files for zuul-nodepool integration test https://review.openstack.org/422284 | 23:36 |
| openstackgerrit | Merged openstack-infra/zuul: Add nodepool integration test script https://review.openstack.org/422288 | 23:51 |
| openstackgerrit | Merged openstack-infra/zuul: Move tests into test/unit https://review.openstack.org/424787 | 23:52 |
| openstackgerrit | Merged openstack-infra/zuul: Add nodepool integration test https://review.openstack.org/424859 | 23:52 |
| *** harlowja has joined #zuul | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!