*** efried1 has joined #openstack-placement | 00:50 | |
*** efried has quit IRC | 00:51 | |
*** efried1 is now known as efried | 00:51 | |
openstackgerrit | Merged openstack/nova master: [placement] Make _ensure_aggregate context not independent https://review.openstack.org/597486 | 00:52 |
---|---|---|
*** efried has quit IRC | 00:58 | |
openstackgerrit | Merged openstack/nova master: Add explanatory prefix to post_test_perf output https://review.openstack.org/591850 | 01:05 |
openstackgerrit | Merged openstack/nova master: Add trait query to placement perf check https://review.openstack.org/592624 | 01:12 |
openstackgerrit | Merged openstack/nova master: Restart scheduler in TestNovaManagePlacementHealAllocations https://review.openstack.org/597571 | 01:12 |
openstackgerrit | Merged openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033 | 01:12 |
*** alex_xu has joined #openstack-placement | 01:19 | |
*** efried has joined #openstack-placement | 01:20 | |
openstackgerrit | Merged openstack/nova master: Make get_allocations_for_resource_provider raise https://review.openstack.org/584598 | 03:28 |
openstackgerrit | Merged openstack/nova master: api-ref: fix volume attachment update policy note https://review.openstack.org/596489 | 03:28 |
*** nicolasbock has quit IRC | 03:40 | |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix a failure to format config sample https://review.openstack.org/597986 | 05:08 |
openstackgerrit | Takashi NATSUME proposed openstack/nova stable/rocky: Fix a broken conf file description in networking doc https://review.openstack.org/597987 | 05:20 |
*** e0ne has joined #openstack-placement | 05:31 | |
*** tetsuro has joined #openstack-placement | 05:53 | |
*** openstackgerrit has quit IRC | 06:07 | |
*** e0ne has quit IRC | 06:19 | |
*** e0ne has joined #openstack-placement | 06:20 | |
*** e0ne has quit IRC | 06:20 | |
*** openstackgerrit has joined #openstack-placement | 06:21 | |
openstackgerrit | huanhongda proposed openstack/nova master: [WIP]Forbidden non-admin user to list deleted instances https://review.openstack.org/598012 | 06:21 |
*** tetsuro has quit IRC | 07:02 | |
*** tetsuro has joined #openstack-placement | 07:06 | |
openstackgerrit | Merged openstack/nova stable/rocky: Fix a broken conf file description in networking doc https://review.openstack.org/597987 | 07:56 |
*** cdent has joined #openstack-placement | 07:59 | |
*** tetsuro has quit IRC | 08:20 | |
*** tetsuro has joined #openstack-placement | 08:22 | |
openstackgerrit | huanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state https://review.openstack.org/598084 | 08:24 |
openstackgerrit | Rong Han proposed openstack/nova master: Reset global variable after unit test is completed. https://review.openstack.org/598088 | 08:42 |
*** ttsiouts has joined #openstack-placement | 08:43 | |
*** e0ne has joined #openstack-placement | 08:48 | |
*** takashin has quit IRC | 09:09 | |
openstackgerrit | huanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state https://review.openstack.org/598084 | 09:15 |
*** tetsuro has quit IRC | 09:23 | |
*** takashin has joined #openstack-placement | 09:34 | |
*** takashin has left #openstack-placement | 09:34 | |
*** cdent has quit IRC | 10:02 | |
*** deepak_mourya_ has joined #openstack-placement | 10:11 | |
*** nicolasbock has joined #openstack-placement | 10:47 | |
*** ttsiouts has quit IRC | 10:56 | |
openstackgerrit | Rong Han proposed openstack/nova master: Reset global variable after unit test is completed. https://review.openstack.org/598088 | 11:00 |
*** cdent has joined #openstack-placement | 11:15 | |
openstackgerrit | Merged openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599 | 11:17 |
*** cdent has quit IRC | 11:23 | |
*** tetsuro has joined #openstack-placement | 11:27 | |
openstackgerrit | Rong Han proposed openstack/nova master: Reset global variable after unit test is completed. https://review.openstack.org/598088 | 11:36 |
*** tetsuro has quit IRC | 11:38 | |
*** ttsiouts has joined #openstack-placement | 11:43 | |
*** cdent has joined #openstack-placement | 11:49 | |
*** tetsuro has joined #openstack-placement | 12:03 | |
*** tetsuro has quit IRC | 12:07 | |
*** tetsuro has joined #openstack-placement | 12:08 | |
openstackgerrit | Jay Pipes proposed openstack/os-traits master: clean up CUDA traits https://review.openstack.org/597170 | 12:41 |
*** mriedem has joined #openstack-placement | 12:54 | |
openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Restart scheduler in TestNovaManagePlacementHealAllocations https://review.openstack.org/598152 | 12:59 |
*** tssurya has joined #openstack-placement | 13:01 | |
openstackgerrit | Chen proposed openstack/nova master: Fix filter server list by multiple vm or task states https://review.openstack.org/598154 | 13:09 |
cdent | gibi: just wanted to say: still chewing on your request groups in ac stuff | 13:10 |
gibi | cdent: no worries, I tried to publish it before the PTG so that we can have a meaningful discussion in Denver | 13:13 |
cdent | gibi: 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 alternatives | 13:15 |
gibi | cdent: 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 |
gibi | cdent: I feel that '_if_ | 13:19 |
cdent | :) | 13:19 |
gibi | cdent: I feel that '_if_' question will be a bigger debate | 13:19 |
gibi | btw 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 pairs | 13:20 |
gibi | but in placement we have a change to limit the size of those products with the limit query paramter | 13:21 |
openstackgerrit | Radoslav Gerganov proposed openstack/nova-specs master: VMware: add support for live migration https://review.openstack.org/598163 | 13:23 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform compute_task notifications https://review.openstack.org/482629 | 13:45 |
openstackgerrit | Merged openstack/nova master: (Re)start caching scheduler after starting computes in tests https://review.openstack.org/597606 | 13:47 |
alex_xu | jaypipes: efried cdent, is it terrible if I create resource provider for each assignable device? | 13:52 |
cdent | alex_xu: I need a bit more context. Which devices are you talking about? | 13:53 |
jaypipes | gibi: I am also still chewing on your spec. review should be done in an hour or two. | 13:54 |
alex_xu | cdent: like the #1 case in https://etherpad.openstack.org/p/nova_nvdimm | 13:54 |
gibi | jaypipes: thanks for your time | 13:55 |
jaypipes | gibi: nem probléma | 13:58 |
gibi | jaypipes: :) | 13:59 |
*** tetsuro has quit IRC | 14:00 | |
cdent | alex_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 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes https://review.openstack.org/597560 | 14:03 |
alex_xu | cdent: 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_xu | cdent: 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_xu | cdent: why landing a workload is more complicated? | 14:12 |
cdent | In #1 there are two different rp identifiers for the same nvimm, which means some kind of mapping needs to be maintained | 14:13 |
alex_xu | ah, you are right, probably a dict to mapping the device and uuid. | 14:14 |
alex_xu | or put the device identifiers to the RP name | 14:14 |
cdent | which is fine, but... I'm not sure of the right word: messy? hacky? | 14:15 |
alex_xu | try to think about how can we map rp with numa node, rp with sriov pf | 14:17 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Revert "Update resources once in update_available_resource" https://review.openstack.org/598176 | 14:19 |
alex_xu | cdent: no idea :) | 14:20 |
cdent | :) | 14:20 |
gibi | alex_xu: network device (like sriov PF) mapped to RP in neutron. One PF is one RP with a VF inventory | 14:23 |
gibi | alex_xu: the uuid of the RP is generated from with uuid5(hostname,pf-device-name) | 14:24 |
alex_xu | gibi: ah | 14:24 |
efried | alex_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 |
gibi | alex_xu: I lied there is no VF inventory just bandwidth inventory at the momement on a PF RP | 14:25 |
alex_xu | efried: cool, sounds like I didn't do a wrong thing, what kind of device in the powervm? | 14:26 |
efried | alex_xu: Well, just because we're doing it in powervm doesn't mean it won't be considered "wrong" :) | 14:26 |
alex_xu | gibi: but I see the idea :) | 14:26 |
efried | alex_xu: At the moment we're focusing on passing through entire devices. | 14:26 |
efried | alex_xu: https://review.openstack.org/#/c/579359/ | 14:27 |
alex_xu | efried: 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 request | 14:27 |
efried | alex_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 |
efried | alex_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 RP | 14:28 |
gibi | alex_xu, efried: the power plan seems to be consistent with the current neutron / bandwidth modelling | 14:29 |
alex_xu | efried: indeed, for the PF case, yes, each PF should be a RP | 14:29 |
efried | gibi: I'm going to need to catch up on the neutron/bandwidth specs... | 14:29 |
gibi | efried: 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 |
efried | yes, I'm looking forward to seeing that. | 14:30 |
alex_xu | I'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 |
efried | alex_xu: I don't understand what's going on at L75-79 in that etherpad. | 14:32 |
efried | If you're using group_policy=none, you should be getting a match from CN1 | 14:32 |
alex_xu | efried: in the end, we merge the resources1 and resource2, then we found 2+2 > CN1's max_size | 14:33 |
efried | alex_xu: Then that's a placement bug. | 14:33 |
efried | oh | 14:34 |
alex_xu | efried: it is already wellknown bug? | 14:34 |
efried | no, sorry, hold on. | 14:34 |
efried | This is related to what gibi is getting at with https://review.openstack.org/#/c/597601/ | 14:35 |
alex_xu | at least our response in the API only can have one entry for same resource class in same RP | 14:35 |
efried | yeah | 14:35 |
efried | so fixing this is going to entail a complete rework of some payload formats. | 14:35 |
alex_xu | have to say gibi got a lot of interesting spec from bandwidth case :) | 14:36 |
gibi | I guess I got them first because bandwidth was the first user of nested RP and granular group | 14:36 |
alex_xu | hah | 14:36 |
efried | alex_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_xu | efried: what you mean multiple separate allocation request? | 14:37 |
alex_xu | any example | 14:38 |
efried | um, yeah, sorry, that doesn't work either. Would have to be two separate consumers. | 14:38 |
efried | We just don't have a way to represent this. | 14:38 |
alex_xu | yea | 14:39 |
efried | And 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_xu | and you have no way to ensure they are one same comput enode | 14:40 |
alex_xu | anyway, if the #1 workable, I think it is better. | 14:41 |
alex_xu | at least the user can create any size device | 14:41 |
alex_xu | efried: cdent gibi, thank you guys for your time | 14:43 |
gibi | alex_xu: np | 14:44 |
cdent | alex_xu: thanks for pushing the boundaries | 14:44 |
*** lei-zh has joined #openstack-placement | 14:46 | |
*** ttsiouts has quit IRC | 14:55 | |
edleafe | efried: 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 |
jaypipes | edleafe: all of the reshaper series. | 14:59 |
edleafe | jaypipes: I thought all of the placement side of it merged already | 15:00 |
edleafe | Oh, I see Eric's patch that just removes some comments only has 1 +2 | 15:01 |
*** ttsiouts has joined #openstack-placement | 15:01 | |
edleafe | Everything else in the bp/reshape-provider-tree series is for compute | 15:02 |
openstackgerrit | Merged openstack/nova master: Fix soft deleting vm fails after "nova resize" vm https://review.openstack.org/546920 | 15:03 |
*** e0ne has quit IRC | 15:27 | |
efried | edleafe: I don't think there's anything crucial pending, no. | 15:39 |
edleafe | efried: Thanks. It looked that way to me, but wanted to double-check | 15:40 |
efried | edleafe: In fact, I wouldn't be averse to abandoning https://review.openstack.org/#/c/597220/ in nova and reproposing it in placement. | 15:40 |
cdent | efried, 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 |
edleafe | efried: Sure, but I'd rather it get a second +2 and merge :) | 15:41 |
efried | cdent: we can -2 stuff as we find it I suppose. | 15:41 |
efried | If you see it before I do, bring it to my attention. | 15:41 |
efried | And let everyone know that's what's going on. | 15:41 |
cdent | jaypipes or gibi: you happy to kick https://review.openstack.org/#/c/597220/ in? | 15:42 |
gibi | cdent: looking | 15:42 |
efried | I 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 |
gibi | cdent: +A | 15:43 |
cdent | yay! | 15:43 |
gibi | efried: a clear mail on the ML about the freeze and then I think we are safe | 15:43 |
edleafe | Nice! | 15:43 |
efried | Cool, now we just need three days to get it merged. | 15:43 |
efried | gate has been brutal to the reshaper series. | 15:44 |
edleafe | As soon as that merges, I'll start a new extraction run | 15:44 |
gibi | efried: it is test only so gate will be gentle, a hope | 15:44 |
efried | The phrase "morning rechecks + coffee" has come to mind. | 15:44 |
openstackgerrit | Merged openstack/nova-specs master: VMware: add support for live migration https://review.openstack.org/598163 | 15:50 |
efried | edleafe: 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 |
mriedem | i guess that was prompted by my huh | 15:56 |
mriedem | *me | 15:56 |
efried | yup | 15:57 |
efried | see link in commit message | 15:57 |
edleafe | efried: sure, but that is pretty trivial, and could be easily applied post-extraction | 15:57 |
efried | yes, sure, swhy I'm asking. | 15:57 |
edleafe | and it's not part of reshaper | 15:57 |
efried | (the comment removal could have also been applied post-extraction) | 15:58 |
edleafe | efried: yeah, but that already had a +2 :) | 16:01 |
efried | edleafe: Okay, jaypipes doesn't like that patch, so I'm going to -2 it for now. (<== mriedem FYI) | 16:01 |
efried | edleafe: other one has a +2 now as well. But also a -1. So ^ | 16:01 |
efried | edleafe, cdent: one of y'all already working on the freeze email? | 16:03 |
cdent | efried: I had not started for two reasons: 1) in the api-sig meeting, 2) not a nova core | 16:03 |
edleafe | efried: we're in the API-SIG meeting now. Feel free to write one | 16:04 |
cdent | so if you've got the cycles I say go for it | 16:04 |
efried | cdent, edleafe: ack, doing it. | 16:04 |
edleafe | thx | 16:04 |
melwitt | so what's the plan? freeze now and then propose the gerrit changes immediately after? | 16:12 |
efried | melwitt: 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 |
melwitt | ok | 16:13 |
efried | melwitt, cdent, edleafe, mriedem, jaypipes: 1st pass: http://paste.openstack.org/raw/729164/ | 16:16 |
mriedem | nothing refers to [1] | 16:17 |
edleafe | efried: Looks good, except for the "Howdy y'all" :) | 16:17 |
efried | perhaps s/extraction is complete/repository is seeded/ ? | 16:17 |
* edleafe still can't stand that even after 10 years in Texas | 16:17 | |
efried | mriedem: Whoops, yeah, I was going to say "we'll start once [1] is merged". | 16:17 |
mriedem | listen y'all, -1 on this paste y'all | 16:17 |
edleafe | efried: No, I think complete is best | 16:17 |
edleafe | Once seeded, we will have several patches to get tests passing | 16:18 |
efried | right, so should we maybe define "complete"? | 16:18 |
edleafe | ...instead of seeding with the finished product as originally planned | 16:18 |
efried | I.e. does that mean you should wait until all those patches merge before proposing? | 16:18 |
edleafe | proposing... what? | 16:19 |
melwitt | will 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 |
cdent | efried: yes, because that stack will have path changes etc | 16:19 |
efried | cdent: okay, swhat I figgered. | 16:19 |
edleafe | melwitt: I don't think that's necessary. The intent is to let people know about the freeze | 16:19 |
efried | melwitt: I figured that was out of scope for this, and covered in the other thread - the one with (technical) in the subject. | 16:19 |
cdent | melwitt: you seen my 1.x.x.x list? with links to the infra doc on the seeding topic? | 16:19 |
melwitt | mostly, I just want to know is everything already ready to go, we freeze when we are going to start moving things | 16:20 |
mriedem | i assume she means the actual infra setup | 16:20 |
mriedem | https://docs.openstack.org/project-team-guide/ ? | 16:20 |
edleafe | melwitt: we need to freeze before the history filter script is applied | 16:20 |
mriedem | oh this https://docs.openstack.org/infra/manual/creators.html | 16:20 |
melwitt | like, when this freeze is started, how long before we see the changes in gerrit that we can start reviewing | 16:20 |
cdent | mriedem: yeah, that, linked from my email | 16:20 |
melwitt | ok | 16:20 |
cdent | matter of days, depending on how long it takes infra to react to the seeding request | 16:21 |
edleafe | the freeze is just on new placement work. The patches in the new repo will be reviewable right away | 16:21 |
melwitt | are 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 followed | 16:28 |
mriedem | i believe that's normal, | 16:28 |
melwitt | will that result in gerrit changes for review or? | 16:28 |
mriedem | roman had osc-placement in his github i think | 16:28 |
mriedem | infra has to seed from something for the initial clone i think | 16:28 |
efried | melwitt, edleafe, cdent, mriedem, jaypipes: v2: http://paste.openstack.org/raw/729165/ | 16:28 |
mriedem | https://review.openstack.org/#/c/448115/ | 16:29 |
mriedem | ^ is the osc-placement seed patch | 16:29 |
mriedem | upstream: https://github.com/malor/osc-placement.git | 16:30 |
cdent | wfm efried | 16:30 |
edleafe | efried: ship it | 16:30 |
mriedem | efried: "the fix should must proposed t" | 16:31 |
efried | thx | 16:31 |
mriedem | i assume you don't want that hanging over your head for all time | 16:31 |
efried | you got that right. | 16:31 |
mriedem | otheriwse +2 | 16:32 |
efried | changing to 'must be' | 16:32 |
efried | melwitt: You good here? | 16:32 |
melwitt | looks ok to me | 16:32 |
efried | ace. Sending. | 16:32 |
cdent | aw, damn, I would have liked some efried typos out in the world | 16:32 |
cdent | it would have made me feel so much better | 16:32 |
efried | find a way to get me to type in portuguese. I can't spell for shit. | 16:32 |
efried | btw, subject: [nova][placement] Freezing placement for extraction | 16:33 |
mriedem | sure | 16:33 |
efried | sent | 16:34 |
efried | thanks y'all | 16:34 |
*** lei-zh has quit IRC | 16:37 | |
*** ttsiouts has quit IRC | 16:59 | |
*** ttsiouts has joined #openstack-placement | 17:00 | |
*** ttsiouts has quit IRC | 17:04 | |
*** mriedem is now known as mriedem_afk | 17:11 | |
openstackgerrit | Merged openstack/nova master: reshaper gabbit: Nix comments re doubled max_unit https://review.openstack.org/597220 | 17:21 |
edleafe | w00t! https://review.openstack.org/#/c/597220/ merged! | 17:25 |
* edleafe starts git cloning... | 17:25 | |
openstackgerrit | Merged openstack/nova master: Fix race condition in reshaper handler https://review.openstack.org/596497 | 17:35 |
openstackgerrit | Merged openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648 | 17:46 |
*** tssurya has quit IRC | 17:46 | |
*** bauzas has joined #openstack-placement | 18:28 | |
openstackgerrit | Merged openstack/nova-specs master: Move rocky implemented specs https://review.openstack.org/592622 | 18:36 |
cdent | melwitt, 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 listens | 18:40 | |
cdent | a) the immediate results of the scripted git filter-branch. this means there will be a few large automated file and import path changes in gerrit | 18:41 |
cdent | b) 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 |
efried | cdent: tbc, with (a) I get to see the path/import changes in a gerrit review; with (b) I don't. | 18:42 |
cdent | efried: correct. with a you can see then in git history, but not in gerrit | 18:43 |
cdent | sorry with b | 18:43 |
efried | iow the "followup commits" you reference in (b) would be github commits | 18:43 |
melwitt | I think I'd rather see a) so we get the visibility of the changes in the openstack review system | 18:44 |
cdent | efried: 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 history | 18:44 |
efried | I 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 |
efried | cdent: Yeah, I get it. | 18:44 |
efried | cdent: 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 |
cdent | efried: that's fine, I'm merely checking so that we can do the right thing. | 18:45 |
edleafe | efried: good to hear, because that's how I restructured the extraction process | 18:45 |
efried | sounds good to me. Thanks for checking in. | 18:46 |
melwitt | yeah, I agree. it would be easier for everyone to review things in gerrit. thanks | 18:46 |
cdent | the question really centered around whether the mechanical path changes were worth of review, the answer sounds like a resounding "yes" | 18:46 |
efried | yup | 18:55 |
efried | It'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 |
efried | iow I want the base in gerrit to be as raw as possible. | 18:55 |
melwitt | +1 | 18:57 |
efried | (except I don't want to review tens of thousands of file deletions) | 19:00 |
melwitt | right, 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, IIUC | 19:06 |
edleafe | melwitt: that's correct | 19:10 |
edleafe | the filter_history script, well, filters out all history not related to placement, so there's no trace of that file | 19:10 |
melwitt | cool, thanks | 19:10 |
*** mriedem has joined #openstack-placement | 19:11 | |
*** mriedem_afk has quit IRC | 19:12 | |
openstackgerrit | Eric Fried proposed openstack/nova master: Fix reshaper report client functonal test nits https://review.openstack.org/598330 | 19:21 |
efried | mriedem: This bud's for you ^ | 19:22 |
mriedem | is it bud dry? | 19:23 |
mriedem | that is some grade A ascii | 19:23 |
efried | You can tell because the mountains are blue. | 19:24 |
efried | owait, that's coors | 19:24 |
efried | Could 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:02 | 19:25 |
efried | s/bug/bud/ (ruined it) | 19:26 |
mriedem | wow you had pulled that up quick | 19:27 |
efried | easy one to find | 19:28 |
*** e0ne has joined #openstack-placement | 19:34 | |
mriedem | oh right april 20 | 19:40 |
mriedem | touche | 19:40 |
mriedem | apparently i don't have the short term memory to remember these things for some reason | 19:40 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Default AZ for instance if cross_az_attach=False and checking from API https://review.openstack.org/469675 | 19:41 |
openstackgerrit | Chris Dent proposed openstack/nova master: VMware: Live migration of instances https://review.openstack.org/270116 | 19:49 |
*** ttsiouts has joined #openstack-placement | 19:56 | |
openstackgerrit | Merged openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034 | 20:09 |
jaypipes | cdent, efried: apologies for being AFK this afternoon. please brief me on anything important I may have missed or been needed for. :( | 20:14 |
efried | jaypipes: See ML for placement freeze strategy, scream if you disagree. | 20:14 |
efried | jaypipes: Agreed initial seed of placement repo will be "raw" - file/import renames will be done within a gerrit review. | 20:15 |
efried | jaypipes: Other than that, I don't think you missed anything crucial. | 20:15 |
*** e0ne has quit IRC | 20:29 | |
*** takashin has joined #openstack-placement | 20:54 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Log the operation when updating generation in ProviderTree https://review.openstack.org/597553 | 21:13 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes https://review.openstack.org/597560 | 21:13 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes https://review.openstack.org/597560 | 21:15 |
openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Move conductor wait_until_ready() delay before manager init https://review.openstack.org/598353 | 21:18 |
*** ttsiouts has quit IRC | 21:19 | |
cdent | mriedem, 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-placement | 21:20 | |
edleafe | cdent: Sounds good to me. | 21:20 |
*** ttsiouts has joined #openstack-placement | 21:20 | |
efried | Makes 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 IRC | 21:20 | |
efried | I thought .zuul.yaml in-repo *was* setting up jobs in a centralized fashion. | 21:20 |
*** ttsiouts has joined #openstack-placement | 21:20 | |
efried | ...which I agree is what we should do. | 21:20 |
mriedem | i think he means from openstack-zuul-jobs | 21:21 |
mriedem | or project-config | 21:21 |
mriedem | which are global | 21:21 |
mriedem | branchless | 21:21 |
cdent | efried: 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 projects | 21:22 |
efried | oic, 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 |
efried | I dig it. | 21:22 |
cdent | correct | 21:22 |
melwitt | are all of the pertinent jobs already in-repo? if they aren't, do we need to move them first? | 21:22 |
cdent | melwitt: as I understood things the intention was to start with the standard python jobs | 21:23 |
cdent | I figured only once we had those working would be bother with any additions | 21:23 |
melwitt | oh, start. yeah that's right. I think I was jumping ahead | 21:23 |
melwitt | yeah | 21:23 |
cdent | at which point we address the question of "where is this job anyway?" | 21:23 |
efried | and "where should it be?" | 21:24 |
* melwitt nods | 21:24 | |
jaypipes | cdent: works for me | 21:26 |
*** ttsiouts has quit IRC | 21:37 | |
*** ttsiouts has joined #openstack-placement | 21:40 | |
*** ttsiouts has quit IRC | 21:49 | |
*** ttsiouts has joined #openstack-placement | 21:50 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Avoid spurious ComputeNode.save during update_available_resource periodic https://review.openstack.org/598365 | 22:05 |
openstackgerrit | Dan Smith proposed openstack/nova master: Move conductor wait_until_ready() delay before manager init https://review.openstack.org/598353 | 22:10 |
*** purplerbot has quit IRC | 22:16 | |
*** purplerbot has joined #openstack-placement | 22:17 | |
*** mriedem is now known as mriedem_lawnboy | 22:17 | |
openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits: Compute: Handle reshaped provider trees https://review.openstack.org/598387 | 22:37 |
efried | mriedem_lawnboy: another green one for ya ^ | 22:38 |
*** ttsiouts has quit IRC | 22:49 | |
*** ttsiouts has joined #openstack-placement | 22:50 | |
*** ttsiouts has quit IRC | 22:54 | |
cdent | edleafe, efried, jaypipes, melwitt, mriedem_lawnboy : https://review.openstack.org/#/c/598362/ , https://review.openstack.org/#/c/598380/ | 22:57 |
cdent | those are the revies for infra and gov of placement | 22:58 |
melwitt | cdent: 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 governance | 23:01 |
cdent | melwitt: 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 orad | 23:03 |
cdent | if it's not okay, say so on the review and we can hash it out there | 23:03 |
melwitt | okay | 23:03 |
cdent | g'night all | 23:22 |
*** cdent has quit IRC | 23:22 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!