| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-04 | |||
| 10:40:06 | kashyap | Only one way to try | |
| 10:40:11 | kashyap | s/try/figure/ | |
| 10:46:53 | johnthetubaguy | kashyap: ha, good question, it might do | |
| 10:47:15 | johnthetubaguy | not for good reasons, our testing of the min version is laughable, AFAIK | |
| 10:47:25 | kashyap | :D | |
| 10:51:34 | openstackgerrit | Merged openstack/nova-specs master: Fix endpoint URI /allocation_requests https://review.openstack.org/557580 | |
| 10:55:48 | openstackgerrit | Merged openstack/nova-specs master: Provide error codes for placement API https://review.openstack.org/418393 | |
| 11:02:58 | sean-k-mooney | johnthetubaguy: kashyap for the rocky realse are we then not going to bump byond those verions and just use what we had planned for queens | |
| 11:03:14 | kashyap | sean-k-mooney: That's a good question | |
| 11:03:35 | kashyap | sean-k-mooney: I don't know, since we didn't give a heads-up, then we should simply stick with the versions what we planned for 'Queens'? | |
| 11:03:41 | kashyap | I know it sucks | |
| 11:04:04 | kashyap | sean-k-mooney: But we _can_ bump it; if we all agree | |
| 11:04:20 | sean-k-mooney | its less then ideal but if we dont depend on somthing form a newer release then i guess we dont have to bump | |
| 11:04:21 | kashyap | > (Hmm, but note that libvirt 1.3.1 was released more | |
| 11:04:21 | kashyap | That's why I added the note to my post to the list: | |
| 11:04:24 | kashyap | > than 2 years ago[1].) | |
| 11:04:30 | sean-k-mooney | ya i know | |
| 11:04:35 | sean-k-mooney | thats why i asked :) | |
| 11:05:17 | sean-k-mooney | it finally means we dont have to check libvirt verions for vhost multi queue once we require 1.3.1+ | |
| 11:14:07 | openstackgerrit | Merged openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 11:41:08 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU} versions for "Rocky" https://review.openstack.org/558783 | |
| 11:50:21 | kashyap | johnthetubaguy: ^ | |
| 11:50:48 | johnthetubaguy | kashyap: cool, ping me when zuul says yes | |
| 11:50:56 | kashyap | Yeap | |
| 12:07:10 | kashyap | johnthetubaguy: We did in the past: https://review.openstack.org/#/c/432700/2/releasenotes/notes/pike-libvirt-min-version-bb7f43020995ac10.yaml | |
| 12:07:55 | johnthetubaguy | kashyap: ah, cool, upgrade sounds correct | |
| 12:08:12 | kashyap | Err, you're right | |
| 12:08:23 | kashyap | I'll do the s/feature/upgrade/ | |
| 12:15:14 | gmann | johnthetubaguy: i might not be getting you completely but yes we can adopt the new set of rules at same time based on old rule is overridden or not. If not then check new rule otherwise go for old rules till we remove them after deprecation phase | |
| 12:19:20 | johnthetubaguy | gmann: not sure, do we have a spec for the Admin vs Read vs Write policy roles? | |
| 12:19:35 | gmann | johnthetubaguy: i think not yet. | |
| 12:19:53 | gmann | johnthetubaguy: just read your comment on patch. | |
| 12:20:01 | johnthetubaguy | gmann: I see that as way more important, and the best reason to add the more granular rules, if that makes sense? | |
| 12:20:14 | gmann | johnthetubaguy: i see your point | |
| 12:20:20 | johnthetubaguy | I assume its operators that want those read only roles that want the extra granularity? | |
| 12:20:38 | johnthetubaguy | so we can give them what the want, rather than what they are asking for, maybe? | |
| 12:20:40 | gmann | yea mainly those | |
| 12:21:49 | gmann | but with admin, read and write roles still we need granular rules with right default out of admin, read, write whatever suitable | |
| 12:22:20 | johnthetubaguy | yes, but I think adding admin, read, write is the reason to add the granular rules | |
| 12:23:57 | johnthetubaguy | gmann: I think there is a patch to add the global vs non-global stuff somewhere, I should dig that up too | |
| 12:26:11 | gmann | johnthetubaguy: ok, i ll search it tomorrow. and yea i think i agree on your point. it makes sense of granular rules with those role. otherwise operator keep having complexity of their own defined roles. | |
| 12:28:44 | johnthetubaguy | gmann: cool, that is the way I was thinking anyways, have a good evening/night | |
| 12:30:02 | kashyap | johnthetubaguy: A quick one: I think you meant to use FAKE_LIBVIRT_VERSION throughout consistently: https://review.openstack.org/#/c/558783/1 | |
| 12:30:24 | gmann | johnthetubaguy: thanks. ll update based on the role patch. | |
| 12:32:31 | johnthetubaguy | kashyap: yeah, that is what I meant to say | |
| 12:33:13 | kashyap | Okido; should also probably add a constant for QEMU | |
| 12:36:01 | johnthetubaguy | yeah, I thought there was one already, but yeah | |
| 12:37:42 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Rocky" https://review.openstack.org/558783 | |
| 12:38:18 | kashyap | johnthetubaguy: Seems like (from a `git grep`) I'm the first user of the constant FAKE_LIBVIRT_VERSION in tests | |
| 12:41:49 | johnthetubaguy | hmm, that is curious | |
| 12:58:45 | efried | johnthetubaguy: Thanks for merging the error codes spec. Do you know who's authorized to approve the blueprint (other than mriedem, who doesn't seem to be around)? | |
| 13:05:47 | johnthetubaguy | efried: I can I think, in theory anyone with nova-specs core should be able to | |
| 13:06:16 | efried | johnthetubaguy: Okay, thanks. | |
| 13:06:41 | johnthetubaguy | that should look better now | |
| 13:07:01 | efried | johnthetubaguy: Nice, thanks! In case you felt like looking at the code while the spec is still fresh, it's ready: https://review.openstack.org/#/c/546177/ | |
| 13:07:33 | efried | be nice to have this code in place for edleafe's work on consumer generations. | |
| 13:07:58 | johnthetubaguy | ah, I see your +2 there already, I will try take a look at that today | |
| 13:08:13 | efried | cool, thank you. | |
| 13:14:16 | mriedem | artom_: can you create https://blueprints.launchpad.net/nova/+spec/numa-aware-live-migration please? | |
| 13:22:22 | artom_ | mriedem, ack | |
| 13:24:26 | artom | mriedem, done | |
| 13:24:46 | mriedem | thanks | |
| 13:35:30 | edleafe | jaypipes: around? | |
| 13:36:04 | edleafe | efried: cdent: maybe you guys could help with a question | |
| 13:36:28 | efried | edleafe: I'm listening. | |
| 13:36:59 | edleafe | ok, <1.8, allocations didn't have project_id/user_id | |
| 13:37:09 | edleafe | in those cases, they are None on the object | |
| 13:37:44 | edleafe | the code I'm doing for consumer generations tries to insert a record in the consumer table if one doesn't yet exist | |
| 13:38:15 | edleafe | But there is a NOT NULL constraint on the project_id and user_id columns, so in that case (and many of our tests) the insert fails | |
| 13:38:46 | edleafe | Should I just punt and say that for <1.8, no consumer record can be created? | |
| 13:39:20 | efried | edleafe: tbc, this is because you wanted to be able to put the generation into the consumers table even for earlier microversions, yah? | |
| 13:40:15 | dansmith | mriedem: I was holding this for your approval: https://review.openstack.org/#/c/558059/4 | |
| 13:40:25 | edleafe | efried: well, normally I'd put a conditional and skip for <1.8. But that means that later calls can and will overwrite | |
| 13:40:38 | edleafe | efried: It does seem that that's the best we can do here | |
| 13:40:44 | edleafe | Just wanted to get a second opinion | |
| 13:41:09 | efried | edleafe: So backing up for a second: today (before your code) if you try to create a consumer record with microversion <1.8, what happens? | |
| 13:41:39 | efried | ...because presumably the request payload doesn't require the proj/user IDs at <1.8 | |
| 13:41:46 | edleafe | efried: the code checks for the presence of those two fields on the allocation object, and if they aren't there, or are None, it skips the creation | |
| 13:42:04 | efried | But how does it ultimately close the loop, then? | |
| 13:42:15 | edleafe | So my feeling is we should continue that behavior, even if it sucks | |
| 13:42:15 | efried | The allocation gets created with... no consumer? | |
| 13:42:25 | edleafe | efried: yep | |
| 13:42:49 | efried | So the consumer in that case is represented only by its UUID in the allocations table; it doesn't truly exist otherwise | |
| 13:42:55 | edleafe | TBC, no consumer *record* | |
| 13:43:10 | edleafe | it still has the instance UUID in the consumer_id field | |
| 13:43:27 | efried | ...of the allocations table | |
| 13:43:33 | edleafe | yes | |
| 13:44:46 | efried | so presumably if you GET an allocation record at 1.8 that was created at <1.8, the proj/user doesn't show up in the response. | |
| 13:44:54 | efried | or it shows up, but with null? | |
| 13:45:28 | edleafe | yeah, they are None >=1.8 | |
| 13:45:42 | efried | Seems to me like the right thing would be to make proj/user be nullable. | |
| 13:45:55 | efried | and always create the record, even <1.8 | |
| 13:46:09 | efried | ...which isn't a behavior change, because the API will still be doing exactly the same thing. | |
| 13:46:43 | edleafe | It's a teeny behavior change, but a real edge of an edge case | |
| 13:47:28 | efried | How would it be a behavior change? You're just changing the condition from "if the record doesn't exist, assume null/null" to "use what's in the record, which will always be there (oh, and btw, might be null)" | |
| 13:47:28 | edleafe | here's the case: | |
| 13:47:41 | mriedem | dansmith: i saw, but haven't dug into the changes yet | |
| 13:47:50 | dansmith | mriedem: okay just wanted to make sure you did | |
| 13:47:56 | edleafe | allocations are created <1.8. No consumer record in the past; now there is w/generation=0 | |
| 13:48:15 | efried | dansmith, mriedem: You'll be delighted to know that I checked our OOT driver, and you don't break it with that change. | |