[openstack-dev] [Fuel] Empty role - status
Andrew Woodward
xarses at gmail.com
Thu Jan 15 20:17:53 UTC 2015
[from another thread]
On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky <ikalnitsky at mirantis.com> wrote:
>
> Guys,
>
> We want to introduce an "empty role" as a basis for plugins. For
> instance, the user select nodes, assign empty role and names it
> somehow like "CONTRAIL". In this step, vanilla fuel will just
> provision a node (since it's an empty role) and the plugin (in post
> hooks) can select all empty roles with node.name == "CONTRAIL" and
> deploy some stuff on that node.
>
> Obviously, it's hackish. But it's a simple approach that requires a
> minimum time. In future, we'll introduce pluggable roles, but that's
> another story.
So far from the review we simply added an role with a base OS, this
provides a nearly useless experience for plugin developers. This is
heavy on hacking even for plugin-devs
issues:
1) you get one role
2) you have to come up with some random way to identify nodes from
each other if you do. We can't set hostname, and node.name in the
nailgun is never in astute.yaml (which is a tech debt that we have
code to fix)
3) disk layout is fixed, and uselessly small, plugin-author will have
a lot of rework to do here
4) multiple plugins that need roles will effectively fight with each other
We can add roles in the releases API as it is, a plugin should be able
to leverage this, the only gap currently is [1] which is not an API
currently (new from granular deployments).
Because of this, it would be more useful to just call these API's
during installing the plugin. Worse case, the plugin author can do
this themselves if we add the install_script support [2]
[1] https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py
[2] https://review.openstack.org/#/c/137301/
On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin <adanin at mirantis.com> wrote:
> Answers inline.
>
> On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <eli at mirantis.com> wrote:
>>
>> Hi,
>>
>> Empty role is ready [1], thanks to granular deployment feature
>> I didn't have to hardcode some hacks in Astute again.
>>
>> But there are several things which I want to mention/discuss:
>>
>> 1. in the patch you can see the name of the role and its description
>> I would like to ask you to verify it and provide some other options if
>> you
>> have any
>> 2. we have a minor problem with the progress bar, we will figure out how
>> to fix it in Astute with Vladimir S.
>> 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
>> and it
>> doesn't allow us to make efficient partitioning schema, e.g. it means
>> that we
>> cannot allocate root partition for all of the disks (provisioning will
>> fail), the
>> current workaround is to allocate root partition with minimal size
>> (about 15G) and leave the rest of the space as is (unallocated). As
>> far as I can see from the bug it's not so easy to fix the problem,
>> actually
>> image based provisioning fixes the problem, but it's not an option for
>> the
>> current release. Maybe you have some other ideas how to fix this
>> problem?
>>
> I would leave it as is - 15 GB. A user or plugin can adjust it for its
> needs.
>
>>
>> Thanks,
>>
>> [1] https://review.openstack.org/#/c/147230/
>> [2] https://bugs.launchpad.net/fuel/+bug/1278964
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> Andrey Danin
> adanin at mirantis.com
> skype: gcon.monolake
>
> __________________________________________________________________________
> 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
>
--
Andrew
Mirantis
Ceph community
More information about the OpenStack-dev
mailing list