| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-26 | |||
| 14:36:47 | efried | up to the point of that in-flight patch, SchedulerReportClient was the only thing using ProviderTree, and it does need to worry about thread safety (sort of :) | |
| 14:37:02 | izombie | The issue I was speaking of yesterday. | |
| 14:37:26 | izombie | artom: It was with the project-id, it wasn't according to the new regex pattern ;) | |
| 14:37:30 | artom | izombie, err, refresh my memory? | |
| 14:37:49 | izombie | artom: was trying to list nova servers and I was hitting 404.. | |
| 14:38:02 | artom | izombie, oh, right | |
| 14:38:10 | efried | rgerganov Feel like proposing that change for new_child to accept name_or_uuid for the parent? | |
| 14:38:18 | rgerganov | efried, yes | |
| 14:38:42 | rgerganov | efried, I will submit patch for it | |
| 14:38:46 | artom | izombie, err, cool? I'm not sure what you mean by new regex pattern | |
| 14:39:13 | efried | rgerganov You could *almost* cheat and pass in the name as it stands :) But that won't quiiite work all the way. | |
| 14:39:15 | rgerganov | efried, I also think that removing all child providers is pretty valid use case | |
| 14:39:16 | izombie | artom: so project mapper has introduced some change in the way project id's are supposed to be | |
| 14:39:51 | efried | rgerganov I would need to understand more about why that's necessary. And in any case you'll have to get it past Jay :) | |
| 14:39:56 | efried | Which reminds me... | |
| 14:40:02 | fried_rice | It's FRIDAY! | |
| 14:40:08 | artom | izombie, I'll be honest, I'm not following | |
| 14:40:12 | izombie | artom: the regex expects a hex sort of value, but our's was simple characters. hence the project id was never fetched and directly passed to routes to find a match | |
| 14:40:19 | fried_rice | niiice | |
| 14:40:44 | radio_gaga | fried_rice, you familiar with the vmware driver? | |
| 14:40:56 | fried_rice | radio_gaga Not at all, sorry. | |
| 14:41:00 | radio_gaga | fried_rice, basically one nova-compute manges a compute cluster in vcenter server | |
| 14:41:22 | izombie | artom: okay, this code might help you gain context https://github.com/openstack/nova/blob/master/nova/api/openstack/__init__.py#L156-L158 | |
| 14:41:24 | radio_gaga | fried_rice, a compute cluster may be divided into resource pools | |
| 14:41:42 | radio_gaga | fried_rice, now we want to create a nested RP for each resource pool under the compute cluster managed by nova | |
| 14:41:50 | fried_rice | radio_gaga And you don't have n-cpu running on those other ("slave"?) nodes in the cluster? | |
| 14:42:06 | radio_gaga | fried_rice, no | |
| 14:42:10 | fried_rice | k | |
| 14:42:20 | radio_gaga | fried_rice, the thing is that resource pools can be dynamic | |
| 14:42:21 | fried_rice | what's a "resource pool"? | |
| 14:42:24 | artom | izombie, ah, thanks - first time looking at that bit of the API code :) | |
| 14:42:43 | radio_gaga | fried_rice, it's just a group of compute resources | |
| 14:42:59 | radio_gaga | fried_rice, the point is that those resource pools can by dynamic | |
| 14:43:34 | fried_rice | radio_gaga Okay, so the hierarchy is: compute-host-where-service-is-running => resource-pool => slave-compute-node | |
| 14:43:35 | radio_gaga | fried_rice, and it would be a lot easier if we delete all child RP and create them again instead of trying to synchronize what's in the provider_tree and what's in vcenter | |
| 14:44:44 | izombie | artom: :) Necessity! | |
| 14:45:56 | fried_rice | radio_gaga Well, you could always provider_tree.remove(nodename) | |
| 14:46:10 | fried_rice | and then rebuild the whole shebang including the root. | |
| 14:46:29 | fried_rice | .remove(nodename) will implicitly whack everything under him. | |
| 14:46:39 | radio_gaga | fried_rice, hm, actually that will do the job | |
| 14:46:47 | radio_gaga | fried_rice, cool thanks | |
| 14:47:08 | radio_gaga | fried_rice, I will try it just in case :) | |
| 14:47:17 | fried_rice | radio_gaga But have you considered having all your compute nodes as roots, and tagging them with traits to identify their resource pool? | |
| 14:48:34 | radio_gaga | fried_rice, having them under one root is a better model because this is the same model in vCenter; you divide one big compute cluster into resource pools | |
| 14:50:01 | fried_rice | radio_gaga As you wish, just another possibility. Or have the slaves all be children directly under the root, and still tag 'em with resource pool trait name. | |
| 14:50:41 | radio_gaga | fried_rice, yeah, that's what I am trying to accomplish right now | |
| 14:51:12 | fried_rice | radio_gaga Point is, then you don't need to whack all the pools and rebuild them - you can just walk the children and reassign their traits. | |
| 14:51:49 | leakypipes | radio_gaga: awesome Friday nick :) | |
| 14:51:59 | radio_gaga | leakypipes, thanks :) | |
| 14:52:44 | radio_gaga | leakypipes, we were discussing changing provider_tree.new_child to accept name_or_uuid instead of uuid | |
| 14:52:59 | fried_rice | leakypipes IMO an oversight, easily corrected. Agree? | |
| 14:53:19 | fried_rice | leakypipes correction: parent_name_or_uuid instead of parent_uuid | |
| 14:53:30 | radio_gaga | yeah, right | |
| 14:54:29 | leakypipes | fried_rice: how about just "parent" | |
| 14:54:34 | fried_rice | sure | |
| 14:54:36 | leakypipes | fried_rice: and make it accept either. | |
| 14:54:37 | ameeda | can you please review this when you available ? https://review.openstack.org/#/c/528385/ | |
| 14:54:43 | fried_rice | radio_gaga is going to propose it | |
| 15:02:39 | tssurya | superdan, mriedem, melwitt : regarding the solution we discussed for nova list displaying only the uuid when a cell DB is down, there is this issue that we end up displaying all the instance uuids in that cell (including the deleted ones)...since we take it from the mappings, :( | |
| 15:03:05 | tssurya | any ideas on how to differentiate the deleted ones using api info ? | |
| 15:03:16 | melwitt | there isn't a way | |
| 15:03:21 | superdan | mm, yep, that's not really avoidable unfortunately | |
| 15:03:21 | leakypipes | ameeda: those are bug fixes. we can get to those as needed over next few weeks. | |
| 15:03:43 | tssurya | melwitt, superdan : ok :( | |
| 15:06:23 | leakypipes | JGrg543#1 | |
| 15:06:34 | superdan | nice | |
| 15:06:40 | belmoreira | superdan that isn't good | |
| 15:06:53 | leakypipes | oops. now y'all know my verizon laptop password. | |
| 15:07:17 | ameeda | leakpipes: if you can review it for me as you can, to let me know if that is good or not. | |
| 15:07:25 | superdan | belmoreira: referring to leakypipes' password or the deleted instances thing? | |
| 15:08:02 | SpazZz | Perfect | |
| 15:08:08 | belmoreira | :) referring to the readonly replica idea | |
| 15:08:12 | radio_gaga | I am going to +2 all my patches with jay's account | |
| 15:08:24 | SpazZz | We handing out +2s? | |
| 15:08:34 | SpazZz | Will pay in baked chicken | |
| 15:08:34 | leakypassword | radio_gaga: good luck :) it's only for my mac laptop (which I hate and don't use for anything) ;) | |
| 15:09:20 | SpazZz | password has been secured. Pipe is again at risk | |
| 15:10:30 | leakypipes | heh | |
| 15:13:09 | leakypipes | superdan, mdbooth, mriedem: if someone is using qcow2 images in glance, with ceph as the backing store, what is the most efficient way to do instance snapshots? is it setting snapshot_image_format=raw or is there some ceph-specific efficient snapshotting method? | |
| 15:13:42 | sean-k-mooney | finucannot: leakypipes superdan just noticed we are at/past feature freeze can https://blueprints.launchpad.net/nova/+spec/enable-sriov-nic-features get a FFE i ame working on the last change finucannot asked for currently so i think this will be done this evening | |
| 15:14:00 | melwitt | leakypipes: you have to configure raw image format in glance | |
| 15:15:05 | melwitt | http://docs.ceph.com/docs/master/rbd/rbd-openstack/ | |
| 15:16:19 | leakypipes | sean-k-mooney: I don't have a problem with it, but mriedem is the decider-in-chief | |
| 15:17:41 | leakypipes | melwitt: lol, I love how the ceph docs refer to a thing called "OpenStack" -- as if it were a single thing. | |
| 15:17:49 | leakypipes | "Install OpenStack" | |
| 15:17:51 | leakypipes | heh | |
| 15:17:58 | melwitt | yeah, totally simple | |
| 15:19:17 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: ProviderTree.new_child: parent is either uuid or name https://review.openstack.org/538264 | |
| 15:19:19 | jroll | leakypipes: https://i.imgur.com/rCr9A.png | |
| 15:19:20 | sean-k-mooney | leakypipes: :) ok ill send a mail to the list requestion the FFE mriedem i hope you dont mind if i cc you. im currently working on the changes now so the final version should be up before i leave today unless there are new review comments. | |
| 15:19:42 | melwitt | leakypipes: you probably need snapshot_image_format = raw too if that will dictate what format the image ends up in glance. the root point is that the image format in glance must be raw for ceph's native cow clone stuff to work | |
| 15:19:51 | radio_gaga | leakypipes, fried_rice https://review.openstack.org/#/c/538264 | |
| 15:20:40 | superdan | jroll: love it | |
| 15:21:08 | jroll | :D | |
| 15:21:20 | kashyap | Can anyone explain what exactly is 'nova live-igration-force-complete' doing under the hood? /me goes to look at source meanwhile | |
| 15:22:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: reno for notification-transformation-queens https://review.openstack.org/518018 | |
| 15:22:17 | giblet | mriedem: ^^ | |
| 15:22:54 | leakypipes | jroll: lol, that's awesome | |
| 15:22:59 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: ProviderTree.new_child: parent is either uuid or name https://review.openstack.org/538264 | |
| 15:24:55 | fried_rice | radio_gaga Small test addition please. | |