| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 20:36:04 | tdurakov | mriedem: ok, will submit new deprecation one | |
| 20:36:21 | tdurakov | but will remove that in a next release:-p | |
| 20:50:10 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: Deperecate cell_name cli arg for migration-list https://review.openstack.org/439147 | |
| 20:50:19 | tdurakov | mriedem: ^ | |
| 20:53:29 | mriedem | sfinucan: you've been deprecating nova-network related options, why not also firewall_driver? | |
| 20:53:54 | mriedem | once nova-network is gone, there is only one impl for firewall_driver which is the noop one | |
| 21:05:47 | tonyb | sfinucan: \o/ | |
| 21:33:50 | dansmith | mriedem: so on the traits thing, | |
| 21:34:21 | dansmith | mriedem: I would hate to see us delay merging the mechanical stuff because we're obsessing over the stuff in the spec which is a little higher level than what we need right away | |
| 21:34:48 | dansmith | obviously I don't want to have two specs, but I wonder if we could move the -2 up a couple patches without risking too much? | |
| 21:35:26 | dansmith | I haven't looked over the comments on the spec, I just see that there are some | |
| 21:38:14 | mriedem | do we have any api db blocker migrations we need to do first or anything? | |
| 21:38:32 | dansmith | I don't think so | |
| 21:38:56 | dansmith | that said, I'm looking at the set of patches and I'm not sure where I'd re-place the -2 without just delaying at a different spot | |
| 21:39:05 | dansmith | so maybe it's not worth it | |
| 21:40:16 | mriedem | unicode traits huh | |
| 21:40:22 | mriedem | pile of poo can be a trait | |
| 21:46:17 | mriedem | do we have a resource tracker patch ready to set the trait that depends on this data model change? | |
| 21:46:30 | mriedem | i don't see anything in RT building on this yet | |
| 21:49:17 | dansmith | mriedem: the only RT intersection is reporting the compute-node trait on startup/RP creation or something | |
| 21:50:31 | mriedem | yeah, and then the scheduler passing that into the resource provider GET query with the filter param right? | |
| 21:50:38 | mriedem | and something something aggregates fits in there too | |
| 21:50:53 | mriedem | so, | |
| 21:51:11 | mriedem | the immediate need for this is for scheduling with shared storage pools and aggregate resource providers right? | |
| 21:51:39 | mriedem | we have a separate bp for that - we could just tie this into that work and decouple the data model change from the REST API/scheduling fallout that will probably come from the traits spec | |
| 21:51:41 | mriedem | if that makes sense | |
| 21:52:16 | dansmith | scheduler asks for that trait to placement, but yeah | |
| 21:52:42 | dansmith | the immediate need is that we can't start reporting any shared pool resources (regardless of if we use them) until we can distinguish them from compute nodes | |
| 21:52:53 | mriedem | yeah, so let's do the traits data model change under https://blueprints.launchpad.net/nova/+spec/shared-resources-pike | |
| 21:53:10 | mriedem | is that a fair compromise? | |
| 21:53:42 | dansmith | is that a paperwork hack? | |
| 21:53:47 | dansmith | I don't care how you justify it :P | |
| 21:54:52 | mriedem | it's a papercut | |
| 21:55:24 | dansmith | *rimshot* | |
| 21:55:34 | mriedem | jaypipes: oh sql wizard of yore, can you answer my question in https://review.openstack.org/#/c/376198/11/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/041_resource_provider_traits.py@57 ? | |
| 21:57:02 | mriedem | cburgess: L33 here https://etherpad.openstack.org/p/nova-ptg-pike-cinder | |
| 21:57:12 | cburgess | mriedem Yes what? | |
| 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? | |