Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-16
15:52:35 mriedem jaypipes: this is what i was talking about https://github.com/openstack/nova/blob/7e0edc67108b3b9d23549a6d3c0d3106dfc2acec/nova/objects/resource_provider.py#L563 - but as noted on the call, it's not in allowed_filters (or the schema now)
15:53:34 jaypipes mriedem: ah. well, yeah, it could never have been added via the API or exposed to it.
15:54:03 mriedem jaypipes: you said you need to rebase this? https://review.openstack.org/#/c/407309/
15:54:22 jaypipes mriedem: yeah.
15:55:19 openstackgerrit Pawel Koniszewski proposed openstack/nova: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489
15:55:21 openstackgerrit Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997
15:55:21 openstackgerrit Pawel Koniszewski proposed openstack/nova: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744
15:58:42 bauzas jaypipes: refrain your pencil, I'm litterally rebasing now
15:59:10 bauzas jaypipes: that will still make Jenkins unhappy, but at least you'd get a fresh copy
15:59:27 cdent I'm going to emboss "refrain your pencil" somewhere. Has a very nice ring to it.
16:04:22 openstackgerrit Sylvain Bauza proposed openstack/nova: Add ComputeNode.get_by_uuid method https://review.openstack.org/418134
16:04:22 openstackgerrit Sylvain Bauza proposed openstack/nova: WIP: Scheduler calling the Placement API https://review.openstack.org/417961
16:04:34 bauzas jaypipes: mriedem: there it is
16:06:32 mriedem bauzas: ok issue in the bottom change
16:06:42 bauzas snap snap
16:07:20 bauzas mriedem: roger, this.
16:07:23 bauzas mriedem: on it
16:08:37 mriedem do we have a migration that added a uuid to every existing compute_nodes record?
16:08:55 mriedem cdent: in honor of you calling out my haggard looks i've brewed another cup of coffee
16:09:19 cdent I am your enabler?
16:09:46 mriedem yes
16:09:58 cdent Is that a paid position?
16:10:09 mriedem now when i get the caffeine shakes i know who to blame
16:10:25 openstackgerrit Andrey Volkov proposed openstack/nova: Add nova-manage cell_v2 create_cell command https://review.openstack.org/332713
16:11:12 openstackgerrit Vasyl Saienko proposed openstack/nova: Support Ironic interface attach/detach in nova virt https://review.openstack.org/364413
16:11:13 openstackgerrit Vasyl Saienko proposed openstack/nova: Generate necessary network metadata for ironic port groups https://review.openstack.org/388756
16:11:40 mriedem ah migration 330
16:11:42 mriedem cool
16:12:44 bauzas mriedem: oh oops, sorry missed your question
16:12:50 bauzas mriedem: yeah, it was done AFAIK
16:13:41 openstackgerrit Andrey Volkov proposed openstack/nova: Add nova-manage cell_v2 create_cell command https://review.openstack.org/332713
16:15:35 melwitt mriedem: I had thought the map_cell0 name/connection was intentionally based on the api db because they're expected to be co-located together
16:19:55 openstackgerrit Sylvain Bauza proposed openstack/nova: Add ComputeNode.get_by_uuid method https://review.openstack.org/418134
16:19:56 openstackgerrit Sylvain Bauza proposed openstack/nova: WIP: Scheduler calling the Placement API https://review.openstack.org/417961
16:20:04 gibi mriedem: hi! I managed finish the notification lazy load field bugfix. I didn't manage to split it up nicely. If you have time could you please check it? https://review.openstack.org/#/c/415857/
16:23:05 openstackgerrit Mikhail Feoktistov proposed openstack/nova: libvirt: ephemeral disk support for virtuozzo containers https://review.openstack.org/312488
16:28:05 openstackgerrit Vasyl Saienko proposed openstack/nova: Support Ironic interface attach/detach in nova virt https://review.openstack.org/364413
16:28:05 openstackgerrit Vasyl Saienko proposed openstack/nova: Generate necessary network metadata for ironic port groups https://review.openstack.org/388756
16:29:53 mriedem melwitt: i'm not sure, we'd probably have to ask alaski if he remembers a specific reason for calling it nova_api_cell0 even though it's using the main db schema
16:31:14 melwitt that was my understanding anyway
16:31:58 openstackgerrit Vasyl Saienko proposed openstack/nova: Support Ironic interface attach/detach in nova virt https://review.openstack.org/364413
16:31:59 openstackgerrit Vasyl Saienko proposed openstack/nova: Generate necessary network metadata for ironic port groups https://review.openstack.org/388756
16:36:26 mriedem melwitt: still, co-locating the nova_api db and cell0 doesn't mean we should name it nova_api_cell0 right? unless it just meant something like, cell0 is only used at the api/controller level
16:36:26 mriedem idk
16:36:30 mriedem it's probably confusing either way
16:37:10 mriedem we should probably figure out what we want though before all of dansmith's changes for it go in
16:39:43 melwitt mriedem: yeah, I could see the name being confusing. I'm trying to think if there's any caveat to making it default to the main db connection. I thought the idea was it's an api cell construct, so default to the connection of the other api cell db
16:41:01 mriedem melwitt: you want to comment on https://review.openstack.org/#/c/420439/ ?
16:41:07 mriedem it's held up by dependencies right now
16:41:16 melwitt okay
16:41:37 mriedem it would be nice if we didn't have to make the change because it's also in devstack and grenade, and potentially backports
16:42:19 mriedem but this comment in the code was wrong: "The cell0 database will use the same database scheme and netloc as the API database"
16:42:27 mriedem which leads me to believe it was just a mistake from the beginning
16:51:51 melwitt mriedem: I was thinking about that and I think it meant scheme as in, url format. not database schema
16:52:05 melwitt I left a comment on the review, fwiw
16:52:08 mriedem oh maybe
16:53:32 mdbooth http://eventlet.net/doc/modules/greenthread.html#eventlet.greenthread.spawn
16:53:50 mdbooth Is there any way to deterministically get a GreenThread object before it starts running?
16:54:10 mdbooth I want to do:
16:54:19 mdbooth x = GreenThread()
16:54:34 mdbooth ...register thread somewhere...
16:54:39 mdbooth x.run()
16:55:14 mriedem mnaser: i'm assumed at your '99% of this volume multiattach stuff is done on the cinder side' comment in the ops list :)
16:55:30 mnaser mriedem hi
16:55:41 mnaser yeah, i think cinder side has multiattachments already setup
16:55:50 mnaser APIs have all that stuff already wired up
16:56:06 mnaser i think the part that never merged was the nova side that made the appropriate api calls and interacted with it
16:56:23 mriedem mnaser: yes i'm fully aware of the history
16:56:31 mriedem but it's not that simple
16:56:54 mnaser mriedem: of course it's not :) it's probably why it never got finished up, i'm very understanding of that
16:57:21 mnaser sorry if that came off as "nova team, finish your job" .. i understand there's complexities involved but i meant it more of "half of the battle is done"
16:57:51 mriedem yeah i know, i've already replied to that thread with details
16:58:28 mnaser mriedem: awesome, thank you so much for following up and being always on top of things :)
17:00:06 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot notifications https://review.openstack.org/382959
17:14:59 mriedem sdague: some fun 'what do you want in pike' big items in the operators list, which are cross-project fodder for the TC probably at the ptg/boston summit
17:16:05 mriedem avolkov: i'm going to rebase my list and delete cells patches on top of your create_cell patch
17:16:11 mriedem just to avoid all of the eventual conflicts
17:16:17 sdague mriedem: ok, I'll take a look. I've been a little heads down today recoding the devstack ini / local.conf manipulation in python as the complexity of merging local.conf files in grenade exceeds the bash code we have
17:16:27 sdague and that's the hold up for d-g support of local.conf
17:16:28 mriedem yeah i saw that in qa
17:16:30 dansmith mriedem: so, it would be super awesome if we could merge the bottom three patches in my set today before I go, or at least get some real review on them
17:16:32 dansmith that would be here and down: https://review.openstack.org/#/c/410473/10
17:16:56 mriedem yeah it's just the next 2 then
17:17:10 mriedem dansmith: did you see the convo i was having with melwitt about about the cell0 naming thing?
17:17:22 dansmith mriedem: no, was on calls sorry
17:17:33 mriedem she also commented on the change, sec
17:17:43 mriedem https://review.openstack.org/#/c/420439/5/nova/cmd/manage.py
17:18:28 mriedem if she's right then we should sort that out before the grenade/devstack/series merges
17:18:46 mriedem plus possible newton backports
17:19:55 dansmith if she's right about wht?
17:20:03 dansmith I was just replying
17:20:16 mriedem well about the connection url and naming
17:20:38 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot notifications https://review.openstack.org/382959
17:20:54 dansmith I'm sure the intent was because the cell0 db may often be co-located, but it's far too confusing, IMHO
17:21:34 openstackgerrit Matt Riedemann proposed openstack/nova: Add InstanceMappingList.get_by_cell_id https://review.openstack.org/420450
17:21:34 openstackgerrit Matt Riedemann proposed openstack/nova: Add nova-manage cell_v2 create_cell command https://review.openstack.org/332713
17:21:35 openstackgerrit Matt Riedemann proposed openstack/nova: Add nova-manage cell_v2 delete_cell command https://review.openstack.org/420451
17:21:35 openstackgerrit Matt Riedemann proposed openstack/nova: Create HostMappingList object https://review.openstack.org/420449
17:21:36 openstackgerrit Matt Riedemann proposed openstack/nova: Add nova-manage cell_v2 list_cells command https://review.openstack.org/420440
17:22:55 melwitt what's confusing about it? that is, did something specific happen to incite this change?

Earlier   Later