Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-09
15:47:10 efried in the future we want to "prefer" hosts that have an accel with the desired bitstream already on them. In that case the placement request would us preferred=BITSTREAM_XXX. But we don't want to expose trait:BISTREAM_XXX=preferred in the flavor extra specs.
15:47:13 dansmith efried: are you saying that if cyborg represented possible devices that could be composed by programming a, say, gzip bitstream into a fpga as a resource in placement that asking for that thing would cause you to get one?
15:47:14 efried kind of thing.
15:47:41 sean-k-mooney well vgpus is a example of Resources:vGPU=1 haveing an effect of actully provision a gpu for the guest
15:47:46 dansmith that's maybe a next-level leap from what I'm saying,
15:48:03 dansmith but it's also a much more user/ops-friendly way of stitching high level functions together
15:48:37 dansmith i.e. instead of plugging low-level nova into low-level cyborg, you define an abstract thing in cyborg which becomes a high-level resource in nova that you just ask for by symbolic name,
15:48:46 efried YES
15:48:47 dansmith which is more what I think we should be shooting for, compared to the former
15:49:19 dansmith you say YES, but I feel like you were arguing NO a minute ago, so I'm confused
15:50:01 efried Today the way we model resources in placement is very similar to the way nova thinks of them
15:50:09 sean-k-mooney how about this. for the mix cpu case. we could say that if you do VCPU:2,PCPU:6 we will generate the topogy for you but you can override it with hw:gust_pinned_cpus
15:50:13 efried so just understanding placement syntax is enough
15:50:50 sean-k-mooney but you could just set hw:guest_pinned_cpus too
15:51:05 efried but very soon (numa modeling, cyborg) we will have to model in placement in ways that are less intuitive
15:51:40 efried if we continue to support placement-ese in that future, it will required the user to understand that extra translation
15:51:49 efried I'm just suggesting we hide that translation in nova.
15:52:14 dansmith but then we have to invent syntax for everything no?
15:52:29 efried we already have that syntax
15:52:33 sean-k-mooney no only if we want to expose contol over that translation
15:53:06 dansmith efried: we've already invented new syntax for "please include me an accelerator by the name of X"
15:53:39 dansmith efried: if that was a placement resource, we wouldn't have had to do that, but we did and now sundar is inspecting internal flavor details of this bespoke syntax everywhere
15:53:59 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Add recreate test for bug 1855927 https://review.opendev.org/701756
15:53:59 openstack bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,In progress] https://launchpad.net/bugs/1855927 - Assigned to Matt Riedemann (mriedem)
15:53:59 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Ensure source service is up before resizing/migrating https://review.opendev.org/701757
15:54:29 dansmith efried: and we will have to invent new syntax when we want to ask it to be hung on a specific numa node I think too right?
15:54:44 dansmith so we'll have two unique things for accelerators: which one and how to attach
15:54:48 sean-k-mooney dansmith: well that would only work if each resouce class is only owned by 1 project
15:55:10 sean-k-mooney nova already "owns" the VGPU resouce class
15:55:26 dansmith wat
15:55:46 sean-k-mooney so that would mean we woudl have to have a seperate CYBORG_VGPU resouce class for cyborg manged VGPUs
15:55:57 efried naw
15:56:07 dansmith we're assigning ownership of *classes* now?
15:56:08 efried per-project ownership is at the RP level.
15:56:09 sean-k-mooney dansmith: to use the vgpu support in nova today you set resouce:vgpu=1
15:56:17 dansmith I thought only instances of RPs were owned
15:56:21 efried ^
15:56:21 dansmith yeah what efried said
15:56:47 openstackgerrit Merged openstack/nova master: Do not reschedule on ExternalNetworkAttachForbidden https://review.opendev.org/694179
15:56:53 openstackgerrit Merged openstack/nova master: nova-net: Remove firewall support (pt. 3) https://review.opendev.org/700511
15:56:56 sean-k-mooney well yes but how would you know in the resouce:vgpu=1 if libvirt or cyborge shoudl handel that request
15:57:00 openstackgerrit Merged openstack/nova stable/rocky: Add functional recreate test for bug 1852610 https://review.opendev.org/698108
15:57:00 openstack bug 1852610 in OpenStack Compute (nova) rocky "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Medium,In progress] https://launchpad.net/bugs/1852610 - Assigned to Matt Riedemann (mriedem)
15:57:05 openstackgerrit Merged openstack/nova stable/rocky: Add functional recreate revert resize test for bug 1852610 https://review.opendev.org/698110
15:57:34 dansmith sean-k-mooney: libvirt handles it in both cases eventually, but that's my point about all of this
15:57:55 dansmith sean-k-mooney: we should have the user ask for what they want, not what they want how they think it's plumbed today
15:58:07 dansmith because if we move vgpu handling completely to cyborg in the future,
15:58:22 dansmith the syntax shouldn't have to change, the users shouldn't have to know how the cloud is doing that behind the scenes, etc
15:58:32 dansmith we're supposed to be an abstraction, not just an API
15:58:53 sean-k-mooney yes i agree with that in principal. and yes libvirt will provide it in either case where it is invetoried by the livbrit driver or cyborg
15:59:48 efried Yes, we had to invent syntax for cyborg, and we'll have to extend existing syntax for numa. IMO that's not a bad thing.
15:59:48 efried IF we could reasonably use placement syntax for everything, that would be okay, but that is not going to be possible.
15:59:48 efried So we're going to need the snowflake syntax no matter what.
15:59:48 efried So when it comes to choosing between using placement syntax in an awkward way, or inventing a new fit-for-purpose custom syntax, I vote for the latter.
15:59:48 efried Currently we have ways to use the placement syntax mostly-not-awkwardly, which is where we're conflicting.
15:59:50 sean-k-mooney part of the proably however was if i wanted 2 fpga with differet bit stream i might need to select different devices to be compatible
15:59:59 efried I feel like we're repeating at this point.
16:00:05 efried I need to run to a meeting. BBIAB
16:00:55 sean-k-mooney that 2 devices with different requirements lead to the need for use to model each request as a seperate request group with different traits
16:00:56 dansmith sean-k-mooney: right, today that will add a third permutation of the cyborg syntax to my point above
16:01:18 sean-k-mooney so it would force the grouping syntax if we jsut use the placeemtn stuff directly
16:01:39 sean-k-mooney well not on the nova side it woudl jsut eb 2 device profiles
16:01:48 sean-k-mooney but yes i could
16:02:03 dansmith sean-k-mooney: I'm saying today there is only one flavor key which is "_the_ device profile" in cyborg
16:02:16 sean-k-mooney yes
16:02:22 dansmith if you need to add more in the future, like we will for hot-attach, then we'll be adding something _else_
16:02:34 sean-k-mooney ya
16:04:15 sean-k-mooney i know its not a sexy thing but i kind of do feel like maybe next cycle it would be good to try and rationalise this and write down how we envision this evolveing
16:05:14 sean-k-mooney e.g. taking all the feature we have like this and trying to express them in with placement for resouces and hw:* for tweeks ectra and see what that looks like
16:06:13 sean-k-mooney at lest when it comes to numa i think we need to do that for cpus and memory before doing numa in placmenet
16:08:36 dansmith there goes sean-k-mooney promising to do stuff "next cycle" :)
16:08:50 dansmith but yes, I thought we were a lot more unified on the plan obviously
16:09:06 dansmith and after this conversation, it feels more like "eff it, just invent new stuff each time"
16:13:29 openstackgerrit Victor Coutellier proposed openstack/nova-specs master: Non-admin user can filter their instances by AZs https://review.opendev.org/701763
16:13:59 alistarle Hi, I was waiting for the #open-discussion part of the meeting but seems there was not today
16:14:09 alistarle I have reported a blueprint about the ability for non admin to filter server by availability zone, I was very surprised that it is an admin only one : https://blueprints.launchpad.net/nova/+spec/non-admin-filter-instance-by-az
16:15:10 alistarle @efried review my code and suggest me to talk about it in the meeting today, in case there will need a spec for that, but waiting for the open discussion I have written the spec :)
16:18:00 dansmith alistarle: if it's an api change, then it needs to be a spec
16:18:46 alistarle It is not really an api change, as everything are already available, it is just about allowing non-admin user to do something restricted to admin
16:18:48 dansmith alistarle: az is a thing that is exposed to users in general, so filtering on it is probably okay, but some thought will need to be given because of things like cells
16:19:33 alistarle But thanks, at least I have not wrote the specs for nothing ;)
16:19:33 dansmith oh I see
16:20:46 dansmith I'm still not sure it doesn't require a microversion bump, fwiw
16:20:49 alistarle That's why in the code, @efried was not sure about requiring a new microversion or not, as it does not really change something in the API
16:21:24 dansmith gmann: ^
16:22:07 alistarle I agree with you, in my opinion it is not required
16:22:13 melwitt hm, I'd have thought that would just be to add a new policy item, not a need a new microversion
16:22:28 dansmith melwitt: well, looking at the code around the change, I dunno
16:22:45 alistarle There is already a policy item available, as explained in the alternative in the specs, for it does not really fit the needs
16:22:48 dansmith the way non-admin search params are handled, everything is very specific
16:23:21 dansmith melwitt: also, unless the user gets a 401 when they try to use it now, a microversion is the only signaling method that they can expect it to work
16:23:21 alistarle Or it fit too much the need I would say ^^
16:24:37 dansmith alistarle: your assertion that policy changes during upgrade are hard is no longer valid, I think,
16:24:47 dansmith since the policy file is just what you want to change, not the full list
16:24:53 dansmith and if it is, your vendor is doing it wrong
16:25:15 alistarle Hmm ok fine, but what about giving too much right to customer ?
16:25:48 dansmith I'm not sure what that means
16:26:09 alistarle They can filter on everything then, not only AZ
16:26:09 melwitt oh, hm. when os_compute_api:servers:allow_all_filters was added it wasn't a new microversion https://github.com/openstack/nova/commit/7c56588647be64a2248b1f37d40369765bc6b977 and I thought you couldn't otherwise know to expect it to work
16:26:30 alistarle And I really think some filter must stay admin only by default

Earlier   Later