Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

[Erlon Cruz]

PS. Don't forget that if you change or disable AppArmor you will have to
reboot the host so the kernel gets reloaded.

Em qua, 24 de out de 2018 às 09:40, Erlon Cruz 
escreveu:

> I think that there's a change that AppArmor is blocking the access. Have
> you checked the dmesg messages related with apparmor?
>
> Em sex, 19 de out de 2018 às 09:38, Neil Jerram  escreveu:
>
>> Wracking my brains over this one, would appreciate any pointers...
>>
>> Setup: Small test deployment with just 3 compute nodes, Queens on Ubuntu
>> Bionic. The first compute node is an NFS server for
>> /var/lib/nova/instances, and the other compute nodes mount that as NFS
>> clients.
>>
>> Problem: Sometimes, when launching an instance which is scheduled to one
>> of the client nodes, nova-compute (in imagebackend.py) gets Permission
>> Denied (errno 13) when calling utime to touch the timestamp on the instance
>> file.
>>
>> Through various bits of debugging and hackery, I've established that:
>>
>> - it looks like the problem never occurs when this is the call that
>> bootstraps the privsep setup; but it does occur quite frequently on later
>> calls
>>
>> - when the problem occurs, retrying doesn't help (5 times, with 0.5s in
>> between)
>>
>> - the instance file does exist, and is owned by root with read/write
>> permission for root
>>
>> - the privsep helper is running as root
>>
>> - the privsep helper receives and executes the request - so it's not a
>> problem with communication between nova-compute and the helper
>>
>> - root is uid 0 on both NFS server and client
>>
>> - NFS setup does not have the root_squash option
>>
>> - there is some AppArmor setup, on both client and server, and I haven't
>> yet worked out whether that might be relevant.
>>
>> Any ideas?
>>
>> Many thanks,
>>   Neil
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][NFS] Inexplicable utime permission denied when launching instance

[Erlon Cruz]

I think that there's a change that AppArmor is blocking the access. Have
you checked the dmesg messages related with apparmor?

Em sex, 19 de out de 2018 às 09:38, Neil Jerram  escreveu:

> Wracking my brains over this one, would appreciate any pointers...
>
> Setup: Small test deployment with just 3 compute nodes, Queens on Ubuntu
> Bionic. The first compute node is an NFS server for
> /var/lib/nova/instances, and the other compute nodes mount that as NFS
> clients.
>
> Problem: Sometimes, when launching an instance which is scheduled to one
> of the client nodes, nova-compute (in imagebackend.py) gets Permission
> Denied (errno 13) when calling utime to touch the timestamp on the instance
> file.
>
> Through various bits of debugging and hackery, I've established that:
>
> - it looks like the problem never occurs when this is the call that
> bootstraps the privsep setup; but it does occur quite frequently on later
> calls
>
> - when the problem occurs, retrying doesn't help (5 times, with 0.5s in
> between)
>
> - the instance file does exist, and is owned by root with read/write
> permission for root
>
> - the privsep helper is running as root
>
> - the privsep helper receives and executes the request - so it's not a
> problem with communication between nova-compute and the helper
>
> - root is uid 0 on both NFS server and client
>
> - NFS setup does not have the root_squash option
>
> - there is some AppArmor setup, on both client and server, and I haven't
> yet worked out whether that might be relevant.
>
> Any ideas?
>
> Many thanks,
>   Neil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Erlon Cruz]

Theres also this document with very detailed information:

https://docs.google.com/spreadsheets/d/18ZtWC75BNCwFqLfFpCGGJ9uPVBvUXX0xuXP1yYG0NDA/edit#gid=0

Erlon

Em qui, 18 de out de 2018 às 10:30, Jay S Bryant 
escreveu:

>
>
> On 10/18/2018 7:21 AM, Sean McGinnis wrote:
> > On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:
> >> On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:
> >>> As you may know, unfortunately, Horizon doesn't support all features
> >>> provided by APIs. That's why we created feature gaps list [1].
> >>>
> >>> I'd got a lot of great conversations with projects teams during the PTG
> >>> and we tried to figure out what should be done prioritize these tasks.
> >>> It's really helpful for Horizon to get feedback from other teams to
> >>> understand what features should be implemented next.
> >>>
> >>> While I'm filling launchpad with new bugs and blueprints for [1], it
> >>> would be good to review this list again and find some volunteers to
> >>> decrease feature gaps.
> >>>
> >>> [1] https://etherpad.openstack.org/p/horizon-feature-gap
> >>>
> >>> Thanks everybody for any of your contributions to Horizon.
> >> +openstack-sigs
> >> +openstack-operators
> >>
> >> I've left some notes for nova. This looks very similar to the compute
> API
> >> OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what
> to
> >> really work on without some user/operator feedback - maybe we can get
> the
> >> user work group involved in trying to help prioritize what people really
> >> want that is missing from horizon, at least for compute?
> >>
> >> [1]
> https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt
> > I also have a cinderclient OSC gap analysis I've started working on. It
> might
> > be useful to add a Horizon column to this list too.
> >
> > https://ethercalc.openstack.org/cinderclient-osc-gap
> I had forgotten that we had this.  I have added it to the persistent
> links at the top of our meeting agenda page so we have it for future
> reference.  Did the same for the Horizon Feature Gaps.  Think it would
> be good to heave those somewhere that we see them and are reminded about
> them.
>
> Thanks!
> Jay
> > Sean
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [manila] nominating Amit Oren for manila core

[Erlon Cruz]

Hey Amit,

Welcome!

Em ter, 9 de out de 2018 às 16:52, Tom Barron  escreveu:

> On 02/10/18 13:58 -0400, Tom Barron wrote:
> >Amit Oren has contributed high quality reviews in the last
> >couple of cycles so I would like to nominated him for manila
> >core.
> >
> >Please respond with your +1 or -1 votes.  We'll hold voting
> >open for 7 days.
> >
> >Thanks,
> >
> >-- Tom Barron (tbarron)
> >
>
> We've had lots of +1s for Amit Oren as manila core and no -1s so I've
> added him.
>
> Welcome, Amit!
>
> -- Tom
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][qa] Enabling online volume_extend tests by default

[Erlon Cruz]

Hi Ghanshyam,


Though I have concern over running those tests by default(making config
> options True by default), because it is not confirmed all cinder backends
> implements this functionality and it only works for nova libvirt driver. We
> need to keep config options default as False and Devstack/CI can make it
> True to run the tests.
>
>
The discussion on the PTG was about whether we should run this on gate to
actually break the CIs. Once that happens, vendors will have 3 options:

#1: fix their drivers by properly implementing  volume_extend and run
the positive tests
#2: fix their drivers by reporting that they not support volume_extend
and run the negative tests
#3: disable volume extend tests at all (not recommendable), but this
still give us a hint on whether the vendor supports this or not


> If this feature becomes mandatory functionality (or cinder say standard
> feature i think) to implement for every backends and it work with all nova
> driver also(in term of instance action events) then, we can enable this
> feature tests by default. But until then, we should keep them disable by
> default in Tempest but we can enable them on gate via Devstack (patch you
> mentioned) and test them daily on integrated-gate.
>

Its not mandatory that the driver must implement online_extend, but if the
driver does not support it, the driver should report as so.


> Overall, I am ok with Devstack change to make these tests enable for every
> Cinder backends but we need to keep the config options false in Tempest.
>

So, the outcome from the PTG was that we would first merge the tempest test
and give time for vendors to get the drivers fixed. Then we would change it
in devstack so we push vendor to fix their drivers in case they hadn't done
that.

Erlon



>
> I will review those patch and leave comments on gerrit (i saw those patch
> introduce new config option than using the existing one)
>
> -gmann
>
>  > Please let us know if you have any question or concerns about it.
>  > Kind regards,Erlon_[1]
> https://review.openstack.org/#/c/572188/[2]
> https://review.openstack.org/#/c/578463/
> __
>  > OpenStack Development Mailing List (not for usage questions)
>  > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

[Erlon Cruz]

If you are planning to re-image an image on a bootable volume then yes you
should use a force parameter. I have lost the discussion about this on PTG.
What is the main use cases? This seems to me something that could be
leveraged with the current revert-to-snapshot API, which would be even
better. The flow would be:

1 - create a volume from image
2 - create an snapshot
3 - do whatever you wan't
4 - revert the snapshot

Would that help in your the use cases?

Em seg, 8 de out de 2018 às 10:54, Sean McGinnis 
escreveu:

> On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote:
> > In Denver, we agree to add a new "re-image" API in cinder to support
> upport
> > volume-backed server rebuild with a new image.
> >
> > An initial blueprint has been drafted in [3], welcome to review it,
> thanks.
> > : )
> >
> > [snip]
> >
> > The "force" parameter idea comes from [4], means that
> > 1. we can re-image an "available" volume directly.
> > 2. we can't re-image "in-use"/"reserved" volume directly.
> > 3. we can only re-image an "in-use"/"reserved" volume with "force"
> > parameter.
> >
> > And it means nova need to always call re-image API with an extra "force"
> > parameter,
> > because the volume status is "in-use" or "reserve" when we rebuild the
> > server.
> >
> > *So, what's you idea? Do we really want to add this "force" parameter?*
> >
>
> I would prefer we have the "force" parameter, even if it is something that
> will
> always be defaulted to True from Nova.
>
> Having this exposed as a REST API means anyone could call it, not just Nova
> code. So as protection from someone doing something that they are not
> really
> clear on the full implications of, having a flag in there to guard volumes
> that
> are already attached or reserved for shelved instances is worth the very
> minor
> extra overhead.
>
> > [1] https://etherpad.openstack.org/p/nova-ptg-stein L483
> > [2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild
> L12
> > [3] https://review.openstack.org/#/c/605317
> > [4]
> >
> https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75
> >
> > Regards,
> > Yikun
> > 
> > Jiang Yikun（Kero）
> > Mail: yikunk...@gmail.com
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][qa] Enabling online volume_extend tests by default

[Erlon Cruz]

Hey folks,

Following up on the discussions that we had on the Denver PTG, the Cinder
team
is planning to enable online volume_extend tests[1] to be run by default.
Currently,
those tests are only run by some CI systems and infra jobs that explicitly
set it to
be so.

We are also adding a negative test and an associated option  in tempest[2]
to allow
vendor drivers that does not support online extending to be tested. This
patch will
be merged first and after a reasonable time for people check whether their
backends supports that or not, we will proceed and merge the devstack
patch[1]
triggering the tests in all CIs and infra jobs.

Please let us know if you have any question or concerns about it.

Kind regards,
Erlon
_
[1] https://review.openstack.org/#/c/572188/
[2] https://review.openstack.org/#/c/578463/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full?

[Erlon Cruz]

Em seg, 1 de out de 2018 às 05:26, Balázs Gibizer <
balazs.gibi...@ericsson.com> escreveu:

>
>
> On Sat, Sep 29, 2018 at 10:35 PM, Matt Riedemann 
> wrote:
> > Nova, cinder and tempest run the nova-multiattach job in their check
> > and gate queues. The job was added in Queens and was a specific job
> > because we had to change the ubuntu cloud archive we used in Queens
> > to get multiattach working. Since Rocky, devstack defaults to a
> > version of the UCA that works for multiattach, so there isn't really
> > anything preventing us from running the tempest multiattach tests in
> > the integrated gate. The job tries to be as minimal as possible by
> > only running tempest.api.compute.* tests, but it still means spinning
> > up a new node and devstack for testing.
> >
> > Given the state of the gate recently, I'm thinking it would be good
> > if we dropped the nova-multiattach job in Stein and just enable the
> > multiattach tests in one of the other integrated gate jobs.
>
> +1
>
> > I initially was just going to enable it in the nova-next job, but we
> > don't run that on cinder or tempest changes. I'm not sure if
> > tempest-full is a good place for this though since that job already
> > runs a lot of tests and has been timing out a lot lately [1][2].
> >
> > The tempest-slow job is another option, but cinder doesn't currently
> > run that job (it probably should since it runs volume-related tests,
> > including the only tempest tests that use encrypted volumes).
>
> If the multiattach test qualifies as a slow test then I'm in favor of
> adding it to the tempest-slow and not lengthening the tempest-full
> further.
>
> +1 On having this on tempest-slow and add this to Cinder, provided that it
would also cover encryption .


> gibi
>
> >
> > Are there other ideas/options for enabling multiattach in another job
> > that nova/cinder/tempest already use so we can drop the now mostly
> > redundant nova-multiattach job?
> >
> > [1] http://status.openstack.org/elastic-recheck/#1686542
> > [2] http://status.openstack.org/elastic-recheck/#1783405
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Erlon Cruz]

I don't know if our workflow supports this, but it would be nice to have a
place to
place cross-projec changes like that (something like,
openstack-cross-projects-specs),
and use that as a initial point for high level discussions. But for now,
you can start creating
specs for the projects involved.

When you do so, please bring the topic to the project weekly
meetings[1][2][3] so you can get
some attention and feedback.

Erlon
___
[1] https://wiki.openstack.org/wiki/Meetings/Glance
[2] https://wiki.openstack.org/wiki/Meetings/Nova
[3] https://wiki.openstack.org/wiki/CinderMeetings



Em qui, 27 de set de 2018 às 22:51, hao wang 
escreveu:

> +1 to Julia's suggestion, Cinder should also have a spec to discuss
> the detail about how to implement the creation of volume from an
> encrypted image.
> Julia Kreger  于2018年9月28日周五 上午9:39写道：
> >
> > Greetings!
> >
> > I suspect the avenue of at least three different specs is likely going
> > to be the best path forward and likely what will be required for each
> > project to fully understand how/what/why. From my point of view, I'm
> > quite interested in this from a Nova point of view because that is the
> > initial user interaction point for majority of activities. I'm also
> > wondering if this is virt driver specific, or if it can be applied to
> > multiple virt drivers in the nova tree, since each virt driver has
> > varying constraints. So maybe the best path forward is something nova
> > centric to start?
> >
> > -Julia
> >
> > On Thu, Sep 27, 2018 at 10:36 AM Markus Hentsch
> >  wrote:
> > >
> > > Dear OpenStack developers,
> > >
> > > we would like to propose the introduction of an encrypted image format
> > > in OpenStack. We already created a basic implementation involving Nova,
> > > Cinder, OSC and Glance, which we'd like to contribute.
> > >
> > > We originally created a full spec document but since the official
> > > cross-project contribution workflow in OpenStack is a thing of the
> past,
> > > we have no single repository to upload it to. Thus, the Glance team
> > > advised us to post this on the mailing list [1].
> > >
> > > Ironically, Glance is the least affected project since the image
> > > transformation processes affected are taking place elsewhere (Nova and
> > > Cinder mostly).
> > >
> > > Below you'll find the most important parts of our spec that describe
> our
> > > proposal - which our current implementation is based on. We'd love to
> > > hear your feedback on the topic and would like to encourage all
> affected
> > > projects to join the discussion.
> > >
> > > Subsequently, we'd like to receive further instructions on how we may
> > > contribute to all of the affected projects in the most effective and
> > > collaborative way possible. The Glance team suggested starting with a
> > > complete spec in the glance-specs repository, followed by individual
> > > specs/blueprints for the remaining projects [1]. Would that be alright
> > > for the other teams?
> > >
> > > [1]
> > >
> http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html
> > >
> > > Best regards,
> > > Markus Hentsch
> > >
> > [trim]
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg][cinder] Stein PTG Summary Page Ready ...

[Erlon Cruz]

Thanks Jay!

Em qua, 19 de set de 2018 às 06:53, Gorka Eguileor 
escreveu:

> On 18/09, Jay S Bryant wrote:
> > Team,
> >
> > I have put together the following page with a summary of all our
> discussions
> > at the PTG: https://wiki.openstack.org/wiki/CinderSteinPTGSummary
> >
> > Please review the contents and let me know if anything needs to be
> changed.
> >
> > Jay
> >
> >
>
> Hi Jay,
>
> Thank you for the great summary, it looks great.
>
> After reading it, I can't think of anything that's missing.
>
> Cheers,
> Gorka.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

[Erlon Cruz]

Nice, good to know. Thanks all for the feedback. We will fix that in our
drivers.

@Walter, so, in this case, if Cinder has the connector, it should not need
to call the driver passing a None object right?

Erlon

Em qua, 18 de jul de 2018 às 12:56, Walter Boring 
escreveu:

> The whole purpose of this test is to simulate the case where Nova doesn't
> know where the vm is anymore,
> or may simply not exist, but we need to clean up the cinder side of
> things.   That being said, with the new
> attach API, the connector is being saved in the cinder database for each
> volume attachment.
>
> Walt
>
> On Wed, Jul 18, 2018 at 5:02 AM, Gorka Eguileor 
> wrote:
>
>> On 17/07, Sean McGinnis wrote:
>> > On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote:
>> > > Hi Cinder and Nova folks,
>> > >
>> > > Working on some tests for our drivers, I stumbled upon this tempest
>> test
>> > > 'force_detach_volume'
>> > > that is calling Cinder API passing a 'None' connector. At the time
>> this was
>> > > added several CIs
>> > > went down, and people started discussing whether this
>> (accepting/sending a
>> > > None connector)
>> > > would be the proper behavior for what is expected to a driver to
>> do[1]. So,
>> > > some of CIs started
>> > > just skipping that test[2][3][4] and others implemented fixes that
>> made the
>> > > driver to disconnected
>> > > the volume from all hosts if a None connector was received[5][6][7].
>> >
>> > Right, it was determined the correct behavior for this was to
>> disconnect the
>> > volume from all hosts. The CIs that are skipping this test should stop
>> doing so
>> > (once their drivers are fixed of course).
>> >
>> > >
>> > > While implementing this fix seems to be straightforward, I feel that
>> just
>> > > removing the volume
>> > > from all hosts is not the correct thing to do mainly considering that
>> we
>> > > can have multi-attach.
>> > >
>> >
>> > I don't think multiattach makes a difference here. Someone is forcibly
>> > detaching the volume and not specifying an individual connection. So
>> based on
>> > that, Cinder should be removing any connections, whether that is to one
>> or
>> > several hosts.
>> >
>>
>> Hi,
>>
>> I agree with Sean, drivers should remove all connections for the volume.
>>
>> Even without multiattach there are cases where you'll have multiple
>> connections for the same volume, like in a Live Migration.
>>
>> It's also very useful when Nova and Cinder get out of sync and your
>> volume has leftover connections. In this case if you try to delete the
>> volume you get a "volume in use" error from some drivers.
>>
>> Cheers,
>> Gorka.
>>
>>
>> > > So, my questions are: What is the best way to fix this problem? Should
>> > > Cinder API continue to
>> > > accept detachments with None connectors? If, so, what would be the
>> effects
>> > > on other Nova
>> > > attachments for the same volume? Is there any side effect if the
>> volume is
>> > > not multi-attached?
>> > >
>> > > Additionally to this thread here, I should bring this topic to
>> tomorrow's
>> > > Cinder's meeting,
>> > > so please join if you have something to share.
>> > >
>> >
>> > +1 - good plan.
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][nova] Proper behavior for os-force_detach

[Erlon Cruz]

Hi Cinder and Nova folks,

Working on some tests for our drivers, I stumbled upon this tempest test
'force_detach_volume'
that is calling Cinder API passing a 'None' connector. At the time this was
added several CIs
went down, and people started discussing whether this (accepting/sending a
None connector)
would be the proper behavior for what is expected to a driver to do[1]. So,
some of CIs started
just skipping that test[2][3][4] and others implemented fixes that made the
driver to disconnected
the volume from all hosts if a None connector was received[5][6][7].

While implementing this fix seems to be straightforward, I feel that just
removing the volume
from all hosts is not the correct thing to do mainly considering that we
can have multi-attach.

So, my questions are: What is the best way to fix this problem? Should
Cinder API continue to
accept detachments with None connectors? If, so, what would be the effects
on other Nova
attachments for the same volume? Is there any side effect if the volume is
not multi-attached?

Additionally to this thread here, I should bring this topic to tomorrow's
Cinder's meeting,
so please join if you have something to share.

Erlon

___
[1] https://bugs.launchpad.net/cinder/+bug/1686278
[2]
https://openstack-ci-logs.aws.infinidat.com/14/578114/2/check/dsvm-tempest-infinibox-fc/14fa930/console.html
[3]
http://54.209.116.144/14/578114/2/check/kaminario-dsvm-tempest-full-iscsi/ce750c8/console.html
[4]
http://logs.openstack.netapp.com/logs/14/578114/2/upstream-check/cinder-cDOT-iSCSI/8e2c549/console.html#_2018-07-16_20_06_16_937286
[5]
https://review.openstack.org/#/c/551832/1/cinder/volume/drivers/dell_emc/vnx/adapter.py
[6]
https://review.openstack.org/#/c/550324/2/cinder/volume/drivers/hpe/hpe_3par_common.py
[7]
https://review.openstack.org/#/c/536778/2/cinder/volume/drivers/infinidat.py
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Planning Etherpad for Denver 2018 PTG

[Erlon Cruz]

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://etherpad.openstack.org/p/cinder-ptg-planning-denver-9-2018
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [PTG] Updates!

[Erlon Cruz]

+1 on the game night! Reserve a room only for that :)

Em qua, 20 de jun de 2018 às 15:25, Kendall Nelson 
escreveu:

> Hello Everyone!
>
> Wanted to give you some updates on PTG4 planning. We have finalized the
> list of SIGs/ Groups/WGs/Teams that are attending. They are as follows:
>
>-
>
>Airship
>-
>
>API SIG
>-
>
>Barbican/Security SIG
>-
>
>Blazar
>-
>
>Chef OpenStack
>-
>
>Cinder
>-
>
>Cyborg
>-
>
>Designate
>-
>
>Documentation
>-
>
>Edge Computing Group
>-
>
>First Contact SIG
>-
>
>Glance
>-
>
>Heat
>-
>
>Horizon
>-
>
>Infrastructure
>-
>
>Interop WG
>
>
>-
>
>Ironic
>-
>
>Kata
>-
>
>Keystone
>-
>
>Kolla
>-
>
>LOCI
>-
>
>Manila
>-
>
>Masakari
>-
>
>Mistral
>-
>
>Monasca
>-
>
>Neutron
>-
>
>Nova
>-
>
>Octavia
>-
>
>OpenStack Ansible
>-
>
>OpenStack Charms
>-
>
>OpenStack Helm
>-
>
>OpenStackClient
>
>
>
>-
>
>Operator Meetup
>Puppet OpenStack
>-
>
>QA
>-
>
>Oslo
>-
>
>Public Cloud WG
>-
>
>Release Management
>-
>
>Requirements
>-
>
>Sahara
>-
>
>Scientific SIG
>-
>
>Self-Healing SIG
>-
>
>SIG- K8s
>-
>
>StarlingX
>-
>
>Swift
>-
>
>TC
>-
>
>TripleO
>-
>
>Upgrades SIG
>-
>
>Watcher
>-
>
>Zuul (pending confirmation)
>
> Thierry and I are working on placing them into a strawman schedule to
> reduce conflicts between related or overlapping groups. We should have more
> on what that will look like and a draft for you all to review in the next
> few weeks.
>
> We also wanted to remind you all of the Travel Support Program. We are
> again doing a two phase selection. The first deadline is approaching: July
> 1st. At this point we have less than a dozen applicants so if you need it
> or even think you need it, I urge you to apply here[1].
>
> Also! Reminder that we have a finite number of rooms in the hotel block so
> please book early to make sure you get the discounted rate before they run
> out. You can book those rooms here[2] (pardon the ugly URL).
>
> Can't wait to see you all there!
>
> -Kendall Nelson (diablo_rojo)
>
> P.S. Gonna try to do a game night again since you all seemed to enjoy it
> so much last time :)
>
> [1]
> https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018
>
> [2]
> https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

[Erlon Cruz]

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 Goirand 
escreveu:

> 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 provisioning, it's
> nice if it works with "normal" cinder LVM then ... :P
>
> When you say "per backend", does it means it can be set differently on
> each volume node?
>
> > If you have already tried to used it and that is not working, please let
> > us know what release you are using, because despite this being the
> > current (and proper) behavior, it might not being like this in the past.
> >
> > Erlon
>
> Will do, thanks.
>
> Cheers,
>
> Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

[Erlon Cruz]

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, because despite this being the current
(and proper) behavior, it might not being like this in the past.

Erlon

Em qui, 14 de jun de 2018 às 06:13, Thomas Goirand 
escreveu:

> 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 a cinder volume of 1 TB, this mean I need 1 TB as
> empty space on the volume node so I can do a backup of that volume.
>
> My question is: is there a way to tell cinder to reserve an amount of
> space for this kind of operation? The only thing I saw was
> reserved_percentage, but this looks like for thin provisioning only. If
> this doesn't exist, would such new option be accepted by the Cinder
> community, as a per volume node option? Or should we do it as a global
> setting?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] cinder-api image doesn't run as a cinder user.

[Erlon Cruz]

Thanks!

Em seg, 11 de jun de 2018 às 11:07, Eduardo Gonzalez 
escreveu:

> Hi,
>
> See a global openstack goal to move into wsgi
> https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
> And spec for cinder
>
>
> https://review.openstack.org/#/c/192683/6/specs/liberty/non-eventlet-wsgi-app.rst
>
> Regards
>
> 2018-06-11 14:36 GMT+02:00 Erlon Cruz :
>
>> Hi Eduardo,
>>
>> Just for curiosity, do you know the motivation why many OS services were
>> moved to run on apache instead of just listen? Any reference about that?
>>
>> Erlon
>>
>> Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
>> escreveu:
>>
>>> Hi,
>>>
>>> From Pike cinder-api only runs as a wsgi process and container has been
>>> migrated into an apache process, currenty we run apache as root user and
>>> not as service's user.
>>>
>>> Regards
>>>
>>>
>>>
>>> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>>>
>>>> Hi, stackers.
>>>>
>>>> We are distributing OpenStack to kubernetes using the docker image
>>>> generated by kolla. I recently upgraded from ocata to pike and found
>>>> that the cinder-api container does not run as a cinder user.
>>>> So it does not pass our unit test.
>>>>
>>>> This seems to have been fixed in the following code,
>>>>
>>>> https://review.openstack.org/#/c/463535/2/docker/cinder/cinder-api/Dockerfile.j2,unified
>>>>
>>>> Is there a reason why it should not be run as a cinder user? Other
>>>> services except cinder-api (cinder-scheduler, cinder-volume,
>>>> cinder-backup) are all running as cinder user. If this is a simple bug, try
>>>> to fix it.
>>>>
>>>> Thanks.
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] cinder-api image doesn't run as a cinder user.

[Erlon Cruz]

Hi Eduardo,

Just for curiosity, do you know the motivation why many OS services were
moved to run on apache instead of just listen? Any reference about that?

Erlon

Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
escreveu:

> Hi,
>
> From Pike cinder-api only runs as a wsgi process and container has been
> migrated into an apache process, currenty we run apache as root user and
> not as service's user.
>
> Regards
>
>
>
> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>
>> Hi, stackers.
>>
>> We are distributing OpenStack to kubernetes using the docker image
>> generated by kolla. I recently upgraded from ocata to pike and found
>> that the cinder-api container does not run as a cinder user.
>> So it does not pass our unit test.
>>
>> This seems to have been fixed in the following code,
>>
>> https://review.openstack.org/#/c/463535/2/docker/cinder/cinder-api/Dockerfile.j2,unified
>>
>> Is there a reason why it should not be run as a cinder user? Other
>> services except cinder-api (cinder-scheduler, cinder-volume,
>> cinder-backup) are all running as cinder user. If this is a simple bug, try
>> to fix it.
>>
>> Thanks.
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][ptg] PTG Summary Now Available ...

[Erlon Cruz]

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 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 you have any questions or concerns over the content.
>>
>> Thanks!
>>
>> Jay
>>
>> (jungleboyj)
>>
>> [1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][summit] Forum topic proposal etherpad created ...

[Erlon Cruz]

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 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.
>
> Thanks!
>
> Jay
>
> (jungleboyj)
>
> [1] https://etherpad.openstack.org/p/YVR-cinder-brainstorming
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][cinder]Question about cinder as glance store

[Erlon Cruz]

That will depend on the Cinder/OS-brick iscsiadm versions right? Can you
tell what are the versions from where the problem was fixed?

Erlon

2018-02-07 8:27 GMT-02:00 Gorka Eguileor :

> On 07/02, Rikimaru Honjo wrote:
> > Hello,
> >
> > I'm planning to use cinder as glance store.
> > And, I'll setup cinder to connect storage by iSCSI multipath.
> >
> > In this case, can I run glance-api and cinder-volume on the same node?
> >
> > In my understanding, glance-api will attach a volume to own node and
> > write a uploaded image to the volume if glance backend is cinder.
> > I afraid that the race condition of cinder-volume's iSCSI operations
> > and glance-api's iSCSI operations.
> > Is there possibility of occurring it?
> > --
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> > Rikimaru Honjo
> > E-mail:honjo.rikim...@po.ntt-tx.co.jp
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Hi,
>
> When properly set with the right configuration and the right system and
> OpenStack packages, Cinder, OS-Brick, and Nova no longer have race
> conditions with iSCSI operations anymore (single or multipathed), not
> even with drivers that do "shared target".
>
> So I would assume that Glance won't have any issues either as long as
> it's properly making the Cinder and OS-Brick calls.
>
> Cheers,
> Gorka.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Deprecation of Kaminario and Pure automatic calculation for max_over_subscription_ratio

[Erlon Cruz]

Folks,

In the Queens release, Cinder has implemented an internal mechanism to
automatically calculate the max_over_subscription_ratio[1]. As Kaminario
and Pure drivers already have a config option and are doing that
internally, we kindly recommend that the driver maintainers deprecate those
options in favor of the more generic option
(max_over_subscription_ratio=auto) in order to maintain a better more
consistent behavior among drivers.

You can find me (erlon) at #openstack-cinder if you have any further
questions.

Sincerely,
Erlon


[1] https://review.openstack.org/#/c/534854/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Leaving the Cinder Core team

[Erlon Cruz]

Hey Scott,

Very sorry too, to see you go. My best wishes in your new position.

Erlon

2017-12-11 18:00 GMT-02:00 Jay S Bryant :

> Scott,
>
> Very sorry to have you go.  Thank you for letting us know that you won't
> be able to continue participating.  It has been a pleasure to work with you
> over the years and hope we will continue to cross paths.
>
> Best wishes and keep in touch!
>
> Sincerely,
>
> Jay
>
>
>
> On 12/11/2017 1:11 PM, Scott D'Angelo wrote:
>
> It is with mixed feelings that I announce my resignation from the
> OpenStack Cinder core reviewer team.
> It has been a great pleasure to watch the OpenStack project evolve over
> the years I have participated, and bit of sadness to move into a new role
> at work where I am no longer involved.
> After changing jobs I had attempted to keep up with Cinder reviews, but I
> clearly have not participated in a few months now. I appreciate Cinder and
> the other teams I've worked with in the OpenStack project, and consider the
> time I spent working with you all one of the best jobs I have had. I do
> not, however, think I will be able to keep up with reviews in the future,
> so I should go ahead and resign.
> Please feel free to contact me anytime about Cinder or for any other
> reason.
>
> scottda
> Scott D'Angelo
> scott.dang...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][3rd-party ci] Voting INSPUR-CI

[Erlon Cruz]

Do you have the patch link? I don't see any report of it[1].



[1] http://ci-watch.tintri.com/project?project=cinder=7+days

On Mon, Sep 18, 2017 at 6:40 AM, Lenny Verkhovsky 
wrote:

> You can do it in your Zuul layout.yaml configuration file
>
>
>
> Ex:
>
> - name: Nova-ML2-Sriov
>
> branch: ^(master|stable/ocata|stable/newton|stable/pike).*$
>
> voting: false
>
> skip-if:
>
>
>
>
>
> *From:* Ivan Kolodyazhny [mailto:e...@e0ne.info]
> *Sent:* Monday, September 18, 2017 1:05 PM
> *To:* OpenStack Development Mailing List  openstack.org>
> *Cc:* wangyong2...@inspur.com; inspur...@inspur.com; jiaohao...@inspur.com
> *Subject:* [openstack-dev] [cinder][3rd-party ci] Voting INSPUR-CI
>
>
>
> Hi Team,
>
>
>
> Looks like we incidentally made INSPUR-CI voting for Cinder. For now, it
> puts -1 for all patches. According to [1] please make it non-voting.
>
>
>
>
>
> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#When_
> thirdparty_CI_voting_will_be_required.3F
> 
>
>
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Project mascot available

[Erlon Cruz]

On Tue, Feb 14, 2017 at 2:24 PM, Walter Boring  wrote:

> How does Horse translate to Cinder block?
> I don't get it.  Our original Cinder block made a lot of sense,
> considering the name of the project.
>
>
>  Horses uses horseshoes, which were created due the needs of the ancient
Roman empire which was the first to have roads made of ... blocks. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Cinder with remote LVM proposal

[Erlon Cruz]

Hi Marco,

What you are proposing is almost like to create an LVM storage box. I
haven't seen any real benefit from the advantages you listed. For 1), the
same problems you can have upgrading the services within the same node will
happen if the LVM services are not in the same host. For, 2), now you have
2 nodes to manage instead of 1, which double the changes of having
problems. And for 3), I really didn't get the advantage related to the
solution you are proposing.

If you have real deployments cases where this could help (or if there are
other people interested), please list it here so people can see more
concrete benefits of using this solution.

Erlon

On Wed, Feb 1, 2017 at 8:48 AM, Marco Marino  wrote:

> Hi, I'd like to know if it is possible to use openstack-cinder-volume with
> a remote LVM. This could be a new feature proposal if the idea is good.
> More precisely, I'm thinking a solution where openstack-cinder-volume runs
> on a dedicated node and LVM on another node (called "storage node").  On
> the storage node I need to have a volume group (normally named
> cinder-volumes) and the targetcli package, so the iscsi_ip_address in
> cinder.conf should be an address associated with the storage node.
> Advantages of this solution are: 1) When I need to upgrade openstack I can
> leave out the storage node from the process (because it has only LVM and
> targetcli or another daemon used for iscsi targets). 2) Down on the
> cinder-volume node cannot creates problems to the iscsi part exposed to
> vms. 3) Support to the open source world in cinder: LVM is the common
> solution for cinder in low budget environment but performance are good if
> the storage node is powerful enough
>
> In my idea, the "interface" between openstack-cinder-volume and lvm can be
> SSH. Basically we need to create/remove/manage logical volumes on a remote
> node and the same for the iscsi targets
>
> Please, let me know if this can be a valid solution.
>
> Thank you
> Marco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [qa] [infra] Proposed new Cinder gate jobs

[Erlon Cruz]

Thanks for giving this review Michal.

On Thu, Jan 19, 2017 at 8:29 AM, Andreas Jaeger  wrote:

> On 2017-01-19 11:10, Michal Dulko wrote:
> > Hi all,
> >
> > I've seen some confusion around new Cinder CI jobs being proposed to
> > project-config in yesterday's IRC scrollback. This email aims to sum
> > this up and explain purposes of what's being proposed.
>
>
> Thanks a lot, Michal! That helps me seeing the big picture with all
> these changes,
>
> Andreas
>
> > [...]
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Does cinder use novaclient?

[Erlon Cruz]

Hi Jane, there is also some other uses, I know. In migration[1]  when
Cinder needs to migrate an attached volume, in some remotefs drivers [2],
when Cinder needs to take a snapshot of an attached volume. Both seems to
work fine with me.

[1] http://bit.ly/2i6m1Pb
[2] http://bit.ly/2i6m3GM


On Tue, Dec 20, 2016 at 4:44 AM, lij...@gohighsec.com 
wrote:

> Hi Cinder community,
>
> Does cinder use novaclient? What's the use of cinder/compute/nova.py?
>
> I find that there seems to have some problems when construct novaclient in
> the file  cinder/compute/nova.py,
>  but I think the file is not being used.
>
> Would you explain the use of this file or how does cinder communicate with
> nova?
>
> Looking forward to your comments. Thanks.
>
>
> BR,
>
> Jane
>
> --
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Marking Cloudbyte driver as unsupported

[Erlon Cruz]

Hmm, nice! Thanks!

On Mon, Dec 19, 2016 at 11:48 AM, Sean McGinnis <sean.mcgin...@gmx.com>
wrote:

> On Mon, Dec 19, 2016 at 08:27:52AM -0200, Erlon Cruz wrote:
> > Hi Sean, what is the command to generate this output?
> >
> > On Fri, Dec 16, 2016 at 6:27 PM, Sean McGinnis <sean.mcgin...@gmx.com>
> > wrote:
>
> I'm using a modified version of the lastcomment script:
>
> https://github.com/openstack/third-party-ci-tools/tree/
> master/monitoring/lastcomment-scoreboard
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Marking Cloudbyte driver as unsupported

[Erlon Cruz]

Hi Sean, what is the command to generate this output?

On Fri, Dec 16, 2016 at 6:27 PM, Sean McGinnis 
wrote:

> Checking name: CloudByte CI
> last seen: 2016-09-27 11:49:45 (80 days, 5:38:50 old)
> last success: 2016-09-27 11:49:45 (80 days, 5:38:30 old)
> success rate: 72%
>
> Per Cinder's non-compliance policy [1] this patch [2] marks
> the driver as unsupported and deprecated and it will be
> approved if the issue is not corrected by the next cycle.
>
> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-
> drivers#Non-Compliance_Policy
> [2] https://review.openstack.org/#/c/411958/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

[Erlon Cruz]

Kevin,

Now that you had a first feedback about the idea, as Jay said, the next
steps is to write a blueprint/spec so other folks in Cinder can better
understand/suggest/vote on what you are proposing.


Erlon

On Sat, Oct 8, 2016 at 12:14 AM, Zhenyu Zheng 
wrote:

> So do we like the idea of "volume based scheduling?"
>
> On Tue, Sep 27, 2016 at 11:39 AM, Joshua Harlow 
> wrote:
>
>> Huang Zhiteng wrote:
>>
>>>
>>>
>>> On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow >> > wrote:
>>>
>>> Huang Zhiteng wrote:
>>>
>>>
>>> On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow
>>> 
>>> >>
>>>
>>> wrote:
>>>
>>>  Huang Zhiteng wrote:
>>>
>>>  In eBay, we did some inhouse change to Nova so that our
>>> big data
>>>  type of
>>>  use case can have physical disks as ephemeral disk for
>>> this type of
>>>  flavors.  It works well so far.   My 2 cents.
>>>
>>>
>>>  Is there a published patch (or patchset) anywhere that
>>> people can
>>>  look at for said in-house changes?
>>>
>>>
>>> Unfortunately no, but I think we can publish it if there are
>>> enough
>>> interests.  However, I don't think that can be easily adopted
>>> onto
>>> upstream Nova since it depends on other in-house changes we've
>>> done to Nova.
>>>
>>>
>>> Is there any blog, or other that explains the full bunch of changes
>>> that ebay has done (u got me curious)?
>>>
>>> The nice thing about OSS is that if u just get the patchsets out
>>> (even to github or somewhere), those patches may trigger things to
>>> change to match your usecase better just by the nature of people
>>> being able to read them; but if they are never put out there, then
>>> well ya, it's a little hard to get anything to change.
>>>
>>>
>>> Anything stopping a full release of all in-house changes?
>>>
>>> Even if they are not 'super great quality' it really doesn't matter
>>> :)
>>>
>>> Apology for sidetracking the topic a bit.  While we encourage our
>>> engineers to embrace community and open source, I think we didn't do a
>>> good job to actually emphasize that. 'Time To Market' is another factor,
>>> usually a feature requirement becomes deployed service in 2,3 sprint
>>> (4~6 weeks), but you know how much can be done in same amount of time in
>>> community, especially with Nova. :)
>>>
>>
>> Ya, sorry for side-tracking,
>>
>> Overall yes I do know getting changes done in upstream is not a 4-6 week
>> process (though maybe someday it could be). In general I don't want to turn
>> this into a rant, and thankfully I think there is a decent LWN article
>> about this kind of situation already. You might like it :)
>>
>> https://lwn.net/Articles/647524/ (replace embedded linux/kernel in this
>> with openstack and imho it's equally useful/relevant).
>>
>>
>> -Josh
>>
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] How to retrieve volume_driver

[Erlon Cruz]

Hi Luzasz,

This information (volume_driver) is only used on driver loading so, its not
available outside Cinder context. Can you tell how and why you need that?
And why parsing the conf file is not enough for you?

Erlon

On Fri, Oct 7, 2016 at 9:05 AM,  wrote:

> Dear all.
>
> I'm a PHD student from Poland and have found out about this list from
> Openstack wiki. Could you kindly tell me, if there is a way to retrieve,
> from outside of OpenStack code, volume_driver for given backend? Preferably
> - without a need to parse the cinder.conf file?
>
> It is fairly easy to retrieve the volume_backend_name, which in most
> scenarios seems to describe the driver type used. However, in general
> scenario, this is just a custom string entered by the admin. I would
> greatly appreciate, if someone could point me to a way to acquire the
> unique stirng, identifying the driver type used - the ona that is passed as
> volume_driver in cinder.conf.
>
> Thank you in advance for your time.
>
> Best regards,
> Lukasz
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [qa] Proposal to make multinode grenade job voting

[Erlon Cruz]

+1
It seems good!


On Thu, Sep 29, 2016 at 7:25 AM, Michał Dulko 
wrote:

> On 09/29/2016 12:10 PM, Michał Dulko wrote:
> > Hello everyone,
> >
> > We have a non-voting multinode grenade job in check queue for around a
> > month now.
> >
> > https://goo.gl/Kr10s6
>
> Whoops, I've sent this by mistake. Here's the actual email:
>
> Hello everyone,
>
> We have a non-voting multinode grenade job in check pipeline for around
> a month now. It is testing rolling upgrades by checking compatibility of
> stable c-vol and c-bak with master c-api and c-sch. This is a
> requirement for Cinder to achieve an assert:supports-rolling-upgrade tag
> [1]. As the job seems fairly stable in comparison with the tempest job
> [2] and in ci-watch [3], I'm proposing to make it voting.
>
> Please note that failures seen in the beginning of September on graph
> [2] are results of bug [4], which was actually found by the job
> (although the bug itself wasn't related to upgrades).
>
> The patch making the job voting is available at [5].
>
> Thanks,
> Michal
>
> [1]
> https://governance.openstack.org/reference/tags/assert_
> supports-rolling-upgrade.html
> [2] https://goo.gl/Kr10s6
> [3] http://ci-watch.tintri.com/project?project=cinder=7+days
> [4] https://bugs.launchpad.net/cinder/+bug/1619246
> [5] https://review.openstack.org/#/c/379346/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

[Erlon Cruz]

On Fri, Sep 23, 2016 at 10:19 PM, Zhenyu Zheng <zhengzhenyul...@gmail.com>
wrote:

> Hi,
>
> Thanks all for the information, as for the filter Erlon(
> InstanceLocalityFilter) mentioned, this only solves a part of the problem,
> we can create new volumes for existing instances using this filter and
> then attach to it, but the root volume still cannot
> be guranteed to be on the same host as the compute resource, right?
>
>
You have two options to use a disk in the same node as the instance.
1 - The easiest, just don't use Cinder volumes. When you create an instance
from an image, the default behavior in Nova, is to create the root disk in
the local host (/var/lib/nova/instances). This have the advantage that Nova
will cache the image locally and will avoid the need of copying the image
over the wire (or having to configure image caching in Cinder).

2 - Use Cinder volumes as root disk. Nova will somehow have to pass the
hints to the scheduler so it properly can use the InstanceLocalityFilter.
If you place this in Nova, and make sure that all requests have the proper
hint, then the volumes created will be scheduled and the host.

Is there any reason why you can't use the first approach?




> The idea here is that all the volumes uses local disks.
> I was wondering if we already have such a plan after the Resource Provider
> structure has accomplished?
>
> Thanks
>
> On Sat, Sep 24, 2016 at 2:05 AM, Erlon Cruz <sombra...@gmail.com> wrote:
>
>> Not sure exactly what you mean, but in Cinder using the
>> InstanceLocalityFilter[1], you can  schedule a volume to the same compute
>> node the instance is located. Is this what you need?
>>
>> [1] http://docs.openstack.org/developer/cinder/scheduler-fil
>> ters.html#instancelocalityfilter
>>
>> On Fri, Sep 23, 2016 at 12:19 PM, Jay S. Bryant <
>> jsbry...@electronicjungle.net> wrote:
>>
>>> Kevin,
>>>
>>> This is functionality that has been requested in the past but has never
>>> been implemented.
>>>
>>> The best way to proceed would likely be to propose a blueprint/spec for
>>> this and start working this through that.
>>>
>>> -Jay
>>>
>>>
>>> On 09/23/2016 02:51 AM, Zhenyu Zheng wrote:
>>>
>>> Hi Novaers and Cinders:
>>>
>>> Quite often application requirements would demand using locally attached
>>> disks (or direct attached disks) for OpenStack compute instances. One such
>>> example is running virtual hadoop clusters via OpenStack.
>>>
>>> We can now achieve this by using BlockDeviceDriver as Cinder driver and
>>> using AZ in Nova and Cinder, illustrated in[1], which is not very feasible
>>> in large scale production deployment.
>>>
>>> Now that Nova is working on resource provider trying to build an
>>> generic-resource-pool, is it possible to perform "volume-based-scheduling"
>>> to build instances according to volume? As this could be much easier to
>>> build instances like mentioned above.
>>>
>>> Or do we have any other ways of doing this?
>>>
>>> References:
>>> [1] http://cloudgeekz.com/71/how-to-setup-openstack-to-use-l
>>> ocal-disks-for-instances.html
>>>
>>> Thanks,
>>>
>>> Kevin Zheng
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Schedule Instances according to Local disk based Volume?

[Erlon Cruz]

Not sure exactly what you mean, but in Cinder using the
InstanceLocalityFilter[1], you can  schedule a volume to the same compute
node the instance is located. Is this what you need?

[1]
http://docs.openstack.org/developer/cinder/scheduler-filters.html#instancelocalityfilter

On Fri, Sep 23, 2016 at 12:19 PM, Jay S. Bryant <
jsbry...@electronicjungle.net> wrote:

> Kevin,
>
> This is functionality that has been requested in the past but has never
> been implemented.
>
> The best way to proceed would likely be to propose a blueprint/spec for
> this and start working this through that.
>
> -Jay
>
>
> On 09/23/2016 02:51 AM, Zhenyu Zheng wrote:
>
> Hi Novaers and Cinders:
>
> Quite often application requirements would demand using locally attached
> disks (or direct attached disks) for OpenStack compute instances. One such
> example is running virtual hadoop clusters via OpenStack.
>
> We can now achieve this by using BlockDeviceDriver as Cinder driver and
> using AZ in Nova and Cinder, illustrated in[1], which is not very feasible
> in large scale production deployment.
>
> Now that Nova is working on resource provider trying to build an
> generic-resource-pool, is it possible to perform "volume-based-scheduling"
> to build instances according to volume? As this could be much easier to
> build instances like mentioned above.
>
> Or do we have any other ways of doing this?
>
> References:
> [1] http://cloudgeekz.com/71/how-to-setup-openstack-to-use-
> local-disks-for-instances.html
>
> Thanks,
>
> Kevin Zheng
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] moving driver to open source

[Erlon Cruz]

On Tue, Sep 20, 2016 at 5:23 AM, Thierry Carrez 
wrote:

> Alon Marx wrote:
> > Thank you ALL for clearing up this issue.
> >
> > To sum up the discussion (not going into too many details):
> > From legal stand point, if one uses python libraries they should be part
> > of the community or confirming with the relevant licenses
> > (http://governance.openstack.org/reference/licensing.html).


Alon,

Its not clear to me what you mean with this sentence. You mean, 'all python
library that is included from the drivers must conform to OpenStack
licensing (i.e. Apache License)'?

Erlon



If one is
> > not using python libraries (e.g. rest, command line, etc.) the
> > non-python executable is considered legitimate wherever it is running.
> > From deployment stand point the desire is to have any piece of code that
> > is required on an openstack installation would be easily downloadable.
> >
> > We understand the requirements now and are working on a plan taking both
> > considerations into account.
>
> I wouldn't say that the situation is cleared up -- we still need to get
> our act together and present a more uniform response to that question
> across multiple projects. But AFAICT your summary accurately represents
> the current Cinder team position on that matter.
>
> I hope we'll be able to hold a cross-project workshop on that question
> in Barcelona, so that we further clear up what is appropriate in-tree,
> as a separate project team and as an external project, across all of
> OpenStack.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] The State of the NFS Driver ...

[Erlon Cruz]

Hi Jay,

Thanks for the update. I can give a look in the NFS job, it will need some
care, like configuring the slave to be a Ubuntu Xenial and setting
apparmor, so when you finish the cloning support we have an operational job.

Erlon

On Wed, Aug 31, 2016 at 11:50 AM, Jay S. Bryant <
jsbry...@electronicjungle.net> wrote:

> On 08/30/2016 08:50 PM, Matt Riedemann wrote:
>
>> On 8/30/2016 10:50 AM, Jay S. Bryant wrote:
>>
>>> All,
>>>
>>> I wanted to follow up on the e-mail thread [1] on Cloning support in the
>>> NFS driver.  The purpose of this e-mail is to provide the plan for the
>>> NFS driver going forward as I see it.
>>>
>>> First, I am aware that the driver has gone quite some time without care
>>> and feeding.  For a number of reasons, the Public Cloud team within IBM
>>> is currently dependent upon the NFS driver working properly for the
>>> cloud environment we are building.  Given our current dependence on the
>>> driver we are planning on picking up the driver and maintaining it.
>>>
>>> The first step in this process was getting the existing patch that adds
>>> snapshot support for NFS [2] rebased.  I did this work a couple of weeks
>>> ago and also got all the unit tests working for the unit test
>>> environment on the master branch.  I now see that it is in merge
>>> conflict again, I plan to continue to keep the patch up-to-date.
>>>
>>> Erlon has been investigating issues with attaching snapshots. It
>>> appears that this may be related to AppArmor running on the system where
>>> the VM is running and attachment is being attempted.  I am hoping to
>>> look into the other questions posed in the patch review in the next week
>>> or two.
>>>
>>> The next step is to create a dependent patch, upon the snapshot patch,
>>> to implement cloning.  I am planning to also undertake this work.  I am
>>> assuming that getting the cloning support in place shouldn't be too
>>> difficult once snapshots are working as it will be just a matter of
>>> using the support from the remotefs driver.
>>>
>>> The last piece of work we have in flight is working on adding QoS
>>> support to the NFS driver.  We have the following spec proposed to get
>>> that work started: [3]
>>>
>>> So, we are in the process of bringing the NFS driver up to good
>>> standing.  During this process we would greatly appreciate reviews and
>>> input from those of you who have previously worked on the driver in
>>> order to expedite integration of the necessary changes. I feel it is in
>>> the best interest of the community to get the driver updated and
>>> supported given that it is the 4th most used driver according to our
>>> user survey.  I think it would not look good to our users if it were to
>>> suddenly be removed.
>>>
>>> Thanks to all of your for your support in this effort!
>>>
>>> Jay
>>>
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-Augu
>>> st/102193.html
>>>
>>> [2] https://review.openstack.org/#/c/147186/
>>>
>>> [3] https://review.openstack.org/361456
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> IMO priority #1 is getting the NFS job passing consistently, who is
>> working on that? Last I checked it was failing a bunch because it was
>> running snapshot and clone tests, which obviously don't work since that
>> support isn't implemented in the driver. I think configuring tempest in the
>> devstack-plugin-nfs repo is fairly straightforward, someone just needs to
>> do it.
>>
>> But at least that gets you closer to a clean NFS job run which gets it
>> out of the experimental queue (possibly) and as a non-voting job in Cinder
>> so you can see if you're regressing anything (or if anything else regresses
>> it once you have clean CI runs).
>>
>> My 2 cents.
>>
>> Matt,
>
> This is good feedback.  I will put a story on our backlog on this for it
> and try to get that working ASAP.
>
> Jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][cinder] Clone feature toggle not in clone tests

[Erlon Cruz]

He is mentioning about the Cinder side: https://review.openstack.org/#
/c/147186/

On Fri, Aug 26, 2016 at 7:01 AM, Jordan Pittier 
wrote:

>
>
> On Thu, Aug 25, 2016 at 7:06 PM, Ben Swartzlander 
> wrote:
>
>> Originally the NFS driver did support snapshots, but it was implemented
>> by just 'cp'ing the file containing the raw bits. This works fine (if
>> inefficiently) for unattached volumes, but if you do this on an attached
>> volume the snapshot won't be crash consistent at all.
>>
>> It was decided that we could do better for attached volumes by switching
>> to qcow2 and relying on nova to perform the snapshots. Based on this, the
>> bad snapshot implementation was removed.
>>
>> However, for a variety of reasons the nova-assisted snapshot
>> implementation has remained unmerged for 2+ years and the NFS driver has
>> been an exception to the rules for that whole time.
>>
> I am not sure to understand what you mean by "the nova-assisted snapshot
> implementation has remained unmerged for 2+ years". It looks merged to me
> [1] and several Cinder drivers dependent on it as far as I know.
>
> [1]: http://developer.openstack.org/api-ref-compute-
> v2.1.html#os-assisted-volume-snapshots-v2.1
>
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][cinder] Clone feature toggle not in clone tests

[Erlon Cruz]

Hi Jordan, Slade,

Currently NFS driver does not support cloning neither snapshots (which are
the base for implementing cloning). AFAIC, the NFS driver was in Cinder
before the minimum requirements being discussed and set, so, it just stood
there with the features it already supported.

There is currently this job
'gate-tempest-dsvm-full-devstack-plugin-nfs-nv'[1] that by the way are
failing in the same test you mentioned tough passing the snapshot tests
(not shure how the configuration is doing that) and a work[2] in progress
to support the snapshot feature.

So, Jordan, I think its OK to allow tempest to skip this tests, provided
that at least in the NFS driver, tempest isn't being an enforcement to
Cinder minimum features requirements.

Erlon


[1]
http://logs.openstack.org/86/147186/25/experimental/gate-tempest-dsvm-full-devstack-plugin-nfs-nv/b149960/
[2] https://review.openstack.org/#/c/147186/

On Wed, Aug 24, 2016 at 6:34 PM, Jordan Pittier 
wrote:

>
> On Wed, Aug 24, 2016 at 6:06 PM, Slade Baumann  wrote:
>
>> I am attempting to disable clone tests in tempest as they aren't
>> functioning in NFS. But the tests test_volumes_clone.py and
>> test_volumes_clone_negative.py don't have the "clone" feature
>> toggle in them. I thought it obvious that if clone is disabled
>> in tempest, the tests that simply clone should be disabled.
>>
>> So I put up a bug and fix for it, but have been talking with
>> Jordan Pittier and he suggested I come to the mailing list to
>> get this figured out.
>>
>> I'm not asking for reviews, unless you want to give them.
>> I'm simply asking if this is the right way to go about this
>> or if there is something else I need to do to get this into
>> Tempest.
>>
>> Here are the bug and fix:
>> https://bugs.launchpad.net/tempest/+bug/1615770
>> https://review.openstack.org/#/c/358813/
>>
>> I would appreciate any suggestion or direction in this problem.
>>
>> For extra reference, the clone toggle flag was added here:
>> https://bugs.launchpad.net/tempest/+bug/1488274
>>
>> Hi,
> Thanks for starting this thread. My point about this patch is, as "volume
> clone" is part of the core requirements [1] every Cinder drive must
> support, I don't see a need for a feature flag. The feature flag already
> exists, but that doesn't mean we should encourage its usage.
>
> Now, if this really helps the NFS driver (although I don"t know why we
> couldn't support clone with NFS)... I don't have a strong opinion on this
> patch.
>
> I -1ed the patch for consistency: I agree that there should be a minimum
> set of features expected from a Cinder driver.
>
> [1] http://docs.openstack.org/developer/cinder/devref/drivers.html#core-
> functionality
>
> Cheers,
> Jordan
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Pending removal of Scality volume driver

[Erlon Cruz]

Hi sean, I think it would worth to CC the contact info informed in the CI
Wiki (openstack...@scality.com).

On Tue, Aug 2, 2016 at 4:26 PM, Sean McGinnis  wrote:

> Tomorrow is the one week grace period. I just ran the last comment
> script and it still shows it's been 112 days since the Scality CI has
> reported on a patch.
>
> Please let me know the status of the CI.
>
> On Thu, Jul 28, 2016 at 07:28:26AM -0500, Sean McGinnis wrote:
> > On Thu, Jul 28, 2016 at 11:28:42AM +0200, Jordan Pittier wrote:
> > > Hi Sean,
> > >
> > > Thanks for the heads up.
> > >
> > > On Wed, Jul 27, 2016 at 11:13 PM, Sean McGinnis  >
> > > wrote:
> > >
> > > > The Cinder policy for driver CI requires that all volume drivers
> > > > have a CI reporting on any new patchset. CI's may have some down
> > > > time, but if they do not report within a two week period they are
> > > > considered out of compliance with our policy.
> > > >
> > > > This is a notification that the Scality OpenStack CI is out of
> compliance.
> > > > It has not reported since April 12th, 2016.
> > > >
> > > Our CI is still running for every patchset, just that it doesn't report
> > > back to Gerrit. I'll see what I can do about it.
> >
> > Great! I'll watch for it to start reporting again. Thanks for being
> > responsive and looking into it.
> >
> > >
> > > >
> > > > The patch for driver removal has been posted here:
> > > >
> > > > https://review.openstack.org/348032/
> > >
> > > That link is about the Tegile driver, not ours.
> >
> > Oops, copy/paste error. Here is the correct one:
> >
> > https://review.openstack.org/#/c/348042/
> >
> > >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Midcycle Action item Summary

[Erlon Cruz]

Thanks for the sum up Kendall!

On Fri, Jul 22, 2016 at 1:20 PM, Kendall Nelson 
wrote:

> Hello All,
>
>We came out of the Midcycle with a lot of things on a lot of people’s
> plates. Here is a summary of what everyone signed up for and what things
> need owners.
>
> scottda:
>
>-
>
>Pick a time to meet weekly to discuss and push ahead with
>Active-Active HA (day1)
>-
>
>Find out the process for how swift uses feature branches and teach us
>(day1)
>-
>
>Write a devstack to fix config for tempest multibackend (just pass
>$CINDER_ENABLED_BACKENDS through to tempest.conf; make sure the string
>formats match up between tempest and cinder) (day2)
>
> geguileo:
>
>-
>
>Make a list of minimal risk Active-Active HA patches to focus on first
>(day1)
>
> jgriffith:
>
>-
>
>Work with scottda on getting the logic back into Nova (?) that was
>ripped out for setting up multiple back ends; it used to be there but was
>removed because there were errors coming from LVM (day2)
>-
>
>Work with xyang and e0ne on consolidating a single stable fake driver
>(day3)
>
> smcginnis:
>
>-
>
>Rebase nested quota support patches (day1)
>-
>
>   https://review.openstack.org/#/c/298453/ Functional Tests for
>   nested quotas
>   -
>
>   https://review.openstack.org/#/c/285640/ Cinder test cases for
>   nested quotas
>
> eharney:
>
>-
>
>Figure out what needs to be changed in the client for min vol sizes
>(day1)
>-
>
>Create a wiki or document and schedule for stable branch release plans
>(day2)
>
> diablo_rojo:
>
>-
>
>Write template for email to send to failing CI’s (day1)
>
> bswartz:
>
>-
>
>Push code for your stochastic scheduler spec(day3)
>
> e0ne:
>
>-
>
>Convert functional job in gate to be a stripped down devstack that can
>have the driver be configured
>
>
> ~~~Needs an owner~~~
>
>-
>
>QA Liaison
>-
>
>Request Infra to make driver branches for old releases (day2)
>-
>
>Set up project config for driver branches for old releases (day2)
>-
>
>Spec for the desired result for seamless failback after replication
>failover(day3)
>-
>
>Set provisioning to thick=true in all drivers and then change the
>default provisioning to thin (day3)
>-
>
>Update documentation for tests to explain differences between unit,
>functional, in-tree tempest, and tempest tests- i.e. what services run in
>functional environment versus in-tree tempest tests, what each’s purpose
>is, maybe examples of things that would be tested in each area? (day3)
>-
>
>Set up jobs for fake driver and real drivers for functional tests
>(day3)
>
>
>
> Links to etherpads where notes were taken and todo’s were set up:
>
> Day1: https://etherpad.openstack.org/p/newton-cinder-midcycle-day1
>
> Day2: https://etherpad.openstack.org/p/newton-cinder-midcycle-day2
>
> Day3: https://etherpad.openstack.org/p/newton-cinder-midcycle-day3
>
> Thanks!
>
> Kendall Nelson
>
> (diablo_rojo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core

[Erlon Cruz]

+1
Not a core but surely is well deserved. Congrats Scott!!

On Tue, Jun 28, 2016 at 5:06 AM, Gorka Eguileor  wrote:

>
> +2
>
> Congrats Scott!!
>
>
> On 27/06, Sean McGinnis wrote:
> > I would like to nominate Scott D'Angelo to core. Scott has been very
> > involved in the project for a long time now and is always ready to help
> > folks out on IRC. His contributions [1] have been very valuable and he
> > is a thorough reviewer [2].
> >
> > Please let me know if there are any objects to this within the next
> > week. If there are none I will switch Scott over by next week, unless
> > all cores approve prior to then.
> >
> > Thanks!
> >
> > Sean McGinnis (smcginnis)
> >
> > [1]
> https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged
> > [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder]The backend-group concept in Cinder

[Erlon Cruz]

You can define several backends with the same volume_backend_name and call
that a group. For example:
[groupA-be1]
volume_backend_name=fast-ssd

[groupA-be2]
volume_backend_name=fast-ssd

[groupB-be3]
volume_backend_name=slow-disk

So, no matter what storage is behind every backend, it will be filtered
 based on the backend_name (and the other capabilities each backend
reports). If you don't want to restart the volume service to each backend
you add. You can add another instance of cinder-volume, even in the same
controller. The scheduler will know how to handle the new ones.

Erlon


On Tue, Jun 14, 2016 at 6:15 AM, chen ying  wrote:

> Hi Duncan Thomas,
> Does you means we can create a volume type include list of backend
> names(such as: backend_name=" name1 name2 name3 name4"), so when we
> create a volume, we can use the volume type to choose  one backend from
> these list of backend names(name1,name2,name3,name4)?
> But in this way, we cannot show the backends obviously capabilities to
> users(such as: performance, ssd, spinning-rust etc).
>
>
>
> --
> *发件人:* Duncan Thomas 
> *发送时间:* 2016年6月14日 8:03
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* Re: [openstack-dev] [cinder]The backend-group concept in Cinder
>
> As long as each backend has a unique name, you can key the type to a list
> of backend names if there's no useful capabilities to key off. No restart
> required.
>
> On 14 June 2016 at 10:16, chen ying  wrote:
>
>> Hi John,
>>
>>
>>
>> User case 1:
>>   The  backends in backend-group-1 have SSD disk, more memory .
>> The backend-group-1 can provide higher performance to user.
>>   The other  backends  in  backend-group-2 have HHD disk, more
>> capacity. The backend-group-2 can provide more storage space to user .
>>
>> Not sure, but we sort of do some of this already via the filter
>> scheduler.  An Admin can define various types (they may be set up based on
>> performance, ssd, spinning-rust etc).  Those types are then given arbitrary
>> definitions via a type (again details hidden from end user) and he/she can
>> create volumes of a specific type.
>>
>>
>>
>> Yes,  An Admin can arbitrary define various types and he/she can create
>> volumes of a specific type. But we need to restart our cinder driver after
>> define various types in each driver(If the driver cannot report
>> capabilities by itself). It will not easy to manage for Admin.
>>
>> Does Admin could use the concept of dynamically adding/removing backends
>> to backend-group. In this way, we not need to modify backend configure
>> file(such as: report a capabilities of ssd, spinning-rust etc).We can
>> arbitrary define various types for backend-group, and also he/she can
>> create volumes of a specific type(from backend-group type).
>>
>> So for example I could say "I want these backends with capability XYZ",
>> and many of backends from different vendors. How to manage these backends
>> by Administrator?
>>
>> Currently:
>>
>> 1.Admin need modify backend configure file, let the backend
>> report capability XYZ to filter scheduler.
>>
>> 2.Restart the volume service, make the capability valid
>>
>> 3.Create volume type(test_type) with capability XYZ.
>>
>> 4.he/she can create volumes of a specific type(test_type)
>>
>>Now we expect:
>>
>> 1.Admin add backend to backend-group
>>
>> 2.Create volume type(test_type) with capability XYZ, use
>> frefix(group or something else (group: capability = XYZ)) to distinguish
>> between the backend capability and the backend-group capability.
>>
>> 3.he/she can create volumes of a specific type(test_type)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] A friendly reminder about reviews

[Erlon Cruz]

Cinder is definitely lacking reviewing force. I remember 2 years ago
comparing with today and I can tell that patches are taking a lot longer to
get reviewed.

This link is also very useful to triage incoming patches:

https://review.openstack.org/#/dashboard/?foreach=project:^openstack/.*cinder.*
status:open NOT owner:self NOT label:Workflow<=-1 label:Verified>=1 NOT
label:Code-Review<=-1,self NOT label:Code-Review>=1,self=Cinder
Review Inbox Specs=project:openstack/manila-specs
Fixes=topic:^bug/.* Feedback (Changes older than 5 days that have not
been reviewed by anyone)=NOT label:Code-Review<=2 age:5d are a
reviewer, but haven't voted in the current revision=reviewer:self
final +2=label:Code-Review>=2 limit:50
Contributors=reviewer:10068 Jenkins, No Negative Feedback=NOT
label:Code-Review>=2 NOT label:Code-Review<=-1 limit:50 Changes
(Changes with no code review in the last 2days)=NOT label:Code-Review<=2
age:2d

Huge link but the result is beautiful :)


Erlon


On Wed, May 11, 2016 at 11:19 AM, Eric Harney  wrote:

> And for completeness, I'd also like to mention that there is this nice
> dashboard:
>
> http://status.openstack.org/reviews/#cinder
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] Cinder Datasource

[Erlon Cruz]

Can you give a bit more of context? Where is the design you mentioned? By
datasource you mean the Cinder service?
There is already some work[1] to allow Cider to attach volumes in baremetal
servers.


[1] https://blueprints.launchpad.net/cinder/+spec/use-cinder-without-nova

On Tue, Apr 12, 2016 at 4:02 AM, Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi,
>
> Here is the design of the Cinder datasource of Vitrage.
>
> Currently Cinder datasource is handling only Volumes.
> This datasource listens to cinder volumes notifications on the oslo bus,
> and updates the topology accordingly.
> Currently Cinder Volume can be attached only to instance (Cinder design).
>
> Future Steps:
> We want to perform research on what other data we can bring from Cinder.
> For example:
> 1. To what zone we can connect the volume
> 2. To what image we can connect the volume
>
> Alexey
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] About snapshot Rollback?

[Erlon Cruz]

I didn't see that mention. You mean about legacy volumes and snapshots?

On Mon, Apr 11, 2016 at 3:58 PM, Duncan Thomas <duncan.tho...@gmail.com>
wrote:

> Ok, you're right about device naming by UUID.
>
> So we have two advantages compared to the existing system:
>
> - Keeping the same volume id (and therefore disk UUID) makes reverting a
> VM much easier since device names inside the instance stay the same
> - Can significantly reduce the amount of copying required on some backends
>
> These do seem like solid reasons to consider the feature.
>
> If you can solve the backwards compatibility problem mentioned further up
> this thread, then I think there's a strong case for considering adding this
> API.
>
> The next step is a spec and a PoC implementation.
>
>
>
> On 11 April 2016 at 20:57, Erlon Cruz <sombra...@gmail.com> wrote:
>
>> You are right, the instance should be shutdown or the device be
>> unmounted, before 'revert' or removing the old device. That should be
>> enough to avoid corruption. I think the device naming is not a problem if
>> you use the same volume (at least the disk UUID will be the same).
>>
>> On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas <duncan.tho...@gmail.com>
>> wrote:
>>
>>> You can't just change the contents of a volume under the instance though
>>> - at the very least you need to do an unmount in the instance, and a detach
>>> is preferable, otherwise you've got data corruption issues.
>>>
>>> At that point, the device naming problems are identical.
>>>
>>> On 11 April 2016 at 20:22, Erlon Cruz <sombra...@gmail.com> wrote:
>>>
>>>> The actual user workflow is:
>>>>
>>>>  1 - User creates a volume(s)
>>>>  2 - User attach volume to instance
>>>>  3 - User creates a snapshot
>>>>  4 - Something happens causing the need of a revert
>>>>  5 - User creates a volume(s) from the snapshot(s)
>>>>  6 - User detach old volumes
>>>>  7 - User attach new volumes (and pray so they get the same id) - Nova,
>>>> should have the ability to honor supplied device names (vdc, vdd, etc),
>>>> which not always happen[1]. But, does the volume keep the same UUID in the
>>>> system? Several application use that to boot.
>>>>
>>>> The suggested workflow would be simpler for a user POV:
>>>>
>>>>  1 - User creates a volume(s)
>>>>  2 - User attach volume to instance
>>>>  3 - User creates a snapshot
>>>>  4 - Something happens causing the need of a revert
>>>>  5 - User revert snapshot(s)
>>>>
>>>>
>>>>  [1] https://goo.gl/Kusfne
>>>>
>>>> On Fri, Apr 8, 2016 at 5:07 AM, Ivan Kolodyazhny <e...@e0ne.info>
>>>> wrote:
>>>>
>>>>> Hi Chenzongliang,
>>>>>
>>>>> I still don't understand what is difference between proposed feature
>>>>> and 'restore volume from snapshot'? Could you please explain it?
>>>>>
>>>>> Regards,
>>>>> Ivan Kolodyazhny,
>>>>> http://blog.e0ne.info/
>>>>>
>>>>> On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang <
>>>>> chenzongli...@huawei.com> wrote:
>>>>>
>>>>>> Dear Cruz:
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Thanks for you kind support, I will review the previous spec
>>>>>> according to the following links.  May be more user scenario we should
>>>>>> considered,such as backup,create volume from snapshot,consistency group 
>>>>>> and
>>>>>> etc,we will spend some time to gather
>>>>>>
>>>>>> the user's scenarios and determin what to do next step.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> zongliang chen
>>>>>>
>>>>>>
>>>>>>
>>>>>> *发件人:* Erlon Cruz [mailto:sombra...@gmail.com]
>>>>>> *发送时间:* 2016年4月5日 2:50
>>>>>> *收件人:* OpenStack Development Mailing List (not for usage questions)
>>>>>> *抄送:* Zhangli (ISSP); Shenhong (C)
>>>>>> *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Chen,
>>>>>>

Re: [openstack-dev] [Cinder] About snapshot Rollback?

[Erlon Cruz]

You are right, the instance should be shutdown or the device be unmounted,
before 'revert' or removing the old device. That should be enough to avoid
corruption. I think the device naming is not a problem if you use the same
volume (at least the disk UUID will be the same).

On Mon, Apr 11, 2016 at 2:39 PM, Duncan Thomas <duncan.tho...@gmail.com>
wrote:

> You can't just change the contents of a volume under the instance though -
> at the very least you need to do an unmount in the instance, and a detach
> is preferable, otherwise you've got data corruption issues.
>
> At that point, the device naming problems are identical.
>
> On 11 April 2016 at 20:22, Erlon Cruz <sombra...@gmail.com> wrote:
>
>> The actual user workflow is:
>>
>>  1 - User creates a volume(s)
>>  2 - User attach volume to instance
>>  3 - User creates a snapshot
>>  4 - Something happens causing the need of a revert
>>  5 - User creates a volume(s) from the snapshot(s)
>>  6 - User detach old volumes
>>  7 - User attach new volumes (and pray so they get the same id) - Nova,
>> should have the ability to honor supplied device names (vdc, vdd, etc),
>> which not always happen[1]. But, does the volume keep the same UUID in the
>> system? Several application use that to boot.
>>
>> The suggested workflow would be simpler for a user POV:
>>
>>  1 - User creates a volume(s)
>>  2 - User attach volume to instance
>>  3 - User creates a snapshot
>>  4 - Something happens causing the need of a revert
>>  5 - User revert snapshot(s)
>>
>>
>>  [1] https://goo.gl/Kusfne
>>
>> On Fri, Apr 8, 2016 at 5:07 AM, Ivan Kolodyazhny <e...@e0ne.info> wrote:
>>
>>> Hi Chenzongliang,
>>>
>>> I still don't understand what is difference between proposed feature and
>>> 'restore volume from snapshot'? Could you please explain it?
>>>
>>> Regards,
>>> Ivan Kolodyazhny,
>>> http://blog.e0ne.info/
>>>
>>> On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang <chenzongli...@huawei.com
>>> > wrote:
>>>
>>>> Dear Cruz:
>>>>
>>>>
>>>>
>>>>  Thanks for you kind support, I will review the previous spec
>>>> according to the following links.  May be more user scenario we should
>>>> considered,such as backup,create volume from snapshot,consistency group and
>>>> etc,we will spend some time to gather
>>>>
>>>> the user's scenarios and determin what to do next step.
>>>>
>>>>
>>>>
>>>> Sincerely,
>>>>
>>>> zongliang chen
>>>>
>>>>
>>>>
>>>> *发件人:* Erlon Cruz [mailto:sombra...@gmail.com]
>>>> *发送时间:* 2016年4月5日 2:50
>>>> *收件人:* OpenStack Development Mailing List (not for usage questions)
>>>> *抄送:* Zhangli (ISSP); Shenhong (C)
>>>> *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback?
>>>>
>>>>
>>>>
>>>> Hi Chen,
>>>>
>>>>
>>>>
>>>> Not sure if I got you right but I brought this topic in
>>>> #openstack-cinder some days ago. The idea is to be able to rollback a
>>>> snapshot in Cinder. Today what is possible to do is to create a volume from
>>>> a snapshot. From the user point of view, this is not ideal, as there are
>>>> several cases, if not the majority of, that the purpose of the snapshot is
>>>> to revert to a desired state, and not keep the original volume. For some
>>>> backends, keeping the original volume means space consumption. This space
>>>> problem becomes bold when we think about consistency groups. For
>>>> consistency groups, some backends might have to copy an entire filesystem
>>>> for each snapshot, consuming space and time. So, I think it would be
>>>> desired to have the ability to revert snapshots.
>>>>
>>>>
>>>>
>>>> I know there have been efforts in the past[1] to implement that, but
>>>> for some reason the work was stopped. If you want to retake the effort
>>>> please create a spec[2]  sol everybody can provide feedback.
>>>>
>>>>
>>>>
>>>> Erlon
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1]
>>>> https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
>>>>
>>>> [2] https://github.com/openstack/cinder-

Re: [openstack-dev] [Cinder] About snapshot Rollback?

[Erlon Cruz]

The actual user workflow is:

 1 - User creates a volume(s)
 2 - User attach volume to instance
 3 - User creates a snapshot
 4 - Something happens causing the need of a revert
 5 - User creates a volume(s) from the snapshot(s)
 6 - User detach old volumes
 7 - User attach new volumes (and pray so they get the same id) - Nova,
should have the ability to honor supplied device names (vdc, vdd, etc),
which not always happen[1]. But, does the volume keep the same UUID in the
system? Several application use that to boot.

The suggested workflow would be simpler for a user POV:

 1 - User creates a volume(s)
 2 - User attach volume to instance
 3 - User creates a snapshot
 4 - Something happens causing the need of a revert
 5 - User revert snapshot(s)


 [1] https://goo.gl/Kusfne

On Fri, Apr 8, 2016 at 5:07 AM, Ivan Kolodyazhny <e...@e0ne.info> wrote:

> Hi Chenzongliang,
>
> I still don't understand what is difference between proposed feature and
> 'restore volume from snapshot'? Could you please explain it?
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang <chenzongli...@huawei.com>
> wrote:
>
>> Dear Cruz:
>>
>>
>>
>>  Thanks for you kind support, I will review the previous spec
>> according to the following links.  May be more user scenario we should
>> considered,such as backup,create volume from snapshot,consistency group and
>> etc,we will spend some time to gather
>>
>> the user's scenarios and determin what to do next step.
>>
>>
>>
>> Sincerely,
>>
>> zongliang chen
>>
>>
>>
>> *发件人:* Erlon Cruz [mailto:sombra...@gmail.com]
>> *发送时间:* 2016年4月5日 2:50
>> *收件人:* OpenStack Development Mailing List (not for usage questions)
>> *抄送:* Zhangli (ISSP); Shenhong (C)
>> *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback?
>>
>>
>>
>> Hi Chen,
>>
>>
>>
>> Not sure if I got you right but I brought this topic in #openstack-cinder
>> some days ago. The idea is to be able to rollback a snapshot in Cinder.
>> Today what is possible to do is to create a volume from a snapshot. From
>> the user point of view, this is not ideal, as there are several cases, if
>> not the majority of, that the purpose of the snapshot is to revert to a
>> desired state, and not keep the original volume. For some backends, keeping
>> the original volume means space consumption. This space problem becomes
>> bold when we think about consistency groups. For consistency groups, some
>> backends might have to copy an entire filesystem for each snapshot,
>> consuming space and time. So, I think it would be desired to have the
>> ability to revert snapshots.
>>
>>
>>
>> I know there have been efforts in the past[1] to implement that, but for
>> some reason the work was stopped. If you want to retake the effort please
>> create a spec[2]  sol everybody can provide feedback.
>>
>>
>>
>> Erlon
>>
>>
>>
>>
>>
>> [1]
>> https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
>>
>> [2] https://github.com/openstack/cinder-specs
>>
>>
>>
>> On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang <chenzongli...@huawei.com>
>> wrote:
>>
>> Hi all:
>>
>> We are condering add a fucntion rollback_snapshot when we use backup.
>> In the end user's scenario. If a vm fails, we hope that we can use snapshot
>> to to recovery the volume's data.
>>
>> Beacuse it can quickly recovery our vm. But if we use the remote data
>> to recovery. We will spend more time.
>>
>> But i'm not sure if the data was recoveried from the backend. whether
>> the host need to rescan the volumes? At the same time. If a volume have
>> been extended, whether it can be roolback?
>>
>>
>>
>>I want to know whether the topic have been discussed or have other
>> recommendations to us?
>>
>>
>>
>>Thanks
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] About snapshot Rollback?

[Erlon Cruz]

Hi Chen,

Not sure if I got you right but I brought this topic in #openstack-cinder
some days ago. The idea is to be able to rollback a snapshot in Cinder.
Today what is possible to do is to create a volume from a snapshot. From
the user point of view, this is not ideal, as there are several cases, if
not the majority of, that the purpose of the snapshot is to revert to a
desired state, and not keep the original volume. For some backends, keeping
the original volume means space consumption. This space problem becomes
bold when we think about consistency groups. For consistency groups, some
backends might have to copy an entire filesystem for each snapshot,
consuming space and time. So, I think it would be desired to have the
ability to revert snapshots.

I know there have been efforts in the past[1] to implement that, but for
some reason the work was stopped. If you want to retake the effort please
create a spec[2]  sol everybody can provide feedback.

Erlon


[1]
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot
[2] https://github.com/openstack/cinder-specs

On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang 
wrote:

> Hi all:
>
> We are condering add a fucntion rollback_snapshot when we use backup.
> In the end user's scenario. If a vm fails, we hope that we can use snapshot
> to to recovery the volume's data.
>
> Beacuse it can quickly recovery our vm. But if we use the remote data
> to recovery. We will spend more time.
>
> But i'm not sure if the data was recoveried from the backend. whether
> the host need to rescan the volumes? At the same time. If a volume have
> been extended, whether it can be roolback?
>
>
>
>I want to know whether the topic have been discussed or have other
> recommendations to us?
>
>
>
>Thanks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Nominate Rodrigo Barbieri for core reviewer team

[Erlon Cruz]

+1
Great addition. I'm not active in Manila, but we work in the same team in
our company and I see he is doing a great work! Well deserved!

On Tue, Feb 2, 2016 at 4:43 PM, Valeriy Ponomaryov  wrote:

> Rodrigo is the first person in queue for taking such responsibility.
> +2
>
> On Tue, Feb 2, 2016 at 8:14 PM, Dustin Schoenbrun 
> wrote:
>
>> +1 He's been a great resource to the community and the nomination is very
>> well deserved!
>>
>>
>> On 02/02/2016 12:58 PM, Knight, Clinton wrote:
>>
>>> +1  Great addition.  Welcome, Rodrigo!
>>>
>>> Clinton
>>>
>>>
>>> On 2/2/16, 12:30 PM, "Ben Swartzlander"  wrote:
>>>
>>> Rodrigo (ganso on IRC) joined the Manila project back in the Kilo
 release and has been working on share migration (an important core
 feature) for the last 2 releases. Since Tokyo he has dedicated himself
 to reviews and community participation. I would like to nominate him to
 join the Manila core reviewer team.

 -Ben Swartzlander
 Manila PTL


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> --
>> Dustin Schoenbrun
>> OpenStack Quality Engineer
>> Red Hat, Inc.
>> dscho...@redhat.com
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[Erlon Cruz]

Hmm, I see. There's this spec[1] that was discussed in the past with a
similar proposal. There's a SPEC with some other points on the discussion,
I think Janice forgot to mention.

Erlon

[1] https://review.openstack.org/#/c/176233/
[2] https://review.openstack.org/#/c/258968/

On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko <michal.du...@intel.com>
wrote:

> On 12/22/2015 01:29 PM, Erlon Cruz wrote:
> > Hi Li,
> >
> > Can you give a quick background on servicegroups (or links to. The
> > spec you linked only describe the process on Nova to change from what
> > they are using to tooz)? Also, what are the use cases and benefits of
> > using this?
> >
> > Erlon
> >
>
> This is simply and idea to be able to use something more sophisticated
> than DB heartbeats to monitor services states. With Tooz implemented for
> that we would be able to use for example ZooKeeper to know about service
> failure in a matter of seconds instead of around a minute. This would
> shrink the window in which c-sch doesn't-know-yet that c-vol failed and
> sends RPC messages to a service that will never answer. I think there
> are more use cases related to service monitoring and failover.
>
> Service groups isn't probably a correct name for proposed enhancement -
> we have this concept somehow implemented, but proposed idea seems to be
> related to making it pluggable.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] [Manila] Will NFS stay with Cinder as a reference implementation?

[Erlon Cruz]

Hi Vincent,

Just to complement what Mike and Gorka said, Cinder NFS drivers does not
provision FS services. It 'consumes' a FS export, and provisions block
storage.
To be more detailed, the Cinder NFS backend, mount a remote share from a
NFS server, and create/stores the cinder volumes as files inside this
exports on the volume node. In a scenario that you have Manila and Cinder,
if Manila is using the generic driver and Cinder the NFS backend, before
create a share, Manila will create a volume in Cinder, which will store
that in the NFS share as a file.

Erlon



On Tue, Sep 29, 2015 at 9:10 AM, Gorka Eguileor  wrote:

> On 29/09, Duncan Thomas wrote:
> > Cinder provides a block storage abstraction to a vm. Manila provides a
> > filesystem abstraction. The two are very different, and complementary. I
> > see no reason why the nfs related cinder drivers should be removed based
> on
> > the existence or maturity of manila - manila is not going to suddenly
> start
> > providing block storage to a vm.
> > On 29 Sep 2015 06:56, "Sheng Bo Hou"  wrote:
> >
> > > Hi folks,
> > >
> > > I have a question about the file services in OpenStack.
> > >
> > > As you know there is a generic NFS driver in Cinder and other file
> system
> > > drivers inherit it, while the project Manila is determined to provide
> the
> > > file system service.
> > >
> > > Will NFS stay with Cinder as the reference implementation for the
> coming
> > > release or releases? Are all the file system drivers going to move to
> > > Manila?
> > > What is relation between Manila as FSaaS and NFS in Cinder?
> > > Any ideas?
> > >
> > > Thank you.
> > >
> > > Best wishes,
> > > Vincent Hou (侯胜博)
> > >
> > > Staff Software Engineer, Open Standards and Open Source Team, Emerging
> > > Technology Institute, IBM China Software Development Lab
> > >
> > > Tel: 86-10-82450778 Fax: 86-10-82453660
> > > Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com
> > > Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
> > > West Road, Haidian District, Beijing, P.R.C.100193
> > > 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> > >
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
>
> I agree with Duncan,
>
> There is a clear distinction between the projects' objectives:
> - Cinder provides the canonical storage provisioning control plane in
>   OpenStack for block storage as well as delivering a persistence model
>   for instance storage.
> - Manila is a File Share Service, in a similar manner, provides
>   coordinated access to shared or distributed file systems.
>
> So I wouldn't move out our NFS drivers.
>
> As the relation between those is that while they both use the same
> storage type they expose it completely different.
>
> Cheers,
> Gorka.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Erlon Cruz]

Hi Cris,

There are some questions that came to my mind.

Cinder has near zero tolerance to backends that does not have a CI running.
So, can one assume that all drivers in Cinder will have the "OpenStack
Compatible" seal?

When you say that the driver have to 'pass' the integration tests, what
tests do you consider? All tests in tempest? All patches? Do you have any
criteria to determine if a backend is passing or not?

About this "OpenStack Compatible" flag, how does it work? Will you hold a
list with the Compatible vendors? Is anything a vendor need to to in order
to use this?

Thanks,
Erlon

On Mon, Sep 28, 2015 at 5:55 PM, Kyle Mestery  wrote:

> The Neutron team also discussed this in Vancouver, you can see the
> etherpad here [1]. We talked about the idea of creating a validation suite,
> and it sounds like that's something we should again discuss in Tokyo for
> the Mitaka cycle. I think a validation suite would be a great step forward
> for Neutron third-party CI systems to use to validate they work with a
> release.
>
> [1] https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty
>
> On Sun, Sep 27, 2015 at 11:39 AM, Armando M.  wrote:
>
>>
>>
>> On 25 September 2015 at 15:40, Chris Hoge  wrote:
>>
>>> In November, the OpenStack Foundation will start requiring vendors
>>> requesting
>>> new "OpenStack Compatible" storage driver licenses to start passing the
>>> Cinder
>>> third-party integration tests.
>>
>> The new program was approved by the Board at
>>> the July meeting in Austin and follows the improvement of the testing
>>> standards
>>> and technical requirements for the "OpenStack Powered" program. This is
>>> all
>>> part of the effort of the Foundation to use the OpenStack brand to
>>> guarantee a
>>> base-level of interoperability and consistency for OpenStack users and to
>>> protect the work of our community of developers by applying a trademark
>>> backed
>>> by their technical efforts.
>>>
>>> The Cinder driver testing is the first step of a larger effort to apply
>>> community determined standards to the Foundation marketing programs.
>>> We're
>>> starting with Cinder because it has a successful testing program in
>>> place, and
>>> we have plans to extend the program to network drivers and OpenStack
>>> applications. We're going require CI testing for new "OpenStack
>>> Compatible"
>>> storage licenses starting on November 1, and plan to roll out network and
>>> application testing in 2016.
>>>
>>> One of our goals is to work with project leaders and developers to help
>>> us
>>> define and implement these test programs. The standards for third-party
>>> drivers and applications should be determined by the developers and users
>>> in our community, who are experts in how to maintain the quality of the
>>> ecosystem.
>>>
>>> We welcome and feedback on this program, and are also happy to answer any
>>> questions you might have.
>>>
>>
>> Thanks for spearheading this effort.
>>
>> Do you have more information/pointers about the program, and how Cinder
>> in particular is
>> paving the way for other projects to follow?
>>
>> Thanks,
>> Armando
>>
>>
>>> Thanks!
>>>
>>> Chris Hoge
>>> Interop Engineer
>>> OpenStack Foundation
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [CINDER] [PTL Candidates] Questions

[Erlon Cruz]

John,

Thanks for the questions, it Ill really help me to make a the best choice.
I hadn't pondered the first question . +1 to make those and other if
suggest part of the candidate proposal.

Erlon

On Mon, Sep 21, 2015 at 6:49 AM, Duncan Thomas 
wrote:

> Hi John. Thanks for the questions.
>
>
>> 1. Do you actually have the time to spend to be PTL
>>
>
> I'm very much aware, and discussed with my management prior to standing,
> that being PTL is a pretty much full time job. I realise I'm somewhat
> limited by not being in a US time zone, however I'm pretty flexible with
> working hours, and already spend a few evening a week working US hours. I'd
> also like to use my time-zone shift as an advantage - I'm aware of how
> difficult it is for non-US contributors to get really involved in cinder
> due to our (generally very efficient) IRC-centric nature. I'd like to see
> if we can make better use of the tools we have for getting attention on
> bugs, features and reviews.
>
>
> 2. What are your plans to make the Cinder project as a core component
>> better (no... really, what specifically and how does it make Cinder better)?
>>
>
> My main worry with Cinder is that we're drifting away from the core vision
> of both Openstack and the original Cinder team - A really good cloud, with
> really good block storage, no matter the technology behind it. We've so
> many half-finished features, APIs that only work under limited
> circumstances and general development debt that is seriously hurting us
> going forward. The new features being proposed are getting more niche, more
> 'everything and the kitchen sink' and less 'top quality, rock solid
> service'. I'd like to shift a focus on back-to-basics, and work on fixing
> the road blocks to fixing these issues - we have plenty of competent
> motivated people, but communication and bureaucratic issues issues both
> within our team and between cinder and other projects (primarily but not
> limited to nova and glance) have gotten in the way.
>
> Things I'd like to see done this cycle:
> - Python3 work - let's just push through it and get it done. Maybe focus
> on it exclusively for a few days or a week some time this cycle. It's
> dragging on, and since we aren't at the point where cinder actually runs
> under python3, new problems slip in regularly.
>
> - Replication, CGs, online backup etc rolled out to more drivers. Lets
> limit the amount of new things drivers need to add this cycle until we've
> caught up on the backlog.
>
> - Nova <-> cinder API. Fixing this in a way that works for the nova team
> appears to need micro-versions. This API has been a thorn in our side for
> all sorts of new features and bugs many times, let's tame it.
>
> - Making CI failures easier to understand. I really struggle to read most
> CI failures, and so don't follow up on them as often as I should. I'm sure
> I'm not alone. I'm convinced that a small amount of work with white space,
> headings etc in devstack and tempest logs could give a really big boost.
> I'd also like to see a state other than 'failed' for situations where there
> was a problem with the CI system itself and so it didn't get as far as
> trying to deploy devstack. As I mentioned, we've enough smart people to
> make improvements that should allow us all to be more productive
>
> - Reducing review noise. I suspect that some policing and emailing people
> to improve etiquette on reviews (don't -1 for spelling and grammar, don't
> post a review until it is ready to be reviewed, give people time to batch
> comments rather than posting a new version for every nit, etc) will pay
> off, but it needs time dedicated to it.
>
> - Less out-of-band discussion on community decisions. I'm a big believer
> that discussion on record and in public, either on IRC or email, has much
> more value than private discussions and public statements. It also reduces
> accusations of bias and unfairness.
>
>
>> 3. ​Why do you want to be PTL for Cinder?
>>
>
> I wan to see cinder continue to succeed. My code contributions have, for
> various reasons, reduced in quantity and value against my efforts on
> mentoring, designs, reviews and communications. I'd like to free up the
> people who are actually writing good code to do more of that, by taking on
> more of the non-code burden and working to remove road blocks that are
> stopping people from making progress - be those internally with-in the
> team, between openstack teams or even helping people solve problems
> (managerial, legal or educational) within their own companies. I've had a
> fair bit of success at that in the past, and I believe that now is the time
> when those skills are the most effective ones to move cinder forward. We've
> a great technical team, so I want to enable them to do more, while keeping
> on top of scope creep and non-standardisation enough to enable cinder to be
> what I and many others would like it be.
>
>
>
>
> I hope this helps people with 

Re: [openstack-dev] [Cinder]Restrict volume creation based on type

[Erlon Cruz]

Hi Eduard,

What extra_specs do you configured in this volume_type?
Yes you can force a volume to an specific node, or backend. You must
configure the volume_backend_name on cinder.conf, and add an extra spec
volume_backend_name='same_as_in_cinder_conf' on the volume type  you
created.

For example:
[lvm1]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_backend_name = lvm

[lvm2]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_backend_name = lvm

Then:
cinder type-create lvm
$ cinder type-key lvm_node set volume_backend_name=lvm


On Fri, Jul 10, 2015 at 5:36 AM, Eduard Matei 
eduard.ma...@cloudfounders.com wrote:

 Hi,

 We've been testing a multi-node setup with our driver and ended up in a
 strange situation:
 - having a driver configured on multiple cinder nodes (But not all)
 - having a volume type (available)
 - creating a volume with specified volume type causes the volume to be
 created (attempted) on a node where the driver is not configured.

 We found something called storage_availability_zone but not quite
 understood it, and it looks like an extra choice in the Create volume
 wizard (which can be skipped/forgotten).

 So, question:
 - can we force a volume type to be tied to specific nodes? (something
 like availability zones, but determined based on volume type, not a
 separate setting)


 Thanks,

 --

 *Eduard Biceri Matei, Senior Software Developer*
 www.cloudfounders.com
  | eduard.ma...@cloudfounders.com



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

[Erlon Cruz]

Thanks Alex!

On Mon, May 4, 2015 at 11:38 AM, Alex Meade mr.alex.me...@gmail.com wrote:

 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/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit#gid=827503418

 -Alex

 On Mon, May 4, 2015 at 3:30 AM, liuxinguo liuxin...@huawei.com wrote:

   · I’m just trying to have a  analysis into it, maybe can begin
 with the “wrapper around the python-cinderclient” as George Peristerakis
 suggested.





 *发件人:* Erlon Cruz [mailto:sombra...@gmail.com]
 *发送时间:* 2015年4月27日 20:07
 *收件人:* OpenStack Development Mailing List (not for usage questions)
 *抄送:* Luozhen; Fanyaohong
 *主题:* Re: [openstack-dev] [cinder] Is there any way to put the driver
 backend error message to the horizon



 Alex,



 Any scratch of the solution you plan to propose?



 On Mon, Apr 27, 2015 at 5:57 AM, liuxinguo liuxin...@huawei.com wrote:

 Thanks for your suggestion, George. But when I looked into
 python-cinderclient (not very deep), I can not find the “wrapper around the
 python-cinderclient” you have mentioned.

 Could you please give me a little more hint to find the “wrapper”?



 Thanks,

 Liu





 *发件人:* George Peristerakis [mailto:gperi...@redhat.com]
 *发送时间:* 2015年4月13日 23:22
 *收件人:* OpenStack Development Mailing List (not for usage questions)
 *主题:* Re: [openstack-dev] [cinder] Is there any way to put the driver
 backend error message to the horizon



 Hi Lui,

 I'm not familiar with the error you are trying to show, but Here's how
 Horizon typically works. In the case of cinder, we have a wrapper around
 the python-cinderclient which if the client sends a exception with a valid
 message, by default Horizon will display the exception message. The message
 can also be overridden in the translation file. So a good start is to look
 in python-cinderclient and see if you could produce a more meaningful
 message.


 Cheers.
 George

 On 10/04/15 06:16 AM, liuxinguo wrote:

 Hi,



 When we create a volume in the horizon, there may occurrs some errors at the 
 driver

 backend, and the in horizon we just see a error in the volume status.



 So is there any way to put the error information to the horizon so users can 
 know what happened exactly just from the horizon?

 Thanks,

 Liu





  __

 OpenStack Development Mailing List (not for usage questions)

 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

[Erlon Cruz]

Alex,

Any scratch of the solution you plan to propose?

On Mon, Apr 27, 2015 at 5:57 AM, liuxinguo liuxin...@huawei.com wrote:

  Thanks for your suggestion, George. But when I looked into
 python-cinderclient (not very deep), I can not find the “wrapper around the
 python-cinderclient” you have mentioned.

 Could you please give me a little more hint to find the “wrapper”?



 Thanks,

 Liu





 *发件人:* George Peristerakis [mailto:gperi...@redhat.com]
 *发送时间:* 2015年4月13日 23:22
 *收件人:* OpenStack Development Mailing List (not for usage questions)
 *主题:* Re: [openstack-dev] [cinder] Is there any way to put the driver
 backend error message to the horizon



 Hi Lui,

 I'm not familiar with the error you are trying to show, but Here's how
 Horizon typically works. In the case of cinder, we have a wrapper around
 the python-cinderclient which if the client sends a exception with a valid
 message, by default Horizon will display the exception message. The message
 can also be overridden in the translation file. So a good start is to look
 in python-cinderclient and see if you could produce a more meaningful
 message.


 Cheers.
 George

 On 10/04/15 06:16 AM, liuxinguo wrote:

 Hi,



 When we create a volume in the horizon, there may occurrs some errors at the 
 driver

 backend, and the in horizon we just see a error in the volume status.



 So is there any way to put the error information to the horizon so users can 
 know what happened exactly just from the horizon?

 Thanks,

 Liu






  __

 OpenStack Development Mailing List (not for usage questions)

 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] cinder support matrix, chap support?

[Erlon Cruz]

Yes

On Mon, Apr 27, 2015 at 9:49 AM, Jordan Pittier jordan.pitt...@scality.com
wrote:

 Hi,
 Isn't CHAP iscsi-specific ?

 Jordan

 On Mon, Apr 27, 2015 at 2:41 PM, Dave Walker em...@daviey.com wrote:

 Hi,

 Recently I have been curious as to which Cinder drivers support
 authentication. It seems that only a subset do.  I wondered, is this
 something that would be useful on the CinderSupportMatrix wiki page?

 Thanks

 --
 Kind Regards,
 Dave Walker

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack live migration using devstack

[Erlon Cruz]

Had the same error, but with cinder. Did you find find out something about
this error?

2015-04-17 14:12:31.957 TRACE cinder Traceback (most recent call last):
2015-04-17 14:12:31.957 TRACE cinder   File /usr/local/bin/cinder-volume,
line 10, in module
2015-04-17 14:12:31.957 TRACE cinder sys.exit(main())
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/cmd/volume.py, line 72, in main
2015-04-17 14:12:31.957 TRACE cinder binary='cinder-volume')
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/service.py, line 249, in create
2015-04-17 14:12:31.957 TRACE cinder service_name=service_name)
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/service.py, line 129, in __init__
2015-04-17 14:12:31.957 TRACE cinder *args, **kwargs)
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/volume/manager.py, line 195, in __init__
2015-04-17 14:12:31.957 TRACE cinder *args, **kwargs)
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/manager.py, line 130, in __init__
2015-04-17 14:12:31.957 TRACE cinder super(SchedulerDependentManager,
self).__init__(host, db_driver)
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/manager.py, line 80, in __init__
2015-04-17 14:12:31.957 TRACE cinder super(Manager,
self).__init__(db_driver)
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/db/base.py, line 42, in __init__
2015-04-17 14:12:31.957 TRACE cinder self.db.dispose_engine()
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/db/api.py, line 80, in dispose_engine
2015-04-17 14:12:31.957 TRACE cinder if 'sqlite' not in
IMPL.get_engine().name:
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/db/sqlalchemy/api.py, line 85, in get_engine
2015-04-17 14:12:31.957 TRACE cinder facade = _create_facade_lazily()
2015-04-17 14:12:31.957 TRACE cinder   File
/opt/stack/cinder/cinder/db/sqlalchemy/api.py, line 72, in
_create_facade_lazily
2015-04-17 14:12:31.957 TRACE cinder **dict(CONF.database.iteritems())
2015-04-17 14:12:31.957 TRACE cinder   File
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.py,
line 796, in __init__
2015-04-17 14:12:31.957 TRACE cinder **engine_kwargs)
2015-04-17 14:12:31.957 TRACE cinder   File
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.py,
line 376, in create_engine
2015-04-17 14:12:31.957 TRACE cinder url =
sqlalchemy.engine.url.make_url(sql_connection)
2015-04-17 14:12:31.957 TRACE cinder   File
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
176, in make_url
2015-04-17 14:12:31.957 TRACE cinder return
_parse_rfc1738_args(name_or_url)
2015-04-17 14:12:31.957 TRACE cinder   File
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
225, in _parse_rfc1738_args
2015-04-17 14:12:31.957 TRACE cinder Could not parse rfc1738 URL from
string '%s' % name)
2015-04-17 14:12:31.957 TRACE cinder ArgumentError: Could not parse rfc1738
URL from string ''
2015-04-17 14:12:31.957 TRACE cinder
c-vol failed to start


On Mon, Mar 10, 2014 at 12:44 PM, abhishek jain ashujain9...@gmail.com
wrote:

 Hi all

 I have created one openstack using one controller node and one compute
 node both installed using devstack.I'm running one instance on controller
 node and want to migrate it to over compute node.
 I'm using following link for this.


 http://docs.openstack.org/grizzly/openstack-compute/admin/content/live-migration-usage.html

 http://docs.openstack.org/grizzly/openstack-compute/admin/content/configuring-migrations.html

 The output of  nova-manage vm list  on the compute node is as follows..

 10 16:01:49.502 DEBUG nova.openstack.common.lockutils
 [req-019d2337-143e-4157-9d6c-3c1f2207f63b None None] Semaphore / lock
 released __get_backend inner
 /opt/stack/nova/nova/openstack/common/lockutils.py:252
 Command failed, please check log for more info
 2014-03-10 16:01:49.507 CRITICAL nova
 [req-019d2337-143e-4157-9d6c-3c1f2207f63b None None] Could not parse
 rfc1738 URL from string ''
 2014-03-10 16:01:49.507 9609 TRACE nova Traceback (most recent call last):
 2014-03-10 16:01:49.507 9609 TRACE nova   File /usr/bin/nova-manage,
 line 10, in module
 2014-03-10 16:01:49.507 9609 TRACE nova sys.exit(main())
 2014-03-10 16:01:49.507 9609 TRACE nova   File
 /opt/stack/nova/nova/cmd/manage.py, line 1378, in main
 2014-03-10 16:01:49.507 9609 TRACE nova ret = fn(*fn_args,
 **fn_kwargs)
 2014-03-10 16:01:49.507 9609 TRACE nova   File
 /opt/stack/nova/nova/cmd/manage.py, line 658, in list
 2014-03-10 16:01:49.507 9609 TRACE nova context.get_admin_context(),
 host)
 2014-03-10 16:01:49.507 9609 TRACE nova   File
 /opt/stack/nova/nova/db/api.py, line 671, in instance_get_all_by_host
 2014-03-10 16:01:49.507 9609 TRACE nova return
 IMPL.instance_get_all_by_host(context, host, columns_to_join)
 2014-03-10 

Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon

[Erlon Cruz]

I like Duncan's idea. To have a dash in horizon where admin can see error
events. It can hide backend details from tenants and  would save the time
of browsing through logs seeking for the operations that  caused errors
(the request id also should be logged in the metadata to allow further
investigation). We have notice this problem while ago, and at the time we
found this bug[1] about the same problem.

[1] https://bugs.launchpad.net/horizon/+bug/1352516


On Fri, Apr 10, 2015 at 5:26 PM, gordon chung g...@live.ca wrote:

  I'd say events are *more* useful in that workflow, not less, as long as
  they contain enough context. For example, the user creates a volume,
  tries to attach it which fails for some config error, so the user
  deletes it. With an event based model, the admin now has an error event
  in their queue. If we used a db field then the error status is
  potentially revived by the successful delete.

 +1

 Nova currently emits a good set of events and errors and we've found it
 especially useful to debug / do postmortem analysis by collecting these
 notifications and being able to view the entire workflow. we've found quite
 a few occasions where the error popups presented in Horizon are not the
 real error but just the last/wrapped error.

 there are various consumers that already collate these error notifications
 from Nova and i don't think it's much of a change if any to collect error
 notifications from Cinder. i don't think there's any change from Ceilometer
 POV -- just publish to error topic.

 cheers,

 gord

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Deadline For Volume Drivers to Be Readded

[Erlon Cruz]

Hi Mike,

The majority of the CIs don't run all 304 tests mostly because of these
tempest problems. I remember there was a list in the Thirdparty CI Wiki
with the common tests that used to fails to everyone, or at least most of
people.  IMO its better to have a more consistent CI than CIs with full
coverage giving lots of false negatives. Don't how much of the tests from
that list are fixed on tempest but we should bring that list up again and
reconsider to have the list of 'known to fail' tests.

Our HBSD drivers are only running 211 because we remove the snapshots tests
that were failing due a  patch that broken our driver.



On Thu, Mar 26, 2015 at 2:21 PM, Mike Perez thin...@gmail.com wrote:

 On 09:39 Thu 26 Mar , Mike Perez wrote:
  As discussed in the last Cinder meeting [1], in order to have your volume
  driver readded into the Kilo release, you must have a CI reporting and
 stable
  for five days prior to 4/6.
 
  This includes:
 
  1) Providing logs to screen sessions, etc configs, tempest output [2].
  2) You should be running around 304 tests if you're following
 instructions from
 the Cinder third party wiki [3]. If you're running less than that,
 your CI
 will be *NOT* be considered satisfactory for skipping tests.
 
  I will also be emailing individuals who have already asked for
 exceptions, just
  to make sure communication was clear.
 
 
  [1] -
 http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
  [2] - http://ci.openstack.org/third_party.html#requirements
  [3] -
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

 The current CI's not meeting the second requirement:

 * Cloudbyte
 * Dell EQL
 * Dell SC FC
 * Dell SC ISCSI
 * EMC VMAX FC
 * EMC VMX ISCSI
 * EMC VNX FC
 * EMC VNX ISCSI
 * EMC XIO FC
 * EMC XIO ISCSI
 * HDS NFS
 * HDS NAS
 * Hitachi HBSD FC
 * Hitach HBSD ISCSI
 * IBM Flash Systems FC
 * IBM Flash Systems ISCSI
 * IBM NAS
 * IBM XIV (couldn't find tempest results to verify)
 * IBM Storwize FC
 * IBM Storwize ISCSI
 * Nimble
 * OpenVStorage
 * Quobyte
 * XIO FC
 * XIO ISCSI
 * Vmware

 Pretty sure this is because the previous instructions in the wiki were
 incorrect and are now corrected [1]. This is not the fault of the CI
 maintainers. As mentioned, individual emails are being sent out to get
 this all
 sorted.


 [1] -
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

 --
 Mike Perez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014

[Erlon Cruz]

Mike, for HDS and Hitachi, the contact person is the same:
openstackdevelopm...@hds.com. Also, we have 5 drivers:

- HDS HNAS NFS
- HDS HNAS iSCSI
- HBSD FC
- HBSD iSCSI
- HDS HUS

This last one, HDS HUS, is deprecated by HBSD drivers and won't be
maintained, so you can add it in the removal list.

On Thu, Mar 19, 2015 at 1:36 PM, Mike Perez thin...@gmail.com wrote:

 On Wed, Mar 18, 2015 at 11:38 PM, Bharat Kumar
 bharat.kobag...@redhat.com wrote:
  Regarding the GlusterFS CI:
 
  As I am dealing with end to end CI process of GlusterFS, please modify
 the
  contact person to bharat.kobag...@redhat.com.
 
  Because of this I may miss important announcements from you regarding the
  CI.

 Done.

 --
 Mike Perez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

[Erlon Cruz]

I agree with John (comment on the mentioned patchset). Also, I expected one
change removing all drivers that does not report on CI. There's one of us
(HUSDriver) that is not maintained and also should be deprecated/removed.

Liu, the best argument here would be a report from your CI in this patch
saying it fails.

On Thu, Mar 19, 2015 at 11:13 PM, liuxinguo liuxin...@huawei.com wrote:

  Hi Mike,



 I have seen the patch at https://review.openstack.org/#/c/165990/ saying
 that huawei driver will be removed because “the maintainer does not have a
 CI reporting to ensure their driver integration is successful”.



 But in fact we really have a CI months ago and it is really reporting to
 reviews, the most resently posts are:‍



 *https://review.openstack.org/#/c/165796/

 Post time:‍ 2015-3-19 0:14:56



 *https://review.openstack.org/#/c/164697/

 Post time: 2015-3-18 23:55:37



 *https://review.openstack.org/164702/

 Post time: 2015-3-18 23:55:37



 *https://review.openstack.org/#/c/152401/

 Post time: 3-18 23:08:45



 And if you want, I will give you more proof of reviews.



 Thanks and regards,

 Liu

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

[Erlon Cruz]

Ok, thanks Anne!

On Tue, Mar 10, 2015 at 6:10 PM, Anne Gentle annegen...@justwriteclick.com
wrote:



 On Tue, Mar 10, 2015 at 3:35 PM, Erlon Cruz sombra...@gmail.com wrote:

 Hi Anne,

 Thanks for the quick answer. One thing that still not clear for me is
 about the documentation that is currently there. Will it be removed
 (converted to the resumed version) in Kilo? If so what are the milestones
 for that?


 All deadlines revolve around the release of Kilo and time for reviews. I
 don't know if we are planning on a purge with all the migration work still
 to be done, so please just work on best effort by April 9th so the doc team
 can work with you.

 Thanks,
 Anne



 Erlon

 On Tue, Mar 10, 2015 at 10:48 AM, Anne Gentle 
 annegen...@justwriteclick.com wrote:



 On Tue, Mar 10, 2015 at 8:28 AM, Erlon Cruz sombra...@gmail.com wrote:

 Hi Anne,

 How about driver documentation that is in the old format? Will it be
 removed in Kilo?



 Hi Erlon,
 The spec doesn't have a specific person assigned for removal, and the
 only drivers the docs team signed up for through the blueprint are these:


- For cinder: volume drivers: document LVM and NFS; backup drivers:
document swift
- For glance: Document local storage, cinder, and swift as backends
- For neutron: document ML2 plug-in with the mechanisms drivers
OpenVSwitch and LinuxBridge
- For nova: document KVM (mostly), send Xen open source call for help
- For sahara: apache hadoop
- For trove: document all supported Open Source database engines
like MySQL.





 The wiki says: Bring all driver sections that are currently just
 ‘bare bones’ up to the standard mentioned. Will this be performed by core
 team?


 Andreas has done some of that work, for example here:
 https://review.openstack.org/#/c/157086/

 We can use more hands of course, just coordinate the work here on the
 list. And Andreas, if there aren't any more to do, let us know. :)
 Thanks,
 Anne




 Thanks,
 Erlon

 On Fri, Mar 6, 2015 at 4:58 PM, Anne Gentle 
 annegen...@justwriteclick.com wrote:

 Hi all,

 We have been working on streamlining driver documentation for Kilo
 through a specification, on the mailing lists, and in my weekly What's Up
 Doc updates. Thanks for the reviews while we worked out the solutions.
 Here's the final spec:

 http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html

 Driver documentation caretakers, please note the following summary:

 - At a minimum, driver docs are published in the Configuration
 Reference at with tables automatically generated from the code. There's a
 nice set of examples in this patch:
 https://review.openstack.org/#/c/157086/

 - If you want full driver docs on docs.openstack.org, please add a
 contact person's name and email to this wiki page:
 https://wiki.openstack.org/wiki/Documentation/VendorDrivers

 - To be included in the April 30 release of the Configuration
 Reference, driver docs are due by April 9th.

 Thanks all for your collaboration and attention.

 Anne


 --
 Anne Gentle
 annegen...@justwriteclick.com


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Anne Gentle
 annegen...@justwriteclick.com


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Anne Gentle
 annegen...@justwriteclick.com

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

[Erlon Cruz]

Hi Anne,

How about driver documentation that is in the old format? Will it be
removed in Kilo? The wiki says: Bring all driver sections that are
currently just ‘bare bones’ up to the standard mentioned. Will this be
performed by core team?

Thanks,
Erlon

On Fri, Mar 6, 2015 at 4:58 PM, Anne Gentle annegen...@justwriteclick.com
wrote:

 Hi all,

 We have been working on streamlining driver documentation for Kilo through
 a specification, on the mailing lists, and in my weekly What's Up Doc
 updates. Thanks for the reviews while we worked out the solutions. Here's
 the final spec:

 http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html

 Driver documentation caretakers, please note the following summary:

 - At a minimum, driver docs are published in the Configuration Reference
 at with tables automatically generated from the code. There's a nice set of
 examples in this patch: https://review.openstack.org/#/c/157086/

 - If you want full driver docs on docs.openstack.org, please add a
 contact person's name and email to this wiki page:
 https://wiki.openstack.org/wiki/Documentation/VendorDrivers

 - To be included in the April 30 release of the Configuration Reference,
 driver docs are due by April 9th.

 Thanks all for your collaboration and attention.

 Anne


 --
 Anne Gentle
 annegen...@justwriteclick.com

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] 3rd Party CI failures ignored, caused driver to break

[Erlon Cruz]

Agreed, CI systems are not reliable. Most of failures are related to
mis-configuration or devstack problems, not driver problems itself. What
happen then, is that people just don't care if there's a red FAILURE in the
CIs results. A 4) option would be to rate CIs according to their
trustfulness (may be a composition counter of uptime and false negatives),
then the developers would pay more attention if they broke a reliable  CI.
Also, this rating could be used as parameter to decide if a CI should vote
or not.

On Thu, Feb 26, 2015 at 5:24 PM, John Griffith john.griffi...@gmail.com
wrote:



 On Thu, Feb 26, 2015 at 1:10 PM, Walter A. Boring IV walter.bor...@hp.com
  wrote:

 Hey folks,
Today we found out that a patch[1] that was made against our lefthand
 driver caused the driver to fail.   The 3rd party CI that we have setup
 to test our driver (hp_lefthand_rest_proxy.py) caught the CI failure and
 reported it correctly[2].  The patch that broke the driver was reviewed and
 approved without a mention of 3rd Party CI failures.

 This is a perfect example of 3rd Party CI working perfectly and catching
 a failure, and being completely ignored by everyone
 involved in the review process for the patch

 I know that 3rd party CI isn't perfect, and has been ripe with false
 failures, which is one of the reasons why they aren't voting today.
 But, that being said, if patch submitters aren't even looking at the
 failures for CI when they are touching drivers that they don't maintain,
 and reviewers
 aren't looking at the CI failures, then why are we even doing 3rd party
 CI?

 Our team is partially responsible for not seeing the failure as well.  We
 should be watching the CI failures closely, but we are doing the best we
 can.  There are enough patches for Cinder ongoing at any one time, that
 we simply can't watch every single one of them for failures. We did
 eventually
 see that every single patchset in gerrit was now failing against our
 driver, and this is how we caught it.  Yes, it was a bit after the fact,
 but we did notice
 it and now have a new patch up that fixes it.   So, in that regard 3rd
 party CI did eventually vet out a problem that our team caught.

 How can we prevent this in the future?
 1) Make 3rd party CI voting.  I don't believe this is ready yet.


 ​Agreed, look at the history on that driver (and many others) and you'll
 see we are in no way ready for that.​


 2) Authors and reviews need to look at 3rd party CI failures when a patch
 touches a driver.  If a failure is seen, contact the CI maintainer and work
 with them and
 see if the failure is related to the patch, if it's not obvious. In this
 case, the failure was obvious.  The import changed, and now the package
 can't find the module.


 ​If things were more stable yeah, I might, but the reality is as I've
 pointed out we have a serious signal to noise ratio problem IMO
 ​


 3) CI maintainers watch every single patchset and report -1's on
 reviews?  (ouch)
 4) ?


 ​Option 4 in my opinion is exactly what I've been doing since this
 started.  I receive a notification for any change that my CI setup fails
 on, and then it's up to me to go and verify if something is truly broken or
 if it's my system that's messed up.  It's not perfect and it's not really a
 true CI but it is a continuous test system which for me is what's most
 important here.  I completely understand that's not the case for other
 things.

 This is where the churn of typo fixes, hacking changes etc can bight us.
 Sure, while reviewing that probably could've/should've been caught.  The
 problem is for me at least if we're going to do this sorts of semantic
 changes that touch so many files I'm likely to be half asleep before I get
 to the cinder/volume section.  Doesn't make it right, but kinda how it is.

 Anyway, yeah it sucks, but I'd argue this worked out GREAT.  A change was
 made that broke things in LHN driver, but historically nobody would've
 known until a customer tried to use it.  In this case, the problem was
 found in less than a day and fixed.  That's a pretty huge win in my opinion!

 Thanks,
 John​





 Here is the patch that broke the lefthand driver[1]
 Here is the reported failure in the c-vol log for the patch by our 3rd
 party CI system[2]
 Here is my new patch that fixes the lefthand driver again.[3]

 [1] https://review.openstack.org/#/c/145780/
 [2] http://15.126.198.151/80/145780/15/check/lefthand-
 iscsi-driver-master-client-pip-dsvm/3927e3d/logs/screen-
 c-vol.txt.gz?level=ERROR
 [3] https://review.openstack.org/#/c/159586/

 $0.02
 Walt

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
 unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List 

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

[Erlon Cruz]

Hi Anne,

Thanks for the quick answer. One thing that still not clear for me is about
the documentation that is currently there. Will it be removed (converted to
the resumed version) in Kilo? If so what are the milestones for that?

Erlon

On Tue, Mar 10, 2015 at 10:48 AM, Anne Gentle annegen...@justwriteclick.com
 wrote:



 On Tue, Mar 10, 2015 at 8:28 AM, Erlon Cruz sombra...@gmail.com wrote:

 Hi Anne,

 How about driver documentation that is in the old format? Will it be
 removed in Kilo?



 Hi Erlon,
 The spec doesn't have a specific person assigned for removal, and the only
 drivers the docs team signed up for through the blueprint are these:


- For cinder: volume drivers: document LVM and NFS; backup drivers:
document swift
- For glance: Document local storage, cinder, and swift as backends
- For neutron: document ML2 plug-in with the mechanisms drivers
OpenVSwitch and LinuxBridge
- For nova: document KVM (mostly), send Xen open source call for help
- For sahara: apache hadoop
- For trove: document all supported Open Source database engines like
MySQL.





 The wiki says: Bring all driver sections that are currently just ‘bare
 bones’ up to the standard mentioned. Will this be performed by core team?


 Andreas has done some of that work, for example here:
 https://review.openstack.org/#/c/157086/

 We can use more hands of course, just coordinate the work here on the
 list. And Andreas, if there aren't any more to do, let us know. :)
 Thanks,
 Anne




 Thanks,
 Erlon

 On Fri, Mar 6, 2015 at 4:58 PM, Anne Gentle 
 annegen...@justwriteclick.com wrote:

 Hi all,

 We have been working on streamlining driver documentation for Kilo
 through a specification, on the mailing lists, and in my weekly What's Up
 Doc updates. Thanks for the reviews while we worked out the solutions.
 Here's the final spec:

 http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html

 Driver documentation caretakers, please note the following summary:

 - At a minimum, driver docs are published in the Configuration Reference
 at with tables automatically generated from the code. There's a nice set of
 examples in this patch: https://review.openstack.org/#/c/157086/

 - If you want full driver docs on docs.openstack.org, please add a
 contact person's name and email to this wiki page:
 https://wiki.openstack.org/wiki/Documentation/VendorDrivers

 - To be included in the April 30 release of the Configuration Reference,
 driver docs are due by April 9th.

 Thanks all for your collaboration and attention.

 Anne


 --
 Anne Gentle
 annegen...@justwriteclick.com


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Anne Gentle
 annegen...@justwriteclick.com

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Etherpad for volume replication created ...

[Erlon Cruz]

Do you have the log of the discussion as well?

On Fri, Feb 13, 2015 at 7:09 AM, Danny Al-Gaaf danny.al-g...@bisect.de
wrote:

 Hi Jay,

 do you have a link to the etherpad?

 Danny

 Am 13.02.2015 um 05:54 schrieb Jay S. Bryant:
  All,
 
  Several members of the Cinder team and I were discussing the
  current state of volume replication while trying to figure out the
  best way to resolve bug 1383524 [1].  The outcome of the discussion
  was a decision to hold off on integrating volume replication
  support for additional drivers.
 
  I took notes from the discussion and have put them in the etherpad.
  We can use that, first thing in L, as a starting point to rework
  and fix replication support.
 
  Please let me know if you have any questions and feel free to
  update the etherpad with addition thoughts.
 
  Thanks! Jay
 
 
  [1] https://bugs.launchpad.net/cinder/+bug/1383524--  Periodic
  update replication status causing issues
 
 
 __
 
 
 OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] K-2 Review-a-thon

[Erlon Cruz]

Hi Mike,

There is 2 features[1][2][3] of HNAS driver that still are not
approved/targeted.
Is there anything missing to then to be approved?

Erlon


[1] https://blueprints.launchpad.net/cinder/+spec/hds-hnas-ssh-backend
[2] https://blueprints.launchpad.net/cinder/+spec/hds-hnas-pool-aware-sched
[3] https://bugs.launchpad.net/cinder/+bug/1402771

On Sat, Jan 31, 2015 at 7:30 PM, Mike Perez thin...@gmail.com wrote:

 * Why: We got a bit in the review queue. K-2 [1] cut is set to February
 5th.

 * When: February 2nd at 2:00 UTC [2] to February 5th at 2:00 UTC [3]
 or sooner if we finish!

 * Where: #openstack-cinder on freenode IRC. There will also be a
 posted google hangout link in channel and etherpad [4] since that
 really worked out in previous hackathons. Remember there is a limit,
 so please join only if you're really going to be participating. You
 also don't have to be core.

 I'm encouraging two cores to sign up for a review in the etherpad [4].
 If there are already two people to a review, try to move onto
 something else to avoid getting burnt out on efforts already spent on
 a review.

 Patch owners will also be receiving an email directly from me to be
 aware of this prime time to respond back to feedback and post
 revisions if necessary.

 --
 Mike Perez

 [1] - https://launchpad.net/cinder/+milestone/kilo-2
 [2] -
 http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150202T02p1=1440
 [3] -
 http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150205T02p1=1440
 [4] - https://etherpad.openstack.org/p/cinder-k2-priorities

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

[Erlon Cruz]

Thanks Deepak!


Mike is also sending the announce to the vendors in the mail accounts
listed in the CI Status page[1].

[1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status

On Tue, Jan 20, 2015 at 6:47 AM, Deepak Shetty dpkshe...@gmail.com wrote:

 Yuck ! its Mar. 19, 2015 (bad copy paste before)

 On Tue, Jan 20, 2015 at 12:16 PM, Deepak Shetty dpkshe...@gmail.com
 wrote:

 Just so that people following this thread know about the final decision,
 Per
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines
 the deadline for CI is extended to Mar. 3, 2015 for all volume drivers.

 snip
 Deadlines

 All volume drivers
 https://github.com/openstack/cinder/tree/master/cinder/volume/drivers
 need to have a CI by end of* K-3, March 19th 2015*.* Failure will result
 in removal in the Kilo release.* Discussion regarding this was in the
 #openstack-meeting IRC room during the Cinder meeting. Read discussion
 logs
 http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21

 /snip

 On Tue, Jan 13, 2015 at 3:55 AM, Mike Perez thin...@gmail.com wrote:

 On 09:03 Mon 12 Jan , Erlon Cruz wrote:
  Hi guys,
 
  Thanks for answering my questions. I have 2 points:
 
  1 - This (remove drivers without CI) is a way impacting change to be
  implemented without exhausting notification and discussion on the
 mailing
  list. I myself was in the meeting but this decision wasn't crystal
 clear.
  There must be other driver maintainers completely unaware of this.

 I agree that the mailing list has not been exhausted, however, just
 reaching
 out to the mailing list is not good enough. My instructions back in
 November
 19th [1][2] were that we need to email individual maintainers and the
 openstack-dev list. That was not done. As far as I'm concerned, we can't
 stick
 to the current deadline for existing drivers. I will bring this up in
 the next
 Cinder meeting.

  2 - Build a CI infrastructure and have people to maintain a the CI for
 a
  new driver in a 5 weeks frame. Not all companies has the knowledge and
  resources necessary to this in such sort period. We should consider a
 grace
  release period, i.e. drivers entering on K, have until L to implement
  theirs CIs.

 New driver maintainers have until March 19th. [3] That's around 17 weeks
 since
 we discussed this in November [2]. This is part the documentation for
 how to
 contribute a driver [4], which links to the third party requirement
 deadline
 [3].

 [1] -
 http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html
 [2] -
 http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34
 [3] -
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines
 [4] - https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

 --
 Mike Perez


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

[Erlon Cruz]

Hi guys,

Thanks for answering my questions. I have 2 points:

1 - This (remove drivers without CI) is a way impacting change to be
implemented without exhausting notification and discussion on the mailing
list. I myself was in the meeting but this decision wasn't crystal clear.
There must be other driver maintainers completely unaware of this.

2 - Build a CI infrastructure and have people to maintain a the CI for a
new driver in a 5 weeks frame. Not all companies has the knowledge and
resources necessary to this in such sort period. We should consider a grace
release period, i.e. drivers entering on K, have until L to implement
theirs CIs.

On Mon, Jan 12, 2015 at 4:07 AM, Asselin, Ramy ramy.asse...@hp.com wrote:

 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
 process is encouraged to attend. [1]

 [1] https://wiki.openstack.org/wiki/Meetings/ThirdParty

 Ramy

 -Original Message-
 From: Mike Perez [mailto:thin...@gmail.com]
 Sent: Sunday, January 11, 2015 6:53 PM
 To: jsbry...@electronicjungle.net; OpenStack Development Mailing List
 (not for usage questions)
 Subject: Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

 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, correct me if I am wrong.
 
  Jay
  On 01/10/2015 04:52 PM, Mike Perez wrote:
  On 14:42 Fri 09 Jan , Ivan Kolodyazhny wrote:
  Hi Erlon,
  
  We've got a thread mailing-list [1] for it and some details in wiki
 [2].
  Anyway, need to get confirmation from our core devs and/or Mike.
  
  [1]
  http://lists.openstack.org/pipermail/openstack-dev/2014-October/0495
  12.html
  [2]
  https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testi
  ng_requirements_for_Kilo_release_and_beyond
  
  Regards,
  Ivan Kolodyazhny
  
  On Fri, Jan 9, 2015 at 2:26 PM, Erlon Cruz sombra...@gmail.com
 wrote:
  
  Hi all, hi cinder core devs,
  
  I have read on IRC discussions about a deadline for drivers vendors
  to have their CI running and voting until kilo-2, but I didn't find
  any post on this list to confirm this. Can anyone confirm this?
  
  Thanks,
  Erlon
  We did discuss and agree in the Cinder meeting that the deadline
  would be k-2, but I don't think anyone reached out to the driver
  maintainers about the deadline. Duncan had this action item [1],
 perhaps he can speak more about it.
  
  [1] -
  http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19
  -16.00.html
  

 That is correct [1]. However, I don't think there was any warning given to
 existing drivers [2]. If Duncan can confirm this is the case, I would
 recommend fair warning go out for the end of Kilo for existing drivers as
 well.

 [1] -
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines
 [2] -
 http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html

 --
 Mike Perez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

[Erlon Cruz]

Hi Ivan, thanks !!

On Fri, Jan 9, 2015 at 10:42 AM, Ivan Kolodyazhny e...@e0ne.info wrote:

 Hi Erlon,

 We've got a thread mailing-list [1] for it and some details in wiki [2].
 Anyway, need to get confirmation from our core devs and/or Mike.

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-October/049512.html
 [2]
 https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond

 Regards,
 Ivan Kolodyazhny

 On Fri, Jan 9, 2015 at 2:26 PM, Erlon Cruz sombra...@gmail.com wrote:

 Hi all, hi cinder core devs,

 I have read on IRC discussions about a deadline for drivers vendors to
 have their CI running and voting until kilo-2, but I didn't find any post
 on this list to confirm this. Can anyone confirm this?

 Thanks,
 Erlon

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Cutoff deadlines for cinder drivers

[Erlon Cruz]

Hi all, hi cinder core devs,

I have read on IRC discussions about a deadline for drivers vendors to have
their CI running and voting until kilo-2, but I didn't find any post on
this list to confirm this. Can anyone confirm this?

Thanks,
Erlon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] how to delete a volume which is in error_deleting state

[Erlon Cruz]

This is usually is related to mis-configuration on the backend driver. For
example, if you create a volume, shutdown the driver to change some
configuration, the backend driver can get confused while trying to delete
the volume or even can't be able to locate the volume in the storage array.
S

On Mon, Jan 5, 2015 at 3:35 AM, Eli Qiao ta...@linux.vnet.ibm.com wrote:


 在 2015年01月05日 13:02, Punith S 写道:

 Hi Eli,

  you have to log-in to MySQL cinder database , and try deleting the
 required volume from the volumes table using the id.
 if it fails due to foreign key constraints in volume metadata table, try
 deleting the corresponding volume metadata and then try to delete the
 required volume row.

   hi Punith, I did as your suggestion, it works. but is that reasonable
 not to delete a error_deleting even that status keeping for a quite long
 time?
 thanks.

  thanks

 On Mon, Jan 5, 2015 at 7:22 AM, Eli Qiao ta...@linux.vnet.ibm.com wrote:


 hi all,
 how to delete a cinder volume which is in error_deleting status ?
 I don't find force delete options in 'cinder delete',  then how we fix it
 if we got such situation ?
 [tagett@stack-01 devstack]$ cinder list

 +--++-+--+-+--+--+
 |  ID  | Status | Name|
 Size | Volume Type | Bootable | Attached to  |

 +--++-+--+-+--+--+
 | 3e0acd0a-f28f-4fe3-b6e9-e65d5c40740b | in-use | with_cirros |
 4   | lvmdriver-1 |   true   | 428f0235-be54-462f-8916-f32965d42e63 |
 | 7039c683-2341-4dd7-a947-e35941245ec4 | error_deleting | None|
 4   | lvmdriver-1 |  false   |  |
 | d576773f-6865-4959-ba26-13602ed32e89 | error_deleting | None|
 4   | lvmdriver-1 |  false   |  |

 +--++-+--+-+--+--+
 [tagett@stack-01 devstack]$ cinder delete
 7039c683-2341-4dd7-a947-e35941245ec4
 Delete for volume 7039c683-2341-4dd7-a947-e35941245ec4 failed: Bad
 Request (HTTP 400) (Request-ID: req-e4d8cdd9-6ed5-4a7f-81de-7f38f2163d33)
 ERROR: Unable to delete any of specified volumes.

 --
 Thanks,
 Eli (Li Yong) Qiao


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  --
  regards,

  punith s
 cloudbyte.com


 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 --
 Thanks,
 Eli (Li Yong) Qiao


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder driver] A question about Kilo merge point

[Erlon Cruz]

Hi,

Yes, I think that the changes of being merged after K1 are few. Check this
docs with the priority list that the core team are working on:

https://etherpad.openstack.org/p/cinder-kilo-priorities

Erlon

On Tue, Dec 16, 2014 at 9:40 AM, liuxinguo liuxin...@huawei.com wrote:

  If a cinder driver can not be mergerd into Kilo before Kilo-1, does it
 means that this driver will has very little chance to be merged into Kilo?

 And what percentage of drivers will be merged before Kilo-1 according to
 the whole drivers that will be merged into Kilo at last?



 Thanks!

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Third-party] Voting for new Third-party CI weekly IRC meeting time

[Erlon Cruz]

Both are fine, but A is better.

On Tue, Dec 9, 2014 at 10:46 PM, Kurt Taylor kurt.r.tay...@gmail.com
wrote:

 So far it looks like we have centered around 2 options:
 Option A 1200 and 2200 UTC
 Option D 1500 and 0400 UTC

 There is still time to pick your best time. Please vote at
 https://www.google.com/moderator/#16/e=21b93c

 Special thanks to Steve, Daya, Markus, Mikhail, Emily, Nurit, Edwin and
 Ramy for taking the time to vote.

 Kurt Taylor (krtaylor)


 On Tue, Dec 9, 2014 at 9:32 AM, Kurt Taylor kurt.r.tay...@gmail.com
 wrote:

 All of the feedback so far has supported moving the existing IRC
 Third-party CI meeting to better fit a worldwide audience.

 The consensus is that we will have only 1 meeting per week at
 alternating times. You can see examples of other teams with alternating
 meeting times at: https://wiki.openstack.org/wiki/Meetings

 This way, one week we are good for one part of the world, the next week
 for the other. You will not need to attend both meetings, just the meeting
 time every other week that fits your schedule.

 Proposed times in UTC are being voted on here:
 https://www.google.com/moderator/#16/e=21b93c

 Please vote on the time that is best for you. I would like to finalize
 the new times this week.

 Thanks!
 Kurt Taylor (krtaylor)



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

[Erlon Cruz]

I agree that 2 meetings per week will mess things up. 1+ for alternating
meetings.

On Fri, Dec 5, 2014 at 1:08 PM, Kurt Taylor kurt.r.tay...@gmail.com wrote:

 In my opinion, further discussion is needed. The proposal on the table is
 to have 2 weekly meetings, one at the existing time of 1800UTC on Monday
 and, also in the same week, to have another meeting at 0800 UTC on Tuesday.

 Here are some of the problems that I see with this approach:

 1. Meeting content: Having 2 meetings per week is more than is needed at
 this stage of the working group. There just isn't enough meeting content to
 justify having two meetings every week.

 2. Decisions: Any decision made at one meeting will potentially be undone
 at the next, or at least not fully explained. It will be difficult to keep
 consistent direction with the overall work group.

 3. Meeting chair(s): Currently we do not have a commitment for a long-term
 chair of this new second weekly meeting. I will not be able to attend this
 new meeting at the proposed time.

 4. Current meeting time: I am not aware of anyone that likes the current
 time of 1800 UTC on Monday. The current time is the main reason it is hard
 for EU and APAC CI Operators to attend.

 My proposal was to have only 1 meeting per week at alternating times, just
 as other work groups have done to solve this problem. (See examples at:
 https://wiki.openstack.org/wiki/Meetings)  I volunteered to chair, then
 ask other CI Operators to chair as the meetings evolved. The meeting times
 could be any between 1300-0300 UTC. That way, one week we are good for US
 and Europe, the next week for APAC.

 Kurt Taylor (krtaylor)


 On Wed, Dec 3, 2014 at 11:10 PM, trinath.soman...@freescale.com 
 trinath.soman...@freescale.com wrote:

 +1.

 --
 Trinath Somanchi - B39208
 trinath.soman...@freescale.com | extn: 4048

 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Thursday, December 04, 2014 3:55 AM
 To: openstack-in...@lists.openstack.org
 Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
 Additional Meeting for third-party

 On 12/03/2014 03:15 AM, Omri Marcovitch wrote:
  Hello Anteaya,
 
  A meeting between 8:00 - 16:00 UTC time will be great (Israel).
 
 
  Thanks
  Omri
 
  -Original Message-
  From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com]
  Sent: Wednesday, December 03, 2014 9:04 AM
  To: He, Yongli; OpenStack Development Mailing List (not for usage
  questions); openstack-in...@lists.openstack.org
  Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for
  Additional Meeting for third-party
 
  Hey,
 
  0700 - 1000 UTC would work for me most weeks fwiw.
 
  Cheers,
  Josh
 
  Rackspace Australia
 
  On 12/3/14 11:17 AM, He, Yongli wrote:
  anteaya,
 
  UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for
 china.
 
  if there is no time slot there, just pick up any time between UTC
  7:00 AM to UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and
  dinner.)
 
  Yongi He
  -Original Message-
  From: Anita Kuno [mailto:ante...@anteaya.info]
  Sent: Tuesday, December 02, 2014 4:07 AM
  To: openstack Development Mailing List;
  openstack-in...@lists.openstack.org
  Subject: [openstack-dev] [third-party]Time for Additional Meeting for
  third-party
 
  One of the actions from the Kilo Third-Party CI summit session was to
 start up an additional meeting for CI operators to participate from
 non-North American time zones.
 
  Please reply to this email with times/days that would work for you.
 The current third party meeting is on Mondays at 1800 utc which works well
 since Infra meetings are on Tuesdays. If we could find a time that works
 for Europe and APAC that is also on Monday that would be ideal.
 
  Josh Hesketh has said he will try to be available for these meetings,
 he is in Australia.
 
  Let's get a sense of what days and timeframes work for those
 interested and then we can narrow it down and pick a channel.
 
  Thanks everyone,
  Anita.
 

 Okay first of all thanks to everyone who replied.

 Again, to clarify, the purpose of this thread has been to find a suitable
 additional third-party meeting time geared towards folks in EU and APAC. We
 live on a sphere, there is no time that will suit everyone.

 It looks like we are converging on 0800 UTC as a time and I am going to
 suggest Tuesdays. We have very little competition for space at that date
 + time combination so we can use #openstack-meeting (I have already
 booked the space on the wikipage).

 So barring further discussion, see you then!

 Thanks everyone,
 Anita.

 ___
 OpenStack-Infra mailing list
 openstack-in...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

 ___
 OpenStack-Infra mailing list
 openstack-in...@lists.openstack.org
 

Re: [openstack-dev] [OpenStack-Infra] [third-party] [infra] New mailing lists for third party announcements and account requests

[Erlon Cruz]

On Fri, Aug 29, 2014 at 5:03 PM, Stefano Maffulli stef...@openstack.org
wrote:

 On Fri 29 Aug 2014 12:47:00 PM PDT, Elizabeth K. Joseph wrote:
  Third-party-request
 
  This list is the new place to request the creation or modification of
  your third party account. Note that old requests sent to the
  openstack-infra mailing list don't need to be resubmitted, they are
  already in the queue for creation.

 I'm not happy about this decision: creating new lists is expensive, it
 multiplies entry points for newcomers, which need to be explained *and*
 understood. We've multiplying processes, rules, points of contact and
 places to monitor, be aware of... I feel overwhelmed. I wonder how much
 worse that feeling is for people who are not 150% of their time
 following discussions online and offline on all OpenStack channels.


I feel the same. As a new comer to openstack community, I can say that
digging all projects Wikis searching for information is very cumbersome. In
fact It took some months to get subscribed in all channels that where
relevant to me. But, who knows if I'm missing some at this very moment.


 Are you sure that a mailing list is the most appropriate way of handling
 requests? Aren't bug trackers more appropriate instead?  And don't we
 have a bug tracker already?

  It would also be helpful for third party operators to join this
  mailing list as well as the -announce list in order to reply when they
  can to distribute workload and support new participants to thethird
  party community.

 What makes you think they will join a list called 'request'? It's a
 request: I file a request, get back what I asked for, I say goodbye.
 Doesn't sound like a place for discussions.

 Also, if the problem with third-party operators is that they don't stick
 around, how did you come to the conclusion that two more mailing lists
 would solve (or help solving) the problem?


 --
 Ask and answer questions on https://ask.openstack.org
 http://t.signauxdix.com/link?url=https%3A%2F%2Fask.openstack.org%2Fukey=agxzfnNpZ25hbHNjcnhyGAsSC1VzZXJQcm9maWxlGICAwLnctacJDAk=0d79c018-bbe4-4a87-91d0-012813563ea8

 ___
 OpenStack-Infra mailing list
 openstack-in...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
 http://t.signauxdix.com/link?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-infraukey=agxzfnNpZ25hbHNjcnhyGAsSC1VzZXJQcm9maWxlGICAwLnctacJDAk=4ec3e9a2-0a9c-45ae-8427-0a563b1988f1

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects

[Erlon Cruz]

 Leave the option about when to submit a design vs. when to submit code to
the
 contributor.

That's is what is being done so far right? Hard to know (mainly if you are
a first contributor) when a change is big or not. I can see lots
of patches   being submitted without the spec getting rejected and being
asked to a SPEC. This line between large-needs-spec/small-dont-need can not
be subjective.

Why launchpad doesn't have a better discussion capability? I mean, users
should be able to post comments on the whiteboard of the vluprint/bug. Then
a quick discussion there could be used to define if a SPEC would be needed.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev][Cinder] Review days? (open to ANYBODY and EVERYBODY)

[Erlon Cruz]

Great John,

I'll push fellows here to help. Couldn't  join today but I'll put in my
schedule for the next weeks. Do you plan to do this review force every
Wednesday?

Erlon


On Mon, Jun 16, 2014 at 9:31 AM, Kerr, Andrew andrew.k...@netapp.com
wrote:

 +1

 Andrew Kerr


 On 6/13/14, 10:30 AM, Duncan Thomas duncan.tho...@gmail.com wrote:

 Same as Jay, for much the same reasons. Having a fixed calendar time
 makes it easy for me to put up a 'do not disturb' sign.
 
 On 13 June 2014 05:10, Jay Bryant jsbry...@electronicjungle.net wrote:
  John,
 
  +2
 
  I am guilty of falling behind on reviews. Pulled in to a lot of other
 stuff
  since the summit ... and before.
 
  Having prescribed time on my calendar is a good idea.  Just put it on my
  calendar.
 
  Jay
 
  On Jun 12, 2014 10:49 PM, John Griffith john.griff...@solidfire.com
  wrote:
 
  Hey Everyone,
 
  So I've been noticing some issues with regards to reviews in Cinder
  lately, namely we're not keeping up very well.  Most of this is a math
  problem (submitters  reviewers).  We're up around 200+ patches in the
  queue, and a large number of them have no negative feedback but have
 just
  been waiting patiently (some  2 months).
 
  Growth is good, new contributors are FANTASTIC... but stale
 submissions in
  the queue are BAD, and I hate for people interested in contributing to
  become discouraged and just go away (almost as much as I hate emails
 asking
  me to review patches).
 
  I'd like to propose we consider one or two review days a week for a
 while
  to try and work on our backlog.  I'd like to propose that on these
 days we
  make an attempt to NOT propose new code (or at least limit it to
 bug-fixes
  [real bugs, not features disguised as bugs]) and have an agreement from
  folks to focus on actually doing reviews and using IRC to collaborate
  together and knock some of these out.
 
  We did this sort of thing over a virtual meetup and it was really
  effective, I'd like to see if we can't do something for a brief
 duration
  over IRC.
 
  I'm thinking we give it a test run, set aside a few hours next Wed
 morning
  to start (coinciding with our Cinder weekly meeting since many folks
 around
  that morning across TZ's etc) where we all dedicate some time prior to
 the
  meeting to focus exclusively on helping each other get some reviews
 knocked
  out.  As a reminder Cinder weekly meeting is 16:00 UTC.
 
  Let me know what you all think, and keep in mind this is NOT limited to
  just current regular Block-Heads but anybody in the OpenStack
 community
  that's willing to help out and of course new reviewers are MORE than
  welcome.
 
  Thanks,
  John
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Duncan Thomas
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Third-Party CI Issue: direct access to review.openstack.org port 29418 required

[Erlon Cruz]

Hi Asselin,

Do you had problems with other ports? Is it need to have outbound access to
other ports?

Erlon



On Mon, Jun 9, 2014 at 2:21 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  All,



 I’ve been working on setting up our Cinder 3rd party CI setup.

 I ran into an issue where Zuul requires direct access to
 review.openstack.org port 29418, which is currently blocked in my
 environment. It should be unblocked around the end of June.



 Since this will likely affect other vendors, I encourage you to take a few
 minutes and check if this affects you in order to allow sufficient time
 to resolve.



 Please follow the instructions in section “Reading the Event Stream” here:
 [1]

 Make sure you can get the event stream ~without~ any tunnels or proxies,
 etc. such as corkscrew [2].

 (Double-check that any such configurations are commented out in:
 ~/.ssh/config and /etc/ssh/ssh_config)



 Ramy (irc: asselin)



 [1] http://ci.openstack.org/third_party.html

 [2] http://en.wikipedia.org/wiki/Corkscrew_(program)









 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Third-Party CI Issue: direct access to review.openstack.org port 29418 required

[Erlon Cruz]

Ok thanks.


On Fri, Jun 13, 2014 at 11:32 AM, Asselin, Ramy ramy.asse...@hp.com wrote:

  As far as I know, that’s the only non-standard port that needs to be
 opened in order to do 3rd party ci.

 Ramy



 *From:* Erlon Cruz [mailto:sombra...@gmail.com]
 *Sent:* Friday, June 13, 2014 4:03 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Cinder] Third-Party CI Issue: direct
 access to review.openstack.org port 29418 required



 Hi Asselin,



 Do you had problems with other ports? Is it need to have outbound access
 to other ports?



 Erlon





 On Mon, Jun 9, 2014 at 2:21 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

 All,



 I’ve been working on setting up our Cinder 3rd party CI setup.

 I ran into an issue where Zuul requires direct access to
 review.openstack.org port 29418, which is currently blocked in my
 environment. It should be unblocked around the end of June.



 Since this will likely affect other vendors, I encourage you to take a few
 minutes and check if this affects you in order to allow sufficient time
 to resolve.



 Please follow the instructions in section “Reading the Event Stream” here:
 [1]

 Make sure you can get the event stream ~without~ any tunnels or proxies,
 etc. such as corkscrew [2].

 (Double-check that any such configurations are commented out in:
 ~/.ssh/config and /etc/ssh/ssh_config)



 Ramy (irc: asselin)



 [1] http://ci.openstack.org/third_party.html

 [2] http://en.wikipedia.org/wiki/Corkscrew_(program)










 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Unit-test] Cinder Driver

[Erlon Cruz]

Hi Yogesh,

The best way to start writing tests is to get some examples from tests
already implemented. Since icehouse release, all tests must be written with
mock¹. Most of the tests on the codebase are written with the old framework
(mox), please have a look on this implementations:

cinder/tests/{test_hp3par.py,test_ibmnas.py, test_netapp_eseries_iscsi.py}

This² is also an implementation Im working in using mock.

Kind Regards,
Erlon



¹ https://github.com/openstack/cinder/blob/master/HACKING.rst
² https://review.openstack.org/#/c/84244/


On Fri, May 30, 2014 at 6:05 AM, Yogesh Prasad yogesh.pra...@cloudbyte.com
wrote:


 Hi All,
 I have developed a cinder driver. Can you please share the steps to create
 an unit test environment and how to run unit test?

 *Thanks  Regards*,
   Yogesh Prasad.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev