On Thu, Sep 24, 2015 at 2:22 PM, Sam Morrison wrote:
>
> Yes an AZ may not be considered a failure domain in terms of control
> infrastructure, I think all operators understand this. If you want control
> infrastructure failure domains use regions.
>
> However from a resource level (eg. running i
> On 24 Sep 2015, at 6:19 pm, Sylvain Bauza wrote:
>
> Ahem, Nova AZs are not failure domains - I mean the current implementation,
> in the sense of many people understand what is a failure domain, ie. a
> physical unit of machines (a bay, a room, a floor, a datacenter).
> All the AZs in Nova
Hi Matt,
On 2015-09-24 1:45 PM, Matt Riedemann wrote:
>
>
> On 9/24/2015 11:50 AM, Mathieu Gagné wrote:
>>
>> May I suggest the following solutions:
>>
>> 1) Add ability to disable this whole AZ concept in Cinder so it doesn't
>> fail to create volumes when Nova asks for a specific AZ. This coul
Le 24/09/2015 19:45, Matt Riedemann a écrit :
On 9/24/2015 11:50 AM, Mathieu Gagné wrote:
On 2015-09-24 3:04 AM, Duncan Thomas wrote:
I proposed a session at the Tokyo summit for a discussion of Cinder
AZs,
since there was clear confusion about what they are intended for and
how
they sh
On 09/24/15 at 12:16pm, Mathieu Gagné wrote:
On 2015-09-24 11:53 AM, Walter A. Boring IV wrote:
The good thing about the Nova and Cinder clients/APIs is that
anyone can write a quick python script to do the orchestration
themselves, if we want to deprecate this. I'm all for deprecating this.
Le 24/09/2015 18:16, Mathieu Gagné a écrit :
On 2015-09-24 11:53 AM, Walter A. Boring IV wrote:
The good thing about the Nova and Cinder clients/APIs is that
anyone can write a quick python script to do the orchestration
themselves, if we want to deprecate this. I'm all for deprecating this.
On 9/24/2015 11:50 AM, Mathieu Gagné wrote:
On 2015-09-24 3:04 AM, Duncan Thomas wrote:
I proposed a session at the Tokyo summit for a discussion of Cinder AZs,
since there was clear confusion about what they are intended for and how
they should be configured. Since then I've reached out to a
On 2015-09-24 3:04 AM, Duncan Thomas wrote:
>
> I proposed a session at the Tokyo summit for a discussion of Cinder AZs,
> since there was clear confusion about what they are intended for and how
> they should be configured. Since then I've reached out to and gotten
> good feedback from, a number
On 2015-09-24 11:53 AM, Walter A. Boring IV wrote:
> The good thing about the Nova and Cinder clients/APIs is that
> anyone can write a quick python script to do the orchestration
> themselves, if we want to deprecate this. I'm all for deprecating this.
I don't like this kind of reasoning which c
> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: 24 September 2015 16:59
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?
>
>
>
> On 9/24/2015 9:
>> To be honest this is probably my fault, AZ's were pulled in as part of
>> the nova-volume migration to Cinder and just sort of died. Quite
>> frankly I wasn't sure "what" to do with them but brought over the
>> concept and the zones that existing in Nova-Volume. It's been an issue
>> since d
On 9/24/2015 9:06 AM, Matt Riedemann wrote:
On 9/24/2015 3:19 AM, Sylvain Bauza wrote:
Le 24/09/2015 09:04, Duncan Thomas a écrit :
Hi
I thought I was late on this thread, but looking at the time stamps,
it is just something that escalated very quickly. I am honestly
surprised an cross-p
On 9/24/2015 3:19 AM, Sylvain Bauza wrote:
Le 24/09/2015 09:04, Duncan Thomas a écrit :
Hi
I thought I was late on this thread, but looking at the time stamps,
it is just something that escalated very quickly. I am honestly
surprised an cross-project interaction option went from 'we don't s
Le 24/09/2015 09:04, Duncan Thomas a écrit :
Hi
I thought I was late on this thread, but looking at the time stamps,
it is just something that escalated very quickly. I am honestly
surprised an cross-project interaction option went from 'we don't seem
to understand this' to 'deprecation mer
Hi
I thought I was late on this thread, but looking at the time stamps, it is
just something that escalated very quickly. I am honestly surprised an
cross-project interaction option went from 'we don't seem to understand
this' to 'deprecation merged' in 4 hours, with only a 12 hour discussion on
t
Hi All,
I'm sorry I was in vacation yesterday(in JST), and I did not notice this
discussion.
I registered "bug 1496235".
In our case , there is Nova 2 az(az1, az2),and Cinder 1 az (default).
Cinder backend is ceph, that is a cluster of compute nodes inclued az1 and
az2 of nova. Nova's 2 az always
> On 24 Sep 2015, at 9:59 am, Andrew Laski wrote:
>
> I was perhaps hasty in approving that patch and didn't realize that Matt had
> reached out for operator feedback at the same time that he proposed it. Since
> this is being used in production I wouldn't want it to be removed without at
> l
On 09/24/15 at 09:34am, Sam Morrison wrote:
Just got alerted to this on the operator list.
We very much rely on this.
We have multiple availability zones in nova and each zone has a corresponding
cinder-volume service(s) in the same availability zone.
We don’t want people attaching a volume f
Just got alerted to this on the operator list.
We very much rely on this.
We have multiple availability zones in nova and each zone has a corresponding
cinder-volume service(s) in the same availability zone.
We don’t want people attaching a volume from one zone to another as the network
won’t
On 2015-09-23 4:50 PM, Andrew Laski wrote:
> On 09/23/15 at 04:30pm, Mathieu Gagné wrote:
>> On 2015-09-23 4:12 PM, Andrew Laski wrote:
>>> On 09/23/15 at 02:55pm, Matt Riedemann wrote:
Heh, so when I just asked in the cinder channel if we can just
deprecate nova boot from volume wit
On 09/23/15 at 04:30pm, Mathieu Gagné wrote:
On 2015-09-23 4:12 PM, Andrew Laski wrote:
On 09/23/15 at 02:55pm, Matt Riedemann wrote:
Heh, so when I just asked in the cinder channel if we can just
deprecate nova boot from volume with source=(image|snapshot|blank)
(which automatically creates t
On 2015-09-23 4:12 PM, Andrew Laski wrote:
> On 09/23/15 at 02:55pm, Matt Riedemann wrote:
>>
>> Heh, so when I just asked in the cinder channel if we can just
>> deprecate nova boot from volume with source=(image|snapshot|blank)
>> (which automatically creates the volume and polls for it to be
>>
On 9/23/2015 2:57 PM, Sylvain Bauza wrote:
Le 23/09/2015 21:45, John Griffith a écrit :
On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Le 23/09/2015 22:15, Andrew Laski a écrit :
On 09/23/15 at 01:45pm, John Griffith wrote:
To be honest this is probably my fault, AZ's were pulled in as part
of the
nova-volume migration to Cinder and just sort of died. Quite frankly I
wasn't sure "what" to do with them but brought over t
On 09/23/15 at 01:45pm, John Griffith wrote:
To be honest this is probably my fault, AZ's were pulled in as part of the
nova-volume migration to Cinder and just sort of died. Quite frankly I
wasn't sure "what" to do with them but brought over the concept and the
zones that existing in Nova-Vo
On 09/23/15 at 02:55pm, Matt Riedemann wrote:
On 9/23/2015 2:45 PM, John Griffith wrote:
On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
On 9/23/2015 2:45 PM, John Griffith wrote:
On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Hi Matt,
In Liberty, we i
Le 23/09/2015 21:45, John Griffith a écrit :
On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Hi Matt,
In Liberty,
On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
wrote:
>
>
> On 9/23/2015 2:15 PM, Matt Riedemann wrote:
>
>>
>>
>> On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
>>
>>> Hi Matt,
>>>
>>> In Liberty, we introduced allow_availability_zone_fallback [1] option in
>>> Cinder config as fix for bug [2].
On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Hi Matt,
In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volu
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Hi Matt,
In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state
[1]
https://github.com
Hi Matt,
In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state
[1]
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150d
I came across bug 1496235 [1] today. In this case the user is booting
an instance from a volume using source=image, so nova actually does the
volume create call to the volume API. They are booting the instance
into a valid nova availability zone, but that same AZ isn't defined in
Cinder, so t
33 matches
Mail list logo
