[openstack-dev] [cinder] Leaving the Cinder core team

2017-12-20 Thread Patrick East 
Hi Everyone,

Wanted to let the group know that I'll be stepping away from my position on
the Cinder Core team.

I've got mixed feelings about it, but with my current responsibilities and
priorities my focus will be elsewhere. I will be unable to dedicate the
level of time and energy to Cinder reviews and core feature/bug
contributions that I've had the privilege of in the past.

My involvement with Cinder won't change much from the last release or so,
just setting expectations that I don't plan to increase my commitment
upstream. I will still be on IRC and involved in bugs/reviews/etc where I
can, primarily in areas I am very familiar with (os-brick, replication,
volume drivers, etc). Feel free to ping me or cc me on reviews/bugs.

Thanks,

Patrick East
patrick.e...@purestorage.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

Re: [openstack-dev] [Cinder] Proposing TommyLikeHu for Cinder core

2017-07-26 Thread Patrick East 
+1

-Patrick

On Tue, Jul 25, 2017 at 1:07 AM, Sean McGinnis 
wrote:

> I am proposing we add TommyLike as a Cinder core.
>
> DISCLAIMER: We work for the same company.
>
> I have held back on proposing him for some time because of this conflict.
> But
> I think from his number of reviews [1] and code contributions [2] it's
> hopefully clear that my motivation does not have anything to do with this.
>
> TommyLike has consistently done quality code reviews. He has contributed a
> lot of bug fixes and features. And he has been available in the IRC channel
> answering questions and helping out, despite some serious timezone
> challenges.
>
> I think it would be great to add someone from this region so we can get
> more
> perspective from the APAC area, as well as having someone around that may
> help as more developers get involved in non-US and non-EU timezones.
>
> Cinder cores, please respond with your opinion. If no reason is given to do
> otherwise, I will add TommyLike to the core group in one week.
>
> And absolutely call me out if you see any in bias in my proposal.
>
> Thanks,
> Sean
>
> [1] http://stackalytics.com/report/contribution/cinder-group/90
> [2] https://review.openstack.org/#/q/owner:%22TommyLike+%
> 253Ctommylikehu%2540gmail.com%253E%22++status:merged
>
> __
> 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] Target classes in Cinder

2017-06-02 Thread Patrick East 
On Fri, Jun 2, 2017 at 12:47 PM, John Griffith 
wrote:

> Hey Everyone,
>
> So quite a while back we introduced a new model for dealing with target
> management in the drivers (ie initialize_connection, ensure_export etc).
>
> Just to summarize a bit:  The original model was that all of the target
> related stuff lived in a base class of the base drivers.  Folks would
> inherit from said base class and off they'd go.  This wasn't very flexible,
> and it's why we ended up with things like two drivers per backend in the
> case of FibreChannel support.  So instead of just say having "driver-foo",
> we ended up with "driver-foo-iscsi" and "driver-foo-fc", each with their
> own CI, configs etc.  Kind of annoying.
>
> So we introduced this new model for targets, independent connectors or
> fabrics so to speak that live in `cinder/volume/targets`.  The idea being
> that drivers were no longer locked in to inheriting from a base class to
> get the transport layer they wanted, but instead, the targets class was
> decoupled, and your driver could just instantiate whichever type they
> needed and use it.  This was great in theory for folks like me that if I
> ever did FC, rather than create a second driver (the pattern of 3 classes:
> common, iscsi and FC), it would just be a config option for my driver, and
> I'd use the one you selected in config (or both).
>
> Anyway, I won't go too far into the details around the concept (unless
> somebody wants to hear more), but the reality is it's been a couple years
> now and currently it looks like there are a total of 4 out of the 80+
> drivers in Cinder using this design, blockdevice, solidfire, lvm and drbd
> (and I implemented 3 of them I think... so that's not good).
>
> What I'm wondering is, even though I certainly think this is a FAR
> SUPERIOR design to what we had, I don't like having both code-paths and
> designs in the code base.  Should we consider reverting the drivers that
> are using the new model back and remove cinder/volume/targets?  Or should
> we start flagging those new drivers that don't use the new model during
> review?  Also, what about the legacy/burden of all the other drivers that
> are already in place?
>

My guess is that trying to push all the drivers into the model would almost
definitely ensure that both code paths are alive and require maintenance
for years to come. Trying to get everyone moved over would be a pretty
large effort and (unless we get real harsh about it) would take a looong
time to get everyone on board. After the transition we would probably end
up with shims all over support the older driver class naming too. Either
that or we would end up with the same top level driver classes we have now,
and maybe internally they use a target instance but not in the configurable
pick and choose way that the model was intended for, and the whole exercise
wouldn't really do much other than have more drivers implement targets and
cause some code churn.

IMO the target stuff is a nice architecture for drivers to follow, but I
don't think its really something we need to do. I could see this being much
more important to push on if we had plans to split up the driver apis into
a provisioner and target kinda thing that the volume manager knows about,
but as long as they all are sent through a single driver class api then
it's all just implementation details behind that.


>
> Like I said, I'm biased and I think the new approach is much better in a
> number of ways, but that's a different debate.  I'd be curious to see what
> others think and what might be the best way to move forward.
>
> Thanks,
> John
>
> __
> 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] locking concern with os-brick

2016-08-14 Thread Patrick East 
In-case folks are not following comments on all the various forums for this
discussion. We've got changes up to address the concerns raised so far on
the immediate problem:

Devstack (changing default config option to be shared):
https://review.openstack.org/341744
Cinder (release note):  https://review.openstack.org/354501
Nova (release note):  https://review.openstack.org/354502
oslo.concurrency (updated config description):
https://review.openstack.org/355269

For addressing concerns like

I have enough experience to know that the notes will not be read.


Any suggestions on where we should document it? I am also not entirely
convinced a release note is the best, especially since it isn't really new
for this release, and may be a thing for future ones too. Theoretically
this has been a problem since Cinder and Nova split off way back when, any
of the volume attach/detach operations have been at risk for this when run
on the same host. With os-brick in liberty and its named locks we got a
mechanism to prevent it, but this wasn't really documented anywhere (or
known to be an issue, as it turns out). I'm not sure what the normal
strategy is to give a heads up to folks using older releases that there
might be issues like this. Suggestions welcome.

Clint Byrum wrote:
>
>> Excerpts from Joshua Harlow's message of 2016-08-13 20:04:13 -0700:
>>
>>> The larger issue here IMHO is that there is now a  API
>>> around locking that might be better suited targeting an actual lock
>>> management system (say redis or zookeeper or etcd or ...).
>>>
>>
>> The more I look at this, the more I think this is just evidence that
>> the compute node itself needs to be an API unto itself. Whether it's
>> Neutron agents, cinder volumes, or what, nova-compute has a bunch of
>> under-the-covers interactions with things like this. It would make more
>> sense to put that into its own implementation behind a real public API
>> than what we have now: processes that just magically expect to be run
>> together with shared filesystems, lock dirs, network interfaces, etc.
>>
>> That would also go a long way to being able to treat the other components
>> more like microservices.
>>
>>
> I very much agree, the amount of interactions 'under-the-covers' makes it
> really hard to do many things (including understanding what those
> interactions even are). For example, how does someone even install
> 'os-brick' at this point, if it requires as a prerequisite that cinder and
> nova-compute be pre-setup with the ? Sucks I guess for
> people/operators/anyone using both components, that are already running
> those with different lock directories...
>
> IMHO the amount of time done 'hacking in solutions' like a shared lock
> directory (or moving both projects to share the same configuration somehow)
> would be better spent on an actual locking solution/service and thinking
> about microservices and ... but meh, what can u do...


I like the sound of a more unified way to interact with compute node
services. Having a standardized approach for inter-service synchronization
for controlling system resources would be sweet (even if it is just a more
sane way of using local file locks). Anyone know if there is existing work
in this area we can build off of? Or is the path forward a new
cross-project spec to try and lock down some requirements, use-cases, etc.?

As far as spending time to hack together solutions via the config settings
for this.. we'll its pretty minimal wrt size of effort compared to solving
the large issue. Don't get me wrong though, I'm a fan of doing both in
parallel. Even if we have resources jump on board immediately I'm not
convinced we have a great chance to "fix" this for N in a more elegant
fashion, much less any of the older releases affected by this. That leads
me to believe we still need the shared config setting for at least a little
while in Devstack, and documentation for existing deployments or ones going
up with N.

-Patrick
__
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

2016-06-27 Thread Patrick East 
+2, Definitely well deserved!

-Patrick
__
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 Michał Dulko to Cinder Core

2016-05-03 Thread Patrick East 
+1, Michal has done some awesome work on Cinder!

-Patrick

On Tue, May 3, 2016 at 11:16 AM, Sean McGinnis 
wrote:

> Hey everyone,
>
> I would like to nominate Michał Dulko to the Cinder core team. Michał's
> contributions with both code reviews [0] and code contributions [1] have
> been significant for some time now.
>
> His persistence with versioned objects has been instrumental in getting
> support in the Mitaka release for rolling upgrades.
>
> If there are no objections from current cores by next week, I will add
> Michał to the core group.
>
> [0] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt
> [1]
>
> https://review.openstack.org/#/q/owner:%22Michal+Dulko+%253Cmichal.dulko%2540intel.com%253E%22++status:merged
>
> Thanks!
>
> Sean McGinnis (smcginnis)
>
>
> __
> 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 Non-Candidacy

2015-09-14 Thread Patrick East 
Mike, you've been an awesome help for me getting started in Cinder. Thanks
for all your hard work as PTL!

-Patrick

On Mon, Sep 14, 2015 at 10:19 AM, Walter A. Boring IV 
wrote:

> Thanks for your leadership and service Mike.   You've done a great job!
>
> Walt
>
>> Hello all,
>>
>> I will not be running for Cinder PTL this next cycle. Each cycle I ran
>> was for a reason [1][2], and the Cinder team should feel proud of our
>> accomplishments:
>>
>> * Spearheading the Oslo work to allow *all* OpenStack projects to have
>> their database being independent of services during upgrades.
>> * Providing quality to OpenStack operators and distributors with over
>> 60 accepted block storage vendor drivers with reviews and enforced CI
>> [3].
>> * Helping other projects with third party CI for their needs.
>> * Being a welcoming group to new contributors. As a result we grew
>> greatly [4]!
>> * Providing documentation for our work! We did it for Kilo [5], and I
>> was very proud to see the team has already started doing this on their
>> own to prepare for Liberty.
>>
>> I would like to thank this community for making me feel accepted in
>> 2010. I would like to thank John Griffith for starting the Cinder
>> project, and empowering me to lead the project through these couple of
>> cycles.
>>
>> With the community's continued support I do plan on continuing my
>> efforts, but focusing cross project instead of just Cinder. The
>> accomplishments above are just some of the things I would like to help
>> others with to make OpenStack as a whole better.
>>
>>
>> [1] -
>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046788.html
>> [2] -
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060530.html
>> [3] -
>> http://superuser.openstack.org/articles/what-you-need-to-know-about-openstack-cinder
>> [4] - http://thing.ee/cinder/active_contribs.png
>> [5] -
>> https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Key_New_Features_7
>>
>> --
>> 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][Glance] Fixing up Cinder store in Glance

2015-07-27 Thread Patrick East 
(and probably end up with caches again). IMO it works much nicer. No need
to overload the details into existing Glance fields, add some new apis, or
expose implementation details to users through metadata. We keep it all
inside Cinder and as far as a user is concerned you just get nice fast
response times when you create a volume from an image (in the right
conditions).

So, this is not an exhaustive list of what could possibly be done to solve
the problems or all of the stuff I've looked into. It is hopefully useful
for some to understand more about how the two features are working, and how
they can work together. To reiterate my stance on this, I don't see the
functionality entirely duplicated in either solution, and not a very good
way to get there. If we can achieve that I'm 100% on board with a unified
approach.

Maybe if we need more discussion we can talk about this at the mid-cycle
meeting next week.

-Patrick

On Mon, Jul 27, 2015 at 6:09 PM, Mike Perez thin...@gmail.com wrote:

 On 23:04 Jul 02, Tomoki Sekiyama wrote:
  Hi Cinder experts,
 
  Currently Glance has cinder backend but it is broken for a long time.
  I am proposing a glance-spec/patch to fix it by implementing the
  uploading/downloading images to/from cinder volumes.
 
  Glance-spec: https://review.openstack.org/#/c/183363/
  Glance_store patch: https://review.openstack.org/#/c/166414/
 
  This will be also useful for sharing volume data among tenants (similar
  use-case with public snapshots proposal discussed at the design summit).
 
 
  I need a review for them from cinder developers to make it progress.

 So I tested out this glance_store patch, along with the Cinder patch [1]
 and
 Glance patch [2] necessary to get things working.

 This made us notice that Glance v2 + Cinder does not work [3].

 Regardless, I had Patrick East who is working on the Image Caching [4]
 effort
 in Cinder to help copying images faster explain what the difference
 between the
 glance_store and his efforts were [5].

 It's not exactly clear from the operator's perspective what the use cases
 are
 for using one or the other. This worries me on duplicated effort, two
 supported
 efforts we have to support once people deploy these different options,
 confusion on which to use, etc.

 I think we should decide on one approach and just use that one. Thoughts?


 [1] - https://review.openstack.org/#/c/201754/10
 [2] - https://review.openstack.org/#/c/186201/11
 [3] - https://bugs.launchpad.net/cinder/+bug/1478737
 [4] -
 http://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html
 [5] -
 http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%23openstack-cinder.2015-07-28.log.html#t2015-07-28T00:45:14

 --
 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] Rebranded Volume Drivers

2015-06-03 Thread Patrick East 
I think having the rebranded drivers is fine (yay for effective code
re-use, right?), but they shouldn't have any special treatment. I don't
like the idea of having different categories of volume drivers where some
require CI and some don't.

As far as I know, in this specific case, they already have a CI system for
the 'base' driver, it should be trivial to add tests for the other drivers
too at this point.

-Patrick

On Wed, Jun 3, 2015 at 10:59 AM, John Griffith john.griffi...@gmail.com
wrote:



 On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez thin...@gmail.com wrote:

 There are a couple of cases [1][2] I'm seeing where new Cinder volume
 drivers for Liberty are rebranding other volume drivers. This involves
 inheriting off another volume driver's class(es) and providing some
 config options to set the backend name, etc.

 Two problems:

 1) There is a thought of no CI [3] is needed, since you're using
 another vendor's driver code which does have a CI.

 2) IMO another way of satisfying a check mark of being OpenStack
 supported and disappearing from the community.

 What gain does OpenStack get from these kind of drivers?

 Discuss.

 [1] - https://review.openstack.org/#/c/187853/
 [2] - https://review.openstack.org/#/c/187707/4
 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers

 --
 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


 ​This case is interesting​ mostly because it's the same contractor
 submitting the driver for all the related platforms.  Frankly I find the
 whole rebranding annoying, but there's certainly nothing really wrong with
 it, and well... why not, it's Open Source.

 What I do find annoying is the lack of give back; so this particular
 contributor has submitted a few drivers thus far (SCST, DotHill and some
 others IIRC), and now has three more proposed. This would be great except I
 personally have spent a very significant amount of time with this person
 helping with development, CI and understanding OpenStack and Cinder.

 To date, I don't see that he's provided a single code review (good or bad)
 or contributed anything back other than to his specific venture.

 Anyway... I think your point was for input on the two questions:

 For item '1':
 I guess as silly as it seems they should probably have 3'rd party CI.
 There are firmware differences etc that may actually change behaviors, or
 things my diverge, or maybe their code is screwed up and the inheritance
 doesn't work (doubtful).

 Yes, it's just a business venture in this case (good or bad, not for me to
 decide).  The fact is we don't discriminate or place a value on peoples
 contributions, and this shouldn't be any different.  I think the best
 answer is follow same process for any driver and move on.  This does
 point out that maybe OpenStack/Cinder has grown to a point where there are
 so many options and choices that it's time to think about changing some of
 the policies and ways we do things.

 In my opinion, OpenStack doesn't gain much in this particular case, which
 brings me back to;
 remove all drivers except the ref-impl and have them pip installable and
 on a certified list based on CI.

 Thanks,
 John


 __
 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] [Cinder] About how to hide the dummy destination record during migration

2015-05-28 Thread Patrick East 
Thanks for the info!

I think for the migration use case this would definitely solve the issue,
but for the image cache we would need more as we would be creating volume
objects and need to track them in the Cinder database. We could use a
system like that to essentially put a 'hidden' flag in the meta-data
entries of the cached images, but its not much better than just adding a
hidden flag in regards to having to filter them out from api calls and not
accounting for them in quota anywhere.

Alternatives for using a special tenant are definitely worth considering, I
admit its not really an ideal solution, but it happens to be fairly
appealing for the problem we are solving. I'll take a closer look at the
Manilla changes and adjust the spec's I have for cinder as needed.

-Patrick

On Wed, May 27, 2015 at 11:01 PM, Sheng Bo Hou sb...@cn.ibm.com wrote:

 Hi Valeriy,

 Thank you for telling me about the private driver storage feature from
 Manila. I have reviewed the patch and it can definitely resolve the dummy
 destination volume issue I have during migration in Cinder. I do not deny
 that it is a good approach.

 However, I need to put Patrick in the CC list to make him aware of this.
 During the previous Cinder IRC, we made an agreement that Cinder will go
 along this approach to consider all the common issues by introducing a
 cinder-internal tenant. Please check the cinder-spec:
 https://review.openstack.org/#/c/186232/. I guess cinder will go along
 this approach.

 @Patrick, I am not sure what our implementation is gonna be. Is it
 possible that similar data model can be used for cinder as it is in Manila?
 Please check *https://review.openstack.org/#/c/176877/*
 https://review.openstack.org/#/c/176877/

 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


  *Valeriy Ponomaryov vponomar...@mirantis.com
 vponomar...@mirantis.com*

 05/27/2015 02:12 PM
  Please respond to
 OpenStack Development Mailing List \(not for usage questions\) 
 openstack-dev@lists.openstack.org

   To
 OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 cc
 rodrigo.barbieri2...@gamil.com
 Subject
 Re: [openstack-dev] [Manila] About how to hide the dummy destination
 record during migration




 Hello Vincent Hou,

 We, Manila folks, are about to merge one of new features - private driver
 storage [1]. That is going to serve for not-user facing data storage
 related to any resource that can be reached by both - API and share driver.

 And in case of share migration, it will be possible to avoid creation of
 temporary share DB record and use this data storage for storing all
 required data per each share.

 Please, look at it, and provide feedback, whether such approach can be
 used in your case or not and why.

 [1] - *https://review.openstack.org/#/c/176877/*
 https://review.openstack.org/#/c/176877/

 Kind regards,

 Valeriy Ponomaryov

 On Wed, May 27, 2015 at 7:28 AM, Sheng Bo Hou *sb...@cn.ibm.com*
 sb...@cn.ibm.com wrote:
 Hi everyone working for Manila,

 This is Vincent Hou from IBM. I am working on all the migration issues in
 Cinder.

 I had one session for the Cinder migration issue in Vancouver and some of
 you folks attended it. The etherpad link is
 *https://etherpad.openstack.org/p/volume-migration-improvement*
 https://etherpad.openstack.org/p/volume-migration-improvement
 Per the issue that we had better not let the user see the target volume
 during migration when issuing command cinder list, we can add an
 additional flag into the volume table, for example, hidden, into it. The
 default value is 0, meaning that it will display for cinder list. For the
 target volume during migration. We can set it to 1, so the user will not be
 able to see it with the command cinder list. I think it is a
 straightforward approach we can go with. I just sync up with you folks, so
 that we can have a consistent way to resolve this issue in both Cinder and
 Manila. I just need to make sure we are on the same page. Is this solution
 OK with you folks? Especially @Rodrigo Barbieri and @Erlon Cruz, etc.

 Looking forward to hearing from you. Thanks.

 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*
 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

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-23 Thread Patrick East 
On Mon, Mar 23, 2015 at 12:59 PM, Stefano Maffulli stef...@openstack.org
wrote:

 On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:
  We've been talking about CI's for a year. We started talking about CI
 deadlines
  in August. If you post a driver for Kilo, it was communicated that you're
  required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
  should've been known by your engineers regardless of when you submitted
 your
  driver.

 Let's work to fix the CI bits for Liberty and beyond. I have the feeling
 that despite your best effort to communicate deadlines, some quite
 visible failure has happened.


I think the only failure is on the side of any driver maintainers who did
not make the deadlines. From my perspective (as one of the driver
maintainers who did setup a CI system and a developer working on Cinder)
this whole process has been a success. The test coverage has sky rocketed
for Cinder, driver maintainers are forced to be a bit more active in the
community, and the code base (in theory) no longer has volume drivers in
tree that we don't know if they actually work or not. This is, in my
opinion, a huge win for the project.


 You've been clear about Cinder's deadlines, I've been trying to add them
 also to the weekly newsletter, too.

 To the people whose drivers don't have their CI completed in time: what
 do you suggest should change so that you won't miss the deadlines in the
 future? How should the processes and tool be different so you'll be
 successful with your OpenStack-based products?


For anyone who struggled with getting a CI system operational there are
numerous resources at your disposal (all of which have been advertised in
Cinder meetings and the #openstack-cinder IRC channel). There are three
meetings every week where you can get help setting them up [1]. There are a
few different Cinder developers who have set up their own CI systems and
shared code/instructions [2][3]. I have seen those same devs supporting
them via IRC and have enabled several other companies to successfully use
their tools. Between these resources I don't think anyone who has actually
showed up at the meetings, asked for help, and make a good faith effort to
keep everyone in the loop and show progress failed to get their system
online and keep their driver in Cinder its not a coincidence.

There are also efforts to provide an easier to use CI system that is shared
with the OpenStack infra team [4]. I would recommend anyone who wants to
help ease this process for new drivers/maintainers to help contribute to
this effort. I think this is going to be the best route forward to ensure
people have the tools they need to setup and operate a stable third party
ci system.


1 -
https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
2 - https://github.com/rasselin/os-ext-testing
3 - https://github.com/j-griffith/sos-ci
4 - https://review.openstack.org/#/c/139745/


-Patrick
__
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] FFE driver-private-data + pure-iscsi-chap-support

2015-02-15 Thread Patrick East 
Hi All,

I would like to request a FFE for the following blueprints:

https://blueprints.launchpad.net/cinder/+spec/driver-private-data
https://blueprints.launchpad.net/cinder/+spec/pure-iscsi-chap-support

The first being a dependency for the second.

The new database table for driver data feature was discussed at the Cinder
mid-cycle meetup and seemed to be generally approved by the team in person
at the meeting as something we can get into Kilo.

There is currently a spec up for review for it here:
https://review.openstack.org/#/c/15/ but doesn't look like it will be
approved by the end of the day for the deadline. I have code pretty much
ready to go for review as soon as the spec is approved, it is a relatively
small patch set.

Thanks!

Patrick East
patrick.e...@purestorage.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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-09 Thread Patrick East 
Hi Eduard,

I am going through the same process of setting up a CI with the same
instructions/tools (migrating from one using jaypipes instructions w/
static slaves). What I learned the other day in IRC is that the gearman
plugin will only register the job if there are build slaves with labels
that can run the jobs. Make sure that your nodepool nodes are being created
and attached to jenkins correctly, if you only see instances with
template in the name my understanding is that those are used for snapshot
images and are not the actual build nodes.

On a related note, I am having issues with the ssh keys. Nodepool is able
to log in to the node to set up the template and create an image from it,
but then fails to log in to a build node. Have you run into any issues with
that?

-Patrick

On Fri, Jan 9, 2015 at 5:14 AM, Eduard Matei eduard.ma...@cloudfounders.com
 wrote:

 Hi all,
 Back with the same error.
 Did a complete (clean) install based on rasselin's tutorial, now i have a
 working jenkins master + a dedicated cloud provider.
 Testing with noop looks ok, but dsvm-tempest-full returns NOT_REGISTERED.

 Here is some debug.log:

 2015-01-09 14:08:06,772 DEBUG zuul.IndependentPipelineManager: Found job
 dsvm-tempest-full for change Change 0x7f8db86278d0 139585,15
 2015-01-09 14:08:06,773 INFO zuul.Gearman: Launch job dsvm-tempest-full
 for change Change 0x7f8db86278d0 139585,15 with dependent changes []
 2015-01-09 14:08:06,773 DEBUG zuul.Gearman: Custom parameter function used
 for job dsvm-tempest-full, change: Change 0x7f8db86278d0 139585,15,
 params: {'BASE_LOG_PATH': '85/139585/15/check', 'ZUUL_PIPELINE': 'check',
 'OFFLINE_NODE_WHEN_COMPLETE': '1', 'ZUUL_UUID':
 'fa4ca39e02b14d1d864725441e301eb0', 'LOG_PATH':
 '85/139585/15/check/dsvm-tempest-full/fa4ca39', 'ZUUL_CHANGE_IDS':
 u'139585,15', 'ZUUL_PATCHSET': '15', 'ZUUL_BRANCH': u'master', 'ZUUL_REF':
 u'refs/zuul/master/Z4efb72c817fb4ab39b67eb93fa8177ea', 'ZUUL_COMMIT':
 u'97c142345b12bdf6a48c89b00f0d4d7811ce4a55', 'ZUUL_URL': u'
 http://10.100.128.3/p/', 'ZUUL_CHANGE': '139585', 'ZUUL_CHANGES':
 u'openstack-dev/sandbox:master:refs/changes/85/139585/15', 'ZUUL_PROJECT':
 'openstack-dev/sandbox'}
 ...
 2015-01-09 14:08:06,837 DEBUG zuul.Gearman: Function
 build:dsvm-tempest-full is not registered
 2015-01-09 14:08:06,837 ERROR zuul.Gearman: Job gear.Job 0x7f8db16e5590
 handle: None name: build:dsvm-tempest-full unique:
 fa4ca39e02b14d1d864725441e301eb0 is not registered with Gearman
 2015-01-09 14:08:06,837 INFO zuul.Gearman: Build gear.Job 0x7f8db16e5590
 handle: None name: build:dsvm-tempest-full unique:
 fa4ca39e02b14d1d864725441e301eb0 complete, result NOT_REGISTERED
 2015-01-09 14:08:06,837 DEBUG zuul.Scheduler: Adding complete event for
 build: Build fa4ca39e02b14d1d864725441e301eb0 of dsvm-tempest-full on
 Worker Unknown
 2015-01-09 14:08:06,837 DEBUG zuul.Scheduler: Done adding complete event
 for build: Build fa4ca39e02b14d1d864725441e301eb0 of dsvm-tempest-full on
 Worker Unknown
 2015-01-09 14:08:06,837 DEBUG zuul.IndependentPipelineManager: Adding
 build Build fa4ca39e02b14d1d864725441e301eb0 of dsvm-tempest-full on
 Worker Unknown of job dsvm-tempest-full to item QueueItem
 0x7f8db17ba310 for Change 0x7f8db86278d0 139585,15 in check

 So it seems that Zuul sees the job, but Gearman returns is not
 registered.

 Any idea how to register it? I see it in Jenkins GUI.
 The only warning i see in Jenkins GUI is:
 There’s no slave/cloud that matches this assignment. Did you mean ‘master’
 instead of ‘devstack_slave’?

 On the cloud provider gui i see instances with names like (
 d-p-c-TIMESTAMP.template.openstack.org) spawning and running and some
 deleting.

 Thanks,

 Eduard


 On Tue, Jan 6, 2015 at 7:29 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  Gearman worker threads is what is needed to actually run the job. You
 need to type ‘status’ to get the results. It shouldn’t be empty since you
 stated the job actually ran (and failed tempest)

 Publishing the result is controlled here in the zuul layout.yaml file
 [1]. Make sure you’re not using the ‘silent’ pipeline which (obviously)
 won’t publish the result. Manual is here [2]

 You’ll need a log server to host the uploaded log files. You can set one
 up like –infra’s using this [3] or WIP [4]



 Ramy



 [1]
 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/zuul/layout.yaml#L22

 [2] http://ci.openstack.org/zuul/index.html

 [3]
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_log_server.sh

 [4] https://review.openstack.org/#/c/138913/



 *From:* Punith S [mailto:punit...@cloudbyte.com]
 *Sent:* Monday, January 05, 2015 10:22 PM
 *To:* Asselin, Ramy
 *Cc:* Eduard Matei; OpenStack Development Mailing List (not for usage
 questions)

 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 thanks ramy :)

 i have setup the CI , but our dsvm-tempest-full job is failing due to
 some failures on running tempest.
 but

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-09 Thread Patrick East 
Ah yea, sorry, should have specified; I am having it run
the prepare_node_devstack.sh from the infra repo. I see it adding the same
public key to the user specified in my nodepool.yaml. The strange part (and
I need to double check.. feel like it can't be right) is that on my master
node the nodepool users id_rsa changed at some point in the process.


-Patrick

On Fri, Jan 9, 2015 at 8:38 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-01-09 08:28:39 -0800 (-0800), Patrick East wrote:
 [...]
  On a related note, I am having issues with the ssh keys. Nodepool
  is able to log in to the node to set up the template and create an
  image from it, but then fails to log in to a build node. Have you
  run into any issues with that?

 Your image build needs to do _something_ to make SSH into the
 resulting nodes possible. We accomplish that by applying a puppet
 manifest which sets up an authorized_keys file for the account we
 want it to use, but there are countless ways you could go about it
 in your environment.
 --
 Jeremy Stanley

 ___
 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] [ThirdPartyCI] Need help setting up CI

2015-01-09 Thread Patrick East 
Thanks for the links!

After digging around in my configs I figured out the issue, I had a typo in
my JENKINS_SSH_PUBLIC_KEY_NO_WHITESPACE (copy pasta cut off a
character...). But I managed to put the right one in the key for nova to
use so it was able to log in to set up the instance, but didn't end up with
the right thing in the NODEPOOL_SSH_KEY variable.

-Patrick

On Fri, Jan 9, 2015 at 9:25 AM, Asselin, Ramy ramy.asse...@hp.com wrote:



 Regarding SSH Keys and logging into nodes, you need to set the
 NODEPOOL_SSH_KEY variable

 1.   I documented my notes here
 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/nodepool/nodepool.yaml.erb.sample#L48

 2.   This is also documented ‘officially’ here:
 https://github.com/openstack-infra/nodepool/blob/master/README.rst

 3.   Also, I had an issue getting puppet to do the right thing with
 keys, so it gets forced here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_master.sh#L197



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Friday, January 09, 2015 8:58 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Thanks Patrick,

 Indeed it seems the cloud provider was setting up vms on a bridge whose
 eth was DOWN so the vms could not connect to the outside world so the
 prepare script was failing.

 Looking into that.



 Thanks,



 Eduard



 On Fri, Jan 9, 2015 at 6:44 PM, Patrick East patrick.e...@purestorage.com
 wrote:

  Ah yea, sorry, should have specified; I am having it run
 the prepare_node_devstack.sh from the infra repo. I see it adding the same
 public key to the user specified in my nodepool.yaml. The strange part (and
 I need to double check.. feel like it can't be right) is that on my master
 node the nodepool users id_rsa changed at some point in the process.




   -Patrick



 On Fri, Jan 9, 2015 at 8:38 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-01-09 08:28:39 -0800 (-0800), Patrick East wrote:
 [...]
  On a related note, I am having issues with the ssh keys. Nodepool
  is able to log in to the node to set up the template and create an
  image from it, but then fails to log in to a build node. Have you
  run into any issues with that?

 Your image build needs to do _something_ to make SSH into the
 resulting nodes possible. We accomplish that by applying a puppet
 manifest which sets up an authorized_keys file for the account we
 want it to use, but there are countless ways you could go about it
 in your environment.
 --
 Jeremy Stanley


 ___
 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





 --

 *Eduard Biceri Matei, Senior Software Developer*

  www.cloudfounders.com

  | eduard.ma...@cloudfounders.com







  *CloudFounders, The Private Cloud Software Company*



  Disclaimer:

  This email and any files transmitted with it are confidential and intended 
 solely for the use of the individual or entity to whom they are addressed.
 If you are not the named addressee or an employee or agent responsible for 
 delivering this message to the named addressee, you are hereby notified that 
 you are not authorized to read, print, retain, copy or disseminate this 
 message or any part of it. If you have received this email in error we 
 request you to notify us by reply e-mail and to delete all electronic files 
 of the message. If you are not the intended recipient you are notified that 
 disclosing, copying, distributing or taking any action in reliance on the 
 contents of this information is strictly prohibited.
 E-mail transmission cannot be guaranteed to be secure or error free as 
 information could be intercepted, corrupted, lost, destroyed, arrive late or 
 incomplete, or contain viruses. The sender therefore does not accept 
 liability for any errors or omissions in the content of this message, and 
 shall have no liability for any loss or damage suffered by the user, which 
 arise as a result of e-mail transmission.


 ___
 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] [infra][devstack] CI failed The plugin token_endpoint could not be found

2014-11-17 Thread Patrick East 
I am also still seeing issues with 'ERROR: openstack The plugin
token_endpoint could not be found', we can work around it by adding in a
list of all the clients to DEVSTACK_PROJECT_FROM_GIT and things go back to
working, for example:

http://ec2-54-69-107-106.us-west-2.compute.amazonaws.com/purestorageci/71/131871/10/check/dsvm-tempest-volume-PureISCSIDriver/8e36386/devstacklog.txt

But without it, attempting to use the released versions from pip:

http://ec2-54-69-107-106.us-west-2.compute.amazonaws.com/purestorageci/95/114395/11/check/dsvm-tempest-volume-PureISCSIDriver/725f580/devstacklog.txt

The strange part is that on my development setup, which is watching
sandbox, I was able to pip uninstall the python-*client packages and it
went back to running with out any problems,  (
http://ec2-54-69-246-234.us-west-2.compute.amazonaws.com/purestorageci/MANUALLY_TRIGGERED_282/devstacklog.txt
) but my live setup did not after going through the same process.

For now things seem ok with getting the packages from git, but it does
concern me that our CI is not able to function the same way as the gate
jenkins. I would rather have our configuration match those as closely as
possible.

I'm happy to provide more details about the setup or the failures. Any
suggestions on how to go about troubleshooting this would be much
appreciated.


-Patrick

On Mon, Nov 17, 2014 at 3:11 AM, Sean Dague s...@dague.net wrote:

 There needs to be a lot more context than that provided. As seen here -
 https://review.openstack.org/#/c/134379/ this seems to be working fine
 upstream.

 -Sean

 On 11/16/2014 09:16 PM, Wan, Sam wrote:
  Hi Sean,
 
Seems once I unset '
 DEVSTACK_PROJECT_FROM_GIT=python-keystoneclient,python-openstackclient',
 devstack will fail with ' ERROR: openstack The plugin token_endpoint could
 not be found'.
How should I overcome this issue then?
 
  Thanks and regards
  Sam
 
  -Original Message-
  From: Sean Dague [mailto:s...@dague.net]
  Sent: Saturday, November 15, 2014 12:28 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [infra][devstack] CI failed The plugin
 token_endpoint could not be found
 
  On 11/14/2014 09:09 AM, Jeremy Stanley wrote:
  On 2014-11-14 00:34:14 -0500 (-0500), Wan, Sam wrote:
  Seems we need to use python-keystoneclient and python-openstackclient
  from git.openstack.org  because those on pip don’t work.
 
  That's a bug we're (collectively) trying to prevent in the future.
  Services, even under development, should not depend on features only
  available in unreleased versions of libraries.
 
  But in latest update of stack.sh, it’s to use pip by default
  [...]
 
  And this is intentional, implemented specifically so that we can keep
  it from happening again.
 
 
  Patrick actually got to the bottom of a bug we had in devstack around
 this, we merged the fixes this morning.
 
  As Jeremy said, installing from pypi released versions is intentional.
  If something wants to use features in a library, the library needs to
 cut a release.
 
-Sean
 
  --
  Sean Dague
  http://dague.net
 
  ___
  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
 


 --
 Sean Dague
 http://dague.net

 ___
 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] [infra][devstack] CI failed The plugin token_endpoint could not be found

2014-11-13 Thread Patrick East 
I'm running into this issue as well on my CI. Any ideas on how to fix this?

My CI is behaving similar to the official jenkins in regards to using pip
to install the clients, and pip freeze shows the same versions on each.

Comparing
http://logs.openstack.org/70/124370/7/check/check-tempest-dsvm-full/d6a53b7/logs/devstacklog.txt.gz#_2014-11-13_18_48_32_860
and the same spot in
http://ec2-54-69-246-234.us-west-2.compute.amazonaws.com/purestorageci/MANUALLY_TRIGGERED_272/devstacklog.txt
they both fail use_library_from_git check for keystoneclient and
openstackclient

Any suggestions would be much appreciated!

-Patrick


On Wed, Nov 12, 2014 at 10:22 PM, Itsuro ODA o...@valinux.co.jp wrote:

 Hi,

  I'm wondering why you are just hitting it now? Does your CI pull the
  latest python-keystoneclient and python-openstackclient from master?

 Yes before it began to fail, but now it is No because of this change:

 https://github.com/openstack-dev/devstack/commit/8f8e2d1fbfa4c51f6b68a6967e330cd478f979ee

 Now python-*client are installed by pip install instead of git clone.

 I think this change causes the problem. But I don't understand
 why there are success CIs and failed CIs (include mine) and how to fix
 the problem.

 Thanks.
 Itsuro Oda

 On Thu, 13 Nov 2014 00:36:41 -0500
 Steve Martinelli steve...@ca.ibm.com wrote:

  About a month ago, we made changes to python-openstackclient that seem
  related to the error message you posted. Change is
  https://review.openstack.org/#/c/127655/3/setup.cfg
  I'm wondering why you are just hitting it now? Does your CI pull the
  latest python-keystoneclient and python-openstackclient from master?
 
  Thanks,
 
  _
  Steve Martinelli
  OpenStack Development - Keystone Core Member
  Phone: (905) 413-2851
  E-Mail: steve...@ca.ibm.com
 
 
 
  From:   Itsuro ODA o...@valinux.co.jp
  To: openstack-dev@lists.openstack.org
  Date:   11/12/2014 11:27 PM
  Subject:[openstack-dev] [infra][devstack] CI failed The plugin
  token_endpoint could not be found
 
 
 
  Hi,
 
  My third party CI becomes failed from about 21:00 12th UTC
  in execution of devstack.
 
  The error occurs at openstack project create admin -f value -c id
  ---
  ERROR: openstack The plugin token_endpoint could not be found
  ---
 
  I found some CIs have same problem.
 
  Does anyone give me a hint to solve this problem ?
 
  Thanks.
  --
  Itsuro ODA o...@valinux.co.jp
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 

 --
 Itsuro ODA o...@valinux.co.jp


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




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

Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account

2014-10-06 Thread Patrick East 
Thanks for the feedback and awesome query!

To move things forward are there any other steps? Anyone else I should ping
to take a look at it?

-Patrick

On Thu, Oct 2, 2014 at 10:36 AM, Asselin, Ramy ramy.asse...@hp.com wrote:

 Looks good to me using this query: http://paste.openstack.org/show/117844/
 Generated via: https://review.openstack.org/#/c/125716/

 Ramy


 -Original Message-
 From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
 Sent: Thursday, October 02, 2014 10:10 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Infra][Cinder] Request for voting permission
 with Pure Storage CI account

 Looks good to me (cinder core)

 On 29 September 2014 19:59, Patrick East patrick.e...@purestorage.com
 wrote:
  Hi All,
 
  I am writing to request voting permissions as per the instructions for
  third party CI systems[1]. The account email is 
 cinder...@purestorage.com.
 
  The system has been operational and stable for a little while now
  building/commenting on openstack/cinder gerrit. You can view its
  comment history on reviews here:
  https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z
 
  Please take a look and let me know if there are any issues. I will be
  the primary point of contact, but the alias
  openstack-...@purestorage.com is the best way for a quick response
  from our team. For immediate issues I can be reached in IRC as
 patrickeast
 
  I look forward to your feedback!
 
  [1]
  http://ci.openstack.org/third_party.html#permissions-on-your-third-par
  ty-system
 
  -Patrick
 
  ___
  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




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

Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account

2014-10-06 Thread Patrick East 
Sounds good, will do.

Thanks!

-Patrick

On Mon, Oct 6, 2014 at 11:03 AM, Anita Kuno ante...@anteaya.info wrote:

 On 10/06/2014 01:58 PM, Patrick East wrote:
  Thanks for the feedback and awesome query!
 
  To move things forward are there any other steps? Anyone else I should
 ping
  to take a look at it?
 
  -Patrick
 I would suggest you attend the Cinder meeting on Wednesday, add an item
 to the agenda, if folks are in favour, have the Cinder ptl post to this
 thread after the meeting and tell infra/me the outcome. If Cinder tells
 infra to give you voting permissions, I can make the change.

 Thanks,
 Anita.
 
  On Thu, Oct 2, 2014 at 10:36 AM, Asselin, Ramy ramy.asse...@hp.com
 wrote:
 
  Looks good to me using this query:
 http://paste.openstack.org/show/117844/
  Generated via: https://review.openstack.org/#/c/125716/
 
  Ramy
 
 
  -Original Message-
  From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
  Sent: Thursday, October 02, 2014 10:10 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Infra][Cinder] Request for voting
 permission
  with Pure Storage CI account
 
  Looks good to me (cinder core)
 
  On 29 September 2014 19:59, Patrick East patrick.e...@purestorage.com
  wrote:
  Hi All,
 
  I am writing to request voting permissions as per the instructions for
  third party CI systems[1]. The account email is 
  cinder...@purestorage.com.
 
  The system has been operational and stable for a little while now
  building/commenting on openstack/cinder gerrit. You can view its
  comment history on reviews here:
  https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z
 
  Please take a look and let me know if there are any issues. I will be
  the primary point of contact, but the alias
  openstack-...@purestorage.com is the best way for a quick response
  from our team. For immediate issues I can be reached in IRC as
  patrickeast
 
  I look forward to your feedback!
 
  [1]
  http://ci.openstack.org/third_party.html#permissions-on-your-third-par
  ty-system
 
  -Patrick
 
  ___
  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
 


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




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

[openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account

2014-09-29 Thread Patrick East 
Hi All,

I am writing to request voting permissions as per the instructions for
third party CI systems[1]. The account email is cinder...@purestorage.com.


The system has been operational and stable for a little while now
building/commenting on openstack/cinder gerrit. You can view its comment
history on reviews here:
https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z

Please take a look and let me know if there are any issues. I will be the
primary point of contact, but the alias openstack-...@purestorage.com is
the best way for a quick response from our team. For immediate issues I can
be reached in IRC as patrickeast

I look forward to your feedback!

[1]
http://ci.openstack.org/third_party.html#permissions-on-your-third-party-system


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