| *** ricolin_ is now known as ricolin | 05:05 | |
| *** rpittau|afk is now known as rpittau | 07:06 | |
| zigo | Since Bullseye, live migration is broken on my system, with libvirt not listening on the qemu+tcp port (it's using socket activation). Does anyone know how to configure the new libvirt correctly for this? | 08:37 |
|---|---|---|
| stephenfin | sean-k-mooney1: you're looking at the wrong XML, I think | 08:58 |
| stephenfin | sean-k-mooney1: You can see the update happening here https://zuul.opendev.org/t/openstack/build/73f734b9ffe745bd833ffe90f324d6d8/log/compute1/logs/screen-n-cpu.txt#7468-7476 | 08:59 |
| bauzas | do someone know whether we use in our jobs the singleconductor devstack value ? https://github.com/openstack/devstack/blob/master/lib/nova#L537 ? | 09:02 |
| bauzas | I was expecting us to create a superconductor by default even for a devstack AIO | 09:02 |
| bauzas | nevermind, found it | 09:09 |
| bauzas | this is just legacy | 09:09 |
| bauzas | I can't see a single job running with a singleconductor | 09:09 |
| stephenfin | bauzas: maybe remove it so? | 09:15 |
| stephenfin | *we should | 09:15 |
| bauzas | yup, think so | 09:15 |
| sean-k-mooney1 | stephenfin the xml should always be ethernet | 10:07 |
| sean-k-mooney1 | stephenfin: it is useing ethernet in that segment which is good | 10:08 |
| sean-k-mooney1 | but it should spawn with it too | 10:08 |
| sean-k-mooney1 | stephenfin: ok so we need to determin why its only taking effect on migration and not on inital spawn | 10:09 |
| sean-k-mooney1 | that narrows it down at least | 10:10 |
| stephenfin | sean-k-mooney: We never set the 'delegate_create' attribute of the VIF object anywhere except as part of a migration | 10:14 |
| stephenfin | sean-k-mooney: https://github.com/openstack/nova/commit/a62dd42c0dbb6b2ab128e558e127d76962738446#diff-d47af556a60631b879ac4f609e24b5616aa81643d152583b1591ef90848382bbR108 | 10:15 |
| stephenfin | which means it's never set as part of the os-vif object https://github.com/openstack/nova/commit/a62dd42c0dbb6b2ab128e558e127d76962738446#diff-918e740344fd54062b1d2040fc7d83a6fb349e33a484b3a442d154977a7f872bR350 | 10:16 |
| sean-k-mooney | ah ok that was my orginal error then. i used to do it uncondtionally then i added the code to do the patch detection | 10:16 |
| sean-k-mooney | so we want to default it to true but have the migration code check and disable if the dest is not supported | 10:17 |
| stephenfin | I can look into that. It's a different issue than the one I'm fixing in that patch though, so I think that patch is still valid by itself | 10:19 |
| opendevreview | Jorhson Deng proposed openstack/nova master: recheck the attachment_id after the reschedule successful https://review.opendev.org/c/openstack/nova/+/796209 | 10:22 |
| sean-k-mooney | it is but without that other change its a really odd behavior | 10:22 |
| sean-k-mooney | i kind of think they need to be in one patch | 10:22 |
| sean-k-mooney | we dont want the interface to be differn after a live migration and have it chagne back after a hard reboot do we | 10:23 |
| sean-k-mooney | we could do that but it feels odd | 10:23 |
| sean-k-mooney | its also not what i had planned in that libvirt would still be invovled in port plugging | 10:23 |
| sean-k-mooney | stephenfin: we can just set it here i belive https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2972 | 10:24 |
| sean-k-mooney | although that technically would mean it should be in the vif model object | 10:26 |
| opendevreview | Jorhson Deng proposed openstack/nova master: recheck the attachment_id after the reschedule successful https://review.opendev.org/c/openstack/nova/+/796209 | 10:27 |
| sean-k-mooney | this is where we make the desision currently | 10:28 |
| stephenfin | sean-k-mooney: we create the VIF just after we call that function https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/network/neutron.py#L3078 | 10:28 |
| sean-k-mooney | stephenfin: we need create port to default to true | 10:28 |
| stephenfin | so we can just set it there always | 10:28 |
| stephenfin | there's no reason it ever needs to be false - it will be ignored for backends where it doesn't make sense | 10:28 |
| sean-k-mooney | am we could but you will have to extend the vif model object if you do that which will change the versioned notifcations | 10:29 |
| sean-k-mooney | and that wont be backportable | 10:29 |
| sean-k-mooney | we need to do this slightly different | 10:30 |
| stephenfin | that's no an o.vo | 10:30 |
| stephenfin | *not | 10:30 |
| sean-k-mooney | its not but its in one | 10:30 |
| sean-k-mooney | the network info cache | 10:30 |
| sean-k-mooney | its got a list of vifs | 10:30 |
| stephenfin | but the VIF model has already been modified https://github.com/openstack/nova/commit/a62dd42c0dbb6b2ab128e558e127d76962738446#diff-dfa43d5033ab6af143d8772d584ed93255e60deb7bc58d87eb7305b19f8fa2ffR381 | 10:30 |
| sean-k-mooney | i guess we normally dont change for compostion but it does change the hash | 10:30 |
| sean-k-mooney | by addign a constant and properties | 10:31 |
| sean-k-mooney | both of which do not change the version of the object | 10:31 |
| sean-k-mooney | oh | 10:31 |
| sean-k-mooney | sorry you ar just setting the property | 10:31 |
| sean-k-mooney | ya so that is why that property stores its data in the profile | 10:32 |
| sean-k-mooney | to avoid the ovo change and be backportable | 10:32 |
| sean-k-mooney | ok | 10:32 |
| sean-k-mooney | so yes we can just set the property to true uncondtionally | 10:32 |
| sean-k-mooney | but we als have https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/network/model.py#L405 | 10:33 |
| sean-k-mooney | ok im confused | 10:33 |
| sean-k-mooney | i tought that was an ovo issue but maybe not | 10:34 |
| stephenfin | those are just dics | 10:34 |
| stephenfin | *dicts | 10:34 |
| stephenfin | so we can store whatever we want in them | 10:34 |
| sean-k-mooney | ok so we just pass delegate_create=True | 10:34 |
| sean-k-mooney | stephenfin: they are but they are also https://github.com/openstack/nova/blob/master/nova/objects/instance_info_cache.py#L38 | 10:34 |
| sean-k-mooney | i guess thats a network model | 10:35 |
| stephenfin | all that that's doing is calling '.json' on the object https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/objects/fields.py#L1084 | 10:35 |
| stephenfin | so it doesn't really matter | 10:35 |
| sean-k-mooney | well its is using https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/network/model.py#L512 | 10:36 |
| sean-k-mooney | ok i guess its fine | 10:36 |
| sean-k-mooney | i had issue adding other filds in the past | 10:36 |
| sean-k-mooney | but maybe i was chanign something else | 10:36 |
| sean-k-mooney | in anycase i think your right we can just set it to true there | 10:36 |
| sean-k-mooney | but we need to ensure in the migration path we set it to false wehn its not present orginally | 10:37 |
| gibi | stephenfin, sean-k-mooney: for me https://review.opendev.org/c/openstack/nova/+/797142 looks fine, but sean-k-mooney has a -1 on it so I'm affraid of approving it | 11:13 |
| sean-k-mooney | gibi: thats what we were discussign above stephen fixed it for migration but its still using the wrong interface type on boot | 11:15 |
| gibi | OK, so there will be changes. thanks | 11:16 |
| sean-k-mooney | so with that patch as is we boot with interface type=bridge then we migrate with ethernet and hard reboot back to bridge | 11:16 |
| sean-k-mooney | the orignal intent was to always use ethernet | 11:16 |
| sean-k-mooney | gibi: technically as is this should actully fix the migration issue we were trying to fix | 11:17 |
| sean-k-mooney | but its a little odd to change the type just for the migration | 11:17 |
| sean-k-mooney | im also worried that this current state breaks ovs on windows | 11:17 |
| sean-k-mooney | so i would prefer to fix the boot case. | 11:18 |
| opendevreview | Merged openstack/nova stable/victoria: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/787252 | 11:18 |
| opendevreview | Stephen Finucane proposed openstack/nova master: libvirt: Always delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/797428 | 11:19 |
| stephenfin | sean-k-mooney: gibi: ^ there's the follow-up patch. I need to figure out test coverage (currently all unit tests are passing and I'm running functional tests now, but I guess I should add a new test). We can proceed with the current patch as-is though IMO | 11:20 |
| stephenfin | it definitely fixes one issue | 11:20 |
| sean-k-mooney | well what about for backporting | 11:20 |
| sean-k-mooney | unless you are going to squash all 3 patches you would have to undo the squashing you have already done | 11:21 |
| stephenfin | Not necessarily. The main patch only ever fixed the issue for live migration but had a bug which we've squashed the fix in for. This new patch stands on its own feet | 11:22 |
| sean-k-mooney | it was ment to do it always | 11:22 |
| sean-k-mooney | ti did do it always before i put in the detection mechanium for upgrades | 11:22 |
| stephenfin | Also, I don't think hard reboot is an issue. We'll have set the 'delegate_create' attribute of the VIF entries as part of live migration and nothing unsets that | 11:23 |
| sean-k-mooney | stephenfin: well i would prefer not to backport it in its current state | 11:23 |
| stephenfin | So it'll change during live migration but it shouldn't change after a hard reboot | 11:23 |
| sean-k-mooney | it will revert back to bridge in a hard reboot | 11:23 |
| sean-k-mooney | without the final patch | 11:23 |
| stephenfin | why? | 11:23 |
| sean-k-mooney | because bridge is what we use for spawn | 11:24 |
| stephenfin | unless the VIF objects in network_info have delegate_create=True | 11:24 |
| sean-k-mooney | which they wont | 11:24 |
| stephenfin | again, why? | 11:24 |
| sean-k-mooney | the migration data vifs are not the same as the ones in the info cache | 11:24 |
| sean-k-mooney | the ones in the info cache get rebuilt form neutron by the perodic task | 11:25 |
| sean-k-mooney | or whenever we get a network-changed event | 11:25 |
| sean-k-mooney | so delegate_create=True will be lost | 11:25 |
| sean-k-mooney | if its ever populated in it in the first place | 11:25 |
| stephenfin | ah, TIL | 11:26 |
| stephenfin | okay, so I'll squash the third patch in too so | 11:26 |
| * gibi nods | 11:26 | |
| sean-k-mooney | ok am can we wait for grenade to run on the 3rd patch then we can merge the second one? | 11:27 |
| sean-k-mooney | i just want to make sure that it is not breaking anything | 11:27 |
| stephenfin | we really need to mute that SQLAlchemy warning | 11:29 |
| sean-k-mooney | yep | 11:29 |
| stephenfin | I've a fix proposed to oslo.db | 11:29 |
| stephenfin | https://review.opendev.org/c/openstack/oslo.db/+/797426 | 11:29 |
| sean-k-mooney | ah nice | 11:30 |
| sean-k-mooney | i was assuming we woudl set that to false | 11:30 |
| sean-k-mooney | are we ok with caching softdelete or json data | 11:30 |
| sean-k-mooney | The requirements for cacheable elements is that they are hashable and also that they indicate the same SQL rendered for expressions using this type every time for a given cache value. | 11:31 |
| sean-k-mooney | ok | 11:31 |
| sean-k-mooney | so ya that is correct | 11:32 |
| sean-k-mooney | cache_ok applies | 11:32 |
| *** osmanlicilegi is now known as Guest187 | 12:25 | |
| *** ChanServ changes topic to "This channel is for Nova development. For support of Nova deployments, please use #openstack" | 12:30 | |
| sean-k-mooney | stephenfin: the full job suite is not finished yet but the live migration job passed and is now using ethernet so thats good to see just waiting on grenade now | 12:39 |
| sean-k-mooney | gibi: gmann so intersing problem, apparently we do not validate server_group policy strings | 12:52 |
| sean-k-mooney | we have never intended the server group to be user extendable right? | 12:52 |
| sean-k-mooney | e.g. by using out of tree filters and weighers? | 12:52 |
| sean-k-mooney | actully we do have schema validataion for thsi | 12:59 |
| sean-k-mooney | https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/api/openstack/compute/schemas/server_groups.py#L22-L67 | 12:59 |
| sean-k-mooney | but i guess that is not workign i need to confrim what is being repoted downstream | 12:59 |
| stephenfin | sean-k-mooney: gibi: gmann: Yeah, there's a request to undo the validation of what we pass to the API in OSC because its seems someone is relying on this broken behavior https://storyboard.openstack.org/#!/story/2008975 | 13:10 |
| sean-k-mooney | so i thikn we need to figure out why the json schema validation is not rejectign there request and fix that and backport it in thet api | 13:13 |
| sean-k-mooney | we could have a workaround config option to disable that but this is not a valid extenion point today | 13:14 |
| gibi | I agree that we should validate the policy | 13:15 |
| gibi | so let's fix it | 13:15 |
| gibi | and backport it | 13:15 |
| gibi | I'm meh on providing the workaround config | 13:15 |
| gibi | if we do that the the default should be still to validate the policy | 13:15 |
| sean-k-mooney | the real question is why is the existing code not validating it when we have the json scmea files to do that and unit test that apprently are testing the validation | 13:15 |
| sean-k-mooney | gibi: yep agreed if we have a config option it shoudl default to validating | 13:16 |
| gibi | good question. unfortunately I have swamped with other things right now | 13:16 |
| sean-k-mooney | am.... wehre do we actully do the jsonscema validation fo the api schema https://codesearch.opendev.org/?q=jsonschema&i=nope&files=&excludeFiles=&repos=openstack/nova | 13:57 |
| sean-k-mooney | ah this is how we import them https://codesearch.opendev.org/?q=from%20nova.api.openstack.compute.schemas%20import&i=nope&files=nova%2Fapi&excludeFiles=&repos=openstack/nova | 14:27 |
| sean-k-mooney | and this is where we use the server group schema https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/server_groups.py#L26 | 14:27 |
| sean-k-mooney | and this is where we apply the vlaidations https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/server_groups.py#L182-L184 | 14:29 |
| gibi | sean-k-mooney: there is a bug around VDPA https://bugs.launchpad.net/nova/+bug/1933096 | 14:42 |
| sean-k-mooney | that should not happen | 14:43 |
| sean-k-mooney | we have a version check for this | 14:43 |
| sean-k-mooney | let me triple check but im pretty sure we only try to use that if libvirt is knew enouch | 14:44 |
| sean-k-mooney | its used here https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/host.py#L1338 | 14:47 |
| sean-k-mooney | which is called form here https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/vif.py#L537-L540 | 14:48 |
| sean-k-mooney | i guess we dont have a libvirt verion check here | 14:49 |
| sean-k-mooney | but they would only hit this if they were using a vdpa port with a version of libvirt that did not uspprot this | 14:49 |
| sean-k-mooney | although form the trace it looks like this is from the perodic | 14:50 |
| sean-k-mooney | which is protected by the version check | 14:51 |
| sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/driver.py#L7346-L7349 | 14:51 |
| gibi | sean-k-mooney: the bug report says they see it on libvirt 7.0.0 | 14:55 |
| gibi | that would pass our version check | 14:56 |
| sean-k-mooney | yep just responding i think there version fo libvirt python is older then there libvirt version | 14:56 |
| sean-k-mooney | which is not supported | 14:56 |
| sean-k-mooney | hum successfully installed libvirt-python-7.4.0 | 14:59 |
| sean-k-mooney | that should work | 14:59 |
| kashyap | The libvirt commit that introduced that _CAP_VDPA should be available from v.6.9.0 (including the Pyth bindings too): | 15:16 |
| kashyap | $> git tag --sort version:refname --contains 53aec799fa31 | head -1 | 15:16 |
| kashyap | v6.9.0 | 15:16 |
| kashyap | (That was on libvirt Git repo) | 15:16 |
| sean-k-mooney | yep next thing to check is the libvirt-python version on pypi | 15:21 |
| sean-k-mooney | so "sean@p50:~/Downloads/libvirt-python-7.4.0$ grep -i VDPA -r *" should have found something but it has not | 15:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: libvirt: Always delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/797428 | 15:36 |
| gibi | nova weekly meeting starts in 6 minutes here in the channel | 15:53 |
| gibi | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jun 22 16:00:05 2021 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | \o | 16:00 |
| dansmith | o/ (kinda) | 16:00 |
| sean-k-mooney | o/ | 16:01 |
| elodilles | o/ | 16:01 |
| gibi | \o | 16:01 |
| alistarle | o/ | 16:02 |
| gibi | #topic Bugs (stuck/critical) | 16:02 |
| gibi | No critical bugs | 16:02 |
| gibi | #link 21 new untriaged bugs (+7 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | 16:02 |
| stephenfin | o/ | 16:02 |
| gibi | our backlog is growing so please if you have some time then look at it and triage some bugs | 16:02 |
| gibi | is there any specific bug that we need to discuss now? | 16:03 |
| sean-k-mooney | gibi: i am pretty sure that https://bugs.launchpad.net/nova/+bug/1933096 | 16:04 |
| sean-k-mooney | is a bug in ther ci env | 16:04 |
| sean-k-mooney | so hopefully we can close that soon | 16:04 |
| gibi | sean-k-mooney: cool. thanks for looking into that | 16:04 |
| gibi | if nothing else then | 16:05 |
| gibi | #topic Gate status | 16:05 |
| gibi | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | 16:05 |
| bauzas | gibi: I'll look at open bugs | 16:06 |
| gibi | bauzas: thank you | 16:06 |
| gibi | I don't see fresh gate bug in that list | 16:06 |
| gibi | last week we merged couple of fixes | 16:06 |
| gibi | how do you feel, does the gate improved? | 16:06 |
| sean-k-mooney | am any suggestions on who i should ping to move https://review.opendev.org/c/openstack/devstack/+/796826 along in devstack | 16:06 |
| bauzas | thanks lyarwood btw. | 16:07 |
| bauzas | for the gate failures fixes | 16:07 |
| gibi | sean-k-mooney: gmann could be one | 16:07 |
| sean-k-mooney | i assume that we are still seeing the intermitant failures due to the agent haning | 16:08 |
| sean-k-mooney | so if we can merge that sooner rather then later it should help with gate stablity | 16:08 |
| gibi | I was off yesterday and did not push any code today so I don't have the view what is failing ont he gate | 16:08 |
| gibi | but I agree that devstack patch is a good step forwa4rd | 16:08 |
| gibi | anything else about the gate? | 16:09 |
| gibi | Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly | 16:10 |
| gibi | placement jobs are green | 16:10 |
| gibi | #topic Release Planning | 16:10 |
| gibi | Milestone 2 is 15 of July which is spec freeze | 16:10 |
| gibi | Spec review day is 6th of July #link http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023083.html | 16:10 |
| gibi | anything else about the coming milestone? | 16:11 |
| gibi | #topic Stable Branches | 16:12 |
| gibi | copying notes from elodilles | 16:12 |
| gibi | stable/ussuri is blocked (fix needs to be merged: https://review.opendev.org/c/openstack/nova/+/794675 ) | 16:12 |
| gibi | other branches should be OK (however, there are quite frequent volume detach failures for example on stable/victoria) | 16:13 |
| gibi | stable/ocata branches of nova are EOL, branches are deleted ( https://review.opendev.org/c/openstack/releases/+/795664 ) | 16:13 |
| gibi | EOM | 16:13 |
| elodilles | sorry, I was lost in the ussuri gate fixing patches, | 16:13 |
| gibi | the detach failure has a fix on master | 16:13 |
| elodilles | i will try to sort it out in the coming days | 16:13 |
| gibi | https://review.opendev.org/c/openstack/nova/+/796255 | 16:13 |
| gibi | this needs to be backported I think | 16:14 |
| gibi | hm | 16:14 |
| gibi | no\ | 16:14 |
| gibi | sorry | 16:14 |
| gibi | I'm not sure | 16:14 |
| gibi | that fix helps with the detach issue on master where we have the new notification based detach | 16:15 |
| sean-k-mooney | it would need to be backported to any release using the events? | 16:15 |
| sean-k-mooney | but not where we poll? | 16:15 |
| sean-k-mooney | so if we backport the events based detach we need to backport both | 16:16 |
| gibi | sean-k-mooney: that is my understanding yes | 16:16 |
| elodilles | I saw lot of failures in victoria as I said, can it be valid backport there? | 16:16 |
| sean-k-mooney | i think its a relitivly safe backport in either case | 16:17 |
| gibi | elodilles: the detach modification is pretty huge patch but it does not change external interfaces | 16:17 |
| sean-k-mooney | gibi: did we backport your events patch to victoria? | 16:17 |
| gibi | so from process perspective it is backportable | 16:17 |
| gibi | sean-k-mooney: no | 16:17 |
| gibi | I dont think so | 16:18 |
| elodilles | anyway, that sound good (except that it's a huge patch :S), I'll add this to my TODO to investigate :) | 16:18 |
| sean-k-mooney | so the failure on vicotria are proably not related to OPERATION_FAILED | 16:18 |
| gibi | sean-k-mooney: yeah | 16:18 |
| sean-k-mooney | elodilles: wehre they OPERATION_FAILED specifcialy or was it just detach failures | 16:18 |
| elodilles | well, the usual error: volume ... failed to detach (in XXXX state ) something | 16:19 |
| sean-k-mooney | ok then that is likely not related to https://review.opendev.org/c/openstack/nova/+/796255 | 16:19 |
| gibi | sean-k-mooney: I dont think nova logs the sepcific error code | 16:19 |
| elodilles | :-/ | 16:19 |
| sean-k-mooney | we can review after the meeting if you have an example | 16:19 |
| elodilles | sure, thanks! | 16:20 |
| gibi | ack | 16:20 |
| sean-k-mooney | gibi: we might see it in the libvirt log in the ci run not sure but just a guess | 16:20 |
| gibi | ok | 16:20 |
| gibi | any other stable related issue? | 16:20 |
| elodilles | nothing else i think :X | 16:21 |
| gibi | #topic Sub/related team Highlights | 16:22 |
| gibi | Libvirt (bauzas) | 16:22 |
| bauzas | just one thing, we discussed about https://review.opendev.org/c/openstack/nova/+/769614 about how to help operators to know about a behaviour modification for a libvirt issue | 16:22 |
| bauzas | we had some argument about some relnote reno section | 16:23 |
| bauzas | but, | 16:23 |
| bauzas | eventually, I +Wd the fix | 16:23 |
| gibi | bauzas: what is the summary? | 16:23 |
| bauzas | do we need to create some better way to tell operators that we no longer verify the cpu topologies ? | 16:24 |
| sean-k-mooney | yes just noticed if you really wanted me to update it i was ok with that just wanted you and stephenfin to agree on a path forward | 16:24 |
| bauzas | gibi: this ^ | 16:24 |
| bauzas | basically, flavors could continue to have the same extraspecs | 16:24 |
| stephenfin | bauzas: I'm still not sure what you're asking for. Are you suggesting we drop the 'upgrade' section? | 16:25 |
| bauzas | stephenfin: no, not about this | 16:25 |
| bauzas | stephenfin: about whether we would need more some kind of documentation for this | 16:25 |
| stephenfin | oh, that | 16:25 |
| sean-k-mooney | oh ok you were conserened if we needed to document it at all | 16:26 |
| sean-k-mooney | not how we did it | 16:26 |
| bauzas | yup | 16:26 |
| sean-k-mooney | ok i tought you just wanted it in the fixes section so i missed that in your previous comments | 16:26 |
| stephenfin | My personal opinion is no. We never documented this behaviour and we never agreed to guarantee it. I wanted to include the release note simply as a courtesy | 16:26 |
| bauzas | basically, the flavors would continue to be the same, it's just the libvirt driver that won't longer verify them | 16:26 |
| stephenfin | similar to how we announce virt API changes, even though we don't support out-of-tree virt drivers | 16:26 |
| stephenfin | I think you've misunderstood things. Nothing changes in what we verify | 16:27 |
| sean-k-mooney | well its not about verificaiotn is that we change unspecified behavior to different unspecifed behavior | 16:27 |
| bauzas | stephenfin: fair enough, I'm having the same opinion but I'm asking the community here if they have concerns | 16:27 |
| stephenfin | yes, what Sean said | 16:27 |
| gibi | if we are changing undefined behavior then reno is just an extra, but not at all mandatory. | 16:28 |
| stephenfin | we had a hidden behavior where we would try to match the number of guest CPU "threads" to the number of host CPU threads | 16:28 |
| stephenfin | but it was hidden. We didn't even know it existed until sean-k-mooney started fixing this bug | 16:28 |
| bauzas | yes, just a performance kind of help | 16:28 |
| stephenfin | exactly. An optimization at most | 16:28 |
| bauzas | okay, any concerns ? | 16:28 |
| bauzas | if not, I'm OK | 16:28 |
| gibi | I'm Ok too | 16:28 |
| gibi | stephenfin, sean-k-mooney: is is settled from your perspective too? | 16:29 |
| stephenfin | no issues from me | 16:29 |
| sean-k-mooney | yep | 16:29 |
| sean-k-mooney | i did not have a stong opiion | 16:29 |
| bauzas | k, that's it for me | 16:29 |
| gibi | ok, thanks | 16:29 |
| gibi | #topic Open discussion | 16:29 |
| gibi | there is one topic | 16:30 |
| gibi | (wenpingsong) vGPU spec reviewing: as we discussed during ptg, cyborg-managed/nova-managed gpu should have a trait indicating who owns this gpu, thanks for bauzas's comments with different thoughts about the trait. We need to have an agreement on that. https://review.opendev.org/c/openstack/nova-specs/+/780452 (can't attending the meeting due to the time slot, but will check the logs later) | 16:30 |
| gibi | as far as I understand we originally suggested the owner traits | 16:30 |
| gibi | but bauzas now suggest using separate RC | 16:30 |
| gibi | for cyborg managed vgpus | 16:30 |
| gibi | this way the trait would not be needed | 16:30 |
| sean-k-mooney | both could work | 16:30 |
| bauzas | my -1 was just for discussing about it | 16:31 |
| gibi | I guess we don't have the use case: Give me a vgpu I don't care if it is cyborg or nova managed | 16:31 |
| bauzas | given I was also working on the mdev spec | 16:31 |
| bauzas | I thought about it | 16:31 |
| sean-k-mooney | owner traits i guess could have upgrade issues | 16:31 |
| bauzas | and I'm not sure we need a "nova" trait | 16:31 |
| sean-k-mooney | e.g. if you upgrade cyborg first | 16:31 |
| sean-k-mooney | without upgrading nova to support owner traits | 16:31 |
| bauzas | I know tho we said we would do it at some PTG | 16:32 |
| bauzas | so I'm sorry to reopen the can | 16:32 |
| sean-k-mooney | well no i think there is a usecase for a nova triat | 16:32 |
| sean-k-mooney | or well RP ownwer in general | 16:32 |
| sean-k-mooney | not nessiarly a trait | 16:32 |
| bauzas | it's the other way of a consumer type :) | 16:33 |
| bauzas | something like a inventory type :) | 16:33 |
| sean-k-mooney | so its a provider type :) | 16:33 |
| bauzas | yeah | 16:33 |
| bauzas | tbh, I don't really like us marking traits for things unnecessary | 16:34 |
| sean-k-mooney | am would it be better to continue this discsssuon on the spec. was tehre a summary you wanted to give in real time | 16:34 |
| bauzas | agreed | 16:34 |
| bauzas | not sure we can have a consensus now | 16:34 |
| gibi | agreed too, I don't have the brainpower to think this through right now | 16:35 |
| bauzas | but I want us to think more about this | 16:35 |
| bauzas | and again, I'm sorry to hold a bit the spec | 16:35 |
| gibi | no worries | 16:35 |
| sean-k-mooney | once we add a trai we cant remove them so we shoudl get this right | 16:35 |
| bauzas | but if we are about to be generic, we could also help cyborg I think | 16:35 |
| bauzas | sean-k-mooney: unfortunately yes | 16:36 |
| sean-k-mooney | unless we used CUSTOM_OWNER i guess we cloud i will try and read the spec again tomorow | 16:36 |
| bauzas | maybe it's also the fact that a 'nova' trait seems to me bizarre | 16:36 |
| gibi | OK, continue this in the spec | 16:36 |
| sean-k-mooney | i dont think we shoudl treat nova as special in placment | 16:37 |
| gibi | any other topic for today? | 16:37 |
| bauzas | with jay's mind, I would transform this into "I can support 'nova'" | 16:37 |
| sean-k-mooney | not form me | 16:37 |
| bauzas | gibi: nope, I'm done | 16:37 |
| sean-k-mooney | bauzas: well it would mean "i can support consumtion by nova" but that just a detail | 16:38 |
| bauzas | sean-k-mooney: that's why I think the name is wrong | 16:38 |
| gibi | if nothing else then I close the meeting and you can continue :) | 16:38 |
| gibi | #endmeeting | 16:38 |
| opendevmeet | Meeting ended Tue Jun 22 16:38:52 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:38 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.html | 16:38 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.txt | 16:38 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.log.html | 16:38 |
| bauzas | thanks gibi | 16:39 |
| elodilles | o/ | 16:39 |
| gibi | from one hand OWNER_NOVA is a trait as it is a qualitative thing not a quantitative one | 16:39 |
| bauzas | surely | 16:39 |
| gibi | and if we ever want to mix nova managed vgpus with cyborg managed ones then we need a common RC | 16:39 |
| gibi | but I'm not sure about we ever want to mix | 16:40 |
| bauzas | gibi: OWNED_BY_NOVA would be a better name | 16:40 |
| bauzas | but it's a bikeshed | 16:40 |
| sean-k-mooney | gibi: well i dotn think we want to mix it via just resouce:vgpu | 16:40 |
| gibi | agree | 16:40 |
| gibi | d | 16:40 |
| elodilles | sean-k-mooney: sorry, I forgot that I need to leave now :S I'll search for example failures that we can look at tomorrow | 16:40 |
| bauzas | gibi: that's why I think we need different RCs | 16:40 |
| sean-k-mooney | cyborg one will always come form a device-profile | 16:40 |
| elodilles | sean-k-mooney: if that is OK for you o:) | 16:40 |
| gibi | if we never mix, then I'm fine with the different RC | 16:40 |
| bauzas | gibi: because inventories would be managed by different services | 16:41 |
| sean-k-mooney | elodilles: cool just ping us and we can confirm if tis the same isssue or not | 16:41 |
| sean-k-mooney | elodilles: hopefully at least | 16:41 |
| bauzas | the consumption would be identical tho | 16:41 |
| elodilles | sean-k-mooney: sure, thanks! :) | 16:41 |
| sean-k-mooney | bauzas: we dont need different RC classes to mix | 16:41 |
| bauzas | sean-k-mooney: yup, the other way | 16:41 |
| sean-k-mooney | we dont need them to isolate ither | 16:42 |
| gibi | sean-k-mooney: if you even want to support give-me-a-vgpu-i-dont-care-if-nova-or-cyborg-managed then we need a common pool of resource and therefore a common RC | 16:42 |
| bauzas | sean-k-mooneybut I'm not sure marking an inventory by a trait for knowing about the owner is the best | 16:42 |
| sean-k-mooney | a trait + RC can do eveything 2 RC classes can do since we do not allow two services to create inventories on teh same RP | 16:42 |
| sean-k-mooney | gibi: right if we want to supprot that your are corect a common resouce class woudl be required | 16:43 |
| gibi | if we don't what that then no need for a common RC | 16:43 |
| bauzas | but I think we're missing some logic | 16:43 |
| sean-k-mooney | bauzas: its marking the RP not the inventory | 16:44 |
| bauzas | either we wanna mix, and then we don't need to know which inventory was created by who | 16:44 |
| sean-k-mooney | bauzas: we do | 16:44 |
| bauzas | or, we just make resources alongside | 16:44 |
| bauzas | and then we don't need the RCs to be the same | 16:44 |
| sean-k-mooney | we do not allow 2 services to modify the same resouce provider | 16:44 |
| bauzas | really ? | 16:45 |
| bauzas | I don't think we want to avoid this | 16:45 |
| sean-k-mooney | so fi we have ownert traits or resocue classes we are fine | 16:45 |
| bauzas | the generation bit is even for distributed servcies | 16:45 |
| gmann | sean-k-mooney: stephenfin gibi can you point me to bug where server group validation did not work. I can see test validating the scema also - https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_server_groups.py#L459 | 16:45 |
| sean-k-mooney | bauzas: we dont allow it becaue the virt driver will replace the traits on the RP | 16:45 |
| stephenfin | gmann: not the exact bug but https://storyboard.openstack.org/#!/story/2008975 and https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a210a58008b631521025be7f3eb | 16:46 |
| stephenfin | I just posted to openstack-discuss about this | 16:46 |
| sean-k-mooney | bauzas: and it will update the inventoris based on its local view | 16:46 |
| gibi | I have to drop of now. I will read back tomorrow | 16:46 |
| gmann | stephenfin: ok, thanks checking | 16:46 |
| bauzas | sean-k-mooney: how placement know which service owns which RP ? | 16:47 |
| sean-k-mooney | bauzas: it does not and it does not enforce it | 16:47 |
| bauzas | sean-k-mooney: that's my point | 16:47 |
| sean-k-mooney | we enforce this today by tellint neutorn and cybrog they may not modify our RPs | 16:47 |
| bauzas | we're blindly recreating a RP | 16:47 |
| gmann | stephenfin: so this is about removing the validation not that current validation did not work right? | 16:47 |
| sean-k-mooney | bauzas: yep | 16:47 |
| stephenfin | gmann: the bug is about removing the API validation from the client. sean-k-mooney is saying that the server validation isn't working though | 16:48 |
| sean-k-mooney | well not quite | 16:48 |
| bauzas | sean-k-mooney: that's my point, some service owns some RP | 16:48 |
| bauzas | it's just nova/placement which doesn't support it | 16:48 |
| sean-k-mooney | stephenfin: gmann im saying that the customer reported it worked and i cant see how the server validation would not block this | 16:49 |
| bauzas | so | 16:49 |
| bauzas | say cyborg creates some RPs | 16:49 |
| bauzas | and nova too | 16:49 |
| bauzas | both are different but have the same RCs | 16:49 |
| spatel | sean-k-mooney hey! had quick question related Cellv2 design, does neutron can be scale using cellv2 or just nova? | 16:49 |
| gmann | sean-k-mooney: stephenfin yeah it is rejected from server side in v2.1 at least (v2 old code I am not sure) | 16:49 |
| bauzas | sean-k-mooney: then why should we have problems if a flavor is asking for some vGPUs ? | 16:50 |
| sean-k-mooney | gmann: it shoudl be rejected in 2.0 based on the validation | 16:50 |
| bauzas | sean-k-mooney: this would eventually go to the libvirt driver | 16:50 |
| bauzas | which would know whether the allocated RP is owned by it or cyboth | 16:50 |
| sean-k-mooney | bauzas: right now cybrog neutron and other prject cannot use any standard RC used by nova | 16:50 |
| gmann | sean-k-mooney: v2 code path was different until we merged it. I am not sure if user using that much old nova | 16:50 |
| sean-k-mooney | gmann: ah good point it was working for them on osp 13 which is queens and not workin on osp 16 whic is train | 16:51 |
| gmann | sean-k-mooney: and in old v2 code path I think we did not had schema validation. its v2.1 introducing the JSON schema validation in more strict way | 16:51 |
| sean-k-mooney | bauzas: perhaps we could just have a google meet call | 16:52 |
| bauzas | sean-k-mooney: unfortunately, I need to stop in 5 mins | 16:52 |
| bauzas | gosh I miss PTGs | 16:52 |
| bauzas | and f2f meetings | 16:52 |
| bauzas | and whiteboards | 16:52 |
| sean-k-mooney | bauzas: we can talk tabout it tomorrow then but tl;dr; today no too openstack service can use the same RC class and no two openstack service can share the same RP | 16:53 |
| bauzas | I could even show source code | 16:53 |
| sean-k-mooney | bauzas: the ownwer triat was a way to allow reuse of stanard RCs across services | 16:53 |
| bauzas | sean-k-mooney: based on your first assumption, that means cyborg can't provide VGPU resources ? | 16:53 |
| bauzas | sean-k-mooney: gosh, this sounds hacky | 16:53 |
| sean-k-mooney | correct which is why the ownwer trait was intoduced in the spec | 16:54 |
| gmann | sean-k-mooney: Mitaka was last with legacy v2 code and since newton we started single code path for v2 and v2.1 which has these schema validation | 16:54 |
| sean-k-mooney | without an owner of the resouce provider in some form resouce classes cant be shared | 16:54 |
| bauzas | sean-k-mooney: honestly, I'd prefer us to have a way to know about which service owns a RP with by default be 'nova' | 16:54 |
| bauzas | meaning another attribute of a RP | 16:55 |
| sean-k-mooney | bauzas: well that is exactly what the ownwer traits were ment to be | 16:55 |
| sean-k-mooney | bauzas: since peole did not want a dedicated value on the RP | 16:55 |
| bauzas | the owner trait is just a hack because we wanna make it round | 16:55 |
| sean-k-mooney | bauzas: we proposed added ownwer before and peopel objected | 16:55 |
| bauzas | sean-k-mooney: then I don't guess why we need to explicitely mark a nova trait | 16:55 |
| sean-k-mooney | we can certenly do that again but the default shoudl nto be nova | 16:56 |
| gmann | sean-k-mooney: stephenfin ohk its modified code he mentioned in github discussion so upstream code is all good | 16:56 |
| bauzas | sean-k-mooneythe default should what ? | 16:56 |
| sean-k-mooney | bauzas: empty | 16:56 |
| sean-k-mooney | bauzas: placment should not prefer nova over other services | 16:56 |
| bauzas | empty meaning ? | 16:56 |
| sean-k-mooney | meaning unowned | 16:57 |
| bauzas | this is wrong | 16:57 |
| sean-k-mooney | bascaly we ould need a reshape | 16:57 |
| bauzas | any RP is owned by something | 16:57 |
| sean-k-mooney | wel just update | 16:57 |
| sean-k-mooney | to populated it for nova RPs | 16:57 |
| sean-k-mooney | gmann: thanks ill feed that back downstream unless you commented on ghitbub already? | 16:58 |
| bauzas | sean-k-mooney: I need to hardstop but let's continue the convo with gibi later tomorrow | 16:58 |
| gmann | sean-k-mooney: doing on github | 16:58 |
| sean-k-mooney | bauzas: ack o/ | 16:58 |
| sean-k-mooney | gmann: thanks | 16:59 |
| bauzas | sean-k-mooney: I guess I'm afraid by all the implications of tagging our RPs explicitely | 16:59 |
| sean-k-mooney | bauzas: whcih is why we need to discuss in a spec :) | 16:59 |
| bauzas | and I just wanna be sure this is the only possibility | 16:59 |
| bauzas | sean-k-mooney: think about something until tomorrow | 17:00 |
| * sean-k-mooney breaths as the 3 conversation i was having in paralle all come to an end | 17:00 | |
| bauzas | sean-k-mooney: would it be a problem if nova would create RPs with VGPUs in it, while cyborg creates RPs with VGPU in them too, and eventually the allocation would go straight to the nova-compute service holding the allocated RP | 17:01 |
| bauzas | I just feel the nova-compute service could know which RPs is owned by who | 17:01 |
| bauzas | and defer to cyborg-agent binding if so | 17:03 |
| bauzas | or just call libvirt if the allocated RP was owned by nova | 17:03 |
| opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Remove 'USES_ALLOCATION_CANDIDATES' https://review.opendev.org/c/openstack/nova/+/773640 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Remove 'hosts_up' https://review.opendev.org/c/openstack/nova/+/773641 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: trivial: Remove FakeScheduler (for realz) https://review.opendev.org/c/openstack/nova/+/773642 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Merge 'FilterScheduler' into base class https://review.opendev.org/c/openstack/nova/+/773643 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers https://review.opendev.org/c/openstack/nova/+/773645 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager https://review.opendev.org/c/openstack/nova/+/773644 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases https://review.opendev.org/c/openstack/nova/+/773647 | 17:04 |
| opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: 'USES_ALLOCATION_CANDIDATES' removal cleanup https://review.opendev.org/c/openstack/nova/+/797513 | 17:04 |
| bauzas | sean-k-mooney: this isn't a scheduling decision until you wanna explicitely shard your resources between nova and cyborg (the non-mixed case) | 17:04 |
| bauzas | and for the non-mixed case, we can have different RCs | 17:04 |
| bauzas | instead of a owner trait | 17:04 |
| * bauzas needs to run now | 17:05 | |
| sean-k-mooney | bauzas: if the request is in the flavor and ti does not come form a device profile then nova shoudl ensure it does not come form an nova created RP | 17:05 |
| sean-k-mooney | the instresting part is if you have resouces:vgpu=1 | 17:06 |
| bauzas | the mixed case | 17:06 |
| sean-k-mooney | which today can only come form nova | 17:06 |
| bauzas | the non-mixed case can be solved with custom RCs | 17:06 |
| sean-k-mooney | and the question then is what hsoudl the bhavior be in the absense of a trait | 17:06 |
| sean-k-mooney | anyway let talk tommorow | 17:07 |
| bauzas | for the mixed case, you can admit that it's OK for a spawn to go to the nova-compute | 17:07 |
| bauzas | and then the nova-compute can either call cyborg-agent to bind | 17:07 |
| bauzas | or, call libvirt to just spawn | 17:07 |
| sean-k-mooney | no that is not ok | 17:07 |
| sean-k-mooney | well maybe | 17:07 |
| sean-k-mooney | but it would be rather complicated | 17:07 |
| sean-k-mooney | ill think about it tonight | 17:08 |
| bauzas | we already get allocations before we call libvirt | 17:08 |
| sean-k-mooney | but it would require change not currently in the spec | 17:08 |
| bauzas | so we already know the allocated RPs | 17:08 |
| sean-k-mooney | bauzas: correct but we will need the condurtor to determin if the rp in the allocation is owned by nova or cyborg | 17:09 |
| bauzas | it's just the nova-compute service which doesn't care and directly passes the allocations as arguments | 17:09 |
| sean-k-mooney | and then have it start the bidning before we call the compute node | 17:09 |
| opendevreview | Merged openstack/nova master: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/769614 | 17:09 |
| sean-k-mooney | sicne we do the arq binding in the conductor | 17:09 |
| bauzas | sean-k-mooney: that's not the workflow I see in https://review.opendev.org/c/openstack/nova-specs/+/780452/8/specs/xena/approved/support-vGPU-nova-cyborg-interaction.rst#132 | 17:09 |
| sean-k-mooney | and without a device procfile we will not know how to create teh arq | 17:09 |
| bauzas | holy shit | 17:09 |
| bauzas | 'nova's is both the conductor and the compute service | 17:09 |
| sean-k-mooney | so we cant make that work without changing the cybrog api | 17:09 |
| bauzas | in the workflow diagram | 17:10 |
| bauzas | well, we get allocations in the conductor, right? | 17:10 |
| bauzas | in order to know which compute services to call, right? | 17:10 |
| sean-k-mooney | yes and we create and bind arqs in the conductor too | 17:10 |
| bauzas | ok, so it's just an extra bit | 17:10 |
| sean-k-mooney | but to create an arq we need a device profile | 17:10 |
| sean-k-mooney | so if we have resouce:vgpu in the flavor it cant be used to create a cybrog ARQ today as we dont have a device profile | 17:11 |
| bauzas | sure, I see it in the diagram | 17:11 |
| *** rpittau is now known as rpittau|afk | 17:11 | |
| bauzas | we create a device profile before we call scheduling, right? | 17:12 |
| sean-k-mooney | so right now a refilter can eailar determin if the vgpu request is from nvoa or cyborg | 17:12 |
| sean-k-mooney | bauzas: yes its a resouce in the cyborg api | 17:12 |
| bauzas | because we never mix | 17:12 |
| sean-k-mooney | so the admihn create a device profile and then creates a flavor that refrence s it | 17:12 |
| sean-k-mooney | bauzas: a device profile is like a pci aliasa | 17:12 |
| bauzas | yup, I got it | 17:13 |
| sean-k-mooney | your are 13 mins passed your hard stop :) | 17:13 |
| bauzas | but it's premature I think to get a device profile based on an assumption that a flavor asked for a vgpu | 17:13 |
| sean-k-mooney | bauzas: that not how that works | 17:14 |
| bauzas | you should get the device profile only if the allocated resource is owned by cyborg | 17:14 |
| bauzas | sean-k-mooney: I know | 17:14 |
| sean-k-mooney | right now the only way to request cybrog resoruce is via a device profile | 17:14 |
| sean-k-mooney | supprot cybrog via the resouce: sysntax is totallyout of scope | 17:14 |
| bauzas | sean-k-mooney: I understand and I don't wanna change this | 17:14 |
| bauzas | ok, ok, | 17:15 |
| bauzas | so a flavor is set with a device profile that's turned into a resources query by a prefilter, right? | 17:15 |
| sean-k-mooney | yes | 17:15 |
| bauzas | in this case, there is ZERO possibility to mix resources | 17:15 |
| bauzas | whatever the resource is | 17:16 |
| sean-k-mooney | well not refilter i thik we have explict logic for cyborg | 17:16 |
| sean-k-mooney | today correct | 17:16 |
| bauzas | so the mixed case is impossible today | 17:16 |
| sean-k-mooney | yes | 17:16 |
| bauzas | so, we're discussing about non-mixed resources | 17:16 |
| bauzas | which can be solved with custom RCs | 17:16 |
| sean-k-mooney | unless tehy break one fo the rule we have about palcment useage | 17:16 |
| sean-k-mooney | bauzas: it can but it does not have to be | 17:17 |
| bauzas | sean-k-mooney: the other possibility implies a huge change for existing deployments, right? | 17:17 |
| sean-k-mooney | no | 17:17 |
| sean-k-mooney | not really | 17:17 |
| sean-k-mooney | just that we would add a trait to all nova rps | 17:18 |
| sean-k-mooney | and we would automatically add it with a prefilter | 17:18 |
| bauzas | yup, I got this, this is a technical answer | 17:18 |
| bauzas | which prevents us to discuss about alternatives | 17:18 |
| sean-k-mooney | we can discuss alternitves | 17:19 |
| bauzas | and the one I'm proposing (again, for the non-mixed case) doesn't imply upgrade impacts | 17:19 |
| sean-k-mooney | but we have discsuted this for 2+ cycle now | 17:19 |
| sean-k-mooney | correct but it means we dotn need os-resouce classes | 17:19 |
| sean-k-mooney | since resouce classes will have to be different per service | 17:19 |
| sean-k-mooney | so its not free | 17:20 |
| sean-k-mooney | bauzas: if we ant differnt service to use diffeernt resouces classes for the same resouce class we can do that | 17:20 |
| bauzas | the whole situation is that we need some scheduling query for telling "yo' I really want cyborg" | 17:20 |
| sean-k-mooney | but its restricting the usfulness of placment | 17:20 |
| sean-k-mooney | or i really want nova but yes | 17:21 |
| sean-k-mooney | which is why the ownwer trait was proposed so we could make a qualitave statmetn about the resouce provier | 17:21 |
| bauzas | nope, in general, you don't need to tell placement "give me nova stuff" | 17:22 |
| bauzas | because if you ask for nova resouces, you get nova stuff | 17:22 |
| sean-k-mooney | you may not | 17:22 |
| bauzas | agreed | 17:22 |
| sean-k-mooney | zun could create RPs with cpu ram and disk | 17:22 |
| bauzas | if cinder was using placement for their own volumes | 17:23 |
| bauzas | you could ask placement for things that nova doesn't knoxw | 17:23 |
| sean-k-mooney | yes | 17:23 |
| bauzas | zun is a good example | 17:23 |
| sean-k-mooney | we have demonstarted that with provider.yaml also | 17:23 |
| sean-k-mooney | bauzas: i think you jsut made an argument indirecly that i might be able to get behind | 17:24 |
| sean-k-mooney | i never want people ot user resouce_# syntax with traits_# sysntax in teh falvor directly | 17:24 |
| sean-k-mooney | e.g. i dont want people to have to use the placmenet group sysntax in flavors | 17:25 |
| sean-k-mooney | so if we are getttign resouce owned by differetn service i dont want them to have to specify traits in request groups in the flavor | 17:25 |
| bauzas | that's reasonable | 17:26 |
| sean-k-mooney | with different resouce_class we dont have to do this | 17:26 |
| sean-k-mooney | along as we dont share resouce classes or do it in a managed way | 17:26 |
| sean-k-mooney | e.g. cindr can use the disk_GB resouce class as long as it does so useing sharing aggreates and does nto create RPs or inventorees under the compute | 17:27 |
| sean-k-mooney | cyborg could use vgpu rc in the same way but only if its not under the compute RP | 17:28 |
| sean-k-mooney | well hum no i need to take a break and think about this with a clear head | 17:28 |
| bauzas | me too | 17:28 |
| bauzas | my hardstop was a softstop | 17:29 |
| bauzas | but my wife should kill me if I'm still writing in 2 mins | 17:29 |
| bauzas | (me joking tbc) | 17:29 |
| sean-k-mooney | i think im going to finsih here also :) | 17:29 |
| *** iurygregory_ is now known as iurygregory | 18:39 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!