Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-16
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: Generate necessary network metadata for ironic port groups https://review.openstack.org/388756
16:28:05 openstackgerrit Vasyl Saienko proposed openstack/nova: Support Ironic interface attach/detach in nova virt https://review.openstack.org/364413
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 idk
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: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 nova-manage cell_v2 create_cell command https://review.openstack.org/332713
17:21:34 openstackgerrit Matt Riedemann proposed openstack/nova: Add InstanceMappingList.get_by_cell_id https://review.openstack.org/420450
17:21:35 openstackgerrit Matt Riedemann proposed openstack/nova: Create HostMappingList object https://review.openstack.org/420449
17:21:35 openstackgerrit Matt Riedemann proposed openstack/nova: Add nova-manage cell_v2 delete_cell command https://review.openstack.org/420451
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?
17:23:06 mriedem while reviewing the docs patch,
17:23:33 mriedem i pointed out that if --database_connection is not provided to map_cell0 the connection url comes from the CONF.api_database.connection, not CONF.database.connection as dan had originally written in the docs patch
17:23:45 dansmith it's confusing because we're taking a url and database name that points to an api schema thing, mangling it, and putting main schema in it, and calling it something with "api" in the name
17:23:47 mriedem which took us down this path
17:24:35 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/420844
17:25:18 melwitt okay. yeah, I can agree the name could be confusing, but I thought the connection, which is like host/user/password makes sense to be the same as the api db as a default. no?
17:25:50 dansmith I don't see why it makes sense for those to be the same?
17:25:52 melwitt that's what we wanted to encourage, that these are the two api dbs
17:26:09 melwitt and it makes sense to put them on the same hosts
17:26:13 mriedem maybe we should have just made the connection arg required
17:26:17 mriedem so we didn't have to guess
17:26:20 dansmith cell0 will grow indefinitely and need to be purged, api db will not.. that means different planning for those types of things
17:26:30 dansmith mriedem: that's fine too
17:27:21 melwitt dansmith: hm, okay. I hadn't thought of that
17:28:03 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient: Updated from global requirements https://review.openstack.org/420861
17:44:32 openstackgerrit Dan Peschman proposed openstack/nova: nova-manage cell_v2 map_cell0 exit 0 https://review.openstack.org/420132
17:45:41 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot notifications https://review.openstack.org/382959
17:47:51 mriedem dansmith: melwitt: so i don't have super strong feelings either way, would be nice if alaski were around to break any ties
17:48:23 mriedem i lean toward the name change trumping the chance of the cell0 and nova_api db connection creds being the same
17:48:48 mriedem i've already started working on backporting the fixes to stable/newton in case we want those
17:49:07 mriedem i tend to think that with most deployments not even at newton yet those would be good to have fixed by the time they upgrade
17:49:10 dansmith I think that we're leaning towards people not doing the simple thing, and thus not just arbitrarily using the same url/creds for everything, so I want us to be more sane
17:49:53 mriedem yeah which making the db connection arg required would fix that, but i'm not sure i want to backport that change
17:50:13 dansmith yeah
17:50:16 mriedem we could make db connection required in ocata, not backport anything, but put out a release note in newton saying you should be explicit when using map_cell0
17:50:29 melwitt yeah, I don't think we should do that being that we know people don't want to be forced to pass connection strings on the command line
17:52:01 mriedem melwitt: sure, but then we're also forcing them to handle it in config, i guess they can pass the --config-file option to nova-manage too
17:52:13 melwitt if there's reason to have api db and cell0 db not be co-located (which has been mentioned today) then that addresses my concern about it. I had been thinking co-locating them would be most common, but if it wouldn't be, then I think it's fine not to default it that way

Earlier   Later