Open Stack

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 <eli at 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 <ikalnitsky at 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 <eli at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland