On 02/01/2013 01:37 PM, Paul Michali wrote:
No problem. So, I have some questions that I'm hoping someone can
direct me as to the best place to post and how to proceed process wise
on bug1059923. This is my first commit, so I'm still figuring out the
process...
It takes a while. I am still trying to figure things out :)
1) The commit that was done, was reverted. Do I continue to use the
review (19649) for this issue, or do I open a new review? If the
latter, is there some indication in the original review that this was
reverted?
You need to open a new review
2) Regarding a proposed solution, where is the best place to discuss
proposals? In the review? In openstack-dev? elsewhere?
The best place is on the openstack development list (OpenStack
Development Mailing List <[email protected]>). Set the
subject with a prefix: [quantum]
3) Specifically on this bug… I'm unsure as to how we want to approach
this (for quantum server)… whether to mark some plugin config options
as 'required' so that existing logic will catch it if they are missing
(I have numerous questions if that route is taken), or drive the
validation logic down into the individual plugin, having them validate
configuration settings (again a bunch of questions). Where can I
discuss these ideas, rather than going back an forth a dozen times in
the review?
The ideas are best discussed on the list.
The packing that we have done with Fedora and RHEL provides the user
with a setup utility script that will make sure that the core_plugin and
the database are set correctly.
I am not sure what the ubuntu guys have done (I have yet to try that out)
Thanks,
PCM (Paul Michali)
On Jan 31, 2013, at 10:23 PM, Dan Wendlandt wrote:
Apologies to Paul. quantum-core requires moderation of non-member
posts (can't seem to find a way to change this), and the launchpad
email notifying me of his posts were mixed in with a deluge of
launchpad emails from mark's hard work tagging each quantum bug :)
sorry for the confusion.
dan
On Mon, Jan 28, 2013 at 5:42 AM, Paul Michali <[email protected]
<mailto:[email protected]>> wrote:
Any suggestions on how I tell if the sql_connection (or if there
are other settings) are valid though? Would there be one for the
service itself, and maybe we could check to see if the two are at
least the same connection type?
Regards,
PCM (Paul Michali)
On Jan 28, 2013, at 8:29 AM, Gary Kotton wrote:
On 01/28/2013 03:25 PM, Paul Michali wrote:
OK, so where do we go from here? Do I continue to revise my
change set to A) show plugin agent configs loaded for debugging
purposes (like the service does), B) validate plugin agent
config options (not specified in the bug, but people were
suggesting this be done), and/or C) validate plugin config for
the service?
I am leaning towards C. Do the core_plugin validation on the service
For B) I had raised the question in the review of how do we
tell if the plugin specific configurations are loaded? I see
that many have sql_connection under DATABASE, and there are OVS
configurations for the four agents, but all of these seem to
provide a default value, if none specified. How do I tell if
the default value is "valid"? I guess in the case of the bug
they were using a MySQL database connection and without the
plugin agent .ini it was falling back to sqlite?
For C) similar to B) how do I pick configuration values to test
and how do I make sure they are "valid"?
I think that most or maybe all of the open source plugins make
use of the DATABASE variables. A recent change was done to
ensure that there are defined in 1 place instead of N (where
N==number of plugins).
Regards,
PCM (Paul Michali)
On Jan 28, 2013, at 6:57 AM, Gary Kotton wrote:
On 01/28/2013 01:55 PM, Paul Michali wrote:
On Jan 28, 2013, at 2:20 AM, Gary Kotton wrote:
Hi,
It has come to my attention (and not sure how I missed it),
that the aforementioned patch does not actually solve the
issue. There are two problems here:
1. The validation should be done on the quantum service
2. The agents do not require the quantum core plugin - this
is only for the service.
PCM: It ended up being pretty convoluted, as we went round
and round on solutions…
I thought that the agents did not operate correctly, if the
core_plugin config item was not specified? I'll try to double
check.
The agent does not require the plugin variable. The plugin is
actually only loaded by the service.
For the server, it already displays the config settings
applied, and checks that the core_plugin is specified. I
could not identify an agent plugin config to check, as there
are default values applied (e.g. sql_connection has SQL lite)
and I couldn't tell if the default was valid or not.
In any case, let me know what I need to do on this bug and on
the commit.
Dan has done a rollback.
Thanks
Gary
Regards,
PCM
Sorry for the mess. How can we revert the patch?
Thanks
Gary
--
Mailing list: https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-core>
Post to : [email protected]
<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-core>
More help : https://help.launchpad.net/ListHelp
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com <http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Mailing list: https://launchpad.net/~quantum-core
Post to : [email protected]
Unsubscribe : https://launchpad.net/~quantum-core
More help : https://help.launchpad.net/ListHelp
