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 <m...@redhat.com> wrote: > On 05/29/2014 07:23 AM, Alexander Ignatov wrote: >> >> On 28 May 2014, at 20:02, Sergey Lukjanov <slukja...@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@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
