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,
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
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.
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
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
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:
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:
>
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
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
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
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
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
12 matches
Mail list logo