Open Stack

Hi Andrew,

What you described is exactly what we were going to do [1],
and everybody understand all of the cons which you described.
Also if you take a look at the blueprint it's not about plugins at all.
Scope of improvements was reduced for the current release and
"Role as a plugin" was postponed.

[1] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin
[2] https://blueprints.launchpad.net/fuel/+spec/blank-role-node

On Thu, Jan 15, 2015 at 11:17 PM, Andrew Woodward <xarses at gmail.com> wrote:

> [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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/3fed5e70/attachment.html>