Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151229/c5739315/attachment.html>