Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-24
14:52:01 bauzas efried: I just wanted to keep minimalistic changes to the alrady approved spec
14:52:12 bauzas efried: no, that's direct code
14:52:17 efried bauzas: I think I'm trying to say it should be described in *some* spec *somewhere*.
14:52:36 bauzas efried: I could amend https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html if you wish
14:52:41 efried I don't disagree we should minimize changes to a spec reapproval in theory, but this seems like something worth including.
14:52:49 efried bauzas: That would be okay too.
14:53:10 bauzas what I reallly want is possible quick approval
14:53:18 efried bauzas: swhy I didn't downvote :)
14:53:24 sean-k-mooney mdbooth: that will still not rebind the context on reconfigurtion
14:53:27 bauzas and then, if left comments, a possible follow-up
14:53:31 efried sure
14:54:10 bauzas efried: or I could amend https://review.openstack.org/#/c/602474 in a follow-up if you prefer
14:56:27 sean-k-mooney mdbooth: you will need to do somehtin like this https://stackoverflow.com/a/33507308
14:56:55 efried bauzas: There was some question (discussion with mriedem) as to whether these vgpu reshaper patches should be associated with the reshaper bp or the vgpu bp. I'm starting to think it's more appropriate to do the latter. The reshaper bp enables the work, but we're not going to go back and tag every future reshape impl against that same bp.
14:57:27 bauzas honestly, it's just a gerrit tag
14:57:31 bauzas so I don't really care
14:57:34 efried That being the case, IMO the text in question ought to go into https://review.openstack.org/#/c/602474 (the vgpu spec).
14:57:35 bauzas provided I have reviews :)
14:57:41 mdbooth sean-k-mooney: Ah, you're right
14:58:03 bauzas efried: fair, I'll write a follow-up
14:58:08 efried It's more than a gerrit tag. It feeds into being able to claim completion of a blueprint, etc.
14:58:24 bauzas I understand this but meh
14:58:52 bauzas either way, looks like it's a priority
14:59:12 sean-k-mooney mdbooth: ill submit the version with the flag for review. ill see if i can create a simple decorator after once the simple fix is up
14:59:31 efried bauzas: I'm not a spec core, so I can't approve it either way.
14:59:35 mdbooth sean-k-mooney: In lighter news, putting an emoji in a gerrit comment causes a 500 :)
15:00:14 bauzas efried: I know, but your comments are still valid
15:00:21 jaypipes melwitt, dansmith: do we actually support quota classes other than "default"?
15:00:33 sean-k-mooney hehe im not sure if that is a feature or a bug
15:00:39 dansmith jaypipes: I think no
15:08:01 melwitt jaypipes: we don't have anything in tree that uses anything other than "default" but if we were to wire it up, it would work. we've thrown around ideas of using them for things like preemptible instances but nothing has materialized yet. and alex_xu's "quota by resource class" proposed to leverage them if you've seen that spec
15:09:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consider allocations invovling child providers during allocation cleanup https://review.openstack.org/606050
15:11:01 jaypipes melwitt: well, the quota by resource class is different. quota *classes* are more templates of default limit values for the set of re
15:11:05 jaypipes gistered resource types.
15:11:22 jaypipes and highly coupled to RAX's turnstile middleware...
15:11:31 mdbooth sean-k-mooney: Actually I'm just going to abandon that patch. It's dumb and nothing like it can work.
15:12:15 melwitt jaypipes: I know, but if you read the spec, we could use them to set limits for resource classes in nova. but I don't think that's gonna happen because people would rather wait until we move to keystone limits and oslo.limit
15:12:18 mdbooth sean-k-mooney: At least sed's feelings won't be hurt.
15:12:47 jaypipes melwitt: ack
15:13:35 bauzas dansmith: based on the numerous feedback, could you please review https://review.openstack.org/#/c/602474/ ? I'll provide a follow-up on some efried's details
15:13:44 bauzas it's a re-approval
15:14:38 sean-k-mooney mdbooth: well https://stackoverflow.com/a/33507308 will work because i wrote it specically for doing this kind of thing but ya lets just stick with the simple fix until it breaks
15:16:07 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924
15:16:20 bauzas efried: just fixed the typo you mentioned ^
15:16:30 bauzas thanks for the review
15:16:40 efried bauzas: But just one of them :)
15:17:09 dansmith bauzas: I'll add it to the queue
15:17:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Add restrictions on updated_at when getting migrations https://review.openstack.org/607798
15:17:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Document restrictions on changes-since/before when listing servers https://review.openstack.org/613070
15:17:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Add restrictions on updated_at when getting instance action records https://review.openstack.org/607801
15:17:16 mdbooth sean-k-mooney: However, I think I didn't demonstrate that mechanically updating all uses of placement_context_manager() is pretty easy.
15:17:27 mdbooth s/didn't/did/
15:17:33 mdbooth That was a weird typo
15:20:07 sean-k-mooney mdbooth: ya i suspected that woudl be easy to do but getting the new decorator correct is the tricky bit. anyway the more i talk about the less time i spend doing it ill have the patch up in a ffew minutes
15:25:09 bauzas dansmith: heh, np
15:50:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reject forced move with nested source allocation https://review.openstack.org/605785
15:50:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consider allocations invovling child providers during allocation cleanup https://review.openstack.org/606050
15:50:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Handle allocations consuming only from the child RPs https://review.openstack.org/608298
15:50:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Run negative server moving tests with nested RPs https://review.openstack.org/604125
15:51:34 gibi mriedem, efried, jaypipes: I have fixed up the use-nested-allocation-candidates series ^^
15:53:00 efried gibi: Cool, I'm sure it's perfect now.
15:53:11 openstackgerrit Matt Riedemann proposed openstack/python-novaclient stable/rocky: Follow up "Fix up userdata argument to rebuild" https://review.openstack.org/613086
15:53:33 gibi efried: :)
15:56:13 jaypipes gibi: thx gibi
15:57:30 openstackgerrit Matt Riedemann proposed openstack/python-novaclient stable/queens: Fix up userdata argument to rebuild. https://review.openstack.org/613090
15:57:31 openstackgerrit Matt Riedemann proposed openstack/python-novaclient stable/queens: Follow up "Fix up userdata argument to rebuild" https://review.openstack.org/613091
16:00:27 openstackgerrit Daniel Abad proposed openstack/nova master: Fix ironic client ironic_url deprecation warning https://review.openstack.org/611872
16:07:08 pvc Hi sean-k-mooney my problem is i cannot run nvidia x settings on my instance
16:07:27 pvc https://docs.nvidia.com/grid/latest/grid-licensing-user-guide/index.html#licensing-grid-vgpu
16:10:01 sean-k-mooney the docs have an advanced section that shouw how to set the liceing info using an config file on linux or the registry on windows
16:16:29 pvc Hi sean-k-mooney can i use conf for adding a license right?
16:16:42 openstackgerrit Dan Smith proposed openstack/nova master: Always read-deleted=yes on lazy-load https://review.openstack.org/575190
16:18:17 dansmith melwitt: the down cell series could use some review if you have time. Everything up to the api change (which I orphaned while working on it) should be passing tests now
16:18:48 bauzas pvc: I pointed you to the nvidia guest licensing documentation this morning
16:19:22 bauzas pvc: https://docs.nvidia.com/grid/6.0/grid-licensing-user-guide/index.html#licensing-grid-software-linux-config-file
16:21:15 melwitt dansmith: thanks for the heads up, I'll go through it. I was also thinking about the handling of quota behavior in the presence of down cells. I don't think we have a patch for that yet. if not, I can look at proposing that on top of the api change
16:21:41 dansmith yep, not that I know of
16:22:27 melwitt ack
16:24:09 cdent sean-k-mooney: I built a place to store wood for the fire. good break. I saw mdbooth abandoned his thing, so where does stuff stand now?
16:25:21 sean-k-mooney cdent: i was in meetings so and some other stff so ill have the simple booling flag version up soon
16:26:33 openstackgerrit Merged openstack/nova-specs master: Re-proposes multiple vGPU types in libvirt https://review.openstack.org/602474
16:26:34 mdbooth cdent: Yeah, having thought about that again, I think it would need a different oslo.db api to do that. The decorator is returned by the object we want to replace, so there's no getting round that.
16:35:42 melwitt bauzas: just noticed another thing for the vgpu spec follow up https://review.openstack.org/#/c/602474/2/specs/stein/approved/vgpu-stein.rst@11
16:35:47 melwitt bp name
17:09:52 openstack bug 1799727 in OpenStack Compute (nova) "CPU_Allocation_Ratio from nova.conf doesn't update exisiting providers" [Undecided,Confirmed] https://launchpad.net/bugs/1799727
17:09:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1799727 https://review.openstack.org/613115
17:13:29 openstackgerrit Jan Gutter proposed openstack/os-vif master: Update port profile unit tests in host_info https://review.openstack.org/610636
17:14:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1799727 https://review.openstack.org/613115
17:14:18 openstack bug 1799727 in OpenStack Compute (nova) "CPU_Allocation_Ratio from nova.conf doesn't update exisiting providers" [High,Confirmed] https://launchpad.net/bugs/1799727
17:25:36 cfriesen jaypipes: stephenfin: regarding the "show server numa topology" spec, are you okay with showing the *guest* topology for regular users if we clean up the various issues you raised in the spec?
17:27:00 sean-k-mooney cfriesen: provdied the show numa toplogy spec does not show and host topology info they i think its fine
17:27:57 sean-k-mooney cfriesen: if you want it to show how the virtual topology is map to a hosts phyisical toplogy then that would be admin only
17:31:28 cfriesen sean-k-mooney: agreed. I think showing the "expected" host details to the admin would be useful, since we've run into cases where expected didn't match actual. :)
17:33:41 sean-k-mooney cfriesen: it should not upstream. the intel nfv ci actully ssh's into the host that the vm is running on and validates its pinned correctly
17:34:44 cfriesen sean-k-mooney: live migration
17:34:47 sean-k-mooney cfriesen: but for an admin yes it could be useful when debuging
17:35:15 cfriesen (at least until the patch goes in to fail the live migration if there's a numa topology)
17:35:15 sean-k-mooney cfriesen: what about it i said we validated it was pinned as nova told it too
17:35:27 sean-k-mooney i did not say nova pinned it correctly
17:36:10 sean-k-mooney cfriesen: ya on that i have asked stephen to make that condional and off by default

Earlier   Later