| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-02 | |||
| 19:54:10 | mriedem | well, there are plenty of "if wrs-header: do extra stuff" | |
| 19:54:30 | mriedem | but yeah, input validation on the api schema i guess | |
| 19:54:31 | mriedem | nixes that | |
| 19:54:44 | mriedem | also, all of this cpu cache stuff... | |
| 19:54:48 | mriedem | i can't wrap my head around this | |
| 19:55:21 | openstackgerrit | Merged openstack/nova master: Fix all invalid obj_make_compatible test case https://review.openstack.org/574240 | |
| 19:55:58 | cfriesen | mriedem: the live migration stuff came out of a live customer issue, as I recall they wanted a quick fix that was backportable to an earlier release. | |
| 19:56:17 | cfriesen | The CPU cache stuff...I think that's the Intel CAT stuff. | |
| 19:56:58 | cfriesen | equivalent to this: https://blueprints.launchpad.net/nova/+spec/cat-support | |
| 19:59:32 | mriedem | ok, not much in there - no spec proposed it looks like | |
| 20:02:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Scrub hw:cpu_model from API samples https://review.openstack.org/588371 | |
| 20:03:39 | mriedem | sw:wrs:srv_grp_messaging huh | |
| 20:06:45 | cfriesen | you can probably ignore the server group messaging stuff...it's probably getting removed | |
| 20:06:52 | mriedem | jesus, ok, so servers within the same group can send messages to each other through a channel on the host? | |
| 20:07:14 | cfriesen | yeah, the idea was to have a low-bandwidth really easy way to message other serves in the group | |
| 20:07:26 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures https://review.openstack.org/584593 | |
| 20:07:29 | cfriesen | ended up being more hassle than it was worth | |
| 20:07:38 | mriedem | who. would. have. thought. | |
| 20:07:49 | cfriesen | but we use the same host/guest backchannel for the cpu scaling code | |
| 20:07:56 | cfriesen | :) | |
| 20:07:59 | mriedem | i see that | |
| 20:08:26 | cfriesen | doing it now, cpu scaling would use virtio-vsock | |
| 20:08:30 | mriedem | was that server group thing only for affinity groups? | |
| 20:08:45 | mriedem | it would have to be right? | |
| 20:08:46 | mriedem | on the same host | |
| 20:09:02 | cfriesen | no, it would send the message back to the controller to redistribute to other compute nodes | |
| 20:09:07 | mriedem | oh right, | |
| 20:09:11 | mriedem | forgot the rpc cast | |
| 20:33:45 | mriedem | cfriesen: where does upstream nova actually support live migration with macvtap pci devices? i don't see anything specific about hat | |
| 20:33:47 | mriedem | *that | |
| 20:34:45 | mriedem | https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-6c3b14d3964eb808ade9d3e7c5d4676dR104 | |
| 20:45:38 | cfriesen | mriedem: https://docs.openstack.org/neutron/pike/admin/config-macvtap.html and https://bugs.launchpad.net/neutron/+bug/1550400 | |
| 20:45:38 | openstack | Launchpad bug 1550400 in neutron "Macvtap driver/agent migrates instances on an invalid physical network" [Medium,In progress] - Assigned to Andreas Scheuring (andreas-scheuring) | |
| 20:48:52 | mriedem | hmm, that's marked in progress | |
| 20:48:55 | mriedem | does it actually work? | |
| 20:49:27 | mriedem | oh i see, | |
| 20:49:36 | cfriesen | According to the first link, "Instance migration requires the same values for the physical_interface_mapping configuration option on each compute node." | |
| 20:49:38 | mriedem | huh does that rely on the migrating_to attribute we set in the port binding dict during live migration? | |
| 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? | |