Open Stack

On 28 May 2014, at 20:02, Sergey Lukjanov <slukjanov at mirantis.com> wrote:

> Hey folks,
> 
> it's a small wrap-up for the topic "Sahara subprojects releasing and
> versioning" that was discussed partially on summit and requires some
> more discussions. You can find details in [0].
> 
>> common
> 
> We'll include only one tarball for sahara to the release launchpad
> pages. All other links will be provided in docs.

+1. And keep python-saharaclient on the corresponding launchpad page.

> 
>> sahara-dashboard
> 
> The merging to Horizon process is now in progress. We've decided that
> j1 is the deadline for merging main code parts and during the j2 all
> the code should be merged into Horizon, so, if in time of j2 we'll
> have some work on merging sahara-dashboard to Horizon not done we'll
> need to fallback to the separated sahara-dashboard repo release for
> Juno cycle and continue merging the code into the Horizon to be able
> to completely kill sahara-dashboard repo in K release.
> 
> Where we should keep our UI integration tests?

Once sahara-dashboard code is not merged to Horizon we could keep 
integration tests in the same repo. Once dashboard code is merged we
could keep tests in sahara-extra repo. AFAIR we have plans to convert
our UI tests to Horizon-capable tests with mocked rest calls. So we could
keep non-converted UI tests in sahara-extra until they are done.

> 
>> sahara-image-elements
> 
> We're agreed that some common parts should be merged into the
> diskimage-builder repo (like java support, ssh, etc.). The main issue
> of keeping -image-elements separated is how to release them and
> provide mapping sahara version - elements version. You can find
> different options in etherpad [0], I'll write here about the option
> that I think will work best for us.
> 
> So, the idea is that sahara-image-elements is a bunch of scripts and
> tools for building images for Sahara. It's high coupled with plugins's
> code in Sahara, so, we need to align them good. Current default
> decision is to keep aligned versioning like 2014.1 and etc. It'll be
> discussed on the weekly irc team meeting May 29.

I vote to keep sahara-image-elements as separate repo and release it
as you Sergey propose. I see problems with sahara-ci when running all bunch 
of integration tests for checking image-elements and core sahara code
on each patch sent to sahara repo in case of collapsed two repos.

> 
>> sahara-extra
> 
> Keep it as is, no need to stop releasing, because we're not publishing
> anything to pypi. No real need for tags.

+1. Also I think we can move our rest-api-samples from sahara to sahara-extra
repo as well.
> 
> 
>> open questions
> 
> If you have any objections for this model, please, share your thoughts
> before June 3 due to the Juno-1 (June 12) to have enough time to apply
> selected approach.
> 
> [0] https://etherpad.openstack.org/p/juno-summit-sahara-relmngmt-backward
> 
> Thanks.
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev