On 18/12/14 14:30, 乔建 wrote:
When using trove, we need to configure nova’s user information in the
configuration file of trove-guestagent, such as
lnova_proxy_admin_user
lnova_proxy_admin_pass
lnova_proxy_admin_tenant_name
Is it necessary? In a public cloud environment, It will lead to seriou
Hello to all.
On Sunday, January 11, 2015, Mark Kirkwood
wrote:
> On 18/12/14 14:30, 乔建 wrote:
>
>> When using trove, we need to configure nova’s user information in the
>> configuration file of trove-guestagent, such as
>>
>> lnova_proxy_admin_user
>>
>> lnova_proxy_admin_pass
>>
>> lnova_proxy
On 11/01/15 22:25, Denis Makogon wrote:
Guest agent doesn't need configuration options described above. IIRC,
only taskmanager needs them.
Right - so we need to update the default config files and doco - as they
have them in there.
About passing auth data. What are those benefits of chang
That only seems to bury the root cause because router_ids shouldn't be none
in this case with the reference L3 plugin.
The ML2 plugin calls disassociate_floatingips with do_notify set to False
so it should always be at least an empty set coming back.
Which L3 plugin were you using? Perhaps the im
I think Kevin is right - the actual root cause lies in plugins for which
disassociate_floating_ips returns None rather than an (empty) iterable.
A quick check revealed that at least:
neutron.plugins.embrane.base_plugin.EmbranePlugin
neutron.plugions.cisco.service_plugins.cisco_router_plugin.CiscoR
Actually, I just noticed that a patch which has been pending review since Sep
is not merged, and that actually fixes the root cause.
https://review.openstack.org/#/c/119269/
Having said that, I think the code can definitely use some touching. If
router_ids is not supposed to be None, it should
On 01/10/2015 05:57 AM, Armando M. wrote:
>>
>> If we were standing at a place with a detailed manual upgrade document
>> that explained how to do minimal VM downtime, that a few ops had gone
>> through and proved out, that would be one thing. And we could figure out
>> which parts made sense to pu
Jay,
I have a hacking rule in nova already [1] and am updating the rule in
the 3 reviews i have for oslo_utils, oslo_middleware and oslo_config
[2] in Nova
thanks,
dims
[1] https://github.com/openstack/nova/blob/master/nova/hacking/checks.py#L452
[2]
https://review.openstack.org/#/q/status:open
> On 9 Jan 2015, at 5:37 am, Joe Gordon wrote:
>
>
>
> On Sun, Jan 4, 2015 at 7:08 PM, Andrew Beekhof wrote:
>
> > On 9 Dec 2014, at 1:20 am, Roman Dobosz wrote:
> >
> > On Wed, 3 Dec 2014 08:44:57 +0100
> > Roman Dobosz wrote:
> >
> >> I've just started to work on the topic of detection i
Hi everyone,
Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, and other
features, I'd like to start a discussion about the NUMA testing in
particular.
Recently we have started a work to test some of these features.
The current plan is to use the functional tests, in the Nova
On 21:00 Sat 10 Jan , Jay S. Bryant wrote:
> I think what we discussed was that existing drivers were supposed to
> have something working by the end of k-2, or at least have something
> close to working.
>
> For new drivers they had to have 3rd party CI working by the end of Kilo.
>
> Duncan
Hi Alan,
We have also proposed an idea about SFC.
For more details you can refer to https://review.openstack.org/#/c/146315/
Thanks
Vikram
-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com]
Sent: 09 January 2015 01:39
To: lv.erc...@zte.com.cn
Cc: OpenStack Deve
On 10/01/15 03:26, Michael Dorman wrote:
> (X-posted to -operators.)
>
> Any thoughts on how the ops track spaces would be requested, since there
> is not a real ‘operators project’, PTL, etc.?
Based on our past events and summit survey feedback from Paris, I've
mentioned to Thierry that we prob
在 2015年01月08日 10:31, yongli he 写道:
to make a more stable service we upgrade the networking device, then the
log server address change to a new
IP address: 198.175.100.33
so the sample log change to(replace the 192.55.68.190 to new address):
http://198.175.100.33/143614/6/
http://198.175.100
Feel free to join any of the 3rd party 'mentoring' meetings on IRC Freenode
#openstack-meeting to help get started, work through issues, etc.
"Third Party meeting for all aspects of Third Party needs: Mondays at 1500 UTC
and Tuesdays at 0800 UTC. Everyone interested in any aspect Third Party pr
Hi Virkram,
Glad to hear that. Have you implemented that?
BR
Alan
发件人: Vikram Choudhary
收件人: "lv.erc...@zte.com.cn" ,
抄送: "OpenStack Development Mailing List (not for usage questions)"
, "sumitnaiksa...@gmail.com"
, Dhruv Dhody ,
"Dongfeng (C)" , Kalyankumar Asangi
Hi Sumit,
About the GBP plugin, I cann't found the implementation of the
network_service_policy API in the GBP plugin driver,
network_service_policy as I understand it corresponds to the network
services( such as FWaas, LBaas) in neutron, I don't konw if I am
understanding this right.
And do
17 matches
Mail list logo
