18:00:32 <SergeyLukjanov> #startmeeting sahara
18:00:33 <openstack> Meeting started Thu Aug  6 18:00:32 2015 UTC and is due to finish in 60 minutes.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:36 <openstack> The meeting name has been set to 'sahara'
18:00:39 <SergeyLukjanov> let's wait for a few mins
18:00:47 <elmiko> cool
18:00:49 <huichun> hello
18:00:55 <alazarev> o/
18:01:03 <vgridnev> hi
18:01:03 <weiting> hello
18:02:28 <tosky> hi
18:02:42 <SergeyLukjanov> #topic sahara@horizon status (crobertsrh, NikitaKonovalov)
18:03:27 <crobertsrh> Not sure we're seeing any more attention from outside of sahara people, but I think our patches are in good shape to be reviewed
18:03:41 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon
18:03:42 <crobertsrh> *we* do need to be reviewing them though
18:04:12 <alazarev> as I see @vgridnev took my https://review.openstack.org/#/c/158918/
18:04:16 <crobertsrh> Even if you're not a "horizon guy", please take a peek at them.  Large parts of the code are very simple to understand.
18:04:21 <vgridnev> #agreed
18:04:28 <crobertsrh> the other parts are entirely incomprehensible.
18:04:31 <vgridnev> alazarev, yea
18:04:59 <SergeyLukjanov> and probably we should talk about getting at least one core in Horizon :)
18:05:28 <elmiko> SergeyLukjanov, +1
18:05:38 <crobertsrh> Or perhaps just start paying a core on the side to help us out.
18:05:43 <elmiko> haha
18:05:46 <SergeyLukjanov> yeah :)
18:06:00 <SergeyLukjanov> we have 1 or 2 in mirantis, there are some core guys from Red Hat
18:06:23 <SergeyLukjanov> we should probably be able to send some beer for reviews :)
18:06:32 <crobertsrh> for sure
18:06:44 <david-lyle> an update from the horizon side, I asked for reviews and shared the etherpad in the weekly meeting. I also explained the one core idea from Horizon's side.
18:06:46 <SergeyLukjanov> from my PoV one +2 is ~ 25% easier review workflow
18:07:01 <crobertsrh> In the meantime, if we can get 4 or 5 +1s on our stuff, that will add fuel when we ping the horizon cores
18:07:01 <SergeyLukjanov> david-lyle, thx!
18:07:10 <elmiko> david-lyle, what about using the cross-project liaison effort to shepherd the idea?
18:07:11 <david-lyle> so please keep your side on the reviews up and we should see things starting to move
18:07:23 <crobertsrh> awesome :)
18:07:32 <david-lyle> even if it's just me :)
18:07:55 <david-lyle> elmiko: to help promote reviews?
18:08:00 <SergeyLukjanov> david-lyle, probably we should have "official" "cores" for sahara part, like document that +1s from the list of guys should be used as a +2
18:08:05 <SergeyLukjanov> (one of +2s)
18:08:20 <elmiko> david-lyle, oh i meant more working towards another core (or something like it)
18:08:30 <SergeyLukjanov> david-lyle, have you seen how the core review workflow works in rally?
18:08:31 <crobertsrh> Maybe an upper case 1 rather than a lowercase 1
18:08:41 <elmiko> like an official sahara-horizon liaison
18:08:48 <SergeyLukjanov> elmiko, yup
18:09:02 <elmiko> maybe someone sassy like crobertsrh ;)
18:09:17 <david-lyle> sure, I assumed up to now crobertsrh was essentially that :)
18:09:22 <david-lyle> sassy
18:09:23 <crobertsrh> careful elmiko, he's a bit of a wild card
18:09:23 <SergeyLukjanov> in Rally, the +2 permissions granted to extended set of people (due to the gerrit limitations) that are asked to +2 only on their components
18:09:27 <david-lyle> I mean liaison
18:09:28 <elmiko> lol
18:09:56 <elmiko> david-lyle, well, he is sassy too >.<
18:10:10 <SergeyLukjanov> :)
18:10:22 <david-lyle> SergeyLukjanov: let me think about that one, I'm not immediately opposed
18:10:26 <SergeyLukjanov> NikitaKonovalov, ping, are you here? :)
18:10:57 <SergeyLukjanov> david-lyle, yeah, sure, it's a good option to think about, it already works very good in Rally
18:11:10 <SergeyLukjanov> folks, do we have something else to chat in this topic?
18:11:26 <crobertsrh> Nothing from me.
18:11:29 * david-lyle goes back to watching
18:11:36 <crobertsrh> thanks david-lyle
18:12:04 <SergeyLukjanov> let's move one
18:12:08 <SergeyLukjanov> david-lyle, thx!
18:12:16 <david-lyle> anytime
18:12:23 <SergeyLukjanov> #topic News / updates
18:13:13 <elmiko> working on the keystone update, think i've solved the issue with trusts. also closing in on the api v2 spec, i have a poc and some ideas but i'm not sure if folks will like my approach ;)
18:13:32 <vgridnev> worked with vanilla 2.7.1, patches on review:
18:13:36 <vgridnev> #link https://review.openstack.org/#/q/status:open+branch:master+topic:bp/support-vanilla-2-7-1,n,z
18:13:42 <apavlov> I've been working on implementation of shared across tenants and protected from updates resources
18:13:44 <huichun> working on add EDP detail error log info when job failed
18:13:49 <crobertsrh> Lots of interesting stuff around sahara + manila integration.  egafford, tmckay and I have a few patches up
18:15:10 <elmiko> oh also, we are getting very close to having an upstream castellan for integration. at which point i want to start pushing the patches for the improved secret storage
18:15:44 <alazarev> I'm finishing pending tasks on OpenStack (no more my patches on review), working on internal stuff
18:15:45 <huichun> elmiko: hi Michael, need your help on review on EDP patches
18:16:00 <huichun> https://review.openstack.org/#/c/182310/
18:16:10 <huichun> https://review.openstack.org/#/c/192097/
18:16:20 <huichun> https://review.openstack.org/#/c/201448/
18:16:46 <NikitaKonovalov> o/ actually not much updates from me as I've been busy with internal activities
18:16:49 <elmiko> huichun, i'll take a look today
18:16:54 <huichun> thanks
18:16:57 <elmiko> np
18:16:57 * tosky as well, internal stuff
18:18:38 <SergeyLukjanov> #topic Client release plans
18:18:53 <SergeyLukjanov> #link https://etherpad.openstack.org/p/sahara-liberty-client
18:19:26 <vgridnev> SergeyLukjanov, I believe that this change should be merged:
18:19:28 <vgridnev> #link https://review.openstack.org/#/c/193157/
18:19:50 <SergeyLukjanov> vgridnev, agree
18:19:59 <crobertsrh> Yes, it's certainly needed.
18:20:16 <SergeyLukjanov> I think we should have a first L cycle client release soon, like early next week
18:21:03 <SergeyLukjanov> crobertsrh, tmckay, elmiko, ping re client release
18:21:20 <SergeyLukjanov> vgridnev, please, add link to this CR to the etherpad
18:21:36 <elmiko> SergeyLukjanov, yup, i'll followup on those reviews
18:21:42 <crobertsrh> Yep
18:21:48 <vgridnev> SergeyLukjanov, ok, done
18:21:50 <SergeyLukjanov> any objection re release early next week?
18:21:56 <elmiko> none from me
18:22:04 <SergeyLukjanov> we could postpone if you expect some changes soon
18:22:13 <crobertsrh> No objection here.
18:22:25 <elmiko> nah, the only changes i want are future stuff that needs to be coded still ;)
18:22:32 <huichun> tmckay
18:22:45 <SergeyLukjanov> folks, please, review https://review.openstack.org/#/c/206124/
18:22:59 <elmiko> SergeyLukjanov, i am curious about our plans for releases in general for sahara after the L cycle
18:23:06 <SergeyLukjanov> elmiko, we'll definetly have at least one more client release
18:23:19 <SergeyLukjanov> elmiko, huge topic for the summit discussions
18:23:25 <elmiko> SergeyLukjanov, yea, definitely
18:23:45 <elmiko> i'm actually excited about moving about moving away from the 1,2,3 cycle release
18:23:55 <elmiko> i think we can get more done
18:24:02 <SergeyLukjanov> due to the gov changes, it's now possible
18:24:05 <elmiko> yea
18:24:12 <elmiko> that's what i'm curious about =)
18:24:16 <SergeyLukjanov> elmiko, the issue is that which verion of OSt should be supported
18:24:27 <elmiko> yea
18:24:33 <elmiko> that makes sense
18:25:12 <SergeyLukjanov> elmiko, if we're doing separated releases (like few times per half year cycle of the rest OSt) then we'll need to work on the latest *stable* OSt
18:25:26 <SergeyLukjanov> and dev new features only after the actual OSt release
18:25:35 <SergeyLukjanov> == + 2-3 month lag on features
18:25:45 <SergeyLukjanov> #agreed release client early next week
18:26:05 <elmiko> SergeyLukjanov, can't we keep a dev branch and a stable branch?
18:26:17 <elmiko> and release from stable branch
18:26:40 <SergeyLukjanov> elmiko, it will mean that we'll need to backport features, that's painful
18:26:50 <elmiko> mmm, good point
18:26:50 <SergeyLukjanov> but it's an option as well
18:27:00 * elmiko likes experimental code
18:27:07 * tosky does not :)
18:27:11 <elmiko> haha
18:27:26 <SergeyLukjanov> #topic Open discussion
18:27:33 <elmiko> but tosky, experimental means you don't have to test it ;)
18:27:38 <SergeyLukjanov> :)
18:27:41 <elmiko> i'd like to talk about api v2 for a minute
18:27:50 <tosky> (until it blows up later)
18:28:02 <elmiko> so, i have an idea about creating the v2 api in an experimental mode, as in not ready for production
18:28:07 <SergeyLukjanov> there is a workflow of developing new features in features branch for the not-yet-released OSt and then merging this feature branches
18:28:17 <SergeyLukjanov> but it's a very tricky flow as well :)
18:28:38 <elmiko> i'm curious if people have thoughts about keeping a v2 api in an experimental stage until we are ready to declare it stable?
18:28:59 <tosky> so that no one is allowed to use it?
18:29:02 <elmiko> SergeyLukjanov, yea, i get that. we don't have to push on that too hard if it's complicated.
18:29:16 <tosky> it would be interesting to know what ohter projects did in the past and try to align
18:29:41 <elmiko> tosky, well the idea would be that we declare it experimental, it would be in the codebase but advised not to use as it will akin to a 0.x.y version. meaning highly variable changes happening
18:30:02 <elmiko> maybe not even keep the saharaclient up to date with it until it is "ready"
18:30:27 <elmiko> what i'd like to do is introduce a v2 endpoint, with microversioning, then iterate upon that while we make changes to get it in shape
18:30:33 <tosky> I think it depends on the common expectation about API stability for projects: does always "published" mean "the contract with clients start here"?
18:31:11 <elmiko> this api would be explicitly marked as non-stable
18:31:16 <elmiko> initially
18:31:25 <tosky> remember that the baseline (basic 2.0 client) will always be supported, even if (to be checked) you deprecate some intermediate microversions
18:31:27 <elmiko> almost akin to how semver.org talks about a 0.x.y version api
18:31:46 <SergeyLukjanov> elmiko, it's a standard approach of adding new API version
18:31:48 <SergeyLukjanov> :)
18:32:18 <elmiko> tosky, i'm suggesting there would be no basic 2.0 client until we declare the v2 ready for it
18:32:26 <elmiko> SergeyLukjanov, ok, cool. so this isn't totally crazy ;)
18:33:23 <elmiko> so, for example, lets say that the v2 starts out at microversion 2.0.0
18:33:26 <SergeyLukjanov> elmiko, I mean the lifecycle is EXPERIMENTAL (not recommended for usage, could be changed significantly), STABLE (no backward compat breaking changes at all, recommended for usage) and DEPRECATED (not recommended for usage, still no backward compat breaking changes at all, mostly always it means that project is preparing for removal of this API version)
18:33:35 <tosky> oh, good to know
18:33:35 <SergeyLukjanov> and actually the last one is REMOVED
18:34:04 <elmiko> and we add a bunch of changes, while increasing the microversion, and we end up at 2.x.y as a happy endpoint for the conversion
18:34:17 <elmiko> then we declare that 2.x.y is the stable, and make a client based on that
18:34:22 <elmiko> then we release the v2 api
18:34:26 <tosky> if it's experimental, I guess you don't need microversioning
18:34:46 <tosky> only from the STABLE status onwards you need them
18:34:49 <SergeyLukjanov> elmiko, I'm not sure that we even really need to increase microversions for the eperimental API
18:34:54 <elmiko> not needed, but i'd like them in there to keep track of how we are advancing the api. also because i think we should use them once it goes stable.
18:34:54 <SergeyLukjanov> tosky ++
18:35:09 <elmiko> fair points
18:35:35 <SergeyLukjanov> I think it's even bad to use microversions for exp. - it'll slow down changes :)
18:35:39 <elmiko> i think it will help for the development process though, as we will need to make many small changes to get the api in shape for stable
18:35:50 <elmiko> SergeyLukjanov, how so?
18:36:18 <SergeyLukjanov> elmiko, (internal feeling)
18:36:25 <tosky> you don't really want garbage running around in STABLE
18:36:26 <SergeyLukjanov> elmiko, not really the technical issue
18:36:39 <elmiko> ok, i can accept that =)
18:36:50 <elmiko> tosky, not sure i follow
18:37:10 <tosky> a STABLE API is the starting point, the development process that lead to that API does not need to be kept around
18:38:17 <elmiko> that's a good point, i see this more as a way for us to track the evolution as it may take 6months to a year to fully implement the v2
18:38:32 <tosky> there is always git for that
18:39:04 <elmiko> true, but i still don't see how bumping microversions takes away from the dev effort. it's just a simple way to confirm the status of an api
18:39:57 <tosky> microversions are a way to introduce (small) API breakages on stable API. If you don't have a stable API, you don't have the problem they are supposed to solve
18:39:57 <elmiko> although i can see how it might things slightly confusing for several developers to coordinate if they have to manage the microversion bumping
18:40:04 <SergeyLukjanov> random bad idea - as an option the 2.dev.666 format could be used and then dropped with a stable release
18:40:19 <elmiko> SergeyLukjanov, i like that bad idea =)
18:40:48 <SergeyLukjanov> elmiko, you've just found the technical thing that will slow down changes ;)
18:40:59 <elmiko> haha, true
18:41:53 <elmiko> my feeling is that it will help to develop the tooling and rigor around using the microversions
18:42:07 <vgridnev> what we are going to do with Hadoop v1 ?
18:42:18 <elmiko> but i acknowledge that it may not be strictly necessary, and could introduce some slowness to development
18:42:54 <SergeyLukjanov> vgridnev, I think we agreed that there is a spec per dropped plugin needed
18:43:09 <SergeyLukjanov> and everyone was mostly ok with dropping H1
18:43:11 <elmiko> tosky, SergeyLukjanov, thanks for talking it through with me =)
18:43:12 <tosky> I thought that the spec was out, but needed few tunings
18:43:21 <tosky> (for removing hadoop1)
18:44:45 <NikitaKonovalov> there is a spec and I need make some corrections there
18:45:46 <NikitaKonovalov> I want to finish it actually asap and finally remove Hadoop v1 as it annoyingly appears to often in the dropdown when creating templates
18:45:56 <NikitaKonovalov> sometimes it simply causes missclicks
18:48:04 <apavlov> There were a lot of talks about PATCH calls implementation in further pathes and replacement current PUT calls with PATCH,  but did we came to a some kind of conclusion about what we should do not in v2 but now. What i got is that we will not touch existing PUT calls, but will we add PATCH for new ones?
18:48:34 <elmiko> apavlov, i agree with that
18:48:43 <elmiko> PATCH for new calls, no touching the older PUT calls
18:49:44 <crobertsrh> Sounds like a plan, +1
18:49:48 <elmiko> an interesting thought about this would be to add the PATCH calls for the PUTs we currently have. allow both to exist in v1.1, but refer to the PATCH calls in the api-ref docs
18:50:09 <elmiko> also, we are missing WADLs for the job binary updates and data source updates
18:50:24 <elmiko> and the scaling operation is wrongly listed as POST
18:50:38 <elmiko> #link https://review.openstack.org/#/c/209542/
18:54:08 <SergeyLukjanov> anything else to chat?
18:54:23 <crobertsrh> I can't think of anything.
18:54:58 <SergeyLukjanov> okay, thank you folks!
18:55:02 <SergeyLukjanov> have a good rest of day
18:55:12 <elmiko> thanks SergeyLukjanov
18:55:28 <SergeyLukjanov> #endmeeting