18:00:32 #startmeeting sahara 18:00:33 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:36 The meeting name has been set to 'sahara' 18:00:39 let's wait for a few mins 18:00:47 cool 18:00:49 hello 18:00:55 o/ 18:01:03 hi 18:01:03 hello 18:02:28 hi 18:02:42 #topic sahara@horizon status (crobertsrh, NikitaKonovalov) 18:03:27 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 #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon 18:03:42 *we* do need to be reviewing them though 18:04:12 as I see @vgridnev took my https://review.openstack.org/#/c/158918/ 18:04:16 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 #agreed 18:04:28 the other parts are entirely incomprehensible. 18:04:31 alazarev, yea 18:04:59 and probably we should talk about getting at least one core in Horizon :) 18:05:28 SergeyLukjanov, +1 18:05:38 Or perhaps just start paying a core on the side to help us out. 18:05:43 haha 18:05:46 yeah :) 18:06:00 we have 1 or 2 in mirantis, there are some core guys from Red Hat 18:06:23 we should probably be able to send some beer for reviews :) 18:06:32 for sure 18:06:44 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 from my PoV one +2 is ~ 25% easier review workflow 18:07:01 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 david-lyle, thx! 18:07:10 david-lyle, what about using the cross-project liaison effort to shepherd the idea? 18:07:11 so please keep your side on the reviews up and we should see things starting to move 18:07:23 awesome :) 18:07:32 even if it's just me :) 18:07:55 elmiko: to help promote reviews? 18:08:00 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 (one of +2s) 18:08:20 david-lyle, oh i meant more working towards another core (or something like it) 18:08:30 david-lyle, have you seen how the core review workflow works in rally? 18:08:31 Maybe an upper case 1 rather than a lowercase 1 18:08:41 like an official sahara-horizon liaison 18:08:48 elmiko, yup 18:09:02 maybe someone sassy like crobertsrh ;) 18:09:17 sure, I assumed up to now crobertsrh was essentially that :) 18:09:22 sassy 18:09:23 careful elmiko, he's a bit of a wild card 18:09:23 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 I mean liaison 18:09:28 lol 18:09:56 david-lyle, well, he is sassy too >.< 18:10:10 :) 18:10:22 SergeyLukjanov: let me think about that one, I'm not immediately opposed 18:10:26 NikitaKonovalov, ping, are you here? :) 18:10:57 david-lyle, yeah, sure, it's a good option to think about, it already works very good in Rally 18:11:10 folks, do we have something else to chat in this topic? 18:11:26 Nothing from me. 18:11:29 * david-lyle goes back to watching 18:11:36 thanks david-lyle 18:12:04 let's move one 18:12:08 david-lyle, thx! 18:12:16 anytime 18:12:23 #topic News / updates 18:13:13 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 worked with vanilla 2.7.1, patches on review: 18:13:36 #link https://review.openstack.org/#/q/status:open+branch:master+topic:bp/support-vanilla-2-7-1,n,z 18:13:42 I've been working on implementation of shared across tenants and protected from updates resources 18:13:44 working on add EDP detail error log info when job failed 18:13:49 Lots of interesting stuff around sahara + manila integration. egafford, tmckay and I have a few patches up 18:15:10 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 I'm finishing pending tasks on OpenStack (no more my patches on review), working on internal stuff 18:15:45 elmiko: hi Michael, need your help on review on EDP patches 18:16:00 https://review.openstack.org/#/c/182310/ 18:16:10 https://review.openstack.org/#/c/192097/ 18:16:20 https://review.openstack.org/#/c/201448/ 18:16:46 o/ actually not much updates from me as I've been busy with internal activities 18:16:49 huichun, i'll take a look today 18:16:54 thanks 18:16:57 np 18:16:57 * tosky as well, internal stuff 18:18:38 #topic Client release plans 18:18:53 #link https://etherpad.openstack.org/p/sahara-liberty-client 18:19:26 SergeyLukjanov, I believe that this change should be merged: 18:19:28 #link https://review.openstack.org/#/c/193157/ 18:19:50 vgridnev, agree 18:19:59 Yes, it's certainly needed. 18:20:16 I think we should have a first L cycle client release soon, like early next week 18:21:03 crobertsrh, tmckay, elmiko, ping re client release 18:21:20 vgridnev, please, add link to this CR to the etherpad 18:21:36 SergeyLukjanov, yup, i'll followup on those reviews 18:21:42 Yep 18:21:48 SergeyLukjanov, ok, done 18:21:50 any objection re release early next week? 18:21:56 none from me 18:22:04 we could postpone if you expect some changes soon 18:22:13 No objection here. 18:22:25 nah, the only changes i want are future stuff that needs to be coded still ;) 18:22:32 tmckay 18:22:45 folks, please, review https://review.openstack.org/#/c/206124/ 18:22:59 SergeyLukjanov, i am curious about our plans for releases in general for sahara after the L cycle 18:23:06 elmiko, we'll definetly have at least one more client release 18:23:19 elmiko, huge topic for the summit discussions 18:23:25 SergeyLukjanov, yea, definitely 18:23:45 i'm actually excited about moving about moving away from the 1,2,3 cycle release 18:23:55 i think we can get more done 18:24:02 due to the gov changes, it's now possible 18:24:05 yea 18:24:12 that's what i'm curious about =) 18:24:16 elmiko, the issue is that which verion of OSt should be supported 18:24:27 yea 18:24:33 that makes sense 18:25:12 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 and dev new features only after the actual OSt release 18:25:35 == + 2-3 month lag on features 18:25:45 #agreed release client early next week 18:26:05 SergeyLukjanov, can't we keep a dev branch and a stable branch? 18:26:17 and release from stable branch 18:26:40 elmiko, it will mean that we'll need to backport features, that's painful 18:26:50 mmm, good point 18:26:50 but it's an option as well 18:27:00 * elmiko likes experimental code 18:27:07 * tosky does not :) 18:27:11 haha 18:27:26 #topic Open discussion 18:27:33 but tosky, experimental means you don't have to test it ;) 18:27:38 :) 18:27:41 i'd like to talk about api v2 for a minute 18:27:50 (until it blows up later) 18:28:02 so, i have an idea about creating the v2 api in an experimental mode, as in not ready for production 18:28:07 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 but it's a very tricky flow as well :) 18:28:38 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 so that no one is allowed to use it? 18:29:02 SergeyLukjanov, yea, i get that. we don't have to push on that too hard if it's complicated. 18:29:16 it would be interesting to know what ohter projects did in the past and try to align 18:29:41 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 maybe not even keep the saharaclient up to date with it until it is "ready" 18:30:27 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 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 this api would be explicitly marked as non-stable 18:31:16 initially 18:31:25 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 almost akin to how semver.org talks about a 0.x.y version api 18:31:46 elmiko, it's a standard approach of adding new API version 18:31:48 :) 18:32:18 tosky, i'm suggesting there would be no basic 2.0 client until we declare the v2 ready for it 18:32:26 SergeyLukjanov, ok, cool. so this isn't totally crazy ;) 18:33:23 so, for example, lets say that the v2 starts out at microversion 2.0.0 18:33:26 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 oh, good to know 18:33:35 and actually the last one is REMOVED 18:34:04 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 then we declare that 2.x.y is the stable, and make a client based on that 18:34:22 then we release the v2 api 18:34:26 if it's experimental, I guess you don't need microversioning 18:34:46 only from the STABLE status onwards you need them 18:34:49 elmiko, I'm not sure that we even really need to increase microversions for the eperimental API 18:34:54 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 tosky ++ 18:35:09 fair points 18:35:35 I think it's even bad to use microversions for exp. - it'll slow down changes :) 18:35:39 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 SergeyLukjanov, how so? 18:36:18 elmiko, (internal feeling) 18:36:25 you don't really want garbage running around in STABLE 18:36:26 elmiko, not really the technical issue 18:36:39 ok, i can accept that =) 18:36:50 tosky, not sure i follow 18:37:10 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 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 there is always git for that 18:39:04 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 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 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 random bad idea - as an option the 2.dev.666 format could be used and then dropped with a stable release 18:40:19 SergeyLukjanov, i like that bad idea =) 18:40:48 elmiko, you've just found the technical thing that will slow down changes ;) 18:40:59 haha, true 18:41:53 my feeling is that it will help to develop the tooling and rigor around using the microversions 18:42:07 what we are going to do with Hadoop v1 ? 18:42:18 but i acknowledge that it may not be strictly necessary, and could introduce some slowness to development 18:42:54 vgridnev, I think we agreed that there is a spec per dropped plugin needed 18:43:09 and everyone was mostly ok with dropping H1 18:43:11 tosky, SergeyLukjanov, thanks for talking it through with me =) 18:43:12 I thought that the spec was out, but needed few tunings 18:43:21 (for removing hadoop1) 18:44:45 there is a spec and I need make some corrections there 18:45:46 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 sometimes it simply causes missclicks 18:48:04 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 apavlov, i agree with that 18:48:43 PATCH for new calls, no touching the older PUT calls 18:49:44 Sounds like a plan, +1 18:49:48 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 also, we are missing WADLs for the job binary updates and data source updates 18:50:24 and the scaling operation is wrongly listed as POST 18:50:38 #link https://review.openstack.org/#/c/209542/ 18:54:08 anything else to chat? 18:54:23 I can't think of anything. 18:54:58 okay, thank you folks! 18:55:02 have a good rest of day 18:55:12 thanks SergeyLukjanov 18:55:28 #endmeeting