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