Re: [openstack-dev] [all] The future of the integrated release

[Jay S. Bryant]

John,

I spent the drive to the Minneapolis Airport thinking about this chain
of e-mails.  Hope these thoughts help ...

On Thu, 2014-08-07 at 07:55 -0600, John Griffith wrote:
> 
> 
> 
> 
> On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle 
> wrote:
> 
> 
> 
> On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant
>  wrote:
> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the
> difference is
> slot selection would just be Nova drivers. I
> > think there is an assumption in the old system that
> everyone in Nova
> > core wants to prioritize the blueprints. I think
> there are a bunch of
> > folks in Nova core that are happy having signaling
> from Nova drivers on
> > high priority things to review. (I know I'm in that
> camp.)
> >
> > Lacking that we all have picking algorithms to hack
> away at the 500 open
> > reviews. Which basically means it's a giant random
> queue.
> >
> > Having a few blueprints that *everyone* is looking
> at also has the
> > advantage that the context for the bits in question
> will tend to be
> > loaded into multiple people's heads at the same
> time, so is something
> > that's discussable.
> >
> > Will it fix the issue, not sure, but it's an idea.
> 
> 
> OK, got it.  So, success critically depends on
> nova-core being willing
> to take review direction and priority setting from
> nova-drivers.  That
> sort of assumption is part of why I think agile
> processes typically
> don't work in open source.  We don't have the ability
> to direct people
> with consistent and reliable results.
> 
> I'm afraid if people doing the review are not directly
> involved in at
> least ACKing the selection and commiting to review
> something, putting
> stuff in slots seems futile.
> 
> 
> 
> My original thinking was I'd set aside a "meeting time" to
> review specs especially for doc issues and API designs. What I
> found quickly was that the 400+ queue in one project alone was
> not only daunting but felt like I wasn't going to make a dent
> as a single person, try as I may.
> 
> 
> I did my best but would appreciate any change in process to
> help with prioritization. I'm pretty sure it will help someone
> like me, looking at cross-project queues of specs, to know
> what to review first, second, third, and what to circle back
> on. 
>  
> --
> Russell Bryant
> 
> ___
> 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
> 
> ​Seems everybody that's been around a while has noticed "issues" this
> release and have talked about it, thanks Thierry for putting it
> together so well and kicking off the ML thread here.
> 
> 
> I'd agree with everything that you stated, I've also floated the idea
> this past week with a few members of the Core Cinder team to have an
> "every other" release for new drivers submissions in Cinder (I'm
> expecting this to be a HUGELY popular proposal [note sarcastic
> tone]).  
> 
> 
> There are three things that have just crushed productivity and
> motivation in Cinder this release (IMO):
> 1. Overwhelming number of drivers (tactical contributions)

I totally agree with this statement.  We have so many large patches to
review that it is daunting.  I wish I had a good solution for dealing
with this issue.  I don't think quick reviews and just trying to get
them through is the right answer.  Perhaps a coordinated effort for some
portion of our code sprint days to knock things down?  Split up the work
and then work together to push some through?


> 2. Overwhelming amount of churn, literally hundreds of little changes
> to modify docstrings, comments etc but no real improvements to code

I can understand the frustration here, but do we 

Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination

[Jay S. Bryant]

Great nomination Walt.  Thank you!

+1

Thank you Xing for your contributions!

Jay

On Thu, 2014-08-14 at 06:55 +, Boring, Walter wrote:
> Hey guys,
>I wanted to pose a nomination for Cinder core.
> 
> Xing Yang.
> She has been active in the cinder community for many releases and has worked 
> on several drivers as well as other features for cinder itself.   She has 
> been doing an awesome job doing reviews and helping folks out in the 
> #openstack-cinder irc channel for a long time.   I think she would be a good 
> addition to the core team.
> 
> 
> Walt
> ___
> 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][FFE] request for exceptions in xiv_ds8k driver

[Jay S. Bryant]

Alon,

Thanks, I have added your request to the etherpad
https://etherpad.openstack.org/p/juno-cinder-approved-ffes and it will
undergo review.

Thanks,
Jay


On Mon, 2014-09-08 at 21:55 +0300, Alon Marx wrote:
> Hi, 
> 
> Please consider the following code changes as Feature Freeze
> Exceptions. 
> The first code change is needed to support the latest XIV release
> (version 11.5.0) and is very important for us, and the second code
> change is simply support for backups. 
> 
> Add domain support for XIV with multitenancy 
> https://review.openstack.org/#/c/118290/ 
> 
> Add support for backups to xiv_ds8k driver 
> https://review.openstack.org/#/c/118298/ 
> 
> Both changes were uploaded, reviewed and all relevant changes made by
> Juno-3 date. 
> Both changes are very small and simple. 
> Both changes affect only the xiv_ds8k driver. 
> Because the changes are small and simple and have no general affect
> the risk is negligible. 
> 
> Thank you, 
> Alon Marx 
> 
> 
> mobile +972549170122, office +97236897824
> email alo...@il.ibm.com
> IBM XIV, Cloud Storage Solutions (previously HSG) 
> ___
> 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] [all] 2019 summit during May holidays?

[Jay S Bryant]

On 11/5/2018 1:06 PM, Julia Kreger wrote:

*removes all of the hats*

*removes years of dust from unrelated event planning hat, and puts it 
on for a moment*


In my experience, events of any nature where convention venue space is 
involved, are essentially set in stone before being publicly 
advertised as contracts are put in place for hotel room booking blocks 
as well as the convention venue space. These spaces are also typically 
in a relatively high demand limiting the access and available times to 
schedule. Often venues also give preference (and sometimes even better 
group discounts) to repeat events as they are typically a known entity 
and will have somewhat known needs so the venue and hotel(s) can staff 
appropriately.


tl;dr, I personally wouldn't expect any changes to be possible at this 
point.


*removes event planning hat of past life, puts personal scheduling hat on*

I imagine that as a community, it is near impossible to schedule 
something avoiding holidays for everyone in the community.


I personally have lost count of the number of holidays and special 
days that I've spent on business trips over the past four years. While 
I may be an out-lier in my feelings on this subject, I'm not upset, 
annoyed, or even bitter about lost times. This community is part of my 
family.



Agreed.

-Julia

On Mon, Nov 5, 2018 at 8:19 AM Dmitry Tantsur > wrote:


Hi all,

Not sure how official the information about the next summit is,
but it's on the
web site [1], so I guess worth asking..

Are we planning for the summit to overlap with the May holidays?
The 1st of May
is a holiday in big part of the world. We ask people to skip it in
addition to
3+ weekend days they'll have to spend working and traveling.

To make it worse, 1-3 May are holidays in Russia this time. To
make it even
worse than worse, the week of 29th is the Golden Week in Japan
[2]. Was it
considered? Is it possible to move the days to less conflicting
time (mid-May
maybe)?

Someone else had raised the fact that this also appears to overlap with 
Pycon and wondered if the date could be changed.  I told them the same 
thing.  Once these things are announced they are, more or less, an 
immovable object.


Dmitry

[1] https://www.openstack.org/summit/denver-2019/
[2] https://en.wikipedia.org/wiki/Golden_Week_(Japan)


__
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][manila] Cinder and Friends Dinner at Berlin Summit ...

[Jay S Bryant]

All,

I am working on scheduling a dinner for the Cinder team (and our 
extended family that work on and around Cinder) during the Summit in 
Berlin.  I have created an etherpad for people to RSVP for dinner [1].


It seemed like Tuesday night after the Marketplace Mixer was the best 
time for most people.


So, it will be a little later dinner ... 8 pm.  Here is the place:

Location: http://www.dicke-wirtin.de/
Address:  Carmerstraße 9, 10623 Berlin, Germany

It looks like the kind of place that will fit for our usual group.

If planning to attend please add your name to the etherpad and I will 
get a reservation in over the weekend.


Hope to see you all on Tuesday!

Jay

[1] https://etherpad.openstack.org/p/BER-cinder-outing-planning

__
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] No meeting this week ...

[Jay S Bryant]

Team,

Just a friendly reminder that we will not have our weekly meeting this 
week due to the OpenStack Summit.


Hope to see some of you here.  Otherwise, talk to you next week!

Thanks,

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

Re: [openstack-dev] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...

[Jay S Bryant]

Ivan,

Yeah, I saw that was the case but it seems like there is not a point in 
time where there isn't a conflict.  Need to get some food at some point 
so anyone who wants to join can, and then we can head to the party if 
people want.


Jay


On 11/10/2018 8:07 AM, Ivan Kolodyazhny wrote:

Thanks for organizing this, Jay,

Just in case if you missed it, Matrix Party hosted by Trilio + Red Hat 
will be on Tuesday too.



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Thu, Nov 8, 2018 at 12:43 AM Jay S Bryant <mailto:jungleb...@gmail.com>> wrote:


All,

I am working on scheduling a dinner for the Cinder team (and our
extended family that work on and around Cinder) during the Summit
in Berlin.  I have created an etherpad for people to RSVP for
dinner [1].

It seemed like Tuesday night after the Marketplace Mixer was the
best time for most people.

So, it will be a little later dinner ... 8 pm.  Here is the place:

Location: http://www.dicke-wirtin.de/
Address: Carmerstraße 9, 10623 Berlin, Germany

It looks like the kind of place that will fit for our usual group.

If planning to attend please add your name to the etherpad and I
will get a reservation in over the weekend.

Hope to see you all on Tuesday!

Jay

[1] https://etherpad.openstack.org/p/BER-cinder-outing-planning

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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][manila] PLEASE READ: Change of location for dinner ...

[Jay S Bryant]

Team,

The dinner has had to change locations.  Dicke Wirtin didn't get my 
online reservation and they are full.


NEW LOCATION: Joe's Restaurant and Wirsthaus -- Theodor-Heuss-Platz 10, 
14052 Berlin


The time is still 8 pm.

Please pass the word on!

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

Re: [openstack-dev] Tool for detecting commonly misspelled words

[Jay S Bryant]

Since I am one of those people that comments on spelling and grammar ... 
If you use emacs for your coding you can add the following to help catch 
spelling issues:  http://www.emacswiki.org/emacs/FlySpell

There is also git-commit-mode:  
http://www.emacswiki.org/emacs/GitCommitMode which ensures good commit 
message structure.  When combined with FlySpell many of the simple 
mistakes can be avoided.


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
  
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   David Kranz 
To: openstack-dev@lists.openstack.org, 
Date:   12/03/2013 01:50 PM
Subject:Re: [openstack-dev] Tool for detecting commonly misspelled 
words



On 12/03/2013 02:05 PM, John Griffith wrote:
> On Tue, Dec 3, 2013 at 11:54 AM, Nachi Ueno  wrote:
>> 2013/12/3 John Griffith :
>>> On Tue, Dec 3, 2013 at 11:38 AM, Russell Bryant  
wrote:
>>>> On 12/03/2013 09:22 AM, Joe Gordon wrote:
>>>>> HI all,
>>>>>
>>>>> Recently I have seen a few patches fixing a few typos.  I would like 
to
>>>>> point out a really nifty tool to detect commonly misspelled words. 
So
>>>>> next time you want to fix a typo, instead of just fixing a single 
one
>>>>> you can go ahead and fix a whole bunch.
>>>>>
>>>>> https://github.com/lyda/misspell-check
>>>>>
>>>>> To install it:
>>>>>$ pip install misspellings
>>>>>
>>>>> To use it in your favorite openstack repo:
>>>>>   $ git ls-files | grep -v locale | misspellings -f -
>>>>>
>>>>>
>>>>> Sample output:
>>>>>
>>>>> http://paste.openstack.org/show/54354
>>>> Are we going to start gating on spellcheck of code and commit 
messages?  :-)
>>> NO please (please please please).  We have enough "grammar reviewers"
>>> at this point already IMO and I honestly think I might puke if jenkins
>>> fails my patch because I didn't put a '.' at the end of my comment
>>> line in the code.  I'd much rather see us focus on things like... I
>>> dunno... maybe having the code actually work?
>> yeah, but may be non-voting reviews by this tool is helpful
> Fair enough... don't get me wrong I'm all for support of non-english
> contributors etc.  I just think that the emphasis on grammar and
> punctuation in reviews has gotten a bit out of hand as of late.  FWIW
> I've never -1'd a patch (and never would) because somebody used "its"
> rather than "it's" in a comment.  Or they didn't end a comment (NOT a
> docstring) with a period.  I think it's the wrong place to spend
> effort quite honestly.
>
> That being said, I realize people will continue to this sort of thing
> (it's very important to get your -1 counts in the review stats) and
> admittedly there is some value to spelling and grammar.  I just feel
> that there are *real* issues and bugs that people could spend this
> time that would actually have some significant and real benefit.
>
> I'm obviously in the minority on this topic so I should probably just
> yield at this point and get on board the grammar train.
>
>
I agree with you. But the last thread about this proved there is no 
consensus. The beauty of a tool like this, run by individuals before 
they submit, is that it will to some degree make this contentious issue 
moot. I always run a spell checker on my own documents and I'm sure it 
will give more confidence to non-native English speakers to run this on 
their patches. So next time I see a misspelling in a review, I will 
simply point the author at this tool to use in the future.

  -David

___
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] weekly meeting

[Jay S Bryant]

John,

I am flexible. 

I am fine with trying to move the time to 04:00 or 05:00 UTC or we can 
alternate.  The one concern with alternation is that it may lead to 
confusion and less attendance, but I am certainly open to trying it.


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
  
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   John Griffith 
To: OpenStack Development Mailing List 
, 
Date:   12/16/2013 09:09 PM
Subject:[openstack-dev] [cinder] weekly meeting



Hi All,

Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
some interest in either changing the weekly Cinder meeting time, or
proposing a second meeting to accomodate folks in other time-zones.

A large number of folks are already in time-zones that are not
"friendly" to our current meeting time.  I'm wondering if there is
enough of an interest to move the meeting time from 16:00 UTC on
Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
willing to look at either moving the meeting for a trial period or
holding a second meeting to make sure folks in other TZ's had a chance
to be heard.

Let me know your thoughts, if there are folks out there that feel
unable to attend due to TZ conflicts and we can see what we might be
able to do.

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

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

[Jay S Bryant]

There is already an option that can be set in cinder.conf using 
'volume_clear=none'

Is there a reason that that option is not sufficient?


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member

Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   "Fox, Kevin M" 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   01/15/2014 06:06 PM
Subject:Re: [openstack-dev] Proposal for dd disk i/o performance 
blueprint of cinder.



What about a configuration option on the volume for delete type? I can see 
some possible options:

* None - Don't clear on delete. Its junk data for testing and I don't want 
to wait.
* Zero - Return zero's from subsequent reads either by zeroing on delete, 
or by faking zero reads initially.
* Random - Write random to disk.
* Multipass - Clear out the space in the most secure mode configured. 
Multiple passes and such.

Kevin

From: CARVER, PAUL [pc2...@att.com]
Sent: Wednesday, January 15, 2014 2:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance 
blueprint of cinder.

Chris Friesen [mailto:chris.frie...@windriver.com] wrote:

>I read a proposal about using thinly-provisioned logical volumes as a
>way around the cost of wiping the disks, since they zero-fill on demand
>rather than incur the cost at deletion time.

I think it make a difference where the requirement for deletion is coming 
from.

If it's just to make sure that a tenant can't read another tenant's disk 
then what
you're talking about should work. It sounds similar (or perhaps identical 
to) how
NetApp (and I assume others) work by tracking whether the current client 
has
written to the volume and returning zeros rather than the actual contents 
of the
disk sector on a read that precedes the first write to that sector.

However, in that case the previous client's bits are still on the disk. If 
they were
unencrypted then they're still available if someone somehow got ahold of 
the
physical disk out of the storage array.

That may not be acceptable depending on the tenant's security 
requirements.

Though one may reasonably ask why they were writing unencrypted bits to
a disk that they didn't have physical control over.

___
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] Proposed Logging Standards

[Jay S Bryant]

Sean and John,

I would be happy to help out with this for Cinder.

Let me know how I can help.


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   John Griffith 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   01/27/2014 02:52 PM
Subject:Re: [openstack-dev] Proposed Logging Standards



On Mon, Jan 27, 2014 at 6:07 AM, Sean Dague  wrote:
> Back at the beginning of the cycle, I pushed for the idea of doing some
> log harmonization, so that the OpenStack logs, across services, made
> sense. I've pushed a proposed changes to Nova and Keystone over the past
> couple of days.
>
> This is going to be a long process, so right now I want to just focus on
> making INFO level sane, because as someone that spends a lot of time
> staring at logs in test failures, I can tell you it currently isn't.
>
> https://wiki.openstack.org/wiki/LoggingStandards is a few things I've
> written down so far, comments welcomed.
>
> We kind of need to solve this set of recommendations once and for all up
> front, because negotiating each change, with each project, isn't going
> to work (e.g - https://review.openstack.org/#/c/69218/)
>
> What I'd like to find out now:
>
> 1) who's interested in this topic?
> 2) who's interested in helping flesh out the guidelines for various log
> levels?
> 3) who's interested in helping get these kinds of patches into various
> projects in OpenStack?
> 4) which projects are interested in participating (i.e. interested in
> prioritizing landing these kinds of UX improvements)
>
> This is going to be progressive and iterative. And will require lots of
> folks involved.
>
> -Sean
>
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> http://dague.net
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Very interested in all of the above.

___
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 Stability Hack-a-thon

[Jay S Bryant]

Mike,

Great idea!

I can participate remotely.

Let me know how I can be of the best help!


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Mike Perez 
To: OpenStack Development Mailing List 
, 
Date:   02/01/2014 02:11 AM
Subject:[openstack-dev] Cinder Stability Hack-a-thon



Folks,

I would love to get people together who are interested in Cinder 
stability 
to really dedicate a few days. This is not for additional features, but 
rather 
finishing what we already have and really getting those in a good shape 
before the end of the release.

When: Feb 24-26
Where: San Francisco (DreamHost Office can host), Colorado, remote?

Some ideas that come to mind:

- Cleanup/complete volume retype
- Cleanup/complete volume migration [1][2]
- Other ideas that come from this thread.

I can't stress the dedicated part enough. I think if we have some folks 
from core and anyone interested in contributing and staying focus, we 
can really get a lot done in a few days with small set of doable stability 
goals 
to stay focused on. If there is enough interest, being together in the 
mentioned locations would be great, otherwise remote would be fine as 
long as people can stay focused and communicate through suggested 
ideas like team speak or google hangout.

What do you guys think? Location? Other stability concerns to add to the 
list?

[1] - https://bugs.launchpad.net/cinder/+bug/1255622
[2] - https://bugs.launchpad.net/cinder/+bug/1246200


-Mike Perez___
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] Grizzly volume quotas

[Jay S Bryant]

Pat,

I see the same behavior on an Icehouse level install.  So, I think you may 
have found a bug.

I would open the bug to python-novaclient to start with, but it may end up 
coming back to Cinder.


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Pat Bredenberg 
To: openstack-dev@lists.openstack.org, 
Date:   02/05/2014 03:05 PM
Subject:[openstack-dev] Grizzly volume quotas



Dear all,

 I'm part of the team bringing OpenStack to Solaris and am confused 
about how volume quotas appear according to nova(1).  We're using 
Grizzly 2013.1.4 for both Nova and Cinder; please let me know what other 
configuration information you need.  The raw data itself is available 
here: http://paste.openstack.org/show/62667/.
 Is it a bug that "volumes" appears as a configurable quota via 
nova(1), according to its help menu?  I'll apologize in advance if this 
has already been documented elsewhere and/or addressed in Havana or 
Icehouse.  I searched but didn't see it mentioned.  If it's a bug that 
has yet to be filed and should be addressed, please let me know and I'll 
gladly file the bug.  Otherwise, I'll chalk it up as a learning 
experience.  Your guidance is greatly appreciated.

Very respectfully,
Pat Bredenberg

___
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] Grizzly volume quotas

[Jay S Bryant]

Joe,

Ah!  So, those aren't for Cinder Volume but for nova-volume.  Ok, so there 
isn't really a bug then.

Sorry for speaking too quickly.  Thanks for the info!


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Joe Gordon 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   02/05/2014 04:03 PM
Subject:Re: [openstack-dev] Grizzly volume quotas



On Wed, Feb 5, 2014 at 1:21 PM, Jay S Bryant  wrote:
> Pat,
>
> I see the same behavior on an Icehouse level install.  So, I think you 
may
> have found a bug.

So the bug here isn't what you expect.

First a bit of background.

* python-novaclient isn't part of the integrated release and needs to
support most releases (not just the most recent).
* python-novaclient doesn't have any mechanism to detect what commands
a cloud supports and hide the other commands  [This is the bug].

So nova client needs to support nova-volume, which is why we still
have the volume quota options.

>
> I would open the bug to python-novaclient to start with, but it may end 
up
> coming back to Cinder.
>
>
> Jay S. Bryant
>IBM Cinder Subject Matter Expert  &  Cinder Core Member
> Department 7YLA, Building 015-2, Office E125, Rochester, MN
> Telephone: (507) 253-4270, FAX (507) 253-6410
> TIE Line: 553-4270
> E-Mail:  jsbry...@us.ibm.com
> 
> All the world's a stage and most of us are desperately unrehearsed.
>   -- Sean O'Casey
> 
>
>
>
> From:Pat Bredenberg 
> To:openstack-dev@lists.openstack.org,
> Date:02/05/2014 03:05 PM
> Subject:[openstack-dev] Grizzly volume quotas
> 
>
>
>
> Dear all,
>
> I'm part of the team bringing OpenStack to Solaris and am confused
> about how volume quotas appear according to nova(1).  We're using
> Grizzly 2013.1.4 for both Nova and Cinder; please let me know what other
> configuration information you need.  The raw data itself is available
> here: http://paste.openstack.org/show/62667/.
> Is it a bug that "volumes" appears as a configurable quota via
> nova(1), according to its help menu?  I'll apologize in advance if this
> has already been documented elsewhere and/or addressed in Havana or
> Icehouse.  I searched but didn't see it mentioned.  If it's a bug that
> has yet to be filed and should be addressed, please let me know and I'll
> gladly file the bug.  Otherwise, I'll chalk it up as a learning
> experience.  Your guidance is greatly appreciated.
>
> Very respectfully,
> Pat Bredenberg
>
> ___
> 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

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

[Jay S Bryant]

All,

Myself and Jim Carey have been working on getting the right solution for 
making lazy_translation work through Nova and Cinder. 

The patch should have also had changes to remove the use of str() in any 
LOG or exception messages as well as the removal of any places where 
strings were being '+' ed together.  In the case of Cinder we are doing it 
as two separate patches that are dependent.  I am surprised that this 
change got past Jenkins.  In the case of Cinder and Nova unit test caught 
a number of problems.

We will make sure to work with Liang Chen to avoid this happening again.

Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Ben Nemec 
To: openstack-dev@lists.openstack.org, 
Date:   02/18/2014 10:37 AM
Subject:Re: [openstack-dev] [Heat] lazy translation is breaking 
Heat



On 2014-02-18 09:15, Christopher Armstrong wrote:
This change was recently merged: 
 
https://review.openstack.org/#/c/69133/
 
Unfortunately it didn't enable lazy translations for the unit tests, so it 
didn't catch the many places in Heat that won't work when lazy 
translations are enabled. Notably there are a lot of cases where the code 
adds the result of a call to _() with another string, and Message objects 
(which are returned from _ when lazy translations are enabled) can't be 
added, resulting in an exception being raised.
 
I think the best course of action would be to revert this change, and then 
reintroduce it along with patches to fix all the problems, while enabling 
it for the unit tests so bugs won't be reintroduced in the future.
 
Agreed.  That behavior was intentional because we shouldn't be adding 
translated strings that way, but obviously it needs to be fixed before 
lazy translation is enabled. :-)
 
Interestingly it also didn't fail any of the tempest tests, I'm not sure 
why.
 
That is kind of concerning.  I see that the error does show up in the logs 
a couple of times though: 
http://logs.openstack.org/33/69133/5/gate/gate-tempest-dsvm-full/d6aa1bd/logs/screen-h-api.txt.gz#_2014-02-17_17_38_25_521
 
Maybe this is something that would need the new error message test enabled 
to be caught?
 
-- 
IRC: radix
Christopher Armstrong

___
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] [oslo] Some questions about Rest API and log messages translation

[Jay S Bryant]

Response marked with >> below.

Jay



From:   Doug Hellmann 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   02/19/2014 09:22 AM
Subject:Re: [openstack-dev] [oslo] Some questions about Rest API 
and log messages translation






On Tue, Feb 18, 2014 at 11:56 PM, Peng Wu  wrote:
Hi,

  Currently I am analyzing the blueprint of translated message id
generation.[1]
  Recently I just found that there is an implementation to generate both
English and translated log messages.
  I think if English and translated log messages are provided, then we
don't need to generate a message id for log messages.

  My question is about Rest API messages translation. If we will return
both English and translated Rest API message, then we don't need to
generate a message id for Rest API message, either.

I don't think we plan to return both messages. My understanding was we 
would return messages in the locale specified by the headers sent from the 
client (assuming those translations are available).
 >> You are correct Doug.  The REST API responses will be in the default 
locale unless a different 'Accept-Language: ' is set.  Then the translated 
response will be returned.

  And currently message id generation blueprint is only for log message
and translated Rest API message. If we provide both English and
translated messages, then we don't need to generate any message id for
messages. Because we just need to read the English log and Rest API
messages.

There may still be utility in documenting messages with a message id. For 
example, a message id wouldn't change even if the wording of a message 
changed slightly (to add more context information, for example).

Doug

 

  Feel free to comment it.

Thanks,
  Peng Wu

Refer URL:
[1] https://blueprints.launchpad.net/oslo/+spec/log-messages-id
[2]
https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain




___
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] [Nova]Do you think volume force delete operation should not apply to the volume being used?

[Jay S Bryant]

I would agree.  I don't think that Cinder should/could be able to act upon 
Nova's state for the VM.  Force-delete is really in place as a backup to 
clean-up after certain failures in Cinder.  Other mechanisms are in place 
to handle issues in Nova.


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   "zhangyu (AI)" 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Cc: "Luohao \(brian\)" 
Date:   02/25/2014 08:20 PM
Subject:Re: [openstack-dev] [Cinder] [Nova]Do you think volume 
force delete operation should not apply to the volume being used?



IMHO, Attach/detach operations can only be issued from the Nova side 
because they are in fact VM/instance management operations. 
Meanwhile, volume create/delete are volume management stuffs, therefore 
Cinder exposes API for them.
 
Also, according to current Cinder code base, no nova detach-volume action 
is issued from the execution flow of a volume deletion.
 
Thank you for suggestions~
 
From: Yuzhou (C) [mailto:vitas.yuz...@huawei.com] 
Sent: Wednesday, February 26, 2014 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Luohao (brian)
Subject: Re: [openstack-dev] [Cinder] [Nova]Do you think volume force 
delete operation should not apply to the volume being used?
 
I thinkforce delete = nova detach volume,then cinder delete volume 

 
Volume status in db shoud be modified after nova detach volume.
 
Thanks!
 
 
From: zhangyu (AI) [mailto:zhangy...@huawei.com] 
Sent: Wednesday, February 26, 2014 8:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] [Nova]Do you think volume force 
delete operation should not apply to the volume being used?
 
If I understand your question correctly, the case you describe should be 
like the following:
 
Assume we have created both an instance and a volume, then we try to 
attach that volume to the instance.
Before that operation is completed (the status of the volume is 
“attaching” now), for whatever reasons we decide to apply a “force delete” 
operation on that volume.
Then, after we applied that force delete, we come to see that, from the 
Cinder side, the volume has been successfully deleted and the status is 
surely “deleted”.
However, from the Nova side, we see that the status of the deleted volume 
remains to be “attaching”.
 
If this is truly your case, I think it is a bug. The reason might lie in 
that, Cinder forgets to refresh the attach_status attribute of a volume in 
DB when applying a “force delete” operation.
Is there any other suggestions?
 
Thanks!
 
 
 
From: yunling [mailto:yunlingz...@hotmail.com] 
Sent: Monday, February 17, 2014 9:14 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cinder]Do you think volume force delete 
operation should not apply to the volume being used?
 
Hi stackers: 
 
 
I found that volume status become inconsistent (nova volume status is 
attaching, verus cinder volume status is deleted) between nova and cinder 
when doing volume force delete operation on an attaching volume. 
I think volume force delete operation should not apply to the volume being 
used, which included the attached status of attaching, attached and 
detached. 
 
 
How do you think? 
 
 
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] Proposal to move from Freenode to OFTC

[Jay S Bryant]

From:   Brian Cline 
To: openstack-dev@lists.openstack.org, 
Date:   03/04/2014 12:29 PM
Subject:Re: [openstack-dev] Proposal to move from Freenode to OFTC



On 03/04/2014 05:01 AM, Thierry Carrez wrote:
> James E. Blair wrote:
>> Freenode has been having a rough time lately due to a series of DDoS
>> attacks which have been increasingly disruptive to collaboration.
>> Fortunately there's an alternative.
>>
>> OFTC http://www.oftc.net/> is a robust and established alternative
>> to Freenode.  It is a smaller network whose mission statement makes it 
a
>> less attractive target.  It's significantly more stable than Freenode
>> and has friendly and responsive operators.  The infrastructure team has
>> been exploring this area and we think OpenStack should move to using
>> OFTC.
> There is quite a bit of literature out there pointing to Freenode, like
> presentation slides from old conferences. We should expect people to
> continue to join Freenode's channels forever. I don't think staying a
> few weeks on those channels to redirect misled people will be nearly
> enough. Could we have a longer plan ? Like advertisement bots that would
> advise every n hours to join the right servers ?
>
>> [...]
>> 1) Create an irc.openstack.org CNAME record that points to
>> chat.freenode.net.  Update instructions to suggest users configure 
their
>> clients to use that alias.
> I'm not sure that helps. The people who would get (and react to) the DNS
> announcement are likely using proxies anyway, which you'll have to
> unplug manually from Freenode on switch day. The vast majority of users
> will just miss the announcement. So I'd rather just make a lot of noise
> on switch day :)
>
> Finally, I second Sean's question on OFTC's stability. As bad as
> Freenode is hit by DoS, they have experience handling this, mitigation
> procedures in place, sponsors lined up to help, so damage ends up
> *relatively* limited. If OFTC raises profile and becomes a target, are
> we confident they would mitigate DoS as well as Freenode does ? Or would
> they just disappear from the map completely ? I fear that we are trading
> a known evil for some unknown here.
>
> In all cases I would target post-release for the transition, maybe even
> post-Summit.
>

Indeed, I can't help but feel like the large amount of effort involved 
in changing networks is a bit of a riverboat gamble. DDoS has been an 
unfortunate reality for every well-known/trusted/stable IRC network for 
the last 15-20 years, and running from it rather than planning for it is 
usually a futile effort. It feels like we'd be chasing our tails trying 
to find a place where DDoS couldn't cause serious disruption; even then 
it's still not a sure thing. I would hate to see everyone's efforts to 
have been in vain once the same problem occurs there.

-- 
Brian Cline
br...@linux.vnet.ibm.com


+1  I have not seen this as a frequent problem.  I have been aware of it 
but it
seems a bit excessive to move to a possibly less equipped provider.

-Jay



___
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] mid-cycle meet-up planning ...

[Jay S. Bryant]

All,

For those of you that weren't able to make the Kilo meet-up in Paris I 
wanted to send out a note regarding Cinder's Kilo mid-cycle meet-up.


IBM has offered to host it in, warm, sunny, Austin, Texas.  The planned 
dates are January 27, 28 and 29, 2015.


I have put together an etherpad with the current plan and will be 
keeping the etherpad updated as we continue to firm out the details: 
https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup


I need to have a good idea how many people are planning to participate 
sooner, rather than later, so that I can make sure we have a big enough 
room.  So, if you think you are going to be able to make it please add 
your name to the 'Planned Attendees' list.


Again, we will also use Google Hangout to virtually include those who 
cannot be physically present.  I have a space in the etherpad to include 
your name if you wish to join that way.


I look forward to another successful meet-up with all of you!

Jay
(jungleboyj)

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

Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?

[Jay S. Bryant]

Monty,

I agree that upgrade is not a significant concern right now if the 
existing driver is not working.


Drew,

I am having trouble following where you guys are currently at with this 
work.  I would like to help get you guys up and going during Kilo.


I am concerned that maybe there is confusion about the 
blueprints/patches that we are all talking about here.  I see this 
Blueprint that was accepted for Juno and appears to have an associated 
patch merged:  [1]  I also see this Blueprint that doesn't appear to be 
started yet: [2]  So, can you help me understand what it is you are 
hoping to get in for Kilo?


I know that you have been concerned about CI.  For new drivers we are 
allowing some grace period to get things working.  Once we get the 
confusion over blueprints worked out and have some code to start 
reviewing we can continue to discuss that issue.


Look forward to hearing back from you!
Jay


[1] 
https://blueprints.launchpad.net/cinder/+spec/oracle-zfssa-cinder-driver
[2] 
https://blueprints.launchpad.net/cinder/+spec/oracle-zfssa-nfs-cinder-driver


On 11/24/2014 11:53 AM, Monty Taylor wrote:

On 11/24/2014 10:14 AM, Drew Fisher wrote:


On 11/17/14 10:27 PM, Duncan Thomas wrote:

Is the new driver drop-in compatible with the old one? IF not, can
existing systems be upgraded to the new driver via some manual steps, or
is it basically a completely new driver with similar functionality?

Possibly none of my business- but if the current driver is actually just
flat broken, then upgrading from it to the new solaris ZFS driver seems
unlikely to be possibly, simply because the from case is broken.


The driver in san/solaris.py focuses entirely on iSCSI.  I don't think
existing systems can be upgraded manually but I've never really tried.
We started with a clean slate for Solaris 11 and Cinder and added local
ZFS support for single-system and demo rigs along with a fibre channel
and iSCSI drivers.

The driver is publically viewable here:

https://java.net/projects/solaris-userland/sources/gate/content/components/openstack/cinder/files/solaris/zfs.py

Please note that this driver is based on Havana.  We know it's old and
we're working to get it updated to Juno right now.  I can try to work
with my team to get a blueprint filed and start working on getting it
integrated into trunk.

-Drew

___
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] [stable] New config options, no default change

[Jay S. Bryant]

On 11/25/2014 08:10 AM, Ihar Hrachyshka wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/11/14 20:17, Jay S. Bryant wrote:

All,

This is a question I have been struggling with for Cinder recently.
Where do we draw the line on backports.  How do we handle config changes?

One thing for Cinder I am also considering, in addition to whether it
changes the default functionality, is whether it is specific to the
submitter's driver.  If it is only going to affect the driver I am more
likely to consider it than something that is going to impact all of Cinder.

What is the text that should be included in the commit messages to make
sure that it is picked up for release notes?  I want to make sure that
people use that.

I'm not sure anyone tracks commit messages to create release notes. A
better way to handle this is to create a draft, post it in review
comments, and copy to release notes draft right before/after pushing the
patch into gate.

Ihar,

Forgive me, I think my question is more basic then.  Where are the 
release notes for a stable branch located to make such changes?


Thanks!




Thanks!
Jay


On 11/11/2014 06:50 AM, Alan Pevec wrote:

New config options may not change behavior (if default value preserves
behavior), they still make documentation more incomplete (doc, books,
and/or blogposts about Juno won't mention that option).

That's why we definitely need such changes described clearly in stable
release notes.
I also lean to accept this as an exception for stable/juno, I'll
request relnote text in the review.

Cheers,
Alan

___
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

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUdI3AAAoJEC5aWaUY1u57YDkH/1LL/Y0gL2egRs1F6pgoaVbk
bEREvavZMyV6JFrojfJz2HKVxeo//0AdCcr3+W7KH5pXtposhg3Xf5v6bhF+n0gO
NX8u23z2zBLh6xdYcJHiRtMz1zhXT66xDhZso4bMNAL98glGOv1rrbkmkj43pR2L
TKSgRyes75nEBOlvPi79Co+2Ti3Z60HbS1NwgqCTGb9yRV3o0JDMZ3+zdFKlrTTf
0ZkrqEHtDaS0wEJmi7vqDAflNBPPn4lo8mAcju9k80lwrCs7g6VdqYJec0Nb/1gJ
Foj6vWRPHDH1ftph3am4yhY6Gs+dXQ1nmhEK0zFucDeLXz01Gql3vKX0xK18Rho=
=6ABy
-END PGP SIGNATURE-

___
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] [stable] New config options, no default change

[Jay S. Bryant]

On 12/02/2014 02:31 AM, Alan Pevec wrote:

What is the text that should be included in the commit messages to make sure 
that it is picked up for release notes?

I'm not sure anyone tracks commit messages to create release notes.

Let's use existing DocImpact tag, I'll add check for this in the
release scripts.
But I prefer if you could directly include the proposed text in the
draft release notes (link below)
I like the idea of using the DocImpact tag to be consistent with what is 
done in the Master branch.

Thanks for the link to the ReleaseNotes wiki page.


better way to handle this is to create a draft, post it in review
comments, and copy to release notes draft right before/after pushing the
patch into gate.

Forgive me, I think my question is more basic then.  Where are the release
notes for a stable branch located to make such changes?

https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.1#Known_Issues_and_Limitations


Cheers,
Alan



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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Jay S. Bryant]

On 12/02/2014 07:22 AM, Alan Pevec wrote:

Hi all,

here are exception proposal I have collected when preparing for the
2014.2.1 release,
stable-maint members please have a look!


General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in the
release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z

Ceilometer (all proposed by Ceilo PTL)
https://review.openstack.org/138315
https://review.openstack.org/138317
https://review.openstack.org/138320
https://review.openstack.org/138321
https://review.openstack.org/138322

Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver

+1 I think this is fine to make an exception for.


Glance
https://review.openstack.org/137704 - glance_store is backward
compatible, but not sure about forcing version bump on stable
https://review.openstack.org/137862 - Disable osprofiler by default to
prevent upgrade issues, disabled by default in other services

Horizon
standing-after-freeze translation update, coming on Dec 3
https://review.openstack.org/138018 - visible issue, no translation
string changes
https://review.openstack.org/138313 - low risk patch for a highly
problematic issue

Neutron
https://review.openstack.org/136294 - default SNAT, see review for
details, I cannot distil 1liner :)
https://review.openstack.org/136275 - self-contained to the vendor
code, extensively tested in several deployments

Nova
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno+topic:1386236/juno,n,z
- soaked more than a week in master, makes numa actually work in Juno

Sahara
https://review.openstack.org/135549 - fix for auto security groups,
there were some concerns, see review for details

___
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] [stable] Exception proposals for 2014.2.1

[Jay S. Bryant]

On 12/03/2014 01:17 PM, Alan Pevec wrote:

2014-12-02 17:15 GMT+01:00 Jay S. Bryant :

Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver

+1 I think this is fine to make an exception for.

one more Cinder exception proposal was added in StableJuno etherpad
* https://review.openstack.org/#/c/138526/ (This is currently the
master version but I will be proposing to stable/juno as soon as it is
approved in Master)  The Brocade FS San Lookup facility is currently
broken and this revert is necessary to get it working again.

Jay, what's the status there, I see master change failed in gate?

Cheers,
Alan
Finally was able to get the master version through the gate and 
cherry-picked it here:

https://review.openstack.org/#/c/139194/

That one has made it through the check.  So, if it isn't too late, it 
could use a +2/+A.


Thanks!
Jay


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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Jay S. Bryant]

On 12/04/2014 05:01 PM, Alan Pevec wrote:

2014-12-04 23:00 GMT+01:00 Jay S. Bryant :

Finally was able to get the master version through the gate and
cherry-picked it here:
https://review.openstack.org/#/c/139194/

That one has made it through the check.  So, if it isn't too late, it could
use a +2/+A.

Looks good and is exception worthy, approved.


Thanks so much Alan!


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

Re: [openstack-dev] [cinder] Anyone knows whether there is freezing day of spec approval?

[Jay S. Bryant]

Dave,

My apologies.  We have not yet set a day that we are freezing BP/Spec 
approval for Cinder.


We had a deadline in November for new drivers being proposed but haven't 
frozen other proposals yet.  I mixed things up with Nova's 12/18 cutoff.


Not sure when we will be cutting off BPs for Cinder.  The goal is to 
spend as much of K-2 and K-3 on Cinder clean-up.  So, I wouldn't let 
anything you want considered linger too long.


Thanks,
Jay

On 12/15/2014 09:16 PM, Chen, Wei D wrote:

Hi,

I know nova has such day around Dec. 18, is there a similar day in Cinder 
project? thanks!

Best Regards,
Dave Chen




___
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-Dev] Logging formats and i18n

[Jay S. Bryant]

John,

Thank you for starting this discussion and Doug, thank you for 
clarifying.  Your explanation below helps a lot!


Jay


On 12/22/2014 12:13 PM, Doug Hellmann wrote:

On Dec 22, 2014, at 1:05 PM, John Griffith  wrote:


On Mon, Dec 22, 2014 at 10:03 AM, Ben Nemec  wrote:

On 12/22/2014 09:42 AM, John Griffith wrote:

Lately (on the Cinder team at least) there's been a lot of
disagreement in reviews regarding the proper way to do LOG messages
correctly.  Use of '%' vs ',' in the formatting of variables etc.

We do have the oslo i18n guidelines page here [1], which helps a lot
but there's some disagreement on a specific case here.  Do we have a
set answer on:

LOG.info(_LI('some message: v1=%(v1)s v2=%(v2)s') % {'v1': v1, 'v2': v2})

vs

LOG.info(_LI('some message: v1=%(v1)s v2=%(v2)s'), {'v1': v1, 'v2': v2})

This is the preferred way.

Note that this is just a multi-variable variation on
http://docs.openstack.org/developer/oslo.i18n/guidelines.html#adding-variables-to-log-messages
and the reasoning discussed there applies.

I'd be curious why some people prefer the % version because to my
knowledge that's not recommended even for untranslated log messages.

Not sure if it's that anybody has a preference as opposed to an
interpretation, notice the recommendation for multi-vars in raise:

# RIGHT
raise ValueError(_('some message: v1=%(v1)s v2=%(v2)s') % {'v1': v1, 'v2': v2})

It’s really not related to translation as much as the logging API itself.

With the exception, you want to initialize the ValueError instance with a 
proper message as soon as you throw it because you don’t know what the calling 
code might do with it. Therefore you use string interpolation inline.

When you call into  the logging subsystem, your call might be ignored based on 
the level of the message and the logging configuration. By letting the logging 
code do the string interpolation, you potentially skip the work of serializing 
variables to strings for messages that will be discarded, saving time and 
memory.

These “rules” apply whether your messages are being translated or not, so even 
for debug log messages you should write:

   LOG.debug(‘some message: v1=%(v1)s v2=%(v2)s’, {‘v1’: v1, ‘v2’: v2})



It's always fun when one person provides a -1 for the first usage; the
submitter changes it and another reviewer gives a -1 and says, no it
should be the other way.

I'm hoping maybe somebody on the olso team can provide an
authoritative answer and we can then update the example page
referenced in [1] to clarify this particular case.

Thanks,
John

[1]: http://docs.openstack.org/developer/oslo.i18n/guidelines.html

___
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



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

Re: [openstack-dev] [3rd-party-ci] Cinder CI and CI accounts

[Jay S. Bryant]

John and Ramy,

Thanks for the feedback.  So, we will create an IBM Storage CI Check 
account and slowly deprecate the multiple accounts as we consolidate the 
hardware.


Jay


On 12/23/2014 08:11 PM, Asselin, Ramy wrote:

I agree with John. Option 4: one ci account for all drivers.

The only valid reasons I'm aware of to use multiple accounts for a single 
vendor is if the hardware required to run the tests are not accessible from a 
'central' ci system, or if the ci systems are managed by different teams.

Otherwise, as you stated, it's more complicated to manage & maintain.

Ramy

-Original Message-
From: John Griffith [mailto:john.griffi...@gmail.com]
Sent: Tuesday, December 23, 2014 3:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [3rd-party-ci] Cinder CI and CI accounts

On Tue, Dec 23, 2014 at 12:07 PM, Alon Marx  wrote:

Hi All,

In IBM we have several cinder drivers, with a number of CI accounts.
In order to improve the CI management and maintenance, we decided to
build a single Jenkins master that will run several jobs for the drivers we own.
Adding the jobs to the jenkins master went ok, but we encountered a
problem with the CI accounts. We have several drivers and several
accounts, but in the Jenkins master, the Zuul configuration has only
one gerrit account that reports.

So there are several questions:
1. Was this problem encountered by others? How did they solve it?
2. Is there a way to configure Zuul on the Jenkins master to report
different jobs with different CI accounts?
3. If there is no way to configure the master to use several CI
accounts, should we build a Jenkins master per driver?
4. Or another alternative, should we use a single CI account for all
drivers we own, and report all results under that account?

We'll appreciate any input.

Thanks,
Alon

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


If you have a look at a review in gerrit you can see others appear to have a single 
account with multiple tests/results submitted.  HP, EMC and NetApp all appear to be 
pretty clear examples of how to go about doing this.  My personal preference on this has 
always been a single CI account anyway with the different drivers consolidated under it; 
if nothing else it reduces clutter in the review posting and makes it "easier" 
to find what you might be looking for.

___
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] [stable-maint] acceptable changes for stable/icehouse

[Jay S. Bryant]

All,

We have been getting a number of non-security patches proposed to 
stable/icehouse for Cinder.  The cores were discussing what was ok to 
put into icehouse at this point in time and couldn't agree as to whether 
we were at the point of only accepting security changes.


Appreciate advice on this topic.

Jay

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

Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

[Jay S. Bryant]

Steven,

Thank you for continuing to pursue this.  Adding this functionality and 
having it consistent will be a good thing.


The plan for Cinder looks good to me and is consistent with Mike and 
Duncan's input.


I look forward to seeing patches for Cinder.

Jay

On 01/06/2015 10:03 AM, Steven Kaufer wrote:


This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the 
client side sorting has the following syntax: --sort [:]


Where the --sort parameter is comma-separated and is used to specify 
one or more sort keys and directions. The direction defaults to 'desc' 
for each sort key and the user can supply 'asc' to override.


For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and 
cinder (note that nova already uses this syntax):


  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may 
be other projects that would also need to be changed.


Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard 
please let me know.


[1] 
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html

[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer


___
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] [stable] Swift object-updater and container-updater

[Jay S. Bryant]

Minwoo,

It is important to understand that Icehouse has gone into a security 
fixes only mode.  It is too late in the stable process to be making 
notable changes for anything other than security issues.


The patch for the fork bomb like problem in object-auditor is in 
Icehouse:  https://review.openstack.org/#/c/126371/  So, we do not need 
to worry about that one.  The other two problems are not really security 
problems as they cause the object-updater and container-updater to throw 
an exception and exit.  The behavior is irritating but not a security risk.


So, I think the fix that you are really asking to have fixed in 
Icehouse, has already merged.  I will propose the other fixes back to 
stable/juno but don't feel they warrant a change in Icehouse.


I hope this clarifies the situation.

Jay

On 01/08/2015 09:21 AM, Minwoo Bae wrote:

Hi, to whom it may concern:


Jay Bryant and I would like to have the fixes for the Swift 
object-updater (https://review.openstack.org/#/c/125746/) and the 
Swift container-updater 
(https://review.openstack.org/#/q/I7eed122bf6b663e6e7894ace136b6f4653db4985,n,z) 
backported to Juno and then to Icehouse soon if possible. It's been in 
the queue for a while now, so we were wondering if we could have an 
estimated time for delivery?


Icehouse is in security-only mode, but the container-updater issue may 
potentially be used as a fork-bomb, which presents security concerns. 
To further justify the fix, a problem of similar nature 
https://review.openstack.org/#/c/126371/(regarding the object-auditor) 
was successfully fixed in stable/icehouse.


The object-updater issue may potentially have some security 
implications as well.



Thank you very much!

Minwoo


___
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] [stable] Swift object-updater and container-updater

[Jay S. Bryant]

Minwoo,

The cherry-picks for the contain-updater and object-updater back to 
stable/juno are now available for review: 
https://review.openstack.org/146211 and https://review.openstack.org/134082


Jay

On 01/08/2015 09:21 AM, Minwoo Bae wrote:

Hi, to whom it may concern:


Jay Bryant and I would like to have the fixes for the Swift 
object-updater (https://review.openstack.org/#/c/125746/) and the 
Swift container-updater 
(https://review.openstack.org/#/q/I7eed122bf6b663e6e7894ace136b6f4653db4985,n,z) 
backported to Juno and then to Icehouse soon if possible. It's been in 
the queue for a while now, so we were wondering if we could have an 
estimated time for delivery?


Icehouse is in security-only mode, but the container-updater issue may 
potentially be used as a fork-bomb, which presents security concerns. 
To further justify the fix, a problem of similar nature 
https://review.openstack.org/#/c/126371/(regarding the object-auditor) 
was successfully fixed in stable/icehouse.


The object-updater issue may potentially have some security 
implications as well.



Thank you very much!

Minwoo


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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] [oslo] dropping namespace packages

[Jay S. Bryant]

Ihar,

I agree that we should do something to enforce using the appropriate 
namespace so that we don't have the wrong usage sneak in.


I haven't gotten any rules written yet.  Have had to attend to a family 
commitment the last few days.  Hope that I can tackle the namspace 
changes next week.


Jay
On 01/08/2015 12:24 PM, Ihar Hrachyshka wrote:

On 01/08/2015 07:03 PM, Doug Hellmann wrote:
I’m not sure that’s something we need to enforce. Liaisons should be 
updating projects now as we release libraries, and then we’ll 
consider whether we can drop the namespace packages when we plan the 
next cycle.


Without a hacking rule, there is a chance old namespace usage will 
sneak in, and then we'll need to get back to updating imports. I would 
rather avoid that and get migration committed with enforcement.


/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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 the Cinder midcycle meetup

[Jay S. Bryant]

Mike,

Thanks for putting this out there again.

A reminder, if you are planning to attend, please update the etherpad so 
that I can get an accurate number in attendance and get all the security 
details set up.


Thank you!

Jay

On 01/10/2015 04:00 PM, Mike Perez wrote:

The meetup will be in Austin, TX on January 27-29. You can find more
information and post your topics on the etherpad:

https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup




__
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

[Jay S. Bryant]

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




__
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] More Details for Mid-Cycle meetup:

[Jay S. Bryant]

All,

I have updated the mid-cycle meetup etherpad 
(https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup) with more 
details with regards to finding the right building on the IBM site and 
have also added my cell phone number to the notes.  Please don't 
hesitate to call or text me with questions.


I have updated the note on dinner at Rudy's, it is on Tuesday, not 
Monday.  For those of you who are in town tonight (1/26), let me know.  
Going to try to get those who are interested together for dinner.


Look forward to seeing you all soon!

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

Re: [openstack-dev] [cinder] proposal of definitions/processes for cinder-spec

[Jay S. Bryant]

On Thu, 2014-04-24 at 15:11 -0700, Walter A. Boring IV wrote:
> On 04/23/2014 05:09 PM, Jay S. Bryant wrote:
> > All,
> >
> > I have gotten questions from our driver developers asking for details
> > regarding the move to using cinder-specs for proposing Blueprints.  I
> > brought this topic up in today's Cinder Weekly Meeting, but the meeting
> > was lightly attended so we decided to move the discussion here.
> >
> > I am going to put this note in the form of 'question' and proposed
> > answer based on the brief discussion we had today.  Note that the
> > answers here are based on the assumption that we want to keep Cinder's
> > use of 'specs' as close to Nova's as possible.  I used the following
> > mailing list thread as a starting point for some of these answers:
> > http://lists.openstack.org/pipermail/openstack-dev/2014-April/032796.html
> >
> > Q: When is a spec approved?
> > A:  When it receives a +2 from the PTL and at least one other Core
> > reviewer.
> >
> > Q: How long are specs valid for?
> > A: For the duration of the release cycle.  Any specs that are not
> > approved during that period of type will need to be resubmitted for the
> > subsequent release.
> >
> > Q: What will the spec template look like?
> > A: This is one of the points I would like to discuss.  The Nova template
> > currently looks like this:
> > https://github.com/openstack/nova-specs/blob/master/specs/template.rst
> > Do we want to follow the same template.  In the interest of staying in
> > sync with Nova's implementation I would say yes, but does this meet our
> > needs?  Are there other/different fields we want to consider to help for
> > instances where the Blueprint is for a new driver or change to a driver?
> > I think we might need, for instance, a 'Drivers Impacted' field.
> I think for starters, we should use the same template until we find
> it doesn't fit our needs.   I just filed my first nova-spec bp
> and rather liked the template and think it would be nice to have this
> for Cinder  cinder-spec.

Good to know Walter.  I haven't been through the process yet.  Glad to
know you felt good about it.  That is helpful to know

> 
> 
> >
> > Q: Will driver developers have to use the same template for functions in
> > their drivers?
> > A: Also a point I would like to discuss.  Developers had asked if a more
> > limited template would be used for changes going into the developer's
> > driver.  At first I thought maybe a different template for Blueprints
> > against a driver might be appropriate, but after looking more closely at
> > Nova's template perhaps that is not necessary.  I would lean towards
> > keeping one template, but maybe not requiring all fields depending on
> > what our final template ends up looking like.
> for now I vote for using the same template.

The more I think about it, I agree.

> >
> > Q: Where do specs for python-cinderclient go?
> > A: Looks like Nova has added a python-novaclient directory.  I don't
> > think we would need a separate python-cinderclient-specs repository but
> > don't have a strong opinion on this point.
> >
> > I am sure this is not an exhaustive list of questions/answers at this
> > point in time but I wanted to start the discussion so we could help move
> > this process forward.  I look forward to your feedback.
> >
> > -Jay Bryant
> > jsbry...@electronicjungle.net
> > Freenode:  jungleboyj
> >
> >
> >
> >
> > ___
> > 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][globalization] Need input on how to proceed .

[Jay S. Bryant]

All,

I am looking for feedback on how to complete implementation of i18n
support for Cinder.  I need to open a new BluePrint for Juno as soon as
the cinder-specs process is available.  In the mean time I would like to
start working on this and need feedback on the scope I should undertake
with this.

First, the majority of the code for i18n support went in with Icehouse.
There is just a small change that is needed to actually enable Lazy
Translation again.  I want to get this enabled as soon as possible to
get plenty of runtime on the code for Icehouse.

The second change is to add an explicit export for '_' to all of our
files to be consistent with other projects. [1]  This is also the safer
way to implement i18n.  My plan is to integrate the change as part of
the i18n work.  Unfortunately this will touch many of the files in
Cinder.

Given that fact, this brings me to the item I need feedback upon.  It
appears that Nova is moving forward with the plan to remove translation
of debug messages as there was a recent patch submitted to enable a
check for translated DEBUG messages.  Given that fact, would it be an
appropriate time, while adding the explicit import of '_' to also remove
translation of debug messages.  It is going to make the commit for
enabling Lazy Translation much bigger, but it would also take out
several work items that need to be addressed at once.  I am willing to
undertake the effort if I have support for the changes.

Please let me know your thoughts.

Thanks!2]
Jay
(jungleboyj on freenode)

[1] https://bugs.launchpad.net/cinder/+bug/1306275


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

Re: [openstack-dev] [cinder][globalization] Need input on how to proceed .

[Jay S. Bryant]

Duncan,

Thanks for the response.  Have some additional thoughts, in-line, below:


On Mon, 2014-04-28 at 12:15 +0100, Duncan Thomas wrote:
> Two separate patches, or even two chains of separate patches, will
> make reviewing and more importantly (hopefully temporary) backouts
> easier. It will also reduce the number of merge conflicts, which are
> still likely to be substantial.

True, I suppose we need to keep in mind the fact that we might want to
make this be easy to back-out in the future.  Hopefully it isn't an
issue this time around though.

> There's no benefit at all to all of this being done in one patch, and
> substantial costs. Doing the conversion by sections seems like the way
> forward.

So, let me propose a different process here.  Handling the i18n and
removal of debug separately instead.  First, propose one patch that will
add the explicit import of '_' to all files.  There will be a lot of
files touched, but they all will be 1 liners.  Then make the patch for
the re-enablement of lazy tanslation a second patch that is dependent
upon the first patch.

Then handle removal of _() from DEBUG logs as a separate issue once the
one above has merged.  For that change do it in multiple patches divided
by section.  Make the sections be the top level directories under
cinder/ ?  Does that sound like a reasonable plan?

> 
> Doing both around the same time (maybe as dependant patches) seems reasonable
> 

As I think about it, I don't know that the debug translation removal
needs to be dependent, but we could work it out that way if you feel
that is important.

Let me know what you think.

Thanks!

> On 27 April 2014 00:20, Jay S. Bryant  wrote:
> > All,
> >
> > I am looking for feedback on how to complete implementation of i18n
> > support for Cinder.  I need to open a new BluePrint for Juno as soon as
> > the cinder-specs process is available.  In the mean time I would like to
> > start working on this and need feedback on the scope I should undertake
> > with this.
> >
> > First, the majority of the code for i18n support went in with Icehouse.
> > There is just a small change that is needed to actually enable Lazy
> > Translation again.  I want to get this enabled as soon as possible to
> > get plenty of runtime on the code for Icehouse.
> >
> > The second change is to add an explicit export for '_' to all of our
> > files to be consistent with other projects. [1]  This is also the safer
> > way to implement i18n.  My plan is to integrate the change as part of
> > the i18n work.  Unfortunately this will touch many of the files in
> > Cinder.
> >
> > Given that fact, this brings me to the item I need feedback upon.  It
> > appears that Nova is moving forward with the plan to remove translation
> > of debug messages as there was a recent patch submitted to enable a
> > check for translated DEBUG messages.  Given that fact, would it be an
> > appropriate time, while adding the explicit import of '_' to also remove
> > translation of debug messages.  It is going to make the commit for
> > enabling Lazy Translation much bigger, but it would also take out
> > several work items that need to be addressed at once.  I am willing to
> > undertake the effort if I have support for the changes.
> >
> > Please let me know your thoughts.
> >
> > Thanks!2]
> > Jay
> > (jungleboyj on freenode)
> >
> > [1] https://bugs.launchpad.net/cinder/+bug/1306275
> >
> >
> > ___
> > 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] About store faults info for volumes

[Jay S. Bryant]

On Wed, 2014-04-30 at 10:20 -0700, Mike Perez wrote:
> On 06:49 Wed 30 Apr , Zhangleiqiang (Trump) wrote:
> > Hi stackers:
> > 
> > I found when a instance status become "error", I will see the detailed 
> > fault info at times when I "show" the detail of Instance.  And it is very 
> > convenient for me to find the failed reason. Indeed, there is a 
> > "nova.instance_faults" which stores the fault info.
> > 
> > Maybe it is helpful for users if Cinder also introduces the similar 
> > mechanism. Any advice?
> > 
> > 
> > --
> > zhangleiqiang (Trump)
> > 
> > Best Regards
> 
> There are some discussions that started a couple of weeks ago about using sub
> states like Nova to know more clearly what happened when a volume is in an
> 'error' state. Unfortunately I'm not sure if that'll be in a formal session at
> the summit, but it'll definitely be discussed while we have the team together.
> Maybe John Griffith can comment since he's approving the sessions.
> 

I hope there is a plan to discuss this.  I have in my meeting notes from
the 4/16 Cinder meeting that there is going to be a summit session.

If that is forgotten we should at least plan to have an informal
discussion about it at some point.  I'll by a round of drinks if
necessary.  :-)

Jay
Freenode:  JungleboyJ


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

Re: [openstack-dev] [cinder][globalization] Need input on how to proceed .

[Jay S. Bryant]

Thanks for the input Duncan.

The removal of the debug logs is really a separate issue.  I was just
hoping to reduce the number of patches that would touch a large number
of files.  As we are thinking through this though, it really is a
separate change so it is best to do separate patches.

On a related note, we shouldn't be taking changes that have debug
messages translated if we are moving forward with removing translation
of debug messages.

Jay

On Thu, 2014-05-01 at 16:41 +0100, Duncan Thomas wrote:
> That sounds like a sensible way forward, yes.
> 
> If the dependency is not need, then great, makes review and merge even easier.
> 
> Thanks
> 
> On 28 April 2014 17:03, Jay S. Bryant  wrote:
> > Duncan,
> >
> > Thanks for the response.  Have some additional thoughts, in-line, below:
> >
> >
> > On Mon, 2014-04-28 at 12:15 +0100, Duncan Thomas wrote:
> >> Two separate patches, or even two chains of separate patches, will
> >> make reviewing and more importantly (hopefully temporary) backouts
> >> easier. It will also reduce the number of merge conflicts, which are
> >> still likely to be substantial.
> >
> > True, I suppose we need to keep in mind the fact that we might want to
> > make this be easy to back-out in the future.  Hopefully it isn't an
> > issue this time around though.
> >
> >> There's no benefit at all to all of this being done in one patch, and
> >> substantial costs. Doing the conversion by sections seems like the way
> >> forward.
> >
> > So, let me propose a different process here.  Handling the i18n and
> > removal of debug separately instead.  First, propose one patch that will
> > add the explicit import of '_' to all files.  There will be a lot of
> > files touched, but they all will be 1 liners.  Then make the patch for
> > the re-enablement of lazy tanslation a second patch that is dependent
> > upon the first patch.
> >
> > Then handle removal of _() from DEBUG logs as a separate issue once the
> > one above has merged.  For that change do it in multiple patches divided
> > by section.  Make the sections be the top level directories under
> > cinder/ ?  Does that sound like a reasonable plan?
> >
> >>
> >> Doing both around the same time (maybe as dependant patches) seems 
> >> reasonable
> >>
> >
> > As I think about it, I don't know that the debug translation removal
> > needs to be dependent, but we could work it out that way if you feel
> > that is important.
> >
> > Let me know what you think.
> >
> > Thanks!
> >
> >> On 27 April 2014 00:20, Jay S. Bryant  
> >> wrote:
> >> > All,
> >> >
> >> > I am looking for feedback on how to complete implementation of i18n
> >> > support for Cinder.  I need to open a new BluePrint for Juno as soon as
> >> > the cinder-specs process is available.  In the mean time I would like to
> >> > start working on this and need feedback on the scope I should undertake
> >> > with this.
> >> >
> >> > First, the majority of the code for i18n support went in with Icehouse.
> >> > There is just a small change that is needed to actually enable Lazy
> >> > Translation again.  I want to get this enabled as soon as possible to
> >> > get plenty of runtime on the code for Icehouse.
> >> >
> >> > The second change is to add an explicit export for '_' to all of our
> >> > files to be consistent with other projects. [1]  This is also the safer
> >> > way to implement i18n.  My plan is to integrate the change as part of
> >> > the i18n work.  Unfortunately this will touch many of the files in
> >> > Cinder.
> >> >
> >> > Given that fact, this brings me to the item I need feedback upon.  It
> >> > appears that Nova is moving forward with the plan to remove translation
> >> > of debug messages as there was a recent patch submitted to enable a
> >> > check for translated DEBUG messages.  Given that fact, would it be an
> >> > appropriate time, while adding the explicit import of '_' to also remove
> >> > translation of debug messages.  It is going to make the commit for
> >> > enabling Lazy Translation much bigger, but it would also take out
> >> > several work items that need to be addressed at once.  I am willing to
> >> > undertake the effort if I have support for the changes.
> >> >
> >> > Please let me know your tho

Re: [openstack-dev] Commit the cinder Driver

[Jay S. Bryant]

Mardan,

Note, you will also need to follow the new Cinder Specs process for Juno
BluePrints.  You can find details here: [1]

Jay

[1]
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-28-16.00.log.html#l-437

On Wed, 2014-05-07 at 18:48 +0530, Swapnil Kulkarni wrote:
> Missed some of the additional links which might be helpful/important
> for you.
> 
> 
> [1] https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
> [2] https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer
> 
> 
> 
> 
> 
> 
> On Wed, May 7, 2014 at 11:38 AM, Swapnil Kulkarni 
> wrote:
> Hi Mardan,
> 
> 
> 
> 
> Thanks!
> 
> 
> For the Cloudbyte ElastiStor I can see couple of (duplicate)
> blueprints filed [1] [2].  You should probably assign one of
> them to you and update  with details till we get cinder-spec
> available for blueprint review process.
> 
> 
> For details about commit process please refer [3].
> 
> 
> For any issues with commit process, feel free to ask questions
> at #openstack-cinder @ freenode.net 
> 
> 
> Also, you should try to attend Cinder meetings [4] to update
> the team about your progress on commits and for any updates
> you should be having related to new driver submissions.
> 
> 
> 
> 
> [1] 
> https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver
> [2] 
> https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver-cinder
> [3] https://wiki.openstack.org/wiki/Gerrit_Workflow
> [4] https://wiki.openstack.org/wiki/CinderMeetings
> 
> 
> 
> Best Regards,
> Swapnil Kulkarni
> irc : coolsvap
> cools...@gmail.com
> +91-87960 10622(c)
> http://in.linkedin.com/in/coolsvap
> 
> "It's better to SHARE"
> 
> 
> 
> On Wed, May 7, 2014 at 11:24 AM, Mardan Raghuwanshi
>  wrote:
> 
> Hi All,
> 
> 
> I developed Cinder driver for CloudByte's ElastiStor,
> now I want to check in this code into master.
> 
> I don't have more idea about git and OpenStack commit
> process, can you guys please guide me to commit the
> code into master branch.
> 
> 
> 
> Thanks,
> 
> Mardan
> 
> 
> 
> ___
> 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] [Nova] FFE Request: Oslo: i18n Message improvements

[Jay S Bryant]

From:   Sean Dague 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   03/07/2014 04:25 AM
Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message 
improvements



On 03/06/2014 04:46 PM, James Carey wrote:
> Please consider a FFE for i18n Message improvements: 
> BP: https://blueprints.launchpad.net/nova/+spec/i18n-messages
> 
> The base enablement for lazy translation has already been sync'd
> from oslo.   This patch was to enable lazy translation support in Nova.
>  It is titled re-enable lazy translation because this was enabled during
> Havana but was pulled due to issues that have since been resolved.
> 
> In order to enable lazy translation it is necessary to do the
> following things:
> 
>   (1) Fix a bug in oslo with respect to how keywords are extracted from
> the format strings when saving replacement text for use when the message
> translation is done.   This is
> https://bugs.launchpad.net/nova/+bug/1288049, which I'm actively working
> on a fix for in oslo.  Once that is complete it will need to be sync'd
> into nova.
> 
>   (2) Remove concatenation (+) of translatable messages.  The current
> class that is used to hold the translatable message
> (gettextutils.Message) does not support concatenation.  There were a few
> cases in Nova where this was done and they are coverted to other means
> of combining the strings in:
> https://review.openstack.org/#/c/78095Remove use of concatenation on
> messages
> 
>   (3) Remove the use of str() on exceptions.  The intent of this is to
> return the message contained in the exception, but these messages may
> contain unicode, so str cannot be used on them and gettextutils.Message
> enforces this.  Thus these need
> to either be removed and allow python formatting to do the right thing,
> or changed to unicode().  Since unicode() will change to str() in Py3,
> the forward compatible six.text_type() is used instead.  This is done 
in: 
> https://review.openstack.org/#/c/78096Remove use of str() on exceptions
> 
>   (4) The addition of the call that enables the use of lazy messages.
>  This is in:
> https://review.openstack.org/#/c/73706Re-enable lazy translation.
> 
> Lazy translation has been enabled in the other projects so it would
> be beneficial to be consistent with the other projects with respect to
> message translation. 

Unless it has landed in *every other* integrated project besides Nova, I
don't find this compelling.

I have tested that the changes in (2) and (3) work
> when lazy translation is not enabled.  Thus if a problem is found, the
> two line change in (4) could be removed to get to the previous behavior.
> 
> I've been talking to Matt Riedemann and Dan Berrange about this.
>  Matt has agreed to be a sponsor.

If this is enabled in other projects, where is the Tempest scenario test
that actually demonstrates that this is working on real installs?

I get that everyone has features that didn't hit. BHowever now is not
that time for that, now is the time for people to get focussed on bugs
hunting. And especially if we are talking about *another* oslo sync.

-1

 -Sean

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

[attachment "signature.asc" deleted by Jay S Bryant/Rochester/IBM] 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sean,

I really feel like this is being made into a bigger deal than it needs to 
be.

The only other project that hasn't accepted this change is Heat and we are 
currently working to resolve that issue.

We were not aware of a requirement for Tempest tests for a change like 
this.  We would be willing to work on getting those added to resolve that 
issue.
If we were to get these added ASAP would you be willing to reconsider?

As far as the Oslo sync is concerned, it is a sync gettextutils which is 
an isolated module that doesn't have other dependencies and is pulling in 
a number of good bug fixes.
The removal of str() from LOGs and exceptions was a ticking time bomb that 
needed to be addressed anyway.

The change brings good value for users and fixes issues that have been 
lying around for quite some time.  We apologize that this is coming in so 
late in the game.
There were extraneous challenges that lead to the timing on this.

Thank you for your consideration on this issue.

Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message improvements

[Jay S Bryant]

From:   Russell Bryant 
To: openstack-dev@lists.openstack.org, 
Date:   03/07/2014 11:31 AM
Subject:Re: [openstack-dev] [Nova] FFE Request: Oslo: i18n Message 
improvements



On 03/07/2014 12:09 PM, Matt Riedemann wrote:
> Dan (Smith), Sean, Jim, Jay and myself talked about this in IRC this
> morning and I didn't realize the recent oslo bug was uncovered due to
> something changing in how the audit logs were showing up after the
> initial nova patch was pushed up on 2/14.  So given that, given the
> number of things that would still need to land (oslo patch/sync plus
> possibly a hacking rule for str->six.text_type) AND the (despite being
> late) Tempest test requirement, I'm dropping sponsorship for this.
> 
> It simply came in too late and is too risky at this point, so let's
> revisit in Juno and get it turned on early so everyone can be
> comfortable with it.

OK.  Thanks a lot to everyone who helped evaluate this.  Hopefully we
can get it sorted early in Juno, then.

-- 
Russell Bryant

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


All,

Thanks for taking the time to consider/discuss this.

Some good lessons learned on this end.

Look forward to getting this in early in Juno.

Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Jay S Bryant]

From:   Brant Knudson 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   03/14/2014 10:26 AM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator 
update.py





On Wed, Mar 12, 2014 at 11:03 AM, Duncan Thomas  
wrote:
On 15 January 2014 18:53, Brant Knudson  wrote:

> At no point do I care what are the different commits that are being 
brought
> in from oslo-incubator. If the commits are listed in the commit message 
then
> I feel an obligation to verify that they got the right commits in the
> message and that takes extra time for no gain.

--> Duncan, It is important to know what commits are being brought over to 
help provide a pointer to
--> the possible cause of subsequent bugs that arise.  I.E. if we sync up 
the DB, there is a commit for fixing
--> db connection order and suddenly we are getting intermittent DB 
connection failures, it give us
--> a starting point to fixing the issue.

I find that I very much *do* want a list of what changes have been
pulled in, so I've so idea of the intent of the changes. Some of the
OSLO changes can be large and complicated, and the more clues as to
why things changed, the better the chance I've got of spotting
breakages or differing assumptions between cinder and OSLO (of which
there have been a number)

I don't very often verify that the version that has been pulled in is
the very latest or anything like that - generally I want to know:

One thing that I think we should be verifying is that the changes being 
brought over have actually been committed to oslo-incubator. I'm sure 
there have been times where someone eager to get the fix in has not waited 
for the oslo-incubator merge before syncing their change over.

 - What issue are you trying to fix by doing an update? (The fact OSLO
is ahead of us is rarely a good enough reason on its own to do an
update - preferably reference a specific bug that exists in cinder)

When I sync a change from oslo-incubator to fix a bug I put Closes-Bug on 
the commit message to indicate what bug is being fixed. If the sync tool 
was enhanced to pick out the *-Bug references from the oslo commits to 
include in the sync commit message that would be handy.
 
 - What other incidental changes are being pulled in (by intent, not
just the code)
 - If I'm unsure about one of the incidental changes, how do I go find
the history for it, with lots of searching (hense the commit ID or the
change ID) - this lets me find bugs, reviews etc

How does one get the list of commits that are being brought over from 
oslo-incubator? You'd have to know what the previous commit was that was 
synced.

- Brant
___
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] [Oslo] Improving oslo-incubator update.py

[Jay S Bryant]

From:   Duncan Thomas 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   03/14/2014 11:49 AM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator 
update.py



On 14 March 2014 16:10, Jay S Bryant  wrote:
> --> Duncan, It is important to know what commits are being brought over 
to
> help provide a pointer to
> --> the possible cause of subsequent bugs that arise.  I.E. if we sync 
up
> the DB, there is a commit for fixing
> --> db connection order and suddenly we are getting intermittent DB
> connection failures, it give us
> --> a starting point to fixing the issue.


Jay, there's been a mix-up in who's saying what here. I *very much*
want to know what commits are being bought over. For slightly
different reasons (I'm mostly wanting them for easy review, you for
bug fixing). Brant is suggesting that just the last commit ID is
enough, which I disagree with (and will continue to hit -1/-2 for).

If somebody was to improve the import script to do this automatically
that would be great. Currently I can't see an easy way of
programatically telling when the last import was - I'll take another
look at the problem if somebody smarter than me doesn't sort it first

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

Duncan,

Thanks for clarifying!  I was quite confused as I thought you were in
favor of the details in the commit messages.  Sorry for confusing who was 
carrying what stance forward.

Brant,

I agree with Duncan.  I think that having details of the commits that
are being pulled in with a sync commit is important.  I realize that the
user probably isn't going to do a perfect job, but it certainly helps 
to give context to the changes being made and provides important bread 
crumbs
for debug.

It would be great if we could get the process for this automated.  In the 
mean time, those of us doing the syncs will just have to slog through the
process.

Jay


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

Re: [openstack-dev] Duplicate code for processing REST APIs

[Jay S Bryant]

From:   Duncan Thomas 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   03/14/2014 11:56 AM
Subject:Re: [openstack-dev] Duplicate code for processing REST 
APIs



On 13 March 2014 21:13, Roman Podoliaka  wrote:
> Hi Steven,
>
> Code from openstack/common/ dir is 'synced' from oslo-incubator. The
> 'sync' is effectively a copy of oslo-incubator subtree into a project
> source tree. As syncs are not done at the same time, the code of
> synced modules may indeed by different for each project depending on
> which commit of oslo-incubator was synced.


Worth noting that there have been a few cases of projects patching
OSLO bugs intheir own tree rather than fixing in OSLO then resyncing.
If anybody has any tooling that can detect that, I'd love to see the
results.

I'm generally of the opinion that cinder is likely to be resistant to
more parts of OSLO being used in cinder unless they are a proper
library - syncs have caused us significant pain, code churn, review
load and bugs in the last 12 months. I am but one voice among many,
but I know I'm not the only member of core who feels this to be the
case. Hopefully I can spend some time with OSLO core at the summit and
discuss the problems I've found.

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


Duncan,

I will come with you for that discussion.  :-)  Have some thoughts and 
questions to share as well.

Regardless, I think we need to make sure to actually get our Oslo syncs 
started for Cinder early
in Juno.  We are way behind on db and db.sqlalchemy.  Planning to propose 
changes to that as soon
as we switch over. 

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

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

[Jay S Bryant]

From:   Brant Knudson 
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
Date:   03/14/2014 02:21 PM
Subject:Re: [openstack-dev] [Oslo] Improving oslo-incubator 
update.py






On Fri, Mar 14, 2014 at 2:05 PM, Jay S Bryant  wrote:

It would be great if we could get the process for this automated.  In the 
mean time, those of us doing the syncs will just have to slog through the 
process. 

Jay



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


What's the process? How do I generate the list of changes?

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


Brant,

My process thus far has been the following:

Do the sync to see what files are changed.
Take a look at the last commit sync'd to what is currently in master for a 
file.
Document all the commits that have come in on that file since.
Repeat process for all the relevant files if there is more than one.
If are multiples files I organize the commits with a list of the files 
touched by that commit.
Document the master level of Oslo when the sync was done for reference.

Process may not be perfect, but it gets the job done.  Here is an example 
of the format I use:  https://review.openstack.org/#/c/75740/

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

Re: [openstack-dev] does exception need localize or not?

[Jay S Bryant]

Doug,

I am glad that this has come up as Mike Perez and I were talking about 
this on Friday and even the documentation that you point to here:  
https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation is not 
clear.  At least, not to me.

Should I interpret that to mean that debug messages should be created 
using LOG.debug and not use _() on the message being sent?  If that is the 
case, there are many places where LOG.debug is using _() on the message 
being passed.  Should we be planning to remove those?  I just want to 
understand what the plan going forward is there, especially given that the 
documentation currently says:  "Debug messages are not translated, for 
now. "

With regards to _LI(), etc.  It appears that this should be used in place 
of LOG.info _("Message").  Should we be enforcing a move from LOG.* to _L* 
in new code that is coming in?

Appreciate your thoughts on the subject!


Jay S. Bryant
   IBM Cinder Subject Matter Expert  &  Cinder Core Member
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Doug Hellmann 
To: Joshua Harlow , 
Cc: "OpenStack Development Mailing List \(not for usage questions\)" 

Date:   03/14/2014 03:54 PM
Subject:Re: [openstack-dev] does exception need localize or not?






On Thu, Mar 13, 2014 at 6:44 PM, Joshua Harlow  
wrote:
From: Doug Hellmann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Thursday, March 13, 2014 at 12:44 PM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] does exception need localize or not?




On Thu, Feb 27, 2014 at 3:45 AM, yongli he  wrote:
refer to :
https://wiki.openstack.org/wiki/Translations

now some exception use _ and some not.  the wiki suggest do not to do 
that. but i'm not sure.

what's the correct way?


F.Y.I 

What To Translate
At present the convention is to translate all user-facing strings. This 
means API messages, CLI responses, documentation, help text, etc.
There has been a lack of consensus about the translation of log messages; 
the current ruling is that while it is not against policy to mark log 
messages for translation if your project feels strongly about it, 
translating log messages is not actively encouraged.

I've updated the wiki to replace that paragraph with a pointer to 
https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation which 
explains the log translation rules. We will be adding the job needed to 
have different log translations during Juno.

 
Exception text should not be marked for translation, becuase if an 
exception occurs there is no guarantee that the translation machinery will 
be functional.

This makes no sense to me. Exceptions should be translated. By far the 
largest number of errors will be presented to users through the API or 
through Horizon (which gets them from the API). We will ensure that the 
translation code does its best to fall back to the original string if the 
translation fails.

Doug

 


Regards
Yongli He


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



I think this question comes up every 3 months, haha ;)

As we continue to expand all the libraries in 
https://github.com/openstack/requirements/blob/master/global-requirements.txt
 and knowing that those libraries likely don't translate there exceptions 
(probably in the majority of cases, especially in non-openstack/oslo 3rd 
party libraries) are we chasing a ideal that can not be caught?

Food for thought,

We can't control what the other projects do, but that doesn't prevent us 
from doing more. 

Doug

 

-Josh
___
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] proposal of definitions/processes for cinder-spec

[Jay S. Bryant]

All,

I have gotten questions from our driver developers asking for details
regarding the move to using cinder-specs for proposing Blueprints.  I
brought this topic up in today's Cinder Weekly Meeting, but the meeting
was lightly attended so we decided to move the discussion here.

I am going to put this note in the form of 'question' and proposed
answer based on the brief discussion we had today.  Note that the
answers here are based on the assumption that we want to keep Cinder's
use of 'specs' as close to Nova's as possible.  I used the following
mailing list thread as a starting point for some of these answers:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/032796.html

Q: When is a spec approved?
A:  When it receives a +2 from the PTL and at least one other Core
reviewer.

Q: How long are specs valid for?
A: For the duration of the release cycle.  Any specs that are not
approved during that period of type will need to be resubmitted for the
subsequent release.

Q: What will the spec template look like?
A: This is one of the points I would like to discuss.  The Nova template
currently looks like this:
https://github.com/openstack/nova-specs/blob/master/specs/template.rst
Do we want to follow the same template.  In the interest of staying in
sync with Nova's implementation I would say yes, but does this meet our
needs?  Are there other/different fields we want to consider to help for
instances where the Blueprint is for a new driver or change to a driver?
I think we might need, for instance, a 'Drivers Impacted' field.

Q: Will driver developers have to use the same template for functions in
their drivers?
A: Also a point I would like to discuss.  Developers had asked if a more
limited template would be used for changes going into the developer's
driver.  At first I thought maybe a different template for Blueprints
against a driver might be appropriate, but after looking more closely at
Nova's template perhaps that is not necessary.  I would lean towards
keeping one template, but maybe not requiring all fields depending on
what our final template ends up looking like.  

Q: Where do specs for python-cinderclient go?
A: Looks like Nova has added a python-novaclient directory.  I don't
think we would need a separate python-cinderclient-specs repository but
don't have a strong opinion on this point.

I am sure this is not an exhaustive list of questions/answers at this
point in time but I wanted to start the discussion so we could help move
this process forward.  I look forward to your feedback.

-Jay Bryant
jsbry...@electronicjungle.net
Freenode:  jungleboyj




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

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

[Jay S. Bryant]

On 09/21/2014 07:37 PM, Matt Riedemann wrote:



On 9/19/2014 8:13 AM, Sean Dague wrote:

I've spent the better part of the last 2 weeks in the Nova bug tracker
to try to turn it into something that doesn't cause people to run away
screaming. I don't remember exactly where we started at open bug count 2
weeks ago (it was north of 1400, with > 200 bugs in new, but it might
have been north of 1600), but as of this email we're at < 1000 open bugs
(I'm counting Fix Committed as closed, even though LP does not), and ~0
new bugs (depending on the time of the day).

== Philosophy in Triaging ==

I'm going to lay out the philosophy of triaging I've had, because this
may also set the tone going forward.

A bug tracker is a tool to help us make a better release. It does not
exist for it's own good, it exists to help. Which means when evaluating
what stays in and what leaves we need to evaluate if any particular
artifact will help us make a better release. But also more importantly
realize that there is a cost for carrying every artifact in the tracker.
Resolving duplicates gets non linearly harder as the number of artifacts
go up. Triaging gets non-linearly hard as the number of artifacts go up.

With this I was being somewhat pragmatic about closing bugs. An old bug
that is just a stacktrace is typically not useful. An old bug that is a
vague sentence that we should refactor a particular module (with no
specifics on the details) is not useful. A bug reported against a very
old version of OpenStack where the code has changed a lot in the
relevant area, and there aren't responses from the author, is not
useful. Not useful bugs just add debt, and we should get rid of them.
That makes the chance of pulling a random bug off the tracker something
that you could actually look at fixing, instead of mostly just 
stalling out.


So I closed a lot of stuff as Invalid / Opinion that fell into those 
camps.


== Keeping New Bugs at close to 0 ==

After driving the bugs in the New state down to zero last week, I found
it's actually pretty easy to keep it at 0.

We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20%
aren't actually a bug, and can be closed immediately. ~30% look like a
bug, but don't have anywhere near enough information in them, and
flipping them to incomplete with questions quickly means we have a real
chance of getting the right info. ~10% are fixable in < 30 minutes worth
of work. And the rest are real bugs, that seem to have enough to dive
into it, and can be triaged into Confirmed, set a priority, and add the
appropriate tags for the area.

But, more importantly, this means we can filter bug quality on the way
in. And we can also encourage bug reporters that are giving us good
stuff, or even easy stuff, as we respond quickly.

Recommendation #1: we adopt a 0 new bugs policy to keep this from
getting away from us in the future.

== Our worse bug reporters are often core reviewers ==

I'm going to pick on Dan Prince here, mostly because I have a recent
concrete example, however in triaging the bug queue much of the core
team is to blame (including myself).

https://bugs.launchpad.net/nova/+bug/1368773 is a terrible bug. Also, it
was set incomplete and no response. I'm almost 100% sure it's a dupe of
the multiprocess bug we've been tracking down but it's so terse that you
can't get to the bottom of it.

There were a ton of 2012 nova bugs that were basically "post it notes".
Oh, "we should refactor this function". Full stop. While those are fine
for personal tracking, their value goes to zero probably 3 months after
they are files, especially if the reporter stops working on the issue at
hand. Nova has plenty of "wouldn't it be great if we... " ideas. I'm not
convinced using bugs for those is useful unless we go and close them out
aggressively if they stall.

Also, if Nova core can't file a good bug, it's hard to set the example
for others in our community.

Recommendation #2: hey, Nova core, lets be better about filing the kinds
of bugs we want to see! mkay!

Recommendation #3: Let's create a tag for "personal work items" or
something for these class of TODOs people are leaving themselves that
make them a ton easier to cull later when they stall and no one else has
enough context to pick them up.

== Tags ==

The aggressive tagging that Tracy brought into the project has been
awesome. It definitely helps slice out into better functional areas.
Here is the top of our current official tag list (and bug count):

95 compute
83 libvirt
74 api
68 vmware
67 network
41 db
40 testing
40 volumes
36 ec2
35 icehouse-backport-potential
32 low-hanging-fruit
31 xenserver
25 ironic
23 hyper-v
16 cells
14 scheduler
12 baremetal
9 ceph
9 security
8 oslo
...

So, good stuff. However I think we probably want to take a further step
and attempt to get champions for tags. So that tag owners would ensure
their bug list looks sane, and actually spend some time fixing them.
It's pretty clear, for instance, that the e

Re: [openstack-dev] [cinder] Not seeking another term as PTL

[Jay S. Bryant]

John,

Thank you for being welcoming to me when I started with Cinder during 
Havana and for all the mentoring and encouragement you have given since 
then.


I think the fact that Cinder is such a great group to work with has a 
lot to owe to your leadership and guidance.  Thank you!


I look forward to continuing to work with you.

Jay

On 09/23/2014 09:57 AM, John Griffith wrote:

Hey Everyone,

I've been kinda mixed on this one, but I think it's a good time for me 
to not run for Cinder PTL.  I've been filling the role since we 
started the idea back at the Folsom Summit, and it's been an absolute 
pleasure and honor for me.


I don't plan on going anywhere and will still be involved as I am 
today, but hopefully I'll also now have a good opportunity to 
contribute elsewhere in OpenStack.  We have a couple of good 
candidates running for Cinder PTL as well as a strong team backing the 
project so I think it's a good time to let somebody else take the 
official PTL role for a bit.


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

Re: [openstack-dev] [oslo] adding James Carey to oslo-i18n-core

[Jay S. Bryant]

On 09/26/2014 06:46 PM, Matt Riedemann wrote:



On 9/25/2014 11:04 AM, Ben Nemec wrote:

+1.  He's on the short list of people who actually understand how all
that lazy translation stuff works. :-)

-Ben

On 09/23/2014 04:03 PM, Doug Hellmann wrote:
James Carey (jecarey) from IBM has done the 3rd most reviews of 
oslo.i18n this cycle [1]. His feedback has been useful, and I think 
he would be a good addition to the team for maintaining oslo.i18n.


Let me know what you think, please.

Doug

[1] http://stackalytics.com/?module=oslo.i18n
___
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



I'm not part of the core team but agree with Ben here.  Jim is my 
go-to guy on the i18n stuff, which I'm sure delights him whenever I 
have issues. :)


I second Matt's note!  I hadn't voted since I am not a core member. Jim 
was my partner in crime on the i18n stuff in Icehouse and has done a lot 
of good work in Juno.  I am so thankful for his knowledge and help!


So, a big +2 from me.  :-)



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

Re: [openstack-dev] [Horizon] [All?] "Status" vs "State"

[Jay S. Bryant]

Good questions!

Jay, I have a request for some clarification in-line.


On 10/01/2014 01:37 PM, Jay Pipes wrote:

Hi Akihiro!

IMO, this is precisely where having an API standards working group can 
help to make the user experience of our public APIs less frustrating. 
Such a working group should have the ability to vet terms like "state" 
vs "status" and ensure consistency across the public APIs.


More thoughts inline :)

On 10/01/2014 11:24 AM, Akihiro Motoki wrote:

Hi,

# The first half is related to Horizon and the latter half is about
the wording in Nova and Neutron API.

During Horizon translation for Juno, I noticed the words "State" and
"Status" in multiple contexts. Sometimes they are in very similar
contexts and sometimes they have different contexts.

I would like to know what are the difference between  "Status" and
"State", and if the current usage is right or not, whether we can
reword them. Input from native speakers would be really appreciated.

I see three usages.

(1) "Status" to show operational status (e.g. 
Up/Down/Active/Error/Build/...)

(2) "Status" to show administrative status (e.g. Enabled/Disabled/...)
(3) "State" to show operational state (e.g., Up/Down/)

Note that (2) and (3) are shown in a same table (for example Compute
Host table in Hypervisor summary). Also (1) and (3) (e.g., task state
in nova) are used in a same table (for example, the instance table).

"Status" in (1) and (2) have different meaning to me, so at least
we need to add some contextual note ("contextual marker" in I18N term)
so that translators can distinguish (1) and (2).

Related to this, I check Nova and Neutron API, and
I don't see a clear usage of these words.

In Nova API, "Status" and "Task State"/"Power State" in instance list
  are both used to show current operational information ("state" is a
bit more detail
information compared to "Status"). On the other hand, in service lits
"Status" is used to show a current administrative status
(Enabled/Disabled) and "State" is used to show current operational
information like Up/Down.

In Neutron API, both "State" (admin_state_up)  and "Status" are
usually used in Neutron resources (networks, ports, routers, and so
on), but it seems the meaning of "State" and "Status" are reversed
from the meaning of Nova service list above.

I am really confused what is the right usage of these words


OK, so here are the definitions of these terms in English (at least, 
the relevant definition as used in the APIs...):


state: the particular condition that someone or something is in at a 
specific time.


example: "the state of the company's finances"

status: the position of affairs at a particular time, especially in 
political or commercial contexts.


example: "an update on the status of the bill"

Note that "state" is listed as a synonym for "status", but "status" is 
*not* listed as a synonym for "state", which is why there is so much 
frustrating vagueness and confusing duplicity around the terms.


IMO, the term "state" should be the only one used in the OpenStack 
APIs to refer to the condition of some thing at a point in time. The 
term "state" can and should be prefaced with a refining descriptor 
such "task" or "power" to denote the *thing* that the state represents 
a condition for.


As I re-read this I think maybe you have answered my question but want 
to be clear.  You feel that 'State' is the only term that should be 
used.  Based on the definitions above, that would make sense.  The 
complication is there are may places in the code where a variable like 
'status' is used.  Don't think we are going to be able to go back and 
fix all those, but it would be something that is good to watch for in 
reviews in the future.
One direct change I would make would be that Neutron's 
"admin_state_up" field would be instead "admin_state" with values of 
UP, DOWN (and maybe UNKNOWN?) instead of having the *same* GET 
/networks/{network_id} call return *both* a boolean "admin_state_up" 
field *and* a "status" field with a string value like "ACTIVE". :(


Another thing that drives me crazy is the various things that 
represent enabled or disabled.


Throughout the APIs, we use, variably:

 * A field called disabled or enabled (Nova flavor-disabled API 
extension with the "OS-FLV-DISABLED:disabled" attribute, Ceilometer 
alarms, Keystone domains, users and projects but not groups or 
credentials)
 * enable_XXX or disable_XXX (for example, in Neutron's GET 
/subnets/{subnet_id} response, there is an enable_dhcp field. In 
Heat's GET /stacks/{stack_id} response, there is a disable_rollback 
field. We should be consistent in using either the word enable or the 
word disable (not both terms) and the tense of the verb should at the 
very least be consistent (disabled vs. disable))
 * status:disabled (Nova os-services API extension. The service 
records have a status field with "disabled" or "enabled" string in it. 
Gotta love it.)


Yet another thing to tack on th

Re: [openstack-dev] [Horizon] [All?] "Status" vs "State"

[Jay S. Bryant]

On 10/02/2014 11:14 AM, Jay Pipes wrote:

On 10/02/2014 11:23 AM, Jay S. Bryant wrote:

As I re-read this I think maybe you have answered my question but want
to be clear.  You feel that 'State' is the only term that should be
used.  Based on the definitions above, that would make sense. The
complication is there are may places in the code where a variable like
'status' is used.  Don't think we are going to be able to go back and
fix all those, but it would be something that is good to watch for in
reviews in the future.


I'm talking about new versions of the public APIs that get proposed, 
not existing ones. Within the codebase, it would be great to use a 
single term "state" for this, prefixed with a refining descriptor like 
"power_", "task_", etc. But that's a lesser concern for me than our 
next generation REST APIs.


Best,
-anotherjay

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

Thanks for the clarification.  I think the proposal is a good idea.

-theotherjay

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

Re: [openstack-dev] [oslo] The right (and the wrong) way of handling module imports in oslo-incubator

[Jay S. Bryant]

On 11/14/2014 03:31 AM, Ihar Hrachyshka wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14/11/14 09:14, Flavio Percoco wrote:

On 13/11/14 23:25 +, Amrith Kumar wrote:

At the suggestion of Doug Hellmann, and relative to a
conversation with him and Flavio at Summit. Doug suggested that I
pose this question on the dev mailing list so someone from OSLO
can communicate the answer to the entire community (rather than
just the private email exchange that we had).



Here’s the situation, I’m using loopingcall.py as an example,
this is not limited to this module but serves as an example.



An OSLO incubator module loopingcall depends on another OSLO
incubator module timeutils.



timeutils has graduated [drum-roll] and is now part of
oslo.utils.



There is also other project code that references timeutils.



So, to handle the graduation of timeutils, the changes I’ll be
making are:



1.  Remove timeutils from openstack-common.conf

2.  Make the project code reference oslo.utils



But what of loopingcall? Should I



a.  Update it and change the import(s) therein to point to
oslo.utils, or

b.  Sync the oslo-incubator code for loopingcall, picking up all
changes at least upto and including the change in oslo-incubator
that handles the graduation of oslo.utils.



In speaking with Doug and Flavio, (after I submitted copious
amounts of code that did (a)) above, I’ve come to learn that I
chose the wrong answer. The correct answer is (b). This doesn’t
have to be part of the same commit, and what I’ve ended up doing
is this …



c.  Leave timeutils in /openstack/common and let
oslo-incubator depend on it while migrating the project to use
oslo.utils. In a subsequent commit, a sync from oslo-incubator
can happen.



I’d like someone on OSLO to confirm this, and for other projects
whose lead I followed, you may want to address these in the
changes you have in flight or have already merged.


`b` is the right answer there. As a general rule - probably the
easiest way to solve the above dilema - people should *never*
modify incubator modules in the project. Sticking to this rule
will automatically answer the question of how to update, maintain
and consume code from oslo-incubator.

Crazy idea: we should have a bot that -1's all the patches that modify
oslo-incubator code without being marked by some special tag
(OsloSync?). We've slipped several local modifications to those files
before (I know two cases in Neutron, though I hardly monitor all the
patch queue).
We had this problem a lot in Cinder in the past.  With education and 
monitoring from the Cores we have been able to avoid it.  The idea of 
monitoring for such commits is a good idea.  I wonder, however, if there 
is a way to do it with a hacking check?





If there are projects that picked `a` as the right answer, please,
update your patches and follow the already well defined workflow
for oslo-incubator. Doing otherwise will just make things harder
for us who maintain oslo, for stable maintenance and for your own
contributors.

Amrith, thanks for bringing this up and for updating your patches,
I know it's a pain and I appreciate your collaboration there.

Cheers, Flavio

P.S: Gentle note. Oslo is not an acronym.



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


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUZcwOAAoJEC5aWaUY1u5741wH/2B/Pf56YtAaru7jAR9bN7IZ
KNY2zkGIDNMZQJWz3DxW7R0myKdmHVqrM/wA+8Lkf0l/ITh1LtiXtRxx5E2sPnJP
jef3ODTESooOKGcGOxvKO8tt/Bl4EorJzkX70dyJzlV7fKfZuwCFpZCp73S7npBh
BYd5Dfhi+pTyIZvtWSYKJzloJ/BasvKM+pwvlVsV9JIwMNrwwaLx2yDh+D3fltEg
bROJooq5J6z/pN19bZ5UkFU2z9lHNI6K6pa1eWLqQdm8WJnNmfmJjiX+vO2wp1z5
7qDsKL/dbHzXfPrBX8MqO9SEvt/jrDS8TeA2tMgAZg8+F5ST1dVHFGxWXJ4eoF4=
=2v6F
-END PGP SIGNATURE-

___
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] [stable] New config options, no default change

[Jay S. Bryant]

All,

This is a question I have been struggling with for Cinder recently. 
Where do we draw the line on backports.  How do we handle config changes?


One thing for Cinder I am also considering, in addition to whether it 
changes the default functionality, is whether it is specific to the 
submitter's driver.  If it is only going to affect the driver I am more 
likely to consider it than something that is going to impact all of Cinder.


What is the text that should be included in the commit messages to make 
sure that it is picked up for release notes?  I want to make sure that 
people use that.


Thanks!
Jay


On 11/11/2014 06:50 AM, Alan Pevec wrote:

New config options may not change behavior (if default value preserves
behavior), they still make documentation more incomplete (doc, books,
and/or blogposts about Juno won't mention that option).

That's why we definitely need such changes described clearly in stable
release notes.
I also lean to accept this as an exception for stable/juno, I'll
request relnote text in the review.

Cheers,
Alan

___
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] Anyone Using the Open Solaris ZFS Driver?

[Jay S. Bryant]

Drew,

I would say that it would be good to open a Blueprint for this and push 
the code up for review.  Even if you don't have CI ready yet you can 
post results of a driver cert test [1] and we can start reviewing the 
code while you work on finishing up the process of getting your CI running.


Look forward to seeing you code.

Jay

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

On 11/16/2014 11:08 PM, Drew Fisher wrote:

We (here at Oracle) have a replacement for this driver which includes
local ZFS, iSCSI and FC drivers all with ZFS as the underlying driver.
We're in the process of getting CI set up so we can contribute the
driver upstream along with our ZFSSA driver (which is already in the tree).

If anybody has more questions about this, please let me know.  The
driver is in the open for folks to look at and if anybody wants us to
start upstream integration for it, we'll be happy to do so.

-Drew


On 11/16/14, 8:45 PM, Mike Perez wrote:

The Open Solaris ZFS driver [1] is currently missing a lot of the minimum
features [2] that the Cinder team requires with all drivers. As a result, it's
really broken.

I wanted to gauge who is using it, and if anyone was interested in fixing the
driver. If there is not any activity with this driver, I would like to propose
it to be deprecated for removal.

[1] - 
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py
[2] - 
http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features


___
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] Log / error message format best practices & standards

[Jay S. Bryant]

Boden,

Thanks for bringing this up:

On Thu, 2014-06-26 at 12:14 -0400, boden wrote:
> We were recently having a discussion over here in trove regarding a 
> standardized format to use for log and error messages - obviously 
> consistency is ideal (within and across projects). As this discussion 
> involves the broader dev community, bringing this topic to the list for 
> feedback...
> 
> 
> I'm aware of the logging standards wiki[1], however this page does not 
> describe in depth a standardized format to use for log / error messages.
> 
> In particular w/r/t program values in messages:
> 
> (a) For in-line program values, I've seen both single quoted and 
> unquoted formatting used. e.g.
> single quote: LOG.info("The ID '%s' is not invalid." % (resource.id))

+1  This isn't one I have been policing a lot in my reviews, but think
this is a good practice.

> unquoted: LOG.info("The ID %s is not valid." % (resource.id))
> 
> (b) For program values appended to the message, I've seen various 
> formats used. e.g.
> LOG.info("This path is invalid: %s" % (obj.path))

+1 This is one I have been enforcing in Cinder reviews.

If I had documentation to point to for such things I think it would be
good to reference in the reviews.

> LOG.info("This path is invalid %s" % (obj.path))
> LOG.info("This path is invalid - %s" % (obj.path))
> 
> 
>  From a consistency perspective, it seems we should consider 
> standardizing a best practice for such formatting.
> 
> For in-line values (#a above) I find single quotes the most consumable 
> as they are a clear indication the value came from code and moreover 
> provide a clear set of delimiters around the value. However to date 
> unquoted appears to be the most widely used.
> 
> For appended values (#b above) I find a delimiter such as ':' most 
> consumable as it provides a clear boundary between the message and 
> value. Using ':' seems fairly common today, but you'll find other 
> formatting throughout the code.
> 
> If we wanted to squash this topic the high level steps are (approximately):
> - Determine and document message format.
> - Ensure the format is part of the dev process (coding + review).
> - Cross team work to address existing messages not following the format.
> 
> 
> Thoughts / comments?
> 
> 
> [1] https://wiki.openstack.org/wiki/LoggingStandards
> 
> 
> 
> ___
> 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] [all][specs] Please stop doing specs for any changes in projects

[Jay S. Bryant]

John,

So you have said a few times that the specs are a learning process.
What do you feel with have learned thus far using specs?  I think you
had the hope that it would help organize targeting blueprints and not
missing things for a release.  Do you feel that is working?

I would like to hear more about how you feel this is working.

Personally, initially, having specs made sense given that they are a
better way to spark discussion around a design change.  They were
working well early in the release for that purpose.

Now, however, they have become a point of confusion.  There is the
question of "when is just a BP sufficient" versus when is neither
required.

I think this is part of the learning process.  Just worth having
discussion so we know for the next round what is needed when.

Jay

On Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote:
> 
> 
> 
> 
> On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews
>  wrote:
> 
> On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant
>  wrote:
> I had been under the impression that all BPs we going
> to require a spec.  I, however,  was made are in
> today's cinder meeting that we are only requiring
> specs for changes that change the user's interaction
> with the system or are a large change that touches the
> broader cinder code base.
> 
> That's generally where we use blueprints in Keystone, anyway.
> If the change has no impact on end users, deployers or other
> projects, then it doesn't need a spec/blueprint. For example,
> a refactor only affects developers of Keystone, so I'd argue
> that blueprints are unnecessary.
> 
> 
> 
> The premise of a "large change that touches the broader ...
> code base" requiring a blueprint is flawed though - we don't
> want to review large changes anyway ;)
> 
> 
> ​Just have to say I really like this last point... also even though
> I'm the one who made that statement the problem with it is that it's
> rather subjective.  
> 
> 
> My position is and continues to be that specs are a learning process,
> we're hammering it out and these conversations on the ML are helpful.​
> This seemsto make sense to me.  The user's commit
> message and unit tests should show the thought of the
> changes impact. 
> 
> Jay
> 
> On Jul 9, 2014 7:57 AM, "Dugger, Donald D"
>  wrote:
> Much as I dislike the overhead and the extra
> latency involved (now you need to have a
> review cycle for the spec plus the review
> cycle for the patch itself) I agreed with the
> `small features require small specs’.  The
> problem is that even a small change can have a
> big impact.  Forcing people to create a spec
> even for small features means that it’s very
> clear that the implications of the feature
> have been thought about and addressed.
> 
>  
> 
> Note that there is a similar issue with bugs.
>  I would expect that a patch to fix a bug
> would have to have a corresponding bug report.
> Just accepting patches with no known
> justification seems like the wrong way to go.
> 
>  
> 
> --
> 
> Don Dugger
> 
> "Censeo Toto nos in Kansa esse decisse." - D.
> Gale
> 
> Ph: 303/443-3786
> 
>  
> 
> From: Dolph Mathews
> [mailto:dolph.math...@gmail.com] 
> Sent: Tuesday, July 1, 2014 11:02 AM
> To: OpenStack Development Mailing List (not
> for usage questions)
> Subject: Re: [openstack-dev] [all][specs]
> Please stop doing specs for any changes in
> projects
> 
>  
> 
> The argument has been made in the past that
> small features will require correspondingly
> small specs. If there's a counter-argument to
> this example (a 

Re: [openstack-dev] [infra] "recheck no bug" and comment

[Jay S. Bryant]

I agree that there are cases where a bug is overkill and it would be
nice to add a note showing I did put some thought into doing the recheck
no bug.  Just my two cents.

On Wed, 2014-07-16 at 17:07 +0100, Derek Higgins wrote:
> On 16/07/14 14:48, Steve Martinelli wrote:
> > What are the benefits of doing this over looking at the existing
> > rechecks, and if not there opening a bug and rechecking the new bug?
> 
> I agree we should be using a bug number (or open one when needed), the
> example in the original email should have included a bug number but now
> that the topic has come up
> 
> I think this would serve as a good way to provide a little explanation
> as to why somebody has not provided a bug number e.g.
> 
> recheck no bug
>zuul was restarted
> 
> Derek
> 
> > 
> > 
> > Regards,
> > 
> > *Steve Martinelli*
> > Software Developer - Openstack
> > Keystone Core Member
> > 
> > *Phone:*1-905-413-2851*
> > E-mail:*_steve...@ca.ibm.com_   
> > 8200 Warden Ave
> > Markham, ON L6G 1C7
> > Canada
> > 
> > 
> > 
> > 
> > 
> > 
> > From:Alexis Lee 
> > To:"OpenStack Development Mailing List (not for usage
> > questions)" ,
> > Date:07/16/2014 09:19 AM
> > Subject:[openstack-dev]  [infra] "recheck no bug" and comment
> > 
> > 
> > 
> > 
> > Hello,
> > 
> > What do you think about allowing some text after the words "recheck no
> > bug"? EG to include a snippet from the log showing the failure has been
> > at least briefly investigated before attempting a recheck. EG:
> > 
> >  recheck no bug
> > 
> >  Compute node failed to spawn:
> > 
> >2014-07-15 12:18:09.936 | 3f1e7f32-812e-48c8-a83c-2615c4451fa6 |
> >  overcloud-NovaCompute0-zahdxwar7zlh | ERROR  | - | NOSTATE | |
> > 
> > 
> > Alexis
> > -- 
> > Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
> > 
> > ___
> > 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

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

[Jay S. Bryant]

Thanks Duncan and also Dolph, I should have made the question
broader.  :-)

On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:
> On 16 July 2014 03:57, Jay S. Bryant  wrote:
> > John,
> >
> > So you have said a few times that the specs are a learning process.
> > What do you feel with have learned thus far using specs?
> 
> I'm not John, but I'm going to answer as if you'd addressed the question 
> wider:
> - Specs can definitely help flesh out ideas and are much better than
> blueprints as a way of tracking concerns, questions, etc
> 

I feel I have better knowledge of what is being worked thanks to the
specs.  This may partially be because I was also involved from the
summit on for the first time.  They definitely are better for fleshing
out ideas and discussing concerns.

> - We as a community are rather shy about making decisions as
> individuals, even low risk ones like 'Does this seem to require a
> spec' - if there doesn't seem to be value in a spec, don't do one
> unless somebody asks for one

Agreed.  I think we all need to be less shy about making decisions and
voicing them.  At least in Cinder.  :-)

> 
> - Not all questions can be answered at spec time, sometimes you need
> to go bash out some code to see what works, then circle again
> 
> - Careful planning reduces velocity. No significant evidence either
> way as to whether it improves quality, but my gut feeling is that it
> does. We need to figure out what tradeoffs on either scale we're happy
> to make, and perhaps that answer is different based on the area of
> code being touched and the date (e.g. a change that doesn't affect
> external APIs in J-1 might need less careful planning than a change in
> J-3. API changes or additions need more discussion and eyes on than
> none-API changes)

I think, through this development cycle we are starting to narrow down
what really needs a spec.  I think it would be good to perhaps have a
Lessons Learned session at the K summit on the specs and try to better
define expectations for use in the future.  I feel it has slowed, or at
least focused development.  That has been good.

> 
> - Specs are terrible for tracking work items, but no worse than blueprints
> 
Agreed.
> - Multiple people might choose to work on the same blueprint in
> parallel - this is going to happen, isn't necessarily rude and the
> correct solution to competing patches is entirely subjective



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

Re: [openstack-dev] [cinder] gettextutils enable_lazy not working

[Jay S. Bryant]

Mike,

Thanks for pointing this out.  I thought I had gotten all of these and
this supports the need for the hacking check I will work on.

We also hit errors like this on our internal CI due to a bad merge.

Anyway, I am on top of this.  Will fix asap.

Jay

On Sun, 2014-07-20 at 15:49 -0700, Mike Perez wrote:
> Recent change to how we use gettextutils [1] seem to not import _
> anymore. According to the commit, enable_lazy() is suppose to
> *replace* gettextutils.install(), but I can't see where in the code
> that happens or see it actually working.
> 
> I have reported a bug [2] that cinder-manage and cinder-rtstool [3] no
> longer work as a result. Using gettextutils.install() seems to resolve
> the issue or explicitly import _. Can someone who is familiar with
> this module please enlighten me how this is suppose to work?
> 
> [1] - https://review.openstack.org/#/c/105561/4
> [2] - https://bugs.launchpad.net/cinder/+bug/1345789
> [3] - https://bugs.launchpad.net/cinder/+bug/1345789/comments/4
> 
> --
> Mike Perez



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

Re: [openstack-dev] [cinder][nova] cinder querying nova-api

[Jay S. Bryant]

Abbass,

There has been discussion around this in the past.

As it would be a significant feature you should open a spec for it.  Do
a 'git clone https://github.com/openstack/cinder-specs.

There are directions in there for actually submitting the spec.

Thanks!
Jay

On Fri, 2014-07-18 at 09:01 +0200, Abbass MAROUNI wrote:
> Thanks Thomas,
> 
> By cinder spec. you mean a cinder blueprint ?
> Where I can submit such a proposition ?
> 
> Thanks,
> 
> On 07/17/2014 05:20 PM, openstack-dev-requ...@lists.openstack.org wrote:
> > You're far from the only person trying to achieve that result, there's
> > plenty of interest in it, and a few approaches being suggested.
> >
> > I can't see a current cinder spec open for this, so it might be worth
> > you starting one, you're more likely to get detailed feedback about
> > the pitfalls there.
> 
> ___
> 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] Integrated with iSCSI target Question

[Jay S. Bryant]

Johnson,

I am not sure what you mean by 'attach volume manually'.  Do you mean
when you do a 'nova volume-attach'?  If so, then, yes, the process will
use the appropriate iscsi_helper and iscsi_ip_address to configure the
attachment.

Does that answer your question?

Jay

On Mon, 2014-07-21 at 12:23 +, Johnson Cheng wrote:
> Dear Thomas,
> 
> Thanks for your reply.
> So when I attach volume manually, will iSCSI LUN be automatically setup via 
> cinder.conf (iscsi_helper and iscsi_ip_address)?
> 
> 
> Regards,
> Johnson
> 
> -Original Message-
> From: Duncan Thomas [mailto:duncan.tho...@gmail.com] 
> Sent: Monday, July 21, 2014 6:16 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question
> 
> The iSCSI lun won't be set up until you try to attach the volume
> 
> On 17 July 2014 12:44, Johnson Cheng  wrote:
> > Dear All,
> >
> >
> >
> > I installed iSCSI target at my controller node (IP: 192.168.106.20),
> >
> > #>iscsitarget open-iscsi iscsitarget-dkms
> >
> >
> >
> > then modify my cinder.conf at controller node as below,
> >
> > [DEFAULT]
> >
> > rootwrap_config = /etc/cinder/rootwrap.conf
> >
> > api_paste_confg = /etc/cinder/api-paste.ini
> >
> > #iscsi_helper = tgtadm
> >
> > iscsi_helper = ietadm
> >
> > volume_name_template = volume-%s
> >
> > volume_group = cinder-volumes
> >
> > verbose = True
> >
> > auth_strategy = keystone
> >
> > #state_path = /var/lib/cinder
> >
> > #lock_path = /var/lock/cinder
> >
> > #volumes_dir = /var/lib/cinder/volumes
> >
> > iscsi_ip_address=192.168.106.20
> >
> >
> >
> > rpc_backend = cinder.openstack.common.rpc.impl_kombu
> >
> > rabbit_host = controller
> >
> > rabbit_port = 5672
> >
> > rabbit_userid = guest
> >
> > rabbit_password = demo
> >
> >
> >
> > glance_host = controller
> >
> >
> >
> > enabled_backends=lvmdriver-1,lvmdriver-2
> >
> > [lvmdriver-1]
> >
> > volume_group=cinder-volumes-1
> >
> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
> >
> > volume_backend_name=LVM_iSCSI
> >
> > [lvmdriver-2]
> >
> > volume_group=cinder-volumes-2
> >
> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
> >
> > volume_backend_name=LVM_iSCSI_b
> >
> > [database]
> >
> > connection = mysql://cinder:demo@controller/cinder
> >
> >
> >
> > [keystone_authtoken]
> >
> > auth_uri = http://controller:5000
> >
> > auth_host = controller
> >
> > auth_port = 35357
> >
> > auth_protocol = http
> >
> > admin_tenant_name = service
> >
> > admin_user = cinder
> >
> > admin_password = demo
> >
> >
> >
> > Now I use the following command to create a cinder volume, and it can 
> > be created successfully.
> >
> > #> cinder create --volume-type lvm_controller --display-name vol 1
> >
> >
> >
> > Unfortunately it seems not attach to a iSCSI LUN automatically because 
> > I can not discover it from iSCSI initiator,
> >
> > #> iscsiadm -m discovery -t st -p 192.168.106.20
> >
> >
> >
> > Do I miss something?
> >
> >
> >
> >
> >
> > Regards,
> >
> > Johnson
> >
> >
> >
> >
> >
> > From: Manickam, Kanagaraj [mailto:kanagaraj.manic...@hp.com]
> > Sent: Thursday, July 17, 2014 1:19 PM
> >
> >
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target 
> > Question
> >
> >
> >
> > I think, It should be on the cinder node which is usually deployed on 
> > the controller node
> >
> >
> >
> > From: Johnson Cheng [mailto:johnson.ch...@qsantechnology.com]
> > Sent: Thursday, July 17, 2014 10:38 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [Cinder] Integrated with iSCSI target 
> > Question
> >
> >
> >
> > Dear All,
> >
> >
> >
> > I have three nodes, a controller node and two compute nodes(volume node).
> >
> > The default value for iscsi_helper in cinder.conf is “tgtadm”, I will 
> > change to “ietadm” to integrate with iSCSI target.
> >
> > Unfortunately I am not sure that iscsitarget should be installed at 
> > controller node or compute node?
> >
> > Have any reference?
> >
> >
> >
> >
> >
> > Regards,
> >
> > Johnson
> >
> >
> >
> >
> > ___
> > 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] Mentor program?

[Jay S. Bryant]

Josh,

I agree that the mailing list is a hard place to provide such guidance
and direction.  I find mailing lists intimidating.  Had taken me some
time to be comfortable submitting here.

After my response to this note the other day I was pinged internally via
our messaging client asking for some mentoring.  They seemed more
comfortable introducing themselves that way and talking.  I hate to
suggest an IRC channel for this, as IRC drives me nuts, also doesn't
seem the best fit.  Maybe instead a wiki page with IRC names of people
that are willing to be individually contacted with requests for
guidance.  I could be listed as a contact for Cinder or i18n as well as
a general process contact.  You for taskflow, etc.

I guess a way to communicate what we feel we can help with and provide
that as a resource for those who may need help in those areas.  Also, on
the same wiki maybe try to cull together some of the 'getting started
info.  

What do you think?

Jay

On Wed, 2014-07-23 at 15:42 -0700, Joshua Harlow wrote:
> Awesome,
> 
> 
> When I start to see emails on ML that say anyone need any help for
> XYZ ... (which is great btw) it makes me feel like there should be a
> more appropriate avenue for those inspirational folks looking to get
> involved (a ML isn't really the best place for this kind of guidance
> and directing). 
> 
> 
> And in general mentoring will help all involved if we all do more of
> it :-)
> 
> 
> Let me know if any thing is needed that I can possible help with to
> get more of it going.
> 
> 
> -Josh
> 
> On Jul 23, 2014, at 2:44 PM, Jay Bryant
>  wrote:
> 
> > Great question Josh!
> > 
> > Have been doing a lot of mentoring within IBM for OpenStack and have
> > now been asked to formalize some of that work.  Not surprised there
> > is an external need as well.
> > 
> > Anne and Stefano.  Let me know if the kids anything I can do to
> > help.
> > 
> > Jay
> > 
> > Hi all,
> > 
> > I was reading over a IMHO insightful hacker news thread last night:
> > 
> > https://news.ycombinator.com/item?id=8068547
> > 
> > Labeled/titled: 'I made a patch for Mozilla, and you can do it too'
> > 
> > It made me wonder what kind of mentoring support are we as a
> > community offering to newbies (a random google search for 'openstack
> > mentoring' shows mentors for GSoC, mentors for interns, outreach for
> > women... but no mention of mentors as a way for everyone to get
> > involved)?
> > 
> > Looking at the comments in that hacker news thread, the article
> > itself it seems like mentoring is stressed over and over as the way
> > to get involved.
> > 
> > Has there been ongoing efforts to establish such a program (I know
> > there is training work that has been worked on, but that's not
> > exactly the same).
> > 
> > Thoughts, comments...?
> > 
> > -Josh
> > ___
> > 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] [openstack-tc] Proposal to recognize indirect contributions to our code base

[Jay S Bryant]

Mark,

Well stated.  I think it is important that OpenStack continue to be 
focussed on individuals contributing to the community and not 
corporations.

There are plenty of metrics already being compiled using e-mail addresses. 
 In fact, I think the visibility of 'sponsors' is already available as a 
result through websites like Stackalytics (http://stackalytics.com/) . 
Highlighting the sponsors of individual commits seems unnecessary.

That's my two cents.


Jay S. Bryant
Linux Developer - 
OpenStack Enterprise Edition
   
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Mark McLoughlin 
To: Nicolas Barcet , 
Cc: OpenStack Development Mailing List 
, openstack...@lists.openstack.org, 
Boris Renski , Tristan Goode 
Date:   11/11/2013 09:58 AM
Subject:Re: [openstack-dev] [openstack-tc] Proposal to recognize 
indirect contributions to our code base



Hi Nick,

On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
> Dear TC members,
> 
> Our companies are actively encouraging our respective customers to have 
the
> patches they mission us to make be contributed back upstream.  In order 
to
> encourage this behavior from them and others, it would be nice that if
> could gain some visibility as "sponsors" of the patches in the same way 
we
> get visibility as "authors" of the patches today.
> 
> The goal here is not to provide yet another way to count affiliations of
> direct contributors, nor is it a way to introduce sales pitches in 
contrib.
>  The only acceptable and appropriate use of the proposal we are making 
is
> to signal when a patch made by a contributor for another comany than the
> one he is currently employed by.
> 
> For example if I work for a company A and write a patch as part of an
> engagement with company B, I would signal that Company B is the sponsor 
of
> my patch this way, not Company A.  Company B would under current
> circumstances not get any credit for their indirect contribution to our
> code base, while I think it is our intent to encourage them to 
contribute,
> even indirectly.
> 
> To enable this, we are proposing that the commit text of a patch may
> include a
>sponsored-by: 
> line which could be used by various tools to report on these commits.
>  Sponsored-by should not be used to report on the name of the company 
the
> contributor is already affiliated to.

Honestly, I've an immediately negative reaction to the prospect of e.g.

  Sponsored-By: Red Hat
  Sponsored-By: IBM

appearing in our commit messages.

I feel strongly that the project is first and foremost a community of
individuals and we instinctively push as much of corporate backing side
of things outside of the project. We try to spend as little time as
possible talking about our affiliations as possible.

And, IMHO, the git commit log is particularly sacred ground - almost
above anything else, it is a place for purely technical details.

However, I do think we'll be able to figure out some way of making it
easier for tools to track more complex affiliations.

Our affiliation databases are all keyed off email addresses right now,
so how about if we allowed for encoding affiliation/sponsorship in
addresses? e.g.

  Author: Mark McLoughlin 

and we could register that address as "work done by Mark on behalf of
IBM" ?

Mark.


___
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] [qa] Policy on spelling and grammar

[Jay S Bryant]

+2 to Clint's comments.

As OpenStack gains a wider following in the corporate world and given that 
the code for OpenStack may be seen by anyone, I think it is very important 
to get spelling and grammar right.  I also think it is important to ensure 
that the commit messages concisely communicate the change that is being 
made.

I regularly comment on misspellings and in the case that a commit message 
is difficult to understand provide suggestions for rewording to make sure 
I understand what is being communicated.

So, I think -1's are fine as long is assistance is being provided.

The point of OpenStack is to have a collaborative community.  Some people 
bring better spelling and grammar to the table than others as a 
contribution.



Jay S. Bryant
Linux Developer - 
OpenStack Enterprise Edition
   
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Clint Byrum 
To: openstack-dev , 
Date:   11/11/2013 12:21 PM
Subject:Re: [openstack-dev] [qa] Policy on spelling and grammar



Excerpts from David Kranz's message of 2013-11-11 09:58:59 -0800:
> I have seen a wide variety of -1'ing (and in many cases approving) 
> patches for minor spelling or grammatical errors and think we need a 
> policy about this. Given the large number of contributors for whom 
> English is not their native language, I would be in favor of rejecting 
> spelling errors in variable or method names but being more lenient in 
> comments, commit messages, READMEs, etc. What do you all think?
> 

The point of code review is to find defects. Misspelled words are defects
in the English language encoded in the change. In fact, commit messages
in particular are critical to get right as they cannot ever be fixed,
and they are generally the most useful when under a stressful situation
trying to determine the nature of a regression.

Many of our contributors are also newbies to python, and we do not let
them get away with obvious mistakes in python code. English is just a
language with a different interpreter (a more forgiving one, for sure,
but also one with many versions at various stages of implementation).

In fact, our large percentage of non-native english speakers is a reason
to be extremely careful about grammar and spelling so as not to confuse
non-native speakers with incorrect grammar and spelling.

I believe that if a -1 for a spelling mistake is causing more than an
extremely short turn around time then either the submitter is not engaged
with the project and thus not responsive to the -1, or the reviewers
are over-taxed and the given project needs more reviewers.

___
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] [qa] Policy on spelling and grammar

[Jay S Bryant]

Agreed that any -1's should require a suggestion for a way to resolve the 
issue.  I haven't seen people -1'ing without suggestions for improvement 
though.  I think, generally, people help explain why a change is needed.



Jay S. Bryant
Linux Developer - 
OpenStack Enterprise Edition
   
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   Ben Nemec 
To: openstack-dev@lists.openstack.org, 
Date:   11/11/2013 02:05 PM
Subject:Re: [openstack-dev] [qa] Policy on spelling and grammar



On 2013-11-11 13:28, Tim Bell wrote:
> As a speaker of the Queen's English, I find flavor to be incorrect.
> Does that mean I can -1 any patch that does not use flavour ?
> 
> At CERN, we are working with 130 countries in a single community. The
> value of the contribution of non-english speakers far exceeds the
> occasional misunderstandings.
> 
> Giving grammar/spellings -1 excludes major sections of the community
> from contribution.
> 
> As our aim is meritocracy (in python, computer architecture and design
> rather than spelling), I'd propose
> 
> - If someone identifies a need for clarification/correction as part of
> a review, they also submit the replacement text rather than just -1.
> - The submitter incorporates that change into a patch

Agreed.  Whenever possible, a grammar/spelling -1 should include 
proposed alternatives (I say whenever possible because I've -1'd a few 
changes where the docstrings were incomprehensible to me, so I couldn't 
provide a better alternative as I wasn't sure what they were trying to 
say :-).

-Ben

___
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] meeting place for event Monday night in Tokyo ...

[Jay S. Bryant]

All,

As has been our custom during previous summits, the Cinder team would 
will be getting together for dinner and drinks on Monday night (11/26) 
at the Tokyo Summit.


Not sure where the evening will take us, but we are planning to meet by 
registration at the Convention Center.  Looking at the map, if I am 
reading it properly, in front of the Huawei Community Lounge on the 
first floor looks like a good place to meet that is right near 
registration.  So, lets go for that.  :-)


We will be meeting at 7:30pm and then decide where we want to go from there.

Look forward to seeing those who can make it!

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

Re: [openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...

[Jay S. Bryant]

On 10/21/2015 04:00 PM, Anita Kuno wrote:

On 10/21/2015 04:54 PM, Jay S. Bryant wrote:

All,

As has been our custom during previous summits, the Cinder team would
will be getting together for dinner and drinks on Monday night (11/26)
at the Tokyo Summit.

Not sure where the evening will take us, but we are planning to meet by
registration at the Convention Center.  Looking at the map, if I am
reading it properly, in front of the Huawei Community Lounge on the
first floor looks like a good place to meet that is right near
registration.  So, lets go for that.  :-)

We will be meeting at 7:30pm and then decide where we want to go from
there.

Look forward to seeing those who can make it!

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

Do you need a list of folks or just wander by and go from there?

Looking forward to seeing Cinder folk at summit!

Thanks Jay,
Anita.

__
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

Anita,

Good question.  Don't think we were planning on getting a list of 
people.  Just going to see

who all is there at 7:30 and roll with it!

Summits are best when we just see where the wind takes us.  ;-)

Will be good to see you again as well!

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

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

[Jay S. Bryant]

+2

Well deserved!  Scott has been a great resource to the project!

On 06/27/2016 12:27 PM, 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

Re: [openstack-dev] [Cinder] Newton Midcycle Planning

[Jay S. Bryant]

Sean,

Thanks for getting the discussion started.

I think R-14 might be a little tricky leading up to the 4th of July weekend.

It seems like R-17 is coming awful quick but could be done.  That or 
R-11 would be my second vote then.


We have had successful meet-ups in Rochester ... yes, the guest wifi 
works in Rochester ... I could check into using our facilities if anyone 
was interested.


Jay

On 04/12/2016 09:05 AM, Sean McGinnis wrote:

Hey Cinder team (and those interested),

We've had a few informal conversations on the channel and in meetings,
but wanted to capture some things here and spread awareness.

I think it would be good to start planning for our Newton midcycle.
These have been incredibly productive in the past (at least in my
opinion) so I'd like to get it on the schedule so folks can start
planning for it.

For Mitaka we held our midcycle in the R-10 week. That seemed to work
out pretty well, but I also think it might be useful to hold it a little
earlier in the cycle to keep some momentum going and make sure things
stay pretty focused for the rest of the cycle.

For reference, here is the current release schedule for Newton:

http://releases.openstack.org/newton/schedule.html

R-10 puts us in the last week of July.

I would have a conflict R-16, R-15. We probably want to avoid US
Independence Day R-13, and milestone weeks R-18 and R12.

So potential weeks look like:

* R-17
* R-14
* R-11
* R-10
* R-9

Nova is in the process of figuring out their date. If we have that, it
would be good to try to avoid an overlap there. Our linked midcycle
session worked out well, but probably better if they don't conflict.

We also need to work out locations. Anyone able and willing to host,
just let me know. We need a facility with wifi, able to hold ~30-40
people, wifi, close to an airport. And wifi.

At some point I still think it would be nice for our international folks
to be able to do a non-US midcycle, but I'm fine if we end up back in Ft
Collins our somewhere similar.

Thanks!

Sean (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] The way to get traces of compiling fails when cinder service restarts

[Jay S. Bryant]

Jun-ha,

Do you have 'verbose = true' and 'debug = true' set in 
/etc/cinder/cinder.conf ?


If not, try setting those options and restarting your services.

Jay

On 04/28/2016 01:20 AM, 박준하 wrote:


Hi all,

I’m a beginner of Openstack.

I tried to modified some sources in Cinder directories for studying 
and restart services such as cinder-api, cinder-volume, cinder-scheduler.


But, I could not discover any compile error on ‘/var/log/*’

I want to watch compile errors with python Traceback.

Is there the best way to debugging on service level?

Thanks

Jun-ha Park

Dept. Cloud Technology group. KINX corp. , Korea



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

[Jay S. Bryant]

Sorry for the slow response here ... +1

Michal,

Thank you for all you have contributed recently.  Welcome to the team!

Jay

On 05/03/2016 01:16 PM, 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] Custom fields for versioned objects

[Jay S. Bryant]

Sean,

Just an FYI that I have created a work item for my team to start working 
this.  So, watch for patches from Slade, Kendall, Ryan, Jacob and I to 
get this implemented.


Thanks,
Jay


On 12/15/2015 10:31 AM, Sean McGinnis wrote:

On Tue, Dec 15, 2015 at 04:46:02PM +0100, Micha?? Dulko wrote:

On 12/15/2015 04:08 PM, Ryan Rossiter wrote:

Thanks for the review Michal! As for the bp/bug report, there???s four options:

1. Tack the work on as part of bp cinder-objects
2. Make a new blueprint (bp cinder???object-fields)
3. Open a bug to handle all changes for enums/fields
4. Open a bug for each changed enum/field

Personally, I???m partial to #1, but #2 is better if you want to track this 
work separately from the other objects work. I don???t think we should go with 
bug reports because #3 will be a lot of Partial-Bug and #4 will be kinda 
spammy. I don???t know what the spec process is in Cinder compared to Nova, but 
this is nowhere near enough work to be spec-worthy.

If this is something you or others think should be discussed in a meeting, I 
can tack it on to the agenda for tomorrow.

bp/cinder-object topic is a little crowded with patches and it tracks
mostly rolling-upgrades-related stuff. This is more of a refactoring
than a ovo essential change, so simple specless bp/cinder-object-fields
is totally fine to me.

I agree. If you can file a new blueprint for this, I can approve it
right away. That will help track the effort.

Thanks for working on this!

Sean (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] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Jay S. Bryant]

Ben,

Please see my in-line responses ...

On 01/04/2016 05:43 PM, Ben Nemec wrote:

On 01/04/2016 03:50 PM, Kendall J Nelson wrote:

Hello,


In brainstorming ideas for talks at the upcoming summit, I thought about
some of the things I had worked on for Cinder and what could still be
improved. One of the things I have been looking into is the generation
of sample configuration option files. Upon initial research it looks
like none of the main projects are doing it the same way.

I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
(at least) are all using the oslo-config-generator tool for this.  There
might be some slight variation in how they call it, but they are using it.
Yes, we know that they are all using oslo-config-generator but there is 
not consistency
in how the information that oslo-config-generator needs to do its job is 
being created.
Kendall is looking to better understand what we should be doing and try 
to bring

greater consistency between the projects.


I only vaguely recall having discussions about this with Cinder, so I'd
be interested in a refresher around why Cinder didn't want to do it the
same way.  I kind of considered it a solved problem.
So, the challenge Cinder has is the fact that there are many 
configuration options with all the
different drivers.  We had proposed a static cinder/opts.py file with 
hacking checks to ensure
that all new options were pulled into the file.  This was considered 
undesirable.  This lead to
the current solution where we are working to find all the possible 
option lists to dynamically
create the cinder/opts.py file.  Similar to what we used to do with the 
old config generator.


For Nova, having a dynamic solution is less important as they don't have 
options changing
as frequently.  It appears that Neutron was less concerned about the 
potentially dynamic nature

of options in their drivers.


For reference:
Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
which calls
https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17
Keystone: https://github.com/openstack/keystone/blob/master/tox.ini#L148
Etc...


I thought it
might be interesting to get a panel together to talk about how it is
done for each project, why it is done that way for each project, and
maybe discuss a more universal approach that could be implemented in
oslo and used by all the projects. Please let me know if you have
knowledge on your project’s method and are interested in being part of a
panel.


If you are interested in looking at Cinder’s approach, here is the patch
I implemented to make the generation of the sample config file dynamic:
https://review.openstack.org/#/c/219700/


All the Best,

*Kendall J. Nelson*
Software Engineer &

Openstack Cinder Contributor

*E-mail:*_kjnel...@us.ibm.com_ 
*Cell Phone:*(952) 215- 4025*
IRC Nickname:*diablo_rojo   
IBM

3605 Hwy 52 N
Rochester, MN 55901-1407
United States





__
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] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?

[Jay S. Bryant]

All,

I had the opportunity to chat with John Garbutt when he was here in 
Rochester for the Nova mid-cycle meet-up.  We discussed the fact that 
there was much to be gained by improving the communication between the 
Cinder and Nova teams.


With that idea in mind, it was suggested that the Cinder team open an 
invitation to Nova members to attend our mid-cycle meet-up.  The 
mid-cycle meet-up, of course, is not a secret.  A member of the Nova 
team has always been welcome to join, just hoping that an explicit 
invitation here may spark some interest.  :-)  Note:  John considered 
attending but is unable to do so.


The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site in 
Fort Collins, CO .  Friday is an optional code sprint day for those who 
are able to stay that long.  Details about the meet-up can be seen on 
our mid-cycle meetup planning etherpad [1].


If you are able to join us and help us work through the various 
challenges we are having between Cinder and Nova it would be greatly 
appreciated!


Jay

[1] https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup

__
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] I have a question about openstack cinder zonemanager driver.

[Jay S. Bryant]

Danny is correct.  You cannot have two different Zone Manager drivers 
configured for one volume process.


Jay

On 08/13/2015 11:00 AM, Daniel Wilson wrote:
I am fairly certain you cannot currently use two different FC switch 
zone drivers in one cinder.conf.  In this case it looks like you would 
need two cinder nodes, one for Brocade fabric and one for Cisco fabric.


Thanks,
Danny

On Thu, Aug 13, 2015 at 2:43 AM, Chenying (A) > wrote:


Hi, guys

 I am using Brocade FC switch in my OpenStack environment. I
have a question about OpenStack cinder zonemanger driver.

I find that *[fc-zone-manager] *can only configure one zone
driver. If I want to use two FC switches from different vendors at
the same time.

One is Brocade FC switch, the other one is Cisco FC switch. Is
there a method or solution configure two FC switch zone driver in
one cinder.conf ?

I want them both to support Zone Manager.

**

**


__
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] Proposing Gorka Eguileor for core

[Jay S. Bryant]

+1

He has been doing good reviews and shown a sustained commitment.

Well done!

Jay

On 08/13/2015 02:13 PM, Mike Perez wrote:

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.




__
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 Sprint Summary

[Jay S. Bryant]

Great summary.  We covered a lot of ground.

Thanks Mike!

On 08/17/2015 10:53 AM, Mike Perez wrote:

A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
Full meeting notes available [1].

Image Caching
=
Glance Cinder backend store + Cinder Image Caching are so similar, it would
just be confusing to operators. We'll document only about the Cinder Image
Caching since the Glance backend store is limited in comparison.


Revisit Spec Review
===
The PTL in the future will be the only one to +2/A specs after sufficient +1's
have been given, and notice of approval to follow in the Cinder meeting.


When Specs and Blueprints are needed

Done https://wiki.openstack.org/wiki/Cinder/how-to-contribute-new-feature


People can guess UUID's that don't belong to them
=
Who cares. In past security discussions this has been a moot point.


Update Hypervisor about extending attached volumes
==
Add support to os-brick, but the Nova team has to be fine with this only
supporting Libvirt for now.


Microversions
=
We're doing it.


Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


Third Party CI for target drivers and zone manager drivers
==
Yes. This is already happening for Brocade and Cisco in Liberty!


Cinder <-> Nova API communication
=
Agreed on how the Cinder API should be used. It requires changes and
a Microversion bump on the Nova side. Design summit session to follow.


Out of tree drivers
===
No.


Exposing force-detach of a volumes
==
Yes, this will be in nova-manage in Liberty.


HA and Cinder
=
We need cross project consensus first. There are existing issues that can be
fixed without a DLM. Fix those first. Mike Perez will be leading cross project 
discussion at the summit.


Replication V2
==
John Griffith did extreme programming with the group and posted a review.
A limited replication feature with async and manual failover should be in
Liberty.


ABC classes for each driver feature
===
Keeping the current solution [2].


[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-June/067563.html




__
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 Gorka Eguileor for core

[Jay S. Bryant]

Congratulations!  Welcome Gorka!

Jay

On 08/19/2015 12:01 PM, Mike Perez wrote:

On 12:13 Aug 13, Mike Perez wrote:

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.

Gorka has been added to Cinder core. Welcome!




__
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

[Jay S. Bryant]

Mike,

We were enabled to do some great things under your leadership. Cinder 
has greatly benefited from your time as a PTL.


Thanks for all you have done!

Jay

On 09/14/2015 11:15 AM, Mike Perez wrote:

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-dev] [Cinder] Late Liberty patches should now be unblocked ...

[Jay S. Bryant]

All,

Now that Mitaka is open I have done my best to go through and remove all 
the -2's that I had given to block Liberty patches that needed to wait 
for Mitaka.


If you have a patch that I missed please ping me on IRC.

Happy Mitaka merging!

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

Re: [openstack-dev] [cinder] Thanks to all the folks on the plane tour to glaciers

[Jay S. Bryant]

Vincent,

So sorry you were not feeling well during the tour.  Those things happen 
though...No worries.


We were glad to get the e-mail letting us know that you were ok and 
feeling better!


Glad that you could join us on the trip and see the Alpine lake and get 
pictures with us.  I will send you a copy of the pictures.


Safe travels back home!

Jay


On 05/22/2015 10:53 PM, Sheng Bo Hou wrote:

Hi all the folks on the plane tour to the glaciers,

This is Vincent Hou. I am sorry about getting a bit plane-sick during 
our trip. It was a sort of harsh for me, but the wonderful thing is that
I really enjoyed the snow, the mountain, the lake, the glaciers, etc. 
I hope the uncomfortable me did not bring too much trouble to you folks.
It felt like that the blood in my body had stopped flowing. I got no 
strength to see, no strength to hear, no strength to sit, even no 
strength
to think... Sorry about that I did not even say goodbye and wish you 
folks a nice trip back to your place.


Thank Kurt. This trip is perhaps the only once in my life with the 
best view I ever see.
Thank Sean. You words helped me a lot. I might not be able to make the 
trip in the last section without them.

Thank Jay, Walter... Thank everybody.

One more request in the end. Can you guys share some photos you have 
taken in our tour? I have missed some view. Thank you so much.


I am feeling much better now in the hotel. Take care, folks! Safe trip 
back home! See 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


__
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

[Jay S. Bryant]

On 06/03/2015 02:53 PM, Eric Harney wrote:

On 06/03/2015 01:59 PM, John Griffith wrote:

On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez  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


​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).

Given that part of the case made for CI was "ensure that Cinder ships
drivers that work", the case of backend behavior diverging over time
from what originally worked with Cinder seems like a valid concern.  We
lose the ability to keep tabs on that for derived drivers without CI.


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


The other issue I see with not requiring CI for "derived" drivers is
that, inevitably, small changes will be made to the driver code, and we
will find ourselves having to sort out how much change can happen before
CI is then required.  I don't know how to define that in a way that
would be useful as a general policy.

Eric

__
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


At first I wasn't too sure that requiring an additional CI for a derived 
driver made sense.  The concerns raised, however, are compelling and I 
think that a CI should be required for rebranded drivers.  It is 
inevitable that subtle differences will sneak in and we need to have CI 
in place to catch any failures that may also be introduced.


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

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

[Jay S. Bryant]

On 02/20/2016 04:42 PM, Duncan Thomas wrote:



On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote:


> Not that I'm adding much to this conversation that hasn't been said 
already, but I am pro v2 API, purely because of how painful and long 
it's been to get the official OpenStack projects to adopt the v2 API 
from v1.


I think there's a slightly different argument here. We aren't taking 
away the v2 API, probably ever. Clients that are satisfied with it can 
continue to use it, as it is, forever. For clients that aren't trying 
to do anything beyond the current basics will quite possibly be happy 
with that. Consumers have no reason to change over without compelling 
value from the change - that will come from what we implement on top 
of microversions, or not. Unlike the v1 transition, we aren't trying 
to get rid of v2, just stop changing existing semantics of it.




__
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
Spent some time talking to Sean about this on Friday afternoon and 
bounced back and forth between the two options.  At first, /v3 made the 
most sense to me ... at least it did at the meetup.  With people like 
Sean Dague and Morgan Fainberg weighing in with concerns, it seems like 
we should reconsider.  Duncan, your comment here about customers moving 
when they are ready is somewhat correct.  That, however, I am concerned 
is a a small subset of the users.  I think many users want to move but 
don't know any better.  That was what we encountered with our 
consumers.  They didn't understand that they needed to update the 
endpoint and couldn't figure out why their new functions weren't working.


So, I am leaning towards going with the /v2 endpoint and making sure 
that the clients we can control are set up properly and we put safety 
checks in the server end.  I think that may be the safest way to go.


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

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

[Jay S. Bryant]

Ivan,

I agree that our testing needs improvement.  Thanks for starting this 
thread.


With regards to adding a hacking check for tests that run too long ... 
are you thinking that we would have a timer that checks or long running 
jobs or something that checks for long sleeps in the testing code?  Just 
curious your ideas for tackling that situation.  Would be interested in 
helping with that, perhaps.


Thanks!
Jay

On 03/02/2016 05:25 AM, Ivan Kolodyazhny wrote:

Hi Team,

Here are my thoughts and proposals how to make Cinder testing process 
better. I won't cover "3rd party CI's" topic here. I will share my 
opinion about current and feature jobs.



Unit-tests

  * Long-running tests. I hope, everybody will agree that unit-tests
must be quite simple and very fast. Unit tests which takes more
than 3-5 seconds should be refactored and/or moved to
'integration' tests.
Thanks to Tom Barron for several fixes like [1]. IMO, we it would
be good to have some hacking checks to prevent such issues in a
future.

  * Tests coverage. We don't check it in an automatic way on gates.
Usually, we require to add some unit-tests during code review
process. Why can't we add coverage job to our CI and do not merge
new patches, with will decrease tests coverage rate? Maybe, such
job could be voting in a future to not ignore it. For now, there
is not simple way to check coverage because 'tox -e cover' output
is not useful [2].


Functional tests for Cinder

We introduced some functional tests last month [3]. Here is a patch to 
infra to add new job [4]. Because these tests were moved from 
unit-tests, I think we're OK to make this job voting. Such tests 
should not be a replacement for Tempest. They even could tests Cinder 
with Fake Driver to make it faster and not related on storage backends 
issues.



Tempest in-tree tests

Sean started work on it [5] and I think it's a good idea to get them 
in Cinder repo to run them on Tempest jobs and 3-rd party CIs against 
a real backend.



Functional tests for python-brick-cinderclient-ext

There are patches that introduces functional tests [6] and new job [7].


Functional tests for python-cinderclient

We've got a very limited set of such tests and non-voting job. IMO, we 
can run them even with Cinder Fake Driver to make them not depended on 
a storage backend and make it faster. I believe, we can make this job 
voting soon. Also, we need more contributors to this kind of tests.



Integrated tests for python-cinderclient

We need such tests to make sure that we won't break Nova, Heat or 
other python-cinderclient consumers with a next merged patch. There is 
a thread in openstack-dev ML about such tests [8] and proposal [9] to 
introduce them to python-cinderclient.



Rally tests

IMO, it would be good to have new Rally scenarios for every patches 
like 'improves performance', 'fixes concurrency issues', etc. Even if 
we as a Cinder community don't have enough time to implement them, we 
have to ask for them in reviews, openstack-dev ML, file Rally bugs and 
blueprints if needed.



[1] https://review.openstack.org/#/c/282861/
[2] http://paste.openstack.org/show/488925/
[3] https://review.openstack.org/#/c/267801/
[4] https://review.openstack.org/#/c/287115/
[5] https://review.openstack.org/#/c/274471/
[6] https://review.openstack.org/#/c/265811/
[7] https://review.openstack.org/#/c/265925/
[8] 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html

[9] https://review.openstack.org/#/c/279432/


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

[openstack-dev] [cinder] Volume Replication and Migration bug triage ...

[Jay S. Bryant]

All,

In discussion with Mike Perez earlier this week the following bugs were 
highlighted in Volume Migration and Volume Replication.  IBM is focusing 
on investigating and resolving these bugs.


I will be putting out updates as we progress towards resolution of these 
issues.


Replication:

/https://bugs.launchpad.net/cinder/+bug/1390001 -- Investigated by Tao 
and found to be Invalid/

https://bugs.launchpad.net/cinder/+bug/1384040 -- assigned to Tao
https://bugs.launchpad.net/cinder/+bug/1372292 -- assigned to Tao
/https://bugs.launchpad.net/cinder/+bug/1370311 -- Requires multi-pool 
scheduler awareness and replica promote supporting multiple pools.  BP 
opened: 
https://blueprints.launchpad.net/cinder/+spec/storwize-support-muli-pool-within-one-backend-relative-features/
https://bugs.launchpad.net/cinder/+bug/1383524 -- Currently assigned to 
Ronen with updates from Avishay.  Have a question in to Avishay to see 
if he can keep investigating.


Migration:

/https://bugs.launchpad.net/cinder/+bug/1404013 -- Fix released for this./
https://bugs.launchpad.net/cinder/+bug/1403916 -- Question out to the 
reporter to see if this is still an issue. (LVM)
https://bugs.launchpad.net/cinder/+bug/1403912 -- Question out to the 
reporter to see if this is still an issue. (LVM)

/https://bugs.launchpad.net/cinder/+bug/1403904 -- Marked Invalid/
https://bugs.launchpad.net/cinder/+bug/1391179 --  Assigned to Alon Marx 
as this is an issue that was seen on XIV.
https://bugs.launchpad.net/cinder/+bug/1283313 -- Avishay was looking 
into this.  Asked if he still is doing so.
https://bugs.launchpad.net/cinder/+bug/1255957 -- Currently marked 
incomplete.  May warrant futher investigation.

/https://bugs.launchpad.net/cinder/+bug/1391172 -- Fix released/
https://bugs.launchpad.net/cinder/+bug/1403902 -- A number of patches 
have been proposed around this one.  Will follow up to understand if it 
is still a problem.
https://bugs.launchpad.net/cinder/+bug/1255622 -- John was the last one 
looking at this.  Appears to work in some situations.

https://bugs.launchpad.net/cinder/+bug/1398177 -- Assigned to Vincent Hou
https://bugs.launchpad.net/cinder/+bug/1308822 -- Assigned to Tao or Li Min.
https://bugs.launchpad.net/cinder/+bug/1278289 -- Assigned to Jay. Will 
investigate
https://bugs.launchpad.net/cinder/+bug/1308315.-- Tao is investigating 
but hasn't been able to recreate.


While triaging all the issues I updated the ones for migration with a 
'migration' tag and updated the replication ones with a 'replication' tag.


If you have any questions/concerns about this, please let me know. 
Otherwise we will work towards cleaning these up.


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

Re: [openstack-dev] [cinder] Feature Freeze Exception Request - bp/linux-systemz

[Jay S. Bryant]

Mike,

A FFE for this has been submitted to Nova and is being sponsored by Matt 
Riedemann:  [1]


Assuming that goes through soon, can we please re-address?

Thanks!
Jay

[1] 
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg45430.html



On 02/09/2015 12:23 PM, Mike Perez wrote:

On 17:31 Mon 09 Feb , Andreas Maier wrote:

Hello,
I would like to ask for the following feature freeze exception in Cinder.

Cinder is not in a feature freeze at the moment [1].


Additional notes: The code in Nova patch set
https://review.openstack.org/149256 is consistent with this patch set,
but a decision to include them in kilo can be made independently for
each of the two patch sets: The Nova patch set enables FCP storage for a
compute node with KVM on System z, while the Cinder patch set enables
Cinder services to run on System z Linux.

If it's not landing in Nova for Kilo [2], I'd rather not target it for Kilo in
Cinder. We're already really packed for K-3, and it's not useful without the
Nova piece. Please resubmit for L-1 in Cinder.

[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055719.html
[2] - https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz




__
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] organizing tempest test development for volume replication

[Jay S. Bryant]

All,

One of the concerns raised with regards to volume migration was the lack 
of tempest testing for the functionality.  Since they I have had some 
interest indicated in helping this effort.  So, to get things started I 
have created an etherpad to track development of such test cases and to 
share thoughts/plans for such work:  [1]


Please let me know if you have any questions with regards to this.

Thanks to anyone who is interested/able to help with this effort!

Jay

[1] https://etherpad.openstack.org/p/replication-tempest-test-dev-planning

__
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] Etherpad for volume replication created ...

[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

Re: [openstack-dev] [cinder] K3 Feature Freeze Exception request for bp/nfs-backup

[Jay S. Bryant]

All,

I will sponsor this.

Patch just needs to be rebased.

Jay

On 03/11/2015 10:20 AM, Tom Barron wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I hereby solicit a feature freeze exception for the NFS backup review [1].

Although only about 140 lines of non-test code, this review completes
the implementation of the NFS backup blueprint [2].  Most of the
actual work for this blueprint was a refactor of the Swift backup
driver to
abstract the backup/restore business logic from the use of the Swift
object store itself as the backup repository.  With the help of Xing
Yang, Jay Bryant, and Ivan Kolodyazhny, that review [3] merged
yesterday and made the K3 FFE deadline.

In evaluating this FFE request, please take into account the following
considerations:

* Without the second review, the goal of the blueprint remains
  unfullfilled.

* This code was upstream in January and was essentially complete
  with only superficial changes since then.

* As of March 5 this review had two core +2s.  Delay since then has
  been entirely due to wait time on the dependent review and need
  for rebase given upstream code churn.

* No risk is added outside NFS backup service itself since the
  changes to current code are all in the core refactor and that
  is already merged.

If this FFE is granted, I will give the required rebase my immediate
attention.

Thanks.

- --
Tom Barron
t...@dyncloud.net

[1] - https://review.openstack.org/#/c/149726
[2] - https://blueprints.launchpad.net/cinder/+spec/nfs-backup
[3] - https://review.openstack.org/#/c/149725
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBAgAGBQJVAF1YAAoJEGeKBzAeUxEHayUH/2iWuOiKBnRauX40fwcR7+js
lIM+qRIHlg2iJ+cnqap6HHUhBSxwHnuAV41zQmFBKnfhc3sIqS98ZSVlUaJQtct/
YjjInKOpxFOEw1FgoFMsrg0qm76zFMXXVIKNegy2iXgXsKzDTWed5n57N8FAP2+6
q/uASOZNHgxbeZLV7LSKS21/3WUoQpIQiW0+1GtkVtO1C9t8Io+TrjlZj7T60kHJ
UEH5HShKE0U40SKhgwRyEK7HqbMDGv8w5SsUgyUntdgDlQycgyI/erKm5WJqcZsF
F6om6HY3oxtulcjbrWmA6+ENnOYsLchXFT8fZeLj7JWOarv5SF2fBQFTqzc/36U=
=/FVr
-END PGP SIGNATURE-

__
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] Deprecation warnings considered harmful?

[Jay S. Bryant]

Duncan,

If you see any of these coming out of Cinder (not oslo) please get a bug 
to me.


I think I have them all removed but need to know if I have missed anything.

Thanks!
Jay

On 03/12/2015 04:24 AM, Duncan Thomas wrote:

ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
/usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_i18n instead.

  from oslo import i18n
/opt/stack/cinder/cinder/openstack/common/policy.py:98: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_config instead.

  from oslo.config import cfg
/opt/stack/cinder/cinder/openstack/common/policy.py:99: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_serialization instead.

  from oslo.serialization import jsonutils
/opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The 
oslo namespace package is deprecated. Please use oslo_messaging instead.

  from oslo import messaging
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_utils instead.

  from oslo.utils import excutils


What are normal, none developer users supposed to do with such 
warnings, other than:

a) panic or b) Assume openstack is beta quality and then panic

--
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] May you reconsider about huawei driver?

[Jay S. Bryant]

Mike,

Looks like this removal may have been a mistake.  We should readdress.

Jay


On 03/20/2015 05:59 AM, Erlon Cruz wrote:
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 > 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


__
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] [oslo][cinder][nova][neutron] going forward to oslo-config-generator ...

[Jay S. Bryant]

All,

Let me start with the TLDR;

Cinder, Nova and Neutron have lots of configuration options that need to 
be processed by oslo-config-generator to create the 
.conf.sample file.  There are a couple of different ways this 
could be done.  I have one proposal out, which has raised concerns, 
there is a second approach that could be taken which I am proposing 
below.  Please read on if you have a strong opinion on the precedent we 
will try to set in Cinder.  :-)


We discussed in the oslo meeting a couple of weeks ago a plan for how 
Cinder was going to blaze a trail to the new oslo-config-generator.  The 
result of that discussion and work is here:  [1]  It needs some more 
work but has the bare bones pieces there to move to using 
oslo-config-generator.


With the change I have written extensive hacking checks that ensure that 
any lists that are registered with register_opts() are included in the 
base cinder/opts.py file that is then a single entry point that pulls 
all of the options together to generate the cinder.conf.sample file.  
This has raised concern, however, that whenever a developer adds a new 
list of configuration options, they are going to have to know to go back 
to cinder/opts.py and add their module and option list there.  The 
hacking check should catch this before code is submitted, but we are 
possibly setting ourselves up for cases where the patch will fail in the 
gate because updates are not made in all the correct places and because 
pep8 isn't run before the patch is pushed.


It is important to note, that this will not happen every time a 
configuration option is changed or added, as was the case with the old 
check-uptodate.sh script.  Only when a new list of configuration options 
is added which is a much less likely occurrence.  To avoid this 
happening at all it was proposed by the Cinder team that we use the code 
I wrote for the hacking checks to dynamically go through the files and 
create cinder/opts.py whenever 'tox -egenconfig' is run.  Doing this 
makes me uncomfortable as it is not consistent with anything else I am 
familiar with in OpenStack and is not consistent with what other 
projects are doing to handle this problem.  In discussion with Doug 
Hellman, the approach also seemed to cause him concern.  So, I don't 
believe that is the right solution.


An alternative that may be a better solution was proposed by Doug:

We could even further reduce the occurrence of such issues by moving the 
list_opts() function down into each driver and have an entry point for 
oslo.config.opts in setup.cfg for each of the drivers.  As with the 
currently proposed solution, the developer doesn't have to edit a top 
level file for a new configuration option.  This solution adds that the 
developer doesn't have to edit a top level file to add a new 
configuration item list to their driver.  With this approach the change 
would happen in the driver's list_opts() function, rather than in 
cinder/opts.py .  The only time that setup.cfg would needed to edited is 
when a new package is added or when a new driver is added.  This would 
reduce some of the already minimal burden on the developer.  We, 
however, would need to agree upon some method for aggregating together 
the options lists on a per package (i.e. cinder.scheduler, cinder.api) 
level.  This approach, however, also has the advantage of providing a 
better indication in the sample config file of where the options are 
coming from.  That is an improvement over what I have currently proposed.


Does Doug's proposal sound more agreeable to everyone?  It is important 
to note that the fact that some manual intervention is required to 
'plumb' in the new configuration options was done by design.  There is a 
little more work required to make options available to 
oslo-config-generator but the ability to use different namespaces, 
different sample configs, etc were added with the new generator.  These 
additional capabilities were requested by other projects.  So, moving to 
this design does have the potential for more long-term gain.


Thanks for taking the time to consider this!

Jay

[1] https://review.openstack.org/#/c/165431/


__
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] [oslo] not running for PTL for liberty cycle

[Jay S. Bryant]

+1000

You have done a great job Doug!  Thank you for your leadership!

Jay

On 04/03/2015 08:11 AM, Flavio Percoco wrote:

On 03/04/15 08:50 -0400, Doug Hellmann wrote:

Team,

I have decided not to run for PTL for Oslo for the next cycle.

Serving as PTL for the last three releases has been a rewarding 
experience, and I think we’ve made some great strides together as a 
team. Now it’s time for me to step down and let someone else take the 
lead position. I am still committed to the mission, and I will  be 
contributing to Oslo, but I do also want to work on some other 
projects that I won’t have time for if I stay in the PTL role. We 
have several good candidates for PTL on the team, and I expect us to 
have no trouble finding someone willing to step up and run.




FWIW, I believe you did an *AMAZING* job as Oslo PTL. It was an honor
to have you in that position. Thanks for your hard work.

Flavio



__
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] Current Status of IBM 3rd Party CI Testing ...

[Jay S. Bryant]

All,

I just wanted to provide an update on 3rd Party CI Testing for IBM's 
drivers.


It was noted late last month that not all of IBM's drivers were running 
the required 304 test cases.  That issue has been resolved for all 3rd 
Party CI's except for DS8k.  The maintainer of that system has been out 
but returns this week.  I will work with him to ensure we get that 
problem resolved.


While looking through results, I noticed that our CI's are still 
intermittently failing.  I will work with the CI maintainers on this.


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

Re: [openstack-dev] [cinder] Current Status of IBM 3rd Party CI Testing ...

[Jay S. Bryant]

Anita,

My apologies.  The original communication on the issue came from Mike 
via the mailing list so I was attempting to continue the public 
discussion here.


I will make sure to not do this in the future.

Jay

On 04/06/2015 03:19 PM, Anita Kuno wrote:

On 04/06/2015 04:03 PM, Jay S. Bryant wrote:

All,

I just wanted to provide an update on 3rd Party CI Testing for IBM's
drivers.

It was noted late last month that not all of IBM's drivers were running
the required 304 test cases.  That issue has been resolved for all 3rd
Party CI's except for DS8k.  The maintainer of that system has been out
but returns this week.  I will work with him to ensure we get that
problem resolved.

While looking through results, I noticed that our CI's are still
intermittently failing.  I will work with the CI maintainers on this.

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

Okay I can understand Huawei posting many many times to the mailing list
to get themselves sorted out, due to their complaints noone is available
for them in apac time (despite the fact that I personally have never
seen Liu in a third party meeting - every Tuesday 0800 utc in
#openstack-meeting) but folks are feeling pressured so I figured I would
give him/her a day or two to get themselves sorted out.

However the expected place for CI account status updates is the wikipage
for third party systems and your individual account page:
https://wiki.openstack.org/wiki/ThirdPartySystems and link to your system.

Jay, (look of disapproval), don't make me come up there,
Anita.

__
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