Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-02
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 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:45:38 cfriesen mriedem: https://docs.openstack.org/neutron/pike/admin/config-macvtap.html and https://bugs.launchpad.net/neutron/+bug/1550400
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?
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/

Earlier   Later