Earlier  
Posted Nick Remark
#openstack-nova - 2021-01-06
12:12:33 gibi stephenfin: further comment in https://review.opendev.org/c/openstack/nova/+/764040
12:14:50 lyarwood sean-k-mooney: yup agreed
12:19:18 sean-k-mooney the main downside to this approch is without a reshape this would only work for new installs
12:19:32 sean-k-mooney but it would work for new installs so that would at least be progress
12:20:17 sean-k-mooney for existing deployments we would need to reshape the allcoation form the compute node rp to the shareing one
12:21:01 sean-k-mooney or sharing ones, you coudl have 1 ceph cluster per az or cell or something consiveably
12:21:29 sean-k-mooney aggrates would take care of modeling that however
12:23:26 lyarwood yeah the upgrade case isn't going to be fun to handle tbh
12:25:16 sean-k-mooney no matter what we do i dont see that improving much. sure if we can write a reshap but it will he complicated
12:25:59 sean-k-mooney i suspect a nova manage command would acatully be a better approch
12:26:32 sean-k-mooney where you spcify the sharing rp and the compute host to reshape
12:27:07 sean-k-mooney hum actully i guess placment-mange not nova mange as this is all on the placement side
13:35:36 sean-k-mooney lyarwood: by the way have you reviewd https://review.opendev.org/c/openstack/cinder-specs/+/766732
13:36:52 sean-k-mooney its propsoing extending os-brick to spawn a deamon process ot monitor and heal NVMEoF volules created over MD raids
13:37:17 sean-k-mooney e.g. havign it actily monitoing the underlying raid config and healing it
13:37:46 sean-k-mooney unfortunetly that is now approved on the cinder cide but i dont think this should be in the scope of os-brick to do personlally
13:38:30 sean-k-mooney gibi: lyarwood did this come up in the nova cinder cross project dicusstion at the ptg?
13:38:50 sean-k-mooney gibi: lyarwood i dont see any nova review on the spec at all
13:39:17 sean-k-mooney this is the os-brick patch https://review.opendev.org/c/openstack/os-brick/+/768576
13:41:37 sean-k-mooney gibi: we had some discussion with qqmber about this on monday
13:50:18 lyarwood sean-k-mooney: iirc it came up in the cinder track ahead of the nova track starting up
13:51:00 lyarwood sean-k-mooney: it's definitently not in n-cpu's wheel house to look after stuff like this so I'm not sure where you would have it if not os-brick?
13:52:36 sean-k-mooney in a standalone agnet
13:52:47 sean-k-mooney the fact is it would be executing in the n-cpu process
13:53:01 sean-k-mooney granted as a child process spawned by os-brick
13:53:16 sean-k-mooney but in any case it would be in the nova-compute contianer
13:53:41 sean-k-mooney for me it makes far more sense to make this its own standalone deamon
13:55:08 lyarwood Yeah I get that but to rearch that layer between os-brick and another local agent would be a huge amount of work
13:55:41 lyarwood ah wait
13:55:46 lyarwood isn't that the proposal anyway
13:56:25 sean-k-mooney the propsoal is to add an agent into os-brick and have os-bick spawn the agent into a new process from the nova compute agent
13:56:42 sean-k-mooney so a seperate deamon coudl use os-brick to do all the work
13:57:22 sean-k-mooney what i dont like is the magic spawning of a seperate process . granted we kind of do that for privsep but that is differnt
13:57:46 sean-k-mooney the lifetime fo rhte privesep process is related to the lifetiem of the nova-compute service
13:57:47 lyarwood right
13:57:54 sean-k-mooney the lifetime or this agent would not be
13:58:08 lyarwood sorry I had this the wrong way around
13:58:17 lyarwood I thought they already had a deamon somewhere
13:58:50 sean-k-mooney its already approved on the cinder side
13:59:16 sean-k-mooney i would have -1 it if it wasnt merged.
14:13:52 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Drop statistics-style fields from os-hypervisors https://review.opendev.org/c/openstack/nova/+/764040
14:14:16 stephenfin gibi: third time lucky :D ^
14:42:08 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: libvirt: Update instance machine type stash spec https://review.opendev.org/c/openstack/nova-specs/+/769547
14:42:44 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Record the machine_type of instances in system_metadata https://review.opendev.org/c/openstack/nova/+/767533
14:42:46 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP nova-manage: Add commands for managaing instance machine type https://review.opendev.org/c/openstack/nova/+/769548
14:59:46 sean-k-mooney stephenfin: how is your review queue at the moment
15:00:28 stephenfin sean-k-mooney: Manageable. What's up?
15:01:12 sean-k-mooney can you take a look at this small bug fix https://review.opendev.org/c/openstack/nova/+/767368 and when you have time my spec for port numa polices https://review.opendev.org/c/openstack/nova-specs/+/765901
15:01:30 sean-k-mooney i still have to update the vdpa spec but that what im going to do now
15:02:21 stephenfin sure thing
15:02:44 gibi sean-k-mooney: if nova needs to know (communicate with) a new agent (spawned by os-brick) then we need a nova spec about it. If the os-brick change is transparent to nova then meh
15:03:28 gibi sean-k-mooney: do we define what is in a nova compute container upstream?
15:03:39 gibi stephenfin: will look in a sec
15:03:51 sean-k-mooney personally im a little uncomfortably with our dependient libs effectivly injecting arbitry code that executes as a persitent deamon
15:04:15 sean-k-mooney gibi: no nova does not kolla/ooo/loci do
15:04:40 sean-k-mooney we do try to keep it at 1 process per container for the most part bar privsep
15:04:41 gibi then those projects needs to be involved to the dicussion as they are impacted by a new agent
15:05:10 gibi stephenfin: I'm +2 on https://review.opendev.org/c/openstack/nova/+/764040
15:05:12 sean-k-mooney the way its proposed it would jsut run in the continer without there interventions or knowladge
15:05:51 sean-k-mooney although in the contier case the new agent would still implictly share the same lifetime as the nova agent since tehy are in the same container
15:06:23 stephenfin gibi: Great. Thanks!
15:06:40 gibi stephenfin: new you are the closest to grab the microversion 2.88
15:07:15 gibi sean-k-mooney: that is actually a good argument for a separate service as they want independent lifetime
15:07:16 stephenfin gibi: Yup. I'm going to ask gmann to take a look at that later, assuming he's back from his PTO
15:07:23 gibi stephenfin: cool
15:59:57 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Parse the 'os' element from domainCapabilities https://review.opendev.org/c/openstack/nova/+/673790
16:11:42 dansmith lyarwood: I was just about to +2 that machine type sysmeta spec rev, but saw that stephenfin already did.. I have annoying unrelated questions, one of which might be an accidental state omission
16:12:04 dansmith lyarwood: if it 's cool, I'll just +2 and let you quickly look if you want to throw the other state in there to avoid a rev-to-the-rev,
16:12:19 dansmith and I can just +W if I'm wrong or you want it separate
16:16:11 lyarwood dansmith: just on a call now, happy to answer your questions before this lands. I'll take a look once this is over.
16:16:28 dansmith lyarwood: ack
17:22:56 lyarwood dansmith: replied, need to drop for dinner but I'll respin this evening.
17:23:02 dansmith ack
17:30:13 gmann stephenfin: ack, I will review today.
17:47:30 stephenfin gmann: thanks
18:58:14 openstackgerrit sean mooney proposed openstack/nova master: [WIP] test numa and vcpu topologies https://review.opendev.org/c/openstack/nova/+/769601
18:58:23 sean-k-mooney melwitt:^
18:59:34 melwitt thanks
19:00:17 sean-k-mooney i wonder is there an easy way to print the xml that would be created
19:20:16 sean-k-mooney ah i can use OS_DEBUG=1 and add assert False
19:20:23 sean-k-mooney and it then dumps all the logs
19:22:54 sean-k-mooney http://paste.openstack.org/show/801461/
19:24:12 sean-k-mooney the numa toplogy is correct but the cpu toplogy is not
19:24:14 sean-k-mooney <topology sockets="8" cores="1" threads="1"/>
19:24:35 melwitt a-ha, cool (about the logs)
19:24:56 sean-k-mooney that was the xml for https://review.opendev.org/c/openstack/nova/+/769601/1/nova/tests/functional/libvirt/test_numa_servers.py#158
19:25:06 melwitt ack
19:25:30 sean-k-mooney oh my extra specs are wrong
19:25:47 sean-k-mooney wiat did i copy those form the customer
19:26:11 sean-k-mooney no they have the correct ones im missing cpu_
19:28:37 sean-k-mooney ok i repoduced it now
19:28:58 sean-k-mooney http://paste.openstack.org/show/801463/
19:29:00 melwitt omg !
19:29:02 sean-k-mooney that is the error
19:29:30 melwitt yes, looks like you've got it. sweet
19:30:39 melwitt yeah there's the IndexError which is a separate thing but once that is fixed it will still be an erroneous failure to schedule. need to open I guess two bugs, one for the IndexError and one for the scheduling fail
19:31:57 openstackgerrit sean mooney proposed openstack/nova master: [WIP] test numa and vcpu topologies https://review.opendev.org/c/openstack/nova/+/769601
19:32:17 sean-k-mooney the index error i think is jsut use trying to get the first entry in the list of toplogies
19:32:28 sean-k-mooney but its empty so that is simple to fix
19:32:29 melwitt correct

Earlier   Later