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

2018-11-01 Thread 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

2018-07-01 Thread 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

2018-06-23 Thread 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

2018-06-07 Thread 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

2018-05-23 Thread 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?

2018-03-19 Thread 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

2017-12-17 Thread 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

2017-12-17 Thread Jay Bryant
Well said Ildiko. Thank you!

Jay

On Sun, Dec 10, 2017, 8:23 PM Ildiko Vancsa <ildiko.van...@gmail.com> 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 <mriede...@gmail.com> 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

2017-12-14 Thread 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

2017-11-27 Thread 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

2017-11-01 Thread 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 ...

2017-09-08 Thread 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

2017-07-27 Thread 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

2017-06-17 Thread 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

2017-06-02 Thread 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: 

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

2017-05-23 Thread 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

2017-05-23 Thread 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 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

2017-05-20 Thread 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

2017-04-01 Thread 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

2017-04-01 Thread 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

2017-03-16 Thread 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 > 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

2017-03-04 Thread 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

2017-03-04 Thread 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 <sean.mcgin...@gmx.com 
<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?

2016-11-13 Thread 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

2016-08-14 Thread 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
>>> 

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

2016-08-13 Thread 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?

2016-07-17 Thread 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

2016-04-05 Thread 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 <duncan.tho...@gmail.com>
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 <jsbry...@electronicjungle.net>
> 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 <dtro...@gmail.com> wrote:
>>
>>> On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez <thin...@gmail.com> 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

2016-04-05 Thread 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

2016-03-14 Thread 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
>
> 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

2016-01-30 Thread 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.

2015-12-22 Thread 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
> > >>> 

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

2015-09-03 Thread 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

2015-08-22 Thread 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 taylor.ber...@solnet.co.nz 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 walter.bor...@hp.com wrote: -
 To: openstack-dev@lists.openstack.org
 From: Walter A. Boring IV walter.bor...@hp.com
 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-0012 on node-6 to 100GB
 
  $ cinder reset-state --state 

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

2015-07-11 Thread 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 thie...@openstack.org
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] [Nova] The unbearable lightness of specs

2015-06-29 Thread 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 tim.b...@cern.ch 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] Need help from folks working on Dell, Storpool and Infortrend drivers

2015-06-29 Thread Jay Bryant
Vincent,

Best place to start is with Sean McGinnis.

Jay

On Sun, Jun 28, 2015 at 10:00 PM Sheng Bo Hou sb...@cn.ibm.com 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
https://review.openstack.org/#/c/180873/66/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] [cinder][stable] Cinder client broken in Juno

2015-06-29 Thread 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 gegui...@redhat.com 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] Some Changes to Cinder Core

2015-05-22 Thread 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 thin...@gmail.com 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] Deadline For Volume Drivers to Be Readded

2015-03-26 Thread 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 thin...@gmail.com wrote:

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

 The current CI's not meeting the second requirement:

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

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


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

 --
 Mike Perez

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

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


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

2015-03-26 Thread 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 mord...@inaugust.com wrote:

 On 03/24/2015 06:05 PM, Kyle Mestery wrote:
  On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann d...@doughellmann.com
  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] Deprecation warnings considered harmful?

2015-03-15 Thread 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 duncan.tho...@gmail.com wrote:

 On 13 March 2015 at 17:36, Doug Hellmann d...@doughellmann.com 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] [cinder]Request to to revisit this patch

2015-03-15 Thread 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 zhan...@huawei.com 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] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

2015-03-01 Thread 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 john.griffi...@gmail.com
wrote:



 On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli stef...@openstack.org
 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
 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 can still be accessed and reinstated.

 There's a lot of knocks against core teams regarding time to review and
 keeping 

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

2015-02-27 Thread 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 harryxi...@gmail.com 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

2015-01-21 Thread 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 thin...@gmail.com wrote:

 On Wed, Jan 21, 2015 at 10:14 AM, Mike Perez thin...@gmail.com 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

2015-01-20 Thread Jay Bryant
Mike,

Thanks for the diligent efforts to get the word out!

Jay
On Jan 20, 2015 12:30 PM, Mike Perez thin...@gmail.com 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

2015-01-20 Thread 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 jaypi...@gmail.com wrote:

 On 01/20/2015 01:30 PM, Ian Cordasco wrote:

 On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org
 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] [oslo] dropping namespace packages

2015-01-08 Thread 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 d...@doughellmann.com wrote:


  On Jan 8, 2015, at 11:29 AM, Ihar Hrachyshka ihrac...@redhat.com
 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


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

2015-01-08 Thread 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: openstack-stable-ma...@lists.openstack.org
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] [stable] Proposal to add Flavio Percoco to stable-maint-core

2015-01-08 Thread Jay Bryant
+2. How contributions have always been helpful.
On Jan 7, 2015 8:50 AM, Alan Pevec ape...@gmail.com 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] [cinder] Anyone knows whether there is freezing day of spec approval?

2014-12-17 Thread 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
javascript:_e(%7B%7D,'cvml','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] Query regarding BluePrint submission for Review

2014-12-16 Thread 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 vikram.choudh...@huawei.com
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?

2014-12-15 Thread 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 wei.d.c...@intel.com 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

2014-12-14 Thread Jay Bryant
On Saturday, December 13, 2014, Deepak Shetty dpkshe...@gmail.com 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 ante...@anteaya.info
 javascript:_e(%7B%7D,'cvml','ante...@anteaya.info'); wrote:

 On 12/12/2014 03:28 AM, Deepak Shetty wrote:
  On Thu, Dec 11, 2014 at 10:33 PM, Anita Kuno ante...@anteaya.info
 javascript:_e(%7B%7D,'cvml','ante...@anteaya.info'); 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
 javascript:_e(%7B%7D,'cvml','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
 javascript:_e(%7B%7D,'cvml','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

2014-09-11 Thread 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 thin...@gmail.com 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

2014-09-06 Thread Jay Bryant
Thierry,

Thanks!   I agree.

Jay
On Sep 6, 2014 9:37 AM, Thierry Carrez thie...@openstack.org 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 jsbry...@electronicjungle.net
  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 mrie...@linux.vnet.ibm.com
  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
  https://wiki.openstack.org/wiki/FeatureFreeze
  [2] https://wiki.openstack.org/__wiki/StringFreeze
  https://wiki.openstack.org/wiki/StringFreeze
  [3] https://wiki.openstack.org/__wiki/DepFreeze
  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/
  https://review.openstack.org/#/c/118535/
  [2]
 
 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-i18n
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
 
 
  --
 
  Thanks,
 
  Matt Riedemann
 
 
  _
  OpenStack-dev mailing list
  OpenStack-dev

[openstack-dev] [Cinder][FFE] make ssh host key policy configurable

2014-09-05 Thread 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] Feature freeze + Juno-3 milestone candidates available

2014-09-05 Thread 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 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/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


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

2014-08-17 Thread 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 gkot...@vmware.com 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

2014-07-25 Thread Jay Bryant
Sean,

Thanks for making this change!

Jay
On Jul 25, 2014 5:41 AM, Sean Dague s...@dague.net 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?

2014-07-23 Thread 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

2014-07-09 Thread 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 donald.d.dug...@intel.com
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] [hacking] rules for removal

2014-06-22 Thread 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 duncan.tho...@gmail.com wrote:

 On 22 June 2014 14:41, Amrith Kumar amr...@tesora.com 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] [Oslo] Translating log and exception messages in Oslo libraries

2014-06-22 Thread 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 doug.hellm...@dreamhost.com
wrote:

 On Fri, Jun 20, 2014 at 8:40 AM, Mark McLoughlin mar...@redhat.com
 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] [OpenStack-Dev][Cinder] Review days? (open to ANYBODY and EVERYBODY)

2014-06-12 Thread 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 john.griff...@solidfire.com
wrote:

 Hey Everyone,

 So I've been noticing some issues with regards to reviews in Cinder
 lately, namely we're not keeping up very well.  Most of this is a math
 problem (submitters  reviewers).  We're up around 200+ patches in the
 queue, and a large number of them have no negative feedback but have just
 been waiting patiently (some  2 months).

 Growth is good, new contributors are FANTASTIC... but stale submissions in
 the queue are BAD, and I hate for people interested in contributing to
 become discouraged and just go away (almost as much as I hate emails asking
 me to review patches).

 I'd like to propose we consider one or two review days a week for a while
 to try and work on our backlog.  I'd like to propose that on these days we
 make an attempt to NOT propose new code (or at least limit it to bug-fixes
 [real bugs, not features disguised as bugs]) and have an agreement from
 folks to focus on actually doing reviews and using IRC to collaborate
 together and knock some of these out.

 We did this sort of thing over a virtual meetup and it was really
 effective, I'd like to see if we can't do something for a brief duration
 over IRC.

 I'm thinking we give it a test run, set aside a few hours next Wed morning
 to start (coinciding with our Cinder weekly meeting since many folks around
 that morning across TZ's etc) where we all dedicate some time prior to the
 meeting to focus exclusively on helping each other get some reviews knocked
 out.  As a reminder Cinder weekly meeting is 16:00 UTC.

 Let me know what you all think, and keep in mind this is NOT limited to
 just current regular Block-Heads but anybody in the OpenStack community
 that's willing to help out and of course new reviewers are MORE than
 welcome.

 Thanks,
 John

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


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