Wednesday, 2016-03-30

*** harlowja has quit IRC00:05
*** sdake has quit IRC00:22
*** sdake has joined #openstack-meeting-cp00:24
*** dtroyer has left #openstack-meeting-cp00:36
*** harlowja has joined #openstack-meeting-cp00:54
*** sdake_ has joined #openstack-meeting-cp00:59
*** sdake has quit IRC01:02
*** sheel has joined #openstack-meeting-cp01:03
*** jklare has quit IRC01:31
*** jklare has joined #openstack-meeting-cp01:33
*** amrith is now known as _amrith_01:56
*** dims has quit IRC01:59
*** dims has joined #openstack-meeting-cp02:04
*** Rocky_g has quit IRC02:14
*** dims_ has joined #openstack-meeting-cp02:45
*** dims has quit IRC02:46
*** sdake_ is now known as sdake03:07
*** sdake_ has joined #openstack-meeting-cp03:17
*** sdake has quit IRC03:20
*** vilobhmm11 has joined #openstack-meeting-cp03:25
*** askb has joined #openstack-meeting-cp03:42
*** vilobhmm11 has quit IRC04:34
*** markvoelker has joined #openstack-meeting-cp04:36
*** vilobhmm11 has joined #openstack-meeting-cp04:47
*** sdake_ has quit IRC05:20
*** sdake has joined #openstack-meeting-cp05:29
*** sdake has quit IRC05:48
*** sdake has joined #openstack-meeting-cp05:51
*** markvoelker has quit IRC06:10
*** markvoelker has joined #openstack-meeting-cp06:26
*** markvoelker has quit IRC06:39
*** vilobhmm11 has quit IRC06:40
*** vilobhmm11 has joined #openstack-meeting-cp06:40
*** markvoelker has joined #openstack-meeting-cp07:40
*** markvoelker has quit IRC07:45
*** sdake_ has joined #openstack-meeting-cp07:49
*** sdake has quit IRC07:51
*** takashin has joined #openstack-meeting-cp07:55
*** takashin has left #openstack-meeting-cp07:55
*** sdake_ has quit IRC08:36
*** markvoelker has joined #openstack-meeting-cp08:42
*** markvoelker has quit IRC08:47
*** vilobhmm11 has quit IRC08:59
*** markvoelker has joined #openstack-meeting-cp09:44
*** markvoelker has quit IRC09:49
*** sdague has joined #openstack-meeting-cp10:16
*** _amrith_ is now known as amrith10:26
*** sdague has quit IRC10:53
*** sdague has joined #openstack-meeting-cp10:53
-openstackstatus- NOTICE: Gate on project-config is currently broken due to IRC tests. The problem has been detected and we are working to fix the issue as soon as possible.11:14
*** markvoelker has joined #openstack-meeting-cp11:46
*** markvoelker has quit IRC11:51
*** raildo-afk is now known as raildo12:11
*** david-lyle_ has joined #openstack-meeting-cp12:17
*** david-lyle has quit IRC12:17
*** amrith is now known as _amrith_12:44
*** markvoelker has joined #openstack-meeting-cp12:47
*** markvoelker has quit IRC12:51
*** ninag has joined #openstack-meeting-cp12:53
*** annegentle has joined #openstack-meeting-cp13:04
*** annegentle has quit IRC13:17
*** diablo_rojo has joined #openstack-meeting-cp13:18
*** nikhil_k has joined #openstack-meeting-cp13:18
*** nikhil has quit IRC13:19
*** annegentle has joined #openstack-meeting-cp13:38
*** ninag has quit IRC13:39
*** ninag has joined #openstack-meeting-cp13:41
*** ninag has quit IRC13:42
*** annegentle has quit IRC13:43
*** markvoelker has joined #openstack-meeting-cp13:48
*** markvoelker has quit IRC13:52
*** _amrith_ is now known as amrith13:58
*** Guest42028 has joined #openstack-meeting-cp14:00
*** Guest42028 has quit IRC14:07
*** sigmavirus24_awa is now known as sigmavirus2414:12
*** markvoelker has joined #openstack-meeting-cp14:16
*** sdake has joined #openstack-meeting-cp14:44
*** annegent_ has joined #openstack-meeting-cp14:46
*** markvoelker has quit IRC14:46
*** sdake_ has joined #openstack-meeting-cp14:56
*** sdake has quit IRC14:57
*** ninag has joined #openstack-meeting-cp14:58
*** annegent_ has quit IRC15:02
*** sdake has joined #openstack-meeting-cp15:08
*** sdake_ has quit IRC15:10
*** annegentle has joined #openstack-meeting-cp15:22
*** askb_ has joined #openstack-meeting-cp15:25
*** askb_ has quit IRC15:27
*** askb_ has joined #openstack-meeting-cp15:27
*** askb has quit IRC15:28
*** annegentle has quit IRC15:28
*** markvoelker has joined #openstack-meeting-cp15:29
*** askb_ has quit IRC15:29
*** askb_ has joined #openstack-meeting-cp15:29
*** askb_ has quit IRC15:31
*** askb_ has joined #openstack-meeting-cp15:31
*** askb_ has quit IRC15:32
*** askb_ has joined #openstack-meeting-cp15:33
*** askb_ has quit IRC15:35
*** askb_ has joined #openstack-meeting-cp15:35
*** askb_ has quit IRC15:37
*** askb_ has joined #openstack-meeting-cp15:37
*** askb_ has quit IRC15:38
*** annegentle has joined #openstack-meeting-cp15:46
*** annegentle has quit IRC15:51
*** mc_nair has left #openstack-meeting-cp16:00
*** annegentle has joined #openstack-meeting-cp16:03
*** annegentle has quit IRC16:05
*** stevemar has quit IRC16:08
*** openstack has joined #openstack-meeting-cp17:04
*** ChanServ sets mode: +o openstack17:04
*** annegentle has joined #openstack-meeting-cp17:07
*** nikhil_k is now known as nikhil17:35
*** sdake has quit IRC17:42
*** annegentle has quit IRC17:48
*** annegentle has joined #openstack-meeting-cp17:50
*** ninag has quit IRC18:03
*** annegentle has quit IRC18:03
*** gnarld_ is now known as cfouts18:06
*** vilobhmm11 has joined #openstack-meeting-cp18:15
*** sigmavirus24 is now known as sigmavirus24_awa18:34
*** annegentle has joined #openstack-meeting-cp18:35
*** sigmavirus24_awa is now known as sigmavirus2418:35
*** ninag has joined #openstack-meeting-cp18:53
*** sdake has joined #openstack-meeting-cp18:57
*** xyang1 has joined #openstack-meeting-cp19:47
*** rockyg has joined #openstack-meeting-cp19:53
*** angdraug has joined #openstack-meeting-cp19:55
*** tpatil has joined #openstack-meeting-cp19:58
*** sdake_ has joined #openstack-meeting-cp20:00
*** patrickeast has joined #openstack-meeting-cp20:01
*** sdake has quit IRC20:02
*** tyr_ has joined #openstack-meeting-cp20:03
*** annegentle has quit IRC20:03
tpatilIs the Cinder-Nova-API meeting postponed?20:08
thingeetpatil: looks like it's 21:00 utc, one more hour20:10
thingeehttp://lists.openstack.org/pipermail/openstack-dev/2016-March/090320.html20:10
*** angdraug has quit IRC20:12
tpatilthingee: Thanks. 21:00 UTC is 13:00 PST, it's already 13:11, anyway I will check again after one hour20:12
*** angdraug has joined #openstack-meeting-cp20:13
*** angdraug has quit IRC20:13
thingeetpatil: it's actually 14:00 with daylight saving time20:13
tpatilthingee: You are correct!20:14
*** tyr_ has quit IRC20:16
*** tyr_ has joined #openstack-meeting-cp20:17
*** annegentle has joined #openstack-meeting-cp20:21
*** ninag has quit IRC20:26
*** angdraug has joined #openstack-meeting-cp20:32
*** sdake has joined #openstack-meeting-cp20:32
*** tyr_ has quit IRC20:32
*** sdake_ has quit IRC20:33
*** takashin has joined #openstack-meeting-cp20:48
*** tyr_ has joined #openstack-meeting-cp20:50
*** andrearosa has joined #openstack-meeting-cp20:59
*** scottda has joined #openstack-meeting-cp21:00
ildikov#startmeting Cinder-Nova API changes21:00
ildikov#startmeeting Cinder-Nova API changes21:00
openstackMeeting started Wed Mar 30 21:00:24 2016 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:00
*** openstack changes topic to " (Meeting topic: Cinder-Nova API changes)"21:00
openstackThe meeting name has been set to 'cinder_nova_api_changes'21:00
scottdaHI21:00
patrickeasthey21:00
ildikovscottda ildikov DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr21:00
DuncanTHi21:00
cfoutshi21:00
ildikovmy typingabilities are limited, sorry :S21:00
andrearosahi21:00
takashinHi21:01
ildikovhi everyone21:01
*** tbarron has joined #openstack-meeting-cp21:01
ildikov#chair scottda21:01
openstackCurrent chairs: ildikov scottda21:01
* alaski lurks21:01
scottda#link https://etherpad.openstack.org/p/cinder-nova-api-changes21:01
scottdaildikov: I can type if you'd like21:01
ildikovlet's wait one more min for folks to show up21:02
scottdaOK21:02
tbarronhi21:02
*** jungleboyj has joined #openstack-meeting-cp21:02
jungleboyjo/21:02
*** mriedem has joined #openstack-meeting-cp21:02
mriedemi'm here!21:02
* jungleboyj cheers for mriedem 21:03
scottdaPlease add items to the etherpad under Issues Summary if y21:03
karthikphi21:03
ildikovok, I guess we can start21:03
scottdaSo, we'd like to fix some things in the API between Nova and Cinder21:03
ildikovthe agenda is on the etherpad scottda posted above21:03
ildikov#topic Briefly discuss the current situation, summarize/agree on the issues21:04
*** openstack changes topic to "Briefly discuss the current situation, summarize/agree on the issues (Meeting topic: Cinder-Nova API changes)"21:04
*** sdague has quit IRC21:04
scottdaOne issue we faced in Mitaka is with multi-attach in Nova...21:04
ildikovthere were a few mail threads on the mailing list about issues with the interaction between these two modules21:04
mriedemunfortunately i've failed at reading the multiattach detach thread21:05
mriedembut i think i have a general idea21:05
scottdaWe had to revert ildikov 's patches because it broke older Cinder clients by passing in a new parameter.21:05
ildikovmultiattach is special, it highlights already existing issues pretty well21:06
scottdaWe can fix that now that Cinder has api microversions21:06
scottdaBut that will require figuring out the pattern to use when Nova needs to use a cinder microversion. So that is one thing.21:06
mriedemscottda: those were the patches reverted during the midcycle right?21:06
scottdamriedem: yes21:06
mriedemand they were to what, pass the connector on attach/detach?21:07
scottdamriedem: I believe so21:07
ildikovthe passed the host name to Cinder21:07
scottdaoh, right.21:07
ildikov*they21:07
ildikovCinder can accept host name, but not host name and instance at the same time21:07
scottdaNewer (Mitaka +) cinder can, the issue is with LIberty and older21:08
ildikovdon't ask about the history of that check, but it's what broke Cinder21:08
mriedemso there is a microversion that added hostname to attach/detach?21:08
*** raildo is now known as raildo-afk21:08
ildikovscottda: yeah, exactly, hemna fixed this during Mitaka21:08
ildikovthis is why tests passed on the gate for my patch21:08
scottdamriedem: Actually, not microversioned in Cinder. just an optional parameter in Mitaka21:08
ildikovbut I think this is a small part of the whole issue21:09
mriedemso if i have a newton nova and liberty cinder,21:09
mriedemand nova passes hostname to cinder21:09
mriedemkablammo21:09
mriedemright?21:09
mriedeminstance + hostname21:09
scottdayes21:09
mriedemhence why we have microversions21:09
mriedemb/c nova has to ask what microversions it can send21:10
scottdaright21:10
*** amrith is now known as _amrith_21:10
scottdaAnd that paves the way for any other changes that are backward incompatible.21:10
mriedemwell, it's also about discoverability, but yeah21:11
scottdaYes. I think when Nova instantiates the cinderclient, it can figure out the server version then and possible store it.21:12
scottdaThen use that to trigger different logic in the code. maybe21:12
* scottda is waving his arms around here21:12
scottdaBut we'll have to figure out those details, and then use that pattern for other stuffs.21:12
scottdaildikov: Any other things around multiattach?21:13
mriedemdoes this fix the detach issue though?21:13
ildikovI'm not sure sending hostname will fix everything21:13
mriedemi thought there was a problem there where cinder needed to start storing the connector in the attachment db21:13
scottdamriedem: There is a POC by jgriffith that might help more with detach...21:14
scottda#link https://review.openstack.org/#/c/284867/21:14
ildikovmriedem: it's kind of an open question still that in what extent we're dealing with the dead horse in each module21:14
scottdaThat stores the connector in the attachment db21:14
ildikovmriedem: Cinder can figure out detach based on this extra info on it's side21:14
scottdaAnd could also return the attachment_id to Nova when intialize_connection is called.21:15
ildikovif the hostname is stored with the attachments in volume info than Nova can also use that information when disconnects a volume21:15
ildikovalthough we might face issues still due to the different Cinder drivers21:15
ildikovs/drivers/back ends/21:15
*** annegentle has quit IRC21:16
scottdaYes, that is another issue. Some drivers multiplex the iscsi connection for >1 volume to the same compute host. Others create 1 connection per attachment.21:16
mriedemscottda: "And could also return the attachment_id to Nova when intialize_connection is called." - that's prior to nova calling os-attach in the volume api21:16
mriedemscottda: so that's a chicken/egg21:16
ildikovmriedem: that was my thinking as well21:17
scottdamriedem: Not sure the details of jgriffith's POC. You are right. Might return it in attach()21:17
mriedemwe already get the attachment_id back from os-attach21:17
ildikovyeah, we get in before detaching21:17
patrickeasti think having the info was half the issue, knowing when to actually disconnect from the backend was the other part that is (in my mind) still unclear21:18
mriedemoh nvm21:18
mriedemos-attach is a 20221:18
mriedemnova waits for the volume to go to in-use21:18
mriedemand nova can get the attachments from the volume GET21:18
ildikovbut it's only for telling Cinder which attachment to detach in case of multiple, it does not say anything about the connector21:18
patrickeastlike scottda mentioned some backend would have a single iscsi session open for all the attachments21:18
patrickeasts/backend/backends/21:19
patrickeastwhich is a problem for multi-attach to >1 vm on the same compute node21:19
patrickeastwell, becomes a problem21:19
ildikovpatrickeast: yeah, exactly, tempest tests with lvm and logs show nicely in multiattach case that the session is killed in case of the first detach on a host21:19
scottdapatrickeast: Right. So there's a question of whether Nova or Cinder should contain the logic around when to actually detach() in Cinder and remove the export21:20
ildikovpatrickeast: and the target is also removed on Cinder side at the moment21:20
patrickeastyep yep21:20
scottdaI don't think we need to answer these questions now...21:20
scottdaI think we are better off figuring out what the questions are...21:20
scottdaand listing the possible solutions.21:21
patrickeastscottda: +121:21
ildikovscottda: yeah, we already got into a few small rabbit holes here21:21
*** _amrith_ is now known as amrith21:22
ildikovI think regarding multiattach the main issue is detach21:22
scottdaildikov: And if we figured out when to actually remove the target and finalize the detach in Cinder, would that solve all known issues?21:23
*** tyr__ has joined #openstack-meeting-cp21:23
scottdaThat, and only passing in host+instance_id with Mitaka+ versions of Cinder?21:23
*** tyr_ has quit IRC21:23
ildikovNova needs to know also when to call out to os-brick21:24
scottdaildikov: This is for the driver/backend specific issues? Around when to actually remove the target?21:24
scottdaOr something else?21:24
ildikovas far as I understood Nova closes the session on the compute node, while Cinder removes the target, but I might messed up with the logs regarding this21:25
mriedemdoes removing the target happen in the terminate_connection API in cinder?21:25
*** annegentle has joined #openstack-meeting-cp21:25
ildikovyes21:25
mriedemand nova passes the connector to that,21:25
ildikovbut we also call disconnect_volume in Nova21:25
patrickeastremoving the target does, but you need to log out on the compute node first21:25
mriedemwhich it's getting from os-brick21:25
patrickeastso at some point nova needs to know what to do21:25
ildikovmriedem: yeah, that's what I meant21:26
mriedemyes, the order is the nova virt driver disconnects the volume21:26
mriedemwhich actually happens in os-brick21:26
mriedemthen it calls the terminate-connection API in cinder21:26
patrickeastyep, exactly21:26
scottdaright21:26
mriedemand passes the volume connector21:26
mriedemif that connector dict was stored with the attachment in the cinder db, nova wouldn't have to pass that21:26
mriedemnova also get the connector from os-brick21:27
ildikovmriedem: I would assume in that case Nova could also check whether there are multiple volume attachments using the same?21:27
mriedemusing the same what?21:27
scottdahemna Had an idea for how to do that from the Nova side.21:27
scottdaHe is not here ATM21:28
ildikovyeah, but that required calling initialize_connection from detach21:28
scottdaildikov: Yes. But we could add a new API to Cinder to get that info21:28
andrearosa+121:29
ildikovscottda: can we store that info with the attachments?21:29
scottdaCan who? Nova?21:29
scottdaor Cinder21:29
ildikovscottda: if not I'm fine with the new API as well, I just would like to minimise the round trips as that's a constant concern21:29
*** annegentle has quit IRC21:30
ildikovCinder21:30
scottdaThere are a few ideas around what to store, where, by whom....21:30
patrickeastone argument in the past is that cinder may not always know about all of the places a volume was attached by some cinder user (in this case nova-compute + os-brick)21:30
scottdaand which entity determines when to remove the target/export21:30
patrickeastso storing the refcount of attachments to some host wasn't really ideal to keep there21:30
patrickeastlike the vm->attached volume mapping count, that is21:30
ildikovscottda: yeah, I know, would be nice to clarify that either here or on a follow up meeting/mail thread...21:30
scottdapatrickeast: Right. There is the arguement that Cinder should not care about any of this.  Just call Cinder when you want the target removed.21:31
patrickeastscottda: yea, i mean, there is sort of a fundamental argument about whether its right or wrong, but also concerns about whether it actually *can* consistently keep track21:31
ildikovpatrickeast: I remember a version of that idea, live migration can mess those things up for instance if it's allowed21:32
scottdaildikov: I'm working on a Cinder  Spec to allow update of connector_info and host in the Cinder DB. That would help with live migration issues.21:33
ildikovpatrickeast: I was wondering to store connector info21:33
ildikovscottda: yeah, sounds like a good start to me, although not a solution to the debates mentioned here21:34
scottdaildikov: Right. Just one piece in the puzzle. And one that doesn't have a lot of different ideas floating around to confuse things.21:34
ildikovscottda: I was suggesting this direction as well, so I'm convinced :)21:35
scottdaSo, under etherpad Issues Summary #2: New Cinder API for Updating Connector info and Nova host is needed for Nova live migration, evacuation, and shelve offload21:35
scottdaIs there any debate or issues with that?21:35
ildikovscottda: it's still a question though how closely coupled we want Nova and Cinder to be here21:36
scottdaWell, for live migration/shelve_offload/evacuate, we are changing the host....21:36
scottdaAnd Cinder stores that host info.21:36
scottdaIF we are using host+instance_id for detach in multi-attach, we'd need to update it.21:36
scottdaandrearosa: Wasn't there some other bug around volumes attached during migration?21:37
scottdaThat would be fixed if we could update that info in Cinder DB?21:37
ildikovwhen the host is changed we need to do updates for sure21:38
andrearosaIIRC there is an issue in not closing the connection with the target when we migrte, that is an issue with shelved_offload not sure if it iw an issue for LM21:38
scottdaOK, so that's Issue #221:38
scottdaandrearosa: Ahh..right. I filed a bug for that but it was relegated to "Wishlist"21:38
andrearosayeap21:38
scottdaI wanted to add a Cinder API to close the connection/remove the target21:39
scottdaso, I'm skipping issue #1 for a moment because it is hard..21:39
scottdaIssue #3 is Cinder cannot force-detach without Nova/caller help since it does not have Connector info21:39
scottdaWe can fix that by saving the connector_info21:39
patrickeasteasy :D21:40
scottdausing jgriffith's patch, or something similar21:40
scottdayup. So let's move back to #121:40
scottdaDetaching volumes with multi-attach when on the same host causes problems21:40
scottdaI'm suggesting we list the issues and alternatives, with Pros and Cons.21:40
cfouts+121:41
patrickeast+121:41
ildikovsounds cool21:41
scottdaWe can add that to the etherpad. And discuss a bit in IRC. Then have a meeting or wrestling match or something to get to some resolution.21:42
scottdaDid anyone have any other issues that needed addressing? IF so, please add to the etherpad "Issues Summary"21:42
scottdaAnything else we could discuss right now?21:43
mriedemndipanov had a patch in nova i can probably add21:43
ildikovit would be good to see a bigger picture as opposed to focus on one particular item21:43
mriedembut it's more of a nova issue i think21:43
ildikovmriedem: which one?21:43
mriedemhttps://review.openstack.org/#/c/290793/21:43
ildikovmriedem: tnx!21:44
scottdamriedem: OK. I think we are open to any changes in the Cinder API to make things better. So anything is fair game.21:44
mriedemi'm not sure this requires a cinder api change21:44
ildikovscottda: mriedem: do we have a picture on what to capture where?21:44
mriedemi think it's a nova problem, but was related to some cinder interaction on attach21:44
scottdaI actually have a WIP spec to refactor the basic attach and detach APIs. But that is probably a lower priority.21:45
ildikovI mean spec wise21:45
scottdaildikov: Well, one spec is cinder-connector-host-update21:45
mriedemyou probably can't write specs until you know what the current multiattach problems are and what the possible fixes are21:45
mriedemwhich i thought needed documenting somewhere (maybe the same etherpad?)21:45
scottdaildikov: I'm working on that one.21:45
scottdamriedem: Yes, I think that etherpad can work for the issues and alternatives for multiattach solution.21:46
mriedemi've honestly lost a lot of the context on the multiattach details since prior to the midcycle21:46
ildikovmriedem: I mainly meant whether we can all agree that it would be better to keep things separate a bit21:46
scottdaI think we all have. It's a complex area.21:46
ildikovlike don't shoehorn everything into the multiattach spec for instance21:47
mriedemildikov: i'd agree with that21:47
scottdayup, me too.21:47
ildikovas storing extra info is used for other cases as well, so it would be better to have full view as opposed to fix only multiattach aspects IMHO21:47
mriedemwe'll need some details laid out on the version constraints here too, i.e. nova newton talking to cinder liberty21:47
scottdaWE usually start with implementing changes on the Cinder side. Nova cannot implement things until Cinder has.21:47
ildikovmriedem: how many version do we plan to support backwards?21:48
ildikovas during Mitaka I think someone mentioned Icehouse or Juno also which is kind of way back in the past to adapt to IMHO21:48
mriedemildikov: well, it really comes down to the api21:48
mriedemnova needs a way to tell that the version of cinder it's talking to can support api x21:49
scottdaWE cannot crash older deployments of Cinder. We'll have to make sure that any incompatible changes are safely using microversions.21:49
mriedemand if not, we have to fail on anything that requires nova using cinder api x21:49
ildikovmriedem: like everything by the end of the day :)21:49
scottdaOK. we can get folks thinking about the best way to do that.21:50
mriedembut the client interaction doesn't really get flushed out until we know what the cinder api changes are, if any21:50
scottdaNova should be able to discover Cinder API version when the cinderclient is instantiated.21:50
ildikovyeap, right, let's elaborate things on the etherpad21:50
mriedemscottda: yup21:51
scottdaOK. We'll get hemna and jgriffith to chime in there.21:51
scottdaAlright. Anything else?21:51
cfoutsI'd like to mention that the Cinder community should discuss how often the Cinder API version is updated. I've seen it updated each time there is an API change and that seems to cause quite a bit of pain21:51
cfoutsmaybe only update the API version at milestones?21:52
ildikovscottda: do we have a follow up plan?21:52
ildikovscottda: have another sync before the summit and/or talk about this on the summit? and/or bring it back to the mailing list?21:53
scottdacfouts: What does Nova do? I think Manila changes for each API change. We need to allow any deployer to take HEAD of master at any time and use it.21:53
cfoutsNova seems to change far less often but I don't know what the logic is21:53
scottdaildikov: I think we'll end up syncing again before the summit. That's still 3+ weeks out.21:53
mriedemscottda: cfouts: http://docs.openstack.org/developer/nova/api_microversion_dev.html21:53
cfoutsmriedem: thanks21:53
mriedemthe microversion changes when it needs to based on the change21:53
mriedemyou can't line things up around milestones21:54
scottdamriedem: Yes. I stole all the Cinder code and docs from Nova. Or Manila, which got it from Nova.21:54
mriedemthe point of microversions is the client opts into them21:54
DuncanTcfouts: What do you mean by 'problems'?21:54
mriedemso if your client code is requesting x.latest, that's a bug in the client21:54
ildikovscottda: I think it would be good to have a quick one, but we will organise it then when we're getting closer21:54
DuncanTcfouts: 'pain', sorry21:54
scottdaildikov: OK. Once we're happy with our listing of alternatives, we can sync again.21:54
mriedemscottda: ildikov: yeah we need another sync up meeting before the summit21:55
mriedemmaybe in 2 weeks?21:55
scottdaSure.21:55
mriedemfwiw, i'm fine with weekly meetings if needed21:55
cfoutsDuncanT: competing patches with the same microversion, client needing to be updated by developer to work with latest server version, QA wondering why things don't work because of microversion change21:55
mriedemmost of the work right now is on the cinder team i think to lay out the plan21:55
mriedemcfouts: QA shouldn't be testing with the latest21:55
scottdamriedem: I agree. But there are the issues around alternatives to multi-attach support. and NOva will have opinions on that.21:56
mriedemclients need to update to support microversions in order21:56
mriedemscottda: yeah, agree21:56
mriedemscottda: you guys set up the options, and we'll knock them down21:56
ildikovscottda: mriedem: agreed, I will call for another meeting before the summit21:56
cfoutsmriedem: our QA tests internally before we push upstream21:56
cfoutsmaybe that isn't a wide spread practice21:57
DuncanTcfouts: Competing patches, sure, it's annoying. We can at least avoid merging clashes with unit tests. Clien tonly needs updating if it wants to use the new feature, that's the point, and that change is needed whether you microversion it or not21:57
mriedemcfouts: i guess i don't have context21:57
scottdaWe only test in production.21:57
scottda:)21:57
mriedemfor example, tempest is testing nova v2.121:57
mriedembut nova has like v2.2521:57
ildikovmriedem: oh, missed the weekly meetings idea, TBH I could live with that as well, I think we can easily end up with a bigger amount of tasks here21:57
mriedemildikov: at least to checkpoint on progress i think that would be fine21:57
scottdaOK, I have to run. Thanks everyone. Weekly sounds good for now. It will put some pressure on us.21:57
mriedemildikov: if there is no news, it's a short meeting21:57
*** rockyg has quit IRC21:58
DuncanTcfouts: All sorts of things can change with a patch between upstream submisison and merging, that is just the nature of the beast21:58
ildikovmriedem: exactly, and having a weekly sync can ensure progress as well21:58
ildikovscottda: thanks!21:58
cfoutsDuncanT: maybe it is more of our process then. I can live with that :)21:58
scottdaildikov: Don't forget to endmeeting when we are all done.21:58
ildikovscottda: I will contact you about the follow-up/maybe weekly meetings21:59
scottdagreat21:59
ildikovscottda: no worries, it's not my first one I had in mind :)21:59
*** vilobhmm11 has quit IRC21:59
ildikovok, we have a half minute left22:00
takashinI would like to talk about the nova swap volume function issue.22:00
ildikovis there any other aspects we would want to discuss here today?22:00
takashin#link https://bugs.launchpad.net/cinder/+bug/152270522:00
openstackLaunchpad bug 1522705 in Cinder "Cinder volumes are stuck when non admin user executes nova swap volume API" [Undecided,In progress] - Assigned to Takashi NATSUME (natsume-takashi)22:00
DuncanTcfouts: We've had similar issues before microversions... I wonder if you could do something by bumping to a massive microversion in the (local only) patch, so your test can request something that will never be supported by upstream code or something? I'll have a think about it22:00
ildikovtakashin: is this the one you wrote the mail about earlier?22:01
andrearosathank you all, I have to go. Bye22:01
takashinI wrote in the etherpad.22:01
ildikovandrearosa: thanks for joining22:01
takashinThe bug is caused  because cinder 'migrate_volume_completion' API can be executed by admin only in default settings of cinder policy.json.22:01
*** andrearosa has left #openstack-meeting-cp22:02
ildikovtakashin: yeah, I can see now22:02
DuncanTtakashin: That's because it was only designed to be used by nova internals22:02
*** vilobhmm11 has joined #openstack-meeting-cp22:03
*** vilobhmm11 has quit IRC22:03
takashinIMO, it is the problem whether attach/detach volumes is performed in nova side or cinder side.22:03
*** vilobhmm11 has joined #openstack-meeting-cp22:03
mriedemtakashin: so this is only a problem if it's a user-initiated volume migration on the cinder side right?22:04
takashinyes22:05
mriedemi don't know the details, but cinder calls the nova swap-volume API?22:05
mriedemas a non-adin22:05
mriedem*admin22:05
mriedemand nova then calls back to cinder as that non-admin and it fails22:05
takashinin cinder, volume migration is admin-only22:05
takashinBut nova allows non-admin-user22:05
mriedemfor swap22:06
mriedembecause for nova it's just a detach of one volume and attach of another22:07
takashinNow detach/attach volume is performed in cider side.22:07
DuncanTSo my first question would be what is the usecase for a none-admin to call this?22:07
takashinOriginally nova allows it to non-adminuser22:08
mriedemif cinder is initiating the swap volume call to nova, why doesn't it do it with the same admin context?22:08
mriedemoh nvm22:08
takashinNo22:09
mriedemso admin volume migration from cinder is not a problem, right?22:09
mriedembut non-user swap volume from nova is a problem22:09
DuncanTIt was expected to be admin only, because it's dangerous in general to go swapping volumes without generating detach/attach events on the VM - it's an easy way to corrupt your volumes with old cached data22:09
mriedembecause http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n494322:09
mriedemso it seems like nova should check if the context is admin before calling http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n494322:10
mriedemthis also bleeds into a cross-project discussion about api capability discoverability22:10
takashinDoes it means admin-context in non-admin user operation?22:11
mriedemso the user can find out what apis they can actually perform22:11
DuncanTmriedem: In this case, the answer is 'admin only', and always has been22:11
mriedemDuncanT: the policy file is configurable though22:11
mriedemunless there is something hardcoded in cinder for this22:12
DuncanTmriedem: Not sure without checking the code... we fixed a bunch of those but there might be more22:12
*** vilobhmm11 has quit IRC22:12
takashinChange policy in nova?22:12
mriedemtakashin: to what? make it admin-only?22:12
*** vilobhmm11 has joined #openstack-meeting-cp22:12
takashinYes22:13
mriedemidk, i guess that's an option22:13
*** vilobhmm111 has joined #openstack-meeting-cp22:13
takashinO.K.22:13
mriedemi honestly don't know what all of the use cases are around swap volume or when it was originally introduced22:13
mriedemi'd need some input from others on the nova team about that, like ndipanov22:13
*** vilobhmm111 has quit IRC22:13
*** vilobhmm111 has joined #openstack-meeting-cp22:14
mriedemseems it should have been implemented like the nova/neutron callback api that we have for vif plugging22:14
mriedemwhich is admin only22:14
*** vilobhmm111 has quit IRC22:14
mriedem"compute_extension:instance_actions:events": "rule:admin_api",22:14
ildikovwe can follow up on this as well and add info to the etherpad in the meantime22:14
*** vilobhmm111 has joined #openstack-meeting-cp22:14
mriedemyeah22:14
mriedemi have to head out22:14
mriedemthere is a ML thread about this?22:15
ildikovmriedem: second one at the bottom of the etherpad IIRC22:15
takashinYes22:16
mriedemFix nova swap volume (updating an attached volume) function22:16
takashin#link http://lists.openstack.org/pipermail/openstack-dev/2016-February/087549.html22:16
mriedemyeah22:16
*** vilobhmm111 has quit IRC22:16
ildikovyeah, that's the one22:16
mriedemi see it got 0 replies :)22:16
*** claudiub|2 has quit IRC22:16
mriedemok, i'll try to read through that at some point and reply, or get others from nova involved22:16
takashinThank you.22:16
*** annegentle has joined #openstack-meeting-cp22:17
*** vilobhmm11 has quit IRC22:17
ildikovgreat, I suggest to close the meeting now22:18
mriedemyes please :)22:18
takashinO.K.22:18
ildikovI will call for a follow up meeting or make it even a series22:18
ildikovI would encourage everyone to keep an eye and add info to the etherpad in the meantime!22:18
ildikovthanks everyone for joining, I think it was a good start22:19
ildikovso if nothing else, then good afternoon/evening/night/morning everyone :)22:19
*** tbarron has left #openstack-meeting-cp22:20
mriedemildikov: yup, thanks for starting this22:20
*** mriedem has left #openstack-meeting-cp22:20
ildikov#endmeeting22:20
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"22:20
openstackMeeting ended Wed Mar 30 22:20:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:20
openstackMinutes:        http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-03-30-21.00.html22:20
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-03-30-21.00.txt22:20
openstackLog:            http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-03-30-21.00.log.html22:20
*** takashin has left #openstack-meeting-cp22:20
*** markvoelker has joined #openstack-meeting-cp22:24
*** sigmavirus24 is now known as sigmavirus24_awa22:27
*** karthikp has quit IRC22:32
*** amrith is now known as _amrith_22:33
*** sdake has quit IRC22:46
*** sdake has joined #openstack-meeting-cp22:46
*** vilobhmm11 has joined #openstack-meeting-cp22:47
*** markvoelker has quit IRC22:57
*** karthikp has joined #openstack-meeting-cp22:58
*** annegentle has quit IRC23:03
*** tpatil has quit IRC23:05
*** annegentle has joined #openstack-meeting-cp23:24
*** annegentle has quit IRC23:28
*** _amrith_ is now known as amrith23:29
*** annegentle has joined #openstack-meeting-cp23:34
*** annegentle has quit IRC23:38
*** angdraug has quit IRC23:43
*** karthikp has quit IRC23:48
*** annegentle has joined #openstack-meeting-cp23:51
*** amrith is now known as _amrith_23:54

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!