| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 16:32:56 | sean-k-mooney | not nessiarly a trait | |
| 16:33:33 | bauzas | it's the other way of a consumer type :) | |
| 16:33:45 | bauzas | something like a inventory type :) | |
| 16:33:49 | sean-k-mooney | so its a provider type :) | |
| 16:33:58 | bauzas | yeah | |
| 16:34:24 | bauzas | tbh, I don't really like us marking traits for things unnecessary | |
| 16:34:43 | 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:51 | bauzas | agreed | |
| 16:34:59 | bauzas | not sure we can have a consensus now | |
| 16:35:11 | gibi | agreed too, I don't have the brainpower to think this through right now | |
| 16:35:12 | bauzas | but I want us to think more about this | |
| 16:35:26 | bauzas | and again, I'm sorry to hold a bit the spec | |
| 16:35:39 | gibi | no worries | |
| 16:35:45 | sean-k-mooney | once we add a trai we cant remove them so we shoudl get this right | |
| 16:35:53 | bauzas | but if we are about to be generic, we could also help cyborg I think | |
| 16:36:06 | bauzas | sean-k-mooney: unfortunately yes | |
| 16:36:34 | sean-k-mooney | unless we used CUSTOM_OWNER i guess we cloud i will try and read the spec again tomorow | |
| 16:36:44 | bauzas | maybe it's also the fact that a 'nova' trait seems to me bizarre | |
| 16:36:50 | gibi | OK, continue this in the spec | |
| 16:37:07 | sean-k-mooney | i dont think we shoudl treat nova as special in placment | |
| 16:37:09 | gibi | any other topic for today? | |
| 16:37:17 | bauzas | with jay's mind, I would transform this into "I can support 'nova'" | |
| 16:37:19 | sean-k-mooney | not form me | |
| 16:37:32 | bauzas | gibi: nope, I'm done | |
| 16:38:33 | sean-k-mooney | bauzas: well it would mean "i can support consumtion by nova" but that just a detail | |
| 16:38:45 | bauzas | sean-k-mooney: that's why I think the name is wrong | |
| 16:38:51 | gibi | if nothing else then I close the meeting and you can continue :) | |
| 16:38:52 | gibi | #endmeeting | |
| 16:38:52 | 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:52 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.html | |
| 16:38:52 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.txt | |
| 16:38:52 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-22-16.00.log.html | |
| 16:39:04 | bauzas | thanks gibi | |
| 16:39:08 | elodilles | o/ | |
| 16:39:27 | gibi | from one hand OWNER_NOVA is a trait as it is a qualitative thing not a quantitative one | |
| 16:39:42 | bauzas | surely | |
| 16:39:50 | gibi | and if we ever want to mix nova managed vgpus with cyborg managed ones then we need a common RC | |
| 16:40:01 | gibi | but I'm not sure about we ever want to mix | |
| 16:40:04 | bauzas | gibi: OWNED_BY_NOVA would be a better name | |
| 16:40:11 | bauzas | but it's a bikeshed | |
| 16:40:21 | sean-k-mooney | gibi: well i dotn think we want to mix it via just resouce:vgpu | |
| 16:40:32 | gibi | agree | |
| 16:40:35 | gibi | d | |
| 16:40:38 | 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:38 | bauzas | gibi: that's why I think we need different RCs | |
| 16:40:40 | sean-k-mooney | cyborg one will always come form a device-profile | |
| 16:40:57 | elodilles | sean-k-mooney: if that is OK for you o:) | |
| 16:40:59 | gibi | if we never mix, then I'm fine with the different RC | |
| 16:41:00 | bauzas | gibi: because inventories would be managed by different services | |
| 16:41:03 | sean-k-mooney | elodilles: cool just ping us and we can confirm if tis the same isssue or not | |
| 16:41:08 | sean-k-mooney | elodilles: hopefully at least | |
| 16:41:15 | bauzas | the consumption would be identical tho | |
| 16:41:20 | elodilles | sean-k-mooney: sure, thanks! :) | |
| 16:41:37 | sean-k-mooney | bauzas: we dont need different RC classes to mix | |
| 16:41:48 | bauzas | sean-k-mooney: yup, the other way | |
| 16:42:02 | sean-k-mooney | we dont need them to isolate ither | |
| 16:42:40 | 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: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:43 | 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:43:19 | sean-k-mooney | gibi: right if we want to supprot that your are corect a common resouce class woudl be required | |
| 16:43:34 | gibi | if we don't what that then no need for a common RC | |
| 16:43:37 | bauzas | but I think we're missing some logic | |
| 16:44:05 | sean-k-mooney | bauzas: its marking the RP not the inventory | |
| 16:44:11 | bauzas | either we wanna mix, and then we don't need to know which inventory was created by who | |
| 16:44:32 | sean-k-mooney | bauzas: we do | |
| 16:44:33 | bauzas | or, we just make resources alongside | |
| 16:44:48 | bauzas | and then we don't need the RCs to be the same | |
| 16:44:48 | sean-k-mooney | we do not allow 2 services to modify the same resouce provider | |
| 16:45:00 | bauzas | really ? | |
| 16:45:07 | bauzas | I don't think we want to avoid this | |
| 16:45:09 | sean-k-mooney | so fi we have ownert traits or resocue classes we are fine | |
| 16:45:26 | bauzas | the generation bit is even for distributed servcies | |
| 16:45:36 | 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:50 | sean-k-mooney | bauzas: we dont allow it becaue the virt driver will replace the traits on the RP | |
| 16:46:22 | stephenfin | gmann: not the exact bug but https://storyboard.openstack.org/#!/story/2008975 and https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a210a58008b631521025be7f3eb | |
| 16:46:27 | stephenfin | I just posted to openstack-discuss about this | |
| 16:46:36 | sean-k-mooney | bauzas: and it will update the inventoris based on its local view | |
| 16:46:42 | gibi | I have to drop of now. I will read back tomorrow | |
| 16:46:46 | gmann | stephenfin: ok, thanks checking | |
| 16:47:06 | bauzas | sean-k-mooney: how placement know which service owns which RP ? | |
| 16:47:18 | sean-k-mooney | bauzas: it does not and it does not enforce it | |
| 16:47:32 | bauzas | sean-k-mooney: that's my point | |
| 16:47:34 | sean-k-mooney | we enforce this today by tellint neutorn and cybrog they may not modify our RPs | |
| 16:47:49 | bauzas | we're blindly recreating a RP | |
| 16:47:51 | gmann | stephenfin: so this is about removing the validation not that current validation did not work right? | |
| 16:47:54 | sean-k-mooney | bauzas: yep | |
| 16:48:22 | 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:36 | sean-k-mooney | well not quite | |
| 16:48:36 | bauzas | sean-k-mooney: that's my point, some service owns some RP | |
| 16:48:46 | bauzas | it's just nova/placement which doesn't support it | |
| 16:49:01 | 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:02 | bauzas | so | |
| 16:49:12 | bauzas | say cyborg creates some RPs | |
| 16:49:17 | bauzas | and nova too | |
| 16:49:26 | bauzas | both are different but have the same RCs | |
| 16:49:36 | spatel | sean-k-mooney hey! had quick question related Cellv2 design, does neutron can be scale using cellv2 or just nova? | |
| 16:49:42 | 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:50:04 | bauzas | sean-k-mooney: then why should we have problems if a flavor is asking for some vGPUs ? | |
| 16:50:08 | sean-k-mooney | gmann: it shoudl be rejected in 2.0 based on the validation | |
| 16:50:23 | bauzas | sean-k-mooney: this would eventually go to the libvirt driver | |