Open Stack

> client

We have separated launchpad project for client and we're publishing
client releases to it.

> extra

I'm neutral about moving job examples and API samples between sahara and extra

> ui tests

if we'll be able to remove sahara-dashboard before good integration
tests for our pages will be done in horizon than we could move them to
the extra repo as a temporary place, but sahara is the wrong place for
ui test due to different layers.

On Thu, May 29, 2014 at 5:59 PM, Trevor McKay <tmckay at redhat.com> wrote:
> below, sahara-extra
>
> On Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov 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.
>>
>> > 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?
>>
>> > 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.
>>
>> > sahara-extra
>>
>> Keep it as is, no need to stop releasing, because we're not publishing
>> anything to pypi. No real need for tags.
>
> Even if we keep the repo for now, I think we could simplify a little
> bit.  The edp-examples could be moved to the Sahara repo.  Some of those
> examples we use in the integration tests anyway -- why have them
> duplicated?
>
>>
>>
>> > 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.
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.