[openstack-dev] [sahara] summit wrap-up: subprojects

Matthew Farrellee matt at redhat.com
Thu May 29 14:30:11 UTC 2014


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




More information about the OpenStack-dev mailing list