| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-15 | |||
| 14:56:17 | gibi | it increase complexity | |
| 14:56:49 | sean-k-mooney | right so really the reosuce tracker and pci tracker are ment to be the source of truth for the resouce that are avlaibel | |
| 14:56:56 | sean-k-mooney | and the virt driver just provide the raw resoucs | |
| 14:57:01 | sean-k-mooney | btu that is not how it works today | |
| 14:57:19 | sean-k-mooney | we have the virt driver direclty updateign the tree | |
| 14:57:23 | gibi | yepp | |
| 14:57:51 | sean-k-mooney | so that is backwards architularly but we did it because how that tree will like is virt dirver depentent because ironic | |
| 14:58:14 | sean-k-mooney | well ironic vmware ectra they look differnt then libvirt or hyperv | |
| 14:58:29 | sean-k-mooney | e.g. clsuterd vs 1:1 drivers | |
| 14:58:51 | gibi | hm it is differnt per driver yes | |
| 14:59:02 | gibi | so that is baad abstraction | |
| 14:59:11 | sean-k-mooney | currently yes | |
| 14:59:21 | sean-k-mooney | if you jsut want to resue the code form the pci module that is fine | |
| 14:59:26 | gibi | we have the generic nova scheduler code that depends on the tree but the tree if virt driver dependent | |
| 14:59:28 | sean-k-mooney | i dont really think we shoudl port it | |
| 14:59:51 | gibi | I will play around more before I decide | |
| 14:59:56 | sean-k-mooney | ack | |
| 15:00:10 | gibi | thanks for talking to me about it | |
| 15:00:16 | sean-k-mooney | gibi: i will be happy to review working code | |
| 15:00:19 | sean-k-mooney | what ever form that takes | |
| 15:00:19 | gibi | sorry If I was sooo negative | |
| 15:00:34 | gibi | shit meeting :/ | |
| 15:00:44 | gibi | I almost made progress today :D | |
| 15:06:41 | opendevreview | Merged openstack/nova stable/yoga: Allow claiming PCI PF if child VF is unavailable https://review.opendev.org/c/openstack/nova/+/840833 | |
| 15:53:49 | dansmith | gibi: sean-k-mooney bauzas: glance is planning to make a change to how image locations are updated (for the tight integration with ceph) | |
| 15:54:06 | dansmith | right now we use the user's token and don't have a "talk to glance with this service account" sort of setup like we do for neutron | |
| 15:54:25 | dansmith | we'd need to create images with their token, but then update the location with the service account | |
| 15:54:35 | dansmith | which is similar I think to things we do for/with neutron | |
| 15:55:00 | dansmith | but the spec in glance is very close to merging and I don't think anyone from nova has looked at it or grokked it from a nova perspective (other than me) | |
| 15:55:10 | dansmith | anyone have any concerns over that or want to review it first? | |
| 15:56:20 | bauzas | dansmith: sorry, triage meeting atm | |
| 15:56:46 | dansmith | bauzas: yep, np, reply when you can | |
| 15:57:16 | bauzas | dansmith: pass me the spec | |
| 15:57:20 | dansmith | https://review.opendev.org/c/openstack/glance-specs/+/840882/15/specs/zed/approved/glance/new-location-info-apis.rst | |
| 15:58:41 | bauzas | dansmith: from what you described, the usecase seems legit | |
| 15:59:30 | dansmith | bauzas: I think so to and it matches what we do for neutron at least, but it's a bit of a departure from how we talk to glance today (which is always with the user's token) so I just wanted to make sure we're all in agreement | |
| 16:00:03 | bauzas | dansmith: I'm more concerned by who would be in charge of doing the necessary bits in nova | |
| 16:00:13 | sean-k-mooney | so we kidn of have this precedent for nuton because | |
| 16:00:19 | sean-k-mooney | we have to update the host-id field | |
| 16:00:35 | bauzas | dansmith: I don't want us to lag with old behaviour because of lack of resources | |
| 16:00:42 | sean-k-mooney | for glance dont we already need admin for reading the multi sotre backend locations | |
| 16:00:55 | bauzas | but if the spec owner signs off for doing the nova bits, I'm cool | |
| 16:00:58 | sean-k-mooney | this is one of the things that would be good to do with the service role in the futre | |
| 16:01:14 | whoami-rajat | bauzas, i might end up doing it since I'm the author of the glance spec but if not will find someone who will be willing to do it | |
| 16:01:17 | dansmith | sean-k-mooney: no, we use the internal api endpoint with the user's token | |
| 16:01:25 | sean-k-mooney | ah ok | |
| 16:01:26 | bauzas | whoami-rajat: cool, I understand | |
| 16:01:37 | dansmith | bauzas: yeah, I'm also curious about that, since it won't be super trivial given that it's buried pretty deep | |
| 16:01:43 | sean-k-mooney | so we cant depend on having the admin token today correct | |
| 16:01:49 | whoami-rajat | since I'm already in charge of the cinder changes, nova changes should not be too hard or different | |
| 16:01:58 | bauzas | dansmith: you get my point | |
| 16:02:15 | bauzas | dansmith: I'm afraid of this being not trivial and requiring some hard work, including testing | |
| 16:02:16 | dansmith | sean-k-mooney: right, this is to solve that problem, and let nova present actual credentials to do that thing, instead of letting unprivileged people do it, but only through the internal api endpoint | |
| 16:02:25 | dansmith | sean-k-mooney: basically real auth instead of host-based auth | |
| 16:02:59 | dansmith | bauzas: yeah, I don't think it'll be super hard since we only do this in a couple places, but it's deep, so not trivial | |
| 16:03:14 | bauzas | whoami-rajat: before saying "not too hard", it's quite self-contained | |
| 16:03:20 | bauzas | ah, burned by dansmith | |
| 16:03:25 | bauzas | but there be dragons | |
| 16:03:51 | bauzas | also | |
| 16:04:13 | dansmith | I really don't think there will much burning or dragons, but I haven't gone digging myself to see exactly what would be involved, so I'm hedging :) | |
| 16:04:14 | bauzas | I guess you'll stick with the existing auth'd roundrobins for a couple of releases ? | |
| 16:04:32 | bauzas | rolling upgrades is a bit of a thing | |
| 16:04:46 | dansmith | bauzas: I think what we do is: if the credentials are configured, use the new way, if not, assume the old way is still active | |
| 16:04:58 | bauzas | all good then | |
| 16:05:00 | dansmith | because some people could still be running glance from folsom and be perfectly happy | |
| 16:05:26 | dansmith | so we don't want to introduce a hard requirement.. we could force a move later, but I think it has to be a decent window of overlap | |
| 16:05:33 | bauzas | I'll chime into the review, thanks for the heads up | |
| 16:05:34 | whoami-rajat | Folsom??? but as dansmith said, we will have backward compatibility | |
| 16:05:52 | dansmith | whoami-rajat: sarcasm so extreme to make it obvious :P | |
| 16:06:07 | bauzas | whoami-rajat: as someone who played with Folsom, glance was perfectly good at that time | |
| 16:06:13 | dansmith | haha | |
| 16:06:25 | dansmith | honestly, openstack has been downhill since folsom anyway :P | |
| 16:06:26 | whoami-rajat | :D | |
| 16:06:40 | whoami-rajat | wow, glance has been stable forever! | |
| 16:06:45 | bauzas | things were easier honestly | |
| 16:06:57 | bauzas | nova-net, glance and nova-volume were easy to manage | |
| 16:07:18 | bauzas | but I'm diverting | |
| 16:07:52 | dansmith | okay so to circle back, | |
| 16:08:27 | dansmith | are there any concerns with the general approach that should hold up glance merging the spec and working on this new interface in zed so that we can start converting nova and cinder in Aardvark? | |
| 16:08:55 | bauzas | I saw the first +2 | |
| 16:08:59 | bauzas | I'll review the spec now | |
| 16:09:35 | bauzas | but from a 10.000ft level, no I think we're on a safe bet | |
| 16:10:01 | dansmith | bauzas: ack, could you look at it today before you go? if so I can throw my +2 on there | |
| 16:10:08 | bauzas | dansmith: on it | |
| 16:10:10 | dansmith | bauzas: thanks | |
| 16:10:44 | whoami-rajat | thanks dansmith and bauzas for the discussion | |
| 16:10:53 | dansmith | ++ | |
| 16:27:07 | gibi | I read back I have no objection | |
| 16:28:03 | whoami-rajat | thanks gibi | |
| 16:32:44 | bauzas | I reviewed the patch | |
| 16:32:54 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: fake: Ensure need_legacy_block_device_info returns False https://review.opendev.org/c/openstack/nova/+/843958 | |
| 16:32:55 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: tests: work around malformed serial XML https://review.opendev.org/c/openstack/nova/+/844743 | |
| 16:32:56 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: functional: Use tempdir for CONF.instances_path https://review.opendev.org/c/openstack/nova/+/844750 | |
| 16:32:57 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: Add a regression test for bug 1939545 https://review.opendev.org/c/openstack/nova/+/843959 | |
| 16:32:59 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: compute: Ensure updates to bdms during pre_live_migration are saved https://review.opendev.org/c/openstack/nova/+/843960 | |
| 16:33:01 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: fup: Make connection_info returned by CinderFixture unique per attachment https://review.opendev.org/c/openstack/nova/+/844744 | |
| 16:33:03 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: func: Add live migration rollback volume attachment tests https://review.opendev.org/c/openstack/nova/+/844745 | |
| 16:33:05 | opendevreview | Artom Lifshitz proposed openstack/nova stable/train: fup: Assert state of connection_info during LM rollback in func tests https://review.opendev.org/c/openstack/nova/+/844746 | |
| 16:33:12 | bauzas | my only concern which isn't blocking is about making sure we provide a smooth upgrade path for our operators | |
| 16:33:46 | bauzas | asking them to change their config before upgrading is a pain | |