Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
20:50:06 cfriesen no clue...you'll see our code comment says macvtap isn't supported in Titanium Cloud
20:50:13 cfriesen I haven't played with it
20:50:40 mriedem yup i saw that
20:50:55 mriedem that limit on servers per group is also a bit strange,
20:51:00 mriedem given we have the server_group_members quota
20:51:11 mriedem which is global unless you override it per tenant i think?
20:51:54 mriedem oh i guess server_group_members is per user
20:51:59 cfriesen per group
20:52:15 cfriesen oh, you mean the quota
20:52:38 mriedem yeah
20:52:52 cfriesen we're getting rid of the server group size I think, trying to align with upstream
20:53:05 mriedem well i was just thinking of alternatives there,
20:53:18 mriedem i.e. you could limit the max members per group using quota which can be overridden
20:53:35 mriedem so your high $$ users get higher quota
20:53:39 melwitt nova meeting in 7 minutes
20:53:56 openstackgerrit Eric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator https://review.openstack.org/588391
20:54:16 cfriesen originally we implemented it when server group metadata was still a thing, or looked like it would be a thing.
20:54:25 mriedem yeah, which was probably forever ago
20:54:56 mriedem so server groups are per-tenant, and then you can override the quota to say like user A in group 1 can have 4 members in a group and user B in group 1 can have 2
20:55:05 openstackgerrit Eric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator https://review.openstack.org/588391
20:55:12 mriedem user A in tenant 1 i meant
20:55:17 efried melwitt: Since you expressed interest, I tracked down a couple more --^
20:55:29 melwitt thanks
20:55:52 cfriesen mriedem: I thought we were getting rid of user quotas
20:56:09 mriedem that's news to me
20:56:23 mriedem oh, with moving to unified limits?
20:56:25 melwitt we've talked about it several times but people keep getting confused, I think
20:56:38 melwitt I think even unified limits added 'user' to their stuff because they thought we needed it
20:57:03 mriedem :/
20:57:13 melwitt we "need" user only if we want to keep the legacy stuff the way it has been, going forward
20:57:26 cfriesen I mean, servers are owned by projects so it seems weird that some users would be able to make new ones and others in the same project wouldn't.
20:57:46 mriedem cern needed user-level quota for working around nova not having hierarchical quota support, iirc
20:58:05 melwitt yeah, that is my understanding as well
20:58:20 mriedem does unified limits give us hierarchical quota support?
20:58:21 melwitt it was a hack to get two level hierarchical
20:58:24 mriedem i thought it was just part of the puzzle
20:58:39 melwitt yes, that's what the keystone team is working on
20:58:53 sean-k-mooney cfriesen: users can have multiple project however so you may want to have per project limits and a limit for the user in general
20:58:58 mriedem w/o lbragstad or someone from keystone actually working on the nova changes, i don't know if/when that will ever get done in nova
21:00:14 melwitt I'm interested in working on it. I've been attending the unified limits and hierarchical sessions at PTG/summits. I added an item for the Stein PTG etherpad about unified limits, if we think we're ready to move to them for the limit piece
21:01:09 mriedem melwitt: you'd probably be best to lead that given your work on the quota stuff
21:01:36 sean-k-mooney melwitt: its been a topic for a few releases on and off right? do you see any obvious blockers?
21:01:37 lbragstad fwiw - the implementation for strict-two-level landed in keystone this release, so that's done
21:02:20 lbragstad we're still working on some changes for the oslo.limit library though (we need to implement support for querying keystone for limits and doing the math)
21:02:41 lbragstad ^ that's really the last bit before people can start incorporating it into their services
21:02:59 sean-k-mooney lbragstad: i would guess nova will have some requirement that other project wont have related to cells
21:03:15 lbragstad yeah - i would agree
21:03:30 lbragstad and i'm curious to flush those out as we go
21:04:19 lbragstad i assume that's going to have an impact on implementing unified limit support for instances, yeah?
21:05:03 sean-k-mooney lbragstad: ya there are some edge case to knowing if you are at or below quota if connect to a cell goes down
21:05:38 lbragstad huh - interesting
21:05:53 sean-k-mooney it would be similar to the problem you would have with keysone federattion if you lost the connection to a remote cloud and contiued to consume resoces on the local cloud and then it came back
21:06:10 lbragstad oh - sure
21:06:32 sean-k-mooney while the connect is broken you could exceed the gloabl limt. then the question is how to hanelit when you get the full view again
21:06:42 lbragstad right...
21:07:30 sean-k-mooney most other project dont shard there resocue view teh same way nova can with cells so ya im sure nova will find edgecases
21:07:34 lbragstad i guess the way we've been thinking about that (originally something sdague thought of)
21:07:59 lbragstad was to just keep things as they are, reject new claims, and give the user an opportunity to clean things up or escalate to an administrator
21:08:59 sean-k-mooney ya that seams like the sane think to do atleast at first until operator start telling us to do something else
21:15:55 mriedem cfriesen: heh https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-1aca090de4ab90afbc1c8d84b13a56f7R478 - i think that is one condition too late :)
21:16:03 mriedem by the time that runs, i think we've already dos'ed neutron
21:26:26 sean-k-mooney melwitt: quick question regardign os-vif stable releases. do you make them when you make sable release of nova?
21:27:23 melwitt sean-k-mooney: usually yes. around and after the third milestone is different because of the release freezes
21:28:04 melwitt IIUC, we are frozen from doing stable/rocky releases until stein opens
21:28:26 sean-k-mooney melwitt: ok there are a few test/tox fixes that would be nice to backport but nothing functional
21:29:32 melwitt sean-k-mooney: I see. I actually requested a FFE for the noop plugin loading bug that got approved, so I released 1.11.1 from the stable/rocky branch recently
21:29:40 sean-k-mooney like https://review.openstack.org/#/c/567942/ to run all of the py27 unit test instead of only a subset.
21:29:57 sean-k-mooney oh cool
21:30:42 melwitt I see. we can release stable/queens at any time, but I'm not sure how releasing the tox fix will help anyone? just needs to make it into the stable/queens branch right? for developers to benefit
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

Earlier   Later