| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 23:11:57 | masber | so i was wondering if I could get some ideas from here as the people is specialised on nova... | |
| 23:12:01 | masber | apologise again | |
| 23:46:48 | melwitt | dansmith: woot \o/ | |
| 23:53:32 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602 | |
| 23:54:27 | jaypipes | dansmith: ok dokey :) ^^ hopefully I got it right this time. | |
| 23:54:41 | jaypipes | heading back to hotel from office... biab. | |
| 23:58:00 | cburgess | jaypipes Yick another week of travel right after PTG? | |
| #openstack-nova - 2017-03-01 | |||
| 00:43:00 | jaypipes | cburgess: yup. | |
| 01:20:20 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 04:12:36 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/439329 | |
| 04:16:08 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/439361 | |
| 04:50:13 | gaoyuan | who is unicell | |
| 05:21:13 | prometheanfire | so, upgrades broken due to a db rename? | |
| 05:31:47 | prometheanfire | getting this isn't that helpful :| | |
| 05:31:48 | prometheanfire | Unable to sync cell0 schema: (psycopg2.OperationalError) FATAL: database "nova_cell0" does not exist | |
| 05:31:48 | prometheanfire | Cell0 is already setup | |
| 05:32:10 | prometheanfire | is it still calling the setup even if it's already set up? | |
| 06:01:49 | openstackgerrit | MarkMielke proposed openstack/nova master: DiskFilter handling for free space less than zero https://review.openstack.org/430091 | |
| 06:25:55 | prometheanfire | the nova_cell0 db creation was non-obvious, might want to update the ocata release notes / install guide | |
| 06:26:02 | prometheanfire | working now at least :D | |
| 06:33:49 | prometheanfire | docs don't mention placement being needed by compute hosts either | |
| 06:41:59 | gaoyuan | who is gorian | |
| 06:48:45 | prometheanfire | what port does placement go on by default? | |
| 07:43:21 | openstackgerrit | Andrey Volkov proposed openstack/nova master: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489 | |
| 07:43:24 | openstackgerrit | Andrey Volkov proposed openstack/nova master: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997 | |
| 07:43:25 | openstackgerrit | Andrey Volkov proposed openstack/nova master: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744 | |
| 07:45:58 | Gorian | gaoyuan, just me - why ? | |
| 07:46:18 | Gorian | 374 people in this channel, and you are wondering why I am? :P | |
| 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 | |