Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-28
22:42:38 mriedem and we're doing a mapping table b/c you can have M:M
22:42:52 mriedem unlike inventories/resource_classes
22:43:06 mriedem a single inventory has a single resource class
22:43:11 mriedem but a resource provider can have multiple traits
22:43:19 mriedem and a trait can be used by multiple resource providers
22:43:28 mriedem used/exposed whatever
22:43:36 mriedem alright
22:44:19 openstackgerrit Matt Riedemann proposed openstack/nova master: [placement] Add Traits related table to the api database https://review.openstack.org/376198
22:45:08 mriedem jaypipes: dansmith: ok +2 on https://review.openstack.org/#/c/376198/ now
22:49:57 jaypipes mriedem: yup, zactly correct.
22:50:06 jaypipes mriedem: and thanks for adding that blueprint to get this going.
22:50:18 dansmith jaypipes: left the +W for you
22:51:14 mriedem ok hosers i'll talk to you tomorrow
22:52:16 dansmith melwitt: *gasp* https://review.openstack.org/#/c/438025/
22:52:33 dansmith looks like the gate is too busy to run my devstack patch against that, but at least it's passing the regular setup
22:53:40 jaypipes Wallaby'd.
23:00:30 masber hi
23:00:46 dansmith infra says nodepool is jammed up, fyi to anyone waiting
23:01:26 masber anybody knows why when I do "nova image-create --poll ..." the image size is 0?
23:01:53 masber I am following this document --> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/End_User_Guide/cli_migrate_instances.html#create_snapshot
23:02:10 masber and this one --> https://docs.openstack.org/user-guide/cli-use-snapshots-to-migrate-instances.html
23:02:38 dansmith masber: that first document is about icehouse, which is ancient. nova image routines are deprecated, and this is not a support channel (please see topic)
23:11:30 masber dansmith, sorry, I couldn't get help on #openstack channel
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 Cell0 is already setup
05:31:48 prometheanfire Unable to sync cell0 schema: (psycopg2.OperationalError) FATAL: database "nova_cell0" does not exist
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.

Earlier   Later