In general - fuel-bootstrap improvements (actually- fuel-agent manager and utils) So, looks like no option for 9.0 - we will work with fuel-agent, and then with porting(re-writing) it to bareon.
On Tue, Dec 29, 2015 at 1:09 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi Aleksey, > > Since Fuel's FF is on 2nd of March, I don't think that full switch from > fuel-agent + nailgun volume manager to Bareon will happen. > Also Bareon will have separate from Fuel release cycle, so you will have > to land the feature first into Bareon and then to Fuel. > > Could you please provide a bit more information on what features are > needed in the agent for 9.0 Fuel release? > > Thanks, > > On Tue, Dec 29, 2015 at 1:38 PM, Aleksey Zvyagintsev < > azvyagint...@mirantis.com> wrote: > >> >> Guys, do you have any plans to achieve integration for fuel9\fuel-next >> ?(and final switching from fuel-agent to BareOn will be...?) >> We are going to implement some new features for fuel - and the main >> question should we push it into fuel-agent or in newer BareOn? >> >> >> On Mon, Dec 28, 2015 at 11:56 PM, Tomasz Napierala < >> tnapier...@mirantis.com> wrote: >> >>> I agree with Evgeny: from work organization it would more optimal to >>> have 2 repos. API and system facing programming are completely different >>> domains, requiring different skill sets. In my opinion separation would >>> lower the entry barriers. >>> >>> Regards, >>> >>> > On 17 Dec 2015, at 15:53, Evgeniy L <e...@mirantis.com> wrote: >>> > >>> > Hi Igor, >>> > >>> > Bareon by itself doesn't have any REST interface, Bareon is basically >>> fuel_agent, >>> > which is framework + CLI wrapper to use it as an agent. >>> > In order to store and edit required entities in the database we need >>> some wrapper, >>> > which adds this functionality. This simple wrapper will be implemented >>> in Bareon-API. >>> > User should be able to use Bareon without any additional API/Database >>> if she/he >>> > wants to do some basic stuff without need to store the configuration, >>> which is not >>> > Fuel use case. >>> > If the question was specifically about Bareon-API in separate repo, >>> there is no >>> > reason to store it in a single repo, since we may have separate teams >>> working >>> > on those sub-projects and those solve a bit different problems, user >>> facing api >>> > vs low level tools. >>> > >>> > Thanks, >>> > >>> > On Thu, Dec 17, 2015 at 5:33 PM, Igor Kalnitsky < >>> ikalnit...@mirantis.com> wrote: >>> > > create Bareon-API repository, and start production ready >>> implementation >>> > >>> > For what reason do we need a separate repo? I thought API will be a >>> > part of bareon repo. Or bareon is just a provisioning agent, which >>> > will be driven by bareon-api? >>> > >>> > On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L <e...@mirantis.com> wrote: >>> > > Hi, >>> > > >>> > > Some time ago, we’ve started a discussion [0] about Fuel >>> modularisation >>> > > activity. >>> > > Due to unexpected circumstances POC has been delayed. >>> > > >>> > > Regarding to partitioning/provisioning system, we have POC with a >>> demo [1] >>> > > (thanks to Sylwester), which shows how the integration of Fuel and >>> Bareon >>> > > [2] can >>> > > be done. >>> > > >>> > > To summarise the implementation: >>> > > * we have a simple implementation of Bareon-API [3], which stores >>> > > partitioning >>> > > related data and allows to edit it >>> > > * for Nailgun new extension has been implemented [4], which uses >>> Bareon-API >>> > > to store partitioning information, so we will be able to easily >>> switch >>> > > between >>> > > classic volume_manager implementation and Bareon-API extension >>> > > * when provisioning gets started, extensions retrieves the data from >>> > > Bareon-API >>> > > >>> > > Next steps: >>> > > * create Bareon-API repository, and start production ready >>> implementation >>> > > * create a spec for Fuel project >>> > > * create a spec for Bareon project >>> > > >>> > > If you have any questions don’t hesitate to ask them in this thread, >>> also >>> > > you can >>> > > find us on #openstack-bareon channel. >>> > > >>> > > Thanks! >>> > > >>> > > [0] >>> > > >>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html >>> > > [1] https://www.youtube.com/watch?v=GTJM8i7DL0w >>> > > [2] >>> > > >>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html >>> > > [3] https://github.com/Mirantis/bareon-api >>> > > [4] https://review.openstack.org/#/c/250864/ >>> > > >>> > > >>> > > >>> __________________________________________________________________________ >>> > > 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 >>> >>> -- >>> Tomasz 'Zen' Napierala >>> Product Engineering - Poland >>> >>> >>> >>> >>> >>> >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >> >> >> >> -- >> --- >> Best regards, >> Aleksey Zvyagintsev >> >> __________________________________________________________________________ >> 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 > > -- --- Best regards, Aleksey Zvyagintsev
__________________________________________________________________________ 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