-1 to make changes now +1 to Alexandra Let's finish fuel-client first. Also, it is about prioritization. We have many things to be resolved in 6.1 (e.g. package the rest of the stuff which not yet packaged into RPM/DEB; split repos openstack/fuel/linux, etc.), and fuel agent in particular has pretty low priority to me in 6.1.
In examples I have provided, which are essential for 6.1, we are experiencing lack of hands. Let's see if we can focus our work on those items and many other essential things, and come to this question later. On Mon, Jan 26, 2015 at 10:29 PM, Aleksandra Fedorova < afedor...@mirantis.com> wrote: > It seems that we have general agreement about the idea, but to make it > happen we need much more detailed proposal. > > Even with python-fuelclient it is not quite clear right now, which version > of nailgun should be used to test it, and the opposite: which version of > fuelclient we have to use in iso builds. We also don't handle it in the > build system very well right now, as we use git hashes, and not fixed > versions, or packages. > > Maybe we should complete the python-fuelclient transformation first and > see how it is going to work for us? > On Jan 26, 2015 8:59 PM, "Roman Prykhodchenko" <m...@romcheg.me> wrote: > >> Vladimir, >> >> As a fuel-separatist I give this initiative a big +1 because of the >> following advantages I can see: >> >> - Git is designed for keeping smaller single-compoent repos, keeping >> everything to one repo is a discouraged pattern >> - Having a separate -core group that will only contain active core >> reviewers for fuel-agent project so getting core-reviews will be easier. >> - It makes possible to re-use some of the existing jobs in OpenStack CI >> - Making independent releases becomes possible >> >> AFAIK fuel-agent is positioned as an independent provisioning tool which >> will not be exclusively used by Fuel. There is a work in progress to >> integrate it with Ironic. Integrating it to any other provisioning system >> should also be possible then. From that perspective putting it into its own >> repo also brings the following advantages: >> >> - Connecting 3rd party CI will be possible >> - Getting involved for the new folks will be much easier >> >> >> - romcheg >> >> >> > 26 січ. 2015 о 17:42 Vladimir Kozhukalov <vkozhuka...@mirantis.com> >> написав(ла): >> > >> > Fuelers, >> > >> > As most of you might know we have a bunch of projects inside fuel-web >> repo which are not directly related to Fuel Web application. Some of them >> are tested together and it seemed we could end up with a set of >> incompatibility issues if we separated them and stopped tracking their >> versions on the git level (instead of release level). >> > >> > Recent activities about separating Fuel Client from Nailgun (api) make >> me think we are mature enough to move all other not related project out of >> fuel-web repo and bring them together not earlier than on the stage of >> system/functional testing. >> > >> > Next step would be moving out Fuel Agent project. The reason is that it >> is independent and potentially could be used even out of Fuel because its >> data parsing mechanism is implemented so as to be agnostic to the data >> format. Some people could be potentially interested in using it >> independently with their own data format. It is tested together with other >> Fuel components during system testing only. >> > >> > >> > >> > Vladimir Kozhukalov >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Mike Scherbakov #mihgen
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev