Open Stack

On 05/28/2014 12:02 PM, 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.

safe to assume this is in addition to the client tarball?


>> 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.

we really need to kill sahara-dashboard before the juno release


> Where we should keep our UI integration tests?

ideally w/ the code it tests, so horizon. are there problems w/ that 
approach?

as a fallback they can go into the sahara repo


>> 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 for merging sahara-image-elements into the sahara repo and 
keeping the strategic direction that common-enough elements get pushed 
to diskimage-builder


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

we still need to figure out the examples and swift plugin, but seems 
reasonable to punt that from the juno cycle if there is no bandwidth


>> 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

so ideal situation imho -

  . sahara (includes image elements and possibly ui tests)
  . python-saharaclient (as before)
  . sahara-extra (handle later)
  . horizon (everything that was in sahara-dashboard)

this misses the puppet modules. possibly they should also be merged into 
the sahara repo.

best,


matt