Open Stack

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 <matt at redhat.com> wrote:
> On 05/29/2014 07:23 AM, Alexander Ignatov wrote:
>>
>> On 28 May 2014, at 20:02, Sergey Lukjanov <slukjanov at mirantis.com> 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
> 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.