| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-02 | |||
| 18:28:34 | mnaser | melwitt: they're pretty much both setting quotas, one handles the quotas that are extra_specs in flavor, the other one handles setting quotas that are from nova volumes | |
| 18:39:12 | melwitt | mnaser: I see. yeah, I dunno where the common method should go. utils seems like the place, as for LibvirtConfigGuestDisk I'd ask lyarwood or mdbooth (they are EU time zone) | |
| 18:45:16 | mriedem | cfriesen: there wasn't any upstream equivalent for this per-instance live migration max downtime feature was there? i know about https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html but that's for per-instance live migration timeout which is different. | |
| 18:53:51 | openstackgerrit | Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927 | |
| 18:53:52 | openstackgerrit | Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033 | |
| 18:53:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598 | |
| 18:53:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599 | |
| 18:53:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648 | |
| 18:53:56 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034 | |
| 18:53:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049 | |
| 18:53:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 18:53:59 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: only _init_compute_node on startup https://review.openstack.org/588094 | |
| 18:54:33 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Remove redundant _update()s https://review.openstack.org/588091 | |
| 19:03:39 | openstackgerrit | Merged openstack/nova master: Wait for vif plugging during live migration job https://review.openstack.org/578551 | |
| 19:03:48 | openstackgerrit | Merged openstack/nova master: Stop setting glance_api_version in cinder.conf in nova-live-migration https://review.openstack.org/579871 | |
| 19:03:55 | openstackgerrit | Merged openstack/nova master: doc: fix resize user guide link https://review.openstack.org/588097 | |
| 19:06:34 | openstackgerrit | Merged openstack/nova master: Hyper-V + OVS: plug vifs before starting VMs https://review.openstack.org/585661 | |
| 19:06:43 | openstackgerrit | Merged openstack/nova master: Complete the api-ref of security group rule https://review.openstack.org/580109 | |
| 19:31:36 | openstackgerrit | Eric Fried proposed openstack/nova master: Grease test_try_deallocate_network_retry_direct https://review.openstack.org/588364 | |
| 19:51:43 | cfriesen | mriedem: was having lunch. I don't think there's any upstream equivalent. I think that was added for existing pets that were created using flavor with too small of a max-downtime. I seem to recall discussing it upstream, but the concensus was that it would make more sense to add it as a parameter to the live-migration call. | |
| 19:52:31 | mriedem | cfriesen: that was exactly my question - why put it on the flavor/image rather than just directly in the live migration api | |
| 19:52:55 | mriedem | i guess because bigger flavors/images could need more downtime? | |
| 19:53:42 | cfriesen | mriedem: it was less code to do it this way, and no on-the-wire API change | |
| 19:54:01 | cfriesen | mriedem: it'd be cleaner as part of the migration request | |
| 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 | |