I must admit, I really like this idea of getting rid of all the devstack
params. It's always a mess looking up the functionality of the various
variables in the code when trying out something new.
I also understand the concern that was raised by somebody (couldn't find
it anymore) that the Neutron
On 2016/04/12 8:02, Kevin Benton wrote:
Oh right, I'm definitely for eliminating these values from Devstack
and just telling people to use post-config. I was just hesitant about
advocating for their removal from neutron.
Yeah, my point is eliminating useless options from Devstack since we can
Oh right, I'm definitely for eliminating these values from Devstack and
just telling people to use post-config. I was just hesitant about
advocating for their removal from neutron.
On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan
wrote:
> On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote:
> >
On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote:
> >[1]:
> >https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178
> >[2]:
> >https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166
>
>
> This is a Nova option to decide how long to wait for Neutron
>[1]:
https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178
>[2]:
https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166
This is a Nova option to decide how long to wait for Neutron to callback
before considering a port failed to be wired. The time this w
I agree. Throughout I was reviewing Devstack over 3 cycles,
I thought the same thing. Devstack often accepted patches just
adding option although we're not sure who really needs the options.
There are many useless stuff in the options.
For example, default value of devstack option is the same valu
Good news... the number of neutron options with a sane default value has
increased significantly in the last couple of releases. If you're looking
at the installation guide, it explicitly configures more options to
override bad values set by distribution packages. For deployment tools,
explicitly c
Armando M. wrote:
> My understanding of the plan to overhaul the neutron (bloated) layer
> present in DevStack being tackled in [1] has always been that this was
> about trimming the layer rather than eliminating it altogether. Is this
> email a reflection of a desire to change direction? If so, Se
On 8 April 2016 at 11:06, Sean Dague wrote:
> On 04/08/2016 12:05 PM, Morales, Victor wrote:
> > Agree, sometimes is hard to figure out what is the Devstack variable
> that will modify the configuration value.
> >
> > There is an effort to categorize the configuration options[1] of some of
> the
On 08.04.2016 14:47, Assaf Muller wrote:
On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley
wrote:
On Apr 8, 2016, at 1:28 PM, Sean M. Collins wrote:
Assaf Muller wrote:
I do want to say that ML2's "mechanism_drivers" option probably does
not have a default for the same reason we do not have a d
On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley
wrote:
>
>> On Apr 8, 2016, at 1:28 PM, Sean M. Collins wrote:
>>
>> Assaf Muller wrote:
>>> I do want to say that ML2's "mechanism_drivers" option probably does
>>> not have a default for the same reason we do not have a default for
>>> the core_plugi
> On Apr 8, 2016, at 1:28 PM, Sean M. Collins wrote:
>
> Assaf Muller wrote:
>> I do want to say that ML2's "mechanism_drivers" option probably does
>> not have a default for the same reason we do not have a default for
>> the core_plugin value, we don't want to play favorites. From Neutron's
>>
Assaf Muller wrote:
> I do want to say that ML2's "mechanism_drivers" option probably does
> not have a default for the same reason we do not have a default for
> the core_plugin value, we don't want to play favorites. From Neutron's
> point of view, ignoring the existence of Devstack and upstream
On 04/08/2016 12:05 PM, Morales, Victor wrote:
> Agree, sometimes is hard to figure out what is the Devstack variable that
> will modify the configuration value.
>
> There is an effort to categorize the configuration options[1] of some of the
> projects. I’m wondering if it could be possible to
On Fri, Apr 8, 2016 at 11:57 AM, Sean M. Collins wrote:
> Edgar Magana wrote:
>> This is a very solid plan. Maybe to fair on the current state of the
>> devstack with neutron functionality, what will be the disadvantage(s) of
>> this change from your perspective?
>>
>
> A user's local.conf will
I like this, for a reason not mentioned. I am not a Neutron dev or
operator and have never learned how to deploy Neutron; I have always
driven it through DevStack. The documentation for that has never been
adequate, and I have concluded it will never be adequate. With inadequate
documentatio
Agree, sometimes is hard to figure out what is the Devstack variable that will
modify the configuration value.
There is an effort to categorize the configuration options[1] of some of the
projects. I’m wondering if it could be possible to create category or field
that specifies the Destack var
Edgar Magana wrote:
> This is a very solid plan. Maybe to fair on the current state of the devstack
> with neutron functionality, what will be the disadvantage(s) of this change
> from your perspective?
>
A user's local.conf will probably get a little bigger - and I think a
lot of the issues ab
This is a very solid plan. Maybe to fair on the current state of the devstack
with neutron functionality, what will be the disadvantage(s) of this change
from your perspective?
Edgar
On 4/8/16, 8:07 AM, "Sean M. Collins" wrote:
>Prior to the introduction of local.conf, the only way to confi
Prior to the introduction of local.conf, the only way to configure
OpenStack components was to introduce code directly into DevStack, so
that DevStack would pick it up then inject it into the configuration
file.
This was because DevStack writes out new configuration files on each
run, so it wasn't
20 matches
Mail list logo
