Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
On Wed, Oct 21, 2015 at 1:21 PM, Igor Kalnitsky wrote: > We can make bidirectional dependencies, just like our deployment tasks do. I'm not sure that we are on the same page regarding problem definition. Imagine the case when we have environment with next set of roles: 1. standalone-rabbitmq 2. standalone-mysql 3. standalone-other-api things 4. compute - requires: controller > 1 5. cinder - requires: controller > 1 6. designate (whatever custom role) - requires: controller > 1 As you see - there is no controller anymore. And 1, 2, 3 developed by one guy, who knows that he need to overwrite requirements for 4,5, but he knows nothing about 6. At the same time developer of 6 role, obviously, knows nothing about standalone-* things. What options do we have here? __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (ikalnit...@mirantis.com) wrote: We can make bidirectional dependencies, just like our deployment tasks do. Just to make sure we are on the same page… We don’t want to be in a situation where a role needs to know about the its reverse dependencies. Dependencies are always expressed one direction. Right? And, btw, standalone-* roles may have a restriction that at least one node is required. I think it's ok for the plugin is case, since if you don't want to use it - just disable it. On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak wrote: > But it will lead to situations, when certain plugins, like > standalone_rabbitmq/standalone_mysql will need to overwrite settings on > *all* > dependent roles, and it might be a problem.. Because, how plugin developer > will be able to know what are those roles? > > On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky > wrote: >> >> Hi Dmitry, >> >> > Insert required metadata into roles that relies on another roles, for >> > compute it will be something like: >> > >> > compute: >> > requires: controller > 1 >> >> Yeah, that's actually what I was thinking about when I wrote: >> >> > Or should we improve it somehow so it would work for one nodes, >> > and will be ignored for others? >> >> So I'm +1 for extending our meta information with such dependencies. >> >> Sincerely, >> Igor >> >> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak >> wrote: >> > Hi, >> > >> >> Can we ignore the problem above and remove this limitation? Or should >> >> we improve it somehow so it would work for one nodes, and will be >> >> ignored for others? >> > >> > I think that this validation needs to be accomplished in a different >> > way, we >> > don't need 1 controller for the sake of 1 controller, >> > 1 controller is a dependency of compute/cinder/other roles. So from my >> > pov >> > there is atleast 2 options: >> > >> > 1. Use tasks dependencies, and prevent deployment in case if some tasks >> > relies on controller. >> > But the implementation might be complicated >> > >> > 2. Insert required metadata into roles that relies on another roles, for >> > compute it will be something like: >> > compute: >> > requires: controller > 1 >> > We actually have DSL for declaring such things, we just need to specify >> > this >> > requirements from other side. >> > >> > But in 2nd case we will still need to use tricks, like one provided by >> > Matt, >> > for certain plugins. So maybe we should spend time and do 1st. >> > >> > >> > __ >> > >> > 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 > > > > __ > 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 __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
We can make bidirectional dependencies, just like our deployment tasks do. And, btw, standalone-* roles may have a restriction that at least one node is required. I think it's ok for the plugin is case, since if you don't want to use it - just disable it. On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak wrote: > But it will lead to situations, when certain plugins, like > standalone_rabbitmq/standalone_mysql will need to overwrite settings on > *all* > dependent roles, and it might be a problem.. Because, how plugin developer > will be able to know what are those roles? > > On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky > wrote: >> >> Hi Dmitry, >> >> > Insert required metadata into roles that relies on another roles, for >> > compute it will be something like: >> > >> > compute: >> > requires: controller > 1 >> >> Yeah, that's actually what I was thinking about when I wrote: >> >> > Or should we improve it somehow so it would work for one nodes, >> > and will be ignored for others? >> >> So I'm +1 for extending our meta information with such dependencies. >> >> Sincerely, >> Igor >> >> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak >> wrote: >> > Hi, >> > >> >> Can we ignore the problem above and remove this limitation? Or should >> >> we improve it somehow so it would work for one nodes, and will be >> >> ignored for others? >> > >> > I think that this validation needs to be accomplished in a different >> > way, we >> > don't need 1 controller for the sake of 1 controller, >> > 1 controller is a dependency of compute/cinder/other roles. So from my >> > pov >> > there is atleast 2 options: >> > >> > 1. Use tasks dependencies, and prevent deployment in case if some tasks >> > relies on controller. >> > But the implementation might be complicated >> > >> > 2. Insert required metadata into roles that relies on another roles, for >> > compute it will be something like: >> >compute: >> > requires: controller > 1 >> > We actually have DSL for declaring such things, we just need to specify >> > this >> > requirements from other side. >> > >> > But in 2nd case we will still need to use tricks, like one provided by >> > Matt, >> > for certain plugins. So maybe we should spend time and do 1st. >> > >> > >> > __ >> > 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 > > > > __ > 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
But it will lead to situations, when certain plugins, like standalone_rabbitmq/standalone_mysql will need to overwrite settings on *all* dependent roles, and it might be a problem.. Because, how plugin developer will be able to know what are those roles? On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky wrote: > Hi Dmitry, > > > Insert required metadata into roles that relies on another roles, for > > compute it will be something like: > > > > compute: > > requires: controller > 1 > > Yeah, that's actually what I was thinking about when I wrote: > > > Or should we improve it somehow so it would work for one nodes, > > and will be ignored for others? > > So I'm +1 for extending our meta information with such dependencies. > > Sincerely, > Igor > > On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak > wrote: > > Hi, > > > >> Can we ignore the problem above and remove this limitation? Or should > >> we improve it somehow so it would work for one nodes, and will be > >> ignored for others? > > > > I think that this validation needs to be accomplished in a different > way, we > > don't need 1 controller for the sake of 1 controller, > > 1 controller is a dependency of compute/cinder/other roles. So from my > pov > > there is atleast 2 options: > > > > 1. Use tasks dependencies, and prevent deployment in case if some tasks > > relies on controller. > > But the implementation might be complicated > > > > 2. Insert required metadata into roles that relies on another roles, for > > compute it will be something like: > >compute: > > requires: controller > 1 > > We actually have DSL for declaring such things, we just need to specify > this > > requirements from other side. > > > > But in 2nd case we will still need to use tricks, like one provided by > Matt, > > for certain plugins. So maybe we should spend time and do 1st. > > > > > __ > > 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 > __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi Dmitry, > Insert required metadata into roles that relies on another roles, for > compute it will be something like: > > compute: > requires: controller > 1 Yeah, that's actually what I was thinking about when I wrote: > Or should we improve it somehow so it would work for one nodes, > and will be ignored for others? So I'm +1 for extending our meta information with such dependencies. Sincerely, Igor On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak wrote: > Hi, > >> Can we ignore the problem above and remove this limitation? Or should >> we improve it somehow so it would work for one nodes, and will be >> ignored for others? > > I think that this validation needs to be accomplished in a different way, we > don't need 1 controller for the sake of 1 controller, > 1 controller is a dependency of compute/cinder/other roles. So from my pov > there is atleast 2 options: > > 1. Use tasks dependencies, and prevent deployment in case if some tasks > relies on controller. > But the implementation might be complicated > > 2. Insert required metadata into roles that relies on another roles, for > compute it will be something like: >compute: > requires: controller > 1 > We actually have DSL for declaring such things, we just need to specify this > requirements from other side. > > But in 2nd case we will still need to use tricks, like one provided by Matt, > for certain plugins. So maybe we should spend time and do 1st. > > __ > 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi, Can we ignore the problem above and remove this limitation? Or should > we improve it somehow so it would work for one nodes, and will be > ignored for others? > I think that this validation needs to be accomplished in a different way, we don't need 1 controller for the sake of 1 controller, 1 controller is a dependency of compute/cinder/other roles. So from my pov there is atleast 2 options: 1. Use tasks dependencies, and prevent deployment in case if some tasks relies on controller. But the implementation might be complicated 2. Insert required metadata into roles that relies on another roles, for compute it will be something like: compute: requires: controller > 1 We actually have DSL for declaring such things, we just need to specify this requirements from other side. But in 2nd case we will still need to use tricks, like one provided by Matt, for certain plugins. So maybe we should spend time and do 1st. __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hey Mike, AFAIK, there's no bug/blueprint on LP. The question I want to raise here is what will happen if I decide to deploy a cluster with one compute without controllers? It looks like a bad UX to me, though it may increase speed of CI gates where one node with one role is enough. Can we ignore the problem above and remove this limitation? Or should we improve it somehow so it would work for one nodes, and will be ignored for others? Thanks, Igor On Wed, Oct 21, 2015 at 9:04 AM, Mike Scherbakov wrote: > Hi all, > is there a plan to remove this restriction permanently? Any bug/blueprint > covering it? > > On Tue, Oct 20, 2015 at 5:07 AM Patrick Petit wrote: >> >> Hi Matthew, >> >> That’s useful. >> Thanks >> >> On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) >> wrote: >> >> Hi Patrick, >> >> During the 7.0 development cycle we made a lot of enhancements to what >> environment characteristics can be modified through a plugin. One item that >> plugins cannot directly modify is the default Fuel roles and their metadata. >> That having been said, there is an open-ended post_install.sh script you can >> use for your plugin to "hack" this value. I know of one project that >> currently disables the requirement for controller role in a deployment. This >> may be helpful in testing a given standalone role that doesn't depend on a >> controller. >> >> Here's a link to the script: http://paste.openstack.org/show/476821/ >> Note that this doesn't reflect "enabled" status of a plugin. It will make >> controller min count 0 for all environments. That won't break them, but it >> just removes the restriction. >> >> Best Regards, >> Matthew Mosesohn >> >> On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov >> wrote: >>> >>> Hello folks, >>> >>> I second Patrick's idea. In our case we would like to install standalone >>> RabbitMQ cluster with Fuel reference architecture to perform destructive >>> tests on it. Requirement to install controller is an excessive burden in >>> that case. >>> >>> Thanks, >>> >>> Dmitry >>> >>> 2015-10-19 13:44 GMT+03:00 Patrick Petit : Hi There, There are situations where we’d like to deploy only Fuel plugins in an environment. That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools. Currently it’s not possible because you need to at least have one controller. What exactly is making that limitation? How hard would it be to have it removed? Thanks Patrick __ 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 >>> >> >> __ >> 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 > > -- > Mike Scherbakov > #mihgen > > __ > 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi all, is there a plan to remove this restriction permanently? Any bug/blueprint covering it? On Tue, Oct 20, 2015 at 5:07 AM Patrick Petit wrote: > Hi Matthew, > > That’s useful. > Thanks > > On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) > wrote: > > Hi Patrick, > > During the 7.0 development cycle we made a lot of enhancements to what > environment characteristics can be modified through a plugin. One item that > plugins cannot directly modify is the default Fuel roles and their > metadata. That having been said, there is an open-ended post_install.sh > script you can use for your plugin to "hack" this value. I know of one > project that currently disables the requirement for controller role in a > deployment. This may be helpful in testing a given standalone role that > doesn't depend on a controller. > > Here's a link to the script: http://paste.openstack.org/show/476821/ > Note that this doesn't reflect "enabled" status of a plugin. It will make > controller min count 0 for all environments. That won't break them, but it > just removes the restriction. > > Best Regards, > Matthew Mosesohn > > On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> Hello folks, >> >> I second Patrick's idea. In our case we would like to install standalone >> RabbitMQ cluster with Fuel reference architecture to perform destructive >> tests on it. Requirement to install controller is an excessive burden in >> that case. >> >> Thanks, >> >> Dmitry >> >> 2015-10-19 13:44 GMT+03:00 Patrick Petit : >> >>> Hi There, >>> >>> There are situations where we’d like to deploy only Fuel plugins in an >>> environment. >>> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA >>> tools. >>> Currently it’s not possible because you need to at least have one >>> controller. >>> What exactly is making that limitation? How hard would it be to have it >>> removed? >>> >>> Thanks >>> Patrick >>> >>> >>> __ >>> 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 >> >> > __ > 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 > -- Mike Scherbakov #mihgen __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi Matthew, That’s useful. Thanks On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) wrote: Hi Patrick, During the 7.0 development cycle we made a lot of enhancements to what environment characteristics can be modified through a plugin. One item that plugins cannot directly modify is the default Fuel roles and their metadata. That having been said, there is an open-ended post_install.sh script you can use for your plugin to "hack" this value. I know of one project that currently disables the requirement for controller role in a deployment. This may be helpful in testing a given standalone role that doesn't depend on a controller. Here's a link to the script: http://paste.openstack.org/show/476821/ Note that this doesn't reflect "enabled" status of a plugin. It will make controller min count 0 for all environments. That won't break them, but it just removes the restriction. Best Regards, Matthew Mosesohn On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov wrote: Hello folks, I second Patrick's idea. In our case we would like to install standalone RabbitMQ cluster with Fuel reference architecture to perform destructive tests on it. Requirement to install controller is an excessive burden in that case. Thanks, Dmitry 2015-10-19 13:44 GMT+03:00 Patrick Petit : Hi There, There are situations where we’d like to deploy only Fuel plugins in an environment. That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools. Currently it’s not possible because you need to at least have one controller. What exactly is making that limitation? How hard would it be to have it removed? Thanks Patrick __ 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 __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi Patrick, During the 7.0 development cycle we made a lot of enhancements to what environment characteristics can be modified through a plugin. One item that plugins cannot directly modify is the default Fuel roles and their metadata. That having been said, there is an open-ended post_install.sh script you can use for your plugin to "hack" this value. I know of one project that currently disables the requirement for controller role in a deployment. This may be helpful in testing a given standalone role that doesn't depend on a controller. Here's a link to the script: http://paste.openstack.org/show/476821/ Note that this doesn't reflect "enabled" status of a plugin. It will make controller min count 0 for all environments. That won't break them, but it just removes the restriction. Best Regards, Matthew Mosesohn On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov < dmescherya...@mirantis.com> wrote: > Hello folks, > > I second Patrick's idea. In our case we would like to install standalone > RabbitMQ cluster with Fuel reference architecture to perform destructive > tests on it. Requirement to install controller is an excessive burden in > that case. > > Thanks, > > Dmitry > > 2015-10-19 13:44 GMT+03:00 Patrick Petit : > >> Hi There, >> >> There are situations where we’d like to deploy only Fuel plugins in an >> environment. >> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA >> tools. >> Currently it’s not possible because you need to at least have one >> controller. >> What exactly is making that limitation? How hard would it be to have it >> removed? >> >> Thanks >> Patrick >> >> __ >> 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 > > __ 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
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hello folks, I second Patrick's idea. In our case we would like to install standalone RabbitMQ cluster with Fuel reference architecture to perform destructive tests on it. Requirement to install controller is an excessive burden in that case. Thanks, Dmitry 2015-10-19 13:44 GMT+03:00 Patrick Petit : > Hi There, > > There are situations where we’d like to deploy only Fuel plugins in an > environment. > That’s typically the case with Elasticsearch and InfluxDB plugins of LMA > tools. > Currently it’s not possible because you need to at least have one > controller. > What exactly is making that limitation? How hard would it be to have it > removed? > > Thanks > Patrick > > __ > 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
[openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi There, There are situations where we’d like to deploy only Fuel plugins in an environment. That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools. Currently it’s not possible because you need to at least have one controller. What exactly is making that limitation? How hard would it be to have it removed? Thanks Patrick__ 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
