Open Stack

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 <eli at 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 <
> azvyagintsev at 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 <
>> tnapierala at 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 <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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> ---
>> Best regards,
>>    Aleksey Zvyagintsev
>>
>> __________________________________________________________________________
>> 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
>
>


-- 
---
Best regards,
   Aleksey Zvyagintsev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151229/c0277f3d/attachment.html>