Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-04
10:03:07 kashyap Just trying to curb the "dragging on" of this
10:03:13 johnthetubaguy kashyap: its in my next tab :)
10:13:53 johnthetubaguy kashyap: you get my first +2 of the day, its a relief to actually +2 something!
10:14:04 kashyap johnthetubaguy: Haha
10:14:21 kashyap johnthetubaguy: Thank you! If your fingers are itching, here's another one: https://review.openstack.org/#/c/558171/
10:14:27 kashyap But it requires more discussion on the list
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

Earlier   Later