| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-28 | |||
| 19:56:59 | mriedem | i believe that's why os-migrations is marked as "frozen" | |
| 19:57:06 | mriedem | although the APIs do behave differently | |
| 19:57:13 | mriedem | so it's kind of odd that os-migrations is frozen | |
| 19:57:28 | mriedem | it seems to be frozen for a very specific case, which is the in-progress live migration case so you can cancel those things | |
| 19:57:38 | tdurakov | my current understanding of the problem: I'd like to see /servers/uuid/migrations become more useful(not only live-migrations) and maybe not only active, based on that I think it's worth to have a mechanism to filter migrations not only by instnace, but host and cell as well | |
| 19:57:46 | mriedem | but if i'm an admin and i just want to see any migration, including completed ones, i can't use /servers/id/migrations | |
| 19:58:40 | mriedem | i don't even see where os-migrations filters by cell | |
| 19:59:13 | tdurakov | mriedem: http://paste.openstack.org/show/600833/ | |
| 19:59:30 | mriedem | tdurakov: in general yes, i think if /servers/id/migrations replaces os-migrations, then the former needs to be built up to serve the needs that the latter already provideds | |
| 19:59:34 | mriedem | *provided | |
| 19:59:39 | tdurakov | is doc help doc misleading? | |
| 19:59:44 | mriedem | i think so | |
| 19:59:51 | mriedem | i don't see anything in the db api code about filtering migrations by cell name | |
| 20:01:05 | tdurakov | at the same point it would be weird to filter out migration by host at the uri: /servers/id/migrations because it's about servers, righht? | |
| 20:01:10 | mriedem | yeah cell_name is passed as a query parameter | |
| 20:01:16 | mriedem | correct | |
| 20:01:31 | mriedem | so the GET query parameters are passed way down to migration_get_all_by_filters in the db api | |
| 20:01:38 | mriedem | and cell_name isn't a thing that gets filtered on | |
| 20:01:42 | mriedem | so the CLI code is lying to us | |
| 20:01:43 | mriedem | :) | |
| 20:02:14 | mriedem | cell_name is not even in the migrations table | |
| 20:02:22 | mriedem | so i don't know who thought that up | |
| 20:07:19 | mriedem | https://github.com/openstack/python-novaclient/commit/3c2a817efcb6954f3c8246c32ce997b9e3a4d000 | |
| 20:07:23 | mriedem | cell_name was just always there | |
| 20:07:39 | mriedem | crazy ass rax | |
| 20:07:44 | mriedem | i'll remove that from novaclient | |
| 20:11:02 | mriedem | this will allow me to procrastinate on recapping the resource provider talk from the PTG, which i didn't follow most of i don't think | |
| 20:11:26 | mriedem | something something traits ironic inventory success glory fame | |
| 20:11:33 | mriedem | jaypipes: ^ is that the summary from the PTG? | |
| 20:13:48 | mriedem | sdague: i suppose to be a nice guy, i should deprecate a completely worthless and unused CLI arg/python API binding option in novaclient for a release before removing it right? | |
| 20:13:55 | mriedem | even though it's never ever worked | |
| 20:15:13 | tdurakov | mriedem: patch is in progress | |
| 20:15:26 | mriedem | tdurakov: are you deprecating or removing? | |
| 20:15:28 | mriedem | also https://bugs.launchpad.net/python-novaclient/+bug/1668743 | |
| 20:15:28 | openstack | Launchpad bug 1668743 in python-novaclient "nova migration-list --cell_name does not actually do anything" [Undecided,New] - Assigned to Matt Riedemann (mriedem) | |
| 20:15:31 | tdurakov | no reason procrastinating on resource provider | |
| 20:27:34 | jaypipes | mriedem: kind of, though I'm actually writing an email summarizing resource providers/placement stuff at the PTG. do you want me to continue that? | |
| 20:28:18 | mriedem | jaypipes: that would be tops | |
| 20:29:30 | jaypipes | mriedem: so, continue this email then? :) | |
| 20:29:31 | openstackgerrit | Timofey Durakov proposed openstack/python-novaclient master: remove cell_name parameter from nova migration-list https://review.openstack.org/439141 | |
| 20:29:38 | tdurakov | mriedem: if you still want to procrastinate^ | |
| 20:30:02 | mriedem | jaypipes: yes please | |
| 20:30:15 | mriedem | contrary to popular belief i don't love doing the recap emails | |
| 20:35:11 | tdurakov | mriedem: what's the proper way deprecating params in nova-client? | |
| 20:35:26 | mriedem | tdurakov: there is a DeprecatedAction class | |
| 20:35:30 | mriedem | it's used elsewhere | |
| 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? | |