#openstack-meeting-3 log

14:00:14 <SergeyLukjanov> #startmeeting sahara
14:00:14 <openstack> Meeting started Thu Feb 25 14:00:14 2016 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:18 <openstack> The meeting name has been set to 'sahara'
14:00:19 <SergeyLukjanov> #chair elmiko
14:00:23 <SergeyLukjanov> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
14:00:24 <openstack> Current chairs: SergeyLukjanov elmiko
14:00:33 <SergeyLukjanov> #topic News / updates
14:00:52 <crobertsrh> Hello/
14:00:59 <tmckay> hello
14:01:02 <sreshetnyak> o/
14:01:08 <crobertsrh> Thanks for all the reviews on the UI re-org.
14:01:28 <crobertsrh> I'll be re-working the documentation over the coming days.
14:01:31 <vgridnev> I think that base things are finished for health checks, waiting reviews and saharaclient release
14:01:46 <esikachev> i am working on improvement scenario tests, updating of sahara-ci
14:01:53 <tmckay> news, updates --  I am working on decoupling the logic around "use_floating_ips".  There are 2 things here: 1) assign floating ips, and 2) use them for the management network
14:02:28 <elmiko> i'm working on api v2, and reporting security bugs. also, i've got a pull request for a blog post about sahara on the security project blog.
14:02:31 <elmiko> #link https://github.com/openstack-security/openstack-security.github.io/pull/13
14:02:34 <tmckay> especially when we consider (someday!) mixed baremetal/vm environments, we should be able to control floating ip use per cluster, or per node group even
14:02:55 <tmckay> looks like it will work fine for neutron, but nova networking may have a legacy wrinkle or two
14:03:04 <tmckay> I'll post a spec when I'm sure it works :)
14:03:55 <NikitaKonovalov> I'm working on some minor UI improvements for duration columns.
14:05:06 <weiting> We are working on nfs-as-a-data-source and would like to know if the bp can be accepted in Mitaka? We really would like to push this feature in Mitaka.
14:05:10 <tmckay> oh, question for open discussion later, I tried to launch mapr cluster with a default template, and I got "clbd failed to start". Anybody here know why that might be?
14:05:16 <weiting> This is bp link: https://review.openstack.org/#/c/210839/
14:05:28 <tmckay> weiting, feature freeze is next week
14:05:35 <elmiko> weiting: the feature freeze for mitaka is less than a week away
14:05:36 <tmckay> code would have to be finished and reviewed
14:05:57 <elmiko> weiting: you could write to the dev mailing list to request an exception
14:06:11 <tmckay> elmiko, that is true, ++
14:07:25 <weiting> So sorry about that since we don't have enough resources to implement this feature and now we got the resource to do that.
14:07:36 <huichun> Working one EDP patches
14:07:41 <weiting> However, I will try to request an exception for this feature.
14:07:55 <crobertsrh> weiting:  I'll certainly be up for reviewing code it if makes it in.
14:07:56 <tmckay> weiting, what is your estimate on time to implement?
14:08:22 <elmiko> weiting: if you think it can be done before mitaka release, definitely post to the ML for an exception
14:08:44 <tmckay> weiting, the mitaka schedule is here
14:08:49 <weiting> After our review, almost all the implementation has been finished, but we need to implement some codes in UI side.
14:08:50 <tmckay> #link http://releases.openstack.org/mitaka/schedule.html
14:09:18 <vgridnev> huichun, hi. Can you explain reasons of your -1 on this change: https://review.openstack.org/#/c/276067/ ? Empty -1 makes me sad
14:10:09 <huichun> vgridnev:  VG sorry, my fault +1 I mean
14:13:29 <vgridnev> any news / updates?
14:14:41 <SergeyLukjanov> #topic Final Mitaka release for python-saharaclient
14:15:00 <SergeyLukjanov> so, we need to have  final release for the client asap
14:15:17 <tosky> is the plan still to deprecate the CLI clients in this cycle?
14:15:19 <elmiko> are there any pending reviews we need to address?
14:15:45 <tmckay> good question. We may also have to be lenient with CI :)
14:16:04 <tmckay> if all the tests pass in a composite of different tests on the same patch, I think we should workflow+1
14:16:35 <tmckay> although I guess we don't actually have to freeze until Wednesday
14:16:54 <SergeyLukjanov> we have to have client release for the horizon patches
14:17:02 <elmiko> even after we +W, it still has to pass CI once more before merge. so it should be ok, just check the failing CI logs to ensure that it's not a problem with the patch.
14:17:04 <vgridnev> health checks stuff was merged to client already
14:17:10 <SergeyLukjanov> so IMO we need client by end of this week
14:17:14 <tmckay> elmiko, ++
14:17:38 <elmiko> SergeyLukjanov: are there any high priority reviews we should know about?
14:17:56 <AndreyPavlov> i will send a small patch for CLI later today
14:18:19 <SergeyLukjanov> there are no open important reviews
14:18:45 <SergeyLukjanov> AndreyPavlov what kind of a patch? is it important for release?
14:20:11 <vgridnev> I guess no
14:20:19 <AndreyPavlov> SergeyLukjanov it's hard to say. it will not change existing behaviour
14:20:37 <SergeyLukjanov> so, probably we don't need to wait for it
14:20:46 <AndreyPavlov> ok then
14:20:48 <SergeyLukjanov> anything else to include into the final release?
14:21:02 <AndreyPavlov> there are two patches currently on review
14:21:03 <AndreyPavlov> https://review.openstack.org/#/c/218606/
14:21:16 <AndreyPavlov> this one should not be merged i guess
14:21:26 <AndreyPavlov> until resume feature
14:21:31 <SergeyLukjanov> agreee
14:21:42 <elmiko> +1
14:21:43 <AndreyPavlov> and this one https://review.openstack.org/#/c/268011
14:22:10 <AndreyPavlov> idk if it works or not, more like "nice to have"
14:22:28 <vgridnev> +1
14:22:37 <huichun> AndreyPavlov:  I will update this patch
14:22:42 <elmiko> AndreyPavlov: that second patch looks really nice, +1 to debug in tox =)
14:22:46 <tmckay> it would be very nice to have ... however, it's more a dev thing anyway, so if it's in master we can all benefit from it
14:23:02 <huichun> Seems merge conflict now
14:24:23 <tmckay> #link https://review.openstack.org/#/q/owner:tmckay%2540redhat.com+status:open
14:24:50 <tmckay> those are mine, I think they should all go in :) We could call them bugs
14:24:56 <SergeyLukjanov> re client release
14:25:03 <tmckay> missing default templates for spark 160, for sure
14:25:13 <tmckay> and deprecating spark 1
14:25:17 <SergeyLukjanov> I think there is no release blockers right now, so, I'm gonna submit release request by EOD
14:25:22 <vgridnev> tmckay, links seems to be unrelated for client
14:25:35 <tmckay> vgridnev, oh, sorry, I was talking general freeze
14:25:48 <SergeyLukjanov> it's a next topic tmckay  :)
14:25:54 <tmckay> heh, ok
14:26:20 <SergeyLukjanov> any objections on client release?
14:26:29 <tmckay> no
14:26:33 <AndreyPavlov> no
14:26:39 <vgridnev> no objections
14:26:58 <SergeyLukjanov> #topic M-3 & FF is coming, let's collect high prio reviews
14:27:33 <vgridnev> SergeyLukjanov, any etherpad for this?
14:27:42 <elmiko> vgridnev++
14:27:52 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-mitaka-ff
14:29:54 <tmckay> ok, I will add my earlier 3 related to spark. I think they are waiting just for CI
14:30:14 <vgridnev> I think that CDH 5.5 is the most important reviews, ambari scaling and ambari HA; health checks stuff. also tmckay's changes
14:30:56 <vgridnev> and probably we should enable ambari by default in this release
14:31:20 <tmckay> vgridnev, ++. cdh 5.5 review is big, I suggest we all download and actually try to run it
14:32:21 <elmiko> considering that the ambari plugin is new, maybe we should give it a cycle to settle in before we enable as default?
14:32:33 <elmiko> (i mean, we are merging it at the freeze basically)
14:33:30 <vgridnev> elmiko, it was added in the liberty, actually
14:33:45 <elmiko> ah, my mistake then
14:33:49 <tmckay> recent patches are improvements, I think, like scaling
14:33:59 <elmiko> fair, i withdraw my objection
14:34:03 <vgridnev> elmiko, also, current hdp is too outdated
14:34:10 <elmiko> vgridnev: +1 to that
14:34:12 <tosky> definitely outdated
14:34:26 <tosky> I didn't check recently, is the CI for Ambari more stable nowadays?
14:34:42 <tmckay> vgridnev, so do we just add ambari, or do we add ambari and make hdp not default?
14:34:53 <tmckay> I suppose it needs a deprecation for a cycle before that
14:35:00 <tosky> tmckay: they are separate plugins, covering different versions
14:35:07 <tmckay> fair enough
14:35:49 <vgridnev> tmckay, I think that we can make hdp 2.0.6 deprecated, and remove in begging of newton (is that a next cycle?)
14:35:51 <NikitaKonovalov> is there a way to gently say "please dont use old hdp, we want to drop it" ?
14:35:59 <elmiko> i'm +1 for making hdp non-default
14:36:11 <SergeyLukjanov> (folks, start adding prio reviews to the etherpad)
14:36:14 <tmckay> vgridnev, yep, newton. sounds good
14:36:16 <tosky> fine, but how to make it non-default?
14:36:30 <SergeyLukjanov> ++ for hdp 2.0.6 deprecation
14:36:33 <tosky> I mean, if you want to use >=2.3, you have no choice but use the new one
14:36:34 <elmiko> i can make a patch to the config options
14:36:42 <vgridnev> I am ok with making that non-default
14:36:51 <tmckay> tosky, good point. we could leave hdp until all the old releases drop off ....
14:36:53 <vgridnev> elmiko, I did one already
14:37:02 <tmckay> eventually, everything through 2.3 will be deprecated ...
14:37:03 <vgridnev> #link https://review.openstack.org/#/c/284719/
14:37:16 <elmiko> vgridnev: lol, i'm slow to day ;)
14:37:43 <elmiko> vgridnev: oh, i meant. i'll make a patch to remove hdp from default. if we are agreed about that?
14:38:12 <tmckay> hmm, maybe we want to do that in newton?
14:38:14 <tmckay> unsure
14:38:29 <tosky> at least we could move it at the end of the list, even if enabled by default
14:38:43 <elmiko> given the state of hdp, and if we are making ambari default, i don't see why not to remove it.
14:38:51 <tmckay> oh, is that list displayed in order, I never noticed
14:38:55 <tosky> it does not change anything, just looks... different
14:39:14 <tosky> maybe
14:39:28 <tmckay> elmiko, hmm, well, remove by default is not the same as deprecate,  you're right
14:39:44 <elmiko> the only people this will affect are those who using configuration files generated from the repo, probably not existing users.
14:39:48 <vgridnev> elmiko, +1. We can add to docs that hdp2.0.6 deprecated; if you need that please enable that in sahara.conf file
14:39:48 <elmiko> i think the impact is minimal
14:40:01 <crobertsrh> that sounds reasonable, +1
14:40:02 <elmiko> ok, i'll make a patch today
14:40:18 <tmckay> it would be people with a default setting for plugins, to be more precise
14:40:24 <elmiko> tmckay: right
14:40:41 <tmckay> alright, I'll give it a +2
14:40:55 <elmiko> maybe we should also generate a warning in the logs about hdp being deprecated?
14:40:56 <tmckay> elmiko, make sure to include a release note
14:41:05 <elmiko> tmckay: ack
14:41:28 <tmckay> elmiko, well, deprecation is different. 2.0.6 we can deprecate in newton, beyond that we'll have to decide
14:41:49 <tmckay> once all the versions supported by the plugin are deprecated, it can just disappear
14:42:08 <tmckay> it's slowly going EOL
14:42:36 <elmiko> right, i was just thinking about a warning. no worries
14:42:39 <tosky> (it's just one version)
14:43:05 <elmiko> yeah, i'll put the patch up and we can debate there ;)
14:43:10 <tmckay> warning may not be bad, if we know what the deprecation plan is
14:43:15 <tmckay> ++
14:47:35 <elmiko> can we talk api v2 for a minute?
14:48:24 <vgridnev> SergeyLukjanov, ?
14:48:33 <SergeyLukjanov> #topic API v2 progress
14:48:37 <elmiko> \o/
14:48:44 <elmiko> #link https://review.openstack.org/#/c/273316/
14:48:47 <huichun> elmiko: API V2 time
14:48:48 <elmiko> i would like to get that merged
14:48:51 <SergeyLukjanov> sorry, I've digged too deep into the reviews :)
14:48:54 <elmiko> haha
14:49:10 <crobertsrh> bah, I keep forgetting to look at them
14:49:13 <elmiko> please, if people could review that. it does not affect sahara at all in the default deployment
14:49:25 <elmiko> but, it does allow me to start pushing more apiv2 patches
14:49:35 <elmiko> i don't think these should be affected by the feature freeze
14:49:53 <elmiko> and i *really* don't want this patch to languish till after the mitaka release
14:50:18 <elmiko> i've also added many more items to the work list at
14:50:19 <elmiko> #link https://wiki.openstack.org/wiki/Sahara/api-v2
14:50:55 <vgridnev> elmiko, +2'ed
14:51:08 <elmiko> are there any objections to getting the base of the v2 api in before we release mitaka?
14:51:12 <tmckay> ++, I think we should merge this week, for sure
14:51:20 <elmiko> thanks guys
14:51:27 * tmckay checks if he still has a +2
14:51:44 * tmckay he does!
14:52:02 <tmckay> vgridnev, do you want to workflow, or should I ;-)
14:52:53 <elmiko> ok, that was all i wanted to bring up. thanks everyone!
14:53:12 <vgridnev> tmckay, I guess SergeyLukjanov can do so
14:53:26 <tmckay> lol, yes. but will he? ;-)
14:54:26 <esikachev> SergeyLukjanov: next topic?
14:54:40 <SergeyLukjanov> #topic Open discussion
14:54:48 <esikachev> (
14:54:55 <SergeyLukjanov> we have only 5 mins left, sorry
14:55:05 <esikachev> okay
14:55:23 <elmiko> esikachev: did you want to talk about the scenario test stuff?
14:55:27 <tmckay> okay, mapr cluster, "clbd failed to start". Anybody know how to fix this?  Must just be a setting, I think, but I used default template
14:55:53 <esikachev> elmiko: in spec i am spoke about releases of sahara-tests, all features for it implemented. what did you think about it?
14:56:19 <vgridnev> tmckay, I tried to bring maps folks to irc, but still can't see them in here
14:56:33 <tmckay> vgridnev, thanks
14:56:36 <vgridnev> maps -> mapr
14:56:45 <tosky> I thought we were going to keep it branchless like tempest; on the other side, tempest does some release (for example before dropping the support for some openstack release)
14:56:46 <elmiko> esikachev: i think it sounded good on my first read, but i need to re-review it
14:56:53 <tosky> what do you mean here by releases of sahara-tests?
14:57:02 <elmiko> (i am not a tempest expert though, by any means)
14:57:45 <esikachev> elmiko: in sahara-tests only scenario framework
14:57:51 <esikachev> niw
14:57:54 <esikachev> now
14:58:10 <tosky> my question still is valid :)
14:58:46 <elmiko> 2 min, then we should take this to #openstack-sahara
14:59:01 <tmckay> oh, open discussion, I had a crazy idea I'll mention here. What about a Manila driver/plugin that makes swift look like an nfs share?
14:59:02 <esikachev> we can discuss on next meeting
14:59:09 <elmiko> k
14:59:09 <esikachev> about scenario tests
14:59:13 <tmckay> elmiko, then we wouldn't need any credentials at all ^^
14:59:29 <tmckay> kind of roundabout, but then again, we are trying to cross from hadoop-land into openstack land
14:59:47 <elmiko> tmckay: certainly sounds attractive, if not cumbersome (requires operator to install yet another openstack service)
14:59:48 <tmckay> manila would handle acls the way it does now
14:59:54 <tosky> tmckay: ask manila people if it makes sense
15:00:04 <tmckay> yeah, just thought of it yesterday
15:00:15 <huichun> vgridnev:  updated sorry for wrong click I mean +1 original
15:00:19 <elmiko> we should take this to -sahara
15:00:25 <tmckay> elmiko, then we could make manila the premier file store for sahara
15:00:28 <SergeyLukjanov> #endmeeting