+1 For Evgeniy, Also guys, as you know - fuel-agent now uses for a lot of different things : IBP\bootstrap\ironic\disk_managment at many other. I hope you are not going to remove all this functionality with re-factoring process.
On Thu, Dec 17, 2015 at 4:53 PM, 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 > > -- --- 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