| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 13:48:07 | bauzas | I can scatter/gather for sure | |
| 13:48:14 | bauzas | but it will take time | |
| 13:48:28 | bauzas | I mean, it's a performance issue | |
| 13:48:42 | dansmith | eh? | |
| 13:48:45 | gibi | bauzas: would be better scatter / gather once to get all the compute node objects from all cells? | |
| 13:48:51 | bauzas | when calling the audit command, then we would have to look at all the cells to find the one having the CN UUID | |
| 13:48:54 | mriedem | scatter/gather non-cell0 cells since you shouldn't have compute nodes in cell0, | |
| 13:49:02 | mriedem | and for most deployments that's only going to be 1 cell to query | |
| 13:49:22 | dansmith | bauzas: you need to scatter/gather a get_by_uuid() right? | |
| 13:49:23 | dansmith | that should be uber fast | |
| 13:49:44 | bauzas | I did this for PS1 https://review.opendev.org/#/c/670112/1/nova/cmd/manage.py@2309 | |
| 13:50:08 | bauzas | dansmith: okay, lemme try to do it | |
| 13:50:30 | bauzas | and then we could for example ask CERN to verify the performance | |
| 13:50:37 | bauzas | or mnaser :) | |
| 13:51:11 | mriedem | my comment wasn't about using scatter/gather, it was about starting with compute nodes and working backward to resource providers | |
| 13:51:15 | bauzas | mriedem: gibi: dansmith: thanks for the help | |
| 13:51:29 | gibi | bauzas: np | |
| 13:51:50 | bauzas | mriedem: yeah, no worries, I already understood this, I just tried to explain that I already used scatter_gather so I already know it :) | |
| 13:51:55 | mriedem | being an audit / heal style command, i don't think blazying fast performance is the primary concern | |
| 13:52:04 | mriedem | *blazing even | |
| 13:52:46 | mriedem | do you allow passing in a single uuid to audit? if not you probably should so you don't have to audit all 20K nodes just to heal one of them that is a problem. | |
| 13:53:29 | mnaser | yeah i think we should loop over RPs instead of CNs | |
| 13:53:30 | gibi | mriedem: yes, the command has a --resource_provider flag | |
| 13:53:35 | mriedem | 20K compute services + x number of ironic VMs... | |
| 13:53:42 | mriedem | *ironic BMs / instances | |
| 13:53:48 | dansmith | mriedem: you know, this has come up before.. we really should move HostMapping to use (or at least have) the compute uuid in there | |
| 13:54:04 | mriedem | dansmith: the cardinality isn't correct for that | |
| 13:54:15 | mriedem | for ironic you have 1 host mapping to x nodes | |
| 13:54:30 | mriedem | gibi: ok good - except let's drop the underscore in the option name, i hate that | |
| 13:54:33 | mriedem | e.g. --max_rows | |
| 13:54:42 | mriedem | options should use dashes | |
| 13:54:51 | dansmith | mriedem: right, which also causes us trouble and why we need thatother mechanism of hostmapping discovery... | |
| 13:54:53 | mriedem | i think stephenfin and i might agree on one thing and that's probably it | |
| 13:55:22 | dansmith | mriedem: I the point is we kinda need nodes and hosts in there, by uuid or name depending :D | |
| 13:55:39 | mriedem | dansmith: so for an ironic compute service, the HostMapping just wouldn't have uuid set? | |
| 13:55:47 | sean-k-mooney | well we can still have a 1:n mapping in the 1:1 case it jsut a specific value of n | |
| 13:56:04 | sean-k-mooney | so we could model it in the db using a mapping table | |
| 13:56:11 | mriedem | .... | |
| 13:56:12 | sean-k-mooney | and in the object as a list right? | |
| 13:56:39 | sean-k-mooney | which might be what we alreday do | |
| 13:56:45 | sean-k-mooney | i was not following the conversation | |
| 13:57:01 | mriedem | from a coding api perspective, if i'm relying on the host mapping uuid to get/match the compute node uuid, then how do i know if that host is managing one or many nodes | |
| 13:57:09 | mriedem | also, | |
| 13:57:26 | dansmith | mriedem: maybe I dunno | |
| 13:57:30 | mriedem | the host mapping name doesn't / shouldn't change (the hostname on the host would have to change which is bad), | |
| 13:57:43 | mriedem | but i can guarantee you that the compute node uuid generated by the compute service will change | |
| 13:57:55 | mriedem | and that would be an up-call or new discovery from the controller to sync those up | |
| 13:58:16 | sean-k-mooney | its unfortunate that we are not usign a uuid5 based on teh host name for the compute node uuid | |
| 13:58:34 | mriedem | all you have to is (1) start the service, (2) discover it to create the host mapping, (3) delete the compute service (4) restart it and bam you have a new compute node with a new uuid | |
| 13:59:00 | mriedem | sean-k-mooney: that's not a bad idea...in the non-ironic case, | |
| 13:59:16 | mriedem | for ironic, since rocky we make the compute node == resource provider == ironic node all use the ironic node uuid | |
| 13:59:22 | mriedem | that has caused some problems... | |
| 13:59:32 | bauzas | mriedem: yup, either the audit command loops over RPs, or asks for a specific RP UUID | |
| 13:59:51 | sean-k-mooney | the ironic node id often matche the chassis uuid backed into the hardware | |
| 14:00:13 | mriedem | meeting time | |
| 14:00:41 | dansmith | mriedem: sorry I lost track of that convo because I was having two | |
| 14:01:06 | mriedem | this is the problem i'm talking about with using static uuids https://review.opendev.org/#/q/Iafba419fe86446ffe636721f523fb619f8f787b3 | |
| 14:01:12 | mriedem | sean-k-mooney: ^ | |
| 14:01:53 | mriedem | somewhat related https://review.opendev.org/#/c/684849/ | |
| 14:02:11 | sean-k-mooney | oh ya i vaguely rememebr that it was related to the phyical node reblanice to a different compute service | |
| 14:02:38 | mriedem | the first is related to maintenance mode on a node, the latter is rebalance | |
| 14:02:56 | sean-k-mooney | ack | |
| 14:03:21 | stephenfin | mriedem: <3 | |
| 14:03:47 | sean-k-mooney | i need to grab somthing to eat before another meeting in an hour so ill join the nova meeting in link 20-30 mins | |
| 14:03:49 | sean-k-mooney | brb | |
| 14:04:10 | mordred | mriedem: in microversion 2.64, os-server-group changed from accepting policies=[] to policy="" ... what happens to additional policies created with lower microversion? | |
| 14:04:39 | mriedem | it was unpossible on lower microversions | |
| 14:04:46 | mriedem | shitty api design allowed a list but the backing db model didn't | |
| 14:04:59 | mriedem | something like that - the json schema only allowed a list with an entry of exactly 1 | |
| 14:05:05 | mordred | ah - cool | |
| 14:05:21 | mordred | so that makes it super easy to support properly in sdk | |
| 14:06:07 | mriedem | mordred: yeah see the description of the parameter in the ref https://docs.openstack.org/api-ref/compute/?expanded=create-server-group-detail#create-server-group | |
| 14:06:16 | mriedem | before 2.64: "A list of exactly one policy name to associate with the server group." | |
| 14:06:41 | mordred | that's amazing | |
| 14:07:14 | mriedem | the poor api design before or the fact it was actually documented? | |
| 14:07:16 | mriedem | both?! | |
| 14:07:24 | mordred | both! | |
| 14:07:45 | mordred | also - I'm glad the answer this time does not require me to figure out how to do more complex logic | |
| 14:07:59 | mordred | sg_attrs['policy'] = policies[0] # this is awesome | |
| 14:08:04 | mriedem | yup | |
| 14:08:40 | mordred | oh - although - I still probably want to figure out how to switch somethign there - because older mvs won't have the policy parameter | |
| 14:08:47 | mordred | maybe I'll just wait until someone complains | |
| 14:09:35 | openstackgerrit | Dan Smith proposed openstack/nova master: Add reserved schema migrations for Ussuri https://review.opendev.org/686411 | |
| 14:12:03 | stephenfin | melwitt: I assume I can kill the entire 'networks' quota thing when nova-net is removed? | |
| 14:12:13 | stephenfin | It seems it's not enabled by default atm anyway | |
| 14:13:36 | efried | sean-k-mooney: do you understand the SEV bug well enough to phrase a docs & reno warning saying it's broke? In case the fix doesn't make Train? | |
| 14:16:29 | stephenfin | mriedem++ lyarwood++ thanks for getting those novaclient fixes in so quickly | |
| 14:16:35 | mriedem | np | |
| 14:17:08 | stephenfin | efried: I'll take a lash at it now | |
| 14:17:15 | efried | thanks stephenfin | |
| 14:23:41 | sean-k-mooney | efried: if you mean the virto/dma issue yes i can proably write something up | |
| 14:24:21 | sean-k-mooney | i dont understand all the lowlevel details but i think i understand enough for a reno listing it as known issues | |
| 14:25:16 | sean-k-mooney | if stephenfin give it a go ill be happy to review too | |
| 14:25:36 | sean-k-mooney | the metting is in #openstack-meeting right | |
| 14:26:09 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/train: docs: Highlight the current broken state of SEV https://review.opendev.org/686414 | |
| 14:27:07 | stephenfin | sean-k-mooney: yeah, #openstack-meeting | |
| 14:27:52 | stephenfin | and that's the reno ^^ I don't know if I need more details or if it's more nuanced than that (are there only certain conditions where virtio-scsi will be present, for example)? | |
| 14:28:07 | sean-k-mooney | yes | |
| 14:28:13 | sean-k-mooney | you have to opt in to it | |
| 14:28:25 | sean-k-mooney | ill review and add details as needed | |