Open Stack

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