+1
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Friday, December 05, 2014 7:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use
Cases that led us to adopt this.
German-- but the point i
+1 for revolving meetings
From: Kurt Taylor
To: OpenStack Development Mailing List (not for usage questions)
; openstack-in...@lists.openstack.org
Sent: Friday, December 5, 2014 8:38 PM
Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
Additional Meeting for third-pa
Found something might be helpful for you
http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Add
在 2014年12月08日 13:13, Alex Xu 写道:
Hi,
I have question about using query string or request body for REST API.
I wonder if we can use body in delete, currently , there isn't any case
used in v2/v3 api.
This question found when I review this spec:
https://review.openstack.org/#/c/131633/6..7/spe
Hi,
I have question about using query string or request body for REST API.
This question found when I review this spec:
https://review.openstack.org/#/c/131633/6..7/specs/kilo/approved/judge-service-state-when-deleting.rst
Think about use request body will have more benefit:
1. Request body can
I think Chris is on vacation. We move V3 API to V2.1. V2.1 have some
improvement compare to V2. You can find more detail at
http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/v2-on-v3-api.html
We need support instance tag for V2.1. And in your patch, we needn't
json-schema for
I think the problem is in nova, can you show your "pci_passthrough_whitelist"
in nova.conf?
At 2014-12-04 18:26:21, "Akilesh K" wrote:
Hi,
I am using neutron-plugin-sriov-agent.
I have configured pci_whitelist in nova.conf
I have configured ml2_conf_sriov.ini.
But when I launch inst
Hi Neil,
@Neil, could you please also add VIF_TYPE_VHOSTUSER in your spec (as I
commented on it)? There has been active VHOSTUSER discuss in JUNO nova BP, and
it's the same usefulness as VIF_TYPE_TAP.
Best Regards
Wu
From: Neil Jerram [neil.jer...@metasw
On Mon, Dec 8, 2014 at 1:51 AM, Gary Kotton wrote:
> Hi Kyle,
> I am not missing the point. I understand the proposal. I just think that it
> has some shortcomings (unless I misunderstand, which will certainly not be
> the first time and most definitely not the last). The thinning out is to
> have
Nice to see it :-)
2014-12-04 23:52 GMT+08:00 Kyle Mestery :
> Note: Similar to Nova, cross-posting to operators.
>
> We've published the list of priorities for Neutron during the Kilo cycle,
> and it's available here [1]. The team has been discussing these since
> before the Paris Summit, and we
On Sun, Dec 07, 2014 at 08:47:28AM +, Tim Bell wrote:
> Would the nova view console be able to see the older versions also ? Ideally,
> we'd also improve on the current situation where the console contents are
> limited to the current file which causes problems around hard reboot
> operations
> The argument boils down to there is a communications cost to adding
> someone to core, and therefore there is a maximum size before the
> communications burden becomes to great.
I'm definitely of the mindset that the core team is something that has a
maximum effective size. Nova is complicated
On Mon, Dec 8, 2014 at 8:33 AM, Johannes Erdfelt wrote:
> On Mon, Dec 08, 2014, Michael Still wrote:
>> There are other things happening behind the scenes as well -- we have
>> a veto process for current cores when we propose a new core. It has
>> been made clear to me that several current core m
Ryan,
I have been working with the L3 sub team in this direction. Progress has
been slow because of other priorities but we have made some. I have
written a blueprint detailing some changes needed to the code to enable the
flexibility to one day run glaring ups on an l3 routed network [1]. Jaim
On Mon, Dec 08, 2014, Michael Still wrote:
> There are other things happening behind the scenes as well -- we have
> a veto process for current cores when we propose a new core. It has
> been made clear to me that several current core members believe we
> have reached "the maximum effective size"
On Mon, Dec 8, 2014 at 4:02 AM, Jay Pipes wrote:
> On 12/07/2014 04:19 AM, Michael Still wrote:
[snip]
>> We've always said we expect cores to maintain an average of two
>> reviews per day. That's not new, nor a rule created by me. Padraig is
>> a great guy, but has been working on other things
Hi Kyle,
I am not missing the point. I understand the proposal. I just think that it has
some shortcomings (unless I misunderstand, which will certainly not be the
first time and most definitely not the last). The thinning out is to have a
shim in place. I understand this and this will be the en
On 12/7/14, 6:41 PM, "Dan Smith" wrote:
>> I'm going to be honest and say I'm confused here.
>>
>> We've always said we expect cores to maintain an average of two
>> reviews per day. That's not new, nor a rule created by me. Padraig is
>> a great guy, but has been working on other things -- he
On 12/07/2014 06:02 PM, Jay Pipes wrote:
> On 12/07/2014 04:19 AM, Michael Still wrote:
>> On Sun, Dec 7, 2014 at 7:03 PM, Gary Kotton wrote:
>>> On 12/6/14, 7:42 PM, "Jay Pipes" wrote:
>>
>> [snip]
>>
-1 on pixelbeat, since he's been active in reviews on
various things AFAICT in the la
Gary, you are still miss the point of this proposal. Please see my comments
in review. We are not forcing things out of tree, we are thinning them. The
text you quoted in the review makes that clear. We will look at further
decomposing ML2 post Kilo, but we have to be realistic with what we can
acc
On 12/07/2014 04:19 AM, Michael Still wrote:
On Sun, Dec 7, 2014 at 7:03 PM, Gary Kotton wrote:
On 12/6/14, 7:42 PM, "Jay Pipes" wrote:
[snip]
-1 on pixelbeat, since he's been active in reviews on
various things AFAICT in the last 60-90 days and seems to be still a
considerate reviewer in
> I'm going to be honest and say I'm confused here.
>
> We've always said we expect cores to maintain an average of two
> reviews per day. That's not new, nor a rule created by me. Padraig is
> a great guy, but has been working on other things -- he's done 60
> reviews in the last 60 days -- which
Also try with nova force-delete after reset:
$ nova help force-delete
usage: nova force-delete
Force delete a server.
Positional arguments:
Name or ID of server.
--
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/
On Sun, Dec 7, 2014 at
Have you tried to delete after reset?
# nova reset-state --active
# nova delete
It works well for me if the VM state is error state.
--
Thanks & Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/
On Sun, Dec 7, 2014 at 7:17 PM, Danny Choi (dannch
That does not work.
It put the VM in ACTIVE Status, but in NOSTATE Power State.
Subsequent delete still won’t remove the VM.
+--+--+++-++
| ID
Thanks!
One more question.
Is there any equivalent API to add keys to the volume-type? I understand we
have APIs for creating volume-type? But how about adding key-value pair
(say I want to add-key to the volume-type as
backend-name="my_iscsi_backend" ?
Thanks,
Pradip
On Sun, Dec 7, 2014 at 4
See https://review.openstack.org/#/c/119938/ - now merged. I don't believe
the python-cinderclient side work has been done yet, nor anything in
Horizon, but the API itself is now there.
On 7 December 2014 at 09:53, Pradip Mukhopadhyay
wrote:
> Hi,
>
>
> Is there a way to find out/list down the b
Please see http://stackalytics.com/report/contribution/nova-group/90. If
we are following the average of 2 reviews per day then proposed list
should be updated.
On 12/7/14, 11:19 AM, "Michael Still" wrote:
>On Sun, Dec 7, 2014 at 7:03 PM, Gary Kotton wrote:
>> On 12/6/14, 7:42 PM, "Jay Pipes"
Hi Doug,
Thanks for a reminder,
Res-submitted following three for kilo:
LBaaS Layer 7 rules - https://review.openstack.org/#/c/139853/
Neutron LBaaS TLS - https://review.openstack.org/#/c/139852
Radware LBaaS Driver - https://review.openstack.org/#/c/139854/
Thanks,
Evg
-
Hi,
Is there a way to find out/list down the backends discovered for Cinder?
There is, I guess, no API for get the list of backends.
Thanks,
Pradip
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/
Hi,
Is there a way to find out/list down the backends discovered for Cinder?
There is, I guess, no API for get the list of backends.
Thanks,
Pradip
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/
On Sun, Dec 7, 2014 at 7:03 PM, Gary Kotton wrote:
> On 12/6/14, 7:42 PM, "Jay Pipes" wrote:
[snip]
>>-1 on pixelbeat, since he's been active in reviews on
>>various things AFAICT in the last 60-90 days and seems to be still a
>>considerate reviewer in various areas.
>
> I agree -1 for Padraig
> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: 06 December 2014 06:39
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [nova] Fixing the console.log grows forever bug.
>
...
>
> However I was encouraged to investigate fixing this in qem
Hi,
I have raised my concerns on the proposal. I think that all plugins should be
treated on an equal footing. My main concern is having the ML2 plugin in tree
whilst the others will be moved out of tree will be problematic. I think that
the model will be complete if the ML2 was also out of tree
I agree -1 for Padraig
On 12/6/14, 7:42 PM, "Jay Pipes" wrote:
>On 12/04/2014 04:05 PM, Michael Still wrote:
>> One of the things that happens over time is that some of our core
>> reviewers move on to other projects. This is a normal and healthy
>> thing, especially as nova continues to spin ou
35 matches
Mail list logo
