Thursday, 2018-08-30

*** efried1 has joined #openstack-placement00:50
*** efried has quit IRC00:51
*** efried1 is now known as efried00:51
openstackgerritMerged openstack/nova master: [placement] Make _ensure_aggregate context not independent  https://review.openstack.org/59748600:52
*** efried has quit IRC00:58
openstackgerritMerged openstack/nova master: Add explanatory prefix to post_test_perf output  https://review.openstack.org/59185001:05
openstackgerritMerged openstack/nova master: Add trait query to placement perf check  https://review.openstack.org/59262401:12
openstackgerritMerged openstack/nova master: Restart scheduler in TestNovaManagePlacementHealAllocations  https://review.openstack.org/59757101:12
openstackgerritMerged openstack/nova master: reshaper: Look up provider if not in inventories  https://review.openstack.org/58503301:12
*** alex_xu has joined #openstack-placement01:19
*** efried has joined #openstack-placement01:20
openstackgerritMerged openstack/nova master: Make get_allocations_for_resource_provider raise  https://review.openstack.org/58459803:28
openstackgerritMerged openstack/nova master: api-ref: fix volume attachment update policy note  https://review.openstack.org/59648903:28
*** nicolasbock has quit IRC03:40
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix a failure to format config sample  https://review.openstack.org/59798605:08
openstackgerritTakashi NATSUME proposed openstack/nova stable/rocky: Fix a broken conf file description in networking doc  https://review.openstack.org/59798705:20
*** e0ne has joined #openstack-placement05:31
*** tetsuro has joined #openstack-placement05:53
*** openstackgerrit has quit IRC06:07
*** e0ne has quit IRC06:19
*** e0ne has joined #openstack-placement06:20
*** e0ne has quit IRC06:20
*** openstackgerrit has joined #openstack-placement06:21
openstackgerrithuanhongda proposed openstack/nova master: [WIP]Forbidden non-admin user to list deleted instances  https://review.openstack.org/59801206:21
*** tetsuro has quit IRC07:02
*** tetsuro has joined #openstack-placement07:06
openstackgerritMerged openstack/nova stable/rocky: Fix a broken conf file description in networking doc  https://review.openstack.org/59798707:56
*** cdent has joined #openstack-placement07:59
*** tetsuro has quit IRC08:20
*** tetsuro has joined #openstack-placement08:22
openstackgerrithuanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state  https://review.openstack.org/59808408:24
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808808:42
*** ttsiouts has joined #openstack-placement08:43
*** e0ne has joined #openstack-placement08:48
*** takashin has quit IRC09:09
openstackgerrithuanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state  https://review.openstack.org/59808409:15
*** tetsuro has quit IRC09:23
*** takashin has joined #openstack-placement09:34
*** takashin has left #openstack-placement09:34
*** cdent has quit IRC10:02
*** deepak_mourya_ has joined #openstack-placement10:11
*** nicolasbock has joined #openstack-placement10:47
*** ttsiouts has quit IRC10:56
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808811:00
*** cdent has joined #openstack-placement11:15
openstackgerritMerged openstack/nova master: Report client: Real get_allocs_for_consumer  https://review.openstack.org/58459911:17
*** cdent has quit IRC11:23
*** tetsuro has joined #openstack-placement11:27
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808811:36
*** tetsuro has quit IRC11:38
*** ttsiouts has joined #openstack-placement11:43
*** cdent has joined #openstack-placement11:49
*** tetsuro has joined #openstack-placement12:03
*** tetsuro has quit IRC12:07
*** tetsuro has joined #openstack-placement12:08
openstackgerritJay Pipes proposed openstack/os-traits master: clean up CUDA traits  https://review.openstack.org/59717012:41
*** mriedem has joined #openstack-placement12:54
openstackgerritMatt Riedemann proposed openstack/nova stable/rocky: Restart scheduler in TestNovaManagePlacementHealAllocations  https://review.openstack.org/59815212:59
*** tssurya has joined #openstack-placement13:01
openstackgerritChen proposed openstack/nova master: Fix filter server list by multiple vm or task states  https://review.openstack.org/59815413:09
cdentgibi: just wanted to say: still chewing on your request groups in ac stuff13:10
gibicdent: no worries, I tried to publish it before the PTG so that we can have a meaningful discussion in Denver13:13
cdentgibi: my most stable thought so far is: _if_ we do this, don't put the info in the allocation_requests, as you already mention in the alternatives13:15
gibicdent: yeah I pretty back and forth about where to put the key for me both direction seems viable. So I guess I will adapt to the majority opinion.13:19
gibicdent: I feel that '_if_13:19
cdent:)13:19
gibicdent: I feel that '_if_' question will be a bigger debate13:19
gibibtw looking at the a_c code in placement I see itertool.product calls (twice) which suggest to me that the placemetn a_c call also scales pretty bad for a more than one groups and viable RP pairs13:20
gibibut in placement we have a change to limit the size of those products with the limit query paramter13:21
openstackgerritRadoslav Gerganov proposed openstack/nova-specs master: VMware: add support for live migration  https://review.openstack.org/59816313:23
openstackgerritTakashi NATSUME proposed openstack/nova master: Transform compute_task notifications  https://review.openstack.org/48262913:45
openstackgerritMerged openstack/nova master: (Re)start caching scheduler after starting computes in tests  https://review.openstack.org/59760613:47
alex_xujaypipes: efried cdent, is it terrible if I create resource provider for each assignable device?13:52
cdentalex_xu: I need a bit more context. Which devices are you talking about?13:53
jaypipesgibi: I am also still chewing on your spec. review should be done in an hour or two.13:54
alex_xucdent: like the #1 case in https://etherpad.openstack.org/p/nova_nvdimm13:54
gibijaypipes: thanks for your time13:55
jaypipesgibi: nem probléma13:58
gibijaypipes: :)13:59
*** tetsuro has quit IRC14:00
cdentalex_xu: how you choose to represent physical inventory to placement is really up to you, but it is important that you don't misrepresent the total amount of stuff. So your option #1 is better than #2 because the overall total of available VNVDIMM_GB is more accurate. However it seems to make landing a workload more complicated.14:02
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756014:03
alex_xucdent: it sounds depends on we decide which is resource provider. For #1, the RP is each namespace in a nvdimm device. For #2, the RP is nvdimm device.14:06
alex_xucdent: I think I see why #2 is starnge, #2 is trying to say the nvdimm device provides namespaces, but actually it provides VNVDIMM_GB.14:07
alex_xucdent: why landing a workload is more complicated?14:12
cdentIn #1 there are two different rp identifiers for the same nvimm, which means some kind of mapping needs to be maintained14:13
alex_xuah, you are right, probably a dict to mapping the device and uuid.14:14
alex_xuor put the device identifiers to the RP name14:14
cdentwhich is fine, but... I'm not sure of the right word: messy? hacky?14:15
alex_xutry to think about how can we map rp with numa node, rp with sriov pf14:17
openstackgerritMatt Riedemann proposed openstack/nova master: Revert "Update resources once in update_available_resource"  https://review.openstack.org/59817614:19
alex_xucdent: no idea :)14:20
cdent:)14:20
gibialex_xu: network device (like sriov PF) mapped to RP in neutron. One PF is one RP with a VF inventory14:23
gibialex_xu: the uuid of the RP is generated from with uuid5(hostname,pf-device-name)14:24
alex_xugibi: ah14:24
efriedalex_xu: Representing each device as a single inventory unit in a single provider - this is how we plan to do it for powervm.14:25
gibialex_xu: I lied there is no VF inventory just bandwidth inventory at the momement on a PF RP14:25
alex_xuefried: cool, sounds like I didn't do a wrong thing, what kind of device in the powervm?14:26
efriedalex_xu: Well, just because we're doing it in powervm doesn't mean it won't be considered "wrong" :)14:26
alex_xugibi: but I see the idea :)14:26
efriedalex_xu: At the moment we're focusing on passing through entire devices.14:26
efriedalex_xu: https://review.openstack.org/#/c/579359/14:27
alex_xuefried: hah, if you see #2 in https://etherpad.openstack.org/p/nova_nvdimm, I found I can't figure the user want to multiple device even with granular request14:27
efriedalex_xu: At some point we'll deal with devices with multiple physical ports (PFs) in which case each PF will be represented by a separate provider.14:27
efriedalex_xu: And at some point after that we'll deal with the fact that a PF can provide multiple VFs (e.g. VGPUs or SR-IOV VFs) and in that case those will be (multiple) inventory units on the same PF RP14:28
gibialex_xu, efried: the power plan seems to be consistent with the current neutron / bandwidth modelling14:29
alex_xuefried: indeed, for the PF case, yes, each PF should be a RP14:29
efriedgibi: I'm going to need to catch up on the neutron/bandwidth specs...14:29
gibiefried: we will show a demo in Denver where actual RP trees will show in devstack (and even booting VMs allocating against those trees)14:30
efriedyes, I'm looking forward to seeing that.14:30
alex_xuI'm doing that is just because the device has fragmental issue, let the operator configure the device first to plan the resource better.14:31
efriedalex_xu: I don't understand what's going on at L75-79 in that etherpad.14:32
efriedIf you're using group_policy=none, you should be getting a match from CN114:32
alex_xuefried: in the end, we merge the resources1 and resource2, then we found 2+2 > CN1's max_size14:33
efriedalex_xu: Then that's a placement bug.14:33
efriedoh14:34
alex_xuefried: it is already wellknown bug?14:34
efriedno, sorry, hold on.14:34
efriedThis is related to what gibi is getting at with https://review.openstack.org/#/c/597601/14:35
alex_xuat least our response in the API only can have one entry for same resource class in same RP14:35
efriedyeah14:35
efriedso fixing this is going to entail a complete rework of some payload formats.14:35
alex_xuhave to say gibi got a lot of interesting spec from bandwidth case :)14:36
gibiI guess I got them first because bandwidth was the first user of nested RP and granular group14:36
alex_xuhah14:36
efriedalex_xu: I haven't read the whole etherpad (or any other background) but have you considered simply using multiple separate allocation requests?14:37
alex_xuefried: what you mean multiple separate allocation request?14:37
alex_xuany example14:38
efriedum, yeah, sorry, that doesn't work either. Would have to be two separate consumers.14:38
efriedWe just don't have a way to represent this.14:38
alex_xuyea14:39
efriedAnd it's not just about GET /allocation_candidates. Even if you managed to get a candidate somewhow with both of your disks in it, it would bounce as soon as you tried to PUT the /allocations/{c}14:39
alex_xuand you have no way to ensure they are one same comput enode14:40
alex_xuanyway, if the #1 workable, I think it is better.14:41
alex_xuat least the user can create any size device14:41
alex_xuefried: cdent gibi, thank you guys for your time14:43
gibialex_xu: np14:44
cdentalex_xu: thanks for pushing the boundaries14:44
*** lei-zh has joined #openstack-placement14:46
*** ttsiouts has quit IRC14:55
edleafeefried: jaypipes: Are there any active placement patches that you feel must be merged before we can freeze the nova placement code? The extraction process is working well enough to move forward.14:58
jaypipesedleafe: all of the reshaper series.14:59
edleafejaypipes: I thought all of the placement side of it merged already15:00
edleafeOh, I see Eric's patch that just removes some comments only has 1 +215:01
*** ttsiouts has joined #openstack-placement15:01
edleafeEverything else in the bp/reshape-provider-tree series is for compute15:02
openstackgerritMerged openstack/nova master: Fix soft deleting vm fails after "nova resize" vm  https://review.openstack.org/54692015:03
*** e0ne has quit IRC15:27
efriededleafe: I don't think there's anything crucial pending, no.15:39
edleafeefried: Thanks. It looked that way to me, but wanted to double-check15:40
efriededleafe: In fact, I wouldn't be averse to abandoning https://review.openstack.org/#/c/597220/ in nova and reproposing it in placement.15:40
cdentefried, edleafe, jaypipes: should we decide on a stategy for holding things so we don't have stuff that accidentally lands in nova before placement is visible and ready?15:41
edleafeefried: Sure, but I'd rather it get a second +2 and merge :)15:41
efriedcdent: we can -2 stuff as we find it I suppose.15:41
efriedIf you see it before I do, bring it to my attention.15:41
efriedAnd let everyone know that's what's going on.15:41
cdentjaypipes or gibi: you happy to kick https://review.openstack.org/#/c/597220/ in?15:42
gibicdent: looking15:42
efriedI wouldn't expect placement stuff to merge without a select handful of cores at least seeing it and knowing it exists; so as long as gibi, jaypipes, mriedem and I are aware of the strategy, it shouldn't be hard to keep stuff out.15:42
gibicdent: +A15:43
cdentyay!15:43
gibiefried: a clear mail on the ML about the freeze and then I think we are safe15:43
edleafeNice!15:43
efriedCool, now we just need three days to get it merged.15:43
efriedgate has been brutal to the reshaper series.15:44
edleafeAs soon as that merges, I'll start a new extraction run15:44
gibiefried: it is test only so gate will be gentle, a hope15:44
efriedThe phrase "morning rechecks + coffee" has come to mind.15:44
openstackgerritMerged openstack/nova-specs master: VMware: add support for live migration  https://review.openstack.org/59816315:50
efriededleafe: There's also https://review.openstack.org/#/c/597291/ <== mriedem gibi jaypipes can we get this merged quickly or freeze it for the placement extract?15:55
mriedemi guess that was prompted by my huh15:56
mriedem*me15:56
efriedyup15:57
efriedsee link in commit message15:57
edleafeefried: sure, but that is pretty trivial, and could be easily applied post-extraction15:57
efriedyes, sure, swhy I'm asking.15:57
edleafeand it's not part of reshaper15:57
efried(the comment removal could have also been applied post-extraction)15:58
edleafeefried: yeah, but that already had a +2 :)16:01
efriededleafe: Okay, jaypipes doesn't like that patch, so I'm going to -2 it for now.  (<== mriedem FYI)16:01
efriededleafe: other one has a +2 now as well. But also a -1. So ^16:01
efriededleafe, cdent: one of y'all already working on the freeze email?16:03
cdentefried: I had not started for two reasons: 1) in the api-sig meeting, 2) not a nova core16:03
edleafeefried: we're in the API-SIG meeting now. Feel free to write one16:04
cdentso if you've got the cycles I say go for it16:04
efriedcdent, edleafe: ack, doing it.16:04
edleafethx16:04
melwittso what's the plan? freeze now and then propose the gerrit changes immediately after?16:12
efriedmelwitt: I'm glad you asked. I'm writing something up, and will pastebin it for y'all's perusal before I send it.16:13
melwittok16:13
efriedmelwitt, cdent, edleafe, mriedem, jaypipes: 1st pass: http://paste.openstack.org/raw/729164/16:16
mriedemnothing refers to [1]16:17
edleafeefried: Looks good, except for the "Howdy y'all" :)16:17
efriedperhaps s/extraction is complete/repository is seeded/ ?16:17
* edleafe still can't stand that even after 10 years in Texas16:17
efriedmriedem: Whoops, yeah, I was going to say "we'll start once [1] is merged".16:17
mriedemlisten y'all, -1 on this paste y'all16:17
edleafeefried: No, I think complete is best16:17
edleafeOnce seeded, we will have several patches to get tests passing16:18
efriedright, so should we maybe define "complete"?16:18
edleafe...instead of seeding with the finished product as originally planned16:18
efriedI.e. does that mean you should wait until all those patches merge before proposing?16:18
edleafeproposing... what?16:19
melwittwill this email explain how the seeding will be done? there's a openstack procedure for doing that through gerrit, is that right mriedem?16:19
cdentefried: yes, because that stack will have path changes etc16:19
efriedcdent: okay, swhat I figgered.16:19
edleafemelwitt: I don't think that's necessary. The intent is to let people know about the freeze16:19
efriedmelwitt: I figured that was out of scope for this, and covered in the other thread - the one with (technical) in the subject.16:19
cdentmelwitt: you seen my 1.x.x.x list? with links to the infra doc on the seeding topic?16:19
melwittmostly, I just want to know is everything already ready to go, we freeze when we are going to start moving things16:20
mriedemi assume she means the actual infra setup16:20
mriedemhttps://docs.openstack.org/project-team-guide/ ?16:20
edleafemelwitt: we need to freeze before the history filter script is applied16:20
mriedemoh this https://docs.openstack.org/infra/manual/creators.html16:20
melwittlike, when this freeze is started, how long before we see the changes in gerrit that we can start reviewing16:20
cdentmriedem: yeah, that, linked from my email16:20
melwittok16:20
cdentmatter of days, depending on how long it takes infra to react to the seeding request16:21
edleafethe freeze is just on new placement work. The patches in the new repo will be reviewable right away16:21
melwittare the steps from the email the usual way to seed a repo? it says to the initial code will be in ed's repo, then after that, the infra steps will be followed16:28
mriedemi believe that's normal,16:28
melwittwill that result in gerrit changes for review or?16:28
mriedemroman had osc-placement in his github i think16:28
mriedeminfra has to seed from something for the initial clone i think16:28
efriedmelwitt, edleafe, cdent, mriedem, jaypipes: v2: http://paste.openstack.org/raw/729165/16:28
mriedemhttps://review.openstack.org/#/c/448115/16:29
mriedem^ is the osc-placement seed patch16:29
mriedemupstream: https://github.com/malor/osc-placement.git16:30
cdentwfm efried16:30
edleafeefried: ship it16:30
mriedemefried: "the fix should must proposed t"16:31
efriedthx16:31
mriedemi assume you don't want that hanging over your head for all time16:31
efriedyou got that right.16:31
mriedemotheriwse +216:32
efriedchanging to 'must be'16:32
efriedmelwitt: You good here?16:32
melwittlooks ok to me16:32
efriedace. Sending.16:32
cdentaw, damn, I would have liked some efried typos out in the world16:32
cdentit would have made me feel so much better16:32
efriedfind a way to get me to type in portuguese. I can't spell for shit.16:32
efriedbtw, subject: [nova][placement] Freezing placement for extraction16:33
mriedemsure16:33
efriedsent16:34
efriedthanks y'all16:34
*** lei-zh has quit IRC16:37
*** ttsiouts has quit IRC16:59
*** ttsiouts has joined #openstack-placement17:00
*** ttsiouts has quit IRC17:04
*** mriedem is now known as mriedem_afk17:11
openstackgerritMerged openstack/nova master: reshaper gabbit: Nix comments re doubled max_unit  https://review.openstack.org/59722017:21
edleafew00t! https://review.openstack.org/#/c/597220/ merged!17:25
* edleafe starts git cloning...17:25
openstackgerritMerged openstack/nova master: Fix race condition in reshaper handler  https://review.openstack.org/59649717:35
openstackgerritMerged openstack/nova master: Report client: get_allocations_for_provider_tree  https://review.openstack.org/58464817:46
*** tssurya has quit IRC17:46
*** bauzas has joined #openstack-placement18:28
openstackgerritMerged openstack/nova-specs master: Move rocky implemented specs  https://review.openstack.org/59262218:36
cdentmelwitt, mriedem_afk, efried, edleafe : we'd like to decide what the form of the placement "seed" repo is. There are two options:18:40
* efried listens18:40
cdenta) the immediate results of the scripted git filter-branch. this means there will be a few large automated file and import path changes in gerrit18:41
cdentb) the result of the filter-branch, with followup commits with those path changes (so we still get the history of those changes, but not in gerrit)18:41
efriedcdent: tbc, with (a) I get to see the path/import changes in a gerrit review; with (b) I don't.18:42
cdentefried: correct. with a you can see then in git history, but not in gerrit18:43
cdentsorry with b18:43
efriediow the "followup commits" you reference in (b) would be github commits18:43
melwittI think I'd rather see a) so we get the visibility of the changes in the openstack review system18:44
cdentefried: yes, but you make it sound like that means they are lost to the sands of time, they are not: they will forever be in git history18:44
efriedI prefer (a). My preference for reduction of the number of gerrit reviews was always based on starting off with (a) in any case.18:44
efriedcdent: Yeah, I get it.18:44
efriedcdent: It's just, that's exactly what I want to be reviewing, and I don't want to review it in github; I want to review it in gerrit.18:44
cdentefried: that's fine, I'm merely checking so that we can do the right thing.18:45
edleafeefried: good to hear, because that's how I restructured the extraction process18:45
efriedsounds good to me. Thanks for checking in.18:46
melwittyeah, I agree. it would be easier for everyone to review things in gerrit. thanks18:46
cdentthe question really centered around whether the mechanical path changes were worth of review, the answer sounds like a resounding "yes"18:46
efriedyup18:55
efriedIt's not really that I care to review the path/import changes so much as that I want to make sure that nothing else got changed along the way.18:55
efriediow I want the base in gerrit to be as raw as possible.18:55
melwitt+118:57
efried(except I don't want to review tens of thousands of file deletions)19:00
melwittright, so this will be a raw copy of the placement directory (the output of the filter) and thus we will not be considering tens of thousands of file deletions, IIUC19:06
edleafemelwitt: that's correct19:10
edleafethe filter_history script, well, filters out all history not related to placement, so there's no trace of that file19:10
melwittcool, thanks19:10
*** mriedem has joined #openstack-placement19:11
*** mriedem_afk has quit IRC19:12
openstackgerritEric Fried proposed openstack/nova master: Fix reshaper report client functonal test nits  https://review.openstack.org/59833019:21
efriedmriedem: This bud's for you ^19:22
mriedemis it bud dry?19:23
mriedemthat is some grade A ascii19:23
efriedYou can tell because the mountains are blue.19:24
efriedowait, that's coors19:24
efriedCould be the other kind of bug. The green kind. I know you like: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-04-20.log.html#t2018-04-20T21:21:0219:25
efrieds/bug/bud/ (ruined it)19:26
mriedemwow you had pulled that up quick19:27
efriedeasy one to find19:28
*** e0ne has joined #openstack-placement19:34
mriedemoh right april 2019:40
mriedemtouche19:40
mriedemapparently i don't have the short term memory to remember these things for some reason19:40
openstackgerritMatt Riedemann proposed openstack/nova master: Default AZ for instance if cross_az_attach=False and checking from API  https://review.openstack.org/46967519:41
openstackgerritChris Dent proposed openstack/nova master: VMware: Live migration of instances  https://review.openstack.org/27011619:49
*** ttsiouts has joined #openstack-placement19:56
openstackgerritMerged openstack/nova master: Report client: _reshape helper, placement min bump  https://review.openstack.org/58503420:09
jaypipescdent, efried: apologies for being AFK this afternoon. please brief me on anything important I may have missed or been needed for. :(20:14
efriedjaypipes: See ML for placement freeze strategy, scream if you disagree.20:14
efriedjaypipes: Agreed initial seed of placement repo will be "raw" - file/import renames will be done within a gerrit review.20:15
efriedjaypipes: Other than that, I don't think you missed anything crucial.20:15
*** e0ne has quit IRC20:29
*** takashin has joined #openstack-placement20:54
openstackgerritMatt Riedemann proposed openstack/nova master: Log the operation when updating generation in ProviderTree  https://review.openstack.org/59755321:13
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756021:13
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756021:15
openstackgerritDan Smith proposed openstack/nova master: WIP: Move conductor wait_until_ready() delay before manager init  https://review.openstack.org/59835321:18
*** ttsiouts has quit IRC21:19
cdentmriedem, efried, edleafe, jaypipes: I'm working on the project-config changes to get placement sucked in and I'm intending to not set up any job in a centralized fashion, and instead use .zuul.yaml in-repo as that's the new shiny and what the python3 goal automation is doing. any objections?21:19
*** takashin has left #openstack-placement21:20
edleafecdent: Sounds good to me.21:20
*** ttsiouts has joined #openstack-placement21:20
efriedMakes sense to me except for "not set up any job in a centralized fashion" <== not sure what you mean by this.21:20
*** ttsiouts has quit IRC21:20
efriedI thought .zuul.yaml in-repo *was* setting up jobs in a centralized fashion.21:20
*** ttsiouts has joined #openstack-placement21:20
efried...which I agree is what we should do.21:20
mriedemi think he means from openstack-zuul-jobs21:21
mriedemor project-config21:21
mriedemwhich are global21:21
mriedembranchless21:21
cdentefried: the "old" way is to edit zuul.d/projects.yaml in openstack-infra/project-config repo: a single centralized location, rather than in the individual projects21:22
efriedoic, you're intending not to put anything into the project-config thing, and exclusively use the in-repo .zuul.yaml to define jobs.21:22
efriedI dig it.21:22
cdentcorrect21:22
melwittare all of the pertinent jobs already in-repo? if they aren't, do we need to move them first?21:22
cdentmelwitt: as I understood things the intention was to start with the standard python jobs21:23
cdentI figured only once we had those working would be bother with any additions21:23
melwittoh, start. yeah that's right. I think I was jumping ahead21:23
melwittyeah21:23
cdentat which point we address the question of "where is this job anyway?"21:23
efriedand "where should it be?"21:24
* melwitt nods21:24
jaypipescdent: works for me21:26
*** ttsiouts has quit IRC21:37
*** ttsiouts has joined #openstack-placement21:40
*** ttsiouts has quit IRC21:49
*** ttsiouts has joined #openstack-placement21:50
openstackgerritMatt Riedemann proposed openstack/nova master: Avoid spurious ComputeNode.save during update_available_resource periodic  https://review.openstack.org/59836522:05
openstackgerritDan Smith proposed openstack/nova master: Move conductor wait_until_ready() delay before manager init  https://review.openstack.org/59835322:10
*** purplerbot has quit IRC22:16
*** purplerbot has joined #openstack-placement22:17
*** mriedem is now known as mriedem_lawnboy22:17
openstackgerritEric Fried proposed openstack/nova master: Fix nits: Compute: Handle reshaped provider trees  https://review.openstack.org/59838722:37
efriedmriedem_lawnboy: another green one for ya ^22:38
*** ttsiouts has quit IRC22:49
*** ttsiouts has joined #openstack-placement22:50
*** ttsiouts has quit IRC22:54
cdentedleafe, efried, jaypipes, melwitt, mriedem_lawnboy : https://review.openstack.org/#/c/598362/ , https://review.openstack.org/#/c/598380/22:57
cdentthose are the revies for infra and gov of placement22:58
melwittcdent: thanks. it's not my expectation that we'll switch governance near s-2. what I'd like to see is the code extraction complete and working with upgrades etc (via zuul job testing) and then we talk and find an agreeable timeline for switching governance23:01
cdentmelwitt: I know, but in discussion with the TC and with people who do want to see it happen before the end of Stein, it was decided that it was necessary to post a review that set a hard deadline so it could be discussed there. Stein 2 was considered a reasonable middle of the orad23:03
cdentif it's not okay, say so on the review and we can hash it out there23:03
melwittokay23:03
cdentg'night all23:22
*** cdent has quit IRC23:22

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!