18:00:07 <vgridnev> #startmeeting sahara
18:00:08 <openstack> Meeting started Thu Apr 14 18:00:07 2016 UTC and is due to finish in 60 minutes.  The chair is vgridnev. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <openstack> The meeting name has been set to 'sahara'
18:00:25 <vgridnev> #link https://wiki.openstack.org/wiki/Meetings/SaharaAgenda
18:00:35 <vgridnev> let's wait a little
18:00:41 <vgridnev> hi folks!
18:00:45 <NikitaKonovalov_> o/
18:00:53 <mionkin> hi
18:00:59 <huichun> hi
18:01:28 <egafford> o/
18:01:30 <esikachev> hi
18:01:51 <tosky> hi
18:02:46 <vgridnev> #topic News / Updates
18:02:58 <vgridnev> anything new folks?
18:03:12 <vgridnev> First release of sahara-tests is done!
18:03:19 <egafford> \o/
18:03:20 <tosky> and a bugfix will be out shortly :)
18:03:28 <tosky> (it does not work when pip-installed)
18:03:33 <tosky> working on it, both esikachev and me
18:04:02 <esikachev> try fix sahara-ci(migrate on heat-neutron)
18:04:29 <vgridnev> also I'm doing some research in ambari, also busy with some internal things
18:05:41 <mionkin> I've added patch to sahara about migration from keystoneclient to keystoneauth and now i'm researching about how to proprerly use keystone v3 instead of v2
18:05:47 <NikitaKonovalov_> I've updated slides for the summit talk. finally
18:06:10 <egafford> Mostly summit prep for EDP and image gen here too.
18:06:12 <huichun> Working on work flow engine research, will raise some specs in sahara
18:07:00 <vgridnev> huichun, please add this for discussion topics for summit
18:07:53 <vgridnev> #topic API v2 progress
18:08:22 <egafford> I think elmiko's trapped in a giant all-day meeting.
18:08:32 <vgridnev> ok then
18:08:40 <vgridnev> #topic Newton summit topics and schedule preparing (vgridnev, NikitaKonovalov)
18:09:00 <vgridnev> #link https://etherpad.openstack.org/p/sahara-newton-summit
18:09:01 <huichun> vgridnev: due to cost control I have no chance to attend this summit  so I think I will talk with you guys in meetings later
18:09:19 <egafford> But the initial v2 module is in master now. :)
18:10:53 <vgridnev> so, initial schedule is posted, we need to fill that up
18:11:18 <vgridnev> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091778.html
18:11:49 <vgridnev> I will starting filling that up with my ideas regarding plugins / API / stuff shortly
18:12:40 <vgridnev> huichun, I think that it doesn't matter. If you will not attend the summit, folks will discuss the topics and will prepare useful feedback
18:13:28 <egafford> huichun: Anything that you add for EDP we'll be sure to get in. :) Please note anything you like on the main etherpad, on the EDP etherpad, or to me personally.
18:13:37 <vgridnev> based on this topics we understand our goals about EDP mechanism / Jobs for the Newton cycle, it's too important for us
18:14:51 <vgridnev> egafford do you have wishes regarding the schedule
18:14:54 <vgridnev> ?
18:15:08 <vgridnev> #link https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Sahara%3A
18:15:21 <huichun> vgridnev: OK
18:15:48 <egafford> The schedule looks completely sane to me; I'm prepping the EDP and image gen sessions actively from currently registered blueprints, as well as hopes and dreams carried over from past summits. :)
18:16:28 <egafford> SergeyLukjanov's notion to make EDP subcomponents more pluggable (job types, data sources, etc.) seems particularly important to me, EDP-wise.
18:16:58 <vgridnev> egafford, I think that simplifying image building is the most important thing for us, since number of supported versions for plugins are growing from release to release
18:17:06 <egafford> It's hard to extend Sahara right now, and extensibility is key.
18:17:08 <egafford> I agree.
18:17:38 <egafford> Image building is crazy. I have a plan, and this cycle seems to be the time to do it.
18:18:21 <egafford> And agreed that our current and future matrix can't support our current image gen strategy.
18:19:37 <huichun> vgridnev: agree ， For example CDH plugin grows from version to version , it"s big effort to maintaine
18:19:42 <egafford> Creating a unified logic for CLI image packing, image validation, and clean image preparation will help us enormously.
18:20:26 <egafford> Right now we're maintaining the same logic in many places for each plugin.
18:20:51 <vgridnev> and also, we should think about detachment of plugins with sahara. and how it will work with EDP.
18:20:59 <egafford> Yup.
18:21:19 <egafford> And to detach plugins from Sahara, we need to pull image-gen into them for it to make sense.
18:22:03 <NikitaKonovalov_> egafford, so it looks like image building will just become a part of the plugin interface, like edp engine
18:22:33 <egafford> I think EDP should *mostly* be ok, we just need to be cleaner about expressing job types, data sources, etc. through standardized interfaces and having a cleaner process by which plugins can register which (data sources, job types, etc.) they support.
18:22:40 <egafford> NikitaKonovalov: That's the notion.
18:23:04 <egafford> The dream is that there's an API which allows the user to click a UI button, spawn a nova build env, pack an image, and register it to Glance.
18:23:30 <egafford> This was my push to start that: https://blueprints.launchpad.net/sahara/+spec/validate-image-spi
18:23:56 <egafford> Got the main module in this cycle; hoped to get some recipes in, but then I lost about half the cycle to illness. This cycle, though. :)
18:25:39 <egafford> A number of other as-a-service components of OpenStack are wrestling very actively with image generation problems, so if we can solve this problem well, we might be doing OpenStack as a whole a big favor.
18:26:52 * egafford is done ranting about image gen for now, unless others have things they'd like to say about it. ;)
18:28:37 <vgridnev> ok, seems that we will finalise the schedule at the next meeting, I will post additional mail to ML about feedback regarding the current one.
18:29:02 <egafford> +1. Seems to me like the session layout itself is perfect, and fits our concerns well.
18:29:12 <vgridnev> is there something additional that we should discuss?
18:29:59 <vgridnev> #topic Open discussion
18:30:15 <tosky> on sahara-tests, I have a proposal
18:30:55 <tosky> the dependencies of the repository are not many and we are not definitely using bleeding edge features from, for example, the clients
18:31:27 <tosky> so I would propose to disable the automatic sync from global requirements,
18:31:42 <tosky> so that we can more easily allow sahara-tests to run on all supported branches with the requirements for those branches
18:32:10 <vgridnev> tosky, how tempest manages requirements updates?
18:32:15 <tosky> there are already few repositories which disabled the automatic sync of global requirements (and they are managing them directly), like aodh and gnocchi
18:33:03 <tosky> vgridnev: tempest bumps requirements and the main developers thinks it should be used for git
18:33:27 <tosky> but this makes the file of packages more complicated, and I personally disagree with that specific decision
18:34:23 <tosky> for example, in RDO people are trying to keep tempest (and soon sahara-tests) in sync with latest versions also for the stable branches, so if the dependencies are bumped, there is some work to do to patch them/fix them for the older versions
18:35:23 <vgridnev> I fully ok with disabling requirements updates, actually. The only thing, I think that we should review our requirements before each release in such case
18:35:32 <tosky> sure
18:35:38 <tosky> just in case they don't conflict
18:35:40 <tosky> I agree
18:36:24 <vgridnev> Uh, also. I wanted to say that we should bring more attention to adding release notes
18:36:51 <NikitaKonovalov_> what about new client releases. Those are supposed to be backward compatible. So there should be no issues in using latest versions.
18:37:02 <vgridnev> I will create some rules regarding that, and will post that to our docs, and to ML
18:37:08 <egafford> vgridnev: Is there a document in devref?
18:37:13 <egafford> vgridnev: Heh; +1.
18:37:32 <NikitaKonovalov_> I dont say we need to bump them every now and then, but it would be great to have latest clients update at leas once in a release
18:37:47 <vgridnev> actually our release notes for Mitaka are sad
18:37:50 <vgridnev> #link http://docs.openstack.org/releasenotes/sahara/mitaka.html
18:38:12 <tosky> NikitaKonovalov_: but this is only about the required dependencies for sahara-tests; of course, when you build your stack of packages for Newton, you will have the latest client
18:38:45 <tosky> NikitaKonovalov_: and the gate for Newton will test with lastest client, while the gates for Mitaka and Liberty will test with the respective older versions of the clients
18:38:48 <tosky> nothing more :)
18:39:04 <NikitaKonovalov_> tosky: ok, then I see no more issues there
18:39:06 <egafford> vgridnev: Yeah, if we can get a doc up, we can make sure all the cores know not to +A anything (that meets the criteria) that doesn't have release notes.
18:39:24 <egafford> Really, not to +2 such things either.
18:40:28 <tosky> every feature and relevant bug, a release note
18:41:05 <tosky> I would say: no release note for regression in non-released version (so that the issue will never be visible to people using stable versions)
18:41:50 <egafford> Sure. If we want any criteria for the format and structure of release notes, though, we should document that so we can check it.
18:42:03 <tosky> reno has already a good documentation
18:42:12 <tosky> if you create a new release notes, a template is populated
18:42:13 <egafford> tosky: Ok, fair.
18:42:15 <tosky> release note*
18:45:06 <vgridnev> is there anything additional that we should discuss?
18:47:12 <vgridnev> ok, seems that can finish the meeting
18:47:17 <vgridnev> thanks, folks!
18:47:19 <egafford> o/
18:47:37 <vgridnev> #endmeeting