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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
