| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 08:09:30 | openstackgerrit | MarkMielke proposed openstack/nova master: DiskFilter handling for free space less than zero https://review.openstack.org/430091 | |
| 08:25:26 | openstackgerrit | MarkMielke proposed openstack/nova master: DiskFilter handling for free space less than zero https://review.openstack.org/430091 | |
| 08:27:02 | bauzas | good morning Nova | |
| 08:34:58 | openstackgerrit | Moshe Levi proposed openstack/nova master: [WIP] OVS acceleration https://review.openstack.org/398265 | |
| 08:39:09 | ftersin | johnthetubaguy: hi. could you please look at https://review.openstack.org/#/c/304715/ , i tried to address your comments, but not sure the result is what you wanted, since you didn't answer on my questions there | |
| 08:43:06 | johnthetubaguy | ftersin: we discussed at the PTG adding a cinder ephemeral disk driver, would that work for you? | |
| 08:49:19 | ftersin | johnthetubaguy: it will consume volumes which will be a bit different than running instances w/o cinder at all | |
| 08:50:05 | johnthetubaguy | ftersin: the user's Nova API calls would be identical, its just the code creating the disks would create volumes in Cinder. | |
| 08:51:39 | ftersin | johnthetubaguy: moreover, that solution is just discussed, but not implemented yet. From the other side we have that solution, which is implemented for previous OS versions as well, and integrated to JuJu and Fuel via corresponding charms/plugins | |
| 08:53:58 | johnthetubaguy | ftersin: the problem is if we added it, we would want to deprecate it as soon as we landed the Cinder one, and create some kind of transition system, etc, so we didn't have to keep maintaining the extra code for each and every Cinder backend twice. | |
| 08:54:09 | openstackgerrit | Alex Xu proposed openstack/nova-specs master: The ResourceProviderTraits API - Manage traits with ResourceProviders https://review.openstack.org/345138 | |
| 08:54:52 | ftersin | johnthetubaguy: do you want to deprecate Ceph backend as well? | |
| 08:55:34 | johnthetubaguy | ftersin: honestly my preference is to also deprecate the local volume support, but I totally need to talk to mdbooth about that | |
| 08:55:50 | johnthetubaguy | my local volume, I mean LVM | |
| 08:56:43 | johnthetubaguy | ftersin: that way, cinder manages storage, neutron manages networking, life is simpler | |
| 08:56:57 | ftersin | johnthetubaguy: i agree with the deprecation of LVM, but what for Ceph? it's used widely | |
| 08:57:30 | johnthetubaguy | ftersin: I mean all ephemeral storage including ceph, transition it to cinder | |
| 08:57:47 | johnthetubaguy | ftersin: if thats not possible, I would like to understand why | |
| 08:58:57 | johnthetubaguy | ftersin: at this point, thats all totally my current preference, rather than any kind of consenus from the PTG | |
| 08:59:50 | ftersin | johnthetubaguy: well, then you'll need a transition procedure. It will affects more than one backend, so it's not a big problem if there will be 2 or 3 such backends | |
| 09:00:03 | ftersin | It's OK for us. We'll be deprecated along with Ceph | |
| 09:00:12 | johnthetubaguy | ftersin: but each transition would be specific to the backend, for sure | |
| 09:00:52 | johnthetubaguy | i.e. adding more drivers now means a lot more work later | |
| 09:02:24 | johnthetubaguy | ftersin: now if we sit down, and getting the cinder support is cycles and cycles away, clearly thats not the right way to go, I just think we don't have enough info to make that call right now | |
| 09:02:43 | ftersin | more checks, probably. But anyway you'll have to develop a pretty common transition system (at least to commonize lvm and ceph things), so it will be not very big extra work to additionaly support another driver there | |
| 09:04:27 | johnthetubaguy | ftersin: in my head the hard bit is "import" volume into Cinder, which feels like its going to be specific to each platform, the common bit is just the loop to call that function for each disk on the system in init_host, but I could be missing something | |
| 09:04:34 | ftersin | under 'that call' you mean the switching to Cinder backend or adding new volume based backends? | |
| 09:05:34 | johnthetubaguy | I mean working out how to "move" the volume from being managed by Nova to being managed by Cinder, I think though using this call somehow: https://developer.openstack.org/api-ref/block-storage/v2/index.html?expanded=manage-existing-volume-detail#manage-existing-volume | |
| 09:08:29 | ftersin | but you'll not need to acquire all volumes, only used for local disks. At the first glance the only not common thing is to fill connection strings | |
| 09:09:25 | johnthetubaguy | ftersin: filling in the "ref" parameter worries me I guess, and ensuring each backend supports that cinder API in the same way | |
| 09:10:29 | johnthetubaguy | ftersin: I think the action here is to discuss the cost of this all in the alternatives section in the spec. Just a few sentences, thats all, to show it has been considered | |
| 09:11:51 | ftersin | sure, each volume driver in Nova can compose a new connection string to attach a volume. But if they can to compose the string for attached volumes? | |
| 09:14:28 | johnthetubaguy | ftersin: yeah, maybe thats not as bad as I think it is. I didn't discover that cinder API till just now, which makes me worry a little bit less | |
| 09:14:52 | ftersin | johnthetubaguy: ok, i may add a consideration of Cinder backend alternative. Do you have a link to appropriate discussion or the result docs or smth else? | |
| 09:15:42 | johnthetubaguy | ftersin: good question, I think jgriffith was taking the action on that one, I am hoping to see a nova-spec from him around that | |
| 09:19:08 | sfinucan | mriedem_away: https://review.openstack.org/#/c/412390/ | |
| 09:20:18 | sfinucan | mriedem_away: I /did/ deprecate firewall_driver :) (along with pretty much everything else nova-network'y - https://review.openstack.org/#/q/topic:bp/centralize-config-options-pike+owner:%22Stephen+Finucane+%253Csfinucan%2540redhat.com%253E%22+status:open) | |
| 09:20:36 | sfinucan | tonyb: What are we celebrating? :) | |
| 09:24:42 | ftersin | johnthetubaguy: well, i'll try to monitor gerrit for that, or ask him. Right now i'm going to add that alternative to the spec and reupload it. Is it ok for you? | |
| 09:24:57 | johnthetubaguy | ftersin: that sounds perfect, thank you | |
| 09:28:03 | ftersin | johnthetubaguy: thank you too | |
| 09:31:44 | openstackgerrit | sahid proposed openstack/nova master: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023 | |
| 09:31:47 | openstackgerrit | sahid proposed openstack/nova master: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364 | |
| 09:31:48 | openstackgerrit | sahid proposed openstack/nova master: numa: fit instance topology with cpus reserved onto cores https://review.openstack.org/400875 | |
| 09:31:50 | openstackgerrit | sahid proposed openstack/nova master: virt: update overhead to take into account vCPUs https://review.openstack.org/385024 | |
| 09:31:54 | openstackgerrit | sahid proposed openstack/nova master: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878 | |
| 09:31:55 | openstackgerrit | sahid proposed openstack/nova master: numa: take into account cpus reserved https://review.openstack.org/400876 | |
| 09:31:56 | openstackgerrit | sahid proposed openstack/nova master: numa: update numa usage incording the cpu reserved https://review.openstack.org/400877 | |
| 09:37:56 | gmann | alex_xu: johnthetubaguy I would not be available for today meeting due to other works. | |
| 09:38:09 | alex_xu | gmann: got it | |
| 09:47:29 | openstackgerrit | Alfredo Moralejo proposed openstack/nova master: Remove domains *-log-* from compile_catalog https://review.openstack.org/439500 | |
| 09:47:50 | tonyb | sfinucan: the merge of your pbr patch ... and then it all went horribly wrong | |
| 09:48:07 | sfinucan | tonyb: oh, do tell | |
| 09:48:21 | openstackgerrit | Alfredo Moralejo proposed openstack/nova master: Remove domains *-log-* from compile_catalog https://review.openstack.org/439500 | |
| 09:49:28 | bauzas | tonyb: not sure I fully understood the pbr major version potential problem you raised | |
| 09:52:01 | tonyb | sfinucan: It seems a few projects (in and out of OpenStack) have defensive caps on pbr < 2.0.0 so we're stuck until they get fixed | |
| 09:52:50 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Backlog spec describing Nova's quota needs https://review.openstack.org/429678 | |
| 09:52:52 | tonyb | bauzas: it *shoudln't* affect nova but projects under Telemtry will be a little broken until we fix the pbr thing (or they land a local patch) | |
| 09:53:34 | johnthetubaguy | tonyb: I meant to ping you about that spec on capabilties, although sounds like you are busy with other fires | |
| 09:53:48 | prometheanfire | was there any docs made for the install guide for setting up the placement api? | |
| 09:54:30 | tonyb | johnthetubaguy: I hope they'll be damped by tomorrow, so I shoudl be able to focus on it tomorrow | |
| 09:54:34 | prometheanfire | because https://docs.openstack.org/developer/nova/placement.html seems kinda lacking, for instance, doesn't say what port it's running on | |
| 09:55:16 | johnthetubaguy | prometheanfire: yeah, I was just going to point to https://docs.openstack.org/developer/nova/placement.html#deployment | |
| 09:55:19 | johnthetubaguy | tonyb: coolness | |
| 09:55:27 | bauzas | tonyb: okay, thanks for the feeback | |
| 09:55:38 | tonyb | prometheanfire: check devstack or wit for the docs install guide | |
| 09:55:46 | johnthetubaguy | prometheanfire: basically its done the same way keystone is deployed, so the port etc is defined by mod_wsgi, etc | |
| 09:56:06 | johnthetubaguy | prometheanfire: and +1 tonyb, devstack shows how thats done, to some extent | |
| 09:56:30 | johnthetubaguy | prometheanfire: jaypipes would know more of the doc plan when he comes online later today | |
| 09:57:03 | prometheanfire | tonyb: I'm actually checking osa first :P | |
| 09:57:32 | tonyb | prometheanfire: fair enough | |
| 09:57:41 | prometheanfire | though osa has it as optional | |
| 09:57:45 | johnthetubaguy | prometheanfire: yeah, I walked through that with OSA, so it should be there now | |
| 09:57:45 | prometheanfire | and it's not :P | |
| 09:58:00 | johnthetubaguy | prometheanfire: I thought they had updated that for this cycle, I guess not | |
| 09:58:10 | johnthetubaguy | by this I mean ocata | |
| 09:58:32 | prometheanfire | right | |
| 09:58:39 | johnthetubaguy | andymccr: did you make placement api required yet in OSA ^ | |
| 09:58:58 | prometheanfire | maybe it's meant to only be configured on certian nodes | |
| 09:59:13 | prometheanfire | johnthetubaguy: so... what's the default port for it? | |
| 09:59:21 | prometheanfire | like nova has a default port | |
| 09:59:21 | johnthetubaguy | prometheanfire: looking here https://github.com/openstack-dev/devstack/blob/55dab95237302fa371b88a2edce06de201d83f52/files/apache-placement-api.template bauzas might be able to help | |
| 09:59:37 | johnthetubaguy | prometheanfire: placement doesn't have a default port, just like keystone, AFAIK | |
| 09:59:38 | prometheanfire | 8780, thanks :D | |
| 09:59:55 | bauzas | prometheanfire: johnthetubaguy: sorry, on meeting atm | |
| 09:59:57 | johnthetubaguy | oh, I guess that kinda is the default | |
| 10:00:02 | prometheanfire | keystone isn't 5000 / 35357 ? | |
| 10:00:23 | johnthetubaguy | well, in theory, none of that matters, you just get the URL from the service catalog | |
| 10:00:40 | prometheanfire | I know it can be discovered, but it's nice to be consistant :P | |
| 10:01:06 | johnthetubaguy | prometheanfire: actually looks like us and keystone might be on 443, technically, https://github.com/openstack-dev/devstack/blob/55dab95237302fa371b88a2edce06de201d83f52/files/apache-keystone.template | |
| 10:01:11 | johnthetubaguy | prometheanfire: but I am not sure | |
| 10:01:17 | andymccr | johnthetubaguy: it's on by default - originally i set it up with a flag but i will probably remove that flag | |
| 10:01:38 | prometheanfire | andymccr: cool, was confused about that :D | |
| 10:01:50 | johnthetubaguy | andymccr: ah, cool, that makes sense, just a transition thing | |
| 10:02:01 | andymccr | prometheanfire: yeah i wanted to set it up prior to it being required and never got it going - and then didn't remove the flag :P | |
| 10:02:03 | andymccr | but yeah it should go now | |
| 10:02:21 | andymccr | either way if you dont force it off - it gets set up | |
| 10:02:47 | prometheanfire | johnthetubaguy: I think it's also on 443 in devstack, but primarily on PUBLICPORT/ADMINPORT | |
| 10:03:00 | johnthetubaguy | yeah, that makes sense | |
| 10:05:34 | andymccr | prometheanfire: there is a discussion about the default ports on the mailing list - essentially there is no default the idea is you use port 80/443 - but we needed one for our backend since we dont have it setup to do that at this point. | |