| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 21:57:16 | mriedem | cburgess: what was the outcome of that? wasn't it "roll this into johnthetubaguy's spec"? | |
| 21:57:23 | cburgess | Yes it was | |
| 21:57:49 | mriedem | hot | |
| 21:57:50 | mriedem | damn | |
| 21:58:15 | cburgess | mriedem See my comments on https://review.openstack.org/#/c/373203/14 | |
| 21:58:22 | cburgess | I need to re-review that though now. | |
| 21:59:07 | mriedem | thus concludes my nova/cinder recap email, yay | |
| 22:00:05 | cburgess | mriedem I'll review rev 15 of that spec today and update with any comments I have as it related to our spec that needs to be merged into this one. | |
| 22:00:21 | mriedem | super | |
| 22:09:17 | cburgess | mriedem Comments added. We still need to account for the changes that will impact BFV in the spec | |
| 22:12:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Default firewall_driver to nova.virt.firewall.NoopFirewallDriver https://review.openstack.org/439187 | |
| 22:36:01 | jaypipes | mriedem: answered. sorry for delay. | |
| 22:36:13 | jaypipes | mriedem: I blame cburgess. | |
| 22:36:34 | cburgess | jaypipes Wait what did I do this time? | |
| 22:37:21 | mriedem | jaypipes: i'm not sure i understand your response | |
| 22:37:34 | mriedem | resource_provider_traits doesn't have a unique constraint defined, but it has 2 primary keys | |
| 22:37:47 | mriedem | do we not need a unique constraint because of those 2 primary keys? | |
| 22:38:28 | cburgess | A primary key is already unique. Why would you need to unique them again? | |
| 22:38:36 | jaypipes | cburgess: everything. you did everything. | |
| 22:38:45 | mriedem | it's the combo, but i think i'm just over thinking it | |
| 22:38:52 | jaypipes | mriedem: the primary key is unique and already contains trait and provider id, yes. | |
| 22:39:02 | cburgess | jaypipes I'm glad someone has finally realized that. | |
| 22:39:53 | jaypipes | mriedem: and the uniqueness isn't dependent on the order. In other words, the constraint of uniqueness over (trait, provider) applies implicitly to (provider, trait) | |
| 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 | |