Re: [openstack-dev] [cinder] about use nfs driver to backup the volume snapshot

[Jay Bryant]

On Thu, Nov 1, 2018, 10:44 AM Rambo  wrote:

> Hi,all
>
>  Recently, I use the nfs driver as the cinder-backup backend, when I
> use it to backup the volume snapshot, the result is return the
> NotImplementedError[1].And the nfs.py doesn't has the
> create_volume_from_snapshot function. Does the community plan to achieve
> it which is as nfs as the cinder-backup backend?Can you tell me about
> this?Thank you very much!
>
> Rambo,

The NFS driver doesn't have full snapshot support. I am not sure if that
function missing was an oversight or not. I would reach out to Eric Harney
as he implemented that code.

Jay

>
>
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L2142
>
>
>
>
>
>
>
>
> Best Regards
> Rambo
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Cinder volume Troubleshoot

[Jay Bryant]

Kevin,

Just a note thatyou may need to look way back in the logs to find the cause
as there m as y be many periodic job failures filling the logs.

Jay

On Sun, Jul 1, 2018, 7:09 AM Ivan Kolodyazhny  wrote:

> Hi Kevin,
>
> Do you have any errors or tracebacks in /var/log/cinder/cinder-volume.log?
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Sun, Jul 1, 2018 at 12:02 PM, Kevin Kwon  wrote:
>
>>
>> Dear All!
>>
>>
>> would you please let me know how can troubleshoot below case?
>>
>> i don't know why below Storage server is down.
>>
>> Please help to figure it out..
>>
>>
>> root@OpenStack-Controller:~# openstack volume service list
>>
>> +--+---+--+-+---++
>> | Binary   | Host  | Zone | Status  | State |
>> Updated At |
>>
>> +--+---+--+-+---++
>> | cinder-scheduler | OpenStack-Controller  | nova | enabled | up|
>> 2018-07-01T08:58:19.00 |
>> | cinder-volume| OpenStack-Storage@lvm | nova | enabled | down  |
>> 2018-07-01T07:28:59.00 |
>>
>> +--+---+--+-+---++
>> root@OpenStack-Controller:~#
>>
>>
>> Kevin
>>
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
> __
> 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] making volume available without stopping VM

[Jay Bryant]

On Sat, Jun 23, 2018, 9:39 AM Volodymyr Litovka  wrote:

> Dear friends,
>
> I did some tests with making volume available without stopping VM. I'm
> using CEPH and these steps produce the following results:
>
> 1) openstack volume set --state available [UUID]
> - nothing changed inside both VM (volume is still connected) and CEPH
> 2) openstack volume set --size [new size] --state in-use [UUID]
> - nothing changed inside VM (volume is still connected and has an old size)
> - size of CEPH volume changed to the new value
> 3) during these operations I was copying a lot of data from external
> source and all md5 sums are the same on both VM and source
> 4) changes on VM happens upon any kind of power-cycle (e.g. reboot
> (either soft or hard): openstack server reboot [--hard] [VM uuid] )
> - note: NOT after 'reboot' from inside VM
>
> It seems, that all these manipilations with cinder just update internal
> parameters of cinder/CEPH subsystems, without immediate effect for VMs.
> Is it safe to use this mechanism in this particular environent (e.g.
> CEPH as backend)?
>
>  From practical point of view, it's useful when somebody, for example,
> update project in batch mode, and will then manually reboot every VM,
> affected by the update, in appropriate time with minimized downtime
> (it's just reboot, not manual stop/update/start).
>
> Thank you.
>
> --
> Volodymyr Litovka
>"Vision without Execution is Hallucination." -- Thomas Edison
>
>
> __
> 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


Volodymyr,

We have had similar issues with extending attached volumes that are iSCSI
based. In that case the VM has to be forced to rescan the scsi bus.

In this case I am not sure if there needs to be a change to Libvirt or to
rbd or something else.

I would recommend reaching out to John Bernard for help.

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] [nova] increasing the number of allowed volumes attached per instance > 26

[Jay Bryant]

On Thu, Jun 7, 2018, 4:17 PM Matt Riedemann  wrote:

> On 6/7/2018 1:54 PM, Jay Pipes wrote:
> >
> > If Cinder tracks volume attachments as consumable resources, then this
> > would be my preference.
>
> Cinder does:
>
> https://developer.openstack.org/api-ref/block-storage/v3/#attachments
>
> However, there is no limit in Cinder on those as far as I know.
>
> There is no limit as we have no idea what to limit at.
>
There is no limit as we don't know what to limit at. Could depend on the
host, the protocol or the backend.

Also that is counting attachments for a volume. I don't think that helps us
determine how many attachments a host had without additional work.

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

[openstack-dev] [Cinder] no meeting today

[Jay Bryant]

Just a reminder there is no meeting because ofthe summit today.

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

Re: [openstack-dev] Adding "not docs" banner to specs website?

[Jay Bryant]

Agree this  is a good idea.

Let me know what we can do to help.

Jay

On Mon, Mar 19, 2018, 9:58 AM Jim Rollenhagen 
wrote:

> Ironic (and surely other projects) have had to point out many times that
> specs are a point in time design discussion, and not completed
> documentation. It's obviously too much work to go back and update specs
> constantly.
>
> What do folks think about a banner at the top of the specs website (or
> each individual spec) that points this out? I'm happy to do the work if we
> agree it's a good thing to do. My suggested wording:
>
> "NOTE: specifications are a point-in-time design reference, not up-to-date
> feature documentation."
>
> // jim
> __
> 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] Switching to longer development cycles

[Jay Bryant]

On Wed, Dec 13, 2017, 4:20 PM Thierry Carrez  wrote:

> Ed Leafe wrote:
> > On Dec 13, 2017, at 12:13 PM, Tim Bell  wrote:
> >
> >> There is a risk that deployment to production is delayed, and therefore
> feedback is delayed and the wait for the ‘initial bug fixes before we
> deploy to prod’ gets longer.
> >
> > There is always a rush at the Feature Freeze point in a cycle to get
> things in, or they will be delayed for 6 months. With the year-long cycle,
> now anything missing Feature Freeze will be delayed by a year. The long
> cycle also means that a lot more time will be spent backporting things to
> the current release, since people won’t be able to wait a whole year for
> some improvements.
> >
> > Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).
>
> Yes, I'll admit I'm struggling with that part of the proposal too. We
> could use intermediary releases but there would always be a "more
> important" release.
>
> Is the "rush" at the end of the cycle still a thing those days ? From a
> release management perspective it felt like the pressure was reduced in
> recent cycles, with less and less FFEs. But that may be that PTLs have
> gotten better at denying them, not that the pressure is reduced now that
> we are past the hype peak...
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Thierry,

I feel like the rush at the end of a cycle had gotten better to some
extent. The features going into Cinder, however habe slowed and we have had
more ling running development.

I am afraid the rush might come back oud we have longer development cycles.

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] [nova][cinder] Nova is now using the Cinder volume attachments API - multiattach comes next

[Jay Bryant]

Well said Ildiko. Thank you!

Jay

On Sun, Dec 10, 2017, 8:23 PM Ildiko Vancsa  wrote:

> Thanks Matt for all the help so far and also for taking the time to write
> up this summary! I would like to join in saying thanks to the handful of
> people listed below who formed an amazing cross-project team during the
> past two years.
>
> I strongly believe that by hunting for multi-attach support we stepped on
> the right track in terms of the interactions between the API’s of Cinder
> and Nova and better readability and maintainability of the code base in
> both projects on the long run with the changes we’ve made so far.
>
> I hope we can grow our team onwards as testing will become even more
> crucial as we move forward with the remaining implementation work to reach
> the minimum functionality for multi-attach.
>
> Thank you All once more for the hard work! And see you on the weekly
> meeting next Thursday. :)
>
> Thanks,
> Ildikó
> (IRC: ildikov)
>
>
> > On 2017. Dec 9., at 13:15, Matt Riedemann  wrote:
> >
> > I just wanted to take a minute to recognize that the patch [1] to make
> Nova use the new-style Cinder volume attach flow has merged.
> >
> > As one can tell from the patch set count alone, this has been in the
> works for a long time now.
> >
> > We were talking about volume multi-attach support back in Mitaka at the
> midcycle in Bristol. The early talks / patches would have piled more
> technical debt onto Nova and further baked in Nova's need to manage volume
> state, which is something we wanted to avoid, so at the Newton summit in
> Austin we changed course and decided to prioritize working on a new data
> model and API in Cinder, which eventually came out as the 3.27 volume
> attachments API in Ocata.
> >
> > There was then serious work on both sides in Pike to start using the new
> 3.27 API and we found out we needed some more changes to Cinder, which
> became the 3.44 Cinder API in Queens. Now Nova has merged the change at the
> end of a very long series of changes to enable the new flow once 3.44 is
> available to Nova and computes are all upgraded to understand the new flow.
> One can appreciate the complexity here if you read through the Nova spec
> for the new attach flow [2].
> >
> > I was really happy to see [1] merge this week because I knew we needed
> to get that in by the queens-2 milestone if we were going to have a shot at
> (1) flushing out stability issues before Queens RC1 and (2) a good chance
> to get multi-attach support into Nova in Queens.
> >
> > We have a plan for multi-attach support [3] which I think is doable
> before feature freeze. The Cinder 3.48 API is now available too which Nova
> needs to correctly detach a multi-attach volume.
> >
> > I want to thank everyone that's helped push this along for their
> dedication and patience, especially John Griffith, Ildiko Vancsa, Steve
> Noyes and John Garbutt. And thanks to Sean McGinnis, Jay Bryant, Walter
> Boring and Balazs Gibizer for review support.
> >
> > We've had weekly meetings between the Nova and Cinder teams for at least
> two years now and I can finally see the end so let's keep up the momentum.
> >
> > [1] https://review.openstack.org/#/c/330285/
> > [2]
> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-new-attach-apis.html
> > [3]
> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-volume-multi-attach.html
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

[Jay Bryant]

Sounds like a good plan.  Hopefully we can do some OUI work face to face as
well?

Jay

On Thu, Dec 14, 2017, 2:55 PM Kendall Nelson  wrote:

> Hello,
>
> It came up in a discussion today that it might be good to get together and
> discuss all the activities around on boarding and various other initial
> interactions to get us all on the same page and a little more
> organized/established.
>
> Given that SIGs have space the beginning of the week (Mon/Tuesday), I am
> proposing that we meet for one of these days. If you are interested, please
> let me know so I can get a headcount.
>
> -Kendall (diablo_rojo)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Dublin PTG format

[Jay Bryant]

Thierry,

I have been happy with the current 2 day/3 day split.  I am concerned that
I would have a harder time getting focus from the project team splitting
across multiple half days.  That is just my hunch.

Jay

On Mon, Nov 27, 2017, 1:21 PM Doug Hellmann  wrote:

> Excerpts from Thierry Carrez's message of 2017-11-27 11:58:04 +0100:
> > Hi everyone,
> >
> > We are in the final step in the process of signing the contract with the
> > PTG venue. We should be able to announce the location this week !
> >
> > So it's time to start preparing. We'll have 5 days, like in Denver. One
> > thing we'd like to change for this round is to give a bit more
> > flexibility in the topics being discussed, especially in the first two
> days.
> >
> > In Denver, we selected a number of general "themes" and gave them all a
> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> > project team meeting could get a room for 2 or 3 days on
> > Wednesday-Friday. That resulted in a bit of flux during the first two
> > days, with a lot of empty rooms as most of the themes did not really
> > need 2 days, and a lot of conflicts were present.
> >
> > For Dublin, the idea would be to still predetermine topics (themes and
> > teams) and assign them rooms in advance. But we would be able to assign
> > smaller amounts of time (per half-day) based on the expressed needs.
> > Beyond those pre-assigned themes/teams we'd add flexibility for other
> > groups to book the remaining available rooms in 90-min slots on-demand.
> > A bit like how we did reservable rooms in the past, but more integrated
> > with the rest of the event. It would all be driven by the PTGbot, which
> > would show which topic is being discussed in which room, in addition to
> > the current discussion subject within each topic.
> >
> > We have two options in how we do the split for predetermined topics. We
> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> > general idea there was to allow some people only interested in a team
> > meeting to only attend the second part of the week. However most people
> > attend all 5 days, and during event feedback some people suggested that
> > "themes" should be in the mornings and "teams" in the afternoons (and
> > all Friday).
> >
> > What would be your preference ? The Mon-Tue/Wed-Fri split means less
> > room changes, which make it easier on the events team. So all else being
> > equal we'd rather keep it the way it is, but I'm open to changing it if
> > attendees think it's a good idea.
> >
> > If you have any other suggestion (that we could implement in the 3
> > months we have between now and the event) please let me know :)
> >
>
> What sort of options do we have for trying the new morning/afternoon
> split approach without increasing the burden on the events team?
>
> Can we print the signs so they have both the project team names and
> a theme listed on the same sign so we can avoid changing them at
> all?
>
> Can we have the project teams or theme room organizers manage their
> own signs, placing them in prepared holders outside of the rooms?
>
> Or do we need signs at all? The rooms all have names or numbers
> already right?
>
> Doug
>
> __
> 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] No meeting this week

[Jay Bryant]

Just a reminder that we do not have a meeting this week as a number of
people will be traveling.

See you in Sydney!

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

[openstack-dev] [cinder] Denver Team Dinner Planned ...

[Jay Bryant]

Team,

I have found a place that I hope we will all enjoy for dinner. The 
general consensus was to do Thursday night with a few exceptions.  So, I 
went with the majority and made reservations for Thursday night at 7 
pm.  Here are the details:


 * */Location:  Casey's Bistro and Pub - 7301 East 29th Avenue Denver,
   CO 80238 -- 720-974-7350/*

 * */Website: /**/http://coloradopubco.com/stapleton-caseys//*

The place is .9 miles from the convention center.  So, it should be 
walkable.


If you are planning to come but haven't yet put your name on the list in 
the etherpad [1] please do so by Wednesday so I can make sure we have an 
accurate number for the reservation.


Look forward to seeing you all next week!

Jay

[1] https://etherpad.openstack.org/p/cinder-ptg-queens


__
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][docs] 404s on docs website after the great reorg

[Jay Bryant]

I think that making it so we can do redirect is good.  The current 
blackhole approach is less than desirable.


Jay


On 7/27/2017 10:06 PM, ChangBo Guo wrote:

++ for the solution.

2017-07-28 2:24 GMT+08:00 Doug Hellmann >:


Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +:
> On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote:
> > In the #openstack-nova channel this morning we were debugging
some cells
> > v2 things, and ran into the fact that the online docs for this -
> > https://docs.openstack.org/nova/latest/cells.html
 go to a 404.
That's a
> > previously well known link, people have it in their browser
history,
> > bookmarks, wiki pages, other websites.
> >
> > My understanding of big moves like this is that redirects are
important.
> > Things going blackhole like that not only is an inconvenience
to users,
> > but impacts our search engine rankings, and takes a while for
them to
> > all sift out. I know in sites I run I'm still regularly getting in
> > bounds to paths on the site that haven't been there for 8 years.
> >
> > It would be really good if we had a way (manual or automated)
to have
> > 301 redirects, that are fixable by the teams that now own the
> > documentation (the project teams).
>
> We can look at including .htaccess files in the tree I guess? Or
> some metadata the publish job uses to build them maybe?

That's exactly what I was thinking.

1. Enable .htaccess files by turning on allowoverride for
docs.openstack.org .

2. Add .htaccess files in each tree, as needed (see
https://review.openstack.org/487932
 for an example of how this
   is done with sphinx).

3. Update the main .htaccess file in openstack-manuals to redirect
   from the old location of docs in a way that passes the full path.
   Right now we redirect to /project/latest/:

  redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/

   I think that would change to look something like:

  redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2

   We would only want to do that for projects that actually have
   .htaccess files, so we can put a flag in the project-data files in
   openstack-manuals and generate project-specific redirect rules
(we're
   already doing that for some other pages).

Then when someone visits docs.o.o/developer/nova/cells.html it would
redirect to docs.o.o/nova/latest/cells.html. The nova team then
need to have a redirect from docs.o.o/nova/latest/cells.html to
docs.o.o/nova/latest/user/cells.html.

If folks think that's a good approach, I will start on the patches
needed in infra and openstack-manuals (1 and 3).

Doug

__
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





--
ChangBo Guo(gcb)


__
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][tc] Moving away from "big tent" terminology

[Jay Bryant]

On Thu, Jun 15, 2017, 10:45 AM Tim Bell  wrote:

> OpenStack Nucleus and OpenStack Electrons?
>
> Tim
>
> -Original Message-
> From: Thierry Carrez 
> Organization: OpenStack
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, 15 June 2017 at 14:57
> To: "openstack-dev@lists.openstack.org"  >
> Subject: Re: [openstack-dev] [all][tc] Moving away from "big tent"
> terminology
>
> Sean Dague wrote:
> > [...]
> > I think those are all fine. The other term that popped into my head
> was
> > "Friends of OpenStack" as a way to describe the openstack-hosted
> efforts
> > that aren't official projects. It may be too informal, but I do think
> > the OpenStack-Hosted vs. OpenStack might still mix up in people's
> head.
>
> My original thinking was to call them "hosted projects" or "host
> projects", but then it felt a bit incomplete. I kinda like the "Friends
> of OpenStack" name, although it seems to imply some kind of vetting
> that
> we don't actually do.
>
> An alternative would be to give "the OpenStack project infrastructure"
> some kind of a brand name (say, "Opium", for OpenStack project
> infrastructure ultimate madness) and then call the hosted projects
> "Opium projects". Rename the Infra team to Opium team, and voilà!
>
> --
> Thierry Carrez (ttx)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


I think moving away from "big tent" is fine though the terminology did work
for some people.

I am responding under Tim's note because I think it gets at what we really
want to communicate and takes me to what we have presented in OUI.  We have
Core OpenStack Projects and then a whole community of additional projects
that support cloud functionality.

So, without it being named, or cutesy, though I liked "Friends of
Openstack", can we go with "OpenStack Core Projects" and "Peripheral
OpenStack Projects"?

Hope that idea helps.

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] Target classes in Cinder

[Jay Bryant]

I had forgotten that we added this and am guessing that other cores did as
well. As a result, it likely, was not enforced in driver reviews.

I need to better understand the benefit. In don't think there is a hurry to
remove this right now. Can we put it on the agenda for Denver?

Jay
On Fri, Jun 2, 2017 at 4:14 PM Eric Harney  wrote:

> On 06/02/2017 03:47 PM, John Griffith wrote:
> > Hey Everyone,
> >
> > So quite a while back we introduced a new model for dealing with target
> > management in the drivers (ie initialize_connection, ensure_export etc).
> >
> > Just to summarize a bit:  The original model was that all of the target
> > related stuff lived in a base class of the base drivers.  Folks would
> > inherit from said base class and off they'd go.  This wasn't very
> flexible,
> > and it's why we ended up with things like two drivers per backend in the
> > case of FibreChannel support.  So instead of just say having
> "driver-foo",
> > we ended up with "driver-foo-iscsi" and "driver-foo-fc", each with their
> > own CI, configs etc.  Kind of annoying.
>
> We'd need separate CI jobs for the different target classes too.
>
>
> > So we introduced this new model for targets, independent connectors or
> > fabrics so to speak that live in `cinder/volume/targets`.  The idea being
> > that drivers were no longer locked in to inheriting from a base class to
> > get the transport layer they wanted, but instead, the targets class was
> > decoupled, and your driver could just instantiate whichever type they
> > needed and use it.  This was great in theory for folks like me that if I
> > ever did FC, rather than create a second driver (the pattern of 3
> classes:
> > common, iscsi and FC), it would just be a config option for my driver,
> and
> > I'd use the one you selected in config (or both).
> >
> > Anyway, I won't go too far into the details around the concept (unless
> > somebody wants to hear more), but the reality is it's been a couple years
> > now and currently it looks like there are a total of 4 out of the 80+
> > drivers in Cinder using this design, blockdevice, solidfire, lvm and drbd
> > (and I implemented 3 of them I think... so that's not good).
> >
> > What I'm wondering is, even though I certainly think this is a FAR
> SUPERIOR
> > design to what we had, I don't like having both code-paths and designs in
> > the code base.  Should we consider reverting the drivers that are using
> the
> > new model back and remove cinder/volume/targets?  Or should we start
> > flagging those new drivers that don't use the new model during review?
> > Also, what about the legacy/burden of all the other drivers that are
> > already in place?
> >
> > Like I said, I'm biased and I think the new approach is much better in a
> > number of ways, but that's a different debate.  I'd be curious to see
> what
> > others think and what might be the best way to move forward.
> >
> > Thanks,
> > John
> >
>
> Some perspective from my side here:  before reading this mail, I had a
> bit different idea of what the target_drivers were actually for.
>
> The LVM, block_device, and DRBD drivers use this target_driver system
> because they manage "local" storage and then layer an iSCSI target on
> top of it.  (scsi-target-utils, or LIO, etc.)  This makes sense from the
> original POV of the LVM driver, which was doing this to work on multiple
> different distributions that had to pick scsi-target-utils or LIO to
> function at all.  The important detail here is that the
> scsi-target-utils/LIO code could also then be applied to different
> volume drivers.
>
> The Solidfire driver is doing something different here, and using the
> target_driver classes as an interface upon which it defines its own
> target driver.  In this case, this splits up the code within the driver
> itself, but doesn't enable plugging in other target drivers to the
> Solidfire driver.  So the fact that it's tied to this defined
> target_driver class interface doesn't change much.
>
> The question, I think, mostly comes down to whether you get better code,
> or better deployment configurability, by a) defining a few target
> classes for your driver or b) defining a few volume driver classes for
> your driver.   (See coprhd or Pure for some examples.)
>
> I'm not convinced there is any difference in the outcome, so I can't see
> why we would enforce any policy around this.  The main difference is in
> which cinder.conf fields you set during deployment, the rest pretty much
> ends up the same in either scheme.
>
> __
> 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...@lis

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Jay Bryant]

On 5/23/2017 9:56 AM, Duncan Thomas wrote:



On 23 May 2017 4:51 am, "Matt Riedemann" > wrote:




Is this really something we are going to have to deny at least
once per release? My God how is it that this is the #1 thing
everyone for all time has always wanted Nova to do for them?


Is it entirely unreasonable to turn the question around and ask why, 
given it is such a commonly requested feature, the Nova team are so 
resistant to 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


I am going to jump into the fray here ...

I think that at some point we need to do a cost/benefit analysis.  If 
customers really want this, than maybe it is worth the potential 
technical debt.  Going down a route of hacking something together from 
the client seems to potentially incur more technical debt and create a 
worse UX.


At the risks of having things thrown at me, I am going to say that this 
could have a number of benefits.  It could be leveraged by the Cinder 
Ephemeral driver that is being considered.  Volume types associated with 
compute hosts could be used to ensure use of storage local to the 
compute host that is managed by Cinder.


Anyway, that is my $0.02.

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] [ptg] How to slice the week to minimize conflicts

[Jay Bryant]

I had expected more cinder/nova sessions the first days, so I like that
proposal.

If we are able to minimize project overlap or have alternatives the last 3
days I think we are moving towards a better solution.

Jay
On Fri, May 19, 2017 at 9:18 AM Thierry Carrez 
wrote:

> Emilien Macchi wrote:
> > On Thu, May 18, 2017 at 5:27 AM, Thierry Carrez 
> wrote:
> >> After giving it some thought, my current thinking is that we should
> >> still split the week in two, but should move away from an arbitrary
> >> horizontal/vertical split. My strawman proposal would be to split the
> >> week between inter-project work (+ teams that rely mostly on liaisons in
> >> other teams) on Monday-Tuesday, and team-specific work on
> Wednesday-Friday:
> >>
> >> Example of Monday-Tuesday rooms:
> >> Interop WG, Docs, QA, API WG, Packaging WG, Oslo, Goals helproom,
> >> Infra/RelMgt/support teams helpdesk, TC/SWG room, VM&BM Working group...
> >>
> >> Example of Wednesday-Thursday or Wednesday-Friday rooms:
> >> Nova, Cinder, Neutron, Swift, TripleO, Kolla, Infra...
> >
> > I like the idea of continuing to have Deployment tools part of
> > vertical projects room.
> > Though once it's confirmed, I would like to setup a 2 hours slot where
> > we meet together and make some cross-deployment-project collaboration.
> > In Atlanta, we managed to do it on last minute and I found it
> > extremely useful, let's repeat this but scheduled this time.
>
> Actually if you look above, I added the "Packaging WG" in the
> Monday-Tuesday rooms example. You could easily have 1 or 2 days there to
> discuss collaboration between packaging projects, before breaking out
> for 2 or 3 days with your own project team.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] ptgbot: how to make "what's currently happening" emerge

[Jay Bryant]

On 5/18/2017 4:57 AM, Thierry Carrez wrote:

Hi again,

For the PTG events we have, by design, a pretty loose schedule. Each
room is free to organize their agenda in whatever way they see fit, and
take breaks whenever they need. This flexibility is key to keep our
productivity at those events at a maximum. In Atlanta, most teams ended
up dynamically building a loose agenda on a room etherpad.

This approach is optimized for team meetups and people who strongly
identify with one team in particular. In Atlanta during the first two
days, where a lot of vertical team contributors did not really know
which room to go to, it was very difficult to get a feel of what is
currently being discussed and where they could go. Looking into 20
etherpads and trying to figure out what is currently being discussed is
just not practical. In the feedback we received, the need to expose the
schedule more visibly was the #1 request.

It is a thin line to walk on. We clearly don't want to publish a
schedule in advance or be tied to pre-established timeboxes for every
topic. We want it to be pretty fluid and natural, but we still need to
somehow make "what's currently happening" (and "what will be discussed
next") emerge globally.

One lightweight solution I've been working on is an IRC bot ("ptgbot")
that would produce a static webpage. Room leaders would update it on
#openstack-ptg using commands like:

#swift now discussing ring placement optimizations
#swift next at 14:00 we plan to discuss better #keystone integration

and the bot would collect all those "now" and "next" items and publish a
single (mobile-friendly) webpage, (which would also include
ethercalc-scheduled things, if we keep any).

The IRC commands double as natural language announcements for those that
are following activity on the IRC channel. Hashtags can be used to
attract other teams attention. You can announce later discussions, but
the commitment on exact timing is limited. Every "now" command would
clear "next" entries, so that there wouldn't be any stale entries and
the command interface would be kept dead simple (at the cost of a bit of
repetition).

I have POC code for this bot already. Before I publish it (and start
work to make infra support it), I just wanted to see if this is the
right direction and if I should continue to work on it :) I feel like
it's an incremental improvement that preserves the flexibility and
self-scheduling while addressing the main visibility concern. If you
have better ideas, please let me know !


Thierry,

I like this idea and it is consistent with what Cinder tried to do in 
the PTG channel at the last event.  I think formalizing it would be great.


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] [Nova] Extend attached volume

[Jay Bryant]

On 4/1/2017 4:07 PM, Matt Riedemann wrote:

On 4/1/2017 12:17 PM, Jay Bryant wrote:

Matt,

I think discussion on this goes all the way back to Tokyo. There was
work on the Cinder side to send the notification to Nova which I believe
all the pieces were in place for.  The missing part (sticking point) was
doing a rescan of the SCSI bus in the node that had the extended volume
attached.

Has doing that been solved since Tokyo?

Jay



I wasn't in Tokyo so this is all news to me. I don't remember hearing 
about anything like this though.


Ok, I am pretty sure I have notes on this somewhere.  I just need to 
find them.  I will work on doing that as a starting point.


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

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

[Jay Bryant]

Matt,

I think discussion on this goes all the way back to Tokyo.  There was 
work on the Cinder side to send the notification to Nova which I believe 
all the pieces were in place for.  The missing part (sticking point) was 
doing a rescan of the SCSI bus in the node that had the extended volume 
attached.


Has doing that been solved since Tokyo?

Jay

On 4/1/2017 10:34 AM, Matt Riedemann wrote:

On 3/31/2017 8:55 PM, TommyLike Hu wrote:

There was a time when this feature had been both proposed in Cinder [1]
and Nova [2], but unfortunately no one (correct me if I am wrong) is
going to handle this feature during Pike. We do think extending an
online volume is a beneficial and mostly supported by venders feature.
We really don't want this feature missed from OpenStack and would like
to continue on. So anyone could share your knowledge of how many works
are left till now and  where should I start with?

Thanks
TommyLike.Hu

[1] https://review.openstack.org/#/c/272524/
[2]
https://blueprints.launchpad.net/nova/+spec/nova-support-attached-volume-extend 




__ 


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



The nova blueprint description does not contain much for details, but 
from what is there it sounds a lot of like the existing volume swap 
operation which is triggered from Cinder by a volume migration or 
retype operation. How do those existing operations not already solve 
this use case?





__
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] [ptls] Project On-Boarding Rooms

[Jay Bryant]

Kendall,

Did you end up reserving a room for Cinder or did others need it?

Since Sean left it open I wanted to know the status so we could plan 
appropriately.


Thanks!

Jay


On 3/16/2017 3:03 PM, Kendall Nelson wrote:

@James Already have Charms on the list :)

@Telles I can put Sahara down to share with Zun.


On Thu, Mar 16, 2017 at 2:38 PM Telles Nobrega > wrote:


Hello Kendall,

I would like to have a room for Sahara as well, if it is still
possible. We sure can split with other team.

On Thu, Mar 16, 2017 at 10:07 AM Ian Y. Choi mailto:ianyrc...@gmail.com>> wrote:

Hello Kendall!

I18n team loves to have a project on-boarding room for new
translators :)
Please reserve a room for I18n if available.


With many thanks,

/Ian


Kendall Nelson wrote on 3/16/2017 3:20 AM:
> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will
offer
> project on-boarding rooms! This idea is that these rooms
will provide
> a place for new contributors to a given project to find out
more about
> the project, people, and code base. The slots will be spread out
> throughout the whole Summit and will be 90 min long.
>
> We have a very limited slots available for interested
projects so it
> will be a first come first served process. Let me know if
you are
> interested and I will reserve a slot for you if there are
spots left.
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
>

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.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 Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

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

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



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


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

Re: [openstack-dev] [Cinder] PTG Recap

[Jay Bryant]

Sean,

Thank you for getting this note out!

If anyone has comments for improvement of the format, please let me 
know.  Want to continue to improve our access to information and make it 
easier to leverage that information in the future!


Thanks!

Jay Bryant (jungleboyj)


On 3/3/2017 1:42 PM, Sean McGinnis wrote:

I leiu of a lengthy email that very few will read, this is just a
pointer.

Jay Bryant (jungleboyj) did a great job during the PTG of capturing
notes and action items from our discussions. One of the items discussed
was around improving capturing these details and making them easier to
find months and years down the road when we've all forgotten. Basically
a way to avoid the usual statement of "Didn't we discuss this in $CITY".

As part of that, in addition to keeping our etherpads with all the
notes, we have started a section on the Cinder wiki to make this info
easy to find, with links to specific PTG and Forum notes from each
event [1].

Thanks Jay for setting this up.

The recap for the first event can be found here: [2]

Sean (smcginnis)

[1] https://wiki.openstack.org/wiki/Cinder#PTG_and_Summit_Meeting_Summaries
[2] https://wiki.openstack.org/wiki/CinderPikePTGSummary

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



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

Re: [openstack-dev] [Cinder] PTG Recap

[Jay Bryant]

Kendall,

Thanks for getting the topics associated with the videos and everything 
organized.  It is appreciated.


For the next meeting I would like to make sure we come up with a 
standard naming scheme for the videos so that it is clear what videos go 
together.  I think we did pretty well for the PTG but haven't always 
done a good job of that.  I am thinking we should maybe standardize 
around  - Cinder PTG - Day X, Part Y .  Thinking having the 
release name at the beginning just might make the videos easier to keep 
organized.


How we will want to do things for the summit, I guess will depend on 
what the sessions are like there.   - Cinder Forum - Day X, 
Party Y maybe?


Thoughts?

Jay


On 3/3/2017 2:45 PM, Kendall Nelson wrote:

Thanks Sean & Jay!

And for those of you that weren't able to make it to the PTG or if 
there was a conversation you couldn't make it to, here is the Cinder 
youtube channel with all of our discussions from the first two days 
[1], nova discussion included. I added topics to the descriptions of 
the videos so its easier to see what we discussed in each video.


Special thanks to Walt for setting up the streaming :)

- Kendall Nelson (diablo_rojo)

[1] https://www.youtube.com/channel/UCJ8Koy4gsISMy0qW3CWZmaQ

On Fri, Mar 3, 2017 at 1:45 PM Sean McGinnis <mailto:sean.mcgin...@gmx.com>> wrote:


I leiu of a lengthy email that very few will read, this is just a
pointer.

Jay Bryant (jungleboyj) did a great job during the PTG of capturing
notes and action items from our discussions. One of the items
discussed
was around improving capturing these details and making them easier to
find months and years down the road when we've all forgotten.
Basically
a way to avoid the usual statement of "Didn't we discuss this in
$CITY".

As part of that, in addition to keeping our etherpads with all the
notes, we have started a section on the Cinder wiki to make this info
easy to find, with links to specific PTG and Forum notes from each
event [1].

Thanks Jay for setting this up.

The recap for the first event can be found here: [2]

Sean (smcginnis)

[1]
https://wiki.openstack.org/wiki/Cinder#PTG_and_Summit_Meeting_Summaries
[2] https://wiki.openstack.org/wiki/CinderPikePTGSummary

__
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 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] [Ironic] Baremetal Storage Service?

[Jay Bryant]

Akira,

Cinder has been working on creating a standalone service that could run on
bare metal nodes. [1]. I am thinking this could meet your needs or be
enhanced to meet your needs. Don't think we want to create a separate
service for it.

Jay

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

On Sun, Nov 13, 2016 at 1:00 AM Akira Yoshiyama 
wrote:

> Hi Jay,
>
> 2016-11-13 3:12 GMT+09:00 Jay Pipes :
> > On 11/12/2016 09:31 AM, Akira Yoshiyama wrote:
> >>
> >> Hi Stackers,
> >>
> >> In TripleO, Ironic provides physical servers for an OpenStack
> >> deployment but we have to configure physical storages manually, or
> >> with any tool, if required. It's better that an OpenStack service
> >> manages physical storages as same as Ironic for servers.
> >>
> >> IMO, there are 2 plans to manage physical storages:
> >
> > When you say "manage physical storage" are you referring to configuring
> > something like Ceph or GlusterFS or even NFS on a bunch of baremetal
> > servers?
>
> No. "physical storages" means storage products like EMC VNX, NetApp
> Data ONTAP, HPE Lefthand and so on.
> Say there is a new service named X to manage them. A user, he/she will
> be a new IaaS admin, requests many baremetal servers to Ironic and
> some baremetal storages to X. After they are provided, he/she will
> start to build a new OpenStack deployment with them. Nova in the new
> one will provide VMs on the servers and Cinder will manage logical
> volumes on the storages. X doesn't manage each logical volume but
> pools, user accounts and network connections of the storages.
>
> BR,
> Akira
>
> > That isn't a multi-tenant HTTP API service designed for lots of users but
> > rather a need to automate some mostly one-time storage setup actions.
> >
> > If so, I think that is more the realm of configuration management systems
> > like Puppet or Ansible than OpenStack itself.
> >
> > Best,
> > -jay
> >
> >> a) extends Ironic
> >> b) creates a new service
> >>
> >> Which is better? Any ideas?
> >>
> >> Thank you,
> >> Akira
>
> __
> 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] [tc][cinder] tag:follows-standard-deprecation should be removed

[Jay Bryant]

I agree with Duncan here. Driver removal has been an important tool to keep
only maintained drivers in the tree and a way to get attention to ignored
drivers. I hate to see the tag removed but think we need to stay true to
the approach we have been taking.

Re-addressing the meaning of the tag with regards to drivers will be
necessary so that we can communicate that Cinder Core is compliant though
we can't guarantee driver compliance.

Jay

On Thu, Aug 11, 2016 at 9:48 AM Duncan Thomas 
wrote:

> Given the options, I'd agree with Sean and John that removing the tag is a
> far lesser evil than changing our policy.
>
> If we leave broken drivers in the tree, the end user (operator) is no
> better off - the thing they evaluated won't work - but it will be harder to
> tell why. The storage vendor won't suffer the pressure that comes from
> driver removal, so will have less incentive to fix their driver (there's
> enough examples of the threat of driver removal causing the immediate fix
> of things that have remained broken for months that we know, for certain
> that the policy works).
>
> I'd prefer to make the meaning of the tag sane WRT third party drivers,
> which I think would help other projects to be able to police their drivers
> and CI better too, without risking losing / not gaining the tag, which is
> likely to hurt a newer project far more than it will cinder.
>
>
>
> On 11 August 2016 at 17:29, John Griffith 
> wrote:
>
>>
>>
>> On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja  wrote:
>>
>>> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis 
>>> wrote:
>>> >> >>
>>> >> >> As follow up on the mailing list discussion [0], gerrit activity
>>> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
>>> >> >> discussion how Cinder follows, or rather does not follow, the
>>> standard
>>> >> >> deprecation policy [4] as the project has been tagged on the assert
>>> >> >> page [5].
>>> >> >>
>>> > 
>>> >> >>
>>> >> >> [0]
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
>>> >> >> [1] https://review.openstack.org/#/c/348032/
>>> >> >> [2] https://review.openstack.org/#/c/348042/
>>> >> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>>> >> >> [4]
>>> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
>>> >> >> [5]
>>> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
>>> >> >>
>>> >> >
>>> >> > Can you be more specific about what you mean? Are you saying that
>>> >> > the policy isn't being followed because the drivers were removed
>>> >> > without a deprecation period, or is there something else to it?
>>> >> >
>>> >> > Doug
>>> >> >
>>> >>
>>> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
>>> >> be removed without any warning to the consumers while the standard
>>> >> deprecation policy defines quite strict lines about informing the
>>> >> consumer of the functionality deprecation before it gets removed.
>>> >>
>>> >> - Erno
>>> >
>>> > It is a good point. I think it highlights a common thread though with
>>> > the other discussion that, at least so far, third party drivers are
>>> > treated differently than the rest of the code.
>>> >
>>> > For any other functionality we certainly follow the deprecation policy.
>>> > Even in existing drivers we try to enforce that any driver renames,
>>> > config setting changes, and similar non-backwards compatible changes go
>>> > through the normal deprecation cycle before being removed.
>>> >
>>> > Ideally I would love it if we could comply with the deprecation policy
>>> > with regards to driver removal. But the reality is, if we don't see
>>> that
>>> > a driver is being supported and maintained by its vendor, then that
>>> > burden can't fall on the wider OpenStack and Cinder community that has
>>> > no way of validating against physical hardware.
>>> >
>>> > I think third party drivers need to be treated differently when it
>>> comes
>>> > to the deprecation policy. If that is not acceptable, then I suppose we
>>> > do need to remove that tag. Tag removal would be the lesser of the two
>>> > versus keeping around drivers that we know aren't really being
>>> > maintained.
>>> >
>>> > If it came to that, I would also consider creating a new cinder-drivers
>>> > project under the Cinder umbrella and move all of the drivers not
>>> tested
>>> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
>>> > would try to avoid that if possible. But it would at least allow us to
>>> > still get code reviews and all of the benefits of being in tree. Just
>>> > some thoughts.
>>> >
>>> > Sean
>>> >
>>>
>>> Sean,
>>>
>>> As said on my initial opening, I do understand and agree with the
>>> reasoning/treatment of the 3rd party drivers. My request for that tag
>>> removal is out of the remains of my ops hat.
>>>
>>> Lets say I was ops evaluating different opt

Re: [openstack-dev] [Openstack-operators] [cinder] [nova] locking concern with os-brick

[Jay Bryant]

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

I think we need to pull Walt and Kendall in and come up with a safer
solution to this.

That is my 2 cents. :-)

Jay

On Sat, Aug 13, 2016 at 5:07 PM Matt Riedemann 
wrote:

> On 8/12/2016 8:54 AM, Matt Riedemann wrote:
> > On 8/12/2016 8:52 AM, Matt Riedemann wrote:
> >> On 8/12/2016 8:24 AM, Sean McGinnis wrote:
> >>> On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote:
>  A devstack patch was pushed earlier this cycle around os-brick -
>  https://review.openstack.org/341744
> 
>  Apparently there are some os-brick operations that are only safe if
> the
>  nova and cinder lock paths are set to be the same thing. Though that
>  hasn't yet hit release notes or other documentation yet that I can
> see.
> >>>
> >>> Patrick East submitted a patch to add a release note on the Cinder side
> >>> last night: https://review.openstack.org/#/c/354501/
> >>>
>  Is this a thing that everyone is aware of at this point? Are project
>  teams ok with this new requirement? Given that lock_path has no
>  default,
>  this means we're potentially shipping corruption by default to users.
>  The other way forward would be to revisit that lock_path by default
>  concern, and have a global default. Or have some way that users are
>  warned if we think they aren't in a compliant state.
> >>>
> >>> This is a very good point that we are shipping corruption by default. I
> >>> would actually be in favor of having a global default. Other than
> >>> requiring tooz for default global locking (with a lot of extra overhead
> >>> for small deployments), I don't see a better way of making sure the
> >>> defaults are safe for those not aware of the issue.
> >>>
> >>> And IMO, having the release note is just a CYA step. We can hope
> someone
> >>> reads it - and understands it's implications - but it likely will be
> >>> missed.
> >>>
> >>> Anyway, that's my 2 cents.
> >>>
> >>> Sean
> >>>
> 
>  I've put the devstack patch on a -2 hold until we get ACK from both
>  Nova
>  and Cinder teams that everyone's cool with this.
> 
>  -Sean
> 
>  --
>  Sean Dague
>  http://dague.net
> 
> 
> __
> 
> 
>  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
> >>>
> >>
> >> I saw the nova one last night:
> >>
> >> https://review.openstack.org/#/c/354502/
> >>
> >> But I don't know the details, like what are the actual specific things
> >> that fail w/o this? Vague "trust me, you need to do this or else"
> >> release notes that impact how people deploy is not fun, so I'd like more
> >> details before we just put this out there.
> >>
> >
> > This is also probably something that should be advertised on the
> > openstack-operators ML. I would at least feel more comfortable if this
> > is a known thing that operators have already been dealing with and we
> > just didn't realize.
> >
>
> I checked a tempest-dsvm CI run upstream and we don't follow this
> recommendation for our own CI on all changes in OpenStack, so before we
> make this note in the release notes, I'd like to see us use the same
> lock_path for c-vol and n-cpu in devstack for our CI runs.
>
> Also, it should really be a note in the help text of the actual
> lock_path option IMO since it's a latent and persistent thing that
> people are going to need to remember after newton has long been released
> and people deploying OpenStack for the first time AFTER newton shouldn't
> have to know there was a release note telling them not to shoot
> themselves in the foot, it should be in the config option help text.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] How to develop a new [Cinder] driver?

[Jay Bryant]

Turbo,

First, trying to understand why you are trying to create a new driver for
Mitaka. New drivers need to go into the latest release. More information
can be found here:
https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

Second, there really isn't any other way with Python, that I know of, other
than making changes and restarting. That is just kind of the way that
Python works.

Third, it sounds to me like you are not getting the image you want to copy
to the volume node where you are running properly. Unless the image you are
copying is on the same backing storage it needs to be mounted on the
control node and then dd'ed, or something similar, into an image you have
created on your backend.

Hope this helps

Jay

On Fri, Jul 15, 2016 at 3:24 PM Turbo Fredriksson  wrote:

> On Jul 15, 2016, at 9:33 PM, Turbo Fredriksson wrote:
>
> > Is there a simpler way to do this?
>
>
> A followup question on that: I'm using a remote SAN
> and I've gotten the creation/deletion/iSCSI share/unshare
> on that to work just fine.
>
> However, when creating a volume from an image, the driver
> fails on copying the image to the volume. Which is kind'a
> obvious I guess, it's not (yet?) available on localhost..
>
> I was thinking about login to the target, copy the
> image onto the device that's created.
>
> But that just don't seem to be a very .. "nice" way to
> do it.. Is there a better one?
> --
> Med ett schysst järnrör slår man hela världen med häpnad
> - Sockerconny
>
>
> __
> 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][openstackclient] Required name option for volumes, snapshots and backups

[Jay Bryant]

Duncan,

Agreed, but the OSC team is concerned about unnecessarily adding API names
into commands as much as the Cinder team wishes to make it clearer which
commands belong to our component. This is where we need to keep this
discussion open with the OSC team to find a good common ground. I am hoping
to have Slade Baumann and Jacob Gregor work this issue actively with Sheel.
We need to pull you in as well given your views on this. I will make sure
they keep you in the loop.

Jay

On Tue, Apr 5, 2016 at 10:24 AM Duncan Thomas 
wrote:

> What about commands the become ambiguous in the future? I doubt there are
> many operations or objects that are unique to Cinder - backup, snapshot,
> transfer, group, type - these are all very much generic, and even if they
> aren't ambiguous now, they might well become so in future...
>
> On 5 April 2016 at 17:15, Jay Bryant 
> wrote:
>
>> All,
>>
>> Just to document the discussion we had during the OSC IRC meeting last
>> week: I believe the consensus we reached was that it wasn't appropriate to
>> pretend "volume" before all Cinder commands but that it would be
>> appropriate to move in that direction to for any commands that may be
>> ambiguous like "snapshot". The cinder core development team will start
>> working with the OSC development teams to address such commands and move
>> them to more user friendly commands and as we move forward we will work to
>> avoid such confusion in the future.
>>
>> Jay
>>
>> On Mon, Mar 28, 2016 at 1:15 PM Dean Troyer  wrote:
>>
>>> On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez  wrote:
>>>
>>>> On 00:40 Mar 28, Jordan Pittier wrote:
>>>> > I am going to play the devil's advocate here but why can"t
>>>> > python-openstackclient have its own opinion on the matter ? This CLI
>>>> seems
>>>> > to be for humans and humans love names/labels/tags and find UUIDS
>>>> hard to
>>>> > remember. Advanced users who want anonymous volumes can always hit
>>>> the API
>>>> > directly with curl or whatever SDK.
>>>>
>>>> I suppose it could, however, names are not unique.
>>>>
>>>
>>> Names are not unique in much of OpenStack.  When ambiguity exists, we
>>> exit with an error.
>>>
>>> Also, this works to produce a volume with no name should you absolutely
>>> require it:
>>>
>>> openstack volume create --size 10 ""
>>>
>>>
>>> dt
>>> --
>>>
>>> Dean Troyer
>>> dtro...@gmail.com
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> --
> 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][openstackclient] Required name option for volumes, snapshots and backups

[Jay Bryant]

All,

Just to document the discussion we had during the OSC IRC meeting last
week: I believe the consensus we reached was that it wasn't appropriate to
pretend "volume" before all Cinder commands but that it would be
appropriate to move in that direction to for any commands that may be
ambiguous like "snapshot". The cinder core development team will start
working with the OSC development teams to address such commands and move
them to more user friendly commands and as we move forward we will work to
avoid such confusion in the future.

Jay

On Mon, Mar 28, 2016 at 1:15 PM Dean Troyer  wrote:

> On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez  wrote:
>
>> On 00:40 Mar 28, Jordan Pittier wrote:
>> > I am going to play the devil's advocate here but why can"t
>> > python-openstackclient have its own opinion on the matter ? This CLI
>> seems
>> > to be for humans and humans love names/labels/tags and find UUIDS hard
>> to
>> > remember. Advanced users who want anonymous volumes can always hit the
>> API
>> > directly with curl or whatever SDK.
>>
>> I suppose it could, however, names are not unique.
>>
>
> Names are not unique in much of OpenStack.  When ambiguity exists, we exit
> with an error.
>
> Also, this works to produce a volume with no name should you absolutely
> require it:
>
> openstack volume create --size 10 ""
>
>
> dt
> --
>
> Dean Troyer
> dtro...@gmail.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Let's do presentations/sessions on Mitaka's new complex features in Design Summit

[Jay Bryant]

Great idea Gorka! I know I could benefit from this as a reviewer.

Thanks for proposing it.

Jay

On Mon, Mar 14, 2016 at 3:52 PM Gorka Eguileor  wrote:

> Hi,
>
> As you all probably know, during this cycle we have introduced quite a
> big number of changes in cinder that will have a great impact in the
> development of the new functionality as well as changes to existing ones
> moving forward from an implementation perspective.
>
> These changes to the cinder code include, but are not limited to,
> microversions, rolling upgrades, and conditional DB update functionality
> to remove API races, and while the latter has a good number of examples
> already merged and more patches under review, the other 2 have just been
> introduced and there are no patches in cinder that can serve as easy
> reference on how to use them.
>
> As cinder developers we will all have to take these changes into account
> in our new patches, but it is hard to do so when one doesn't have an
> in-depth knowledge of them, and while we all probably know quite a bit
> about them, it will take some time to get familiar enough to be aware of
> *all* the implications of the changes made by newer patches.
>
> And it's for this reason that I would like to suggest that during this
> summit's cinder design sessions we take the time to go through the
> changes giving not only an example of how they should be used in a
> patch, but also the do's, dont's and gotchas.
>
> A possible format for these explanations could be a presentation -around
> 30 minutes- by the people that were involved in the development,
> followed by Q&A.
>
> I would have expected to see some of these in the "Upstream Dev" track,
> but unfortunately I don't (maybe I'm just missing them with all the cool
> title names).  And maybe these talks are not relevant for that track,
> being so specific and only relevant to cinder developers and all.
>
> I believe these presentations would help the cinder team increase the
> adoption speed of these features while reducing the learning curve and
> the number of bugs introduced in the code caused by gaps in our
> knowledge and misinterpretations of the new functionality.
>
> I would take lead on the conditional DB updates functionality, and I
> would have no problem doing the Rolling upgrades presentation as well.
> But I believe there are people more qualified and more deserving of
> doing that one; though I offer my help if they want it.
>
> I have added those 3 topics to the Etherpad with Newton Cinder Design
> Summit Ideas [1] so people can volunteer and express their ideas in
> there.
>
> Cheers,
> Gorka.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Nominating Patrick East to Cinder Core

[Jay Bryant]

+1. Patrick's contributions to Cinder have been notable since he joined us
and he is a pleasure to work with!   Welcome to the core team Patrick!

Jay

On Fri, Jan 29, 2016, 19:05 Sean McGinnis  wrote:

> Patrick has been a strong contributor to Cinder over the last few
> releases, both with great code submissions and useful reviews. He also
> participates regularly on IRC helping answer questions and providing
> valuable feedback.
>
> I would like to add Patrick to the core reviewers for Cinder. Per our
> governance process [1], existing core reviewers please respond with any
> feedback within the next five days. Unless there are no objections, I will
> add Patrick to the group by February 3rd.
>
> Thanks!
>
> Sean (smcginnis)
>
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

[Jay Bryant]

All,

Has anyone found a way to do code reviews on an iPad. In the old Gerrit you
could. With the new interface attempts to enter comments don't work. It
looks like you should be able to enter text but when you type the page just
jumps around. Very frustrating.

I have tried Safari and Chrome with no luck.

Jay

On Tue, Dec 22, 2015 at 5:31 AM Steve Gordon  wrote:

> - Original Message -
> > From: "Lenny Verkhovsky" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > Hi,
> > After Upgrading to 2.11 seems that
> > lastcomment (
> >
> https://github.com/openstack/third-party-ci-tools/tree/master/monitoring/lastcomment-scoreboard
> > )
> >   monitoring tool stopped working
> >
> > I've posted a small patch https://review.openstack.org/#/c/259083/ to
> fix the
> > issue,
> > But I wander if there is a proper rest query to for CI name?
> > Currently there is only account_id field in Gerrit response and it's not
> > really human readable.
>
> I ran into this with a custom script as well, you can use the account_id
> in a request of the form:
>
> review.openstack.org/accounts//name
>
> ...to get a human readable account name.
>
> -Steve
>
> > Lennyb.
> >
> >
> > -Original Message-
> > From: Zaro [mailto:zaro0...@gmail.com]
> > Sent: Tuesday, December 22, 2015 3:21 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver
> 2.11,
> > completed.
> >
> > Hit '?' and it says '/' is find, give that a try.
> >
> > Looks like in Gerrit 2.11 the 'f' to get a popup of the list of files is
> only
> > available in unified diff view.  I don't remember if it was available in
> > side-by-side view on Gerrit 2.8.
> >
> > -Khai
> >
> >
> > On Mon, Dec 21, 2015 at 5:04 PM, Carl Baldwin 
> wrote:
> > > I also really miss being able to pull up the list of files in diff
> > > view with the 'f' key.  Any equivalent?
> > >
> > > Carl
> > >
> > > On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin 
> wrote:
> > >> I noticed a couple of things today while reviewing a largish page [1].
> > >> First, when I search for something using the browser's builtin search
> > >> (Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that
> > >> are not in the visible portion of the page.  For example, when I
> > >> search for DNSDOMAIN, I get 1 hit from the top of the file.  The file
> > >> actually has almost 30 hits for this string.  For example, scroll
> > >> down to about L310 in the file.  You'll see them all over the place
> > >> (and now Chrome's search finds these hits if you try again).  I use
> > >> to use search within a file with the old gerrit and never noticed
> > >> this problem.
> > >>
> > >> The other thing that I found annoying is when I scroll the page with
> > >> my trackpad, it now jumps around sometimes to a different part of the
> > >> page.  For example, I'll scroll up to find a spot in the file and
> > >> when I think I've arrived, it will jump back down the file a bit.  It
> > >> is disorienting.  Of course, now it isn't doing it anymore so it
> > >> doesn't seem to be all the time.  It was behaving this way for a good
> > >> 20 minutes trying to get through this file.
> > >>
> > >> Carl
> > >>
> > >> Carl
> > >>
> > >> [1] https://review.openstack.org/#/c/212213/36/neutron/db/dns_db.py
> > >>
> > >> On Thu, Dec 17, 2015 at 8:17 PM, Brian Haley 
> wrote:
> > >>> On 2015-12-16 16:24, openstack-dev-requ...@lists.openstack.org
> wrote:
> > 
> >  Thanks to everyone for their patience while we upgraded to Gerrit
> >  2.11.  I'm happy to announce that we were able to successfully
> >  completed this task at around 21:00 UTC.  You may hack away once
> more.
> > 
> >  If you encounter any problems, please let us know here or in
> >  #openstack-infra on Freenode.
> > >>>
> > >>>
> > >>> I'm still undecided on 2.11, have to give it more time, but I have
> > >>> noticed one thing that's annoying...
> > >>>
> > >>> Trying to copy text from a review no longer works easily.  When I
> > >>> highlight text there's a little "bubble" pop-up of {press c to
> > >>> comment}, which seems to interfere with both my three-button mouse
> copy
> > >>> buffer, as well as Ctrl-C.
> > >>> Call me a nitpicker, but having to highlight text, right-button
> > >>> click, Copy, right-button click, Paste, is a pain.
> > >>>
> > >>> Maybe someone has a simple work-around for that.
> > >>>
> > >>> -Brian
> > >>>
> > >>> 
> > >>> __ 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 fo

Re: [openstack-dev] [cinder] FFE Request - capacity-headroom

[Jay Bryant]

Since Mike is out I wanted to respond to this:

I don't think we a re planning to take FFE requests this time around. Also,
the core team discussed this particular item and felt that there are still
too many open questions on the patch and the patch is too invasive to merge
this late in the game.

Please resubmit for Mitaka.

Thanks!
Jay
On Wed, Sep 2, 2015 at 6:38 AM Xin, Xiaohui  wrote:

> Hi,
>
> I would like to request feature freeze exception for the implementation of
> capacity-headroom.
>
> It calculates virtual free memory and send notifications to the ceilometer
> together with other storage capacity stats.
>
>
> Blueprint:
>
> https://blueprints.launchpad.net/cinder/+spec/capacity-headroom
>
>
> Spec:
> https://review.openstack.org/#/c/170380/
>
>
>
> Addressed by:
>
> https://review.openstack.org/#/c/206923
>
>
>
>
> I have addressed the latest comments related to active-active deployment
> according to Gorka Eguileor’s comments and suggestions.
>
> Please kindly review and evaluate it. Great Thanks!
>
>
>
> Thanks
>
> Xiaohui
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Extending attached disks

[Jay Bryant]

Taylor,

I am adding some IBMers who are also looking into making this work. PowerVC
has a solution hacked into place but we are working on getting a more
general solution implemented for Mitaka. Hoping we can all work together to
get a solution in place.

Will you be in Tokyo? If so, it would be good to have a plan together to
discuss there.

Gerald and Sam,

Can you guys join the OpenStack dev mailing list and continue the
discussion?

Thanks!
Jay

On Fri, Aug 21, 2015 at 8:20 PM  wrote:

> For RBDs it IS as simple as making calls to virsh after an attached volume
> is extended. I've done it half a dozen time with no intermediate steps and
> it works. I'd love to test it more robustly, obviously, but unfortunately I
> got bigger fish to fry with BAU.
>
> iSCSI might involve more work, I acknowledge that, but there is nothing
> wrong with putting the framework in place now and throwing an "unsupported
> volume type" error message if we haven't worked out the best method for
> doing this for a particular type.
>
> The way I see it, the only ones that are going to cause us problems are
> ones that require the host to suspend the disk prior to operating on it. In
> other words if the notification to the host can't be done atomically, that
> could definitely cause issues.
>
> However, all the examples I have seem implemented in OpenStack volumes
> thus far (iSCSI, RDB) are either atomic or no notification required (in the
> case of RBD). Even Multipath is atomic (granted, it's multiple chained
> atomic operations, but still, they won't be left in an irrecoverable
> failure state).
>
> Yes, the page you linked does warn about the issue when there is no path
> the device, however I think that if you're trying to resize a volume the
> compute node can't connect to, you got bigger problems (that is to say,
> throwing an error here is perfectly reasonable).
>
> Regards,
>
> Taylor Bertie
> Enterprise Support Infrastructure Engineer
>
> Mobile +64 27 952 3949
> Phone +64 4 462 5030
> Email taylor.ber...@solnet.co.nz
>
> Solnet Solutions Limited
> Level 12, Solnet House
> 70 The Terrace, Wellington 6011
> PO Box 397, Wellington 6140
>
> www.solnet.co.nz
>
>
> -"Walter A. Boring IV"  wrote: -
> To: openstack-dev@lists.openstack.org
> From: "Walter A. Boring IV" 
> Date: 2015-08-22 7:13
> Subject: Re: [openstack-dev] [nova][cinder] Extending attached disks
>
> This isn't as simple as making calls to virsh after an attached volume
> is extended on the cinder backend, especially when multipath is involved.
> You need the host system to understand that the volume has changed size
> first, or virsh will really never see it.
>
> For iSCSI/FC volumes you need to issue a rescan on the bus (iSCSI
> session, FC fabric),  and then when multipath is involved, it gets quite
> a bit more complex.
>
> This lead to one of the sticking points with doing this at all, is
> because when cinder extends the volume, it needs to tell nova that it
> has happened, and the nova (or something on the compute node), will have
> to issue the correct commands in sequence for it all to work.
>
> You'll also have to consider multi-attached volumes as well, which adds
> yet another wrinkle.
>
> A good quick source of some of the commands and procedures that are
> needed you can see here:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/online-logical-units.html
>
>
> You can see that volumes with multipath requires a lot of hand holding
> to be done correctly.  It's non trivial.  I see this as being very error
> prone, and any failure
> in the multipath process could lead to big problems :(
>
> Walt
> > Hi everyone,
> >
> > Apologises for the duplicate send, looks like my mail client doesn't
> create very clean HTML messages. Here is the message in plain-text. I'll
> make sure to send to the list in plain-text from now on.
> >
> > In my current pre-production deployment we were looking for a method to
> live extend attached volumes to an instance. This was one of the
> requirements for deployment. I've worked with libvirt hypervisors before so
> it didn't take long to find a workable solution. However I'm not sure how
> transferable this will be across deployment models. Our deployment model is
> using libvirt for nova and ceph for backend storage. This means obviously
> libvirt is using rdb to connect to volumes.
> >
> > Currently the method I use is:
> >
> > - Force cinder to run an extend operation.
> > - Tell Libvirt that the attached disk has been extended.
> >
> > It would be worth discussing if this can be ported to upstream such that
> the API can handle the leg work, rather than this current manual method.
> >
> > Detailed instructions.
> > You will need: volume-id of volume you want to resize,
> hypervisor_hostname and instance_name from instance volume is attached to.
> >
> > Example: extending volume f9fa66ab-b29a-40f6-b4f4-e9c64a155738 attached
> to instance-000

Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

[Jay Bryant]

Thierry,

Well put, and interesting. I didn't know about the other cultural concerns
around numbers.

Most importantly, I think using names for releases is better than numbers,
creating a more personal connection to each release. Would hate to see that
end.

Unfortunately there isn't much we can do to avoid legal concerns. If people
are more frustrated by having legal on the backend, it sounds like we have
an alternative to return to. If all else fails we could vote on which
process was preferred after the M release.

Jay

On Fri, Jul 10, 2015 at 4:20 AM Thierry Carrez 
wrote:

> Adam Lawson wrote:
> > The alternative of course is to just number the releases since names
> > ultimately don't mean anything but it seems there are problems with that
> > level of simplicity. I personally prefer Tristan's suggestion to keep it
> > as simple as possible. In a few years we'll run out of letters anyway.
>
> Part of the confusion here is that we are not naming "releases". We are
> naming release *cycles*. We are giving a name to a period of time,
> basically. In that period of time, various version numbers for various
> components will be released. Saying "Glance 12.0.0 was released in
> OpenStack 13 cycle" is not really helping.
>
> We won't run out of letters, because the names can cycle back to A
> (potentially using a new theme, away from "geographic features near
> where the corresponding design summit happened").
>
> So while we could technically name a release cycle "14", I feel it's a
> bit more difficult to rally around a number than a name. Also, numbers
> wouldn't really solve the perceived issues with names: numbers happen to
> also be culturally meaningful. You don't have a 13th floor in many US
> buildings. In China, building miss the 4th floor instead. 9 is feared in
> Japan. And don't talk about 39 to Afghans.
>
> I think "growing up" is accepting the pain that comes with picking a
> good name, rather than sidestepping the issue.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Thoughts on ReleaseNoteImpact git commit message tag

[Jay Bryant]

This question has come up several times for Cinder. I personally think it
would be a good thing to add to help avoid things getting missed for
release notes. It does have the drawback of effecting cherry picks but that
doesn't seem like a huge problem.

Jay

On Wed, Jul 8, 2015 at 11:46 AM Thierry Carrez 
wrote:

> Soren Hansen wrote:
> > Putting release notes in the git repo so that they simply will get
> > merged along with the corresponding code seems like a no-brainer. What
> > am I missing?
>
> For stable branches it prevents us from just backporting master changes
> using straight cherry-picks.
>
> For example you want to tweak the stable release notes for every CVE you
> end up fixing post-release in the stable branch. You have a master fix
> that happens to update the master release notes. Cherry-picking that
> will not cover your stable release notes, so you'll have to alter the
> fix to drop the master release note change and add a stable release note
> change.
>
> Doesn't mean it's not an option, but it adds pain compared to the
> current situation.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno

[Jay Bryant]

I too would prefer option 2. Would rather do the pack ports than remove the
functionality.

Jay

On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor  wrote:

> On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote:
> > There was a bug raised [1] from some large deployments that the Cinder
> > client 1.2.0 and beyond is not working because of version discovery.
> > Unfortunately it's not taking into account of deployments that have a
> > proxy.
>
> A little bit unrelated, but volume pagination in Cinder client is also
> broken due to Version Discovery:
> https://bugs.launchpad.net/python-cinderclient/+bug/1453755
>
> >
> > Cinder client asks Keystone to find a publicURL based on a version.
> > Keystone will gather data from the service catalog and ask Cinder for
> > a list of the public endpoints and compare. For the proxy cases,
> > Cinder is giving internal URLs back to the proxy and Keystone ends up
> > using that instead of the publicURL in the service catalog. As a
> > result, clients usually won't be able to use the internal URL and
> > rightfully so.
> >
> > This is all correctly setup on the deployer's side, this an issue with
> > the server side code of Cinder.
> >
> > There is a patch that allows the deployer to specify a configuration
> > option public_endpoint [2] which was introduced in a patch in Kilo
> > [3]. The problem though is we can't expect people to already be
> > running Kilo to take advantage of this, and it leaves deployers
> > running stable releases of Juno in the dark with clients upgrading and
> > using the latest.
> >
> > Two options:
> >
> > 1) Revert version discovery which was introduced in Kilo for Cinder
> client.
> >
> > 2) Grant exception on backporting [4] a patch that helps with this
> > problem, and introduces a config option that does not change default
> > behavior. I'm also not sure if this should be considered for Icehouse.
>
> +1 to option 2 and I wouldn't be totally against considering it for
> Icehouse.
>
> Cheers,
> Gorka.
> >
> >
> > [1] - https://launchpad.net/bugs/1464160
> > [2] -
> http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html
> > [3] - https://review.openstack.org/#/c/159374/
> > [4] - https://review.openstack.org/#/c/194719/
> >
> > --
> > Mike Perez
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Need help from folks working on Dell, Storpool and Infortrend drivers

[Jay Bryant]

Vincent,

Best place to start is with Sean McGinnis.

Jay

On Sun, Jun 28, 2015 at 10:00 PM Sheng Bo Hou  wrote:

> Hi everyone,
>
> For folks who are working on Dell, Storpool and Infortrend drivers:
> I have got a new patch for https://review.openstack.org/#/c/180873. There
> is a change about how to implement the method update_migrated_volume for
> each driver.
> The code needs to return the final values for the key _name_id and
> provider_location. I have changed accordingly in your driver, but I am no
> 100% sure of the precision, so I need your reviews on the changes about
> your driver. If there is any comment, tell me how to change it. You can
> take the implementation for Storwize as a reference.
>
>- First, check if the rename works the same for both the 'available'
>or 'in-use' volumes. It is possible to handle differently.
>- Then check if the rename is successful, it may return different
>_name_id and provider_location values.
>- There is an explanation about the update_migrated_volume in
>https://review.openstack.org/#/c/180873/67/cinder/volume/driver.py
>
>
>
> Thank you.
>
> Best wishes,
> Vincent Hou (侯胜博)
>
> Staff Software Engineer, Open Standards and Open Source Team, Emerging
> Technology Institute, IBM China Software Development Lab
>
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
> West Road, Haidian District, Beijing, P.R.C.100193
> 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] The unbearable lightness of specs

[Jay Bryant]

+1. I think this is a good comment for all reviews. I have been frustrated
lately with a number of reviews that I spent time upon but didn't feel
should be scored. I think that 0 with comments should be counted as well.

On Fri, Jun 26, 2015 at 2:27 PM Tim Bell  wrote:

> > -Original Message-
> > From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> > Sent: 26 June 2015 16:42
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs
> >
> > On 2015-06-25 16:39:56 + (+), Tim Bell wrote:
> > [...]
> > > One of the problems that I’ve seen is with specs etiquette where
> > > people -1 because they have a question. This is a question of
> > > education rather than a fundamental issue with the process.
> >
> > http://docs.openstack.org/infra/manual/developers.html#peer-review
> > has been updated with a 7th entry addressing this in particular.
> > Hopefully that will help realign reviewers on acceptable vs.
> > unacceptable use of -1 for certain types of questions over time.
>
> I also feel that stackalytics should credit people of a 0 review comment
> on specs. Currently, I think that only non-zero reviews are considered as a
> contribution. My understanding of the workflow is that a 0 is in many cases
> is the constructive way to respond and therefore should be considered as a
> contribution.
>
> Tim
>
> > --
> > Jeremy Stanley
> >
> > __
> > 
> > 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] Some Changes to Cinder Core

[Jay Bryant]

+1 Well deserved.  Welcome to Core Sean! It is a pleasure to work with you!

Thanks to Avishay for all his contributions!  Sorry to see you go.

Jay
On May 22, 2015 4:36 PM, "Mike Perez"  wrote:

> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
>
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>
> Contributions:
> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
>
> 30/90 day review stats:
> http://stackalytics.com/report/contribution/cinder-group/30
> http://stackalytics.com/report/contribution/cinder-group/90
>
> As new contributors step up to help in the project, some move onto
> other things. I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
>
> Cinder core, please reply with a +1 for approval. This will be left
> open until May 29th. Assuming there are no objections, this will go
> forward after voting is closed.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Bryant]

Mike,

This effort has taken quite some time and was going to require hard
decisions to be made at some point.   You have been more than patient in
this process and I commend you for that as well as all the communication.

Thank you for continuing to drive this!

Jay
On Mar 24, 2015 10:55 PM, "Monty Taylor"  wrote:

> On 03/24/2015 06:05 PM, Kyle Mestery wrote:
> > On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann 
> > wrote:
> >
> >> Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400:
> >>>
> >>> Echoing both Thierry and John.  I support Mike’s decision to enforce
> the
> >> requirement. Maintaining drivers in the tree comes with
> responsibilities to
> >> the community and 3rd party CI is one of the them.  Mike enforcing this
> >> requirement was the right action even if a hard one to take.
> >>>
> >>> mark
> >>
> >> Indeed. The deadlines were communicated clearly, and frequently.
> >> Making phone calls to reach out to contributors for issues like
> >> this is exceptional.
> >>
> >> +1000. Enabling contributors is great, but CI systems are an important
> > part of that enablement. I appreciate what Mike has done to drive Cinder
> > towards a quality level for all contributors here. It's a hard stance to
> > take, but saying "No" can sometimes be the right decision.
>
> I'm just going to pile on.
>
> People keep asking us to focus on quality over landing features. It was
> the #1 request from EVERY operator at the recent Ops summit. This is one
> of that facets of doing that. It's hard, and it doesn't always feel good
> to all the parties involved - but it's important.
>
> Thank you, Mike, for sticking to your deadline. OpenStack will be better
> for it.
>
> "If it's not tested, it's broken"
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Bryant]

Mike,

I am communicating this problem with my teams and will get it resolved asap.

Jay
On Mar 26, 2015 1:23 PM, "Mike Perez"  wrote:

> On 09:39 Thu 26 Mar , Mike Perez wrote:
> > As discussed in the last Cinder meeting [1], in order to have your volume
> > driver readded into the Kilo release, you must have a CI reporting and
> stable
> > for five days prior to 4/6.
> >
> > This includes:
> >
> > 1) Providing logs to screen sessions, etc configs, tempest output [2].
> > 2) You should be running around 304 tests if you're following
> instructions from
> >the Cinder third party wiki [3]. If you're running less than that,
> your CI
> >will be *NOT* be considered satisfactory for skipping tests.
> >
> > I will also be emailing individuals who have already asked for
> exceptions, just
> > to make sure communication was clear.
> >
> >
> > [1] -
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-25-16.00.log.html#l-173
> > [2] - http://ci.openstack.org/third_party.html#requirements
> > [3] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> The current CI's not meeting the second requirement:
>
> * Cloudbyte
> * Dell EQL
> * Dell SC FC
> * Dell SC ISCSI
> * EMC VMAX FC
> * EMC VMX ISCSI
> * EMC VNX FC
> * EMC VNX ISCSI
> * EMC XIO FC
> * EMC XIO ISCSI
> * HDS NFS
> * HDS NAS
> * Hitachi HBSD FC
> * Hitach HBSD ISCSI
> * IBM Flash Systems FC
> * IBM Flash Systems ISCSI
> * IBM NAS
> * IBM XIV (couldn't find tempest results to verify)
> * IBM Storwize FC
> * IBM Storwize ISCSI
> * Nimble
> * OpenVStorage
> * Quobyte
> * XIO FC
> * XIO ISCSI
> * Vmware
>
> Pretty sure this is because the previous instructions in the wiki were
> incorrect and are now corrected [1]. This is not the fault of the CI
> maintainers. As mentioned, individual emails are being sent out to get
> this all
> sorted.
>
>
> [1] -
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder]Request to to revisit this patch

[Jay Bryant]

I agree with Walt that reverting this is the right answer.

Please make sure to have your ci running as well for liberty.

Jay
On Mar 4, 2015 2:30 AM, "Zhangni"  wrote:

>  Hi Mike, Jay, and Walter,
>
>
>
> Please revisit this patch https://review.openstack.org/#/c/151959/ and
> don’t revert this, thank you very much!
>
>
>
> I think it’s apposite to merge the SDSHypervisor driver in cinder first,
> and next to request nova to add a new libvirt volume driver.
>
>
>
> Meanwhile nova side always ask whether the driver is merged into Cinder,
> please see my comments in nova spec
> https://review.openstack.org/#/c/130919/, thank you very much!
>
>
>
>
>
>
>
> Best regards
>
>
>
> ZhangNi
>
>
>
> __
> 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 Bryant]

+2. I think the having checks are helpful.  If they aren't removed it does
Leelee harm.

Jay
On Mar 15, 2015 6:39 AM, "Duncan Thomas"  wrote:

> On 13 March 2015 at 17:36, Doug Hellmann  wrote:
>
>
>> I wish we, as a community, were less obsessed with creating so many
>> hacking rules. These are really minor changes and it's going to be a
>> relatively short-lived issue that could just be fixed once. If there's a
>> regression, fixing *that* won't be hard or take long.
>>
>>
> Ok, this comment has peaked my interest again, since I hold pretty much
> the exact opposite view and am a well known fan of hacking checks. My logic
> is:
> - Hacking checks point out the error for most submitters before review,
> saving reviewer time and CI cycles, and increasing the comfort level of the
> submitter (for most people, a -1 feels harsh/negative)
> - Hacking checks don't slip up and miss one because they are reviewing at
> 1am the night before the deadline
> - Regressions hurt, and not all of our code is covered by unit tests / CI
> - Debugging the output of a hacking check is many times faster than
> debugging a unit test, even for simple failures (and work is underway to
> may this even faster)
> - Hacking checks that are left around for migrations like this even a few
> cycles longer than they are needed have zero cost. As long as nobody type
> 'oslo.foo' then they never need even know of their existence. We can be
> really lazy about removing them with no harm at all.
>
> Am I missing something? I am a general proponent of 'write hacking checks
> for any mechanical code change'. We've seen definite benefits from this
> approach and few to no downsides that I'm aware of.
>
> __
> 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] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Jay Bryant]

+2

I recently had a patch abandoned that had every right to be pulled off the
list.  It had fallen off my radar and was no longer relevant.

As long as there is a way to restore the patch where appropriate,  we
should do it.

Jay
I have to agree with John. We have many more submitters than we have core
folks, and our current scaling limits tend to be around core and reviews,
not around submissions, so making life slightly more difficult for
submitters in order to make it substantially easier for core is a
reasonable trade.

Not marking a review as abandoned if feedback hasn't been responded to in 2
week misleads reviewers and submitters, so I fully support the cinder
abandonment rules - the 'restore change' button takes a moment to click.

On 28 February 2015 at 03:02, John Griffith 
wrote:

>
>
> On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli 
> wrote:
>
>> I'm not expressing myself cleary enough. I don't advocate for the
>> removal of anything because I like pretty charts. I'm changing the
>> subject to be even more clear.
>>
>> On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote:
>> > I am asking you to please independently remove changes that you don't
>> > think should be considered from your metrics.
>>
>> I'm saying that the reports have indicators that seem to show struggle.
>> In a previous message Kevin hinted that probably a reason for those bad
>> looking numbers was due to "a lot of reviews that appear to have been
>> abandoned". This doesn't seem the case because some projects have a
>> habit of 'purging'.
>>
>> I have never explicitly ordered developers to purge anything. If their
>> decision to purge is due to the numbers they may have seen on the
>> reports I'd like to know.
>>
>> That said, the problem that the reports highlight remains confirmed so
>> far: contributors seem to be left in some cases hanging, for many many
>> days, *after a comment* and they don't come back.
>>
>> > I think abandoning changes so that the metrics look the way we want is a
>> > terrible experience for contributors.
>>
>> I agree, that should not be a motivator. Also, after chatting with you
>> on IRC I tend to think that instead of abandoning the review we should
>> highlight them and have humans act on them. Maybe build a dashboard of
>> 'old stuff' to periodically sift through and see if there are things
>> worth picking up again or to ping the owner or something else managed by
>> humans.
>>
>> I happened to have found one of such review automatically closed that
>> could have been fixed with a trivial edit in commit message instead:
>>
>> https://review.openstack.org/#/c/98735/
>>
>> (that owner had a bunch of auto-abandoned patches
>> https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%
>> 2540gmail.com%253E%22,n,z
>> ).
>> I have made a note to reach out to him and
>> get more anecdotes.
>>
>> > Especially as it appears some projects, such as nova, are in a position
>> > where they are actually leaving -2 votes on changes which will not be
>> > lifted for 2 or 3 months.  That means that if someone runs a script like
>> > Sean's, these changes will be abandoned, yet there is nothing that the
>> > submitter can do to progress the change in the mean time.  Abandoning
>> > such a review is making an already bad experience for contributors even
>> > worse.
>>
>> this sounds like a different issue :(
>>
>>
>> __
>> 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
>>
> ​
> For what it's worth, at one point the Cinder project setup an auto-abandon
> job that did purge items that had a negative mark either from a reviewer or
> from Jenkins and had not been updated in over two weeks.  This had
> absolutely nothing to do with metrics or statistical analysis of the
> project.  We simply had a hard time dealing with patches that the submitter
> "didn't care about".  If somebody takes the time to review a patch, then I
> don't think it's too much to ask that the submitter respond to questions or
> comments within a two week period.  Note, the auto purge in our case only
> purged items that had no updates or activity at all.
>
> We were actually in a position where we had patches that were submitted,
> failed unit tests in the gate (valid failures that occurred 100% of the
> time) and had sat for an entire release without the submitter ever updating
> the patch. I don't think it's unreasonable at all to abandon these and
> remove them from the queue.  I don't think this is a bad thing, I think
> it's worse to leave them as active when they're bit-rotted and the
> submitter doesn't even care about them any longer.  The other thing is,
> those patches are "still there", they c

Re: [openstack-dev] Ideas about Openstack Cinder for GSOC 2015

[Jay Bryant]

Fyi ...

This is something that Mike Perez was thinking about so you can ping
thingee on irc if you can't find e0ne.

Jay
On Feb 27, 2015 3:51 AM, "harryxiyou"  wrote:

> Hi all,
>
> I cannot find the proper idea about Openstack Cinder for GSOC 2015
> here[1]. Could anyone please give me some clues?
>
> [1] https://wiki.openstack.org/wiki/GSoC2015
>
>
> Thanks, Harry
>
> __
> 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] Changes to Cinder Core

[Jay Bryant]

+1

Ivan had been doing a great job!  Will be glad to have him (officially) on
the team!

Jay
On Jan 21, 2015 10:18 AM, "Mike Perez"  wrote:

> On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez  wrote:
> > It gives me great pleasure to nominate Ivan Kolodyazhny (e0ne) for
> > Cinder core. Ivan's reviews have been valuable in decisions, and his
> > contributions to Cinder core code have been greatly appreciated.
> >
> > Reviews:
> >
> https://review.openstack.org/#/q/reviewer:%22Ivan+Kolodyazhny+%253Ce0ne%2540e0ne.info%253E%22,n,z
> >
> > Contributions:
> >
> https://review.openstack.org/#/q/owner:%22Ivan+Kolodyazhny%22+project:+openstack/cinder,n,z
> >
> > 30/90 day review stats:
> > http://stackalytics.com/report/contribution/cinder-group/30
> > http://stackalytics.com/report/contribution/cinder-group/90
> >
> > As new contributors step up to help in the project, some move onto
> > other things. I would like to recognize Josh Durgin for his early
> > contributions to Nova volume, early involvement with Cinder, and now
> > unfortunately departure from the Cinder core team.
> >
> > Cinder core, please reply with a +1 for approval. This will be left
> > open until Jan 26th. Assuming there are no objections, this will go
> > forward after voting is closed.
>
> And apologies for missing the [cinder] subject prefix.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Bryant]

Mike,

Thanks for the diligent efforts to get the word out!

Jay
On Jan 20, 2015 12:30 PM, "Mike Perez"  wrote:

> On 13:53 Tue 20 Jan , Erlon Cruz wrote:
> > Thanks Deepak!
> >
> >
> > Mike is also sending the announce to the vendors in the mail accounts
> > listed in the CI Status page[1].
> >
> > [1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
>
> I've actually gone through each volume driver file and emailed whoever
> mostly
> appeared in git blame, as well as whoever appeared recently in commits with
> an obvious company email address. This has been cross checked with the
> proposed
> maintainers file [1].
>
> --
> Mike Perez
>
> [1] - https://review.openstack.org/#/c/116887/
>
> __
> 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] Cross-project DevRef Was Re: Skipping Cross-Project meeting today

[Jay Bryant]

+2  This topic had come up in Cinder I believe as well.

Having a common devref for common content would be good and would make it
easier to keep the documentation current.

Jay
On Jan 20, 2015 4:05 PM, "Jay Pipes"  wrote:

> On 01/20/2015 01:30 PM, Ian Cordasco wrote:
>
>> On Jan 20, 2015, at 05:23, Thierry Carrez 
>>> wrote:
>>>
>>> Hi everyone,
>>>
>>> Given that the agenda docket is pretty slim this week, I'd like to
>>> skip this cross-project meeting and have the next one on Jan 27.
>>>
>>> sigmavirus24 posted the "Cross-project DevRef akin to Nova's" item
>>> but I'd prefer if we discussed it on the mailing-list first (not
>>> certain it requires everyone's attention just yet, and could just
>>> be proposed as a spec).
>>>
>>> Cheers,
>>>
>>> -- Thierry Carrez (ttx)
>>>
>>> 
>>> __
>>>
>>>
>>>  OpenStack Development Mailing List (not for usage questions)
>
>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Hey all,
>>
>> First, let me provide some context. The week before last, an update
>> to sqlalchemy-migrate broke glance’s gate. While helping us fix the
>> problem, Matt Riedemann noticed that the project doesn’t have a
>> Developer Reference document. The document helps new developers
>> determine what system packages they need to build a development
>> environment for the project.
>>
>> We discussed the idea of putting one together for glance at the team
>> meeting last week. While discussing it, we realized a lot of the
>> steps are similar to Nova’s and it might benefit OpenStack as a whole
>> to have one common DevRef that links off to individual ones for
>> further configuration. The list of common steps could be maintained
>> in one place (rather than synchronized between projects) and then
>> individual extensions would be maintained with in each project or
>> wiki.
>>
>> Before we started duplicating content in our own document, we wanted
>> to present the idea to the cross-project team and the community as a
>> whole.
>>
>> Feedback is greatly appreciated, Ian
>>
>
> I think a common shared developer reference is a great idea, Ian. ++
>
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

[Jay Bryant]

+2. How contributions have always been helpful.
On Jan 7, 2015 8:50 AM, "Alan Pevec"  wrote:

> +2 Flavio knows stable branch policies very well and will be a good
> addition to the cross-projects stable team.
>
> 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

[openstack-dev] Fwd: [Openstack-stable-maint] Stable check of openstack/cinder failed

[Jay Bryant]

I have a patch out to resolve this failure:
https://review.openstack.org/145642

Jay
-- Forwarded message --
From: "A mailing list for the OpenStack Stable Branch test reports." <
openstack-stable-ma...@lists.openstack.org>
Date: Jan 8, 2015 1:40 AM
Subject: [Openstack-stable-maint] Stable check of openstack/cinder failed
To: 
Cc:

Build failed.

- periodic-cinder-docs-icehouse
http://logs.openstack.org/periodic-stableperiodic-cinder-docs-icehouse/d17b6e2/
: SUCCESS in 5m 58s
- periodic-cinder-python26-icehouse
http://logs.openstack.org/periodic-stableperiodic-cinder-python26-icehouse/5b0d5e1/
: SUCCESS in 9m 58s
- periodic-cinder-python27-icehouse
http://logs.openstack.org/periodic-stableperiodic-cinder-python27-icehouse/0f277fd/
: SUCCESS in 8m 40s
- periodic-cinder-docs-juno
http://logs.openstack.org/periodic-stableperiodic-cinder-docs-juno/8447e0d/
: SUCCESS in 4m 37s
- periodic-cinder-python26-juno
http://logs.openstack.org/periodic-stableperiodic-cinder-python26-juno/2735239/
: FAILURE in 12m 11s
- periodic-cinder-python27-juno
http://logs.openstack.org/periodic-stableperiodic-cinder-python27-juno/dbe1e66/
: FAILURE in 8m 17s

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

Re: [openstack-dev] [oslo] dropping namespace packages

[Jay Bryant]

We talked about this in Cinder.  I am planning to create some hacking
checks for us just to be safe.   Shouldn't take a ton of effort.

Jay
On Jan 8, 2015 12:03 PM, "Doug Hellmann"  wrote:

>
> > On Jan 8, 2015, at 11:29 AM, Ihar Hrachyshka 
> wrote:
> >
> > On 01/05/2015 04:51 PM, Doug Hellmann wrote:
> >> As each library is released, we will send release notes to this list,
> as usual. At that point the Oslo liaisons should start planning patches to
> change imports in their projects from "oslo.foo" to “oslo_foo". The old
> imports should still work for now, but new features will not be added to
> the old namespace, so over time it will be necessary to make the changes
> anyway. We are likely to remove the old namespace package completely during
> the next release cycle, but that hasn't been decided.
> >
> > Making the switch probably requires us to add some hacking rule that
> would forbid old namespace based imports, right? Do we by chance have such
> a rule implemented anywhere?
>
> 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.
>
> Doug
>
>
> ___
> 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] [Glance] [Swift] cinder upload-to-image creates image with 'queued' state

[Jay Bryant]

Timur,

In addition to logs,  i would check to make sure that there is sufficient
space to create a copy of the image to transfer it to glance.

I have heard of issues like that when disk space is low on either end.

Jay
On Jan 1, 2015 7:45 AM, "Timur Nurlygayanov" 
wrote:

> Hi all,
>
> I have the strange error with Cinder: I have several volumes (with 30-100
> Gb size) and I want to create Glance images based on these volumes, but
> when I execute
>
> cinder upload-to-image --force true 0074d4a8-e4a1-4620-ae3e-40e46ea6eeef
> volume002
>
> I can see that this volume status changed to 'uploading' but in Glance I
> can see the image with zero size and status 'queued' and it hangs in this
> state.
> I have checked Glance / Cinder logs, restarted
> Glance/Cinder/Swift/RabbitMQ but it doesn't help.
>
> I also found this bug:
> https://bugs.launchpad.net/cinder/+bug/1298042
> and I have applied fix, but it doesn't work.
>
> I have several volumes and this issue reproduced for only part of my
> volumes and I also can successfully upload images to Glance.
> My environment: 3 hardware servers, OpenStack IceHouse, Cinder for
> volumes, Swift file storage service for Glance images.
>
> How I can debug this issue? (I have no any errors/exceptions in
> Glance/Cinder/Swift logs)
>
> Thank you!
>
> --
>
> Timur,
> Senior QA Engineer
> OpenStack Projects
> Mirantis Inc
>
>
> ___
> 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] Anyone knows whether there is freezing day of spec approval?

[Jay 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 listopenstack-...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] Query regarding BluePrint submission for Review

[Jay Bryant]

Vikram,

The process is documented here: https://wiki.openstack.org/wiki/Blueprints

Let me know if you have questions.

Jay
On Dec 16, 2014 11:18 PM, "Vikram Choudhary" 
wrote:

>  Dear All,
>
>
>
> We want to submit a new blueprint for review.
>
> Can you please provide the steps for doing it.
>
>
>
> Thanks
>
> Vikram
>
> ___
> 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 knows whether there is freezing day of spec approval?

[Jay Bryant]

Dave,

Yes,  we are not taking new specs/blueprints after 12/18.

Jay
On Dec 15, 2014 9:18 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] [nova][cinder][infra] Ceph CI status update

[Jay Bryant]

On Saturday, December 13, 2014, Deepak Shetty  wrote:

> I think you completely mis-understood my Q
> I am completely in agreement for _not_ putting CI status in mailing list.
>
> Let me rephrase:
>
> As of now, I see 2 places where CI status is being tracked:
>
> https://wiki.openstack.org/wiki/ThirdPartySystems (clicking on the Link
> tells u the status)
> and
> https://wiki.openstack.org/wiki/Cinder/third-party-ci-status (one of
> column is status column)
>
> How are the 2 different ? Do we need to update both ?
>
> thanx,
> deepak
>
> On Sat, Dec 13, 2014 at 1:32 AM, Anita Kuno  > wrote:
>>
>> On 12/12/2014 03:28 AM, Deepak Shetty wrote:
>> > On Thu, Dec 11, 2014 at 10:33 PM, Anita Kuno > > wrote:
>> >
>> >> On 12/11/2014 09:36 AM, Jon Bernard wrote:
>> >>> Heya, quick Ceph CI status update.  Once the test_volume_boot_pattern
>> >>> was marked as skipped, only the revert_resize test was failing.  I
>> have
>> >>> submitted a patch to nova for this [1], and that yields an all green
>> >>> ceph ci run [2].  So at the moment, and with my revert patch, we're in
>> >>> good shape.
>> >>>
>> >>> I will fix up that patch today so that it can be properly reviewed and
>> >>> hopefully merged.  From there I'll submit a patch to infra to move the
>> >>> job to the check queue as non-voting, and we can go from there.
>> >>>
>> >>> [1] https://review.openstack.org/#/c/139693/
>> >>> [2]
>> >>
>> http://logs.openstack.org/93/139693/1/experimental/check-tempest-dsvm-full-ceph/12397fd/console.html
>> >>>
>> >>> Cheers,
>> >>>
>> >> Please add the name of your CI account to this table:
>> >> https://wiki.openstack.org/wiki/ThirdPartySystems
>> >>
>> >> As outlined in the third party CI requirements:
>> >> http://ci.openstack.org/third_party.html#requirements
>> >>
>> >> Please post system status updates to your individual CI wikipage that
>> is
>> >> linked to this table.
>> >>
>> >
>> > How is posting status there different than here :
>> > https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
>> >
>> > thanx,
>> > deepak
>> >
>>
>> >
>> >
>>
> Deepak,

We have been using the Cinder wiki page to track development of each CI and
to communicate issues within the Cinder community.  The general wiki is for
tracking the state of all the different CI systems.

So, I would say that both should be updated right now, eventually the
Cinder one should be deprecated.

Jay

> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> There are over 100 CI accounts now and growing.
>>
>> Searching the email archives to evaluate the status of a CI is not
>> something that infra will do, we will look on that wikipage or we will
>> check the third-party-announce email list (which all third party CI
>> systems should be subscribed to, as outlined in the third_party.html
>> page lined above).
>>
>> If we do not find information where we have asked you to put it and were
>> we expect it, we may disable your system until you have fulfilled the
>> requirements as outlined in the third_party.html page linked above.
>>
>> Sprinkling status updates amongst the emails posted to -dev and
>> expecting the infra team and other -devs to find them when needed is
>> unsustainable and has been for some time, which is why we came up with
>> the wikipage to aggregate them.
>>
>> Please direct all further questions about this matter to one of the two
>> third-party meetings as linked above.
>>
>> Thank you,
>> Anita.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>

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

Re: [openstack-dev] [Cinder] Request for J3 FFE - add reset-state function for backups

[Jay Bryant]

It isn't a huge change.   I am ok with it if we can get the issues
addressed.   Especially Duncan's concern.
On Sep 11, 2014 12:17 PM, "Mike Perez"  wrote:

> On 12:23 Tue 09 Sep , yunling wrote:
> > Hi Cinder Folks,I would like to request a FFE for add reset-state
> function for backups[1][2].The spec of add reset-state function for backups
> has been reviewed and merged[2]. These code changes have been well tested
> and are not very complex[3]. I would appreciate any consideration for an
> FFE.Thanks,
>
> It looks like the current review has some comments that are waiting too be
> addressed now.
>
> --
> 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] Feature freeze + Juno-3 milestone candidates available

[Jay Bryant]

Thierry,

Thanks!   I agree.

Jay
On Sep 6, 2014 9:37 AM, "Thierry Carrez"  wrote:

> In that precise case, given how early it is in the freeze, I think
> giving a quick heads-up to the -i18n team/list should be enough :) Also
> /adding/ a string is not as disruptive to their work as modifying a
> potentially-already-translated one.
>
> Joe Cropper wrote:
> > +1 to what Jay said.
> >
> > I’m not sure whether the string freeze applies to bugs, but the defect
> > that Matt mentioned (for which I authored the fix) adds a string, albeit
> > to fix a bug.  Hoping it’s more desirable to have an untranslated
> > correct message than a translated incorrect message.  :-)
> >
> > - Joe
> > On Sep 5, 2014, at 3:41 PM, Jay Bryant  > <mailto:jsbry...@electronicjungle.net>> wrote:
> >
> >> Matt,
> >>
> >> I don't think that is the right solution.
> >>
> >> If the string changes I think the only problem is it won't be
> >> translated if it is thrown.   That is better than breaking the coding
> >> standard imho.
> >>
> >> Jay
> >>
> >> On Sep 5, 2014 3:30 PM, "Matt Riedemann"  >> <mailto:mrie...@linux.vnet.ibm.com>> wrote:
> >>
> >>
> >>
> >> On 9/5/2014 5:10 AM, Thierry Carrez wrote:
> >>
> >> Hi everyone,
> >>
> >> We just hit feature freeze[1], so please do not approve
> >> changes that add
> >> features or new configuration options unless those have been
> >> granted a
> >> feature freeze exception.
> >>
> >> This is also string freeze[2], so you should avoid changing
> >> translatable
> >> strings. If you have to modify a translatable string, you
> >> should give a
> >> heads-up to the I18N team.
> >>
> >> Finally, this is also DepFreeze[3], so you should avoid adding
> new
> >> dependencies (bumping oslo or openstack client libraries is OK
> >> until
> >> RC1). If you have a new dependency to add, raise a thread on
> >> openstack-dev about it.
> >>
> >> The juno-3 development milestone was tagged, it contains more
> >> than 135
> >> features and 760 bugfixes added since the juno-2 milestone 6
> >> weeks ago
> >> (not even counting the Oslo libraries in the mix). You can
> >> find the full
> >> list of new features and fixed bugs, as well as tarball
> >> downloads, at:
> >>
> >> https://launchpad.net/__keystone/juno/juno-3
> >> <https://launchpad.net/keystone/juno/juno-3>
> >> https://launchpad.net/glance/__juno/juno-3
> >> <https://launchpad.net/glance/juno/juno-3>
> >> https://launchpad.net/nova/__juno/juno-3
> >> <https://launchpad.net/nova/juno/juno-3>
> >> https://launchpad.net/horizon/__juno/juno-3
> >> <https://launchpad.net/horizon/juno/juno-3>
> >> https://launchpad.net/neutron/__juno/juno-3
> >> <https://launchpad.net/neutron/juno/juno-3>
> >> https://launchpad.net/cinder/__juno/juno-3
> >> <https://launchpad.net/cinder/juno/juno-3>
> >> https://launchpad.net/__ceilometer/juno/juno-3
> >> <https://launchpad.net/ceilometer/juno/juno-3>
> >> https://launchpad.net/heat/__juno/juno-3
> >> <https://launchpad.net/heat/juno/juno-3>
> >> https://launchpad.net/trove/__juno/juno-3
> >> <https://launchpad.net/trove/juno/juno-3>
> >> https://launchpad.net/sahara/__juno/juno-3
> >> <https://launchpad.net/sahara/juno/juno-3>
> >>
> >> Many thanks to all the PTLs and release management liaisons
> >> who made us
> >> reach this important milestone in the Juno development cycle.
> >> Thanks in
> >> particular to John Garbutt, who keeps on doing an amazing job
> >> at the
> >> impossible task of keeping the Nova ship straight in troubled
> >> waters
> >> while we head toward the Juno release port.
> >>
> >> Regards,
> >>
> >> [1] https://wiki.openstack.org/__wiki/FeatureFreeze
> 

Re: [openstack-dev] Feature freeze + Juno-3 milestone candidates available

[Jay Bryant]

Matt,

I don't think that is the right solution.

If the string changes I think the only problem is it won't be translated if
it is thrown.   That is better than breaking the coding standard imho.

Jay
On Sep 5, 2014 3:30 PM, "Matt Riedemann"  wrote:

>
>
> On 9/5/2014 5:10 AM, Thierry Carrez wrote:
>
>> Hi everyone,
>>
>> We just hit feature freeze[1], so please do not approve changes that add
>> features or new configuration options unless those have been granted a
>> feature freeze exception.
>>
>> This is also string freeze[2], so you should avoid changing translatable
>> strings. If you have to modify a translatable string, you should give a
>> heads-up to the I18N team.
>>
>> Finally, this is also DepFreeze[3], so you should avoid adding new
>> dependencies (bumping oslo or openstack client libraries is OK until
>> RC1). If you have a new dependency to add, raise a thread on
>> openstack-dev about it.
>>
>> The juno-3 development milestone was tagged, it contains more than 135
>> features and 760 bugfixes added since the juno-2 milestone 6 weeks ago
>> (not even counting the Oslo libraries in the mix). You can find the full
>> list of new features and fixed bugs, as well as tarball downloads, at:
>>
>> https://launchpad.net/keystone/juno/juno-3
>> https://launchpad.net/glance/juno/juno-3
>> https://launchpad.net/nova/juno/juno-3
>> https://launchpad.net/horizon/juno/juno-3
>> https://launchpad.net/neutron/juno/juno-3
>> https://launchpad.net/cinder/juno/juno-3
>> https://launchpad.net/ceilometer/juno/juno-3
>> https://launchpad.net/heat/juno/juno-3
>> https://launchpad.net/trove/juno/juno-3
>> https://launchpad.net/sahara/juno/juno-3
>>
>> Many thanks to all the PTLs and release management liaisons who made us
>> reach this important milestone in the Juno development cycle. Thanks in
>> particular to John Garbutt, who keeps on doing an amazing job at the
>> impossible task of keeping the Nova ship straight in troubled waters
>> while we head toward the Juno release port.
>>
>> Regards,
>>
>> [1] https://wiki.openstack.org/wiki/FeatureFreeze
>> [2] https://wiki.openstack.org/wiki/StringFreeze
>> [3] https://wiki.openstack.org/wiki/DepFreeze
>>
>>
> I should probably know this, but at least I'm asking first. :)
>
> Here is an example of a new translatable user-facing error message [1].
>
> From the StringFreeze wiki, I'm not sure if this is small or large.
>
> Would a compromise to get this in be to drop the _() so it's just a string
> and not a message?
>
> Maybe I should just shut-up and email the openstack-i18n mailing list [2].
>
> [1] https://review.openstack.org/#/c/118535/
> [2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> ___
> 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][FFE] make ssh host key policy configurable

[Jay Bryant]

Not sure if the patch to make the ssh strict policy setting configurable
needed an official ffe.  It merged after the tag so I wanted to cover my
bases.

This is my request.

Thanks!
Jay

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

Re: [openstack-dev] [All] LOG.warning/LOG.warn

[Jay Bryant]

+2

I prefer the LOG.warning format and support that given the documentation
you shared.

If there is agreement I would create a hacking check.

Jay
On Aug 17, 2014 1:28 AM, "Gary Kotton"  wrote:

>  Hi,
> Over the last few weeks I have seen a number of patches where LOG.warn is
> replacing LOG.warning. I think that if we do something it should be the
> opposite as warning is the documented one in python 2 and 3
> https://docs.python.org/3/howto/logging.html.
> Any thoughts?
> Thanks
> Gary
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Bryant]

Sean,

Thanks for making this change!

Jay
On Jul 25, 2014 5:41 AM, "Sean Dague"  wrote:

> On 07/25/2014 01:18 AM, Ian Wienand wrote:
> > On 07/16/2014 11:15 PM, Alexis Lee wrote:
> >> What do you think about allowing some text after the words "recheck no
> >> bug"?
> >
> > I think this is a good idea; I am often away from a change for a bit,
> > something happens in-between and Jenkins fails it, but chasing it down
> > days later is fairly pointless given how fast things move.
> >
> > It would be nice if I could indicate "I thought about this".  In fact,
> > there might be an argument for *requiring* a reason
> >
> > I proposed [1] to allow this
> >
> > -i
> >
> > [1] https://review.openstack.org/#/c/109492/
>
> At the QA / Infra meetup we actually talked about the recheck syntax,
> and to change the way elastic recheck is interacting with the user.
>
>
> https://review.openstack.org/#/q/status:open+project:openstack-infra/elastic-recheck+branch:master+topic:erchanges,n,z
>
> and
>
>
> https://review.openstack.org/#/q/status:open+project:openstack-infra/config+branch:master+topic:er,n,z
>
> Are the result of that. Basically going forward we'll just support
>
> 'recheck.*'
>
> If you want to provide us with info after the recheck, great, we can
> mine it later. However we aren't using that a ton at this point, so
> we'll make it easier on people.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mentor program?

[Jay Bryant]

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

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

[Jay Bryant]

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.

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 "small" feature requiring a relatively large amount of spec effort), I'd
> love to have links to both the spec and the resulting implementation so we
> can discuss exactly why the spec was an unnecessary additional effort.
>
> On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore <
> jason.dunsm...@rackspace.com> wrote:
>
> On Mon, Jun 30 2014, Joshua Harlow wrote:
>
> > There is a balance here that needs to be worked out and I've seen
> > specs start to turn into requirements for every single patch (even if
> > the patch is pretty small). I hope we can rework the 'balance in the
> > force' to avoid being so strict that every little thing requires a
> > spec. This will not end well for us as a community.
> >
> > How have others thought the spec process has worked out so far? To
> > much overhead, to little…?
> >
> > I personally am of the opinion that specs should be used for large
> > topics (defining large is of course arbitrary); and I hope we find the
> > right balance to avoid scaring everyone away from working with
> > openstack. Maybe all of this is part of openstack maturing, I'm not
> > sure, but it'd be great if we could have some guidelines around when
> > is a spec needed and when isn't it and take it into consideration when
> > requesting a spec that the person you have requested may get
> > frustrated and just leave the community (and we must not have this
> > happen) if you ask for it without explaining why and how clearly.
>
> +1 I think specs are too much overhead for small features.  A set of
> guidelines about when specs are needed would be sufficient.  Leave the
> option about when to submit a design vs. when to submit code to the
> contributor.
>
> Jason
>
>
> ___
> 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] Translating log and exception messages in Oslo libraries

[Jay Bryant]

+1 To translating oslo logs.  There is quite a bit of logging that comes
out of the libraries.   It should be logged for consistency using delayed
translation.

Jay
On Jun 20, 2014 8:22 AM, "Doug Hellmann" 
wrote:

> On Fri, Jun 20, 2014 at 8:40 AM, Mark McLoughlin 
> wrote:
> > Hi
> >
> > I'm not sure we've ever discussed this before, but I had previously
> > figured that we shouldn't translate log and exception messages in
> > oslo.messaging.
> >
> > My thinking is:
> >
> >   - it seems like an odd thing for a library to do, I don't know of
> > examples of other libraries doing this .. but I haven't gone
> > looking
> >
> >   - it involves a dependency on oslo.i18n
> >
> >   - more than just marking strings for translation and using
> > gettextutils, you also need to set up the infrastructure for pushing
> > the .pot files to transifex, pulling the .po files from .transifex
> > and installing the .mo files at install time
> >
> > I don't feel terribly strongly about this except that unless someone is
> > willing to see this through and do the transifex and install-time work,
> > we shouldn't be doing the use-oslo.i18n and mark-strings-for-translation
> > work.
>
> I had thought we would do all of the oslo libraries, since so many of
> the log messages actually come from library code. I think Andreas has
> already set up most of the infrastructure needed to make the
> translation jobs work.
>
> We haven't done a great job of communicating the plan on log
> translations, and I'm currently looking for someone from the i18n team
> to step forward to be the point of contact on that work.
>
> Doug
>
> >
> > 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

[Jay Bryant]

I agree Duncan.

I think the commit message is one of the most important parts of a
commit.   If the message is not useful, the code shouldn't go in.

Jay Bryant
On Jun 22, 2014 1:51 PM, "Duncan Thomas"  wrote:

> On 22 June 2014 14:41, Amrith Kumar  wrote:
> > In addition to making changes to the hacking rules, why don't we mandate
> also
> > that perceived problems in the commit message shall not be an acceptable
> > reason to -1 a change.
>
> -1.
>
> There are some /really/ bad commit messages out there, and some of us
> try to use the commit messages to usefully sort through the changes
> (i.e. I often -1 in cinder a change only affects one driver and that
> isn't clear from the summary).
>
> If the perceived problem is grammatical, I'm a bit more on board with
> it not a reason to rev a patch, but core reviewers can +2/A over the
> top of a -1 anyway...
>
> > Would this improve the situation?
>
> Writing better commit messages in the first place would improve the
> situation?
>
> ___
> 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][Cinder] Review days? (open to ANYBODY and EVERYBODY)

[Jay Bryant]

John,

+2

I am guilty of falling behind on reviews. Pulled in to a lot of other stuff
since the summit ... and before.

Having prescribed time on my calendar is a good idea.  Just put it on my
calendar.

Jay
On Jun 12, 2014 10:49 PM, "John Griffith" 
wrote:

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