16:00:18 <smcginnis> #startmeeting Cinder
16:00:20 <openstack> Meeting started Wed Feb 10 16:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:22 <jseiler> hi
16:00:25 <openstack> The meeting name has been set to 'cinder'
16:00:26 <gouthamr> hi..
16:00:35 <smcginnis> Courtesy pings:
16:00:37 <smcginnis> dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang tbarron scottda erlon rhedlind jbernard vincent_hou kmartin patrickeast sheel dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17
16:00:39 <dulek> o/
16:00:40 <xyang2> hi
16:00:40 <geguileo> hi!
16:00:43 <patrickeast> hey
16:00:46 <vincent_hou> hi
16:00:49 <akerr> o/
16:00:50 <adrianofr> hi
16:00:50 <scottda> hi
16:00:50 <sheel> hello all
16:00:50 <mc_nair> o/
16:00:51 <mtanino> hi
16:00:58 <eharney> hi
16:00:59 <jungleboyj> Here!
16:01:04 <DuncanT> hi
16:01:09 <thingee> o/
16:01:11 <smcginnis> Looks like a big agenda today, so let's get going...
16:01:12 <yuriy_n17> hi
16:01:14 <bswartz> hi
16:01:16 <smcginnis> #topic Announcements
16:01:18 <e0ne> hi
16:01:25 <jgregor> Hello!
16:01:27 <fernnest> hi
16:01:30 <smcginnis> #info Bug stats: Cinder - 513 open bugs, Python-cinderclient - 38 open bugs, OS-Brick - 14 open bugs
16:01:36 <Guest67795> hi
16:01:42 <ameade> o/
16:01:43 <smcginnis> #link http://releases.openstack.org/mitaka/schedule.html Release schedule
16:01:47 <diablo_rojo> Hello :)
16:01:47 <flip214> hi
16:01:47 <Swanson> hello
16:01:50 <cfouts> hi
16:01:50 <cknight> Hi
16:01:53 <Swanson> Early today.
16:01:55 <tbarron> hi
16:02:00 <smcginnis> Reminder that we are starting to get to the end of some of the deadlines.
16:02:24 <smcginnis> Non-client library freeze coming up quick, so we'll need to cut a final os-brick in about a week
16:02:51 <smcginnis> A few things outstanding there that I think we want to get through, so please watch for those reviews.
16:03:06 <jungleboyj> smcginnis: ++
16:03:22 <smcginnis> Big one to keep in mind, feature freeze at the end of the month.
16:03:49 <smcginnis> #topic Transition to LIO
16:03:58 <DuncanT> Will we consider replication support for drivers a bug?
16:04:04 <sheel> smcginnis:+1
16:04:06 <DuncanT> I suspect we'll need to
16:04:08 <smcginnis> DuncanT: Oh, good point.
16:04:16 <smcginnis> Some leeway on those.
16:04:32 <smcginnis> I don't want anyone cut off due to our change of course if at all possible.
16:04:40 <jungleboyj> DuncanT: Thanks for bringing that up!  What kind of leeway are we talking?
16:04:53 <smcginnis> I will treat those like bugs so they have more time.
16:05:04 <DuncanT> smcginnis: ++
16:05:06 <smcginnis> Until hard freeze I think.
16:05:12 <jungleboyj> smcginnis: Good.
16:05:22 <smcginnis> But for those working on it - please don't wait!!
16:05:28 <e0ne> smcginnis: we need to anounce it in the ML
16:05:31 <vincent_hou> smcginnis: nice.
16:05:37 <erlon> hey
16:05:39 <jungleboyj> I have been opening bugs for the V2 changes that I have seen go in to move them to V2.1
16:05:45 <jungleboyj> Cheesecake for all!
16:05:48 <smcginnis> jungleboyj: Good.
16:05:52 <smcginnis> I like that.
16:06:15 * anteaya also likes cheesecake
16:06:19 <smcginnis> eharney: jbernard doesn't seem to be here. Have you been working with him on any of the LIO stuff?
16:06:19 <vincent_hou> We will get on that way from 2 => 2.1 for rep v2.
16:06:24 <smcginnis> (getting back on topic)
16:06:33 <eharney> i think i can cover the main question here
16:06:39 <smcginnis> eharney: Thanks!
16:07:06 <eharney> my understanding is that nobody is against the general idea of moving from scsi-target-utils to LIO as the default for the LVM driver now that's widely supported
16:07:34 <eharney> the primary technical reason we can't flip a switch for this is because there's a problem of changing that default and not breaking existing installs
16:07:35 <smcginnis> eharney: +1 - I think the issue is upgrade handling, right?
16:07:47 <mtanino> eharney: +1
16:08:08 <eharney> my proposal is to do something like we did for nas_secure_file options where they only take effect if you have no volumes (also framed as "new install")
16:08:25 <smcginnis> eharney: Seems reasonable.
16:08:33 <eharney> so unless anyone has any general disagreements with switching over to LIO in general i think we should just head that direction
16:08:36 <smcginnis> Anyone know of any issues with that?
16:08:46 * mriedem sneaks in late
16:08:47 <eharney> there has been an LIO CI for some time
16:09:14 <vincent_hou> eharney: Is there any special drawback that we use scsi-target? just interested.
16:09:27 <e0ne> eharney: it that CI stable enough?
16:09:32 <e0ne> s/it/is
16:09:46 <eharney> vincent_hou: it's userspace and doesn't perform as well, doesn't support as many features, is not really the future (already dropped from EL7 where we did this migration long ago)
16:09:52 * anteaya offers mriedem some cheesecake
16:10:02 <smcginnis> anteaya: :)
16:10:19 <eharney> e0ne: as far as i know it is...
16:10:19 <jbernard> o/
16:10:31 * jungleboyj hands mriedem a tardy slip
16:10:52 <smcginnis> Yeah, I think from when I've watch LIO CI was pretty stable.
16:10:55 <e0ne> eharney: could you please compare it with tgtd job using http://graphite.openstack.org?
16:10:55 <eharney> e0ne: should pull stats, but afaik, it mirrors the LVM tgt CI just fine
16:11:07 <smcginnis> From my understanding, the only reason we hadn't switch was the upgrade question.
16:11:15 <jbernard> that's my primary question
16:11:27 <jbernard> what do we and users expect if we change the default
16:11:42 <e0ne> it would be great to have real numbers how it is stable
16:11:53 <eharney> e0ne: we can get real numbers if you would like
16:12:33 <eharney> jbernard: the general expectation IMO is don't break upgrades and work the same as the current driver
16:12:37 <e0ne> eharney: AFAIR, we do it each time when we want to get job voting
16:12:45 <eharney> e0ne: not a problem.
16:13:00 <jbernard> eharney: ok, that should be doable
16:13:00 <e0ne> now, gate-tempest-dsvm-full-lio it not voting
16:13:12 <jbernard> e0ne: we'll need to change that
16:13:16 <smcginnis> That would need to change.
16:13:18 <eharney> no
16:13:20 <e0ne> +1
16:13:27 <thingee> e0ne: LIO has existed the kernel for sometime. While that doesn't speak on stability, I am aware of it being used in real deployments.
16:13:31 <eharney> the change would be that the regular main job switches to LIO
16:13:34 <eharney> not to make the LIO job voting
16:13:43 <eharney> what we would do is create a different job for tgt
16:13:46 <smcginnis> eharney: Good point.
16:13:52 <jbernard> eharney: ahh, nice
16:14:00 <smcginnis> The new tgt one then would need to be voting.
16:14:03 <jbernard> eharney: swappa-dappa
16:14:08 <eharney> but these are all auxiliary points for now IMO
16:14:18 <e0ne> smcginnis: +1
16:14:44 <jbernard> im happy to drive the effort, as long as we're all okay with that direction
16:14:51 <DuncanT> It doesn't sound like anybody has a problem in principle - we just need to collect up to to-do list and work through it
16:15:05 <eharney> right, so let's get to all the other topics here
16:15:08 <smcginnis> jbernard: Yep, as long as we don't break upgrades, that sounds like the right thing to do.
16:15:18 <smcginnis> eharney, jbernard: Thanks!
16:15:31 <smcginnis> #topic Outreachy projects
16:15:36 <smcginnis> jbernard: Still you. :)
16:15:43 <jbernard> right, i applied to be a mentor for cinder
16:15:49 <jbernard> ive got a few project ideas
16:16:02 <smcginnis> jbernard: Do you have an etherpad or anything like that going?
16:16:03 <jbernard> but wanted to raise it here, if anyone has smallish bit-sized projects for new contributers
16:16:13 <jbernard> smcginnis: not yet, but i can start one
16:16:26 <smcginnis> jbernard: That might help. We can direct people there to capture ideas.
16:16:30 <xyang2> jbernard: does it have to be a project?  can it be bug fixing?
16:16:50 <jbernard> i think it can be anything that would help the project and allow a contributer to gain experience
16:17:05 <smcginnis> +1
16:17:14 <diablo_rojo> +1
16:17:16 <vincent_hou> like low hanging fruit?
16:17:17 <jbernard> so somthing simple like 'convert this driver to use versioned objects'
16:17:26 <jbernard> or remove taskflow from volume create
16:17:33 <jbernard> although that's a larger undertaking
16:17:37 <smcginnis> vincent_hou: Low hanging fruit would be a good way to help people get involved.
16:17:38 <kmartin> lol
16:17:42 <scottda> How about "add functional test for X"
16:17:46 <anteaya> jbernard: half the work with outreachy is being available everyday, so the mentee keeps showing up
16:17:48 <smcginnis> vincent_hou: But I don't think we've been good tagging those.
16:17:57 <smcginnis> scottda: That's a good idea.
16:17:58 <vincent_hou> OK.
16:17:59 <DuncanT> Removing taskflow is a fairly epic job to get right now
16:18:10 <scottda> we're scarce in functional tests,  and learning  how to test Cinder is a great place to start
16:18:14 <jbernard> DuncanT: yeah, i take taht one back
16:18:15 <diablo_rojo> smcginnis: Last time I looked there weren't more than a dozen low hanging fruit tags
16:18:29 <jbernard> anteaya: no problems ther
16:18:32 <diablo_rojo> scottda: +1
16:18:39 <anteaya> jbernard: wonderful
16:18:41 <smcginnis> diablo_rojo: I'm sure there are more, we just need to identify them.
16:18:53 <diablo_rojo> smcginnis: True.
16:18:56 <jbernard> ill start etherpads for both LIO and outreachy projects post links
16:19:12 <anteaya> fully a 1/3 of the internship is learning our workflow
16:19:13 <smcginnis> jbernard: Thanks for doing this. We can link the etherpads here if you have them. Or next time.
16:19:24 <smcginnis> anteaya: Very true!
16:19:25 <jbernard> smcginnis: ill have them for next time
16:19:27 <dulek> jbernard: Any chance you'll post links to the ML?
16:19:39 <jbernard> dulek: yep, very appropriate
16:19:42 <smcginnis> jbernard: Perfect, thanks for doing this. I think it's great for the community.
16:19:59 <sheel> jbernard: +1
16:20:01 <smcginnis> #topic Support for 4-byte unicode for naming volume, snapshot, CG, volume_type etc
16:20:02 <jbernard> no problem, i hope there are some takers, it'd be great to have new folks
16:20:09 <smcginnis> sheel: You're up.
16:20:20 <sheel> hello all
16:20:34 <smcginnis> #link https://bugs.launchpad.net/cinder/+bug/1542413 Bug report
16:20:35 <openstack> Launchpad bug 1542413 in Cinder "Unable to use 4-bytes unicode when creating volume, volume_type, CG, etc" [Medium,Confirmed] - Assigned to Jacob Gregor (jgregor)
16:20:35 <sheel> ITs basically to discuss how we are going to handle unicode characters
16:20:58 <sheel> MySQL's character set which is utf8 does not support 4 byte characters.
16:20:58 <sheel> Should we prevent this issue(by prohibiting user for not using 4 byte characters) or fix it?
16:21:08 <eharney> so i think we already have solved this
16:21:22 <sheel> eharney: yes we have solved this by prohibiting user
16:21:26 <eharney> no, we haven't
16:21:42 <DuncanT> eharney: The patch you linked makes our API dependant on the backing DB :-(
16:21:45 <eharney> i have a patch up already that solves it by letting it work if the backend db supports it, and responds with the correct error message if it doesn't
16:21:59 <eharney> DuncanT: how so?
16:22:16 <sheel> yes but that will not allow user to use 4 byte unicode characters
16:22:17 <eharney> DuncanT: by not throwing 500 for errors coming from the db...?
16:22:26 <smcginnis> DuncanT: You mean something will worlk on one cloud but not another depending on the backing DB?
16:22:28 <eharney> sheel: why not?
16:22:38 <DuncanT> eharney: The user has no way to know if they can use 4-byte unicode messages or not unless they try it
16:22:40 <mriedem> smcginnis: that would be my concern
16:22:43 <mriedem> right
16:22:46 <mriedem> it's not discoverable
16:22:47 <eharney> that is true
16:23:06 <smcginnis> Well, "discoverable" but not in a good way. ;)
16:23:16 <eharney> so the patch i linked still needs to land, but you are considering adding a more purposeful check at the API layer to prevent it intentionally
16:23:19 <DuncanT> IMO it is something we really need to be consistent about
16:23:24 <jungleboyj> eharney: Link?
16:23:33 <sheel> eharney: if user tries 4 byte will they wont get error message, though gentle message but still they prohibity user from using it
16:23:35 <flip214> well, "discoverable" as in "have some trash table and try to insert there", right?
16:23:41 <sheel> right?
16:23:42 <smcginnis> This one?
16:23:44 <vincent_hou> I guess I can try to save Vhinese chars as names to test.
16:23:45 <smcginnis> #link https://review.openstack.org/#/c/266036/
16:23:48 <eharney> https://review.openstack.org/#/c/266036/
16:23:49 <vincent_hou> Chinese
16:23:50 <bswartz> why can't support for 4-byte utf-8 get added to mysql and then we can require that?
16:24:01 <jungleboyj> Thanks.
16:24:07 <eharney> bswartz: i've wondered what the perf implications are of changing to the utf8mb4 char set, does anyone know?
16:24:24 <eharney> mysql supports it but you have to create the database in a way that uses it
16:24:25 <mriedem> jaypipes was talking about this same issue at the nova midcycle
16:24:34 <mriedem> so i'd ask jay about the 4-byte utf8 mysql thing
16:24:35 <smcginnis> I would think maybe a little extra storage overhead, but maybe more?
16:24:44 <bswartz> 4-byte unicode is worth supporting IMO
16:24:46 <DuncanT> eharney: Can you do a migrate?
16:24:47 <jgregor> eharney: Based on some initial investigation I have done, I do not see any major issues that would need to be tackled.
16:24:49 <jeblair> mordred, SpamapS, or jaypipes may be able to help
16:24:54 <eharney> DuncanT: i don't know
16:24:58 <smcginnis> mriedem: Do you remember where that conversation ended up?
16:25:04 <mriedem> smcginnis: that it wasn't funh
16:25:06 <mriedem> *fun
16:25:07 <clarkb> you can migrate
16:25:11 <jgregor> eharney: We would need to check the maximum length of columns and index keys.
16:25:11 <smcginnis> mriedem: Is there a plan to support in nova?
16:25:18 <mriedem> smcginnis: i don't think so
16:25:26 <smcginnis> mriedem: OK, thanks.
16:25:26 <clarkb> and the overhead is 4 bytes per character instead of 3
16:25:47 <mordred> what did I do?
16:25:48 <jeblair> clarkb: probably not the end of the world for volume name fields
16:26:14 <jeblair> mordred: perf/feasibility implications of 4 byte utf8 in mysql
16:26:17 <smcginnis> I'm curious if the backends that use the volume name can actually support this too.
16:26:19 <mordred> ah
16:26:26 <eharney> smcginnis: they probably shouldn't be doing that
16:26:43 <smcginnis> eharney: Yeah
16:26:52 <eharney> by which i mean, definitely shouldn't
16:27:03 <smcginnis> And maybe there aren't now, but I thought we had some that were using volume name.
16:27:05 <sheel> In that case, I think its better to go with eharney's patch
16:27:08 <DuncanT> smcginnis: Once cinder can handle it, we can push some tests into tempest to see what explodes
16:27:12 <mc_nair> seems useful to coordinate cross-project on this since everyone will be hitting a similar issue
16:27:14 <eharney> sheel: they're orthogonal
16:27:24 <eharney> we need to land patches like mine to go from HTTP 500->400 now
16:27:25 <jungleboyj> smcginnis: I haven't seen that?
16:27:28 <eharney> actual support is a different question
16:27:33 <smcginnis> mc_nair: Good point.
16:27:36 <eharney> which can be done alongside or after that
16:27:39 <mordred> so, last time I cared full 4-byte support was shallow, that might have improved - but the big difference is that size explosion
16:27:41 <sheel> eharney: yes
16:27:47 <smcginnis> If nova is discussing this too, that's a good sign it's a cross project issue.
16:27:47 <mordred> are we talking for volume names?
16:27:49 <jungleboyj> mc_nair: Good point.  diablo_rojo ^^^
16:27:49 <sheel> eharney: that is  true
16:27:53 <jeblair> mordred: yes
16:27:56 <mordred> yah. should be fine
16:27:57 <DuncanT> mordred: Yes
16:28:01 <smcginnis> So I think eharney's patch is probably a good first step.
16:28:08 <smcginnis> But we need a larger plan.
16:28:11 <DuncanT> mordred: Probably metadata k/v and similar as well
16:28:17 <hemna> mornin
16:28:23 <sheel> smcginnis: yes, that s why i raise this for meeting
16:28:40 <mordred> just be aware that you're going to be increasing storage requirements by 4x in indexes at least - and I can't remember whether it's on-disk or in-memory where everything gets blown out to 4-bytes-per-char regardless of if the char is actually a 4-byte char
16:28:43 <diablo_rojo> jungleboyj: Is this something you would like me to bring up in the next cp meeting?
16:28:46 <mc_nair> think every project will hit this same discussion for anywhere they let user defined names
16:28:55 <mordred> for things like that it's likely a non-issue
16:28:59 <clarkb> mordred: everything iirc
16:29:09 <clarkb> (I had to do this for etherpad)
16:29:12 <mordred> clarkb: there's one place where it doesn't blow out - but I cannot remember where that is
16:29:15 <smcginnis> diablo_rojo: Can you work with sheel and raise this as a cross project issue?
16:29:15 <jungleboyj> diablo_rojo: Possibly if that is the concensus here.
16:29:24 <flip214> that'll get funny on the REST connections (JSON), too
16:29:25 <mordred> clarkb: safer to just assume it's everytihng
16:29:25 <diablo_rojo> smcginnis: Definitely
16:29:36 <mordred> it's DEFINITELY indexes
16:29:38 <sheel> diablo_rojo: smcginnis : thanks
16:29:52 <jungleboyj> mc_nair: Good call on the cross projectness.
16:29:58 <diablo_rojo> sheel: Maybe we involve jgregor too?
16:29:58 <smcginnis> OK, let's raise this for CP. I don't think we can decide anything here right now.
16:30:01 <eharney> so we're ok with continuing to land patches to go from http 500->400 in the meantime?
16:30:01 <mordred> which tends to be the biggest issue, because it can cause index buffers to get overblown more quickly leading to performance degredation if index buffer sizes are not increased
16:30:08 <sheel> diablo_rojo: yup
16:30:10 <smcginnis> eharney: Yes, I think so.
16:30:16 <jgregor> diablo_rojo: sheel :)
16:30:22 <eharney> smcginnis: ok
16:30:26 <diablo_rojo> sheel:  jgregor Cool. We all can chat after the meeting
16:30:39 <mc_nair> smcginnis: +1
16:30:39 <sheel> diablo_rojo: jgregor :yes
16:30:44 <smcginnis> #topic New behavior of DocImpact tag
16:30:49 <sheel> smcginnis:  eharney  +1
16:31:04 <smcginnis> So some of you may have noticed this by now.
16:31:19 <smcginnis> There's been a change in what happens when you put a DocImpact tag in a commit.
16:31:24 <sheel> yes
16:31:28 <jungleboyj> smcginnis: sheel Thanks for the attention to this.  It keeps coming up.  Would be good to resolve.
16:31:29 <xyang2> smcginnis: this behavior doesn't make sense.  it should be a bug in openstack manuals
16:31:30 <sheel> new bugs
16:31:39 <smcginnis> From what I understood, in the past it would open a bug against the doc team.
16:31:51 <smcginnis> xyang2: I actually like it, though it's more work for us.
16:32:00 <hemna> what does it do now ?
16:32:00 <xyang2> smcginnis: what do we need to do in cinder?
16:32:03 <eharney> xyang2: don't some of them need to land in release notes that we handle?
16:32:04 <sheel> jungleboyj: welcome
16:32:19 <xyang2> eharney: in my case, it is already added to release notes
16:32:23 <smcginnis> With the old way manuals would then need to look at the patch and try out what changed and what the doc impact was.
16:32:29 <xyang2> so I need to add that in openstack manuals
16:32:40 <smcginnis> Most of the time there was no detail to explain what the doc impact was in the commit.
16:32:44 <xyang2> not sure what else to change in cinder as it is a new feature in driver
16:32:56 <smcginnis> So folks that don't know the code and might not even be programmers were stuck doing investigation.
16:33:13 <mriedem> smcginnis: reviewers can always -1 when there is no explanation in the commit message with the DocImpact tag
16:33:16 <smcginnis> So the new approach is these bugs will not be opened against the project where they came from.
16:33:23 <mriedem> it's actually in the docs that there should be an explanation
16:33:29 <smcginnis> mriedem: We kinda sorta did that once in awhile.
16:33:41 <mtanino> mriedem: +1
16:33:44 <smcginnis> So really there is just one extra step.
16:33:47 <jungleboyj> smcginnis: You mean "now be opened"
16:33:57 <sheel> smcginnis: I think this is right way, but  how we though about to move with it
16:34:05 <smcginnis> *now
16:34:12 <xyang2> now it opened a bug in cinder right after the feature was merged in cinder
16:34:17 <eharney> does our use of reno now mean that if we only want release notes, just add them and don't add DocImpact?
16:34:25 <mriedem> eharney: that's what nova has been doing
16:34:27 <xyang2> so we need to fix it in openstack manuals and close it in cinder?
16:34:31 <smcginnis> eharney: Sometimes that can be the case.
16:34:38 <smcginnis> I think we overused DocImpact to be honest.
16:34:39 <mriedem> DocImpact is really usually only the manuals
16:34:43 <mriedem> smcginnis: +1
16:34:47 <eharney> seems sensible
16:34:52 <mtanino> xyang2: Should we also add openstack-manual to the opened bug?
16:34:55 <smcginnis> But maybe I can finish explaining the process now. ;)
16:35:20 <xyang2> https://bugs.launchpad.net/cinder/+bug/1543407
16:35:21 <openstack> Launchpad bug 1543407 in Cinder " ScaleIO QoS Support" [Undecided,New] - Assigned to Xing Yang (xing-yang)
16:35:28 <xyang2> here is the bug opened for me automatically
16:35:30 <sheel> smcginnis: yes, plz
16:35:38 <smcginnis> So the extra step is when a patch lands with DocImpact, we need to add info about the documeentation impact in the bug that is opened.
16:35:39 <xyang2> but the patch just got merged in cinder
16:35:45 <smcginnis> Bahhhhhhh
16:35:46 <smcginnis> :)
16:36:21 <smcginnis> Once some information about what needs to be documented is added to the bug, it then can be switched over to the manuals project.
16:36:23 <xyang2> we can add it in the bug but we can only fix it in manuals
16:36:35 <xyang2> so there's no more patch to submit in cinder
16:36:40 <smcginnis> They then have the information they need to update the manuals.
16:36:41 <hemna> smcginnis, is this change documented anywhere ?
16:36:41 <mriedem> does anything comment on the patch saying there was a bug opened? or you have to hunt for it?
16:36:46 <hemna> I'm sure to forget this shit
16:37:00 <mriedem> knowing how great LP search works
16:37:00 <jgriffith_away> hemna: +1, yeah... we've just made this really difficult IMO
16:37:04 <smcginnis> xyang2: Right, it's opened in Cinder so we triage it, then switched to manuals to be closed with a patch.
16:37:17 <hemna> jgriffith_away, +1 yah I don't get this change at all.  This is a mess IMHO
16:37:17 <mriedem> i'd hope the bug is at least tagged with 'documentation'
16:37:21 <smcginnis> hemna: Somewhere, but unfortunately I'm unprepared and don't have that handy.
16:37:24 <xyang2> smcginnis: ok, right weird
16:37:38 <Swanson> jgriffith, you're not dead!
16:37:40 <hemna> basically it's just going to make people not use DocImpact at all now.
16:37:51 <xyang2> hemna: tagged with cinder doc
16:37:52 <jgriffith> Swanson: not quite yet... come back next Tuesday
16:37:53 <mriedem> well, honestly, this isn't really any worse than what happened before
16:37:55 <smcginnis> mriedem: The bug gets opened tagged with "cinder" and "doc", so easy to query.
16:38:05 <mriedem> before a docs bug would be opened and sit for years
16:38:09 <mriedem> b/c no details
16:38:09 <diablo_rojo> hemna: +1 I can see that happening
16:38:10 <smcginnis> mriedem: +1
16:38:21 <hemna> yah I don't see a point in even using the tag now.
16:38:26 <smcginnis> Now we need to think about whether something really is a DocImpact or not.
16:38:26 <mriedem> now a cinder bug is opened so there is a marginally better chance someone will ping a person to doc it and send it over to manuals
16:38:27 <anteaya> the point of the change is to reduce the load on the docs folks as they have not been able to work productively
16:38:28 <jgriffith> mriedem: don't get me wrong... I'm just saying it's not clear *yet*
16:38:38 <smcginnis> Which we should have been doing in the first place.
16:38:48 <smcginnis> And stop dumping on the manual team to go figure it out.
16:38:56 <jgriffith> anteaya: and that seems completely fair/reasonable :)
16:39:03 <jgriffith> smcginnis: +1
16:39:19 <anteaya> and that's the point but I understand that the change in routine is upsetting
16:39:27 <smcginnis> SO we definitely still want to use this for new config options and new features.
16:39:31 <jungleboyj> diablo_rojo: smcginnis Sounds like something that we will have to monitor.
16:39:33 <smcginnis> That requires updates to the docs.
16:39:39 <jgriffith> anteaya: mriedem smcginnis I was just saying that following your discussion on the process here was kinda confusing.  We need to get it written up clearly and concisely
16:39:46 <smcginnis> But now we have the ownership to say what needs to be added.
16:39:52 <jgriffith> anteaya: mriedem smcginnis and make sure it's easy to find etc
16:39:56 <geguileo> jgriffith: +1
16:40:00 <mtanino> jgriffith: +1
16:40:04 <smcginnis> Instead of assuming someone not part of cinder can figure it out on their own.
16:40:04 <anteaya> jgriffith: that is reasonable
16:40:09 <mriedem> jgriffith: so write docs about the docs process? :)
16:40:13 <mriedem> it's a catch-22
16:40:19 <hemna> mriedem, :)
16:40:19 <e0ne> jgriffith: +1
16:40:21 <jgriffith> mriedem: well.. no it's not
16:40:25 <mriedem> joking...
16:40:25 <smcginnis> jgriffith: Confusing for sure.
16:40:26 <diablo_rojo> smcginnis: is there a reason why this happened isnstead of just forcing people to explain the DocImpact tag in the commit?
16:40:28 <sheel> smcginnis: so, may be this can be monitored by cinder-bug team member and just assign this to member who worked on patch to add this infomation
16:40:29 <jgriffith> mriedem: if you want process that's how it works :)
16:40:36 <smcginnis> Woudl have been a lot less if I could have just explained it first. :)
16:40:36 <jgriffith> mriedem: Oh... ok... :)
16:40:39 <jungleboyj> Something that everyone shoudl be responsible for.  And everyone can help out with.
16:40:39 <mriedem> i <3 process
16:40:40 <jgriffith> mriedem: sorry
16:40:43 <anteaya> diablo_rojo: because people weren't
16:40:48 <jgriffith> mriedem: you do not!!!
16:40:50 <jgriffith> liar
16:40:54 <smcginnis> sheel: That's waht I've been doing.
16:41:07 <sheel> smcginnis: yup, i see this
16:41:13 <sheel> :)
16:41:13 <mriedem> diablo_rojo: b/c reviewers weren't enforcing that
16:41:20 <smcginnis> mriedem: +1
16:41:24 <sheel> I wil try to overload you for this
16:41:25 <diablo_rojo> anteaya: I wasn't aware that was something we had to do otherwise I definitely would have :/
16:41:29 * jgriffith is certainly guilty
16:41:42 <anteaya> #link this email to the -dev list may help http://lists.openstack.org/pipermail/openstack-dev/2016-February/085733.html
16:41:50 <diablo_rojo> anteaya: Thanks :)
16:41:50 <smcginnis> Bringing it up here so folks understand now and know what it means to us.
16:41:53 <jungleboyj> diablo_rojo: ++
16:41:53 * jgriffith catches maybe 1 in 10... or 1 in 100
16:41:54 <smcginnis> anteaya: Thanks!!
16:41:56 <anteaya> diablo_rojo: well now you have expanded your awareness
16:41:59 <anteaya> smcginnis: welcome
16:42:04 <diablo_rojo> anteaya: True :)
16:42:05 <DuncanT> diablo_rojo: Many people weren't aware, including reviews, don't feel bad
16:42:22 <smcginnis> And on that, I'm done talking doc bugs. Bleh.
16:42:22 <hemna> jgriffith, +1
16:42:23 <xyang2> smcginnis: thingee used to hold off the release notes until a doc patch is added, but now we are adding release notes as part of the patch
16:42:27 <smcginnis> #topic Deprecating cinder client
16:42:34 <diablo_rojo> DuncanT: its an easy thing to look at and I totally would have had I know, but oh well. New process here we come
16:42:37 <smcginnis> thingee: Hey
16:42:38 <jungleboyj> Well, now we need to be aware of the doc bugs and get people responding.
16:42:41 <thingee> hi
16:42:49 <jungleboyj> diablo_rojo: ++
16:42:52 <thingee> so deprecating cinder client in favor of the openstack client http://specs.openstack.org/openstack/openstack-specs/specs/deprecate-cli.html
16:42:56 <DuncanT> A wild Mike appears....
16:43:10 <smcginnis> We've talked about this some here and at the midcycle.
16:43:13 <thingee> your wonderful cp-spec liaison has brought this up a few times
16:43:14 <DuncanT> thingee: Did you see the notes from the midcycle about this?
16:43:18 <e0ne> we decided to not do it in Mitaka
16:43:24 <thingee> as I understand the author of the spec has already been in contact with smcginnis about this
16:43:25 * diablo_rojo blushes
16:43:28 <smcginnis> I agree we want to have osc be the one CLI to rule them all.
16:43:31 <smcginnis> Some day
16:43:38 <thingee> DuncanT: no
16:43:48 * SpamapS perks up at the mention of utf8. Please to ping me when open discussion begins or we can loop back to that topic.
16:43:54 <e0ne> #link https://etherpad.openstack.org/p/mitaka-cinder-midcycle-day-1
16:44:00 <smcginnis> We need to get to feature parity between cinderclient and osc.
16:44:07 <smcginnis> Then we can start thinking about deprecating.
16:44:12 <hemna> smcginnis, +1
16:44:16 <smcginnis> Until then, I'm not going to change anything.
16:44:16 <thingee> So I started looking at osc and cinder client and noticed there is quite a bit missing
16:44:18 <thingee> yes exactly
16:44:21 <hemna> I don't think it makes any sense to deprecate right now.
16:44:26 <smcginnis> thingee: Yeah. :/
16:44:31 <jgriffith> smcginnis: thingee ???
16:44:36 <smcginnis> jbernard: Outreachy ^^
16:44:46 <smcginnis> jbernard: Add cinderclient functionality to osc.
16:44:48 <scottda> We hope to land microversions soon. I was told OSC does not yet support microversions
16:44:52 <thingee> so wanted to see what the group thought on this effort
16:44:53 <diablo_rojo> hemna: You had posted a pretty huge list in the reviews and that wasn't complete right?
16:44:53 <hemna> smcginnis, thingee I even pointed out some of those differences in the gerrit review for the client deprecation.
16:45:00 <thingee> it's not going to get better as people keep adding to cinder client
16:45:08 <hemna> diablo_rojo, correct.  I took a 5 minute pass and lined out many items that were missing.
16:45:21 <jgriffith> thingee: let's be clear here... this is just cli
16:45:27 <smcginnis> thingee: On the other hand, we can't stop improving things waiting for osc to get caught up.
16:45:28 <jgriffith> thingee: osc uses cinderclient
16:45:31 <diablo_rojo> hemna: and there were some pretty important things missing there
16:45:40 <jgriffith> thingee: correct?
16:45:42 <thingee> jgriffith: yup, that's true. so we cinder client needs it still
16:45:53 <thingee> forgot about that
16:46:05 <thingee> but anyways, the effort towards getting stuff moved over...
16:46:12 <jungleboyj> So, we need to be making sure that anything that is touching cinderclient also get as change to OSC as well.  Right?
16:46:14 <DuncanT> thingee: We were wondering if there was a way to put the cinder bits in cinder-client and have OSC suck them out, rather than needing to go to the OSC repo for every new feature?
16:46:19 <thingee> jungleboyj: yes
16:46:24 <jungleboyj> Reviewers!!!  :-)
16:46:24 <jgriffith> jungleboyj: if you want a cli for it yes
16:46:33 <DuncanT> thingee: i.e. make it discover stuff out of cinder-client
16:46:34 <smcginnis> DuncanT: Oh yeah, forgot that. That would be ideal.
16:46:35 <jungleboyj> jgriffith: Right.
16:46:38 <jgriffith> jungleboyj: it's just cli impact
16:46:47 <thingee> DuncanT: not that I'm aware of, but it's really just setting the CLI to the cinder client method it should call
16:46:50 <jgriffith> jungleboyj: righty ho
16:46:51 <thingee> in theory nothing too crazy
16:47:05 <jungleboyj> jgriffith: Right.  Understood.  Just wanted to make note here.
16:47:14 <hemna> jungleboyj, OSC needs CLI commands to what cinderclient already provides.
16:47:19 <jgriffith> https://github.com/openstack/python-openstackclient/tree/master/openstackclient/volume
16:47:24 <jgriffith> DuncanT: ^^
16:47:26 <DuncanT> thingee: Going through another review cycle unnecessarily is pretty crazy IMO
16:47:31 <hemna> there are lots of things missing that OSC needs to support.
16:47:32 <hemna> DuncanT, +1
16:47:34 <e0ne> thingee: we're are going to try to implement OSC plugin inside cniderclient
16:47:36 <smcginnis> I'm going to move on as I don't think we can do anything immediately on this and we have other stuff to cover.
16:47:43 <jgriffith> DuncanT: no magic there... just a lot of work
16:47:47 <jungleboyj> hemna: Understood.  And we need to be aware taht any future CLI changes shouldn't be missed.
16:47:51 <smcginnis> #topic Status of api-microversions patch set
16:47:52 <smcginnis> scottda: Hey
16:47:53 <DuncanT> jgriffith: Needs more magic
16:47:58 <jgriffith> DuncanT: :)
16:47:59 <scottda> #link https://review.openstack.org/#/c/224910
16:48:01 <thingee> smcginnis: so my point of this was anybody care? anybody interested in working on this.
16:48:11 <smcginnis> thingee: I think yes.
16:48:16 <scottda> patches pass Jenkins and are ready for review
16:48:19 <diablo_rojo> DuncanT: Theres always a need for more magic :)
16:48:24 <smcginnis> thingee: I'm hoping to spend a little time on it as well.
16:48:33 <smcginnis> scottda: Anything missing yet?
16:48:34 <DuncanT> thingee: I might try to prototype my idea, or convince somebody else to
16:48:42 <hemna> scottda, we finally passing Jenkins?
16:48:43 <scottda> I'm hopeful I can get tests (functional, tempest) up as a separate patch
16:49:08 <scottda> hemna: We were passing Jenkins, but /v3 enpoint had to be added. Passing now.
16:49:11 <diablo_rojo> DuncanT: if you can prototype it you could get your ATC code
16:49:19 <scottda> And I've adressed any review comments that I know of
16:49:21 <jungleboyj> :-)
16:49:21 <smcginnis> diablo_rojo: Hah!
16:49:27 <smcginnis> DuncanT: She got you.
16:49:29 <hemna> scottda, excellent.
16:50:02 <diablo_rojo> scottda: Good work.
16:50:04 <scottda> I hope review objections can be made soon, so fixes can be made, etc. ....We're getting close to feature freeze
16:50:17 <smcginnis> scottda: Live demo?
16:50:18 <hemna> scottda, I'll help review
16:50:22 <scottda> I can also do a demo,
16:50:23 <jungleboyj> scottda: Good news.
16:50:33 <jungleboyj> scottda: Will try to look.
16:50:49 <scottda> Thurs or Fri at 16:00 UTC? (this meeting time)?
16:50:51 <smcginnis> scottda: Thinking google hangout recorded to our Youtube channel?
16:50:58 <scottda> smcginnis: yes
16:51:05 <scottda> How about Friday 16:00 UTC?
16:51:09 <smcginnis> scottda: That would be great to have.
16:51:16 <smcginnis> scottda: I think that time works for me.
16:51:23 <scottda> OK, I'll set it up and post to ML
16:51:30 <hemna> scottda, google hangout ?
16:51:45 <smcginnis> scottda: Thanks for working on this. A lot involved to get that through.
16:51:47 <scottda> hemna: yes, + Youtube (I'll need your help with that, I reckon)
16:51:54 <hemna> scottda, I can setup a youtube live stream to host it
16:52:10 <smcginnis> A/V Club to the rescue. :)
16:52:21 <scottda> Soooo...can functional/tempest tests be added as a separate patch set?
16:52:22 <jungleboyj> hemna: Is our hero!
16:52:38 <smcginnis> scottda: I think so.
16:52:47 <smcginnis> scottda: I wouldn't want to cram too much in one patchset.
16:52:52 <smcginnis> scottda: Probably better to break it out.
16:52:57 <scottda> OK, so please beat up on it ASAP
16:53:00 <hemna> is that 8am PST ?
16:53:02 <jungleboyj> smcginnis: Do you think scottda is trustworthy?  ;-)
16:53:04 <hemna> this Friday ?
16:53:08 <smcginnis> :)
16:53:15 <scottda> hemna: Yes. Same time as this meeting, but on Friday
16:53:19 <smcginnis> jungleboyj: We know where he lives.
16:53:25 <hemna> crap, I can't make that time.
16:53:33 <jungleboyj> :-)
16:53:56 <smcginnis> scottda: Oh, actually I have a conflict too.
16:53:59 <scottda> I can push out 1 hour? 17:00 UTC Friday? Too late for e0ne and DuncanT ?
16:54:15 <DuncanT> Ok for me
16:54:23 <e0ne> 17:00 UTC is good for me
16:54:24 <smcginnis> scottda: I'm bust until 17:30 UTC.
16:54:28 <eharney> FYI we still have HA on the agenda and six minutes left
16:54:37 <smcginnis> But if we capture this in a video I think that's OK.
16:54:51 <scottda> OK, we can debate the times in channel afterwards.
16:54:57 <scottda> That's it. Move on.
16:55:13 <smcginnis> #info Tentative demo time, 17:00 UTC Friday
16:55:24 <smcginnis> #topic Job distribution for HA A/A
16:55:29 <smcginnis> geguileo: Hi
16:55:38 <geguileo> For job distribution, do we need/want to disable specific nodes?
16:55:49 <DuncanT> geguileo: yes
16:55:55 <geguileo> Should this disabling have the same effect as disabling has now (only prevent scheduler RPC calls)? Or should it also prevent the node from processing RPC calls coming from the API nodes?
16:56:31 <DuncanT> geguileo: The later if there are other nodes in the group IMO, though that is a nice-to-have rather than a hard requirement
16:56:31 <geguileo> DuncanT: If I remember correctly you wanted to stop them completely, right?
16:56:59 <DuncanT> geguileo: It would be nice for disable to mean 'leave that node the hell alone'
16:57:07 <geguileo> Ok, then the idea I propose is to stop the RPC server
16:57:20 <geguileo> When the node is disabled and start it again when it is enabled again
16:57:35 <geguileo> For that we would be polling the DB to see the status of disabled
16:57:57 <geguileo> The alternative is creating a new message queue for each backend-node pair
16:58:03 <smcginnis> 2 minute warning
16:58:07 <geguileo> And getting the enable/disable in that queue
16:58:20 <geguileo> Any preference?
16:58:23 <DuncanT> geguileo: Or having more than one RPC channel to the manager
16:58:41 <DuncanT> Ah, yes, new message queue, same thing
16:58:46 <jgriffith> geguileo: DuncanT is there a possibility of doing something more simple first?
16:58:48 <DuncanT> Better than polling I think
16:58:59 <geguileo> jgriffith: Yep, not allowing disabling nodes
16:59:23 <jgriffith> geguileo: DuncanT like a disable in the manager?  Or say like setting a check in rpc.api for service status?
16:59:25 <flip214> DRBD has the same problem... a "normal" disconnect might take very long (draining buffers), forced does it NOW... with bad side effects.
16:59:26 <DuncanT> jgriffith: disabling nodes I'd really like, but if that is only at the scheduler level I'm fine with that as a starter
16:59:30 <geguileo> DuncanT: I think it's also better but it may be considerably more complicated and will duplicate our queues
16:59:30 <jgriffith> for both cast and call
16:59:57 <smcginnis> Pick this up again next week?
16:59:58 <flip214> don't know which would be more appropriate here, though... I guess waiting for all tasks currently in-progress might takes up to hours
17:00:03 <jgriffith> DuncanT: I agree with you, just wonder if there's a way to do it without trying to be too clever and showing off :)
17:00:07 <smcginnis> Or discuss in channel.
17:00:18 <smcginnis> No showing off??
17:00:22 <DuncanT> flip214: Disable shouldn't normally kill running tasks... that's kind of the point IMO
17:00:24 <jgriffith> smcginnis: :)
17:00:31 <smcginnis> Alright, we're out of time.
17:00:35 <smcginnis> Thanks everyone.
17:00:38 <geguileo> jgriffith: I'm really looking for the simplest solution
17:00:48 <smcginnis> #endmeeting