| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-04 | |||
| 15:09:08 | mnaser | https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/driver.py#L7073-L7094 | |
| 15:09:35 | mnaser | that still is supposed to execute even in pre-new-port-binding in neutron right? | |
| 15:09:47 | mnaser | sorry for all the questions, im just trying to gather some sense to figure out where the issue is | |
| 15:09:52 | sean-k-mooney | no | |
| 15:10:11 | sean-k-mooney | vifs will not be in migrate_data in queens | |
| 15:10:21 | mnaser | hmmmmm | |
| 15:10:37 | mnaser | ok that's confusing because if you remember we had that bug with host_mtu | |
| 15:10:37 | sean-k-mooney | that is how we disable it on queens to rocky | |
| 15:10:55 | mnaser | oh sorry that was in rocky only | |
| 15:13:18 | mnaser | so im assuming that because 'vifs' was added in rocky, that field will be dropped by anything running queens | |
| 15:13:27 | mnaser | so that portion should be skipped | |
| 15:13:28 | mnaser | sigh | |
| 15:17:37 | sean-k-mooney | mnaser: yes but also the vifs field is only added in one place in the conductor and the conductor checks the versions before adding it | |
| 15:18:18 | mdbooth | o/ | |
| 15:18:20 | openstackgerrit | garyk proposed openstack/nova master: Ensure that block device rollback is done when attachment fails https://review.openstack.org/622207 | |
| 15:18:21 | mnaser | sean-k-mooney: yeah and im seeing similar workflows here https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/driver.py#L7587-L7615 vs https://github.com/openstack/nova/blob/stable/queens/nova/virt/libvirt/driver.py#L7564-L7582 | |
| 15:18:31 | mnaser | so re-running with debug enabled and seeing which path it picks | |
| 15:18:33 | lyarwood | mdbooth: https://review.openstack.org/#/c/618478/ - can you take a swing at that when you have time | |
| 15:23:38 | sean-k-mooney | mnaser: if it take the one it should not let me know and we can open a bug as we intended and tried really hard not to enable unless both supproted it | |
| 15:39:55 | cfriesen | curious what people think about Sylvain's suggestion to add the ability to query server groups by server UUID instead of including the server group in the server details. | |
| 15:40:10 | cfriesen | (in the context of https://review.openstack.org/#/c/612255) | |
| 15:50:29 | bauzas | cfriesen: mmm ? | |
| 15:50:56 | bauzas | hah | |
| 15:52:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677 | |
| 15:52:15 | openstackgerrit | Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705 | |
| 15:52:15 | openstackgerrit | Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695 | |
| 15:52:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711 | |
| 15:52:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049 | |
| 15:52:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042 | |
| 15:53:50 | openstackgerrit | Eric Fried proposed openstack/nova master: Turn off rp association refresh in nova-next https://review.openstack.org/616033 | |
| 15:54:51 | cfriesen | bauzas: I think the suggestion could work, but it would probably mean that the CLI client would issue another HTTP request to get that info for each instance (unless we added a specific flag to tell it to show the groups, which seems not-friendly) | |
| 15:55:20 | bauzas | cfriesen: my biggest concern is about the inflation for the instance API | |
| 15:55:48 | cfriesen | bauzas: isn't that what pagination is for? | |
| 15:56:40 | bauzas | of course, but how many users use server groups ? | |
| 15:57:05 | cfriesen | among our users, anti-affinity is pretty common | |
| 16:00:27 | cfriesen | is there a way to do anti-affinity in placement? I know it was discussed at one point, not sure if anything came of it | |
| 16:00:50 | cdent | cfriesen: not got off the ground yet | |
| 16:01:02 | cdent | nested took all brains | |
| 16:05:57 | openstackgerrit | Jack Ding proposed openstack/nova master: [WIP] Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 16:36:42 | openstackgerrit | Merged openstack/python-novaclient master: Change openstack-dev to openstack-discuss https://review.openstack.org/621869 | |
| 16:49:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 16:56:07 | mriedem | cfriesen: i think i also suggested that in denver | |
| 16:56:26 | mriedem | ala https://developer.openstack.org/api-ref/compute/?expanded=#list-port-interfaces | |
| 16:56:33 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=#list-volume-attachments-for-an-instance | |
| 16:58:15 | mriedem | although i guess that wasn't noted in the etherpad, so maybe i thought it elsewhere | |
| 16:58:18 | cfriesen | mriedem: you mean querying server groups by instance? | |
| 16:58:34 | mriedem | yes, rather than return server group information in the servers resource api, | |
| 16:58:40 | mriedem | you filter server groups by member | |
| 16:59:03 | sean-k-mooney | jaypipes: just spent the last few minute talking to the kuryr folks they are now aware of the ML post and will follow up there. | |
| 16:59:37 | bauzas | cfriesen: I agree with mriedem | |
| 16:59:53 | sean-k-mooney | jaypipes: turns out they are storing the os-vif object in the k8s api as annotation on the pod/deployment and k8s stores them in ectd | |
| 16:59:53 | bauzas | cfriesen: ie. not directly providing a new field for the servers API | |
| 16:59:58 | cfriesen | yeah, we've already got the backend DB API to do it. If you and Sylvain are both in favour, I can recommend we switch the spec around to propose that. | |
| 17:00:11 | bauzas | cfriesen: but I'm fine with any other API endpoint | |
| 17:00:21 | bauzas | like mriedem said | |
| 17:00:43 | mriedem | let me read the spec first | |
| 17:00:57 | mriedem | i might have notes on this in my diff analysis thing too, checking | |
| 17:01:07 | cfriesen | bauzas' suggestion is listed in the "alternatives" secution | |
| 17:01:32 | mriedem | at the ptg we said we couldn't show server groups when listing servers with details b/c it would be too inefficient, so we'd restrict to just GET /servers/{server_id} (show) | |
| 17:01:52 | mriedem | but filtering server groups by member would also be useful i think and solve the same problem | |
| 17:02:18 | openstackgerrit | melissaml proposed openstack/os-traits master: Change openstack-dev to openstack-discuss https://review.openstack.org/622429 | |
| 17:02:41 | mriedem | cfriesen: yeah column 35 https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing | |
| 17:02:47 | mriedem | maybe i just had this conversation in my head | |
| 17:02:53 | cfriesen | :) | |
| 17:02:59 | mriedem | er row 35 | |
| 17:03:03 | mriedem | "Propose a spec if we want this. We could store the server group information with the instance in the instance_extra table, or add a "member" query filter to the GET /os-server-groups API to filter groups returned by server members." | |
| 17:04:09 | openstackgerrit | Filippo Inzaghi proposed openstack/osc-placement master: Change openstack-dev to openstack-discuss https://review.openstack.org/622432 | |
| 17:06:11 | cfriesen | mriedem: okay...and I suppose it'd make more sense to make the filter query keyword "member" since that lines up with the "members" field in the server group response | |
| 17:09:22 | mriedem | i commented | |
| 17:09:45 | mriedem | i would make the filter parameter "members" to match the response parameter | |
| 17:10:12 | mriedem | the only question is if we'd use the same "in:" semantics that the placement API uses for things like member_of=in:42896e0d-205d-4fe3-bd1e-100924931787,5e08ea53-c4c6-448e-9334-ac4953de3cfa | |
| 17:10:31 | mriedem | cdent: remind me, why did we use "in" rather than just allow member_of to be a list? | |
| 17:10:37 | mriedem | expliciteness? | |
| 17:11:04 | mriedem | "members" for the server groups API filtering seems obvious that it would be a list | |
| 17:11:08 | cdent | mriedem: I think it was following pre-existing patterns and also to make it clear that it means "one of", not "all of" | |
| 17:11:20 | mriedem | ah | |
| 17:11:46 | cfriesen | I think GET /os-server-groups?members=server1,server2 would be clear enough | |
| 17:12:12 | mriedem | but then is that OR'ed or AND'ed | |
| 17:12:19 | cdent | reads as a | |
| 17:12:23 | cdent | AND | |
| 17:12:24 | cdent | to me | |
| 17:12:28 | mriedem | right, me too | |
| 17:12:31 | cfriesen | a given instance can only be a member of one group though | |
| 17:12:35 | cfriesen | so AND doesn't make sense | |
| 17:12:50 | sean-k-mooney | cfriesen: can it | |
| 17:12:59 | mriedem | yes | |
| 17:13:06 | mriedem | you can only specify the group when creating the server, | |
| 17:13:11 | mriedem | you can't add/remove members to/from groups | |
| 17:13:24 | mriedem | despite previous attempts to push that into the api | |
| 17:13:26 | sean-k-mooney | ok then GET /os-server-groups?member=uuid woudl be enough | |
| 17:13:50 | sean-k-mooney | unless you want GET /os-server-groups?members=server1,server2 to tell you if they are in the same group | |
| 17:13:51 | cfriesen | sean-k-mooney: mriedem wanted to be able to query the membership of multiple instances in one call | |
| 17:14:08 | mriedem | i'm not saying i want anything :) | |
| 17:14:21 | mriedem | i'm trying to figure out what the use cases are besides "show me the group my server is a member of" | |
| 17:14:24 | mriedem | since that is the obvious one | |
| 17:14:32 | cfriesen | okay..personally I think the idea would be that you list a bunch of instance via filter, then you want to query the group membership for that list of instances | |
| 17:14:37 | mriedem | but i'd also like to avoid having 4 microversions over time because of AND/OR wrinkles that people want later | |
| 17:15:00 | mriedem | the member_of filtering in GET /resource_providers seems sufficiently flexible for all cases, | |
| 17:15:04 | mriedem | which is why i was saying maybe we model that | |
| 17:16:06 | mriedem | cfriesen: in which case, ?members=server1,server2 is OR'ed | |