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 <xar...@gmail.com> wrote: > [from another thread] > On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky <ikalnit...@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 <ada...@mirantis.com> wrote: > > Answers inline. > > > > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L <e...@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-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > -- > > Andrey Danin > > ada...@mirantis.com > > skype: gcon.monolake > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev