<div dir="ltr">Hello to All.<div><br></div><div>See inline comments.</div><div><br></div><div>Kind regards,</div><div>Denys Makogon</div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-24 23:55 GMT+03:00 Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin.lu@huawei.com" target="_blank">hongbin.lu@huawei.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-CA" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:#1f497d">Hi all,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">At the last team meeting, we tried to define the scope of the Higgins project. In general, we agreed to focus on the following features as an initial start:<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Build a container abstraction and use docker as the first implementation.<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Focus on basic container operations (i.e. CRUD), and leave advanced operations (i.e. keep container alive, rolling upgrade, etc.) to users or other projects/services.<u></u><u></u></span></p>
<p><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Start with non-nested container use cases (e.g. containers on physical hosts), and revisit nested container use cases (e.g. containers on VMs) later.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">The items below needs further discussion so I started this ML to discuss it.<u></u><u></u></span></p>
<p><u></u><span style="color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Container composition: implement a docker compose like feature</span></p></div></div></blockquote><div><br></div><div>In Docker-compose, at this point of time i'm working to extracting core functionality into something similar to libcompose (written on Go) but with Python API.</div><div>I can tell that it is not that fast, so that work would take some time (couple releases). My suggestion is to implement abstraction layer that will consume your own implementation of compose features and once docker-compose will be ready to be consumed then in Higgins we will switch to it.</div><div><br></div><div>Another thing, it is worth considering to use TOSCA modeling (see how Tacker is doing it) for container orchestration.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-CA" link="blue" vlink="purple"><div><p><span style="color:#1f497d"><u></u><u></u></span></p>
<p><u></u><span style="color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Container host management: abstract container host<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">For #1, it seems we broadly agreed that this is a useful feature. The argument is where this feature belongs to. Some people think this feature belongs to other projects, such as Heat, and others think it belongs
to Higgins so we should implement it. For #2, we were mainly debating two things: where the container hosts come from (provisioned by Nova or provided by operators); should we expose host management APIs to end-users? Thoughts?</span></p></div></div></blockquote><div><br></div><div>Here's what i think, if we would take a look at Solum that uses swarm cluster API endpoint that defined in its config, so for me, as for operator it is not that useful.</div><div><br></div><div>As first step, we can live with that, but when you would think of multisite OpenStack containers orchestration that case wouldn't work at all. As proposal, i'd like to see special DB model that represents swarm cluster entity (all necessary creds to connect to it: TLS certs, user/password, endpoint, etc.) and provide advanced placement algorithm that would help to define where should container lay or let users to pick concrete swarm cluster to deploy their container.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-CA" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Best regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Hongbin<u></u><u></u></span></p>
</div>
</div>
<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></div>