16:00:09 <thingee> #startmeeting cinder
16:00:09 <openstack> Meeting started Wed Jun  3 16:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'cinder'
16:00:13 <ameade> \0/
16:00:20 <tbarron> hi again
16:00:23 <Swanson> Hello to the meeting minutes.
16:00:28 <vincent_hou> hi
16:00:33 <jungleboyj> Hello again.
16:00:34 <hemna> hey
16:00:34 <geguileor> Hi
16:00:36 <eharney> hi
16:00:38 <thingee> announcements...
16:00:38 <dulek> hi
16:00:40 <rajinir_r> hi
16:00:43 <adurbin__> hi
16:00:43 <rhe00_> hi
16:00:45 <xyang1> Hi
16:00:45 <patrickeast> hi
16:00:46 <scottda> hi
16:00:50 <avishay> hello
16:00:52 <thangp> hi
16:00:53 <dannywilson> hi
16:00:54 <thingee> #topic announcements
16:01:05 <thingee> Liberty-1 is approaching
16:01:26 <thingee> I will start cutting blueprints on June 10 that do not have a patch up that is passing jenkins
16:01:29 <thingee> #link https://launchpad.net/cinder/+milestone/liberty-1
16:01:45 <thingee> Better luck in L-2
16:01:53 <asselin__> hi
16:02:12 <thingee> #info Blueprints in L-1 will be cut if they do not have a passing patch posted by June 10th
16:02:13 <dulek> By cutting you mean - moving to L-2?
16:02:29 <ameade> not drivers right?
16:02:32 <thingee> dulek: out of l-1. You can try for l-2
16:02:43 <ameade> thats still 12th?
16:03:03 <thingee> #todo thingee to send to ML about blueprint cut
16:03:38 <asselin__> #action thingee to send to ML about blueprint cut
16:03:48 <thingee> asselin__: thanks
16:03:50 <thingee> heh
16:04:05 <thingee> also drivers, please read the ML post about deadlines for drivers.
16:04:05 <deepakcs> Hi
16:04:32 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/064072.html
16:04:36 <thingee> June 15th
16:04:52 <thingee> I'm not going to repeat what's already in there, but that's a separate deadline from regular blueprints
16:05:04 <opencompute> http://www.openstack.org/blog/2015/05/deadline-for-new-cinder-volume-drivers-in-liberty/
16:05:11 <smcginnis> \o/
16:05:13 <ameade> kk ty
16:05:26 <thingee> I will start an etherpad to track drivers
16:05:29 <thingee> in review
16:05:52 <thingee> specs I will be approving by the end of this week....
16:05:56 <thingee> image caching https://review.openstack.org/182520
16:06:06 <thingee> and replication v2 https://review.openstack.org/#/c/155644/
16:06:12 <thingee> speak up now
16:06:30 <thingee> and lastly don't forget about casual review friday, thanks to DuncanT
16:06:31 <vincent_hou> I have one
16:06:33 <vincent_hou> https://review.openstack.org/#/c/186327/
16:06:41 <thingee> alright agenda for today
16:07:05 <thingee> #link https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting
16:07:12 <jungleboyj> vincent_hou: We are getting there.
16:07:23 <vincent_hou> Thx
16:07:30 <thingee> #topic 3rd Party CI - FC Passthrough - upstream now available
16:07:32 <thingee> asselin__: hi
16:07:38 <asselin__> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/065677.html
16:07:44 <asselin__> just posted to the mailing list...
16:07:57 <asselin__> just to let everyone know patrickeast and I have fc passthrough scripts avaialble
16:08:10 <smcginnis> asselin__: +1
16:08:11 <asselin__> https://git.openstack.org/cgit/stackforge/third-party-ci-tools/tree/provisioning_scripts/fibre_channel
16:08:34 <thingee> asselin__: is this communicated on the infra third party page or Cinder third party page?
16:08:38 <asselin__> nikeshm is probably the first 'new' person to use them on his driver
16:08:49 <asselin__> thingee, cinder FAQ
16:08:55 <thingee> asselin__: perfect :)
16:09:01 <asselin__> #link https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#FAQ
16:09:22 <asselin__> so just remember to go to the FAQ :)
16:09:33 <asselin__> that's it from me...just wanted to make it known
16:09:42 <thingee> it's new and frequently asked already ;)
16:10:06 <thingee> thanks asselin__
16:10:08 <asselin__> big thanks to patrickeast for refactoring it to be consumable
16:10:13 <thingee> and patrickeast !
16:10:23 <hemna> nice job guys
16:10:23 <jungleboyj> asselin__ and patrickeast Thanks guys!
16:10:44 <thingee> #topiic Volume status during migration
16:10:47 <thingee> vincent_hou: jungleboyj hi
16:10:54 <vincent_hou> Hi
16:10:56 <jungleboyj> thingee: Howdy.
16:11:04 <thingee> #link https://review.openstack.org/#/c/186327/
16:11:50 <jungleboyj> So, I think vincent_hou is making great progress proposing improvements to volume migration but avishay has raised a concern.
16:11:51 <vincent_hou> I am proposing that we change the status of a volume to 'migrating' when it is migrating for the migration improvement.
16:12:09 <jungleboyj> ^^ want to get feedback from others on that.
16:12:17 <thingee> why are comments in ps6 being ignored
16:12:20 <thingee> that's kind of annoying
16:12:31 <vincent_hou> I like to avoid things like attempting to attach the volume while migrating.
16:12:33 <thingee> two people have asked for there comments to be addressed.
16:12:38 <thingee> their*
16:12:50 <DuncanT> So as a deployer, it would be really nice to be able to migrate transparently to the tenant
16:12:52 <vincent_hou> Avishay proposes not changing the volume status during migration and aborting a migration if a user attempts to attach/detach the volume.
16:13:13 <DuncanT> i.e. Avishay's approach
16:13:16 <avishay> so migration is an admin operation and has to be because users don't know about backends
16:13:43 <avishay> if you expose the fact that a volume is being migrated, suddenly users become aware of backends and the abstraction breaks
16:13:43 <jungleboyj> avishay: We have a 'retyping' status.  How is this different?
16:13:53 <DuncanT> Though it would also be nice to be able to stop a user getting in the way of a migration if I really need to move the volume like now
16:13:54 <avishay> jungleboyj: the user initiates retype
16:14:09 <hemna> avishay, +1
16:14:11 <avishay> DuncanT: +1
16:14:16 <DuncanT> So setting the status to 'migrating' only during a --force would be ideal
16:14:26 <avishay> DuncanT: agreed
16:14:29 <DuncanT> For normal migrates, just abort
16:14:45 <avishay> DuncanT: or even better than migrating, "maintenance"
16:14:48 <jungleboyj> Ahh... Ok. I am just concerned that allowing the user to cause an action initiated by the admin is dangerous.
16:15:08 <thingee> DuncanT: +1 this is nothing new of what we already said at the summit of just being ok with aborting
16:15:09 <avishay> DuncanT: the user doesn't need to know why, just that it's temporarily unavailable for attach/detach
16:15:11 <geguileor> If we don't use ING state then we would have to change the ING approach to locking
16:15:19 <jungleboyj> We are trying to make migration more robust and having something to abort seems to just be more fragile.  Simple is better.
16:15:23 <DuncanT> avishay: ++
16:15:42 <thingee> avishay: that seems simple to me
16:15:44 <jungleboyj> avishay: I do like the idea of having a general 'unavailable' status.
16:15:58 <jungleboyj> That could be useful else where.
16:16:02 <hemna> geguileor, we should always be doing ING status checks in the API anyway
16:16:05 <DuncanT> jungleboyj: Depends what you're trying to achieve... we often want to reballance or drain a server without users knowing
16:16:12 <hemna> but we currently can't because of Nova now.
16:16:18 <thingee> hemna: the problem is we don't have an ING for migrate
16:16:25 <geguileor> hemna: maintenance is not ING state  ;-)
16:16:26 <thingee> hemna: that's the point of this proposal
16:16:37 <hemna> well, we kinda do...migration_status no ?
16:16:44 <jungleboyj> geguileor: Maintaining.  ;-)
16:17:08 <hemna> put the volume in 'something'  status :)
16:17:09 <geguileor> jungleboyj: Ok, just wanted to point that out before we agreed on the term :)
16:17:09 <hemna> that's ING
16:17:31 <vilobhmm> hemna : is this with regards to the idea that we were talking about the other day
16:17:37 <jungleboyj> What about 'unavailable' ?
16:17:53 <jungleboyj> Though that brings up more questions, potentially then 'maintenance'
16:17:57 <vilobhmm> hemna : just joined so wanted to know the context
16:18:02 <avishay> the name of the state doesn't really matter
16:18:05 <DuncanT> The point is, as an admin, I /really/ want to be able to do things like reballance without affecting the tenant
16:18:19 <hemna> jungleboyj, well as long as the 'ing' state check also checks for unavailable
16:18:22 <dulek> avishay: +1
16:18:24 <avishay> DuncanT: +1, not only without affecting, without him knowing
16:18:26 <DuncanT> maintainance mode means SLA affected
16:18:27 <hemna> to prevent actions as well
16:18:32 <hemna> I'm ok with that
16:18:36 <geguileor> DuncanT: +1
16:18:43 <mtanino> DuncanT: +1
16:18:45 <DuncanT> avishay: +1
16:18:47 <vilobhmm> avishay, DuncanT : +1
16:19:01 <DuncanT> It really is a necessary function for a large cloud
16:19:04 <thingee> I'm seeing a lot of agreement
16:19:07 <smcginnis> hemna: unavailabling
16:19:08 <hemna> yup
16:19:12 <hemna> :P
16:19:17 <avishay> thingee: scary right?
16:19:17 <jungleboyj> smcginnis: :-)
16:19:33 <jungleboyj> Which agreement are coming to?
16:19:36 <geguileor> smcginnis: XD
16:19:39 <vincent_hou> so something like "unavailable" for the volume status?
16:19:48 <vincent_hou> during migration?
16:20:02 <thingee> as jungleboyj raised, this can be used for others thing
16:20:19 <avishay> vincent_hou: noooo
16:20:27 <DuncanT> vincent_hou: No
16:20:28 <jungleboyj> thingee: Ok, I am glad that people like that idea but I don't feel like we are greeing on that for migration.
16:20:38 <jungleboyj> Yeah, that was what I as afraid of.
16:20:38 <geguileor> Unavailable is frightening to users
16:20:56 <DuncanT> vincent_hou: Need to be able to do it without user knowing
16:20:57 <avishay> vincent_hou: no state change normally, and abort if attach/detach. if the admin passes a special flag, then the volume goes to 'unavailable' or whatever state and then no attcah/detach is allowed.
16:20:59 <rajinir_r> +1 for 'Maintaining'
16:21:06 <vincent_hou> OK.
16:21:29 <DuncanT> vincent_hou: *maybe* a 'migrating' state for migrate --force, but that is less important than the silent migration
16:21:36 <geguileor> avishay: +1
16:21:53 <vincent_hou> DuncanT: It sounds OK to me.
16:21:54 <geguileor> DuncanT: +1
16:21:55 <jungleboyj> avishay DuncanT So, we are going to allow a user to override what an admin has requested?
16:22:15 <DuncanT> jungleboyj: If the admin doesn't say --force, yes, absolutely
16:22:17 <geguileor> jungleboyj: If admin doesn't force it yes
16:22:20 <rajinir_r> +2 for 'Migrating'
16:22:28 <vincent_hou> I have the same concern as Jay has.
16:22:33 <jungleboyj> Ok, that makes me queasy
16:22:53 <DuncanT> jungleboyj: It's nice to be able to kick off migrations without affecting SLAs or otherwise impacting the customer
16:23:00 <avishay> think of it from the POV of the operator, not the developer :)
16:23:13 <jungleboyj> So, in the case a user requests and attachment we would stop the migration and delete the new volume that was being created.  Throw some huge warning into the logs as to why the migration stopped/
16:23:32 <jungleboyj> avishay: :-)
16:23:33 <avishay> jungleboyj: even info, not warning
16:23:42 <DuncanT> jungleboyj: info
16:23:46 <avishay> it's not a big deal, normal flow
16:23:58 <thingee> sounds like an awful experience for ops if it's an emergency
16:24:09 <DuncanT> thingee: --force then
16:24:10 <avishay> thingee: that's why you have the --force flag
16:24:10 <geguileor> thingee: Then you would use --force
16:24:12 <vincent_hou> One more issue is that when we do "retype", we already put "retyping" in the volume status. Shall we change that approach as well?
16:24:15 <jungleboyj> avishay: DuncanT Ok, that seems odd to me, but you guys have more experience.
16:24:30 <avishay> vincent_hou: no, retype is a user-initiated action
16:24:30 <thingee> piranhas in this room
16:24:34 <jungleboyj> vincent_hou: No, sounds like that is different as it can be initiated by user.
16:24:38 <avishay> thingee: :P
16:24:45 <DuncanT> jungleboyj: It really is a common thing to want to move volumes off a 'hot' backend without affecting the user
16:24:46 <geguileor> thingee: XD
16:24:55 <hemna> I think unavailable makes sense
16:25:02 <vincent_hou> OK.
16:25:13 <thingee> unavailable .... in a cloud?
16:25:14 <jungleboyj> DuncanT: Ok.
16:25:19 <hemna> yup
16:25:19 <thingee> not sure what I think about that
16:25:35 <DuncanT> 'maintainence' might be better
16:25:41 <thingee> yea
16:25:43 <DuncanT> (give or take some spelling)
16:25:47 <vincent_hou> OK.
16:25:52 <thingee> ok, vincent_hou sounds like you got some feedback to go with
16:25:54 <thingee> anything else?
16:26:02 <vincent_hou> Thank you so much folks
16:26:19 <thingee> #topic Status update on c-vol A/A efforts
16:26:19 <vincent_hou> I will resolve the comments for this spec ASAP>
16:26:23 <jungleboyj> Thanks guys!
16:26:24 <thingee> dulek: geguileor hi
16:26:29 <vincent_hou> THank you folks.
16:26:31 <dulek> hi!
16:26:32 <geguileor> hi
16:26:32 <dulek> (I'm on a mobile approaching some forest area, so may be disconnected any time)
16:26:37 <thingee> #link https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
16:26:41 <thingee> ha
16:26:54 * geguileor is the backup
16:26:56 <dulek> So we just wanted to gather updates from folks engaged in c-vol A/A efforts
16:27:32 <vilobhmm> so i am working with a syzmon regarding https://review.openstack.org/#/c/183537/
16:27:38 <dulek> Let me start - me and an engineer from my team are developing Tooz locks implementation for Cinder.
16:28:15 <dulek> Right now we're in the process of testing it and looking for corner cases.
16:28:32 <vilobhmm> review is in progress for this effort
16:29:17 <geguileor> So will it only change current locks or include new needed locks?
16:30:17 <geguileor> (new needed as in we see they are missing)
16:30:21 <vilobhmm> its a proposal not a way to go for
16:30:24 <vilobhmm> also do we need to open a bug and start working on fixing the nova-cinder interaction because i have been seeing it a lot lately that volume getting stuckin in "ing" state
16:30:27 <DuncanT> I/we are looking at fixing up Nova to start catching some failures rather than trying to figure everything out in advance. Requires some substantial moving things round in Nova though
16:30:47 <vilobhmm> DuncanT : do we have a bug for it
16:30:55 <hemna> DuncanT, https://bugs.launchpad.net/nova/+bug/1458958
16:30:55 <openstack> Launchpad bug 1458958 in OpenStack Compute (nova) "Exceptions from Cinder detach volume API not handled" [Undecided,New]
16:31:08 <hemna> DuncanT, that's a start and needs to get handled
16:31:10 <thingee> #link https://bugs.launchpad.net/nova/+bug/1458958
16:31:22 <DuncanT> hemna: I started on attach actually, but yeah
16:31:29 <hemna> aaaaand no one has signed up to fixy that one yet :(
16:31:37 <vilobhmm> i did assign myself now
16:31:43 <vilobhmm> will work on it
16:32:06 <hemna> but just in general, Cinder can't do 'ING' state checks now and return VolumeIsBusy exceptions now because of a bunch of those types of failures on the Nova side.
16:32:14 <DuncanT> hemna: It is true of every nova call to cinder TBH
16:32:21 <vilobhmm> hemna : agree
16:32:28 <hemna> personally, I think we need to shore up the cinder API side and do 'ING' checks
16:32:31 <vilobhmm> DuncanT : +1
16:33:13 <vilobhmm> we need additional validation at the cinder API layer before procedding ahead and coming to know abt it at the manager layer …what does everyone think abt it
16:33:24 <thingee> dulek, geguileor: so can we talk about what we would like to have for l-1?
16:33:40 <DuncanT> hemna: Just patch the client in nova to raise an exception at random one time in 4, then make nova handle it... can do the cinder API work afterwards
16:33:46 <geguileor> thingee: Progably a good idea :)
16:33:48 <thingee> there's a lot rainbow and unicorn talk happening atm.
16:33:58 <hemna> :)
16:34:19 <DuncanT> We can't change the cinder API until nova can handle the response, or things break even more than they do now
16:34:27 <hemna> DuncanT, +1
16:34:33 <vilobhmm> ok
16:35:06 <thingee> DuncanT: ok lets start there.
16:35:11 <hemna> I had leeantho file that defect as an example of what happens when the Nova side doesn't compensate for VolumeIsBusy being sent back from Cinder.
16:35:12 <thingee> who is looking into that?
16:35:24 <thingee> who cares to help look at the nova side for catching failures?
16:35:45 <hemna> I'd do it if I wasn't slammed at the moment
16:35:46 <thingee> once we know who wants to take on that, we can track the patch posted and help review.
16:36:20 <DuncanT> We are just doing sprint planning, but hopefully us
16:36:23 <hemna> *sigh*
16:36:26 <thingee> ok no one so far
16:36:30 <thingee> ...
16:36:36 <hemna> everyone wants to work on the new shiny Cinder stuff and not fix these major issues :(
16:36:39 <vilobhmm> I can also help hemna, DuncanT
16:36:48 <winston-d> thingee: i can take a look
16:36:50 <dulek> Sorry, got disconnected...
16:36:57 <thingee> hey look at that, winston-d to the rescue
16:37:07 <hemna> winston-d, thank you.
16:37:12 <hemna> I can help if possible.
16:37:30 <winston-d> hemna: cool
16:37:37 <thingee> I would say at most point winston-d to the particular known failure areas. which is apparently every cinder call from nova
16:37:47 <thingee> hemna, DuncanT ^
16:38:04 <hemna> we should ping jaypipes or jogo and get them up to speed with what we are trying to fix here from the Nova side.
16:38:15 <geguileor> winston-d: I'll be working on the tests to confirm all things that break
16:38:16 <thingee> winston-d: if you come up with a patch next week or whenever, let us know so I can bring it up in the meeting and we can help review.
16:38:31 <hemna> getting some nova core's to buy off on this will help us push it through the nova side as well
16:38:32 <DuncanT> Attach is the messiest piece to fix by the looks of it
16:38:33 <winston-d> thingee: sure
16:38:36 <dulek> Do we need any Cinder blueprints for that?
16:38:40 <hemna> DuncanT, yup, for sure
16:38:42 <DuncanT> Since it does some crazy inspection
16:38:45 <dulek> And Nova's BP deadline is closing fast.
16:38:59 <DuncanT> We'll need a nova BP for sure
16:39:02 <jaypipes> hemna: I'm kinda swamped :( Perhaps ndipanov would be a good alternative?
16:39:29 <DuncanT> Andrea in the nova team @HP is available I believe
16:39:36 <hemna> jaypipes, thanks man.  any help with just supporting with timely reviews would be great at this point.
16:39:37 <ndipanov> big shoes to fill
16:39:41 <thingee> jaypipes: we're talking about some try/catches in nova for cinder calls. pretty small stuff.
16:39:50 <thingee> ndipanov: ^
16:39:59 * ndipanov scrolls back
16:40:01 <thingee> if anyone cares about gate failures, seems like a good priority
16:40:08 <winston-d> fwiw, https://review.openstack.org/#/c/167815/ has been sitting there for 2 months
16:40:21 <hemna> ndipanov, for reference  https://bugs.launchpad.net/nova/+bug/1458958
16:40:21 <openstack> Launchpad bug 1458958 in OpenStack Compute (nova) "Exceptions from Cinder detach volume API not handled" [Undecided,New] - Assigned to Vilobh Meshram (vilobhmm)
16:40:53 <xyang> we also have this one: https://review.openstack.org/#/c/138664/,  not sure how to proceed
16:40:54 <dulek> So who will start with writing a BP for Nova?
16:41:17 <jaypipes> vilobhmm: FYI, best not to assign yourself to a bug before pushing a patch for it. when you push a patch, it will auto-assign you to the bug if you reference the bug in your commit message.
16:41:22 <hemna> do we need a Nova BP to fix a bug ?
16:41:29 <thingee> how descriptive does this bp need to be? We're catching potential exceptions.
16:41:33 <dulek> I can volunteer if DuncanT will help me to understand relations there.
16:41:34 <vilobhmm> jaypipes : sure
16:41:40 <jaypipes> hemna: no, not unless the Nova API changes.
16:41:48 <DuncanT> I'll start for attach, and get Andrea to input.
16:41:53 <vilobhmm> thingee : I can help with the blueprint and the spec
16:41:56 <ndipanov> hemna, thingee ok so what's the question
16:42:14 <thingee> ndipanov: review the patch when it's posted. We're doing better try/catch of cinder calls from nova.
16:42:18 <thingee> getting a sponsor
16:42:32 <hemna> ndipanov, so we are just going to do some exception catching in the calls to Cinder.  and need reviews when patches go up, so we can fix this.
16:42:33 <ndipanov> thingee, sounds like a good idea - pls ping me
16:42:40 <hemna> ndipanov, thank you!!!
16:42:51 <thingee> ndipanov: thank you, I appreciate your time on helping with failures here.
16:43:05 <dulek> Cool, this seem like we can fix that without a BP and spec?
16:43:06 <jaypipes> I'll do my best to get to reviews.
16:43:10 <thingee> ndipanov: I'll get cinder folks here to help verify things as well
16:43:16 <thingee> jaypipes: thank you
16:43:25 <ndipanov> it is somewhere on my todo list to move all of the detach stuff into nova/virt/block_device.py
16:43:32 <ndipanov> but sadly hadn;t done that  yet
16:43:36 <thingee> vilobhmm: honestly I don't think this is a complicated bp, but DuncanT please help?
16:43:47 <ndipanov> in that case we would have a single place where to catch those...
16:44:19 <thingee> ndipanov: yeah should be that one wrapper file nova has for cinder
16:44:24 <thingee> nova.volumes.cinder or something
16:44:34 <thingee> winston-d: ^
16:44:45 <thingee> whew
16:44:46 <DuncanT> thingee: It isn't just try/catch, since nova tries to figure out stuff for itself that needs to be re-arranged so it can be skipped once cinder returns more
16:44:50 <hemna> ndipanov, +1
16:44:58 <xyang> ndipanov: what about failure during attach?
16:45:13 <hemna> the trick is to get Nova to bail gracefully when a volume is busy
16:45:16 <thingee> DuncanT: lets start with the try/catch issues for l-1
16:45:22 <thingee> fast approaching
16:45:23 <hemna> I think that's probably the part where we'll need help
16:45:30 <geguileor> thingee: +1
16:45:30 <winston-d> thingee: agree
16:45:36 <dulek> thingee: But Nova has BP deadline for L-1.
16:45:37 <ndipanov> xyang, attach is done using the classes so it's wrapped inside a block_device.attach()
16:45:49 <dulek> thingee: I mean L-1 is BP deadline.
16:45:50 <thingee> dulek: I understand and I got people to handle that ;)
16:45:59 <thingee> dulek: vilobhmm and DuncanT will work together on the bp
16:46:07 <thingee> how complicated is a bp on try/catch? honestly
16:46:09 <dulek> thingee: Agreed! :)
16:46:16 <thingee> ok thanks everyone
16:46:17 <vilobhmm> thingee: cool..will do that
16:46:28 <ndipanov> detach is sadly inlined in the compute manager callbacks
16:46:32 <thingee> #action DuncanT vilobhmm to work on bp for try/catch issue catching on calls to cinder from nova
16:46:38 <ndipanov> but this doesn't affect you guys
16:46:39 <winston-d> dulek: these are fundmentally bugs, bp isn't really necessary
16:46:49 <thingee> #action winston-d to work on patch(es) to do try/catch handling on calls to cinder from nova
16:46:59 <thingee> #agreed this is a good starting point for l-1 being around the corner
16:47:17 <thingee> #topic Third party CI requirements for re-branded drivers
16:47:19 <thingee> DuncanT: hi
16:47:23 <thingee> DuncanT: and thanks for bringing this up
16:47:33 <DuncanT> You can't just catch the eception, since you're too caught up in nova to be able to /do/ anything... so you're pretty much where you are today (broken) but with a log message
16:47:38 <thingee> #link https://review.openstack.org/#/c/187853/
16:47:45 <thingee> #link https://review.openstack.org/#/c/187707/
16:48:16 <thingee> so these are rebranded drivers... basically inheriting off other driver classes.
16:48:38 <thingee> #idea should rebranded drivers also have CI's or do they just piggy-back off the real driver CI's?
16:49:21 <thingee> asselin__ anteaya ^
16:49:23 <opencompute> I think they should
16:49:30 * asselin__ is thinking
16:49:32 <patrickeast> where do we draw the line then?
16:49:46 <asselin__> honestly...not sure why we need those drivers...
16:49:50 <thingee> patrickeast: that's what I was thinking. What if they make some modifications.
16:49:54 <smcginnis> These are trivial inheritence, so I see little value. But I could see the same situation where more functionality is introduced that would need it.
16:50:02 <thingee> they could override a method or two
16:50:06 <smcginnis> asselin__: That is a very good point.
16:50:16 <DuncanT> asselin__: branding
16:50:20 <thingee> asselin__: good point
16:50:32 <asselin__> yes...buy why do we need branding inside cinder?
16:50:35 <DuncanT> asselin__: The internals are the same, but the marketing, pricing, etc is very different
16:50:40 <thingee> not exactly the problem cinder is trying to solve IMO.
16:50:54 <smcginnis> I can see branding as a strong marketing requirement. But completely new drivers seems excessive.
16:50:56 <DuncanT> asselin__: they are effectively different products in the consumer's eyes
16:50:57 <asselin__> brand the hardware. use the common driver
16:51:03 <smcginnis> Especially since config options don't get "rebranded".
16:51:06 <smcginnis> BUt I see the need.
16:51:12 <winston-d> asselin__: so their customers won't notice what they have is actually sth else if not looking close enough?
16:51:18 <smcginnis> Though I don't really like it.
16:51:23 <opencompute> In this case, I see config options are rebranded
16:51:27 <DuncanT> All these two patches do is rename some config options TBH
16:51:35 <smcginnis> opencompute: Oh, right.
16:51:47 <thingee> IMO it's not solving anything. Sure, you use a different dot path with your products name, but that doesn't solve the problem over the product you're rebranding being in the config option name /description
16:51:51 <thingee> and log messages
16:52:02 <smcginnis> At least they are complete duplication of the same driver code.
16:52:17 <tbarron> smcginnis: for now
16:52:22 <smcginnis> I do appreciate that they tried to minimize the impact.
16:52:26 <smcginnis> tbarron: Right.
16:52:28 <Swanson> They need a CI.  If you bring a driver you bring a CI.
16:52:36 <dulek> So isn't valid point for us - if you want branding, then introduce brand new driver, without inheritance?
16:52:40 <dulek> And the CI?
16:52:41 <Swanson> If that is too much pain then don't bring the driver.
16:52:53 <smcginnis> Swanson: Fair point.
16:52:54 <dulek> Swanson: +1
16:52:56 <patrickeast> Swanson: +1
16:53:00 <DuncanT> Asking for CI is not totally unreasonable
16:53:14 <DuncanT> The inheritence model is definitely better than cut n paste
16:53:20 <asselin__> I'm also leaning on needing ci.
16:53:29 <tbarron> DuncanT: implement CI#2 via sed :-)
16:53:34 <opencompute> True, because we cannot control how much changes went in to new driver
16:53:46 <cFouts> o/
16:53:53 <winston-d> can they create a symbol link to a inherited ci?
16:53:56 <patrickeast> if we require the ci, they are treated as regular drivers and future reviewers dont have to decide how much of a modification warrants adding CI testing
16:54:01 * DuncanT leans for not needing CI for what is there, but is entirely accepting of others voting differently
16:54:12 <DuncanT> patrickeast: Valid point
16:54:20 <winston-d> opencompute: we can controll, we review the patches and approve them.
16:54:33 <thingee> The point of us asking for a CI from some vendors besides verifying they're stuff works was for them to actually be committed in some way to OpenStack and actually understanding how things work. Some people had no idea how to deploy OpenStack before this requirement. IMO, this rebrand thing introduces another way for drive by driver patches and not be
16:54:33 <thingee> involved with the community
16:54:39 <winston-d> opencompute: if we are unhappy about driver change, -2 and ask for really ci
16:54:40 <opencompute> I like the idea of inherited CI
16:55:02 <opencompute> so parent driver changes require both CI +1s
16:55:39 <thingee> I'm still a -1 on these rebranded drivers. It's not a solving anything.
16:55:53 <dulek> opencompute: I don't see how that should work. Child driver can change things.
16:56:05 <asselin__> I'm also -1 on rebranded drivers.
16:56:09 <thingee> see my comments earlier about config options and log messages being confusing of the product you're attempting to rebrand
16:56:12 <opencompute> Child driver only needs it own CI to pass
16:56:29 <DuncanT> thingee: The log messages get rebranded correctly
16:56:38 <thingee> DuncanT: how so?
16:56:40 <opencompute> Parent driver needs parent and children CI to pass
16:57:09 <DuncanT> thingee: The only 'brand' in there are the config option names and the class names, all of which are changed in the child
16:57:10 <thingee> three minute warning
16:57:10 <dulek> 3 minutes warning
16:57:35 <thingee> DuncanT: what about config options that mention the parent product?
16:57:39 <Swanson> It solves a problem for a vendor and a customer.  I've dev X so I get dev X driver.  Not dev Y driver.  Log and options should properly reflect that it is dev X tho or there is no point.
16:57:39 <thingee> name/description
16:57:56 <Swanson> So a complete rebranding or nothing.
16:58:17 <opencompute> Log should include vendor name
16:58:31 <thingee> as asselin__ mentioned earlier, what if they make one method override? we would need to draw the line somewhere.
16:58:37 <opencompute> only 2 minutes
16:58:38 <DuncanT> thingee: Those config options are redone in the child AFAICT. Maybe I need to read the patches again
16:58:39 <thingee> it just seems complicated for little gain from the community
16:58:56 <winston-d> thingee: then we -2 to those changes and ask for ci
16:59:17 <thingee> are any of these maintainers of the rebrand here?
16:59:20 <thingee> in this meeting?
16:59:33 <thingee> ....
16:59:35 <smcginnis> I don't see nikesh around.
16:59:35 <thingee> and there's my point
16:59:38 <DuncanT> thingee: Assuming the rebranding works correctly, it is less complicated to see the name of the array in the config file, rather than some other competitor's array...
16:59:43 <thingee> the smallest involvement as possible
16:59:45 <thingee> to get your product in
16:59:57 <DuncanT> He is time-zone challenged today I believe
17:00:05 <DuncanT> He's been in the meeting before
17:00:06 <asselin__> he was in sanjose
17:00:12 <thingee> #endmeeting