| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-20 | |||
| 12:32:58 | johnthetubaguy | actually, yeah, looks like thats not in a tagged release quite yet | |
| 12:33:01 | openstack | Launchpad bug 1683104 in openstack-manuals "instance is not created rightly" [Undecided,New] | |
| 12:33:01 | asettle | nicolasbock: Hey if you're around, I need a nova docs CPL ;) https://bugs.launchpad.net/openstack-manuals/+bug/1683104 and https://bugs.launchpad.net/openstack-manuals/+bug/1683071 | |
| 12:33:02 | openstack | Launchpad bug 1683071 in openstack-manuals "error installing nova-common" [Undecided,New] | |
| 12:33:17 | asettle | I just need someone to help verify :( | |
| 12:33:25 | zioproto | Yes but this commit is in Mitaka | |
| 12:33:31 | zioproto | I am confused | |
| 12:33:47 | nicolasbock | asettle, ok, let me have a look | |
| 12:33:51 | asettle | Thanks :) | |
| 12:36:04 | zioproto | johnthetubaguy: maybe you are right, this https://review.openstack.org/#/c/438630/ is only in 14.0.5 | |
| 12:36:14 | zioproto | and I have 14.0.4 | |
| 13:21:15 | efried | mriedem Good morning. When you have a sec - I noticed in your "Reflections" email the term "shared storage pools" - was wondering what that means? | |
| 13:23:32 | mriedem | a pool, of shared storage | |
| 13:23:55 | mriedem | efried: https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/generic-resource-pools.html | |
| 13:25:32 | efried | mriedem Okay, thanks. PowerVM has Shared Storage Pools (capitals intentional) which is a very specific technology based on a cluster of VIOSes etc. Just wanting to anticipate future confusion that will be caused by e.g. https://review.openstack.org/443189 | |
| 13:26:16 | mriedem | it's just a file share isn't it? | |
| 13:26:31 | dansmith | zioproto: yep, what johnthetubaguy said.. there are some data migrations that won't run without the services having been updated yet | |
| 13:26:38 | dansmith | zioproto: specifically one, that PciDevice one | |
| 13:26:50 | dansmith | zioproto: if you don't use any pci devices in your deployment then it won't do anything when it runs anyway | |
| 13:27:01 | johnthetubaguy | dansmith: it sounds like he was missing your fix up for the delete services thingy | |
| 13:27:15 | johnthetubaguy | old packages | |
| 13:27:16 | johnthetubaguy | well... older | |
| 13:27:18 | traskat | hey, what i have to do apply to apply extra specs to running VMs for examaple disk IO limitations? | |
| 13:27:27 | dansmith | johnthetubaguy: ah maybe | |
| 13:27:28 | sfinucan | mriedem: Could you take a look at these today? https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bump-min-libvirt | |
| 13:27:39 | mriedem | sfinucan: i can | |
| 13:28:01 | sfinucan | mriedem: Cheers | |
| 13:28:15 | efried | mriedem PowerVM SSP? No. The VIOSes share a pool of SAN disks and carve out LUs, which can then be attached to VMs. Things like thin clones are supported. Aforementioned patch allows multiple separate hosts (which otherwise don't communicate with each other) to share a SSP, including sharing images. | |
| 13:29:16 | efried | The VIOSes use an AIX-specific cluster technology, and an AIX-specific shared file system type. | |
| 13:29:32 | mriedem | efried: at a high level it's the same concept for modeling it in the placement service | |
| 13:29:39 | mriedem | it's a shared storage resource provider, | |
| 13:29:54 | mriedem | which will be in an aggregate relationship with the compute node resource providers that it serves disk to | |
| 13:30:19 | efried | mriedem Cool, maybe we ( thorst ) can look into folding PowerVM SSP into that concept. Thanks. | |
| 13:30:53 | mriedem | so rather than each compute node resource provider reporting it has 100TB of disk or whatever the pool size is, which would be a lie if you have 10 computes for the same storage (10*100TB), you'd model it so that the 10 compute RPs share the same disk RP with 100TB | |
| 13:31:08 | mriedem | efried: it's an operator thing to set it up properly | |
| 13:31:22 | efried | But we would have to enable/support it. | |
| 13:31:34 | mriedem | jaypipes or cdent or edleafe can correct me if i'm wrong | |
| 13:32:17 | edleafe | mriedem: correctamundo | |
| 13:33:41 | jaypipes | efried: totes. the VIOSes in AIX on PVM SSPs on SAN. yep, totes. | |
| 13:34:01 | openstackgerrit | Sandeep Pawar proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951 | |
| 13:36:09 | thorst | efried: yeah, we should definitely fold into that concept... (was afk) | |
| 13:36:50 | efried | thorst adreznec Let's queue it up for discussion in our box doc. | |
| 13:37:38 | thorst | yep | |
| 13:37:49 | thorst | we may have some FS ones in the same boat. | |
| 13:39:12 | efried | thorst Though it looks like maybe there is no affordance for it to be automated - the deployer just has to know which hosts are sharing an SSP and run these resource-provider set inventory commands accordingly. | |
| 13:40:00 | thorst | well, we've got a command to tell them all the hosts sharing...so. Maybe something to doc for that process. | |
| 13:40:38 | efried | Would be kinda neat if there was a method on the compute driver that could be asked to provide some kind of identifier for the shared resource (the SSP UUID in this case?) so the controller can figure out the pool on its own. | |
| 13:40:50 | efried | mriedem edleafe jaypipes Future enhancement ^^ ? | |
| 13:41:24 | efried | (though I haven't finished reading the spec yet ;-) | |
| 13:41:37 | jaypipes | efried: in case it wasn't obvious, I was being sarcastic above. :) | |
| 13:42:07 | efried | jaypipes Oh, it wasn't. | |
| 13:42:10 | efried | To me | |
| 13:42:22 | jaypipes | efried: I was poking fun at your TLAs :P | |
| 13:42:41 | efried | Gotcha. IBM does love its TLAs. | |
| 13:42:59 | jaypipes | efried: joking aside, I don't see anything that would prevent SSPs from being used as shared resource providers, no. | |
| 13:43:28 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for resource providers https://review.openstack.org/457532 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534 | |
| 13:43:29 | openstackgerrit | Roman Podoliaka proposed openstack/osc-placement master: CLI for inventories https://review.openstack.org/457533 | |
| 13:43:44 | efried | jaypipes Agree. But seems like it should be possible without operator intervention - at least in the narrow case I'm thinking about. | |
| 13:44:15 | jaypipes | efried: yes, indeed. | |
| 13:44:21 | efried | Not sure if possible in the general case. | |
| 13:44:47 | efried | I would think it should be possible if the shared storage was via NFS. | |
| 13:45:10 | efried | As long as the computes had a reliable way to canonicalize the host and mountpoint. | |
| 13:45:17 | rpodolyaka | cdent: thanks for your input on osc-placement changes! it's good to have a pair of fresh eyes on this | |
| 13:46:08 | thorst | could do the old - have each compute create a file on the share...and then have the compute drivers report back what they see. From that you could figure out who can see who... | |
| 13:46:15 | openstackgerrit | Lee Yarwood proposed openstack/nova master: encryptors: Switch to os-brick encryptor classes https://review.openstack.org/391597 | |
| 13:47:37 | cdent | rpodolyaka: you're very welcome | |
| 13:48:05 | lyarwood | mriedem: would you be willing to approve the bp for ^ https://blueprints.launchpad.net/nova/+spec/switch-to-os-brick-encryptor-classes or should I bring it up during the meeting today? | |
| 13:51:17 | mriedem | lyarwood: bring it up during open discussion | |
| 13:51:24 | lyarwood | mriedem: ack thanks | |
| 13:53:04 | cdent | johnthetubaguy: I've seen your comments on the service stuff on https://review.openstack.org/#/c/457283/ and I'm confused on one point that you might be able to help me on: | |
| 13:53:37 | cdent | johnthetubaguy: do we expect the host field in the service record to be the same or different for each instance of the wsgi app? | |
| 13:54:20 | johnthetubaguy | cdent: I think we want an entry for each version that is installed | |
| 13:54:29 | johnthetubaguy | cdent: so we can tell when the upgrade has finished | |
| 13:54:38 | johnthetubaguy | (or not) | |
| 13:54:51 | cdent | that doesn't really answer my question :) | |
| 13:55:15 | johnthetubaguy | cdent: true, I think the answer is yes, but the above is why | |
| 13:55:41 | johnthetubaguy | oops, by yes, I mean different for each instance | |
| 13:55:59 | johnthetubaguy | the problem is cleaning up old ones, etc, its a bit... unexpected | |
| 13:56:14 | cdent | so many knobs | |
| 13:56:31 | cdent | okay, I'll make some adjustments. using CONF.host seems like a reasonable way to go | |
| 13:56:56 | openstack | Launchpad bug 1631430 in OpenStack Compute (nova) "Only one entry created for nova-osapi_compute and nova-metadata services in multi-n-api environment" [Medium,In progress] - Assigned to Sujitha (sujitha-neti) | |
| 13:56:56 | johnthetubaguy | cdent: I think this is the extra context: https://review.openstack.org/#/c/384724/ and https://launchpad.net/bugs/1631430 | |
| 13:57:11 | mriedem | nova meeting in 3 minutes in #openstack-meeting | |
| 13:57:33 | cdent | thanks johnthetubaguy | |
| 13:58:41 | openstackgerrit | sahid proposed openstack/nova master: network: add command to configure trusted mode for VFs https://review.openstack.org/458513 | |
| 13:58:42 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 13:58:53 | mdbooth | sfinucan johnthetubaguy mriedem: I'd really like to push this one over the line: https://review.openstack.org/#/c/383859/ . Appreciate it's a pretty complex, though. I was thinking about splitting out the code which resets on libvirt reconnection into a separate patch. I still think this code adds robustness, but splitting it out might make it simpler to review the most important part of the patch. Worth it? | |
| 13:59:26 | mriedem | i wouldn't split it | |
| 13:59:31 | sfinucan | I wouldn't | |
| 13:59:41 | mdbooth | Glad I asked :) | |
| 14:00:09 | sfinucan | Yeah, I'm generally happy with it as is. The tests are by far the most complex piece but copious comments do help | |
| 14:00:34 | johnthetubaguy | yeah, I think I am quite close to +2 on that now, its dropped off my radar for a bit | |
| 14:00:43 | johnthetubaguy | will try taking another peak today | |
| 14:00:43 | mdbooth | Yeah, the tests are a nightmare | |
| 14:01:04 | mdbooth | Ok, thanks. I'll update with sfinucan's comments, but otherwise leave it alone. | |
| 14:02:25 | sfinucan | (y) | |
| 14:21:30 | traskat | hey, what i have to do to apply extra specs to running VMs for examaple disk IO limitations without restart the VM? | |
| 14:25:13 | efried | traskat Resize? | |