| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-12 | |||
| 14:07:51 | bauzas | gibi: oh that one | |
| 14:07:58 | bauzas | gibi: silverlining, already reviewed it | |
| 14:08:53 | sean-k-mooney | stephenfin: it is intended to be used for validating glance metadata entries and its used but horizon to generate teh ui with the dropdown vlaues and for validation | |
| 14:09:22 | sean-k-mooney | it also has defintions for the flavor extra specs too. | |
| 14:09:45 | mriedem | tssurya: dansmith: i left comments in the down cell servers view builder change, the series is going to have to be rebased | |
| 14:10:00 | sean-k-mooney | stephenfin: what might make sense it to extract it into a seperate repo that glance,nova and cinder can all import and share | |
| 14:10:00 | stephenfin | sean-k-mooney: Aye, I knew about. If that was ever kept up-to-date though, I'm not sure if it still is. Barely any edits in years https://github.com/openstack/glance/tree/master/etc/metadefs | |
| 14:10:33 | stephenfin | I didn't know that it supported flavour extra specs though. That's good to know | |
| 14:10:59 | stephenfin | sean-k-mooney: Aye, I think so. I'll have a look into it when I get a chance. Just been annoying me for some time now | |
| 14:11:11 | sean-k-mooney | stephenfin: ya it was orginally created to keep the falvor extra specs and image metadata in sync | |
| 14:11:38 | sean-k-mooney | if we did extract it i dont see why we could not autogenerate the docs for it too | |
| 14:13:36 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Remove _legacy_dict methods https://review.openstack.org/636210 | |
| 14:13:37 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source https://review.openstack.org/634827 | |
| 14:13:37 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Add migration param to check_can_live_migrate_destination https://review.openstack.org/634605 | |
| 14:13:38 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Use live_migration_claim() to check dest resources https://review.openstack.org/634606 | |
| 14:13:38 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] Introduce live_migration_claim() https://review.openstack.org/635669 | |
| 14:13:39 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] LM: update NUMA-related XML on the source https://review.openstack.org/635229 | |
| 14:13:39 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP] LM: Make dest send NUMAMigrateData to the source https://review.openstack.org/634828 | |
| 14:13:42 | kashyap | Gosh, this serial / char devices code is making me go slowly mental... | |
| 14:13:44 | sean-k-mooney | stephenfin: can we put it as a cross project topic with the glance and maybe cinder folks for the ptg | |
| 14:14:16 | stephenfin | sean-k-mooney: Good idea, that | |
| 14:15:32 | sean-k-mooney | stephenfin: it looks like it also cover nova host aggrage metadata too https://github.com/openstack/glance/blob/master/etc/metadefs/compute-aggr-num-instances.json | |
| 14:15:34 | bauzas | lyarwood: I just agree with mriedem_snow on https://review.openstack.org/#/c/628726/4 | |
| 14:15:46 | bauzas | lyarwood: we should make backports easy by providing a series | |
| 14:15:48 | bauzas | WDYT ? | |
| 14:16:36 | bauzas | since you already identified the source of the conflicts, and you also want to backport the missing changes, I don't see any difficulty in making the backports intertwined | |
| 14:16:36 | lyarwood | bauzas: yeah ack sorry I totally forgot about that | |
| 14:16:50 | bauzas | lyarwood: ack, ping me when you're done then | |
| 14:17:29 | bauzas | that's what happens when you write poor interfaces | |
| 14:20:57 | NewBruce | sean-k-mooney any chance i can get your thoughts on a bit of a bug that looks to be related to the port binding API changes? | |
| 14:25:07 | sean-k-mooney | NewBruce: i saw you comments this moring | |
| 14:25:19 | NewBruce | awesome, sorry for chasing | |
| 14:25:44 | NewBruce | done some more debugging now, and feels like i isolated the point it fails | |
| 14:25:47 | sean-k-mooney | no worries i just havent had a chance to reply was booking flights and stuff | |
| 14:26:02 | sean-k-mooney | so one general question | |
| 14:26:06 | NewBruce | np. hope your goin' somewhere warm | |
| 14:26:24 | sean-k-mooney | PTG flights | |
| 14:26:25 | openstackgerrit | Merged openstack/nova stable/pike: Handle IndexError in _populate_neutron_binding_profile https://review.openstack.org/635921 | |
| 14:26:28 | NewBruce | sure - | |
| 14:27:01 | sean-k-mooney | am you have a mixed cloud with OSA nodes and RDO nodes | |
| 14:27:21 | NewBruce | correct | |
| 14:27:28 | sean-k-mooney | is the contol plan. e.g. your contolers all RDO or is it also mixed | |
| 14:27:42 | NewBruce | control plane is upgrade to Rocky/OSA | |
| 14:28:21 | NewBruce | we have multiple sites, with the same config which dont exhibit the problem | |
| 14:28:27 | sean-k-mooney | ok so you have Rocky/OSA contol plane + OSA computes + some rocky/RDO computes | |
| 14:28:36 | NewBruce | correct | |
| 14:28:54 | NewBruce | looking in the setup today we have some RDO net nodes as well | |
| 14:29:20 | sean-k-mooney | and on the neutron side is it also a mix or all OSA for you neturon controler services | |
| 14:29:30 | NewBruce | so they could do with being upgraded.... but in the debugging ive done today, it seems to bail out in the call to _setup_migration_port_profile | |
| 14:29:46 | dansmith | mriedem_snow: okay I was thinking we should maybe try real hard to get that merged today | |
| 14:29:59 | NewBruce | in a successful migration, the host_id passed to _setup_migration_port_profile is the target/dest compute; whereas in a failure the host_id passed to _setup_migration_port_profile is the source | |
| 14:30:02 | sean-k-mooney | how the multiple portbinging code is ment to work is that the nova condocutor is first ment to check the neutron api to determin if neutron support it | |
| 14:31:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/628726 | |
| 14:31:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.openstack.org/629597 | |
| 14:31:47 | sean-k-mooney | the condoctor then check the version of both the souce and dest compute service and if they both support the multiple port binding workflow it is enabled | |
| 14:31:58 | NewBruce | will be used as described below. | |
| 14:31:58 | NewBruce | If both compute nodes are queens or newer. In this case the new workflow | |
| 14:32:08 | lyarwood | bauzas / stephenfin / mriedem_snow ^ reworked these into a series now on top of https://review.openstack.org/#/c/620111/, hopefully that's cleaner for everyone. | |
| 14:32:47 | NewBruce | so that check is based on the nova versions, yeah? which is fair enough, as when i monitor the ml2_port_bindings. i see the duplicate port entries in both successful and fail cases; | |
| 14:33:18 | NewBruce | in the services table both source and dest are v35 | |
| 14:33:35 | NewBruce | for nova-compute | |
| 14:33:46 | sean-k-mooney | NewBruce: thew new workflow should only take effect if the source and dest compute nodes are rocky | |
| 14:33:51 | NewBruce | which they are | |
| 14:34:30 | NewBruce | sorry sean-k-mooney - gotta run for 10-15 will be back online | |
| 14:34:38 | sean-k-mooney | sure no worries | |
| 14:35:54 | zigo | Hi there! | |
| 14:36:09 | zigo | I'm getting a weirdo bug inside Horizon which is related to Novaclient. | |
| 14:36:18 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: libvirt: Do not reraise DiskNotFound exceptions during resize https://review.openstack.org/571410 | |
| 14:36:25 | zigo | When listing instances, Horizon first try to get the nova microversion. | |
| 14:36:36 | kaisers | stephenfin: Hi! would you care to revisit https://review.openstack.org/#/c/522245/ ? Old driver bugfix change that has been sitting for some time and is not overly complex. | |
| 14:36:57 | zigo | So it tries to get https://api/compute/v2.1 | |
| 14:37:17 | zigo | But nova sends as reply a redirect to https://api/compute/v2.1/ (note the lasting slash ...) | |
| 14:37:18 | stephenfin | kaisers: Sure. I'd totally forgotten about that :) I'll take a look now | |
| 14:37:31 | kaisers | stephenfin: greate, thnx | |
| 14:37:34 | zigo | It's probably a miss-configuration of haproxy, apache, or something else... | |
| 14:37:52 | zigo | Though shouldn't nova-api reply with the microversion even without the lasting / ? | |
| 14:42:12 | zigo | bauzas: ^ | |
| 14:42:21 | bauzas | efried: gibi: I'm torn, given we only pass allocations down to the virt driver, how can the driver know whether the related RP is a root RP or a child ? | |
| 14:42:58 | bauzas | it should then look at the ProviderTree, right? | |
| 14:43:22 | efried | bauzas: You can't, until we implement https://review.openstack.org/#/c/597601/ | |
| 14:43:38 | efried | does spawn have access to the provider tree? | |
| 14:43:39 | gibi | bauzas: I think from the allocation alone you cannot figure out | |
| 14:44:07 | bauzas | because then we have a problem with the reshape | |
| 14:44:31 | efried | The reshape comes from update_provider_tree, which *does* have access to the provider tree. | |
| 14:44:34 | gibi | bauzas: do you really need that information? can you simply look at the allocation, select the RP that has VGPU resource allocated from | |
| 14:44:53 | bauzas | gibi: how can I know this question ? | |
| 14:46:08 | bauzas | gibi: efried: I mean, for the moment, we use a mdev when creating an instance by https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6273 | |
| 14:46:09 | gibi | bauzas: you want to know which PGPU you are allocated the mdev from. You have the allocations dict. That dict has RPs with resources in it. The RP you need is the one that has VGPU resource allocated from | |
| 14:46:45 | bauzas | gibi: efried so I'm changing the above to check with RP was allocated | |
| 14:47:09 | bauzas | and then only either creating a new mdev or use an existing mdev from the pci device related to the RP | |
| 14:47:18 | stephenfin | kaisers: Done. Feel free to ping me whenever I do forget stuff. I'll simply ignore you if I'm too busy :) | |
| 14:47:42 | bauzas | gibi: I'm getting allocations, right? | |
| 14:47:58 | stephenfin | lyarwood: Thanks for tackling that (y) It was on my TODO list | |
| 14:48:07 | bauzas | gibi: so I guess I'm getting https://developer.openstack.org/api-ref/placement/?expanded=list-allocations-detail#response-example-1-28 | |
| 14:48:29 | gibi | yes | |
| 14:48:50 | bauzas | so how can I get the RP ? | |
| 14:49:01 | bauzas | I just have the RP UUID | |
| 14:49:02 | efried | the rp is in there, but only its uuid, not its name. | |
| 14:49:10 | gibi | ok it is just the UUID | |
| 14:49:22 | gibi | what else you would need? then name ? | |