Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-16
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
17:52:22 mriedem and by handle it in config, i mean if they want cell0 to use the same host/user/password as the nova_api db and not the main db
17:52:41 melwitt mriedem: yes, --config-file is key to setting up cells v1 anyway
17:52:55 dansmith if they don't want to use the command line, then they need to have two separate places to define it anyway
17:52:59 dansmith in the config I mean
17:53:39 openstackgerrit Gábor Antal proposed openstack/nova: Added instance.reboot.error to the legacy notifications https://review.openstack.org/411816
17:53:46 dansmith the re-use of the config elements to avoid using command line args is super confusing and annoying to me
17:53:52 mdbooth I have a test which uses threading (it's a concurrency test, this is unavoidable)
17:53:54 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot.error notification https://review.openstack.org/411791
17:54:07 dansmith it would be better, IMHO, if we had a yaml format for creds or something that we just had people create for each insertion they want to use,
17:54:21 mdbooth I'm explicitly using threading.Thread rather than eventlet.greenthread, because the latter doesn't do what I need
17:54:35 dansmith instead of "create a fake config, put just this section/keys in there, then we'll use that to create a db row instead of reading that config at runtime like it was intended"...
17:54:49 mdbooth I create a thread and start it, but when the thread does threading.current_thread() it gets the main thread
17:55:03 mdbooth Is this some evilness related to eventlet?
17:55:57 melwitt dansmith: yeah, I guess cell0 is a special case. for all the other things, it makes sense to say "base this cell upon my old cells v1 cell conf". cell0 might probably be a whole new host/user/pass
17:56:06 mdbooth threading.current_thread() has the expected behaviour for me when not run in the test harness
17:56:30 dansmith melwitt: well, that case applies to like four operators.. the other billion will be creating fake configs when they want to configure or spin up new cells
17:57:19 melwitt dansmith: only if they don't want to pass on command line, yeah
17:57:34 dansmith melwitt: well, right, that's what I'm railing against :)
17:57:50 mdbooth 'eventlet.green.threading'
17:57:50 mdbooth (Pdb) threading.current_thread.__module__
17:57:55 mdbooth eventlet: j'accuse!
18:00:13 melwitt dansmith: yeah, it would be good to have a real way of doing that
18:02:26 jaypipes gah, nested resource providers needs yet another rebase :)
18:02:40 mriedem melwitt: dansmith: sounds like a clouds.yaml kind of thing, but a bit different
18:02:45 mriedem nova-db.yaml :)
18:02:54 dansmith mriedem: yeah, like that
18:03:15 ildikov mriedem: I'm guessing if the version negotiation with the client can get sorted out then we can do the testing in the placement_api job as you seuggested earlier, right?

Earlier   Later