<div dir="ltr">Hi Andrew,<div><br></div><div>What you described is exactly what we were going to do [1],</div><div>and everybody understand all of the cons which you described.</div><div>Also if you take a look at the blueprint it's not about plugins at all.</div><div>Scope of improvements was reduced for the current release and</div><div>"Role as a plugin" was postponed.</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin">https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin</a></div><div>[2] <a href="https://blueprints.launchpad.net/fuel/+spec/blank-role-node">https://blueprints.launchpad.net/fuel/+spec/blank-role-node</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 11:17 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[from another thread]<br>
On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
><br>
> Guys,<br>
><br>
> We want to introduce an "empty role" as a basis for plugins. For<br>
> instance, the user select nodes, assign empty role and names it<br>
> somehow like "CONTRAIL". In this step, vanilla fuel will just<br>
> provision a node (since it's an empty role) and the plugin (in post<br>
> hooks) can select all empty roles with <a href="http://node.name" target="_blank">node.name</a> == "CONTRAIL" and<br>
> deploy some stuff on that node.<br>
><br>
> Obviously, it's hackish. But it's a simple approach that requires a<br>
> minimum time. In future, we'll introduce pluggable roles, but that's<br>
> another story.<br>
<br>
<br>
So far from the review we simply added an role with a base OS, this<br>
provides a nearly useless experience for plugin developers. This is<br>
heavy on hacking even for plugin-devs<br>
<br>
issues:<br>
1) you get one role<br>
2) you have to come up with some random way to identify nodes from<br>
each other if you do. We can't set hostname, and <a href="http://node.name" target="_blank">node.name</a> in the<br>
nailgun is never in astute.yaml (which is a tech debt that we have<br>
code to fix)<br>
3) disk layout is fixed, and uselessly small, plugin-author will have<br>
a lot of rework to do here<br>
4) multiple plugins that need roles will effectively fight with each other<br>
<br>
We can add roles in the releases API as it is, a plugin should be able<br>
to leverage this, the only gap currently is [1] which is not an API<br>
currently (new from granular deployments).<br>
<br>
Because of this, it would be more useful to just call these API's<br>
during installing the plugin. Worse case, the plugin author can do<br>
this themselves if we add the install_script support [2]<br>
<br>
[1] <a href="https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py" target="_blank">https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py</a><br>
[2] <a href="https://review.openstack.org/#/c/137301/" target="_blank">https://review.openstack.org/#/c/137301/</a><br>
<div><div class="h5"><br>
On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin <<a href="mailto:adanin@mirantis.com">adanin@mirantis.com</a>> wrote:<br>
> Answers inline.<br>
><br>
> On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Empty role is ready [1], thanks to granular deployment feature<br>
>> I didn't have to hardcode some hacks in Astute again.<br>
>><br>
>> But there are several things which I want to mention/discuss:<br>
>><br>
>> 1. in the patch you can see the name of the role and its description<br>
>>     I would like to ask you to verify it and provide some other options if<br>
>> you<br>
>>     have any<br>
>> 2. we have a minor problem with the progress bar, we will figure out how<br>
>>     to fix it in Astute with Vladimir S.<br>
>> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific<br>
>> and it<br>
>>     doesn't allow us to make efficient partitioning schema, e.g. it means<br>
>> that we<br>
>>     cannot allocate root partition for all of the disks (provisioning will<br>
>> fail), the<br>
>>     current workaround is to allocate root partition with minimal size<br>
>>     (about 15G) and leave the rest of the space as is (unallocated). As<br>
>>     far as I can see from the bug it's not so easy to fix the problem,<br>
>> actually<br>
>>     image based provisioning fixes the problem, but it's not an option for<br>
>> the<br>
>>     current release. Maybe you have some other ideas how to fix this<br>
>> problem?<br>
>><br>
> I would leave it as is - 15 GB. A user or plugin can adjust it for its<br>
> needs.<br>
><br>
>><br>
>> Thanks,<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/147230/" target="_blank">https://review.openstack.org/#/c/147230/</a><br>
>> [2] <a href="https://bugs.launchpad.net/fuel/+bug/1278964" target="_blank">https://bugs.launchpad.net/fuel/+bug/1278964</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Andrey Danin<br>
> <a href="mailto:adanin@mirantis.com">adanin@mirantis.com</a><br>
> skype: gcon.monolake<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Andrew<br>
Mirantis<br>
Ceph community<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>