Mailing List Archive

Quantum Common Configuration Issues
Hi,
The reviews of the implementation have brought up a number of issues
(https://review.openstack.org/#/c/8101). These are namely the management
of the various configuration files and paths. I am sorry for bring this
up now. I was under the impression that we want to try and keep the same
files and support as of today, but this was a bit naive in retrospect.
I would like to suggest a solution and if possible get some feedback
prior to addressing all of the issues/comments. I would like to suggest
the following:
There will be 2 configuration files:
1. quantum.conf - this will be used by both the agents and the quantum
service. The file will contain all of the key value pair used by either
the agents and plugin. The installation packages for the quantum
agent/service can create or modify the files accordingly.
For example:
Common for both:-
debug
verbose
logging ...
rpc fields (for up and coming scaling bp)
Quantum service:-
port
listing address
database configuration if necessary
...
Quantum agent:-
root wrapper
polling interval
...
2. api-paste.ini - this is only used by the quantum service (similar
support in nova, keystone and glance)
Thanks
Gary

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
Re: Quantum Common Configuration Issues [ In reply to ]
Hi Gary,

I'd like to make sure that its easy to have common options across different
plugins (e.g., database options, DHCP options, etc.), so I think this
approach makes sense, at least at a high-leve. I'll take a look at the
review as well.

Dan


On Tue, Jun 5, 2012 at 10:55 AM, Gary Kotton <gkotton@redhat.com> wrote:

> Hi,
> The reviews of the implementation have brought up a number of issues (
> https://review.openstack.org/**#/c/8101<https://review.openstack.org/#/c/8101>).
> These are namely the management of the various configuration files and
> paths. I am sorry for bring this up now. I was under the impression that we
> want to try and keep the same files and support as of today, but this was a
> bit naive in retrospect.
> I would like to suggest a solution and if possible get some feedback prior
> to addressing all of the issues/comments. I would like to suggest the
> following:
> There will be 2 configuration files:
> 1. quantum.conf - this will be used by both the agents and the quantum
> service. The file will contain all of the key value pair used by either the
> agents and plugin. The installation packages for the quantum agent/service
> can create or modify the files accordingly.
> For example:
> Common for both:-
> debug
> verbose
> logging ...
> rpc fields (for up and coming scaling bp)
> Quantum service:-
> port
> listing address
> database configuration if necessary
> ...
> Quantum agent:-
> root wrapper
> polling interval
> ...
> 2. api-paste.ini - this is only used by the quantum service (similar
> support in nova, keystone and glance)
> Thanks
> Gary
>
> --
> Mailing list: https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Quantum Common Configuration Issues [ In reply to ]
On 06/11/2012 07:38 AM, Dan Wendlandt wrote:
> Hi Gary,
>
> I'd like to make sure that its easy to have common options across
> different plugins (e.g., database options, DHCP options, etc.), so I
> think this approach makes sense, at least at a high-leve. I'll take a
> look at the review as well.
Thanks. Please note that this will be done in stages.
Stage 1: ovs and linux bridge to use non-global conf structure (completed)
Stage 2: quantum service to use global CONF structure and ryu plugin to
use non-global conf (pending review)
Stage 3: remove the paste configuration form the quantum.conf file and
create a separate file for the paste config.
Stage 4: merge all to use the global CONF structure
The open review is for stage 2.
(https://review.openstack.org/#/c/8101/). Will be happy to get input so
that we can move forward with this. This is blocking the scalable agent
support.
Thanks
Gary
>
> Dan
>
>
> On Tue, Jun 5, 2012 at 10:55 AM, Gary Kotton <gkotton@redhat.com
> <mailto:gkotton@redhat.com>> wrote:
>
> Hi,
> The reviews of the implementation have brought up a number of
> issues (https://review.openstack.org/#/c/8101). These are namely
> the management of the various configuration files and paths. I am
> sorry for bring this up now. I was under the impression that we
> want to try and keep the same files and support as of today, but
> this was a bit naive in retrospect.
> I would like to suggest a solution and if possible get some
> feedback prior to addressing all of the issues/comments. I would
> like to suggest the following:
> There will be 2 configuration files:
> 1. quantum.conf - this will be used by both the agents and the
> quantum service. The file will contain all of the key value pair
> used by either the agents and plugin. The installation packages
> for the quantum agent/service can create or modify the files
> accordingly.
> For example:
> Common for both:-
> debug
> verbose
> logging ...
> rpc fields (for up and coming scaling bp)
> Quantum service:-
> port
> listing address
> database configuration if necessary
> ...
> Quantum agent:-
> root wrapper
> polling interval
> ...
> 2. api-paste.ini - this is only used by the quantum service
> (similar support in nova, keystone and glance)
> Thanks
> Gary
>
> --
> Mailing list: https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> Post to : netstack@lists.launchpad.net
> <mailto:netstack@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>