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