| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-06 | |||
| 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 | |
| 19:33:44 | sean-k-mooney | actully just lookking a littel more up in the logs http://paste.openstack.org/show/801464/ | |
| 19:33:51 | sean-k-mooney | we have the limits printed | |
| 19:34:05 | sean-k-mooney | so it has the flaovr limits there Flavor limits 2:2:8 | |
| 19:34:10 | melwitt | yeah. that is showing on the customer case too | |
| 19:34:38 | sean-k-mooney | ya so the issue is the preference of 0,0,0 | |