what were the bunch of issues you ran into? will you capture them in a
blueprint or bug so they can be resolved?
best,
matt
On 05/29/2014 10:03 AM, Sergey Lukjanov wrote:
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable diskimage-builder version
The dib is now published to pypi, so, we could make
sahara-image-elements in dib-style and publish it to pypi in the same
style. It makes us able to add some sanity tests for images checking
and add gate jobs for running them (it could be done anyway, but this
approach with separated repo looks more consistent). Developing
sahara-image-elements as a pip-installable project we could add
diskimage-builder to the requirements.txt of it and manage it's
version, it'll provide us good flexibility - for example, we'll be
able to specify to use "latest release dib".
- all scripts and dib will not be installed with sahara (50/50)
On Thu, May 29, 2014 at 3:57 PM, Matthew Farrellee <[email protected]> wrote:
On 05/29/2014 07:23 AM, Alexander Ignatov wrote:
On 28 May 2014, at 20:02, Sergey Lukjanov <[email protected]> wrote:
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.
this problem was raised during the design summit and i thought the
resolution was that the sahara-ci could be smart about which set of itests
it ran. for instance, a change in the elements would trigger image rebuild,
a change outside the elements would trigger service itests. a change that
covered both elements and the service could trigger all tests.
is that still possible?
best,
matt
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
