On 28 May 2014, at 20:02, Sergey Lukjanov <slukja...@mirantis.com> 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. +1. And keep python-saharaclient on the corresponding launchpad page. > >> 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. > > Where we should keep our UI integration tests? Once sahara-dashboard code is not merged to Horizon we could keep integration tests in the same repo. Once dashboard code is merged we could keep tests in sahara-extra repo. AFAIR we have plans to convert our UI tests to Horizon-capable tests with mocked rest calls. So we could keep non-converted UI tests in sahara-extra until they are done. > >> 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. > >> sahara-extra > > Keep it as is, no need to stop releasing, because we're not publishing > anything to pypi. No real need for tags. +1. Also I think we can move our rest-api-samples from sahara to sahara-extra repo as well. > > >> 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 > > Thanks. > > -- > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev