Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-27
16:34:44 mdbooth hemna: I was also thinking the other day that locking requirements are driver-specific
16:34:51 imacdonn go away*
16:35:02 mdbooth hemna: So if we don't want os-brick to do any locking, I get that
16:35:19 mdbooth However, we still need a way for os-brick to tell us what locks we need to hold
16:35:33 mdbooth Take this case, for eg, the lock we want is per-target
16:35:43 mdbooth The caller has no idea what a target is, only os-brick knows that
16:36:04 hemna just lock around the process of disconnecting a volume from the host
16:36:18 hemna which is the workflow of disconnect_volume(), then terminate_connection()
16:36:20 mdbooth lock *what* around the process of disconnecting a volume
16:36:31 imacdonn hemna: it's not, though
16:36:34 mdbooth And now all drivers are going to have the same serialisation requirements
16:36:47 mdbooth For some drivers, concurrent attach/detach is fine
16:36:50 imacdonn hemna: terminate_connection() is called from a bunch of different places in compute.manager
16:36:50 mdbooth Others not
16:37:13 mdbooth For some, async terminate_connection is fine, no locking required
16:37:15 mdbooth Others not
16:37:27 mdbooth This is a hard interface
16:39:55 mdbooth hemna: On the terminate_connection front, it could reasonably be a callback for eg
16:40:05 mdbooth Then os-brick wouldn't have to know anything about cinder
16:40:41 mdbooth But 'tell the target to kill this lun now' is a generic concept
16:41:15 imacdonn yeah, that's what I'm envisaging
16:59:06 hemna ok so why does this guy not call brick's disconnect_volume ?
16:59:07 hemna https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3616
17:00:06 hemna This is what a proper disconnect workflow should look like in nova https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2264-L2268
17:00:59 hemna err
17:01:01 hemna wait...lol
17:01:09 hemna that doesn't call brick either.
17:01:34 imacdonn right ... brick gets called from within driver.destroy .. that's the problem
17:01:52 imacdonn as the comment right there says ;)
17:02:07 hemna boo!
17:04:08 imacdonn the hack that's gotten me by since icehouse is to put a lock on _shutdown_instance() (and a few similar places in manager) and the same lock on connect_volume() in virt.libvirt.volume.iscsi
17:05:28 openstackgerrit Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/460305
17:05:58 johnthetubaguy mdbooth: that iSCSI question, isn't that backend specific? I thought it was one iSCSI target per volume for some?
17:11:42 openstackgerrit Samantha Blanco proposed openstack/nova master: Remove flavor-rxtx policy https://review.openstack.org/444036
17:37:59 openstackgerrit Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to local_cleanup https://review.openstack.org/456851
17:43:52 efried mordred Have a chance to skim https://review.openstack.org/#/c/460337/ yet?
17:44:05 efried mordred I'm working on the nova changes to accomodate.
17:46:21 mordred oh good - they're fixed now
17:47:03 efried trivial pep8 stuff. Still haven't done live testing, just wanting to make sure I'm heading down the right path here.
18:08:52 mriedem johnthetubaguy: i thought we had a policy check for showing fault details?
18:09:01 mriedem but i don't see that here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L280
18:09:08 mriedem except the is_admin check
18:28:12 efried sdague Got a sec to talk about [glance]api_server*s* ?
18:37:16 linuxman openstack-nova-scheduler service unable to start how to fix this issue
18:39:45 openstackgerrit Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to shutdown_instance https://review.openstack.org/456877
18:40:47 efried linuxman I think you want to ask that in #openstack?
18:41:29 linuxman but i hava a problem with nova service
18:42:10 efried Counts as "support of Nova deployments", nah?
18:42:12 mriedem linuxman: see the channel topic please, this is generally not a support channel, especially without any sort of context on the specific issue
18:42:36 mriedem "does not start" is not very helpful for debugging
18:44:06 mriedem thorst: it's snowing here, just fyi
18:44:22 linuxman you have any idea about proper rdo openstack channel
18:45:25 mriedem linuxman: i don't see one on https://wiki.openstack.org/wiki/IRC
18:45:29 mriedem but i'd try #openstack-rdo?
18:45:47 mriedem doesn't look like that's it
18:46:09 mriedem linuxman: https://www.rdoproject.org/community/#discuss
18:46:18 imacdonn just #rdo I think
18:46:21 mriedem yes
18:46:46 linuxman just #rdo i tried but know one is there
18:47:09 mriedem i count 291 people
18:47:32 mriedem make sure you're on freenode
18:47:40 imacdonn I'm there .. I'm not just paying attention ;)
18:48:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Expose StandardLogging fixture for use https://review.openstack.org/460642
18:48:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Do not log live migration success when it actually failed https://review.openstack.org/458958
18:48:34 mriedem sdague: i made all of your log fixture dreams come true
18:51:30 mriedem dansmith: you want to tickle this little ocata fix in https://review.openstack.org/#/c/459840/ ?
18:52:11 mriedem dansmith: should i be reviewing https://review.openstack.org/#/c/460616/ ?
18:52:18 mriedem is ironic/tripleo testing that out?
18:52:48 thorst mriedem: lol. It's 80 in RTP
18:53:06 mriedem oh now that i look out the window again the snow stopped
18:53:09 mriedem that's like the 3rd time today
18:53:28 mriedem i could just be hallucinating
18:53:50 dansmith mriedem: working with them now and on functional tests
18:53:54 mriedem ok
18:59:16 mriedem EmilienM: "Postgresql support (or call it how you want) is also removed upstream in OpenStack." where was that decided?
18:59:22 mriedem the governance change was abandoned i thought?
18:59:34 EmilienM yeah probably
18:59:46 EmilienM mriedem: AFIK there is a session in Boston about that
18:59:51 cfriesen is it possible to run individual functional tests?
18:59:55 mriedem right, but your email says it was removed
18:59:58 mriedem cfriesen: yes
19:00:04 EmilienM mriedem: we're got some feedback from our users who use postgres, I don't think we'll remove the code in our side.
19:00:12 EmilienM mriedem: I was wrong
19:00:34 mriedem cfriesen: tox -e functional -- nova.tests.functional.....
19:00:49 cfriesen mriedem: thanks, I didn't have the double dash and it didn't like me
19:01:39 mriedem -- is key
19:06:48 sdague mriedem: nice
19:11:40 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove legacy v2.0 code from test_flavor_access https://review.openstack.org/460719
19:13:44 openstackgerrit Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616
19:16:04 dansmith mriedem: you can look at this now ^
19:16:14 dansmith pretty sure that'll do it for them but they're testing now
19:17:21 mriedem will do after jaybird's get_inventory libvirt change
19:17:39 abhi89 johnthetubaguy: Hi.. can you please review https://review.openstack.org/460305.. you had suggested to change the exception message while translating the cinder exception..
19:26:11 mriedem jaypipes: your patch made me think of this ^
19:26:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a note to *_allocation_ratio options about Ironic hardcode https://review.openstack.org/460722
19:41:24 abhi89 melwitt: Hi Melanie..
19:41:39 melwitt abhi89: hi
19:41:47 abhi89 melwitt: regarding https://review.openstack.org/#/c/460305/
19:43:22 abhi89 in that fix, previously, everytime we had a volume related quota exception ('gigabytes', 'volumes', 'per_volume_gigabytes'), we used to raise VolumeLimitExceeded exception
19:44:02 abhi89 now with my change, we give appropriate exception message for each of those 3 exceptions

Earlier   Later