[openstack-dev] [Fuel] Modularization activity POC

Mike Scherbakov mscherbakov at mirantis.com
Wed Oct 21 06:01:36 UTC 2015


Thanks Eugene. I'd recommend to start integration as early as possible...

On Tue, Oct 20, 2015 at 2:11 AM Evgeniy L <eli at mirantis.com> wrote:

> Hi Mike,
>
> 1. our plan is to have working partitioning/provisioning in a couple of
> weeks,
>     networking is more complicated and it's better to ask Vladimir/Ryan.
> 2, 3. here we have just some general ideas, we should have independent
> releases on pypi,
>     each component should have responsible person (team), the same way we
> do it for fuel-plugin-builder
>     and fuelclient. The same applies to independent docker containers.
> Another thing is how
>     we are going to combine it in ready to use tool, there are several
> ways, if we drop containers,
>     those will be just rpm/deb packages and dependencies between them, if
> we continue using
>     docker containers, the simplest and the most robust way is to build a
> single container which
>     has everything user needs.
>
> Regarding the spec our plan is to start writing spec after we have working
> POC.
>
> Thanks,
>
>
> On Tue, Oct 20, 2015 at 4:43 AM, Mike Scherbakov <mscherbakov at mirantis.com
> > wrote:
>
>> This is great start, Evgeny.
>> I have a few questions:
>>
>>    1. When do you expect to have POC to show?
>>    2. Do you plan to put new services into separate repos?
>>    3. How do you plan to package those - will you create RPM package for
>>    each, as well as Docker container (as we have everything in containers on
>>    Fuel master node)
>>
>> These questions, of course, should be covered in spec - so may be I
>> should just wait for you guys to create specs. I just think that it's very
>> important to think about integration from the very beginning.
>>
>> Thanks,
>>
>> On Mon, Oct 19, 2015 at 8:54 AM Igor Kalnitsky <ikalnitsky at mirantis.com>
>> wrote:
>>
>>> Hey Evgeniy.
>>>
>>> This is awesome news1 I believe that microservices is way to go.
>>> Despite the fact that them bring a set of classical problems (e.g.
>>> duplication of domain entities) we will win more than loose. :)
>>>
>>> If there will be any specs or design meetings, please send me invite -
>>> I'd gladly join discussions.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>>
>>>
>>> On Wed, Oct 14, 2015 at 5:30 PM, Evgeniy L <eli at mirantis.com> wrote:
>>> > Hi,
>>> >
>>> > We are starting Fuel modularization POC activity which is basically in
>>> one
>>> > sentence
>>> > can be explained as "Use Fuel without Fuel", it means that we want to
>>> > provide
>>> > for a user a way to use some good things from Fuel, without entire
>>> master
>>> > node and
>>> > other parts which user doesn't need.
>>> >
>>> > Currently we have monolithic system which includes every aspect of
>>> > deployment
>>> > logic, those components tightly coupled together, and there are few
>>> persons
>>> > who understand all the interactions between components.
>>> >
>>> > As a result of modularization we will get the next benefits:
>>> > 1. reusability of components
>>> > 1.1. it will lead to more components consumers (users)
>>> > 1.2. better integration with the community (some community projects
>>> might
>>> >        be interested in using some parts of Fuel)
>>> > 2. components decoupling will lead to clear interfaces between
>>> components
>>> > 2.1. so it will be easier to replace some component
>>> > 2.2. it will be easier to split the work between teams and it will help
>>> > scale teams in
>>> >        a much more efficient way
>>> >
>>> > Here are some thing which naturally can be used separately:
>>> > * network configuration (is a part of POC)
>>> > * advanced partitioning/provisioning (is a part of POC)
>>> > * discovery mechanism (ironic-inspector?)
>>> > * power management (ironic?)
>>> > * network verification
>>> > * diagnostic snapshot
>>> > * etc
>>> >
>>> > The main purpose of POC is to try to make partly working system to
>>> figure
>>> > out the
>>> > scope of work which we will have to do upstream in order to make it
>>> > production ready.
>>> >
>>> > Here are few basic component-specific ideas:
>>> >
>>> > Advanced partitioning/provisioning
>>> > * split provisioning into two independent actions partitioning and
>>> > provisioning
>>> >   (currently we have a single call which does partitioning,
>>> provisioning,
>>> >    post provisioning configuration)
>>> > * figure out the data format (currently it's too Fuel and Cobbler
>>> specific)
>>> >
>>> > Network configuration
>>> > * CRUD api on any entity in the system (in Fuel not all of the data are
>>> > exposed via api,
>>> >   so user has to go and edit entries in db manually)
>>> > * no constraints regarding to network topology (in Fuel there are a
>>> lot of
>>> > hardcoded
>>> >   assumptions)
>>> >
>>> > Node hardware discovery
>>> > * should be able to support different source drivers at the same time
>>> >    (csv file, fuel-nailgun-agent, CMDB, dhcp, cobbler etc)
>>> > * versioning of HW information (required for life cycle management)
>>> > * notification about changes in hardware or about node statuses
>>> >   (required for life cycle management)
>>> >
>>> > Common requirements for components:
>>> > * every component must follow OpenStack coding standards when
>>> >   we start working upstream after POC (so there shouldn't be a question
>>> >   what to use pecan of flask)
>>> > * Fuel specific interfaces should be implemented as drivers
>>> > * this one is obvious, but currently one of the most problematic parts
>>> in
>>> > Fuel,
>>> >   HW gets changed, interface can be replaced, disk can be removed,
>>> >   component should have a way to handle it
>>> >
>>> > Technically speaking, we want to have separate services for every
>>> component,
>>> > it is one of the technical ways to force components to have clear
>>> > interfaces.
>>> >
>>> > Other architecture decision which we want to try to solve is
>>> extendability,
>>> > currently we have a problem that all of the logic which is related to
>>> > deployment
>>> > data is hardcoded in Nailgun. Plugins should be able to retrieve any
>>> data it
>>> > needs from the system, in order to perform plugin deployment, these
>>> data
>>> > should
>>> > be retrieved using some interface, and we already have interface where
>>> we
>>> > can
>>> > provide stability and versioning, it's REST API. So basically
>>> deployment
>>> > should
>>> > consist of two steps first is to retrieve all required data from any
>>> source
>>> > it needs,
>>> > and after that send data to the nodes and start deployment.
>>> >
>>> > If you have any questions/suggestion don't hesitate to ask.
>>> >
>>> > Thanks,
>>> >
>>> >
>>> __________________________________________________________________________
>>> > 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
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> __________________________________________________________________________
>> 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
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/e685148d/attachment.html>


More information about the OpenStack-dev mailing list