2014/1/13 Clint Byrum :
> Excerpts from Nachi Ueno's message of 2014-01-13 10:35:07 -0800:
>> Hi Clint
>>
>> 2014/1/10 Clint Byrum :
>> > Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700:
>> >> Hi Flavio, Clint
>> >>
>> >> I agree with you guys.
>> >> sorry, may be, I wasn't clear. M
Excerpts from Nachi Ueno's message of 2014-01-13 10:35:07 -0800:
> Hi Clint
>
> 2014/1/10 Clint Byrum :
> > Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700:
> >> Hi Flavio, Clint
> >>
> >> I agree with you guys.
> >> sorry, may be, I wasn't clear. My opinion is to remove every
> >>
Hi Clint
2014/1/10 Clint Byrum :
> Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700:
>> Hi Flavio, Clint
>>
>> I agree with you guys.
>> sorry, may be, I wasn't clear. My opinion is to remove every
>> configuration in the node,
>> and every configuration should be done by API from c
Excerpts from Nachi Ueno's message of 2014-01-10 13:42:30 -0700:
> Hi Flavio, Clint
>
> I agree with you guys.
> sorry, may be, I wasn't clear. My opinion is to remove every
> configuration in the node,
> and every configuration should be done by API from central resource
> manager. (nova-api or n
Hi Flavio, Clint
I agree with you guys.
sorry, may be, I wasn't clear. My opinion is to remove every
configuration in the node,
and every configuration should be done by API from central resource
manager. (nova-api or neturon server etc).
This is how to add new hosts, in cloudstack, vcenter, and
Excerpts from Doug Hellmann's message of 2014-01-09 12:21:05 -0700:
> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
>
> > Hi folks
> >
> > Thank you for your input.
> >
> > The key difference from external configuration system (Chef, puppet
> > etc) is integration with
> > openstack services.
On 09/01/14 13:28 -0500, Jay Pipes wrote:
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
>Hi folks
>
>OpenStack process tend to have many config options, and many hosts.
>It is a pain to manage this tons of config options.
>To centralize this
2014/1/9 Doug Hellmann :
>
>
>
> On Thu, Jan 9, 2014 at 3:56 PM, Nachi Ueno wrote:
>>
>> Hi Oleg
>>
>> 2014/1/9 Oleg Gelbukh :
>> > On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote:
>> >>
>> >> 2014/1/9 Jeremy Hanmer :
>> >>
>> >> > How do you see these interactions defined? For instance, if I
On Thu, Jan 9, 2014 at 3:56 PM, Nachi Ueno wrote:
> Hi Oleg
>
> 2014/1/9 Oleg Gelbukh :
> > On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote:
> >>
> >> 2014/1/9 Jeremy Hanmer :
> >>
> >> > How do you see these interactions defined? For instance, if I deploy
> >> > a custom driver for Neutron,
Hi Oleg
2014/1/9 Oleg Gelbukh :
> On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote:
>>
>> 2014/1/9 Jeremy Hanmer :
>>
>> > How do you see these interactions defined? For instance, if I deploy
>> > a custom driver for Neutron, does that mean I also have to patch
>> > everything that will be tal
Hi Jay
2014/1/9 Jay Pipes :
> Hope you don't mind, I'll jump in here :)
I'll never mind to discuss with you :)
> On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:
>> Hi Jeremy
>>
>> Don't you think it is burden for operators if we should choose correct
>> combination of config for multiple nod
On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno wrote:
> 2014/1/9 Jeremy Hanmer :
> > How do you see these interactions defined? For instance, if I deploy
> > a custom driver for Neutron, does that mean I also have to patch
> > everything that will be talking to it (Nova, for instance) so they can
Hope you don't mind, I'll jump in here :)
On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:
> Hi Jeremy
>
> Don't you think it is burden for operators if we should choose correct
> combination of config for multiple nodes even if we have chef and
> puppet?
It's more of a burden for operators
Hi Bob
2014/1/9 Robert Kukura :
> On 01/09/2014 02:34 PM, Nachi Ueno wrote:
>> Hi Doug
>>
>> 2014/1/9 Doug Hellmann :
>>>
>>>
>>>
>>> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
Hi folks
Thank you for your input.
The key difference from external configuration s
On Thu, Jan 9, 2014 at 10:53 PM, Nachi Ueno wrote:
> Hi folks
>
> Thank you for your input.
>
> The key difference from external configuration system (Chef, puppet
> etc) is integration with
> openstack services.
> There are cases a process should know the config value in the other hosts.
> If we
2014/1/9 Jeremy Hanmer :
> Having run openstack clusters for ~2 years, I can't say that I've ever
> desired such functionality.
My proposal is adding functionalities, not removing it.
so if you are satisfied with file based configuration with chef or puppet,
this change won't affect you
> How do
On 01/09/2014 02:34 PM, Nachi Ueno wrote:
> Hi Doug
>
> 2014/1/9 Doug Hellmann :
>>
>>
>>
>> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
>>>
>>> Hi folks
>>>
>>> Thank you for your input.
>>>
>>> The key difference from external configuration system (Chef, puppet
>>> etc) is integration wit
Hi Doug
Thank you for your input.
2014/1/9 Doug Hellmann :
>
>
>
> On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno wrote:
>>
>> Hi Doug
>>
>> 2014/1/9 Doug Hellmann :
>> >
>> >
>> >
>> > On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
>> >>
>> >> Hi folks
>> >>
>> >> Thank you for your input.
>> >
Having run openstack clusters for ~2 years, I can't say that I've ever
desired such functionality.
How do you see these interactions defined? For instance, if I deploy
a custom driver for Neutron, does that mean I also have to patch
everything that will be talking to it (Nova, for instance) so th
On Thu, Jan 9, 2014 at 2:34 PM, Nachi Ueno wrote:
> Hi Doug
>
> 2014/1/9 Doug Hellmann :
> >
> >
> >
> > On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
> >>
> >> Hi folks
> >>
> >> Thank you for your input.
> >>
> >> The key difference from external configuration system (Chef, puppet
> >> etc
On Thu, Jan 9, 2014 at 7:53 PM, Nachi Ueno wrote:
> One example of such case is neuron + nova vif parameter configuration
> regarding to security group.
> The workflow is something like this.
>
> nova asks vif configuration information for neutron server.
> Neutron server ask configuration in neu
Hi Doug
2014/1/9 Doug Hellmann :
>
>
>
> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
>>
>> Hi folks
>>
>> Thank you for your input.
>>
>> The key difference from external configuration system (Chef, puppet
>> etc) is integration with
>> openstack services.
>> There are cases a process shoul
On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno wrote:
> Hi folks
>
> Thank you for your input.
>
> The key difference from external configuration system (Chef, puppet
> etc) is integration with
> openstack services.
> There are cases a process should know the config value in the other hosts.
> If we
Hi Jeremy
Don't you think it is burden for operators if we should choose correct
combination of config for multiple nodes even if we have chef and
puppet?
If we have some constraint or dependency in configurations, such logic
should be in openstack source code.
We can solve this issue if we have
Hi folks
Thank you for your input.
The key difference from external configuration system (Chef, puppet
etc) is integration with
openstack services.
There are cases a process should know the config value in the other hosts.
If we could have centralized config storage api, we can solve this issue.
+1 to Jay. Existing tools are both better suited to the job and work
quite well in their current state. To address Nachi's first example,
there's nothing preventing a Nova node in Chef from reading Neutron's
configuration (either by using a (partial) search or storing the
necessary information in
I agree with Doug’s question, but also would extend the train of thought to ask
why not help to make Chef or Puppet better and cover the more OpenStack
use-cases rather than add yet another competing system?
Cheers,
Morgan
On January 9, 2014 at 10:24:06, Doug Hellmann (doug.hellm...@dreamhost.co
On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:
> On 08/01/14 17:13 -0800, Nachi Ueno wrote:
> >Hi folks
> >
> >OpenStack process tend to have many config options, and many hosts.
> >It is a pain to manage this tons of config options.
> >To centralize this management helps operation.
> >
>
Nachi,
Thanks for bringing this up. We've been thinking a lot about handling of
configurations while working on Rubick.
In my understanding, oslo.config could provide an interface to different
back-ends to store configuration parameters. It could be simple centralized
alternative to configuration
What capabilities would this new service give us that existing, proven,
configuration management tools like chef and puppet don't have?
On Thu, Jan 9, 2014 at 12:52 PM, Nachi Ueno wrote:
> Hi Flavio
>
> Thank you for your input.
> I agree with you. oslo.config isn't right place to have server s
Hi Flavio
Thank you for your input.
I agree with you. oslo.config isn't right place to have server side code.
How about oslo.configserver ?
For authentication, we can reuse keystone auth and oslo.rpc.
Best
Nachi
2014/1/9 Flavio Percoco :
> On 08/01/14 17:13 -0800, Nachi Ueno wrote:
>>
>> Hi fo
On 08/01/14 17:13 -0800, Nachi Ueno wrote:
Hi folks
OpenStack process tend to have many config options, and many hosts.
It is a pain to manage this tons of config options.
To centralize this management helps operation.
We can use chef or puppet kind of tools, however
sometimes each process depe
Hi folks
OpenStack process tend to have many config options, and many hosts.
It is a pain to manage this tons of config options.
To centralize this management helps operation.
We can use chef or puppet kind of tools, however
sometimes each process depends on the other processes configuration.
For
33 matches
Mail list logo
