Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
21:31:01 melwitt oh, because it runs in a CI job
21:31:10 sean-k-mooney ya
21:31:23 sean-k-mooney its to make sure we dont backport stuff that breakes py27
21:31:36 sean-k-mooney that said all the unit tests are running under by 35
21:31:47 sean-k-mooney *py35
21:32:37 melwitt okay, since that's queens I think that's okay. if you want to do a release for an older stable branch, you can just propose it and let me know so I can ack it
21:33:01 melwitt smcginnis: can you sanity check me on that? ^
21:33:41 melwitt is it okay to release stable/queens for non-client libraries during freeze? is freeze only for rocky or for all branches?
21:34:12 sean-k-mooney well in this case its more to highlight the fact that there are some pendign stable/X backports and that im not sure if the nova stable team reguraly checks os-vif
21:34:29 melwitt pending as in, not merged?
21:34:39 sean-k-mooney yes
21:35:31 melwitt okay. just have to let people (stable cores) know to take a look if there's something important there
21:35:36 sean-k-mooney such as this one for pike from december that i proosed back in january and got a +2 from mriedem_afk 4 months ago https://review.openstack.org/#/c/531465/
21:37:03 smcginnis melwitt: Yep, that looks right. Freeze just applies to rocky work.
21:37:15 melwitt smcginnis++
21:37:31 sean-k-mooney i have core rights on master not the sable/branches so while i do flag pending backports to the nova sable team every now and then there is not much more i can do if they dont get reviewed
21:38:19 sean-k-mooney anyway there is nothing breakign the gate or that customer are screaming about that im aware of so just an FYI
21:39:53 melwitt sean-k-mooney: okay, thanks for letting me know. I'll see if I can find someone for the second +2s
21:46:01 openstackgerrit Merged openstack/os-vif stable/pike: Check if interface belongs to a Linux Bridge before removing https://review.openstack.org/531465
21:46:26 melwitt tonyb: fancy reviewing a os-vif backport to fix their tox py27 job? https://review.openstack.org/567942
21:47:29 tonyb melwitt: done
21:47:38 melwitt thank you sir
21:47:51 tonyb melwitt: no problem at all
21:54:55 sean-k-mooney tonyb: thanks.
21:55:50 tonyb sean-k-mooney: np. It's my very minor super power ;P
21:56:30 sean-k-mooney by the way looking at http://ci-watch.tintri.com/project?project=nova&time=7+days i do not see teh intel nfv ci. https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI has not been updated since febuary. anyone rememebr the last time they saw it comment on something?
21:56:35 openstackgerrit Merged openstack/os-vif stable/queens: fix tox py27 job https://review.openstack.org/567942
21:57:26 melwitt sean-k-mooney: can't remember. it's been awhile
21:58:35 sean-k-mooney i have been waiting for it to comment on some change i was doing to networking-ovs-dpdk... i guess ill jsut do the testing myself.
21:59:07 tonyb sean-k-mooney: If you really cared to find out you could add the notes ref to you nova repo and then grep the notes for a comment from that CI
21:59:15 tonyb it *might* work
22:00:03 sean-k-mooney tonyb: oh? im not sure i follow
22:00:45 tonyb sean-k-mooney: gimme 5 to find a link
22:00:51 sean-k-mooney as in a gerrit query for a reviewer?
22:01:18 tonyb sean-k-mooney: Oh you could do that as well
22:01:47 melwitt oh yeah, good idea
22:02:11 tonyb sean-k-mooney: So looking at https://git.openstack.org/cgit/openstack/nova/commit/?id=2499f616094f63ed0a1a3c201789d14cc61a62c4
22:02:43 tonyb 'notes' get added to each review based on code-reviews. they're in a seperate ref
22:03:09 tonyb so you can just add that ref to your nova repo and then when you do git show on a SHA you'll get to see the reviewers
22:03:25 tonyb so the CI votes (but not comments) would be included.
22:04:34 tonyb https://review.openstack.org/#/q/reviewedby%3Aintel-nfv-ci
22:04:46 tonyb look slike it's still voting
22:05:58 sean-k-mooney maybe what does exception meen next to a ci comment https://review.openstack.org/#/c/584829/
22:06:44 tonyb sean-k-mooney: Oh it means it's voting but not doign anythign helpful ;P
22:07:35 sean-k-mooney ah it makes perfect sense lol
22:07:56 tonyb ;p
22:08:17 tonyb sean-k-mooney: Let me see if I can find the last time it voted +1
22:10:26 tonyb sean-k-mooney: Nope my gerrit fu is weak right now. I'll grab some coffee and try again
22:11:12 sean-k-mooney well looking at the log server it has not uploaded anything sice the 18th http://52.27.155.124/portland/2018-07-18
22:13:48 sean-k-mooney tonyb: thanks for trying in anycase. i might reach out and ask what the status is.
22:20:34 openstackgerrit Takashi NATSUME proposed openstack/nova master: Reno for notification-transformation-rocky https://review.openstack.org/588403
22:35:28 melwitt lbragstad: sorry for the delayed reply, but yeah what I was thinking was to look at migrating to keystone limits in stein, not yet going for the enforce part. johnthetubaguy had also mentioned that a two-stage approach to the migration might make migration easier from an operator perspective but I didn't understand that bit
22:38:43 melwitt we have other work we'd like to do like be able to set quota limits for custom resource classes and where we're at right now, we could do that via our existing quota classes API, but then that will leave more to have to migrate to keystone limits when we move. so I was thinking maybe we should move to keystone limits first, then let the limits piece of custom resource class quotas be covered by unified limits, and all we do on our
22:38:43 melwitt side is the enforce with what we already have. then next stage will be to move to oslo.limit for enforcement
22:43:20 lbragstad interesting melwitt
22:43:46 lbragstad so - you'd query keystone directly for limit information as opposed to using oslo.limit?
22:44:24 melwitt yeah. I actually didn't know the limit query was supposed to go through oslo.limit. if it does, we could do that, I just missed it or forgot
22:44:56 melwitt or are you saying limit + enforce are coupled?
22:45:01 melwitt in oslo.limit
22:45:04 lbragstad technically - it probably doesn't _have_ to go through oslo.limit, but that's where we were going to hide all the logic that understands the project tree
22:45:12 melwitt right okay
22:45:18 tonyb sean-k-mooney: Ahh when it votes it doens't actually 'vote' it just leaves a comment so it's back to groveling in the review metadata :(
22:45:44 lbragstad melwitt: i'm trying to map terms, but i was under the assumption that enforcement would be a requirement?
22:45:49 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927
22:45:50 openstackgerrit Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033
22:45:51 openstackgerrit Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598
22:45:52 openstackgerrit Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599
22:45:53 openstackgerrit Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648
22:45:54 openstackgerrit Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034
22:45:55 openstackgerrit Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049
22:45:56 openstackgerrit Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236
22:45:57 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Remove redundant _update()s https://review.openstack.org/588091
22:46:15 lbragstad if not - then it sounds like something we can build into oslo.limit or consider supporting (since it's the thing raise exceptions to the service)
22:46:26 melwitt lbragstad: it is, sorry. I mean whether it's one call or two calls in oslo.limit to do limits vs enforce
22:46:49 lbragstad oh - the thing that protects against race conditions?
22:47:21 melwitt sorry, I think I'm confusing things and I haven't looked at the POC code in awhile
22:47:46 lbragstad the skeleton of oslo.limit has that implemented in the context manager https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L60-L62
22:48:06 melwitt ah, yeah I remember now
22:48:13 lbragstad https://github.com/openstack/oslo.limit/blob/master/oslo_limit/tests/test_limit.py#L96 probably helps visualize things a bit, too
22:48:22 lbragstad from a usage perspective anyway
22:49:31 melwitt thanks
22:49:37 lbragstad this stuff will get implemented soon, since this is where the code the calculates the limits wrt the tree https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L81-L85
22:49:57 lbragstad (implementation detail of the context manager though)
22:49:58 melwitt and that will also pull the limits from keystone?
22:50:07 lbragstad yep - exactly
22:50:32 lbragstad when you enter the context manager, it should query keystone for the limits and do calculations based on the claims your making
22:50:51 melwitt ah, I see. I think I jumped the gun then. for some reason I was thinking we could move to using keystone limits only, as a first step, and then start doing the oslo.enforcement in a second separate step
22:50:52 lbragstad then __exit__ will do error handling in the event there was a race condition and verify = True
22:51:00 melwitt from a project perspective
22:51:05 lbragstad aha - sure
22:51:16 lbragstad hopefully it's only one step for you
22:51:29 lbragstad (unless there is a good reason to break things up a bit?)
22:51:44 melwitt no, I don't think there is. just ignorance on my part
22:51:55 lbragstad it's a lot of moving pieces =/
22:52:04 melwitt yeah, for sure
22:52:26 lbragstad we were waiting on an APi to return the project heirarchy with limit data associated to it (landed in rocky)
22:52:50 lbragstad now that's in, we can start working on finishing up the implementation of that context manager
22:52:59 lbragstad (i'm hoping to start that soon)
22:53:09 melwitt on our side we have to decide whether to go ahead with the custom resource classes quotas by using our own quota classes API or wait for oslo.limit
22:54:11 lbragstad i can bump the oslo.limit impl up on my priority list if it helps give you all a definitive direction

Earlier   Later