+1000
On Wed, Nov 2, 2016 at 1:09 PM, Tom Barron wrote:
> I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
> manila core team. This is a clear case where he's already been doing
> the review work, excelling both qualitatively and quantitatively, as
> well as being a valu
This sounds like a good idea to me. The queue doesn't handle this since we
just read everything off immediately anyways. I have seen issues where
customers have to write scripts that build 5 volumes, sleep, then build
more until they get >100 volumes. Just because a Cinder volume service will
clobb
+1 I thought he was already! which is usually a good sign.
On Thu, May 5, 2016 at 1:39 PM, Mike Perez wrote:
> On 13:16 May 03, Sean McGinnis wrote:
> > Hey everyone,
> >
> > I would like to nominate Michał Dulko to the Cinder core team. Michał's
> > contributions with both code reviews [0] and
I'd like an answer on this specific issue. I agree with Chris and I wonder
if our goal is consistency across services or an ideal standard.
Nova has 'X-OpenStack-Nova-API-Version' and Manila has
'X-Openstack-Manila-Api-Version'. If we deviate from this, we should
suggest that those projects add th
9:30:23
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Glance] glance core rotation part 1
>
> > Hi,
> >
> > I would like to propose the following removals from glance-core based on
> > the simple criterion of inactivity/limited activity for a long period (
I don't know if this is really a big problem. IMO, even with microversions
you shouldn't be implementing things that aren't backwards compatible
within the major version. I thought the benefit of microversions is to know
if a given feature exists within the major version you are using. I would
cons
Hi Chen Li,
You are correct in that setting up a CI system is not a trivial task. IMO
it would make sense to have this eventually tested with infras
infrastructure but as Jeremy mentioned, they don't have the bandwidth to do
the setup. Below are some links to get started if you all are interested
Agreed, I'd also like to mention that rebranded arrays may differ slightly
in functionality as well so the CIs would need to run against a physical
rebranded device. These differences also justify the need for letting
rebranded drivers in.
-Alex
On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez wrote:
There is a spec to get this work started. It's currently a Heat spec:
https://review.openstack.org/#/c/186436/
That spec is for defining a basic schema to start with.
-Alex
On Mon, Jun 1, 2015 at 4:48 AM, Flavio Percoco wrote:
> On 28/05/15 16:48 +0100, Gordon Sim wrote:
>
>> On 05/27/2015 05:
So it seems that this will break a number of drivers, I see that glusterfs
does the same thing.
On Thu, May 7, 2015 at 10:29 PM, Alex Meade wrote:
> It appears that the release of taskflow 0.10.0 exposed an issue in the
> NetApp NFS drivers. Something changed that caused the sqlalchemy
It appears that the release of taskflow 0.10.0 exposed an issue in the
NetApp NFS drivers. Something changed that caused the sqlalchemy Volume
object to be garbage collected even though it is passed into create_volume()
An example error can be found in the c-vol logs here:
http://dcf901611175aa43
Hey Erlon,
The summit etherpad is here:
https://etherpad.openstack.org/p/liberty-cinder-async-reporting
It links to what we discussed in Paris. I will be filling it out this week.
Also note, I have submitted this topic for a cross-project session:
https://docs.google.com/spreadsheets/d/1vCTZBJKCM
I think there is a lot to discuss here and I would love to push for a
solution implemented in Liberty. I have a proposed summit session on this
topic (Asynchrounous Error Reporting). I also discussed this briefly at the
Kilo summit. I will work on formalizing some of these ideas and hopefully
we ca
We believe we have satisfied the required criteria [1] to have NetApp’s
fibre channel drivers included in the Kilo release. We have submitted a
revert patch [2] along with posting an ether pad [3] to provide more detail
on our progress. Thanks for your consideration.
[1]
http://lists.openstack.org
+1
On Thu, Apr 2, 2015 at 10:30 AM, Thomas Bechtold wrote:
> On 02.04.2015 15:16, Ben Swartzlander wrote:
> > Clinton Knight (cknight on IRC) has been working on OpenStack for the
> > better part of the year, and starting in February, he shifted his focus
> > from Cinder to Manila. I think every
As an Engineer running the NetApp CI, I thought it would be a good time to
chime in here. While I have many opinions around this whole process, I will
try my best to avoid any judgement and minimize ratholes.
Over the past year, we have implemented a scalable CI system that is now
running tests ag
Hey Henry/Folks,
I think it could make sense for Glance to store the volume UUID, the idea
is that no matter where an image is stored it should be *owned* by Glance
and not deleted out from under it. But that is more of a single tenant vs
multi tenant cinder store.
It makes sense for Cinder to at
tested against our storage
controllers and are not very complex. I would appreciate any consideration
for an FFE.
Thanks,
-Alex Meade
[1]
https://blueprints.launchpad.net/cinder/+spec/pool-aware-cinder-scheduler-support-in-netapp-drivers
[2] https://review.openstack.org/#/c/119436/
[3] https
Hey Folks,
The blueprint for Access Groups can be found here:
https://blueprints.launchpad.net/manila/+spec/access-groups
If you have a chance, please look through the proposal for the API
resources and DB schema changes here:
https://etherpad.openstack.org/p/manila-access-groups-api-proposal
-A
+100 it's about time!
On Thu, Jun 12, 2014 at 3:26 AM, Mark Washenberger <
mark.washenber...@markwash.net> wrote:
> Hi folks,
>
> I'd like to nominate Nikhil Komawar to join glance-core. His code and
> review contributions over the past years have been very helpful and he's
> been taking on a ve
Glance has the concept of 'protected properties' which is really just
policies around metadata. property = metadata in glance.
https://wiki.openstack.org/wiki/Glance-property-protections
-Alex
On Tue, May 6, 2014 at 6:50 AM, Duncan Thomas wrote:
> 'metadata' is a free form key-value space for
Just so everyone is aware. Glance supports 'delayed deletes' where image
data will not actually be deleted at the time of the request. Glance also
has the concept of 'protected images', which allows for setting an image as
protected, preventing it from being deleted until the image is
intentionally
I think I agree with you John. Micromanaging the common library just makes more
work. Is there any argument to not syncing everything? And do you mean
cherry-picking only some of the changes in a single module?!? if that's the
case then future syncing could get weird, really weird.
-Alex
-
their abandoned patches and restore any
that are still relevant.
Use this link to see your abandoned patches, just replace "alex-meade" with
your own launchpad id.
https://review.openstack.org/#/q/status:abandoned+project:openstack/glance+owner:alex-meade,n,z
Also, if you have any &qu
I don't know any actual numbers but I would have the concern that images tend
to stick around longer than instances. For example, if someone takes daily
snapshots of their server and keeps them around for a long time, the number of
exists events would go up and up.
Just a thought, could be a va
another -1 from me for dropping it from hacking.
I've been bitten by both lack of explicit usage and review bikeshedding on this
exact thing.
-Alex
-Original Message-
From: "Sean Dague"
Sent: Tuesday, August 6, 2013 7:32am
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-d
+1 to everything Russell just said and of course Blueprints for this. One for
#3 (changing from mox -> Mock) would be good so that anyone who is bored or
finds this urgent can collaborate. Also, we need to make sure reviewers are
aware (Hopefully they are reading this).
-Alex
-Original Mes
+1 I prefer mock over mox as well. It's more readable and intuitive. I've had a
number of bad mox experiences lately so I'm a tad biased.
-Alex
-Original Message-
From: "Jay Pipes"
Sent: Wednesday, July 24, 2013 2:24pm
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] U
28 matches
Mail list logo
