| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-02 | |||
| 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 | |
| 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 | side is the enforce with what we already have. then next stage will be to move to oslo.limit for enforcement | |
| 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: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 | |