Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-07
13:50:40 openstackgerrit ya.wang proposed openstack/nova master: Select cpu model from a list of cpu models https://review.openstack.org/637834
13:50:58 gibi nova meeting starts in 9 minutes on #openstack-meeting
13:50:59 mriedem server group member quota is enforced at the user, not project, level
13:51:22 mriedem jaypipes: https://github.com/openstack/nova/blob/master/nova/quota.py#L1075
13:52:42 bauzas any urgent code review before FF ?
13:52:53 bauzas I looked at the etherpad, but it's a bit messy :(
13:53:10 mriedem it is yes
13:53:14 bauzas disclaimer: long series can't be honestly reviewed
13:53:17 mriedem i'm just trying to sort out the index question on https://review.openstack.org/#/c/633349/
13:53:28 jaypipes good lord that is an expensive quota check :(
13:53:45 mriedem i don't know if we'll try to merge part of this instance mapping user_id series or not
13:54:00 mriedem it's getting to be too late to be having these types of questions
13:54:18 bauzas mriedem: do you want some other eye's lookup ?
13:54:59 bauzas I saw this series in the etherpad, but I was thinking it was a bit difficult to review it by only 6 hours
13:55:08 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Boot a VM with an unaddressed port https://review.openstack.org/641670
13:55:16 mriedem the bottom 4-5 changes have had a lot of review from me and dansmith actually
13:55:30 bauzas there is a -W from melwitt, can we still review ?
13:55:40 jaypipes mriedem: is there a technical reason why we couldn't still filter by project as well as user on that server group members quota query?
13:55:52 mriedem bauzas: that was procedural while waiting for approval of the changes above
13:55:54 jaypipes (seems like it's just a mistake in the original code)
13:56:04 bauzas mriedem: okay, then I'll look
13:56:41 mriedem jaypipes: i don't think it's an oversight
13:56:55 jaypipes mriedem: why not?
13:57:03 mriedem anyway, i wouldn't want to have to go down that rathole on FF
13:57:10 jaypipes ack
13:57:48 mriedem i'd have to dig into when server group member quota was added
13:57:57 mriedem we do have some per-user quota checks on purpose,
13:57:59 mriedem like keypairs i think
13:59:19 mriedem efried: https://review.openstack.org/#/c/637234/ is merged now if you want to start a novaclient release, or after the meeting
13:59:33 efried argh, meeting, thanks for the reminder.
13:59:38 efried mriedem: was just starting the release.
14:01:00 jaypipes mriedem: I understand the keypairs being user_id-specific. not so much the server groups one.
14:09:10 efried mriedem: So microversion parity changes don't count as major bump-worthy?
14:09:32 mriedem efried: no, since they are opt-in features
14:09:39 mriedem major is for backward incompatible changes
14:09:43 efried okay.
14:09:45 mriedem semver baby
14:10:12 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Boot a VM with an unaddressed port https://review.openstack.org/641670
14:18:53 mriedem yikun: efried: i saw yikun posted a topic proposal for nova/cyborg integration https://etherpad.openstack.org/p/DEN-train-nova-brainstorming - question is if that should be a forum or ptg session? it might be fine to have both.
14:19:12 mriedem forum session to lay out the goals/requirements and ptg session to talk about design/implementation details
14:19:38 mriedem i know our product team wants to focus on fpga integration with nova but it sounds like upstream cyborg team is talking more about gpu support? which we already have in nova.
14:22:01 mriedem yikun so i'd be in favor of a forum session
14:22:15 efried The more the better as far as I'm concerned.
14:22:16 sean-k-mooney mriedem: for what tis worth fpga integration with openstack is 1 already possible via pci passthrough and 2 on our products teams wishlist too to do without relying on pci passthouhg
14:22:53 efried though I'm kinda hoping to have the nova/cyborg integration design mostly agreed upon before Denver
14:23:04 efried since we already had it agreed upon after *last* Denver.
14:23:11 mriedem ok i guess i didn't know about #1, i only really ever hear about people using gpus
14:23:45 sean-k-mooney efried: by the way i think i have a path forward that jaypipes and you might like on one topic
14:23:50 efried mriedem: "Can do it with PCI passthrough" isn't a thing that should stop us doing stuff with cyborg. We've been trying to make PCI passthrough DIAF for years now. This is the opportunity to do that.
14:24:20 mriedem efried: sure, that's not my point
14:24:32 efried okay, sorry, I didn't get your point then
14:25:10 sean-k-mooney efried: when cyborg reprogams an fpga for mutiple tenatn. why dont we jsut create a child resouce provider form the otrgin device resouce provider with the new capablities listed as traits on the new RP and new invetores of the resouce it provides
14:25:25 efried sean-k-mooney: How does that help anything?
14:25:53 sean-k-mooney efried: we dont need to ever update the traits or resouce clases on the original RP
14:26:04 mriedem considering we'll be lucky to get *anything* of substance done wrt nova/cyborg integration, what is the biggest benefit of a new feature functionality we could add with that integration? gpus w/o passthrough or fpgas? we already have a lot of people using gpus with passthrough in nova, and we have vgpus, so it seems like fpga would be the bigger first "win" from an integration.
14:26:09 sean-k-mooney the orginal RP device inventory can be consumed by cyborg
14:26:41 sean-k-mooney and cyborge can create a dynamic child with the image capablities when its programed
14:26:57 efried how would the claim sequence work?
14:27:46 sean-k-mooney if you want ipsec ofload you make a resouce request for the ipsec class if you want a device you use a fpga device resource class
14:27:51 sean-k-mooney i can write something up
14:28:15 efried It sounds like a really complicated way to do the same thing as the existing design.
14:28:19 sean-k-mooney but basically you should be able to support both multi and singel tenant use of a device
14:28:28 efried for what benefit, preserving architectural purity?
14:28:34 sean-k-mooney efried: well we agreed to not update the rp in the existing desing
14:28:40 efried huh?
14:28:45 sean-k-mooney at least not in phase 1
14:29:13 efried Not to update its inventory, yes. But we agreed to use dynamic traits to signify bitstreams.
14:30:13 sean-k-mooney efried: yes which means if a bitstream can support 8 concurent consumer fo aes compression we agreed that you cannot create a new inventory to model that
14:30:42 edleafe efried: is "dynamic traits" a euphemism for "tracking state"?
14:30:55 sean-k-mooney without creating new inventories you cannot alleratiors that have mulit tenatn bitstreams
14:31:13 sean-k-mooney edleafe: more or less
14:31:41 edleafe sean-k-mooney: ugh, that's what it sounds like
14:31:43 efried mriedem: https://review.openstack.org/641678 <== python-novaclient release
14:31:48 sean-k-mooney edleafe: the suggestion was to tag the fpga RP with a CUSTOM_ trait for the bitstream it is programed with
14:32:23 edleafe sean-k-mooney: yeah, that was discussed and rejected a while ago. Looks like it's back from the dead.
14:32:23 efried we doing this again?
14:32:35 efried it was not rejected
14:32:41 efried It was not anyone's favorite
14:32:42 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor bandwidth related functional tests https://review.openstack.org/641679
14:32:58 sean-k-mooney efried: ya i know im not really objecting to it
14:33:15 sean-k-mooney efried: i just thing that there is a better way of modeling it
14:33:22 efried edleafe: but it was agreed upon (by which I mean "consensus" - i.e. not everybody cast an aye vote) as the lesser evil
14:34:05 mriedem efried: ack, will take a look after i'm back from the bus stop
14:34:15 sean-k-mooney efried: for what its worth we never discussed the model im now proposeing and i think jaypipes and other may like it and it will enable more usecase for cyborg to
14:34:51 smcginnis mriedem_afk, efried: Correct, no need to tag milestone beta's unless you know there are downstream consumers that could use it.
14:35:55 sean-k-mooney efried: would you like me to write up a more detailed proposal?
14:35:58 efried sean-k-mooney: We have been in analysis paralysis on this thing for too long. We need to make forward progress. The design as currently represented in the PoC is what we agreed on in Denver after discussing it at every PTG for the past two years. It is simple. It works. It would be counterproductive to try to redesign it yet again at this stage.
14:35:58 efried If a "dynamic child provider" model is really seen as far superior to this design, we can look at switching to it in U or later.
14:36:14 cdent sean-k-mooney, efried, edleafe: didn't we make a decision many months ago that we should just stick with, even if it isn't perfect?
14:36:33 efried this ^
14:36:37 efried because there is no perfect
14:37:08 sean-k-mooney for the record we also commited to having the poc working by m1 at the latest
14:37:53 edleafe cdent: I guess I don't remember a decision, just lots of back-and-forth discussion. Maybe it was in Berlin, and that's why I don't recall it?
14:38:33 cdent edleafe: not certain. I _think_ I'm remembering Denver.
14:38:58 efried sean-k-mooney: m1 of what? At this point we're proposing it for train, since stein has sailed. The PoC is ready now.
14:39:08 sean-k-mooney cdent: this discusstion predates teh creation of placement. at least my involvement in it does
14:39:38 cdent sean-k-mooney: then I think you've proving my point
14:39:40 sean-k-mooney efried: the poc was expected to be completed by m1 of stein
14:39:55 efried sean-k-mooney: if we were going to get it into stein, sure.
14:40:23 jaypipes mriedem: is it a 0% chance of getting the quota-in-placement series reviewed and merged today then? even if I take over the bottom patch? there's actually a lot of good in that series and it opens up much-needed refactoring and cleanup in Train if we can get it done (not to mention a simpler way of reasoning about quotas)

Earlier   Later