18:00:23 #startmeeting sahara 18:00:24 Meeting started Thu Mar 17 18:00:23 2016 UTC and is due to finish in 60 minutes. The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:28 The meeting name has been set to 'sahara' 18:00:32 hi 18:00:33 o/ 18:00:33 hi 18:00:34 #link http://wiki.openstack.org/wiki/Meetings/SaharaAgenda 18:00:50 #topic News / updates 18:01:29 working almost on bug fixing and testing sahara, some internal stuff 18:01:40 hi, I've just finished support of usage hadoop swiftfs with Keystone API v3 by adding hadoop-openstack.jar into plugins images 18:01:42 worked on nightly jobs. Merged! :) 18:01:43 i'm mainly working on api v2, and a little on talk for summit. also, we have completed the bandit work and it is all green now =) 18:01:43 #info I'm stepping down as PTL, staying around w/ a project, always ready to help 18:01:56 Working on patch review and EDP 18:02:05 the RC1 will be today 18:02:15 updating my repos right now 18:02:23 * elmiko raises a glass to SergeyLukjanov ;) 18:02:54 thanks SergeyLukjanov ! 18:02:57 * SergeyLukjanov planning to have a beers in Austin ;) 18:03:03 +1 18:03:08 Thanks SergeyLukjanov 18:03:08 yes, right, thanks SergeyLukjanov 18:03:49 trying to migrate sahara tempest API tests to sahara-tests _with_ history 18:04:38 and also, I brought my candidacy for PTL role in Newton 18:04:42 #link https://review.openstack.org/#/c/293987/ 18:04:54 I've mostly been testing out the UI. I added myself to a couple bugs that I hope to fix soon. 18:05:02 vgridnev: +1, thanks! 18:05:08 great news vgridnev :) 18:05:29 Cong vgridnev ! 18:05:33 tosky no way to migrate with history actually ;) 18:05:45 SergeyLukjanov: I think it is 18:06:00 SergeyLukjanov: but let's talk later, if there are other topic 18:06:03 topics* 18:06:04 sure 18:06:11 let's move on? 18:07:20 I'd like to have a few mins to talk about Sahara input for the Community roadmap, if possible 18:07:42 #topic OpenStack Community Roadmap - Sahara info review (Carol Barrett) (I can only attend for the 1st 30 mins) 18:07:46 carolbarrett sure 18:07:49 thanks carolbarrett =) 18:07:59 Thanks Sergey 18:08:02 Link to the draft: https://docs.google.com/presentation/d/1CwHEYE1YDRoHIaFQjN2wwEnj5ZQEUkIsCJwl9NG-f0A/edit?usp=sharing 18:08:02 Link to roadmap published for Tokyo Summit: https://www.openstack.org/assets/tokyo-summit/OpenStack-Roadmap-Mitaka-Update.pptx 18:08:15 I'll start with a little background 18:08:23 carolbarrett sorry for the no replies from my sight... 18:08:29 #link https://docs.google.com/presentation/d/1CwHEYE1YDRoHIaFQjN2wwEnj5ZQEUkIsCJwl9NG-f0A/edit?usp=sharing 18:08:35 #link https://www.openstack.org/assets/tokyo-summit/OpenStack-Roadmap-Mitaka-Update.pptx 18:08:41 elmiko: Thanks! 18:09:23 I'm part of the Product Work Group. This team produces a couple of deliverables like User Stories to bring requirements from markets (like enterprise) into the community 18:09:55 As well as producing a multi-release roadmap that gets released ahead of Summits and updated after the Design Summit dust settles 18:10:08 we do this in collaboration with the OpenStack foundation 18:10:23 I was asked to reach out to you all and create a page on Sahara 18:10:29 \o/ 18:10:32 That's in the 1st link posted 18:10:41 carolbarrett thank you! 18:10:45 I like the slide for Sahara and the items seems to be correct (#1 link) 18:11:07 SergeyLukjanov: Thanks! Glad to hear that! 18:11:11 Yeah, the slide looks good 18:11:38 I could use a bit more info on a couple of these to be able to speak to them. 18:11:56 Nice slide carolbarrett 18:11:56 I looked in your specs, launchpad, etc to put this together. 18:12:21 Is there any other place that I could look to find the details on SPI method for example? 18:12:38 And pls - go ahead and edit the slide to improve the content! 18:13:07 Is there more we can say, directionally, about Ocata? 18:13:27 carolbarrett: in general, this is the documentation for our spi methods docs.openstack.org/developer/sahara/devref/plugin.spi.html 18:13:38 it's not very descriptive, but gives a developer eye view 18:13:38 elmiko: Thanks! 18:14:09 the method in question, i believe was the validate(cluster) 18:14:37 i think we have more info on the way images are validated, let me look 18:14:41 * elmiko rifles through links 18:15:13 http://specs.openstack.org/openstack/sahara-specs/specs/mitaka/validate-image-spi.html 18:15:22 elmiko, yeah, you are right, but I was not landed into Mitaka release, as far I know 18:15:22 that's the dirty details ;) 18:15:37 vgridnev: i might have the wrong method there 18:16:07 vgridnev: Can we verify whether it has landed in Mitaka? 18:16:12 o/ 18:16:22 And if it didn't land, should we push to Newton? 18:16:23 1min 18:17:16 seems it's on review: https://review.openstack.org/#/c/263424/ 18:17:17 This is the type of feedback I'm looking for, want to make sure that the info is accurate and covers the most siginificant new capabilities that were added in Mitaka 18:17:36 Yeah, I think that we should push that to the Newton release 18:17:57 vgridnev: will make the change 18:18:06 vgridnev: +1 18:18:20 what else do we need to change? 18:18:51 (no ideas from my side) 18:19:09 the mitaka portion looks ok to me 18:19:28 do we need to add any other deprecations? 18:19:31 I think no, but probably we should mention with MapR versions were removed 18:19:57 SergeyLukjanov: You think the slide calls out the top priorities for the project as you go into the Newton Design Sessions? 18:20:06 or just mention which are still there, MapR 500 and MapR 510 are still there 18:20:33 carolbarrett I think so 18:20:35 vgridnev: What do we need to change on the "Remove" entry under mitaka? 18:21:13 SergeyLukjanov: Are there any other ongoing or long term areas for enhancement or expansion that we would want to call out? 18:21:23 apiv2? 18:21:26 I would say all MapR plugin versions were removed except for 500 and 510 18:21:49 carolbarrett: we are currently working on a new version of our api, it definitely qualifies as long term ;) 18:22:07 This could be based upon changes in other OpenStack Proects, Big Tent direction, etc? 18:22:14 Modularity, scalability, etc? 18:22:19 elmiko yeah, I think v2 API could be added as on-going work for the next releases 18:22:32 carolbarrett ^^ 18:22:49 carolbarrett there is an often requested to support new plugins in old sahara releases 18:22:56 SergeyLukjanov: may I request EDP engine parts enhancement to be added in? 18:23:28 carolbarrett so we want to do something with it, but no clear plans yet. there is too high coupling between sahara and plugins to support moving them to previous releases 18:24:09 What's the right wording for the v2 API? Is it about enhancing existing APIs or developing new ones or compatibility, etc? 18:24:40 SergeyLukjanov: Understand the compatibility challenge.... 18:25:02 we can leave that out if you want 18:25:07 EDP log enhancement and Multiple EDP workflow support 18:25:16 sahara-tests separation appropriate? 18:25:38 what about the EDP engine ehancements - should we carry that over to Newton? If so, any specific focus of that work that we can highlight? 18:25:41 carolbarrett: v2 is about enhancing/rewriting portions of existing api, and improving developer experience 18:25:54 it is a major version bump 18:25:56 carolbarrett working on a new api that'll provide more clear and flexible endpoint for end users based on the existing one IMO 18:26:39 got it. 18:26:53 what about EDP engine suggestion? 18:26:59 carolbarrett: EDP log enhancement, we should add user friendly info to end user, and support multiple EDP workflow 18:28:20 huichun: Thanks 18:29:01 Good stuff! 18:29:01 carolbarrett anything else to discuss on this topic? 18:29:28 carolbarrett thx a lot, great job in putting this items together! 18:29:38 SergeyLukjanov: I think I got what I need. I'll update the slide and send a not on ML for any addl comments 18:29:58 SergeyLukjanov: Happy to help out, this is good stuff for our users and market! 18:29:59 +1, thanks carolbarrett ! 18:30:16 thanks for your help elmiko! 18:30:16 #topic API v2 progress 18:30:20 #link https://review.openstack.org/#/c/273316/ 18:30:20 hey 18:30:23 #link https://wiki.openstack.org/wiki/Sahara/api-v2 18:30:33 all the work items have been added to the wiki 18:30:46 i am currently working on writing the specs for some of the bigger foundational features 18:31:05 a couple of red hatters have signed on to work on portions of this as well 18:31:18 so, hopefully over the next few weeks we'll start to put some reviews up 18:31:34 but, these can all wait until after mitaka release is finalized and freeze is over 18:31:57 i think that's about it for current status, any questions? 18:32:33 elmiko cool, thx for the update! 18:32:42 #topic Scenario tests releases 18:32:42 =) 18:32:49 tosky, esikachev your turn 18:33:11 so 18:33:16 tosky: what about moving tempest? 18:33:26 tests) 18:33:28 I spoke with -infra, and they told me that a way is possible 18:34:16 the idea is: push the filtered changes to a clean (orphan) branch, merge it, and request a special ACL to be able to push a merge commit to gerrit for review 18:34:52 you can see how it would look like from the master branch here: https://github.com/ltoscano-rh/sahara-tests 18:35:10 after that the code is merged, we can move it around/add tempest plugin interface with no issues 18:35:24 tosky yeah, I think we can do it, I could help from infra root side 18:35:46 about the move itself, I'm pretty neutral 18:35:55 sreshetnyak was having some concerns AFAIK 18:35:58 ok, so I will recheck that it is working, and if you are fine, I will proceed with this 18:36:04 sure, which kind of concerns? 18:36:41 while waiting for concerns 18:36:47 tempest will (in the long run) keep only core parts and tests (mainly scenario) for core services 18:36:50 * tosky waits 18:36:53 tosky: what about release scenario framework and tempest tests? 18:37:01 esikachev tosky what are you guys thinking about release sahara-tests? 18:37:12 SergeyLukjanov: as I said, I'm fine with that 18:37:25 SergeyLukjanov: all ready from my side 18:37:32 we want release tempest tests with framework? 18:37:33 esikachev: did you try to pip install it? Does it work? 18:37:51 esikachev what's the release model, versioning, release criteria? 18:38:18 sreshetnyak: if they are part of sahara-tests, yes, tempest-like tests for API would be released as well 18:38:35 SergeyLukjanov: criteria: all tests for testing sahara-release merged 18:39:02 but if we keep the sahara-tests like tempest, so branchless and able to support all supported openstack releases, then it's not different from tempest "releases" 18:39:24 tosky: no, i am worked on nightly-jobs. but i tried it today 18:39:28 (users could always use the master, like for tempest) 18:39:29 *try 18:39:51 esikachev: oh, perfect; I think there could be some issues with some relative paths 18:40:13 at least that's the effect I've seen in a draft RPM package for sahara-tests 18:40:21 like this morning, and I couldn't investigate 18:40:52 so, can we have tempest tests for testing releases? 18:41:39 sreshetnyak: having tempest tests in sahara-tests instead of tempest is not different from the current situation, they are just in a different (but more proper) location 18:41:40 imho 18:41:43 tosky: tempest test for independent release? 18:42:07 huichun: what do you mean by independent release? 18:42:50 Current tempest is out of Sahara-tests, right? 18:43:40 tosky: what about packaging? we should pack only scenario framework? 18:43:58 tosky: AFAIK, we need a spec 18:44:11 huichun: current tempest tests are for API and are in tempest repo 18:44:34 sreshetnyak: why should we package only scenario frameworks? I think everything from that repo could be package 18:45:18 I mean, it's all like before, because sahara-tests (for previous discussions) is brancheless like tempest, but it is a better fit because 18:45:36 - it's a non-core project 18:45:54 - sahara-tests reviews do not require tempest core 18:46:07 esikachev: a spec for the move? 18:46:12 yes 18:46:45 SergeyLukjanov: what did you think?^^ 18:47:01 tosky: I don't see reasons for pack tempest tests. we don't have ability for installing all dependencies, like tempest 18:47:32 sreshetnyak: iirc there are no additional dependencies apart from tempest(.lib) itself 18:47:40 esikachev honestly don't have specific thoughts about move 18:48:22 sreshetnyak: and if you want to run the tests, you require tempest, so the dependencies come from tempest 18:48:32 tosky: ah, ok. I don't know it 18:48:58 sreshetnyak: what were talking about is this: http://docs.openstack.org/developer/tempest/plugin.html 18:49:27 sreshetnyak: it's the same mechanism we applied to python-saharaclient tests currently in sahara (sahara/tests/tempest/scenario/data_processing) 18:50:39 any questions? 18:51:07 I think it's now cleared out 18:51:16 tosky esikachev thx folks for driving the sahara-tests 18:51:20 #topic Newton summit topics 18:51:31 so, I've created the etherpad for it 18:51:33 #link https://etherpad.openstack.org/p/sahara-newton-summit 18:51:33 i added a bunch of stuff to the etherpad 18:51:41 just trying to suggest some things 18:51:45 please, start adding discussion topics to it 18:53:52 #topic Open discssion 18:53:55 I have a few discussion topics on deprecations, maybe 18:54:08 tmckay dump any ideas 18:54:09 1) depreate internal db for job binaries 18:54:19 it's better to have more topics than less ;) 18:54:24 tmckay ++ 18:54:45 we actually had someone asking about that last night 18:54:48 2) deprecate use_namespaces -- I've found 2 bugs with it already, maybe a 3rd (currently looking) and it seems very very fragile. problem is .... 18:55:05 with multi-tenant and many private networks that could overlap, is there another good solution? 18:55:14 like configure neutron to just handle it 18:55:53 so bug #1, frozen dict, it didn't work with spark/storm, #2 couldn't get routers, #3 on ubuntu right now I am dying on a pickle error 18:55:55 bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 - Assigned to MFauzilkamil Zainuddin (apogee) 18:56:05 and that's after going through the pain of setting up root-wrap 18:56:11 heh 18:56:16 thanks openstack 18:56:39 so, anyway, I'll add to the pad, but there's a summary 18:56:40 whoa, that was cool 18:56:53 bug #2 18:56:56 also, the old topic we always have -- make bug reporting better, and harvest job logs 18:57:08 sorry, just had to try 18:57:15 :) lol 18:57:53 elmiko, talking it over with someone today I realized that multiple private nets say on 192.168.x.y from a script to set up tenants would be ambiguous from the controller 18:57:58 hence the namespaces 18:58:07 that makes sense 18:58:22 i agree in general, though, we should have a session on deprecations 18:58:24 but there may be a way to shepherd around that, or at least make the stuff under the covers less complex / more robust 18:58:38 and everyone can bring their favorite thing to deprecate to that session ;) 18:58:53 hadoop .... just kidding :) spark ftw 18:58:57 :) 18:59:02 lol! 18:59:07 1 min left 18:59:39 elmiko, PTL? deprecate SergeyLukjanov ;-) 18:59:51 ;( 18:59:56 PTL HA? 19:00:02 ++ 19:00:09 SergeyLukjanov, you will be missed 19:00:10 #endmeeting