| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-04 | |||
| 10:14:41 | kashyap | Topic of it: [RFC] Pick next minimum libvirt / QEMU versions for "Stein" | |
| 10:15:10 | johnthetubaguy | kashyap: ah right, I usually let distro people argue that one out, good to have the discussion though! | |
| 10:15:22 | kashyap | Yeah, I did an hour's sleuthing and wrote a new email | |
| 10:15:39 | kashyap | But `postfix` isn't letting me send it to openstack-{dev,operator} lists | |
| 10:20:57 | johnthetubaguy | kashyap: your libvirt version looks too new for Debian, did I miss something there? | |
| 10:21:18 | kashyap | johnthetubaguy: I know, this morning I even spent time on #debian-backports | |
| 10:21:44 | kashyap | johnthetubaguy: The discussion was: | |
| 10:21:45 | kashyap | asked: | |
| 10:21:45 | kashyap | I also talked on #debian-backports IRC channel on OFTC network, where I | |
| 10:21:46 | kashyap | libvirt 3.2.0 and QEMU 2.9.0, even if via a different repository. | |
| 10:21:46 | kashyap | "What I'm essentially looking for is: "How can 'stretch' users get | |
| 10:21:48 | kashyap | As they are proposed to be least common denominator versions across | |
| 10:21:50 | kashyap | distributions." | |
| 10:21:53 | kashyap | And two people said: Then the versions from 'Buster' could be backported | |
| 10:21:55 | kashyap | to 'stretch-backports'. The process for that is to: "ask the maintainer | |
| 10:21:58 | kashyap | of those package and Cc to the backports mailing list." | |
| 10:22:15 | johnthetubaguy | why 3.2 not 3.0.0? | |
| 10:22:28 | johnthetubaguy | well, and 2.9 rather than 2.8? | |
| 10:23:28 | johnthetubaguy | totally not against better stretch-backports, sounds like a good plan either way | |
| 10:24:01 | kashyap | johnthetubaguy: That is possible, actually -- to accomodate 'Stretch' | |
| 10:24:13 | kashyap | To use 3.0.0 and 2.8 | |
| 10:24:30 | johnthetubaguy | its not a ... stretch (giggles like a school boy) | |
| 10:24:57 | kashyap | But we should remember that 3.2.0 and 2.9 are already much older | |
| 10:25:02 | kashyap | Hehe | |
| 10:25:08 | kashyap | johnthetubaguy: Did you also catch the email -- http://lists.openstack.org/pipermail/openstack-operators/2018-March/015067.html | |
| 10:25:20 | kashyap | Where I actually called out the Debian thing, and asked people to chime in | |
| 10:26:26 | johnthetubaguy | cool, seems like a step too far to exclude Debian, but its good to ask | |
| 10:26:44 | kashyap | Yeah, exactly. I *don't* want to exclude it | |
| 10:26:58 | kashyap | That's why I even spent an hour or two talking to the upstream Debian folks on OFTC | |
| 10:27:12 | kashyap | Just to see what could be done; since we can get rid of backward-compatibility code | |
| 10:31:17 | johnthetubaguy | kashyap: so can't we do the bump to 1.3.1 and 2.5.0 now ish? | |
| 10:31:48 | kashyap | johnthetubaguy: Yes, we can; that's what I'm working on. | |
| 10:32:05 | kashyap | > As it stands, during the "Pike" release the advertized NEXT_MIN versions | |
| 10:32:08 | kashyap | > were set to: libvirt 1.3.1 and QEMU 2.5.0 -- but they weren't actually | |
| 10:32:11 | kashyap | > bumped for the "Queens" release. So they will now be applied for the | |
| 10:32:14 | kashyap | > "Rocky" release. | |
| 10:32:19 | kashyap | johnthetubaguy: I think that's what you were referring to | |
| 10:32:29 | johnthetubaguy | kashyap: yeah, totally, just I would +2 that one | |
| 10:33:01 | kashyap | Yeah, it requires going through the whole codebase removing conditional cruft, etc. And fix relevant unit tests | |
| 10:33:11 | kashyap | Will post here once I'm ready in a bit | |
| 10:33:25 | johnthetubaguy | true... well there are two changes, the bump then the removal, depending on how you look at it :) | |
| 10:33:55 | johnthetubaguy | anyways, glad you are pushing on that, sounds worthwhile to me | |
| 10:39:35 | kashyap | johnthetubaguy: Yeah; there are multiple changes | |
| 10:39:45 | kashyap | Just bumping it won't magically pass everything, would it? :-) | |
| 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. | |