yes
-- Original --
From: "Ivan Kolodyazhny";
Date: Tue, Jul 17, 2018 05:00 PM
To: "OpenStack Developmen";
Subject: Re: [openstack-dev] [cinder] about block device driver
Do you use the volumes on the same nodes where instances a
nk you!
>
>
>
> -- Original --
> *From: * "Ivan Kolodyazhny";
> *Date: * Tue, Jul 17, 2018 04:09 PM
> *To: * "OpenStack Developmen";
> *Subject: * Re: [openstack-dev] [cinder] about block device driver
>
> Rambo,
>
>
an McGinnis";
Date: 2018年7月16日(星期一) 晚上9:32
To: "OpenStack Developmen";
Subject: Re: [openstack-dev] [cinder] about block device driver
On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote:
> On 16/07, Rambo wrote:
> > Well,in my opinion,the BlockDeviceDriver
McGinnis";
> *Date:* 2018年7月16日(星期一) 晚上9:32
> *To:* "OpenStack Developmen";
> *Subject:* Re: [openstack-dev] [cinder] about block device driver
>
> On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote:
> > On 16/07, Rambo wrote:
> > > Well,in m
ginal --
From: "Sean McGinnis";
Date: 2018年7月16日(星期一) 晚上9:32
To: "OpenStack Developmen";
Subject: Re: [openstack-dev] [cinder] about block device driver
On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote:
> On 16/07, Rambo wrote:
> > Well,in my opi
But I want to create a volume backed server for data processing scenarios,maybe
the BlockDeviceDriver is more suitable.
-- Original --
From: "Sean McGinnis";
Date: 2018年7月16日(星期一) 晚上9:32
To: "OpenStack Developmen";
Subject: Re: [openstack
: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, July 16, 2018 8:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] about block device driver
On 07/16/2018 09:32 AM, Sean McGinnis wrote:
The other option would be to not use Cinder volumes so you just use
local stora
Is this for ephemeral storage handling?
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, July 16, 2018 8:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] about block device driver
On 07/16/2018 09:32 AM, Sean McGinnis wrote
On 07/16/2018 09:32 AM, Sean McGinnis wrote:
The other option would be to not use Cinder volumes so you just use local
storage on your compute nodes.
^^ yes, this.
-jay
__
OpenStack Development Mailing List (not for usage
On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote:
> On 16/07, Rambo wrote:
> > Well,in my opinion,the BlockDeviceDriver is more suitable than any other
> > solution for data processing scenarios.Does the community will agree to
> > merge the BlockDeviceDriver to the Cinder repositor
.openstack.org/p/cinder-rocky-meeting-agendas
>
> -- Original --
> From: "Gorka Eguileor";
> Date: 2018年7月16日(星期一) 下午5:20
> To: "OpenStack Developmen";
> Subject: Re: [openstack-dev] [cinder] about block device driver
>
>
> On
--
From: "Gorka Eguileor";
Date: 2018年7月16日(星期一) 下午5:20
To: "OpenStack Developmen";
Subject: Re: [openstack-dev] [cinder] about block device driver
On 16/07, Rambo wrote:
> Hi,all
>
>
> In the Cinder repository, I noticed that the BlockDeviceDriver driver
On 16/07, Rambo wrote:
> Hi,all
>
>
> In the Cinder repository, I noticed that the BlockDeviceDriver driver is
> being deprecated, and was eventually be removed with the Queens release.
>
>
> https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/block_device.py
>
>
> In
Hi,all
In the Cinder repository, I noticed that the BlockDeviceDriver driver is
being deprecated, and was eventually be removed with the Queens release.
https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/block_device.py
In my use case, the instances using Cind
Thanks Jay!
Em sex, 6 de jul de 2018 às 14:30, Jay S Bryant
escreveu:
> All,
>
> I have created an etherpad to start planning for the Denver PTG in
> September. [1] Please start adding topics to the etherpad.
>
> Look forward to seeing you all there!
>
> Jay
>
> (jungleboyj)
>
> [1] https://eth
All,
I have created an etherpad to start planning for the Denver PTG in
September. [1] Please start adding topics to the etherpad.
Look forward to seeing you all there!
Jay
(jungleboyj)
[1] https://etherpad.openstack.org/p/cinder-ptg-planning-denver-9-2018
__
On Thu, Jul 5, 2018 at 6:17 PM, Doug Hellmann wrote:
> Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> > On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> > nishant.e.ku...@ericsson.com> wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I have registered a blueprint for addi
Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> nishant.e.ku...@ericsson.com> wrote:
>
> > Hi,
> >
> >
> >
> > I have registered a blueprint for adding http security headers -
> > https://blueprints.launchpad.net/cinder/+
On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
nishant.e.ku...@ericsson.com> wrote:
> Hi,
>
>
>
> I have registered a blueprint for adding http security headers -
> https://blueprints.launchpad.net/cinder/+spec/http-security-headers
>
>
>
> Reason for introducing this change - I work for AT&T
Hi,
I have registered a blueprint for adding http security headers -
https://blueprints.launchpad.net/cinder/+spec/http-security-headers
Reason for introducing this change - I work for AT&T cloud project - Network
Cloud (Earlier known as AT&T integrated Cloud). As part of working there we
have
Hi Sean,
thanks for the responce, my questions and comments below.
On 6/25/18 9:42 PM, Sean McGinnis wrote:
Not sure if it's an option for you, but in the Pike release support was added
to be able to extend attached volumes. There are several caveats with this
feature though. I believe it only
>
> In fact, I'm ok with delayed resize (upon power-cycle), and it's not an
> issue for me that VM don't detect changes immediately. What I want to
> understand is that changes to Cinder (and, thus, underlying changes to CEPH)
> are safe for VM while it's in active state.
>
No, this is not consi
On 06/23/2018 08:38 AM, Volodymyr Litovka wrote:
Dear friends,
I did some tests with making volume available without stopping VM. I'm using
CEPH and these steps produce the following results:
1) openstack volume set --state available [UUID]
- nothing changed inside both VM (volume is still conn
Hi Jay,
We have had similar issues with extending attached volumes that are
iSCSI based. In that case the VM has to be forced to rescan the scsi bus.
In this case I am not sure if there needs to be a change to Libvirt or
to rbd or something else.
I would recommend reaching out to John Berna
On Sat, Jun 23, 2018, 9:39 AM Volodymyr Litovka wrote:
> Dear friends,
>
> I did some tests with making volume available without stopping VM. I'm
> using CEPH and these steps produce the following results:
>
> 1) openstack volume set --state available [UUID]
> - nothing changed inside both VM (vo
Dear friends,
I did some tests with making volume available without stopping VM. I'm
using CEPH and these steps produce the following results:
1) openstack volume set --state available [UUID]
- nothing changed inside both VM (volume is still connected) and CEPH
2) openstack volume set --size [
Hi Thomas,
Yes. If you have more than 1 volume node, or 1 volume node with multiple
backends definitions. Each volume node should have at least one [backend]
that will point to your storage configuration. You can add that config for
each of them.
Erlon
Em sex, 15 de jun de 2018 às 09:52, Thomas
On Fri, 15 Jun 2018, Eric Fried wrote:
We just merged an initial pass at direct access to the placement service
[1]. See the test_direct suite for simple usage examples.
Note that this was written primarily to satisfy the FFU use case in
blueprint reshape-provider-tree [2] and therefore likely
We just merged an initial pass at direct access to the placement service
[1]. See the test_direct suite for simple usage examples.
Note that this was written primarily to satisfy the FFU use case in
blueprint reshape-provider-tree [2] and therefore likely won't have
everything cinder needs. So p
On 06/14/2018 01:10 PM, Erlon Cruz wrote:
> Hi Thomas,
>
> The reserved_percentage *is* taken in account for non thin provisoning
> backends. So you can use it to spare the space you need for backups. It
> is a per backend configuration.
Oh. Reading the doc, I thought it was only for thin provisi
On Thu, Jun 14, 2018 at 08:10:56AM -0300, Erlon Cruz wrote:
> Hi Thomas,
>
> The reserved_percentage *is* taken in account for non thin provisoning
> backends. So you can use it to spare the space you need for backups. It is
> a per backend configuration.
>
> If you have already tried to used it
On Thu, Jun 14, 2018 at 11:13:22AM +0200, Thomas Goirand wrote:
> Hi,
>
> When using cinder-backup, it first makes a snapshot, then sends the
> backup wherever it's configured. The issue is, to perform a backup, one
> needs to make a snapshot of a volume, meaning that one needs the size of
> the v
Hi Thomas,
The reserved_percentage *is* taken in account for non thin provisoning
backends. So you can use it to spare the space you need for backups. It is
a per backend configuration.
If you have already tried to used it and that is not working, please let us
know what release you are using, be
Hi,
When using cinder-backup, it first makes a snapshot, then sends the
backup wherever it's configured. The issue is, to perform a backup, one
needs to make a snapshot of a volume, meaning that one needs the size of
the volume as empty space to be able to make the snapshot.
So, let's say I have
On 6/7/2018 8:33 AM, Lucio Seki wrote:
Since Pike release, Cinder supports in-use volume extending [1].
By default, it assumes that every storage backend is able to perform
this operation.
Actually, by default, Tempest assumes that no backends support it, which
is why it's disabled by default
All,
I have gotten the Vancouver Summit Forum session recordings uploaded to
YouTube. You can see the links in our wiki here:
https://wiki.openstack.org/wiki/VancouverSummit2018Summary
Let me know if you have any questions.
Thanks!
Jay
___
Peter,
Thanks for getting that fixed. The associated patch has been removed so
we should be good now.
Jay
On 6/7/2018 9:15 AM, Peter Penchev wrote:
On Mon, Jun 04, 2018 at 02:40:09PM -0500, Sean McGinnis wrote:
Our CI has been chugging along since June 2nd (not really related to
the timin
On Mon, Jun 04, 2018 at 02:40:09PM -0500, Sean McGinnis wrote:
> >
> > Our CI has been chugging along since June 2nd (not really related to
> > the timing of your e-mail, it just so happened that we fixed another
> > small problem there). You can see the logs at
> >
> > http://logs.ci-openstac
Hi.
Since Pike release, Cinder supports in-use volume extending [1].
By default, it assumes that every storage backend is able to perform this
operation.
Thus, the tempest test for this feature should be enabled by default. A
patch was submitted to enable it [2].
Please note that, after this patc
>
> Our CI has been chugging along since June 2nd (not really related to
> the timing of your e-mail, it just so happened that we fixed another
> small problem there). You can see the logs at
>
> http://logs.ci-openstack.storpool.com/
>
Thanks Peter.
It looks like the reason the report run
Peter,
Thank you for the update. We are investigating why this shows up as
failing in our CI tracking list.
I will hold off on the associated patch.
Thank you for the quick response!
Jay
On 6/4/2018 2:07 PM, Peter Penchev wrote:
On Sat, Jun 02, 2018 at 06:13:23PM -0500, Jay S Bryant wrot
On Sat, Jun 02, 2018 at 06:13:23PM -0500, Jay S Bryant wrote:
> All,
>
> This note is to make everyone aware that I have submitted patches for a
> number of drivers that have not run 3rd party CI in 60 or more days. The
> following is a list of the drivers, how long since their CI last ran and
>
On 6/1/2018 7:28 PM, Chris Dent wrote:
On Wed, 9 May 2018, Chris Dent wrote:
I've started an etherpad for the forum session in Vancouver devoted
to discussing the possibility of tracking and allocation resources
in Cinder using the Placement service. This is not a done deal.
Instead the sessi
All,
This note is to make everyone aware that I have submitted patches for a
number of drivers that have not run 3rd party CI in 60 or more days.
The following is a list of the drivers, how long since their CI last ran
and links to the patches which mark them as unsupported drivers:
* Data
On Wed, 9 May 2018, Chris Dent wrote:
I've started an etherpad for the forum session in Vancouver devoted
to discussing the possibility of tracking and allocation resources
in Cinder using the Placement service. This is not a done deal.
Instead the session is to discuss if it could work and how
Just a reminder there is no meeting because ofthe summit today.
Jay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openst
Hi,
During the last OpenStack PTG, I announced in the Cinder room the
development of cinderlib, and explained how this library allowed any
Python application to use Cinder storage drivers (there are over 80)
without running any services.
This takes the standalone effort one step further. Now you
Hi All,
Problem description:
Monty Taylor added split-logger functionality in patch[1].
This functionality splits logs in four different logs:
* keystoneauth.session.request
* keystoneauth.session.response
* keystoneauth.session.body
* keystoneauth.session.requ
Team,
We discussed having a team dinner like we have done in the past during
today's team meeting. It sounded like most people would be available
Tuesday evening, so that is the evening I am planning for.
If you are able to attend please add your name to the etherpad [1] by
Sunday 5/20 so t
All,
I have etherpads created for our Cinder related Forum discussions:
* Tuesday, 5/22 11:00 to 11:40 - Room 221-222 - Cinder High
Availability (HA) Discussion
-https://etherpad.openstack.org/p/YVR18-cinder-ha-forum
* Tuesday, 5/22 11:50 to 12:30 - Room 221-222 - Multi-attach
Introdu
I've started an etherpad for the forum session in Vancouver devoted
to discussing the possibility of tracking and allocation resources
in Cinder using the Placement service. This is not a done deal.
Instead the session is to discuss if it could work and how to make
it happen if it seems like a go
On 04/12/2018 10:25 PM, 李俊波 wrote:
> Hello Nova, Cinder developers,
>
>
>
> I would like to ask you a question concerns a Cinder patch [1].
>
>
>
> In this patch, it mentioned that RBD features were incompatible with
> multi-attach, which disabled multi-attach for RBD. I would like to know
Hello Nova, Cinder developers,
I would like to ask you a question concerns a Cinder patch [1].
In this patch, it mentioned that RBD features were incompatible with
multi-attach, which disabled multi-attach for RBD. I would like to know
which RBD features that are incompatible?
In the Bu
On 09/04, Sean McGinnis wrote:
> On Mon, Apr 09, 2018 at 07:00:56PM +0100, Duncan Thomas wrote:
> > Hopefully this flow means we can do rebuild root filesystem from
> > snapshot/backup too? It seems rather artificially limiting to only do
> > restore-from-image. I'd expect restore-from-snap to be a
On 4/9/2018 1:00 PM, Duncan Thomas wrote:
Hopefully this flow means we can do rebuild root filesystem from
snapshot/backup too? It seems rather artificially limiting to only do
restore-from-image. I'd expect restore-from-snap to be a more common
use case, personally.
Hmm, now you've got me thin
On Mon, Apr 09, 2018 at 07:00:56PM +0100, Duncan Thomas wrote:
> Hopefully this flow means we can do rebuild root filesystem from
> snapshot/backup too? It seems rather artificially limiting to only do
> restore-from-image. I'd expect restore-from-snap to be a more common
> use case, personally.
>
Hopefully this flow means we can do rebuild root filesystem from
snapshot/backup too? It seems rather artificially limiting to only do
restore-from-image. I'd expect restore-from-snap to be a more common
use case, personally.
On 9 April 2018 at 09:51, Gorka Eguileor wrote:
> On 06/04, Matt Riedem
On 4/9/2018 3:51 AM, Gorka Eguileor wrote:
As I see it, the process would look something like this:
- Nova detaches volume using OS-Brick
- Nova calls Cinder re-image passing the node's info (like we do when
attaching a new volume)
- Cinder would:
- Ensure only that node is connected to th
On 06/04, Matt Riedemann wrote:
> On 4/6/2018 5:09 AM, Matthew Booth wrote:
> > I think you're talking at cross purposes here: this won't require a
> > swap volume. Apart from anything else, swap volume only works on an
> > attached volume, and as previously discussed Nova will detach and
> > re-at
On 4/6/2018 5:09 AM, Matthew Booth wrote:
I think you're talking at cross purposes here: this won't require a
swap volume. Apart from anything else, swap volume only works on an
attached volume, and as previously discussed Nova will detach and
re-attach.
Gorka, the Nova api Matt is referring to
On 6 April 2018 at 09:31, Gorka Eguileor wrote:
> On 05/04, Matt Riedemann wrote:
>> On 4/5/2018 3:15 AM, Gorka Eguileor wrote:
>> > But just to be clear, Nova will have to initialize the connection with
>> > the re-imagined volume and attach it again to the node, as in all cases
>> > (except when
On 05/04, Matt Riedemann wrote:
> On 4/5/2018 3:15 AM, Gorka Eguileor wrote:
> > But just to be clear, Nova will have to initialize the connection with
> > the re-imagined volume and attach it again to the node, as in all cases
> > (except when defaulting to downloading the image and dd-ing it to t
On 4/5/2018 3:15 AM, Gorka Eguileor wrote:
But just to be clear, Nova will have to initialize the connection with
the re-imagined volume and attach it again to the node, as in all cases
(except when defaulting to downloading the image and dd-ing it to the
volume) the result will be a new volume i
On 04/04, Matt Riedemann wrote:
> On 4/2/2018 6:59 AM, Gorka Eguileor wrote:
> > I can only see one benefit from implementing this feature in Cinder
> > versus doing it in Nova, and that is that we can preserve the volume's
> > UUID, but I don't think this is even relevant for this use case, so why
On 4/2/2018 6:59 AM, Gorka Eguileor wrote:
I can only see one benefit from implementing this feature in Cinder
versus doing it in Nova, and that is that we can preserve the volume's
UUID, but I don't think this is even relevant for this use case, so why
is it better to implement this in Cinder th
On 29/03, Sean McGinnis wrote:
> > This is the spec [0] about rebuild the volumed backed server.
> > The question raised in the spec is about how to bandle the root volume.
> > Finally,in Nova team,we think that the cleanest / best solution to this is
> > to
> > add a volume action API to ci
On 3/29/2018 8:36 PM, Matt Riedemann wrote:
On 3/29/2018 6:50 PM, Sean McGinnis wrote:
May we can add a "Reimaging" state to the volume? Then Nova could
poll for it
to go from that back to Available?
That would be fine with me, and maybe similar to how 'extending' and
'retyping' work for a
On 3/29/2018 6:50 PM, Sean McGinnis wrote:
May we can add a "Reimaging" state to the volume? Then Nova could poll for it
to go from that back to Available?
That would be fine with me, and maybe similar to how 'extending' and
'retyping' work for an attached volume?
Nova wouldn't wait for the
>
> >
> >Ideally, from my perspective, Nova would take care of the detach/attach
> >portion
> >and Cinder would only need to take care of imaging the volume.
>
> Agree. :) And yeah, I pointed this out in the nova spec for volume-backed
> rebuild also. I think nova can basically handle this like
On 3/29/2018 9:28 AM, Sean McGinnis wrote:
I do not think changing the revert to snapshot implementation is appropriate
here. There may be some cases where this can get the desired result, but there
is no guarantee that there is a snapshot on the volume's base image state to
revert to. It also wo
> This is the spec [0] about rebuild the volumed backed server.
> The question raised in the spec is about how to bandle the root volume.
> Finally,in Nova team,we think that the cleanest / best solution to this is to
> add a volume action API to cinder for re-imaging the volume.Once that is
Hi,all
This is the spec [0] about rebuild the volumed backed server.The question
raised in the spec is about how to bandle the root volume.Finally,in Nova
team,we think that the cleanest / best solution to this is to add a volume
action API to cinder for re-imaging the volume.Once that i
On 21/03, TommyLike Hu wrote:
> Hey Gorka,
> Thanks for your input:) I think I need to clarify that our idea is to
> share the backup resource to another tenants, that is different with
> transfer as the original tenant still can fully control the backup
> resource, and the tenants that have be
Hey Gorka,
Thanks for your input:) I think I need to clarify that our idea is to
share the backup resource to another tenants, that is different with
transfer as the original tenant still can fully control the backup
resource, and the tenants that have been shared to only have the ability to
se
On 20/03, Jay S Bryant wrote:
>
>
> On 3/19/2018 10:55 PM, TommyLike Hu wrote:
> > Now Cinder can transfer volume (with or without snapshots) to different
> > projects, and this make it possbile to transfer data across tenant via
> > volume or image. Recently we had a conversation with our custome
Sure! I will bring this to our weekly meeting when more feedbacks are
gathered : )
Jay S Bryant 于2018年3月21日周三 下午1:05写道：
> Tommy,
>
> I am still not sure that this is going to move the team to a different
> decision.
>
> Now that you have more information you can propose it as a topic in
> tomorro
Tommy,
I am still not sure that this is going to move the team to a different
decision.
Now that you have more information you can propose it as a topic in
tomorrow's team meeting if you wish.
Jay
On 3/20/2018 8:54 PM, TommyLike Hu wrote:
Thanks Jay,
The question is AWS doesn't have
Thanks Jay,
The question is AWS doesn't have the concept of backup and their
snapshot is incremental backup internally and will be finllay stored into
S3 which is more sound like backup for us. Our snapshot can not be used
across AZ.
Jay S Bryant 于2018年3月21日周三 上午4:13写道：
>
>
> On 3/19/2018 10:
On 3/19/2018 10:55 PM, TommyLike Hu wrote:
Now Cinder can transfer volume (with or without snapshots) to
different projects, and this make it possbile to transfer data across
tenant via volume or image. Recently we had a conversation with our
customer from Germany, they mentioned they are mo
Now Cinder can transfer volume (with or without snapshots) to different
projects, and this make it possbile to transfer data across tenant via
volume or image. Recently we had a conversation with our customer from
Germany, they mentioned they are more pleased if we can support transfer
data accros
We are getting test failures on both stable/pike and stable/ocata branches with
the error:
oslo_utils/versionutils.py", line 45, in is_compatible
if same_major and (requested_parts[0] != current_parts[0]):
TypeError: 'Version' object does not support indexing
This is due to a set
On 09/03, Sean McGinnis wrote:
>
> > On Mar 9, 2018, at 07:37, TommyLike Hu wrote:
> >
> > Thanks Gorka,
> > To be clear, I started this discussion not because I reject this
> > feature, instead I like it as it's much more clean and simple, compared
> > with performance impact it solves seve
Thomas,
Thanks for finding this. I have opened a bug and submitted a patch.
Patch: https://review.openstack.org/552134
Bug: https://bugs.launchpad.net/cinder/+bug/1755282
Jay
(jungleboyj)
On 3/12/2018 3:17 AM, Thomas Goirand wrote:
Hi,
When inspecting Cinder's (Queens release) cinder.c
On 2018-03-12 13:46:30 -0300 (-0300), Erlon Cruz wrote:
> I think I missed something about this. By Forum you mean Summit? Will that
> happen during the Vancouver Summit right? Will the forum be something
> similar to PTG? What is the target public? Operators, users admin?
Yes, the Forum takes pl
Thanks Jay, that helps a lot!
2018-03-06 18:46 GMT-03:00 Ivan Kolodyazhny :
> Jay, thanks a lot for this great summary!
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Tue, Mar 6, 2018 at 10:02 PM, Jay S Bryant
> wrote:
>
>> Team,
>>
>> I have collected all of our actions and ag
I think I missed something about this. By Forum you mean Summit? Will that
happen during the Vancouver Summit right? Will the forum be something
similar to PTG? What is the target public? Operators, users admin?
Erlon
2018-03-08 14:52 GMT-03:00 Jay S Bryant :
> All,
>
> I just wanted to share t
Excerpts from Thomas Goirand's message of 2018-03-12 09:17:19 +0100:
> Hi,
>
> When inspecting Cinder's (Queens release) cinder.conf, I can see:
>
> # Warning: Failed to format sample for my_ip
> # unhashable type: 'HostAddress'
This part sounds like it might be a bug in oslo.config, which
does
Hi,
When inspecting Cinder's (Queens release) cinder.conf, I can see:
# Warning: Failed to format sample for my_ip
# unhashable type: 'HostAddress'
So it seems there's an issue in either Cinder or Oslo. How can I
investigate and fix this?
It's very likely that I'm once more the only person in t
> On Mar 9, 2018, at 07:37, TommyLike Hu wrote:
>
> Thanks Gorka,
> To be clear, I started this discussion not because I reject this feature,
> instead I like it as it's much more clean and simple, compared with
> performance impact it solves several other issues which we hate badly. I
>
Thanks Gorka,
To be clear, I started this discussion not because I reject this
feature, instead I like it as it's much more clean and simple, compared
with performance impact it solves several other issues which we hate badly.
I wrote this is to point out we may have this issue, and to see whet
On 09/03, TommyLike Hu wrote:
> Hey all,
> During the Cinder and Manila's cross project discussion on quota system
> last week, I raise our concern of performance impact on the count resource
> feature, and Gorka pointed out we might miss some of the indexes when
> testing. So I reshaped the en
All,
I just wanted to share the fact that I have created the etherpad for
proposing topics for the Vancouver Forum. [1]
Please take a few moments to add topics there. I will need to propose
the topics we have in the next two weeks so this will need attention
before that point in time.
Th
On 06/03, 李杰 wrote:
> Hi,all
>
>
> This is the patch [0] about volume revert to snapshot with Ceph.Is
> anyone working on this patchset or maybe new patchset was proposed to
> implement RBD specific functionality?Can you tell me more about this ?Thank
> you very much.
> The link is h
Jay, thanks a lot for this great summary!
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Tue, Mar 6, 2018 at 10:02 PM, Jay S Bryant wrote:
> Team,
>
> I have collected all of our actions and agreements out of the three days
> of etherpads into the following summary page: [1] . The etherp
Team,
I have collected all of our actions and agreements out of the three days
of etherpads into the following summary page: [1] . The etherpad
includes links to the original etherpads and video clips.
I am planning to use the wiki to help guide our development during Rocky.
Let me know if
Hi,all
This is the patch [0] about volume revert to snapshot with Ceph.Is anyone
working on this patchset or maybe new patchset was proposed to implement RBD
specific functionality?Can you tell me more about this ?Thank you very much.
The link is here.
Re:https://review.openst
Met with Jay, looking at alternatives
On 2 Mar 2018 6:26 pm, "Duncan Thomas" wrote:
> I'm in the pub now, and they are closing down
>
> On 2 Mar 2018 5:48 pm, "Jay S. Bryant" wrote:
>
>> Ivan,
>>
>> I sent another note but will also respond in this thread.
>>
>> Yes, they will serve us tonight.
I'm in the pub now, and they are closing down
On 2 Mar 2018 5:48 pm, "Jay S. Bryant" wrote:
> Ivan,
>
> I sent another note but will also respond in this thread.
>
> Yes, they will serve us tonight. It is a somewhat limited menu but I
> stopped to look at it and it still looked good.
>
> Sidewa
Ivan,
I sent another note but will also respond in this thread.
Yes, they will serve us tonight. It is a somewhat limited menu but I
stopped to look at it and it still looked good.
Sidewalks on the way to the restaurant were not in too bad of shape.
Jay
On 3/2/2018 10:48 AM, Ivan Kolodyaz
Hi Jay,
Will Fagans serve us tonight?
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant wrote:
>
>
> On 3/1/2018 6:50 AM, Sean McGinnis wrote:
>
>> On Feb 28, 2018, at 16:58, Jay S Bryant wrote:
>>>
>>> Team,
>>>
>>> Just a reminder that we will be
101 - 200 of 2874 matches
Mail list logo
