| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-06 | |||
| 11:52:46 | sean-k-mooney | if i had time i would really like to test that and write that up in docs because it would be greate do document how to correctly deploy using sharing agggreats to model storage | |
| 11:53:02 | gibi | currently we copy the allocation including the part that is allocated from sharing providers | |
| 11:53:14 | gibi | even if the same sharing provider shares with the new destination | |
| 11:53:29 | sean-k-mooney | we would just do double allcoations then | |
| 11:53:32 | sean-k-mooney | which i think is ok | |
| 11:53:52 | sean-k-mooney | it would reconsile the vaules wehn we do resize confirm | |
| 11:54:07 | gibi | hm, yes | |
| 11:54:10 | sean-k-mooney | i mean its not perfect but its not dangourous | |
| 11:54:24 | sean-k-mooney | it would jsut cause some failures wehn near capasity | |
| 12:00:34 | gibi | stephenfin: left feedback in https://review.opendev.org/c/openstack/nova/+/764040 | |
| 12:01:37 | sean-k-mooney | gibi: do we have any ci tests using provider.yaml | |
| 12:01:48 | gibi | sean-k-mooney: hm, good question | |
| 12:01:59 | gibi | I don't think we have tempest tesd | |
| 12:02:00 | gibi | test | |
| 12:02:04 | sean-k-mooney | im wondering if i could maybe test this theory with a change to the ceph job | |
| 12:02:23 | gibi | we have some functional test | |
| 12:03:54 | gibi | https://github.com/openstack/nova/blob/ccb2e11129d4a0730b0ba19a7f49ed8fc5a05f6d/nova/tests/functional/compute/test_resource_tracker.py#L665 | |
| 12:05:30 | sean-k-mooney | specificly i was thinking of configure both compute nodes to report 0 disk_gb and having a pretest hook create the sharing resouce provider | |
| 12:06:11 | gibi | I think it can be done | |
| 12:07:53 | sean-k-mooney | ya i think it would be worth testing at least | |
| 12:08:12 | sean-k-mooney | ill have to try and make time to do it. | |
| 12:08:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Drop statistics-style fields from os-hypervisors https://review.opendev.org/c/openstack/nova/+/764040 | |
| 12:08:26 | stephenfin | gibi: done | |
| 12:09:50 | lyarwood | sean-k-mooney: I'd be interested in helping with that | |
| 12:10:06 | lyarwood | once I've finished this machine type stuff | |
| 12:11:10 | stephenfin | gibi++ thanks :) | |
| 12:12:08 | stephenfin | gmann: When you're around, could do with some input on https://review.opendev.org/c/openstack/nova/+/765798/ I'm kind of lost as to what the next steps are /o\ | |
| 12:12:16 | sean-k-mooney | hehe i was hoping you would say that. long term it would be nice to be able to do it automatically but if this worked we could do it via an install and docuemnt it for this release and figure out how to make it work out of the box in the future | |
| 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. | |