[openstack-dev] [cinder][manila] PLEASE READ: Change of location for dinner ...

2018-11-13 Thread Jay S Bryant

Team,

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


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


The time is still 8 pm.

Please pass the word on!

Jay


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


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

2018-11-12 Thread Jay S Bryant

Ivan,

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


Jay


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

Thanks for organizing this, Jay,

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



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


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


All,

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

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

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

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

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

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

Hope to see you all on Tuesday!

Jay

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

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



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


[openstack-dev] [cinder] No meeting this week ...

2018-11-12 Thread Jay S Bryant

Team,

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


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

Thanks,

Jay


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


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

2018-11-07 Thread Jay S Bryant

All,

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


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


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

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

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

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


Hope to see you all on Tuesday!

Jay

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

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


Re: [openstack-dev] [all] 2019 summit during May holidays?

2018-11-05 Thread Jay S Bryant



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

*removes all of the hats*

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


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


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


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

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


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



Agreed.

-Julia

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


Hi all,

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

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

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

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


Dmitry

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


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

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



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


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


Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

2018-10-24 Thread Jay S. Bryant



On 10/23/2018 9:01 AM, Jon Bernard wrote:

* melanie witt  wrote:

On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote:

I created a new vm and a new volume with type 'ceph'[So that the volume
will be created on one of two hosts. I assume that the volume created on
host dev@rbd-1#ceph this time]. Next step is to attach the volume to the
vm. At last I want to migrate the volume from host dev@rbd-1#ceph to
host dev@rbd-2#ceph, but it failed with the exception
'NotImplementedError(_("Swap only supports host devices")'.

So that, my real problem is that is there any work to migrate
volume(*in-use*)(*ceph rbd*) from one host(pool) to another host(pool)
in the same ceph cluster?
The difference between the spec[2] with my scope is only one is
*available*(the spec) and another is *in-use*(my scope).


[1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/
[2] https://review.openstack.org/#/c/296150

Ah, I think I understand now, thank you for providing all of those details.
And I think you explained it in your first email, that cinder supports
migration of ceph volumes if they are 'available' but not if they are
'in-use'. Apologies that I didn't get your meaning the first time.

I see now the code you were referring to is this [3]:

if volume.status not in ('available', 'retyping', 'maintenance'):
 LOG.debug('Only available volumes can be migrated using backend '
   'assisted migration. Falling back to generic migration.')
 return refuse_to_migrate

So because your volume is not 'available', 'retyping', or 'maintenance',
it's falling back to generic migration, which will end up with an error in
nova because the source_path is not set in the volume config.

Can anyone from the cinder team chime in about whether the ceph volume
migration could be expanded to allow migration of 'in-use' volumes? Is there
a reason not to allow migration of 'in-use' volumes?

Generally speaking, Nova must facilitate the migration of a live (or
in-use) volume.  A volume attached to a running instance requires code
in the I/O path to correctly route traffic to the correct location - so
Cinder must refuse (or defer) a migrate operation if the volume is
attached.  Until somewhat recently Qemu and Libvirt did not support the
migration to non-block (RBD) targets which is the reason for lack of
support.  I believe we now have all of the pieces to perform this
operation successfully, but I suspect it will require a setup with
correct versions of all the related software.  I will try to verify this
during the current release cycle and report back.

Jon,

Thanks for the explanation and investigation!

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]ceph rbd replication group support

2018-10-21 Thread Jay S. Bryant
I would reach out to Lisa Li (lixiaoy1) on Cinder to see if this is 
something they may pick back up.  She has been more active in the 
community lately and may be able to look at this again or at least have 
good guidance for you.


Thanks!

Jay



On 10/19/2018 1:14 AM, 王俊 wrote:


Hi:

I have a question about rbd replication group, I want to know the plan 
or roadmap about it? Anybody work on it?


Blueprint: 
https://blueprints.launchpad.net/cinder/+spec/ceph-rbd-replication-group-support


Thanks



保密:本函仅供收件人使用,如阁下并非抬头标明的收件人,请您即刻删除本函,勿以任何方式使用及传播,并请您能将此误发情形通知发件人,谢谢! 





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


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


Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

2018-10-21 Thread Jay S. Bryant

Boxiang,

I have not herd any discussion of extending this functionality for Ceph 
to work between different Ceph Clusters.  I wasn't aware, however, that 
the existing spec was limited to one Ceph cluster. So, that is good to know.


I would recommend reaching out to Jon Bernard or Eric Harney for 
guidance on how to proceed.  They work closely with the Ceph driver and 
could provide insight.


Jay


On 10/19/2018 10:21 AM, Boxiang Zhu wrote:


Hi melanie, thanks for your reply.

The version of my cinder and nova is Rocky. The scope of the cinder 
spec[1]
is only for available volume migration between two pools from the same 
ceph cluster.
If the volume is in-use status[2], it will call the generic migration 
function. So that as you
describe it, on the nova side, it raises NotImplementedError(_("Swap 
only supports host devices").

The get_config of net volume[3] has not source_path.

So does anyone try to succeed to migrate volume(in-use) with ceph 
backend or is anyone doing something of it?


[1] https://review.openstack.org/#/c/296150
[2] 
https://review.openstack.org/#/c/256091/23/cinder/volume/drivers/rbd.py
[3] 
https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/volume/net.py#L101



Cheers,
Boxiang
On 10/19/2018 22:39,melanie witt 
 wrote:


On Fri, 19 Oct 2018 11:33:52 +0800 (GMT+08:00), Boxiang Zhu wrote:

When I use the LVM backend to create the volume, then attach
it to a vm.
I can migrate the volume(in-use) from one host to another. The
nova
libvirt will call the 'rebase' to finish it. But if using ceph
backend,
it raises exception 'Swap only supports host devices'. So now
it does
not support to migrate volume(in-use). Does anyone do this
work now? Or
Is there any way to let me migrate volume(in-use) with ceph
backend?


What version of cinder and nova are you using?

I found this question/answer on ask.openstack.org:


https://ask.openstack.org/en/question/112954/volume-migration-fails-notimplementederror-swap-only-supports-host-devices/

and it looks like there was some work done on the cinder side [1] to
enable migration of in-use volumes with ceph semi-recently (Queens).

On the nova side, the code looks for the source_path in the volume
config, and if there is not one present, it raises
NotImplementedError(_("Swap only supports host devices"). So in your
environment, the volume configs must be missing a source_path.

If you are using at least Queens version, then there must be
something
additional missing that we would need to do to make the migration
work.

[1] https://blueprints.launchpad.net/cinder/+spec/ceph-volume-migrate

Cheers,
-melanie





__
OpenStack Development Mailing 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] [all] Naming the T release of OpenStack

2018-10-18 Thread Jay S Bryant



On 10/18/2018 8:29 AM, Neil Jerram wrote:
FWIW, I've have no clue if this is serious or not, or what 'Train' 
refers to...



Neil,

The two Project Team Gathering events in Denver were held at a hotel 
next to the train line from downtown to the airport.  The crossing 
signals there had some sort of malfunction in the past causing them to 
not stop the cars when a train was coming properly.  As a result the 
trains were required to blow their horns when passing through that 
area.  Obviously staying in a hotel, by trains that are blowing their 
horns 24/7 was less than ideal.  As a result, many jokes popped up about 
Denver and trains.


When OpenStack developers think Denver, we think Trains.  :-)

Jay


On Thu, Oct 18, 2018 at 2:25 PM Jay S Bryant <mailto:jungleb...@gmail.com>> wrote:


On 10/18/2018 1:35 AM, Tony Breeds wrote:


Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll

+2 +W  Great names proposed above but based on other discussions
with people I think the community would be happy with the Train
name.  Plus if people ask about it, it gives us an opportunity to
share a story that gives insight into the community we are.  :-) 
Thanks for proposing that path Tony!

Jay

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.


[1]http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2]https://wiki.openstack.org/wiki/Release_Naming/T_Proposals

[3]https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4]https://twitter.com/vkmc/status/1040321043959754752
[5]https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
<https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T%E2%80%93Z>


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



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


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

2018-10-18 Thread Jay S Bryant



On 10/18/2018 7:21 AM, Sean McGinnis wrote:

On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:

On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:

As you may know, unfortunately, Horizon doesn't support all features
provided by APIs. That's why we created feature gaps list [1].

I'd got a lot of great conversations with projects teams during the PTG
and we tried to figure out what should be done prioritize these tasks.
It's really helpful for Horizon to get feedback from other teams to
understand what features should be implemented next.

While I'm filling launchpad with new bugs and blueprints for [1], it
would be good to review this list again and find some volunteers to
decrease feature gaps.

[1] https://etherpad.openstack.org/p/horizon-feature-gap

Thanks everybody for any of your contributions to Horizon.

+openstack-sigs
+openstack-operators

I've left some notes for nova. This looks very similar to the compute API
OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to
really work on without some user/operator feedback - maybe we can get the
user work group involved in trying to help prioritize what people really
want that is missing from horizon, at least for compute?

[1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc

--

Thanks,

Matt

I also have a cinderclient OSC gap analysis I've started working on. It might
be useful to add a Horizon column to this list too.

https://ethercalc.openstack.org/cinderclient-osc-gap
I had forgotten that we had this.  I have added it to the persistent 
links at the top of our meeting agenda page so we have it for future 
reference.  Did the same for the Horizon Feature Gaps.  Think it would 
be good to heave those somewhere that we see them and are reminded about 
them.


Thanks!
Jay

Sean

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



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


Re: [openstack-dev] [all] Naming the T release of OpenStack

2018-10-18 Thread Jay S Bryant

On 10/18/2018 1:35 AM, Tony Breeds wrote:


Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll
+2 +W  Great names proposed above but based on other discussions with 
people I think the community would be happy with the Train name.  Plus 
if people ask about it, it gives us an opportunity to share a story that 
gives insight into the community we are.  :-) Thanks for proposing that 
path Tony!


Jay

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
[3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4] https://twitter.com/vkmc/status/1040321043959754752
[5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


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


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


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

2018-10-09 Thread Jay S Bryant



On 10/8/2018 8:54 AM, Sean McGinnis wrote:

On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote:

In Denver, we agree to add a new "re-image" API in cinder to support upport
volume-backed server rebuild with a new image.

An initial blueprint has been drafted in [3], welcome to review it, thanks.
: )

[snip]

The "force" parameter idea comes from [4], means that
1. we can re-image an "available" volume directly.
2. we can't re-image "in-use"/"reserved" volume directly.
3. we can only re-image an "in-use"/"reserved" volume with "force"
parameter.

And it means nova need to always call re-image API with an extra "force"
parameter,
because the volume status is "in-use" or "reserve" when we rebuild the
server.

*So, what's you idea? Do we really want to add this "force" parameter?*


I would prefer we have the "force" parameter, even if it is something that will
always be defaulted to True from Nova.

Having this exposed as a REST API means anyone could call it, not just Nova
code. So as protection from someone doing something that they are not really
clear on the full implications of, having a flag in there to guard volumes that
are already attached or reserved for shelved instances is worth the very minor
extra overhead.
I concur with Sean's assessment.  I think putting a safety switch in 
place in this design is important to ensure that people using the API 
directly are less likely to do something that they may not actually want 
to do.


Jay

[1] https://etherpad.openstack.org/p/nova-ptg-stein L483
[2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12
[3] https://review.openstack.org/#/c/605317
[4]
https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75

Regards,
Yikun

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


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



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


[openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

2018-10-03 Thread Jay S. Bryant

Team,

We had discussed the possibility of adding Gorka to the stable core team 
during the PTG.  He does review a number of our backport patches and is 
active in that area.


If there are no objections in the next week I will add him to the list.

Thanks!

Jay (jungleboyj)


__
OpenStack Development Mailing 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] Follow-up on core team changes ...

2018-10-03 Thread Jay S. Bryant

Team,

I wanted to follow up on the note I sent a week or so ago about changes 
to the Core team.  I talked to Winston-D (Huang Zhiteng) and it sounded 
like he would not be able to take a more active role.  There were no 
other objections so I am removing him from the Core list.


John Griffith indicated an interest in staying on and thinks that he 
will be able to get more time for Cinder.  As a result we have decided 
to keep him on.


This leaves Cinder with 9 people on the core team.

Thanks!

Jay (jungleboyj)


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


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

2018-10-02 Thread Jay S Bryant
As a friend of Manila I am definitely +1 except that Cinder would like 
him back full time.  ;-)


Jay


On 10/2/2018 12:58 PM, Tom Barron wrote:
Amit Oren has contributed high quality reviews in the last couple of 
cycles so I would like to nominated him for manila core.


Please respond with your +1 or -1 votes.  We'll hold voting open for 7 
days.


Thanks,

-- Tom Barron (tbarron)


__ 


OpenStack Development Mailing 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][qa] Should we enable multiattach in tempest-full?

2018-10-01 Thread Jay S Bryant



On 10/1/2018 10:28 AM, Matt Riedemann wrote:

On 10/1/2018 8:37 AM, Ghanshyam Mann wrote:
+1 on adding multiattach on integrated job. It is always good to 
cover more features in integrate-gate instead of separate jobs. These 
tests does not take much time, it should be ok to add in tempest-full 
[1]. We should make only really slow test as 'slow' otherwise it 
should be fine to run in tempest-full.


I thought adding tempest-slow on cinder was merged but it is not[2]

[1]http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-output.txt.gz#_2018-10-01_10_12_55_482653 


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


Sean and I are working on getting those changes merged.  So, that will 
be good.
Actually it will be enabled in both tempest-full and tempest-slow, 
because there is also a multiattach test marked as 'slow': 
TestMultiAttachVolumeSwap.


I'll push patches today.


Thank you!  I think this is the right way to go.

__
OpenStack Development Mailing 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][elections] Stein TC Election Results

2018-09-28 Thread Jay S Bryant

++ To what Jeremy said and congratulations.


On 9/27/2018 7:19 PM, Jeremy Stanley wrote:

On 2018-09-27 20:00:42 -0400 (-0400), Mohammed Naser wrote:
[...]

A big thank you to our election team who oversees all of this as
well :)

[...]

I wholeheartedly concur!

And an even bigger thank you to the 5 candidates who were not
elected this term; please run again in the next election if you're
able, I think every one of you would have made a great choice for a
seat on the OpenStack TC. Our community is really lucky to have so
many qualified people eager to take on governance tasks.


__
OpenStack Development Mailing 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][forum] Need Topics for Berlin Forum ...

2018-09-24 Thread Jay S Bryant

Team,

Just a reminder that we have an etherpad to plan topics for the Forum in 
Berlin [1].  We are short on topics right now so please take some time 
to think about what we should talk about.  I am also planning time for 
this discussion during our Wednesday meeting this week.


Thanks for taking time to consider topics!

Jay

(jungleboyj)

[1] https://etherpad.openstack.org/p/cinder-berlin-forum-proposals


__
OpenStack Development Mailing 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] Forum Topic Submission Period

2018-09-24 Thread Jay S Bryant

Thank you sir!

Jay


On 9/24/2018 10:10 AM, Jimmy McArthur wrote:

Yes - we are taking submissions through Wednesday :)


Jay S Bryant <mailto:jungleb...@gmail.com>
September 24, 2018 at 10:03 AM

Jimmy,

Having a little trouble getting topics for Cinder.  Hoping to wrangle 
up more in our meeting on Wednesday.  Wanted to make sure that we 
could submit topics on Wednesday.  That is how I interpreted your 
note but wanted to be better safe than sorry.


Thanks!
Jay



On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur <mailto:ji...@openstack.org>
September 17, 2018 at 11:13 AM
Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th. Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step 
on up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum. URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy

___
Openstack-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs




__
OpenStack Development Mailing 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] Forum Topic Submission Period

2018-09-24 Thread Jay S Bryant

Jimmy,

Having a little trouble getting topics for Cinder.  Hoping to wrangle up 
more in our meeting on Wednesday.  Wanted to make sure that we could 
submit topics on Wednesday.  That is how I interpreted your note but 
wanted to be better safe than sorry.


Thanks!
Jay



On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th. Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step on 
up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy



__
OpenStack Development Mailing 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] Mid-Cycle Planning ...

2018-09-21 Thread Jay S Bryant

Team,

As we discussed at the PTG I have started an etherpad to do some 
planning for a possible Cinder Mid-cycle meeting.  Please check out the 
etherpad [1] and leave your input.


Thanks!

Jay

[1] https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning


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


Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

2018-09-21 Thread Jay S Bryant



On 9/21/2018 12:06 PM, John Griffith wrote:




On Fri, Sep 21, 2018 at 11:00 AM Sean McGinnis <mailto:sean.mcgin...@gmx.com>> wrote:


On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote:
> All,
>
> In the last year we have had some changes to Core team
participation.  This
> was a topic of discussion at the PTG in Denver last week.  Based
on that
> discussion I have reached out to John Griffith and Winston D
(Huang Zhiteng)
> and asked if they felt they could continue to be a part of the
Core Team.
> Both agreed that it was time to relinquish their titles.
>
> So, I am proposing to remove John Griffith and Winston D from
Cinder Core.
> If I hear no concerns with this plan in the next week I will
remove them.
>
> It is hard to remove people who have been so instrumental to the
early days
> of Cinder.  Your past contributions are greatly appreciated and
the team
> would be happy to have you back if circumstances every change.
>
> Sincerely,
> Jay Bryant
>

Really sad to see Winston go as he's been a long time member, but
I think over
the last several releases it's been obvious he's had other
priorities to
compete with. It would be great if that were to change some day.
He's made a
lot of great contributions to Cinder over the years.

I'm a little reluctant to make any changes with John though. We've
spoken
briefly. He definitely is off to other things now, but with how
deeply he has
been involved up until recently with things like the multiattach
implementation, replication, and other significant things, I would
much rather
have him around but less active than completely gone. Having a few
good reviews
is worth a lot.



I would propose we hold off on changing John's status for at least
a cycle. He
has indicated to me he would be willing to devote a little time to
still doing
reviews as his time allows, and I would hate to lose out on his
expertise on
changes to some things. Maybe we can give it a little more time
and see if his
other demands keep him too busy to participate and reevaluate later?

Sean

__
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


Hey Everyone,

Now that I'm settling in on my other things I think I can still 
contribute a bit to Cinder on my own time.  I'm still pretty fond of 
OpenStack and Cinder so would love the opportunity to give it a cycle 
to see if I can balance things and still be helpful.


Thanks,
John

Sean,

Thank you for your input on this and for following up with John.

John,

Glad that you are settling into your new position and think some time 
will free up for Cinder again.  I would be happy to have your continued 
input.


I am removing you from consideration for removal.

Jay
(jungleboyj)

__
OpenStack Development Mailing 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] Proposed Changes to the Core Team ...

2018-09-19 Thread Jay S Bryant

All,

In the last year we have had some changes to Core team participation.  
This was a topic of discussion at the PTG in Denver last week.  Based on 
that discussion I have reached out to John Griffith and Winston D (Huang 
Zhiteng) and asked if they felt they could continue to be a part of the 
Core Team.  Both agreed that it was time to relinquish their titles.


So, I am proposing to remove John Griffith and Winston D from Cinder 
Core.  If I hear no concerns with this plan in the next week I will 
remove them.


It is hard to remove people who have been so instrumental to the early 
days of Cinder.  Your past contributions are greatly appreciated and the 
team would be happy to have you back if circumstances every change.


Sincerely,
Jay Bryant

(jungleboyj)


__
OpenStack Development Mailing 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] [docs] Nominating Ian Y. Choi for openstack-doc-core

2018-09-19 Thread Jay S Bryant



On 9/19/2018 1:50 PM, Petr Kovar wrote:

Hi all,

Based on our PTG discussion, I'd like to nominate Ian Y. Choi for
membership in the openstack-doc-core team. I think Ian doesn't need an
introduction, he's been around for a while, recently being deeply involved
in infra work to get us robust support for project team docs translation and
PDF builds.

Having Ian on the core team will also strengthen our integration with
the i18n community.

Please let the ML know should you have any objections.

Petr,

Not a doc Core but wanted to add my support.  Agree he would be a great 
addition.  Appreciate all he does for i18n, docs and OpenStack!


Jay


Thanks,
pk

__
OpenStack Development Mailing 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] Berlin Forum Proposals

2018-09-19 Thread Jay S Bryant

Gorka,

Oh man!  Sorry for the duplication.  I will update the link on the Forum 
page if you are able to move your content over.  Think it will confused 
people less if we use the page I most recently sent out.  Does that make 
sense?


Thanks for catching this mistake!

Jay


On 9/19/2018 4:42 AM, Gorka Eguileor wrote:

On 18/09, Jay S Bryant wrote:

Team,

I have created an etherpad for our Forum Topic Planning:
https://etherpad.openstack.org/p/cinder-berlin-forum-proposals

Please add your ideas to the etherpad.  Thank you!

Jay


Hi Jay,

After our last IRC meeting, a couple of weeks ago, I created an etherpad
[1] and added it to the Forum wiki [2] (though I failed to mention it).

I had added a possible topic to this etherpad [1], but I can move it to
yours and update the wiki if you like.

Cheers,
Gorka.


[1]: https://etherpad.openstack.org/p/cinder-forum-stein
[2]: https://wiki.openstack.org/wiki/Forum/Berlin2018



__
OpenStack Development Mailing 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] Berlin Forum Proposals

2018-09-18 Thread Jay S Bryant

Team,

I have created an etherpad for our Forum Topic Planning: 
https://etherpad.openstack.org/p/cinder-berlin-forum-proposals


Please add your ideas to the etherpad.  Thank you!

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] [ptg][cinder] Stein PTG Summary Page Ready ...

2018-09-18 Thread Jay S Bryant

Team,

I have put together the following page with a summary of all our 
discussions at the PTG: 
https://wiki.openstack.org/wiki/CinderSteinPTGSummary


Please review the contents and let me know if anything needs to be changed.

Jay


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


Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

2018-09-18 Thread Jay S Bryant



On 9/18/2018 7:40 AM, Jeremy Stanley wrote:

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]

I can understand that IRC cannot be used in China which is very
painful and mostly it is used weChat.

[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.

I have team members in Shanghai who are able to access IRC.  I will 
double check, but I am not aware of them doing anything to work around 
the national firewall.  So, I am guessing that we are dealing with the 
usual corporate firewall issues.




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


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


Re: [openstack-dev] [cinder][infra] Remove driverfixes/ocata branch

2018-09-17 Thread Jay S Bryant



On 9/17/2018 10:46 AM, Sean McGinnis wrote:

Plan

We would now like to have the driverfixes/ocata branch deleted so there is no
confusion about where backports should go and we don't accidentally get these
out of sync again.

Infra team, please delete this branch or let me know if there is a process
somewhere I should follow to have this removed.

The first step is to make sure that all changes on the branch are in a non open 
state (merged or abandoned). 
https://review.openstack.org/#/q/project:openstack/cinder+branch:driverfixes/ocata+status:open
 shows that there are no open changes.

Next you will want to make sure that the commits on this branch are preserved 
somehow. Git garbage collection will delete and cleanup commits if they are not 
discoverable when working backward from some ref. This is why our old stable 
branch deletion process required we tag the stable branch as $release-eol 
first. Looking at `git log origin/driverfixes/ocata ^origin/stable/ocata 
--no-merges --oneline` there are quite a few commits on the driverfixes branch 
that are not on the stable branch, but that appears to be due to cherry pick 
writing new commits. You have indicated above that you believe the two branches 
are in sync at this point. A quick sampling of commits seems to confirm this as 
well.

If you can go ahead and confirm that you are ready to delete the 
driverfixes/ocata branch I will go ahead and remove it.

Clark


I did another spot check too to make sure I hadn't missed anything, but it does
appear to be as you stated that the cherry pick resulted in new commits and
they actually are in sync for our purposes.

I believe we are ready to proceed.

Sean,

Thank you for following up on this.  I agee it is a good idea to remove 
the old driverfixes/ocata branch to avoid possible confusion in the future.


Clark,

Sean, myself and the team worked to carefully cherry-pick everything 
that was needed in stable/ocata so I am confident that we are ready to 
remove driverfixes/ocata.


Thanks!
Jay



Thanks for your help.

Sean

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



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


[openstack-dev] [cinder][ptg] Team Photos Posted ...

2018-09-15 Thread Jay S Bryant

Team,

Wanted to share the team photos from the PTG.  You can get them here: 
https://www.dropbox.com/sh/2pmvfkstudih2wf/AADynEnPDJiWIOE2nwjzBgtla/Cinder?dl=0_nav_tracking=1


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] [ptg][cinder][placement] etherpad for this afternoon's meeting

2018-09-11 Thread Jay S Bryant

All,

I have created an etherpad to take notes during our meeting this 
afternoon: https://etherpad.openstack.org/p/cinder-placement-denver-ptg-2018


If you have information you want to get in there before the meeting I 
would appreciate you pre-populating the pad.


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] [ptg][cinder][manila] Team Dinner Plan ...

2018-09-10 Thread Jay S Bryant

All,

We have landed on a decision for the Cinder/Manila Dinner plan.

Here are the details:

Location:  Casey's Bistro and Pub

 * 7:30 pm Tuesday after the Happy Hour

 * 7301 E 29th Ave, Denver, CO 80238

 * Reservation for Amit

See you all there!

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] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

2018-09-10 Thread Jay S Bryant



On 9/10/2018 11:14 AM, Zane Bitter wrote:

On 10/09/18 10:34 AM, Jeremy Stanley wrote:

On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
[...]

# Linking to projects by name

Keen observers might've noticed that StoryBoard recently grew the 
ability

to link to projects by name, rather than by ID number. All the links to
projects in the UI have been replaced with links in this form, and its
probably a good idea for folk to start using them in any documentation
they have. These links look like

https://storyboard.openstack.org/#!/project/openstack-infra/storyboard


Thanks for this!!!

+2  Thank you for addresing this!



[...]

Worth noting, this has made it harder to find the numeric project ID
without falling back on the API. Change
https://review.openstack.org/600893 merged to the releases
repository yesterday allowing deliverable repositories to be
referenced by their StoryBoard project name rather than only the ID
number. If there are other places in tooling and automation where we
relied on the project ID number, work should be done to update those
similarly.


In the docs configuration we use the ID for the generating the bugs 
link. We also rely on it being a numeric ID (as a string - it crashes 
if you use an int) rather than a string to determine whether the 
target is a launchpad project or a storyboard project.



# Finding stories from a task ID

It is now possible to navigate to a story given just a task ID, if for
whatever reason that's all the information you have available. A 
link like


   https://storyboard.openstack.org/#!/task/12389

will work. This will redirect to the story containing the task, and 
is the
first part of work to support linking directly to an individual task 
in a

story.

[...]

As an aside, I think this makes it possible now for us to start
hyperlinking Task footers in commit messages within the Gerrit
change view. I'll try and figure out what we need to adjust in our
Gerrit commentlink and its-storyboard plugin configs to make that
happen.


+1


__ 


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

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



__
OpenStack Development Mailing 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] [docs][cinder] about cinder volume qos

2018-09-10 Thread Jay S Bryant



On 9/10/2018 7:17 AM, Rambo wrote:

Hi,all

      At first,I find it is supported that we can define hard 
performance limits for each volume in doc.openstack.org[1].But only 
can define hard performance limits for each volume type in fact. 
Another, the note"As of the Nova 18.0.0 Rocky release, front end QoS 
settings are only supported when using the libvirt driver.",in fact, 
we have supported the front end QoS settings when using the libvirt 
driver previous. Is the document wrong?Can you tell me more about this 
?Thank you very much.


[1]https://docs.openstack.org/cinder/latest/admin/blockstorage-basic-volume-qos.html




Rambo,

The performance limits are limited to a volume type as you need to have 
a volume type to be able to associate a QoS type with it.  So, that 
makes sense.


As for the documentation, it is a little confusing the way that is 
worded but it isn't wrong.  So, QoS support thus far, including Nova 
18.0.0, front end QoS setting only works with the libvirt driver.  I 
don't interpret that as meaning that there wasn't QoS support before that.


Jay







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] [nova][cinder] about unified limits

2018-09-08 Thread Jay S Bryant

Ben,

Ping me when you are planning on having this discussion if you think of 
it.  Since there is interest in this for Cinder I would like to try to 
be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes 
were captured in etherpad [1]. We spent the Rocky cycle fixing 
usability issues with the API [2] and implementing support for a 
hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick 
transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is over 
it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the request 
claim is valid or not. There are patches up for this work, and 
reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work 
out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit API 
being experimental as we shake out usability issues in both pieces of 
software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we 
can use the first couple iterations to generate some well-written 
usage documentation. Any questions coming from developers in this 
phase should probably be answered in documentation if we want to 
enable folks to pick this up and run with it. Otherwise, I could see 
the handful of people pushing the effort becoming a bottle neck in 
adoption.


Hopefully this helps paint the landscape of where things are 
currently with respect to each piece. As always, let me 

Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

2018-09-08 Thread Jay S Bryant

Ildiko,

Sounds like a good plan.  I don't think I have other plans for Wednesday 
so that should work.


Look forward to seeing you next week!

Jay


On 9/7/2018 5:30 PM, Ildiko Vancsa wrote:

Hi Training Team,

As a couple of us will be at the PTG next week it would be great to get 
together one of the days maybe for lunch.

Wednesday would work the best for Kendall and me, but we can look into other 
days as well if it would not work for the majority of people around.

So my questions would be:

* Are you interested in getting together one of the lunch slots during next 
week?

* Would Wednesday work for you or do you have another preference?

Please drop a response to this thread and we will figure it out by Monday or 
early next week based on the responses.

Thanks,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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][ptg] Topics scheduled for next week ...

2018-09-07 Thread Jay S Bryant

Team,

I have created an etherpad for each of the days of the PTG and split out 
the proposed topics from the planning etherpad into the individual days 
for discussion: [1] [2] [3]


If you want to add an additional topic please add it to Friday or find 
some time on one of the other days.


I look forward to discussing all these topics with you all next week.

Thanks!

Jay

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

[2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday

[3] https://etherpad.openstack.org/p/cinder-ptg-stein-friday


__
OpenStack Development Mailing 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][placement] Room Scheduled for Cinder Placement Discussion ...

2018-09-07 Thread Jay S Bryant

All,

The results of the Doodle poll suggested that the end of the day Tuesday 
was the best option for us all to get together. [1]


I have scheduled the Big Thompson Room on Tuesday from 15:15 to 17:00.

I hope we can all get together there and then to have a good discussion.

Thanks!

Jay

[1] https://doodle.com/poll/4twwhy46bxerrthx#table


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


[openstack-dev] [cinder][nova][placement] Doodle Calendar Created for Placement Discussion

2018-09-06 Thread Jay S Bryant

All,

We discussed in our weekly meeting yesterday that it might be good to 
plan an additional meeting at the PTG to continue discussions with 
regards to Cinder's use of the Placement Service.


I have looked at the room schedule [1] and there are quite a few open 
rooms on Monday.  Fewer rooms on Tuesday but there are still some 
options each day.


Please fill out the poll [2] if you are interested in attending ASAP and 
then I will reserve a room as soon as it looks like we have quorum.


Thank you!

Jay

[1] http://ptg.openstack.org/ptg.html

[2] https://doodle.com/poll/4twwhy46bxerrthx


__
OpenStack Development Mailing 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][neutron] Cross-cell cold migration

2018-08-24 Thread Jay S Bryant



On 8/23/2018 12:07 PM, Gorka Eguileor wrote:

On 23/08, Dan Smith wrote:

I think Nova should never have to rely on Cinder's hosts/backends
information to do migrations or any other operation.

In this case even if Nova had that info, it wouldn't be the solution.
Cinder would reject migrations if there's an incompatibility on the
Volume Type (AZ, Referenced backend, capabilities...)

I think I'm missing a bunch of cinder knowledge required to fully grok
this situation and probably need to do some reading. Is there some
reason that a volume type can't exist in multiple backends or something?
I guess I think of volume type as flavor, and the same definition in two
places would be interchangeable -- is that not the case?


Hi,

I just know the basics of flavors, and they are kind of similar, though
I'm sure there are quite a few differences.

Sure, multiple storage arrays can meet the requirements of a Volume
Type, but then when you create the volume you don't know where it's
going to land. If your volume type is too generic you volume could land
somewhere your cell cannot reach.



I don't know anything about Nova cells, so I don't know the specifics of
how we could do the mapping between them and Cinder backends, but
considering the limited range of possibilities in Cinder I would say we
only have Volume Types and AZs to work a solution.

I think the only mapping we need is affinity or distance. The point of
needing to migrate the volume would purely be because moving cells
likely means you moved physically farther away from where you were,
potentially with different storage connections and networking. It
doesn't *have* to mean that, but I think in reality it would. So the
question I think Matt is looking to answer here is "how do we move an
instance from a DC in building A to building C and make sure the
volume gets moved to some storage local in the new building so we're
not just transiting back to the original home for no reason?"

Does that explanation help or are you saying that's fundamentally hard
to do/orchestrate?

Fundamentally, the cells thing doesn't even need to be part of the
discussion, as the same rules would apply if we're just doing a normal
migration but need to make sure that storage remains affined to compute.


We could probably work something out using the affinity filter, but
right now we don't have a way of doing what you need.

We could probably rework the migration to accept scheduler hints to be
used with the affinity filter and to accept calls with the host or the
hints, that way it could migrate a volume without knowing the
destination host and decide it based on affinity.

We may have to do more modifications, but it could be a way to do it.




I don't know how the Nova Placement works, but it could hold an
equivalency mapping of volume types to cells as in:

  Cell#1Cell#2

VolTypeA <--> VolTypeD
VolTypeB <--> VolTypeE
VolTypeC <--> VolTypeF

Then it could do volume retypes (allowing migration) and that would
properly move the volumes from one backend to another.

The only way I can think that we could do this in placement would be if
volume types were resource providers and we assigned them traits that
had special meaning to nova indicating equivalence. Several of the words
in that sentence are likely to freak out placement people, myself
included :)

So is the concern just that we need to know what volume types in one
backend map to those in another so that when we do the migration we know
what to ask for? Is "they are the same name" not enough? Going back to
the flavor analogy, you could kinda compare two flavor definitions and
have a good idea if they're equivalent or not...

--Dan

In Cinder you don't get that from Volume Types, unless all your backends
have the same hardware and are configured exactly the same.

There can be some storage specific information there, which doesn't
correlate to anything on other hardware.  Volume types may refer to a
specific pool that has been configured in the array to use specific type
of disks.  But even the info on the type of disks is unknown to the
volume type.

I haven't checked the PTG agenda yet, but is there a meeting on this?
Because we may want to have one to try to understand the requirements
and figure out if there's a way to do it with current Cinder
functionality of if we'd need something new.

Gorka,

I don't think that this has been put on the agenda yet.  Might be good 
to add.  I don't think we have a cross project time officially planned 
with Nova.  I will start that discussion with Melanie so that we can 
cover the couple of cross projects subjects we have.


Jay


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-dev] [cinder][manila] Team Dinner Planning at PTG...

2018-08-21 Thread Jay S Bryant

All,

We talked in the Cinder team meeting about doing a joint Cinder/Manila 
team dinner at the PTG in Denver.


I have created a Doodle Poll to indicate what night would work best for 
everyone. [1]  Also, if you are planning to come please add your name in 
the Cinder Etherpad [2].


Look forward to seeing you all at the PTG!

Jay

[1] https://doodle.com/poll/8rm3ahdyhmrtx5gp#table

[2] https://etherpad.openstack.org/p/cinder-ptg-planning-denver-9-2018


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


Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant



On 8/17/2018 12:30 PM, Dan Smith wrote:

The subject of using placement in Cinder has come up, and since then I've had a
few conversations with people in and outside of that team. I really think until
placement is its own project outside of the nova team, there will be resistance
from some to adopt it.

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to) _consume_ placement any time
soon. I hope it will _report_ to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.

Dan,

I don't know of any reason we wouldn't want to report to placement. Just 
a matter of getting a person to implement it.


Also, from a consumption standpoint we really only have one or two 
people are are opposed at this point.  We have time scheduled at the PTG 
to discuss this further.  The discussions in Vancouver seemed to be 
tilting toward the fact that it might solve other technical issues we 
have been having from an Active/Active HA configuration standpoint.  
Just need to get the right people in the room to talk about it.


Jay

What other projects are _likely_ to _consume_ placement even if they
don't know they'd want to? What projects already want to use it but
refuse to because it has Nova smeared all over it? We talked about this
a lot in the early justification for placement, but the demand for that
hasn't really materialized, IMHO; maybe it's just me.


This reluctance on having it part of Nova may be real or just perceived, but
with it within Nova it will likely be an uphill battle for some time convincing
other projects that it is a nicely separated common service that they can use.

Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)

--Dan

__
OpenStack Development Mailing 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] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant



On 8/17/2018 1:34 PM, Sean McGinnis wrote:

Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)


A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


Sean and Tom,

That brief discussion was in Vancouver: 
https://etherpad.openstack.org/p/YVR-cinder-placement


But as Sean indicated I think the long story short was that we would 
make it so that we could use the placement service if it was available 
but would leave the existing functionality in the case it wasn't there.


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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant



On 8/17/2018 10:59 AM, Ed Leafe wrote:

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
  * working towards being official and governed
  * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

Ed,

I started working with Cinder right after the split had taken place.  I 
have had several discussions as to how the split took place and why over 
the years since.


In the case of Cinder we split because the pace at which things were 
changing in the Cinder project had exceeded what could be handled by the 
Nova team.  Nova has always been a busy project and the changes coming 
in for Nova Volume were getting lost in the larger Nova picture.  So, 
Nova Volume was broken out to become Cinder so that people could focus 
on the storage aspect of things and get change through more quickly.


So, I think, for the most part that it has been something that has 
benefited the project.  The exception would be all the challenges that 
have come working cross project on changes that impact both Cinder and 
Nova but that has improved over time.  Given the good leadership I 
envision for the Placement Service I think that is less of a concern.


For the placement service, I would expect that there will be a greater 
rate of change once more projects are using it.  This would also support 
splitting the service out.

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


I do agree that pulling the service out sooner than later is probably best.

-- Ed Leafe






__
OpenStack Development Mailing 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] [puppet] migrating to storyboard

2018-08-17 Thread Jay S Bryant



On 8/16/2018 4:03 PM, Kendall Nelson wrote:


Hello :)

On Thu, Aug 16, 2018 at 12:47 PM Jay S Bryant <mailto:jungleb...@gmail.com>> wrote:


Hey,

Well, the attachments are one of the things holding us up along
with reduced participation in the project and a number of other
challenges.  Getting the time to prepare for the move has been
difficult.


I wouldn't really say we have reduced participation- we've always been 
a small team. In the last year, we've actually seen more involvement 
from new contributors (new and future users of sb) which has been 
awesome :) We even had/have an outreachy intern that has been working 
on making searching and filtering even better.


Prioritizing when to invest time to migrate has been hard for several 
projects so Cinder isn't alone, no worries :)
Sorry, I wasn't clear here.  I was referencing greatly reduced 
participation in Cinder.  I had been hoping to get more time to dig into 
StoryBoard and prepare the team for migration but that has been harder 
given an increased need to do other work in Cinder.


I have noticed that the search in StoryBoard was better so that was 
encouraging.


I am planning to take some time before the PTG to look at how
Ironic has been using Storyboard and take this forward to the team
at the PTG to try and spur the process along.


Glad to hear it! Once I get the SB room on the schedule, you are 
welcome to join the conversations there.  We would love any feedback 
you have on what the 'other challenges' are that you mentioned above.
Yeah, I think it would be good to have time at the PTG to get Manila, 
Cinder, Oslo, etc. together to talk about this.  This will give me 
incentive to do some more experimenting before the PTG.  :-)


See you in Denver.  :-)


Jay Bryant - (jungleboyj)


On 8/16/2018 2:22 PM, Kendall Nelson wrote:

Hey :)

Yes, I know attachments are important to a few projects. They are
on our todo list and we plan to talk about how to implement them
at the upcoming PTG[1].

Unfortunately, we have had other things that are taking priority
over attachments. We would really love to migrate you all, but if
attachments is what is really blocking you and there is no other
workable solution, I'm more than willing to review patches if you
want to help out to move things along a little faster :)

-Kendall Nelson (diablo_rojo)

[1]https://etherpad.openstack.org/p/sb-stein-ptg-planning

On Wed, Aug 15, 2018 at 1:49 PM Jay S Bryant
mailto:jungleb...@gmail.com>> wrote:



On 8/15/2018 11:43 AM, Chris Friesen wrote:
> On 08/14/2018 10:33 AM, Tobias Urdin wrote:
>
>> My goal is that we will be able to swap to Storyboard
during the
>> Stein cycle but
>> considering that we have a low activity on
>> bugs my opinion is that we could do this swap very easily
anything
>> soon as long
>> as everybody is in favor of it.
>>
>> Please let me know what you think about moving to Storyboard?
>
> Not a puppet dev, but am currently using Storyboard.
>
> One of the things we've run into is that there is no way to
attach log
> files for bug reports to a story. There's an open story on
this[1]
> but it's not assigned to anyone.
>
> Chris
>
>
> [1] https://storyboard.openstack.org/#!/story/2003071
<https://storyboard.openstack.org/#%21/story/2003071>
>
Cinder is planning on holding on any migration, like Manila,
until the
file attachment issue is resolved.

Jay
>

__

>
> 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





Thanks!

- 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


Re: [openstack-dev] [puppet] migrating to storyboard

2018-08-16 Thread Jay S Bryant

Hey,

Well, the attachments are one of the things holding us up along with 
reduced participation in the project and a number of other challenges.  
Getting the time to prepare for the move has been difficult.


I am planning to take some time before the PTG to look at how Ironic has 
been using Storyboard and take this forward to the team at the PTG to 
try and spur the process along.


Jay Bryant - (jungleboyj)


On 8/16/2018 2:22 PM, Kendall Nelson wrote:

Hey :)

Yes, I know attachments are important to a few projects. They are on 
our todo list and we plan to talk about how to implement them at the 
upcoming PTG[1].


Unfortunately, we have had other things that are taking priority over 
attachments. We would really love to migrate you all, but if 
attachments is what is really blocking you and there is no other 
workable solution, I'm more than willing to review patches if you want 
to help out to move things along a little faster :)


-Kendall Nelson (diablo_rojo)

[1]https://etherpad.openstack.org/p/sb-stein-ptg-planning

On Wed, Aug 15, 2018 at 1:49 PM Jay S Bryant <mailto:jungleb...@gmail.com>> wrote:




On 8/15/2018 11:43 AM, Chris Friesen wrote:
> On 08/14/2018 10:33 AM, Tobias Urdin wrote:
>
>> My goal is that we will be able to swap to Storyboard during the
>> Stein cycle but
>> considering that we have a low activity on
>> bugs my opinion is that we could do this swap very easily anything
>> soon as long
>> as everybody is in favor of it.
>>
>> Please let me know what you think about moving to Storyboard?
>
> Not a puppet dev, but am currently using Storyboard.
>
> One of the things we've run into is that there is no way to
attach log
> files for bug reports to a story.  There's an open story on this[1]
> but it's not assigned to anyone.
>
> Chris
>
>
> [1] https://storyboard.openstack.org/#!/story/2003071
<https://storyboard.openstack.org/#%21/story/2003071>
>
Cinder is planning on holding on any migration, like Manila, until
the
file attachment issue is resolved.

Jay
>
__

>
> 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://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] [api] [cinder] backup restore in api v2

2018-08-15 Thread Jay S Bryant



On 8/15/2018 8:00 AM, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 07:52:47AM -0500, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem

Thanks for pointing that out Artem. That does appear to be a documentation bug.
The backup API has not changed, so v2 and v3 should be identical in that
regard. We will need to update our docs to reflect that.

Sean

Ah, we just did a really good job of hiding it:

https://developer.openstack.org/api-ref/block-storage/v2/index.html#restore-backup

I see the formatting for that document is off so that it actually appears as a
section under the delete documentation. I will get that fixed.

Artem and Sean,

Thanks for finding that and fixing it.

Jay

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

__
OpenStack Development Mailing 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] [puppet] migrating to storyboard

2018-08-15 Thread Jay S Bryant



On 8/15/2018 11:43 AM, Chris Friesen wrote:

On 08/14/2018 10:33 AM, Tobias Urdin wrote:

My goal is that we will be able to swap to Storyboard during the 
Stein cycle but

considering that we have a low activity on
bugs my opinion is that we could do this swap very easily anything 
soon as long

as everybody is in favor of it.

Please let me know what you think about moving to Storyboard?


Not a puppet dev, but am currently using Storyboard.

One of the things we've run into is that there is no way to attach log 
files for bug reports to a story.  There's an open story on this[1] 
but it's not assigned to anyone.


Chris


[1] https://storyboard.openstack.org/#!/story/2003071

Cinder is planning on holding on any migration, like Manila, until the 
file attachment issue is resolved.


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] [cinder] Reminder about the weekly Cinder meeting ...

2018-08-14 Thread Jay S Bryant



On 8/13/2018 5:44 PM, Jeremy Stanley wrote:

On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote:

I know we did a ping last week in #openstack-ansible for our meeting no
issue. I wonder if it's a length of names thing or a channel setting.

[...]

Freenode's Sigyn bot may not have been invited to
#openstack-ansible. We might want to consider kicking it from
channels while they have nick registration enforced.

It does seem that we don't really need the monitoring if registration is 
enforced.  I would be up for doing this.



__
OpenStack Development Mailing 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] Reminder about the weekly Cinder meeting ...

2018-08-14 Thread Jay S Bryant

Ben,

Don't fully understand why it was kicking me.  I guess one of the 
behaviors that is considered suspicious is trying to message a bunch of 
nicks at once.  I had tried reducing the number of people in my ping but 
it still kicked me and so I decided to not risk it again.


Sounds like the moral of the story is if sigyn is in the channel, be 
careful.  :-)


Jay


On 8/13/2018 4:06 PM, Ben Nemec wrote:



On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 
16:00 UTC.  I bring this up as I can no longer send the courtesy 
pings without being kicked from IRC.  So, if you wish to join the 
meeting please add a reminder to your calendar of choice.


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.



__
OpenStack Development Mailing 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] Reminder about the weekly Cinder meeting ...

2018-08-08 Thread Jay S Bryant

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 
UTC.  I bring this up as I can no longer send the courtesy pings without 
being kicked from IRC.  So, if you wish to join the meeting please add a 
reminder to your calendar of choice.


Thank you!

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

2018-08-08 Thread Jay S Bryant



On 8/8/2018 9:12 AM, Jeremy Stanley wrote:

On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:

So basically, we have added "sl" to osc. Duly noted.

(FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
migration. The train "stutters" a bit during the cutover.)

Now I can base it on PTG design work in a backronym fashion.

[...]

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.


+1



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


__
OpenStack Development Mailing 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] Proposing Zane Bitter as oslo.service core

2018-08-03 Thread Jay S Bryant



On 8/3/2018 11:58 AM, Ben Nemec wrote:

Hi,

Zane has been doing some good work in oslo.service recently and I 
would like to add him to the core team.  I know he's got a lot on his 
plate already, but he has taken the time to propose and review patches 
in oslo.service and has demonstrated an understanding of the code.


Please respond with +1 or any concerns you may have.  Thanks.

-Ben


Not an Oslo Core but wanted to share my +1.  :-)
__ 


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

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



__
OpenStack Development Mailing 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] [infra][horizon][osc] ClientImpact tag automation

2018-08-02 Thread Jay S Bryant



On 8/2/2018 10:59 AM, Radomir Dopieralski wrote:
To be honest, I don't see much point in automatically creating bugs 
that nobody is going to look at. When you implement a new feature, 
it's up to you to make it available in Horizon and CLI and wherever 
else, since the people working there simply don't have the time to 
work on it. Creating a ticket will not magically make someone do that 
work for you. We are happy to assist with this, but that's it. 
Anything else is going to get added whenever someone has any free 
cycles, or it becomes necessary for some reason (like breaking 
compatibility). That's the current reality, and no automation is going 
to help with it.


I disagree with this view.  In the past there have been companies that 
have had people working on Horizon to keep it implemented for their 
purposes.  Have these bugs available would have made their work easier.  
I also know that there are people on the OSC team that just work on 
keeping functions implemented and up to date.


At a minimum, having these bugs automatically opened would help when 
someone is trying to figure out why the new function they are looking 
for is not available in OSC or Horizon.  A search would turn up the fact 
that it hasn't been implemented yet.  Currently, we frequently have the 
discussion 'Has that been implemented in Horizon yet?'  This would 
reduce the confusion around that subject.


So, I support trying to make this happen as I feel it moves us towards a 
better UX for OpenStack.


On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis > wrote:


I'm wondering if someone on the infra team can give me some
pointers on how to
approach something, and looking for any general feedback as well.

Background
==
We've had things like the DocImpact tag that could be added to
commit messages
that would tie into some automation to create a launchpad bug when
that commit
merged. While we had a larger docs team and out-of-tree docs, I
think this
really helped us make sure we didn't lose track of needed
documentation
updates.

I was able to find part of how that is implemented in jeepyb:


http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py

Current Challenge
=
Similar to the need to follow up with documentation, I've seen a
lot of cases
where projects have added features or made other changes that
impact downstream
consumers of that project. Most often, I've seen cases where
something like
python-cinderclient adds some functionality, but it is on projects
like Horizon
or python-openstackclient to proactively go out and discover those
changes.

Not only just seeking out those changes, but also evaluating
whether a given
change should have any impact on their project. So we've ended up
in a lot of
cases where either new functionality isn't made available through
these
interfaces until a cycle or two later, or probably worse, cases
where something
is now broken with no one aware of it until an actual end user
hits a problem
and files a bug.

ClientImpact Plan
=
I've run this by a few people and it seems to have some support.
Or course I'm
open to any other suggestions.

What I would like to do is add a ClientImpact tag handling that
could be added
very similarly to DocImpact. The way I see it working is it would
work in much
the same way where project's can use this to add the tag to a
commit message
when they know it is something that will require additional work
in OSC or
Horizon (or others). Then when that commit merges, automation
would create a
launchpad bug and/or Storyboard story, including a default set of
client
projects. Perhaps we can find some way to make those impacted clients
configurable by source project, but that could be a follow-on
optimization.

I am concerned that this could create some extra overhead for
these projects.
But my hope is it would be a quick evaluation by a bug triager in
those
projects where they can, hopefully, quickly determine if a change
does not in
fact impact them and just close the ones they don't think require
any follow on
work.

I do hope that this will save some time and speed things up
overall for these
projects to be notified that there is something that needs their
attention
without needing someone to take the time to actively go out and
discover that.

Help Needed
===
From the bits I've found for the DocImpact handling, it looks like
it should
not be too much effort to implement the logic to handle a
ClientImpact flag.
But I have not been able to find all the moving parts that work
together to
perform that automation.

If anyone has 

[openstack-dev] [election][cinder] PTL Candidacy for Stein Release

2018-07-30 Thread Jay S Bryant

All,

I have submitted a letter announcing my Cinder PTL Candidacy for the 
Stein Release Cycle here:  https://review.openstack.org/587139


I am including a copy of the letter below.

Thank you for your continued support!

Sincerely,

Jay Bryant (jungleboyj)

-

All,

This letter is to indicate my interest in continuing to serve as
the Cinder PTL for the Stein release. This would be my third
release as PTL and am happy to continue leading this great project.

As I look back at the last two releases we have gotten some
good things done.  The implementation of multi-attach has
been a goal of Cinder for quite some time and I am glad to
have been able to help make this happen.  We have also seen
a change from trying to get new features implemented in Cinder
to fixing bugs and making Cinder more user friendly and stable.
During the Rocky release we have continued to improve our
documentation, have worked on improving HA support and removed
a lot of old code that did not need to remain in tree.
I think this is an important evolution in the Cinder project:
to focus on stability, usability and maintainability of our code.

With that said I think the Stein release is going to be a challenging
release for Cinder.  We have the following issues that are going
to need to be addressed:

* Migration to Storyboard
* Dwindling review support
* Making decisions around the Placement Service and Cinder
* Continuing discussion around Cinder as a Stand-alone service

I am hoping that I will be able to use my experience over
the last two releases to move the above issues forward.

Sincerely,
Jay Bryant (jungleboyj)



__
OpenStack Development Mailing 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] [StoryBoard] issues found while using storyboard

2018-07-23 Thread Jay S Bryant



On 7/23/2018 1:53 PM, Chris Friesen wrote:

Hi,

I'm on a team that is starting to use StoryBoard, and I just thought 
I'd raise some issues I've recently run into.  It may be that I'm 
making assumptions based on previous tools that I've used (Launchpad 
and Atlassian's Jira) and perhaps StoryBoard is intended to be used 
differently, so if that's the case please let me know.


1) There doesn't seem to be a formal way to search for newly-created 
stories that have not yet been triaged.


2) There doesn't seem to be a way to find stories/tasks using 
arbitrary boolean logic, for example something of the form "(A OR (B 
AND C)) AND NOT D". Automatic worklists will only let you do "(A AND 
B) OR (C AND D) OR (E AND F)" and story queries won't even let you do 
that.


3) I don't see a structured way to specify that a bug has been 
confirmed by someone other than the reporter, or how many people have 
been impacted by it.


4) I can't find a way to add attachments to a story.  (Like a big log 
file, or a proposed patch, or a screenshot.)

Chris,

Tom Barron and I have both raised this as a concern for Cinder and 
Manila.  I could not find a bug for not being able to create attachments 
so I have created one: https://storyboard.openstack.org/#!/story/2003071


Jay


5) I don't see a way to search for stories that have not been assigned 
to someone.


6) This is more a convenience thing, but when looking at someone 
else's public automatic worklist, there's no way to see what the query 
terms were that generated the worklist.


Chris

__ 


OpenStack Development Mailing 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] [OSSN-0084] Data retained after deletion of a ScaleIO volume

2018-07-12 Thread Jay S Bryant



On 7/11/2018 1:20 AM, Luke Hinds wrote:



On Tue, Jul 10, 2018 at 9:08 PM, Jim Rollenhagen 
mailto:j...@jimrollenhagen.com>> wrote:


On Tue, Jul 10, 2018 at 3:28 PM, Martin Chlumsky
mailto:martin.chlum...@gmail.com>> wrote:

It is the workaround that is right and the discussion part
that is wrong.

I am familiar with this bug. Using thin volumes
_and/or_ enabling zero padding DOES ensure data contained
in a volume is actually deleted.


Great, that's super helpful. Thanks!

Is there someone (Luke?) on the list that can send a correction
for this OSSN to all the lists it needs to go to?

// jim


It can, but I would want to be sure we get an agreed consensus. The 
note has already gone through a review cycle where a cinder core 
approved the contents:


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

If someone wants to put forward a patch with the needed amendments , I 
can send out a correction to the lists.



All,

I have forwarded this note on to Helen Walsh at Dell EMC (Walsh, Helen 
) as they do not monitor the mailing list as 
closely.  Hopefully we can get her engaged to ensure we get the right 
update out there.


Thanks!



On Tue, Jul 10, 2018 at 10:41 AM Jim Rollenhagen
mailto:j...@jimrollenhagen.com>> wrote:

On Tue, Jul 10, 2018 at 4:20 AM, Luke Hinds
mailto:lhi...@redhat.com>> wrote:

Data retained after deletion of a ScaleIO volume
---

### Summary ###
Certain storage volume configurations allow newly
created volumes to
contain previous data. This could lead to leakage of
sensitive
information between tenants.

### Affected Services / Software ###
Cinder releases up to and including Queens with
ScaleIO volumes
using thin volumes and zero padding.


According to discussion in the bug, this bug occurs with
ScaleIO volumes using thick volumes and with zero padding
disabled.

If the bug is with thin volumes and zero padding, then the
workaround seems quite wrong. :)

I'm not super familiar with Cinder, so could some Cinder
folks check this out and re-issue a more accurate OSSN,
please?

// jim


### Discussion ###
Using both thin volumes and zero padding does not
ensure data contained
in a volume is actually deleted. The default volume
provisioning rule is
set to thick so most installations are likely not
affected. Operators
can check their configuration in `cinder.conf` or
check for zero padding
with this command `scli --query_all`.

 Recommended Actions 

Operators can use the following two workarounds, until
the release of
Rocky (planned 30th August 2018) which resolves the issue.

1. Swap to thin volumes

2. Ensure ScaleIO storage pools use zero-padding with:

`scli --modify_zero_padding_policy
    (((--protection_domain_id  |
    --protection_domain_name )
    --storage_pool_name ) | --storage_pool_id )
    (--enable_zero_padding | --disable_zero_padding)`

### Contacts / References ###
Author: Nick Tait
This OSSN :
https://wiki.openstack.org/wiki/OSSN/OSSN-0084

Original LaunchPad Bug :
https://bugs.launchpad.net/ossn/+bug/1699573

Mailing List : [Security] tag on
openstack-dev@lists.openstack.org

OpenStack Security Project :
https://launchpad.net/~openstack-ossg




__
OpenStack Development Mailing 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 

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

2018-07-06 Thread Jay S Bryant

All,

I have created an etherpad to start planning for the Denver PTG in 
September. [1]  Please start adding topics to the etherpad.


Look forward to seeing you all there!

Jay

(jungleboyj)

[1] https://etherpad.openstack.org/p/cinder-ptg-planning-denver-9-2018



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


Re: [openstack-dev] [openstack-community] Give cinder-backup more CPU resources

2018-07-06 Thread Jay S Bryant



On 7/6/2018 9:33 AM, Alan Bishop wrote:


On Fri, Jul 6, 2018 at 10:18 AM Amy Marrich > wrote:


Hey,

Forwarding to the Dev list as you may get a better response from
there.

Thanks,

Amy (spotz)

On Thu, Jul 5, 2018 at 11:30 PM, Keynes Lee/WHQ/Wistron
mailto:keynes_...@wistron.com>> wrote:

Hi

When making “cinder backup-create”

We found the process “cinder-backup” use 100% util of 1 CPU
core on an OpenStack Controller node.

It not just causes a bad backup performance, also make the
openstack-cinder-backup unstable.

Especially when we make several backup at the same time.

The Controller Node has 40 CPU cores.

Can we assign more CPU resources to cinder-backup ?


This has been addressed in [1], but it may not be in the release 
you're using.


[1] 
https://github.com/openstack/cinder/commit/373b52404151d80e83004a37d543f825846edea1




In addition to the change above we also have 
https://review.openstack.org/#/c/537003/ which should also help with the 
stability issues.  That has been backported as far as Pike.


The change for multiple processes is only in master for the Rocky 
release right now.


Jay


Alan

cid:image007.jpg@01D1747D.DB260110



*Keynes  Lee **李俊賢*

Direct:



+886-2-6612-1025

Mobile:



+886-9-1882-3787

Fax:



+886-2-6612-1991



E-Mail:



keynes_...@wistron.com 


*---*

*This email contains confidential or legally privileged
information and is for the sole use of its intended recipient. *

*Any unauthorized review, use, copying or distribution of this
email or the content of this email is strictly prohibited.*

*If you are not the intended recipient, you may reply to the
sender and should delete this e-mail immediately.*


*---*


___
Community mailing list
commun...@lists.openstack.org

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


__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

2018-06-12 Thread Jay S Bryant



On 6/11/2018 6:00 PM, Matt Riedemann wrote:

On 6/11/2018 3:31 PM, Doug Hellmann wrote:

As we shift teams over to Storyboard, we have another opportunity
to review the processes and to decide how to use the new tool. Some
teams with lightweight processes will be able to move directly with
little impact. Other teams who are doing more tracking and planning
will need to think about how to do that. The new tool provides some
flexibility, and as with any other big change in our community,
we're likely to see a bit of divergence before we collectively
discover what works and teams converge back to a more consistent
approach.  That's normal, expected, and desirable.

I recommend that people spend a little time experimenting on their
own before passing judgement or trying to set standards.

Start by looking at the features of the tool itself.  Set up a work
list and add some stories to it. Set up a board and see how the
automatic work lists help keep it up to date as the story or task
states change. Do the same with a manually managed board. If you
need a project to assign a task to because yours hasn't migrated
yet, use openstack/release-test.

Then think about the workflows you actually use -- not just the
ones you've been doing because that's the way the project has always
been managed. Think about how those workflows might translate over
to the new tool, based on its features. If you're not sure, ask and
we can see what other teams are doing or what people more familiar
with the tool suggest trying.


I'm reminded of something we talked about in IRC last week wrt 
tracking blueprint-type changes over a given series / release in 
storyboard. It was mentioned that storyboard has a not-yet-implemented 
epics feature which is really how we'd probably do this (nested 
stories is another way of thinking about this). So nova could, for 
example, have an epic for Stein and then track a story for each 
blueprint, with the old launchpad blueprint 'work items' (which we 
don't use, but we do have a list of work items in our specs template) 
tracked as tasks - which would also be nice since you can track tasks 
like documentation, CLIs (nova and OSC) and tempest testing (if 
required). One thing people always commit to in their spec is adding 
support for the feature in client libraries, tempest and docs, but 
once the nova server side change is merged those commitments end up 
getting dropped (not always, but more often than I'd like).


Being able to use epics to organize the stories would be very helpful.  
Maybe it is something that can be done with tags but if Storyboard has 
something more purposefully created to track epics like Jira has that 
would help make Storyboard a bit more useful.


__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

2018-06-11 Thread Jay S Bryant



On 6/11/2018 11:54 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2018-06-11 11:42:52 -0500:

On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?

Paul, this is actually one of the big concerns I have with the move to
Storyboard is the fact that there is no longer standardization across
projects.  When I asked about this it was noted that it would be
important for Cinder to document how we use Storyboard so people can
refer to the documentation and know how to use it.  This, however, seems
needlessly complicated. Would have expected how to use Storyboard was
going to be used to be documented/recommended before hand.

I'm not sure what sort of project-specific documentation we think we
need.

Each project team can set up its own board or worklist for a given
series. The "documentation" just needs to point to that thing, right?

Each team may also decide to use a set of tags, and those would need to
be documented, but that's no different from launchpad.
As I understood it, there is no required way to use Storyboard for 
tracking what used to be 'Blueprints'.  So each time will need to 
document how they use Storyboard to record such things.  If I am 
incorrect about this I apologize.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.

Agreed.  Wonder if at the next midcycle it would be worth having a cross
project discussion to try and create some consistency.  That, however,
would require buy-in from at least the core projects.

Why? If we have a large number of projects who agree to use the tool a
certain way, that seems good, regardless of whether any specific teams
are included in the group. Let the outliers document their processes, if
they end up being significantly different.
Fair enough.  It would help if we had buy-in from all of the projects 
but you are right that nothing prevents us from achieving consensus from 
those are are willing to participate.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?


__
OpenStack Development Mailing 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] use of storyboard (was [TC] Stein Goal Selection)

2018-06-11 Thread Jay S Bryant


On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?
Paul, this is actually one of the big concerns I have with the move to 
Storyboard is the fact that there is no longer standardization across 
projects.  When I asked about this it was noted that it would be 
important for Cinder to document how we use Storyboard so people can 
refer to the documentation and know how to use it.  This, however, seems 
needlessly complicated. Would have expected how to use Storyboard was 
going to be used to be documented/recommended before hand.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.
Agreed.  Wonder if at the next midcycle it would be worth having a cross 
project discussion to try and create some consistency.  That, however, 
would require buy-in from at least the core projects.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?




__
OpenStack Development Mailing 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] Recordings from the Vancouver Summit Uploaded

2018-06-11 Thread Jay S Bryant

All,

I have gotten the Vancouver Summit Forum session recordings uploaded to 
YouTube.  You can see the links in our wiki here: 
https://wiki.openstack.org/wiki/VancouverSummit2018Summary


Let me know if you have any questions.

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] [TC] Stein Goal Selection

2018-06-08 Thread Jay S Bryant



On 6/7/2018 5:48 PM, Matt Riedemann wrote:

On 6/7/2018 3:25 PM, Kendall Nelson wrote:
I know it doesn't fit the shiny user facing docket that was discussed 
at the Forum, but I do think its time we make migration official in 
some capacity as a release goal or some other way. Having migrated 
Ironic and having TripleO on the schedule for migration (as requested 
during the last goal discussion) in addition to having migrated Heat, 
Barbican and several others in the last few months we have reached 
the point that I think migration of the rest of the projects is 
attainable by the end of Stein.


Thoughts?


I haven't used it much, but it would be really nice if someone could 
record a modern 'how to storyboard' video for just basic usage/flows 
since most people are used to launchpad by now so dealing with an 
entirely new task tracker is not trivial (or at least, not something I 
want to spend a lot of time figuring out).


I found:

https://www.youtube.com/watch?v=b2vJ9G5pNb4

https://www.youtube.com/watch?v=n_PaKuN4Skk

But those are a bit old.

Helps if I include the link to the video: 
https://www.openstack.org/videos/boston-2017/storyboard-101-survival-guide-to-the-great-migration


Hope that 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] [TC] Stein Goal Selection

2018-06-08 Thread Jay S Bryant



On 6/7/2018 5:48 PM, Matt Riedemann wrote:

On 6/7/2018 3:25 PM, Kendall Nelson wrote:
I know it doesn't fit the shiny user facing docket that was discussed 
at the Forum, but I do think its time we make migration official in 
some capacity as a release goal or some other way. Having migrated 
Ironic and having TripleO on the schedule for migration (as requested 
during the last goal discussion) in addition to having migrated Heat, 
Barbican and several others in the last few months we have reached 
the point that I think migration of the rest of the projects is 
attainable by the end of Stein.


Thoughts?


I haven't used it much, but it would be really nice if someone could 
record a modern 'how to storyboard' video for just basic usage/flows 
since most people are used to launchpad by now so dealing with an 
entirely new task tracker is not trivial (or at least, not something I 
want to spend a lot of time figuring out).


I found:

https://www.youtube.com/watch?v=b2vJ9G5pNb4

https://www.youtube.com/watch?v=n_PaKuN4Skk

But those are a bit old.


Matt,

The following presentation was done in Boston.  If I remember correctly 
they covered some of the basics on how to use Storyboard. [1]


I feel your pain on the migration.  I have used it a bit and and it is 
kind of like a combination of Launchpad and Trello.  I think once we 
start using it the learning curve won't be so bad.


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] Removing Support for Drivers with Failing CI's ...

2018-06-07 Thread Jay S Bryant

Peter,

Thanks for getting that fixed.  The associated patch has been removed so 
we should be good now.


Jay


On 6/7/2018 9:15 AM, Peter Penchev wrote:

On Mon, Jun 04, 2018 at 02:40:09PM -0500, Sean McGinnis wrote:

Our CI has been chugging along since June 2nd (not really related to
the timing of your e-mail, it just so happened that we fixed another
small problem there).  You can see the logs at

   http://logs.ci-openstack.storpool.com/


Thanks Peter.

It looks like the reason the report run doesn't show Storpool reporting is a
due to a mismatch on name. The officially list account is "StorPool CI"
according to https://wiki.openstack.org/wiki/ThirdPartySystems/StorPool_CI

But it appears on looking into this that the real CI account is "StorPool
distributed storage CI". Is that correct? If so, can you update the wiki with
the correct account name?

Right... sorry about that.  I've fixed that in the wiki -
https://wiki.openstack.org/w/index.php?title=ThirdPartySystems=161664

Best regards,
Peter



__
OpenStack Development Mailing 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] summary of joint leadership meeting from 20 May

2018-06-05 Thread Jay S Bryant



On 6/5/2018 7:31 AM, Sean McGinnis wrote:

On Tue, Jun 05, 2018 at 11:21:16AM +0200, Thierry Carrez wrote:

Jay Pipes wrote:

On 06/04/2018 05:02 PM, Doug Hellmann wrote:

[...]>

Personally, I've very much enjoyed the separate PTGs because I've actually
been able to get work done at them; something that was much harder when the
design summits were part of the overall conference.

Right, the trick is to try to preserve that productivity while making it
easier to travel to... One way would be to make sure the PTG remains a
separate event (separate days, separate venues, separate registration),
just co-located in same city and week.


[...]

There are a few plans under consideration, and no firm decisions
have been made, yet. We discussed a strawman proposal to combine
the summit and PTG in April, in Denver, that would look much like
our older Summit events (from the Folsom/Grizzly time frame) with
a few days of conference and a few days of design summit, with some
overlap in the middle of the week.  The dates, overlap, and
arrangements will depend on venue availability.

Has the option of doing a single conference a year been addressed? Seems
to me that we (the collective we) could save a lot of money not having
to put on multiple giant events per year and instead have one.

Yes, the same strawman proposal included the idea of leveraging an
existing international "OpenStack Day" event and raising its profile
rather than organizing a full second summit every year. The second PTG
of the year could then be kept as a separate event, or put next to that
"upgraded" OpenStack Day.


I actually really like this idea. As things slow down, there just aren't enough
of big splashy new things to announce every 6 months. I think it could work
well to have one Summit a year, while using the OSD events as a way to reach
those folks that can't make it to the one big event for the year due to timing
or location.

It could help concentrate efforts to have bigger goals ready by the Summit and
keep things on a better cadence. And if we can still do a PTG-like event along
side one of the OSD events, it would allow development to still get the
valuable face-to-face time that we've come to expect.
I think going to one large summit event a year could be good with a 
co-located PTG type event.  I think, however, that we would still need 
to have a Separate PTG type event at some other point in the year.  I 
think it is going to be hard to keep development momentum going in the 
projects without a couple of face-to-face meetings a year.



Thinking on this is still very much work in progress.

--
Thierry Carrez (ttx)


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



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


Re: [openstack-dev] [cinder] Removing Support for Drivers with Failing CI's ...

2018-06-04 Thread Jay S Bryant

Peter,

Thank you for the update.  We are investigating why this shows up as 
failing in our CI tracking list.


I will hold off on the associated patch.

Thank you for the quick response!

Jay


On 6/4/2018 2:07 PM, Peter Penchev wrote:

On Sat, Jun 02, 2018 at 06:13:23PM -0500, Jay S Bryant wrote:

All,

This note is to make everyone aware that I have submitted patches for a
number of drivers that have not run 3rd party CI in 60 or more days.  The
following is a list of the drivers, how long since their CI last ran and
links to the patches which mark them as unsupported drivers:

  * DataCore CI – 99 Days - https://review.openstack.org/571533
  * Dell EMC CorpHD CI – 121 Days - https://review.openstack.org/571555
  * HGST Solutions CI – 306 Days - https://review.openstack.org/571560
  * IBM GPFS CI – 212 Days - https://review.openstack.org/571590
  * Itri Disco CI – 110 Days - https://review.openstack.org/571592
  * Nimble Storage CI – 78 Days - https://review.openstack.org/571599
  * StorPool – Unknown - https://review.openstack.org/571935
  * Vedams –HPMSA – 442 Days - https://review.openstack.org/571940
  * Brocade OpenStack – CI – 261 Days - https://review.openstack.org/571943

All of these drivers will be marked unsupported for the Rocky release and
will be removed in the Stein release if the 3rd Party CI is not returned to
a working state.

If your driver is on the list and you have questions please respond to this
thread and we can discuss what needs to be done to return support for your
driver.

Thank you for your attention to this matter!

Hi,

Thanks for taking care of Cinder by culling the herd.

The StorPool CI is, understandably, on your list, since we had some
problems with the CI infrastructure (not the driver itself) during
the month of May.  However, we fixed them on May 31st and our CI had
several successful runs then, quickly followed by a slew of failures
because of the "pip version 1" strip()/split() problem in devstack.

Our CI has been chugging along since June 2nd (not really related to
the timing of your e-mail, it just so happened that we fixed another
small problem there).  You can see the logs at

   http://logs.ci-openstack.storpool.com/

I am thinking of scheduling a rerun for all the changes that our CI
failed on (and that have not been merged or abandoned yet); this may
happen in the next couple of days.

So, thanks again for your work on this, and hopefully this message will
serve as a "we're still alive" sign.  If there is anything more we
should do, like reschedule the failed builds, please let us know.

Best regards,
Peter




__
OpenStack Development Mailing 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] [placement] cinder + placement forum session etherpad

2018-06-04 Thread Jay S Bryant



On 6/1/2018 7:28 PM, Chris Dent wrote:

On Wed, 9 May 2018, Chris Dent wrote:


I've started an etherpad for the forum session in Vancouver devoted
to discussing the possibility of tracking and allocation resources
in Cinder using the Placement service. This is not a done deal.
Instead the session is to discuss if it could work and how to make
it happen if it seems like a good idea.

The etherpad is at

   https://etherpad.openstack.org/p/YVR-cinder-placement


The session went well. Some of the members of the cinder team who
might have had more questions had not been able to be at summit so
we were unable to get their input.

We clarified some of the things that cinder wants to be able to
accomplish (run multiple schedulers in active-active and avoid race
conditions) and the fact that this is what placement is built for.
We also made it clear that placement itself can be highly available
(and scalable) because of its nature as a dead-simple web app over a
database.

The next steps are for the cinder team to talk amongst themselves
and socialize the capabilities of placement (with the help of
placement people) and see if it will be suitable. It is unlikely
there will be much visible progress in this area before Stein.

Chris,

Thanks for this update.  I have it on the agenda for the Cinder team to 
discuss this further.  We ran out of time in last week's meeting but 
will hopefully get some time to discuss it this week.  We will keep you 
updated as to how things progress on our end and pull in the placement 
guys as necessary.


Jay


See the etherpad for a bit more detail.



__
OpenStack Development Mailing 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] Organizational diversity tag

2018-06-04 Thread Jay S Bryant



On 6/2/2018 2:08 PM, Doug Hellmann wrote:

Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +:

On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote:
[...]

It feels like we would be saying that we don't trust 2 core reviewers
from the same company to put the project's goals or priorities over
their employer's.  And that doesn't feel like an assumption I would
want us to encourage through a tag meant to show the health of the
project.

[...]

That's one way of putting it. On the other hand, if we ostensibly
have that sort of guideline (say, two core reviewers shouldn't be
the only ones to review a change submitted by someone else from
their same organization if the team is large and diverse enough to
support such a pattern) then it gives our reviewers a better
argument to push back on their management _if_ they're being
strongly urged to review/approve certain patches. At least then they
can say, "this really isn't going to fly because we have to get a
reviewer from another organization to agree it's in the best
interests of the project" rather than "fire me if you want but I'm
not approving that change, no matter how much your product launch is
going to be delayed."

Do we have that problem? I honestly don't know how much pressure other
folks are feeling. My impression is that we've mostly become good at
finding the necessary compromises, but my experience doesn't cover all
of our teams.
In my experience this hasn't been a problem for quite some time.  In the 
past, at least for Cinder, there were some minor cases of this but as 
projects have matured this has been less of an issue.

While I'd like to think a lot of us have the ability to push back on
those sorts of adverse influences directly, I have a feeling not
everyone can comfortably do so. On the other hand, it might also
just be easy enough to give one of your fellow reviewers in another
org a heads up that maybe they should take a look at that patch over
there and provide some quick feedback...

__
OpenStack Development Mailing 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] Removing Support for Drivers with Failing CI's ...

2018-06-02 Thread Jay S Bryant

All,

This note is to make everyone aware that I have submitted patches for a 
number of drivers that have not run 3rd party CI in 60 or more days.  
The following is a list of the drivers, how long since their CI last ran 
and links to the patches which mark them as unsupported drivers:


 * DataCore CI – 99 Days - https://review.openstack.org/571533
 * Dell EMC CorpHD CI – 121 Days - https://review.openstack.org/571555
 * HGST Solutions CI – 306 Days - https://review.openstack.org/571560
 * IBM GPFS CI – 212 Days - https://review.openstack.org/571590
 * Itri Disco CI – 110 Days - https://review.openstack.org/571592
 * Nimble Storage CI – 78 Days - https://review.openstack.org/571599
 * StorPool – Unknown - https://review.openstack.org/571935
 * Vedams –HPMSA – 442 Days - https://review.openstack.org/571940
 * Brocade OpenStack – CI – 261 Days - https://review.openstack.org/571943

All of these drivers will be marked unsupported for the Rocky release 
and will be removed in the Stein release if the 3rd Party CI is not 
returned to a working state.


If your driver is on the list and you have questions please respond to 
this thread and we can discuss what needs to be done to return support 
for your driver.


Thank you for your attention to this matter!

Jay

(jungleboy)

__
OpenStack Development Mailing 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][all] A culture change (nitpicking)

2018-05-29 Thread Jay S Bryant


On 5/29/2018 3:19 PM, Doug Hellmann wrote:

Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:

On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
:> >> maybe we're all saying the same thing here?
:> > Yeah, I feel like we're all essentially in agreement that nits (of the
:> > English mistake of typo type) do need to get fixed, but sometimes
:> > (often?) putting the burden of fixing them on the original patch
:> > contributor is neither fair nor constructive.
:> I am ok with this statement if we are all in agreement that doing
:> follow-up patches is an acceptable practice.
:
:Has it ever not been?
:
:It seems like it has always come down to a bit of negotiation with
:the original author, hasn't it? And that won't change, except that
:we will be emphasizing to reviewers that we encourage them to be
:more active in seeking out that negotiation and then proposing
:patches?

Exactly, it's more codifying a default.

It's not been unacceptable but I think there's some understandable
reluctance to make changes to someone else's work, you don't want to
seem like your taking over or getting in the way.  At least that's
what's in my head when deciding should this be a comment or a patch.

I think this discussion suggests for certain class of "nits" patch is
preferred to comment.  If that is true making this explicit is a good
thing becuase let's face it my social skills are only marginally
better than my speeling :)

-Jon


OK, that's all good. I'm just surprised to learn that throwing a
follow-up patch on top of someone else's patch was ever seen as
discouraged.

The spice must flow,
Doug


Maybe it would be different now that I am a Core/PTL but in the past I 
had been warned to be careful as it could be misinterpreted if I was 
changing other people's patches or that it could look like I was trying 
to pad my numbers. (I am a nit-picker though I do my best not to be.


I am happy if people understand I am just trying to keep the process 
moving and keep the read/flow of Cinder consistent.  :-)


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] [tc][all] A culture change (nitpicking)

2018-05-29 Thread Jay S Bryant



On 5/29/2018 2:06 PM, Artom Lifshitz wrote:

On Tue, May 29, 2018 at 10:52:04AM -0400, Mohammed Naser wrote:

:On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
:>  One idea would be that, once the meat of the patch
:> has passed multiple rounds of reviews and looks good, and what remains
:> is only nits, the reviewer themselves take on the responsibility of
:> pushing a new patch that fixes the nits that they found.

Doesn't the above suggestion sufficiently address the concern below?

:I'd just like to point out that what you perceive as a 'finished
:product that looks unprofessional' might be already hard enough for a
:contributor to achieve.  We have a lot of new contributors coming from
:all over the world and it is very discouraging for them to have their
:technical knowledge and work be categorized as 'unprofessional'
:because of the language barrier.
:
:git-nit and a few minutes of your time will go a long way, IMHO.

As very intermittent contributor and native english speaker with
relatively poor spelling and typing I'd be much happier with a
reviewer pushing a patch that fixes nits rather than having a ton of
inline comments that point them out.

maybe we're all saying the same thing here?

Yeah, I feel like we're all essentially in agreement that nits (of the
English mistake of typo type) do need to get fixed, but sometimes
(often?) putting the burden of fixing them on the original patch
contributor is neither fair nor constructive.
I am ok with this statement if we are all in agreement that doing 
follow-up patches is an acceptable practice.



__
OpenStack Development Mailing 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][all] A culture change (nitpicking)

2018-05-29 Thread Jay S Bryant

Julia,

Thank you for starting this discussion.


On 5/29/2018 9:43 AM, Artom Lifshitz wrote:

I dunno, there's a fine line to be drawn between getting a finished
product that looks unprofessional (because of typos, English mistakes,
etc), and nitpicking to the point of smothering and being
counter-productive. One idea would be that, once the meat of the patch
has passed multiple rounds of reviews and looks good, and what remains
is only nits, the reviewer themselves take on the responsibility of
pushing a new patch that fixes the nits that they found.
In the past this is something that I have wanted to do but have received 
mixed feedback on its level of appropriateness.  I am happy to push 
follow-up patches to address nit-picks rather than hold up a patch.  We, 
however, will need to communicate to the community that this is now an 
acceptable practice.



On Tue, May 29, 2018 at 9:55 AM, Julia Kreger
 wrote:

During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to revise it over
and over.

While nitpicks do help guide and teach, the consensus seemed to be
that we do need to shift the culture a little bit. As such, I've
proposed a change to our principles[1] in governance that attempts to
capture the essence and spirit of the nitpicking topic as a first
step.

-Julia
-
[1]: https://review.openstack.org/570940

__
OpenStack Development Mailing 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] Project Team Dinner at Vancouver Summit

2018-05-16 Thread Jay S Bryant

Team,

We discussed having a team dinner like we have done in the past during 
today's team meeting.  It sounded like most people would be available 
Tuesday evening, so that is the evening I am planning for.


If you are able to attend please add your name to the etherpad [1] by 
Sunday 5/20 so that I can make reservations.


Thank you!

Jay

[1] https://etherpad.openstack.org/p/YVR18-cinder-dinner


__
OpenStack Development Mailing 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] forum etherpads now available ...

2018-05-14 Thread Jay S Bryant

All,

I have etherpads created for our Cinder related Forum discussions:

 * Tuesday, 5/22 11:00 to 11:40 - Room 221-222 - Cinder High
   Availability (HA) Discussion
   -https://etherpad.openstack.org/p/YVR18-cinder-ha-forum
 * Tuesday, 5/22 11:50 to 12:30 - Room 221-222 - Multi-attach
   Introduction and Future Direction
   -https://etherpad.openstack.org/p/YVR18-cinder-mutiattach-forum
 * Wednesday, 5/23 9:40 to 10:30 - Room 221-222 - Cinder's
   Documentation Discussion
   -https://etherpad.openstack.org/p/YVR18-cinder-documentation-forum

We also have the session on using the placement service:

 * Monday 5/21 16:20 to 17:00 - Planning to use Placement in
   Cinderhttps://etherpad.openstack.org/p/YVR-cinder-placement

Please take some time to look at the etherpads before the forum and add 
your thoughts/questions for discussion.


Thank you!

Jay Bryant

(jungleboyj)

__
OpenStack Development Mailing 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] about re-image the volume

2018-03-30 Thread Jay S Bryant



On 3/29/2018 8:36 PM, Matt Riedemann wrote:

On 3/29/2018 6:50 PM, Sean McGinnis wrote:
May we can add a "Reimaging" state to the volume? Then Nova could 
poll for it

to go from that back to Available?


That would be fine with me, and maybe similar to how 'extending' and 
'retyping' work for an attached volume?


Nova wouldn't wait for the volume to go to 'available', we don't want 
it to go to 'available', we'd just wait for it to go back to 
'reserved'. During a rebuild the instance still needs to keep the 
volume logically attached to it so another instance can't grab it.



This all sounds reasonable to me.

Thanks for hashing it out guys!

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] Support share backup to different projects?

2018-03-20 Thread Jay S Bryant

Tommy,

I am still not sure that this is going to move the team to a different 
decision.


Now that you have more information you can propose it as a topic in 
tomorrow's team meeting if you wish.


Jay


On 3/20/2018 8:54 PM, TommyLike Hu wrote:


Thanks Jay,
    The question is AWS doesn't have the concept of backup and their 
snapshot is incremental backup internally and will be finllay stored 
into S3 which is more sound like backup for us. Our snapshot can not 
be used across AZ.


Jay S Bryant <jungleb...@gmail.com 
<mailto:jungleb...@gmail.com>>于2018年3月21日周三 上午4:13写道:




On 3/19/2018 10:55 PM, TommyLike Hu wrote:

Now Cinder can transfer volume (with or without snapshots) to
different projects,  and this make it possbile to transfer data
across tenant via volume or image. Recently we had a conversation
with our customer from Germany, they mentioned they are more
pleased if we can support transfer data accross tenant via backup
not image or volume, and these below are some of their concerns:

1. There is a use case that they would like to deploy their
develop/test/product systems in the same region but within
different tenants, so they have the requirment to share/transfer
data across tenants.

2. Users are more willing to use backups to secure/store their
volume data since backup feature is more advanced in product
openstack version (incremental backups/periodic backups/etc.).

3. Volume transfer is not a valid option as it's in AZ and it's a
complicated process if we would like to share the data to
multiple projects (keep copy in all the tenants).

4. Most of the users would like to use image for bootable volume
only and share volume data via image means the users have to
maintain lots of image copies when volume backup changed as well
as the whole system needs to differentiate bootable images and
none bootable images, most important, we can not restore volume
data via image now.

5. The easiest way for this seems to support sharing backup to
different projects, the owner project have the full authority
while shared projects only can view/read the backups.

6. AWS has the similar concept, share snapshot. We can share it
by modify the snapshot's create volume permissions [1].

Looking forward to any like or dislike or suggestion on this idea
accroding to my feature proposal experience:)


Thanks
TommyLike


[1]:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html


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

Tommy,

As discussed at the PTG, this still sounds like improper usage of
Backup.  Happy to hear input from others but I am having trouble
getting my head around it.

The idea of sharing a snapshot, as you mention AWS supports sounds
like it could be a more sensible approach.  Why are you not
proposing that?

Jay

__
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] [cinder] Support share backup to different projects?

2018-03-20 Thread Jay S Bryant



On 3/19/2018 10:55 PM, TommyLike Hu wrote:
Now Cinder can transfer volume (with or without snapshots) to 
different projects,  and this make it possbile to transfer data across 
tenant via volume or image. Recently we had a conversation with our 
customer from Germany, they mentioned they are more pleased if we can 
support transfer data accross tenant via backup not image or volume, 
and these below are some of their concerns:


1. There is a use case that they would like to deploy their 
develop/test/product systems in the same region but within different 
tenants, so they have the requirment to share/transfer data across 
tenants.


2. Users are more willing to use backups to secure/store their volume 
data since backup feature is more advanced in product openstack 
version (incremental backups/periodic backups/etc.).


3. Volume transfer is not a valid option as it's in AZ and it's a 
complicated process if we would like to share the data to multiple 
projects (keep copy in all the tenants).


4. Most of the users would like to use image for bootable volume only 
and share volume data via image means the users have to maintain lots 
of image copies when volume backup changed as well as the whole system 
needs to differentiate bootable images and none bootable images, most 
important, we can not restore volume data via image now.


5. The easiest way for this seems to support sharing backup to 
different projects, the owner project have the full authority while 
shared projects only can view/read the backups.


6. AWS has the similar concept, share snapshot. We can share it by 
modify the snapshot's create volume permissions [1].


Looking forward to any like or dislike or suggestion on this idea 
accroding to my feature proposal experience:)



Thanks
TommyLike


[1]: 
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.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

Tommy,

As discussed at the PTG, this still sounds like improper usage of 
Backup.  Happy to hear input from others but I am having trouble getting 
my head around it.


The idea of sharing a snapshot, as you mention AWS supports sounds like 
it could be a more sensible approach.  Why are you not proposing that?


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] Vancouver Summit Schedule now live!

2018-03-15 Thread Jay S Bryant



On 3/15/2018 1:14 PM, Matt Riedemann wrote:

On 3/15/2018 11:05 AM, Kendall Waters wrote:
The schedule is organized by new tracks according to use cases: 
private & hybrid cloud, public cloud, container infrastructure, CI / 
CD, edge computing, HPC / GPUs / AI, and telecom / NFV. You can sort 
within the schedule to find sessions and speakers around each topic 
or open source project (with new tags!).


I've asked about this before, but are the project updates no longer 
happening at this summit? Maybe those are too silo'ed to fall into the 
track buckets. I ask because I don't see anything in the schedule 
about project updates.



Matt,

Project updates are happening.  I think it is Anne and Kendall N that 
are setting those up.  An e-mail went out to PTLs about that a while 
back asking if they wanted to participate.


I found it weird too that the schedule went out without those listed.  I 
know they are busy, however, trying to coordinate those and the 
onboarding sessions.


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] [First Contact][SIG] [PTG] Summary of Discussions

2018-03-14 Thread Jay S Bryant



On 3/14/2018 10:57 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2018-03-14 10:38:37 -0500:

On 3/14/2018 10:04 AM, Petr Kovar wrote:

On Tue, 13 Mar 2018 18:57:24 -0500
Jay S Bryant <jungleb...@gmail.com> wrote:


Amy,

The top level page for projects is referenced under documentation from
here:  https://docs.openstack.org/queens/projects.html

So, I think we have that one covered for people who are just looking for
the top level documentation.

Yes, we have that covered. Just to clarify this a bit further, we also have
project lists like https://docs.openstack.org/queens/install/,
https://docs.openstack.org/queens/admin/ and
https://docs.openstack.org/queens/configuration/, what's missing is
https://docs.openstack.org/queens/contributor/.

Cheers,
pk


Petr,

Do we need a contributor link per-release?  I thought in past
discussions that the contributor info should always go to latest and
that was why this is slightly different.

Jay

We can have a per-series page that lists all projects and links to their
"latest" contributor doc page.


Agreed.  That would make the most sense.


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


Re: [openstack-dev] [First Contact][SIG] [PTG] Summary of Discussions

2018-03-14 Thread Jay S Bryant



On 3/14/2018 10:04 AM, Petr Kovar wrote:

On Tue, 13 Mar 2018 18:57:24 -0500
Jay S Bryant <jungleb...@gmail.com> wrote:


Amy,

The top level page for projects is referenced under documentation from
here:  https://docs.openstack.org/queens/projects.html

So, I think we have that one covered for people who are just looking for
the top level documentation.

Yes, we have that covered. Just to clarify this a bit further, we also have
project lists like https://docs.openstack.org/queens/install/,
https://docs.openstack.org/queens/admin/ and
https://docs.openstack.org/queens/configuration/, what's missing is
https://docs.openstack.org/queens/contributor/.

Cheers,
pk


Petr,

Do we need a contributor link per-release?  I thought in past 
discussions that the contributor info should always go to latest and 
that was why this is slightly different.


Jay



On 3/13/2018 3:02 PM, Amy Marrich wrote:

I think if we're going to have that go to the development contributors
section (which makes sense) maybe we should also have ways of getting
to the deployment and admin docs as well?

Amy (spotz)

On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant <jungleb...@gmail.com
<mailto:jungleb...@gmail.com>> wrote:



 On 3/13/2018 1:38 PM, Petr Kovar wrote:

 On Thu, 8 Mar 2018 12:54:06 -0600
     Jay S Bryant <jungleb...@gmail.com
 <mailto:jungleb...@gmail.com>> wrote:

 Good overview.  Thank you!

 One additional goal I want to mention on the list, for
 awareness, is the
 fact that we would like to eventually get some consistency
 to the pages
 that the 'Contributor Guide' lands on for each of the
 projects.  Needs
 to be a page that is friendly to new contributors, makes
 it easy to
 learn about the project and is not overwhelming.

 What exactly that looks like isn't defined yet but I have
 talked to
 Manila about this.  They were interested in working
 together on this.
 Cinder and Manila will work together to get something
 consistent put
 together and then we can work on spreading that to other
 projects once
 we have agreement from the SIG that the approach is agreeable.

 This is a good cross-project goal, I think. We discussed a
 similar approach
 in the docs room wrt providing templates to project teams that
 they can
 use to design their landing pages for admin, user,
 configuration docs; that
 would also include the main index page for project docs.

 As for the project-specific contributor guides,
 https://docs.openstack.org/doc-contrib-guide/project-guides.html
 <https://docs.openstack.org/doc-contrib-guide/project-guides.html>
 specifies
 that any contributor content should go to
 doc/source/contributor/. This will
 allow us to use templates to generate lists of links,
 similarly to what
 we do for other content areas.

 Cheers,
 pk


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

 Petr,

 Good point.  I was trying to think of how to make a better landing
 page for new contributors and you may have hit on the answer.
 RIght now when you click through from  here:
 https://www.openstack.org/community
 <https://www.openstack.org/community> You land at the top level
 Cinder documentation page which is incredibly overwhelming for a
 new person: https://docs.openstack.org/cinder/latest/
 <https://docs.openstack.org/cinder/latest/>

 If the new contributor page instead lands here:
 https://docs.openstack.org/cinder/latest/contributor/index.html
 <https://docs.openstack.org/cinder/latest/contributor/index.html>
 It would give me a page to craft for new users looking for
 information to get started.

 Thoughts on this approach?

 Kendall and Mike ... Does the above approach make sense?

 Jay



 __
 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

Re: [openstack-dev] [nova] about rebuild instance booted from volume

2018-03-14 Thread Jay S Bryant


On 3/14/2018 9:10 AM, Tim Bell wrote:

Matt,

To add another scenario and make things even more difficult (sorry (), if the 
original volume has snapshots, I don't think you can delete it.

Tim

Tim,

You are correct.  You can't delete volumes with snapshots.

Jay




-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 14 March 2018 at 14:55
To: "openstack-dev@lists.openstack.org" , 
openstack-operators 
Subject: Re: [openstack-dev] [nova] about rebuild instance booted from volume

 On 3/14/2018 3:42 AM, 李杰 wrote:
 >
 >  This is the spec about  rebuild a instance booted from
 > volume.In the spec,there is a
 >question about if we should delete the old root_volume.Anyone who
 > is interested in
 >booted from volume can help to review this. Any suggestion is
 > welcome.Thank you!
 >The link is here.
 >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
 
 Copying the operators list and giving some more context.
 
 This spec is proposing to add support for rebuild with a new image for

 volume-backed servers, which today is just a 400 failure in the API
 since the compute doesn't support that scenario.
 
 With the proposed solution, the backing root volume would be deleted and

 a new volume would be created from the new image, similar to how boot
 from volume works.
 
 The question raised in the spec is whether or not nova should delete the

 root volume even if its delete_on_termination flag is set to False. The
 semantics get a bit weird here since that flag was not meant for this
 scenario, it's meant to be used when deleting the server to which the
 volume is attached. Rebuilding a server is not deleting it, but we would
 need to replace the root volume, so what do we do with the volume we're
 replacing?
 
 Do we say that delete_on_termination only applies to deleting a server

 and not rebuild and therefore nova can delete the root volume during a
 rebuild?
 
 If we don't delete the volume during rebuild, we could end up leaving a

 lot of volumes lying around that the user then has to clean up,
 otherwise they'll eventually go over quota.
 
 We need user (and operator) feedback on this issue and what they would

 expect to happen.
 
 --
 
 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] [PTG] Summary of Discussions

2018-03-13 Thread Jay S Bryant

Amy,

The top level page for projects is referenced under documentation from 
here:  https://docs.openstack.org/queens/projects.html


So, I think we have that one covered for people who are just looking for 
the top level documentation.


Jay


On 3/13/2018 3:02 PM, Amy Marrich wrote:
I think if we're going to have that go to the development contributors 
section (which makes sense) maybe we should also have ways of getting 
to the deployment and admin docs as well?


Amy (spotz)

On Tue, Mar 13, 2018 at 2:55 PM, Jay S Bryant <jungleb...@gmail.com 
<mailto:jungleb...@gmail.com>> wrote:




On 3/13/2018 1:38 PM, Petr Kovar wrote:

On Thu, 8 Mar 2018 12:54:06 -0600
    Jay S Bryant <jungleb...@gmail.com
<mailto:jungleb...@gmail.com>> wrote:

Good overview.  Thank you!

One additional goal I want to mention on the list, for
awareness, is the
fact that we would like to eventually get some consistency
to the pages
that the 'Contributor Guide' lands on for each of the
projects.  Needs
to be a page that is friendly to new contributors, makes
it easy to
learn about the project and is not overwhelming.

What exactly that looks like isn't defined yet but I have
talked to
Manila about this.  They were interested in working
together on this.
Cinder and Manila will work together to get something
consistent put
together and then we can work on spreading that to other
projects once
we have agreement from the SIG that the approach is agreeable.

This is a good cross-project goal, I think. We discussed a
similar approach
in the docs room wrt providing templates to project teams that
they can
use to design their landing pages for admin, user,
configuration docs; that
would also include the main index page for project docs.

As for the project-specific contributor guides,
https://docs.openstack.org/doc-contrib-guide/project-guides.html
<https://docs.openstack.org/doc-contrib-guide/project-guides.html>
specifies
that any contributor content should go to
doc/source/contributor/. This will
allow us to use templates to generate lists of links,
similarly to what
we do for other content areas.

Cheers,
pk



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

Petr,

Good point.  I was trying to think of how to make a better landing
page for new contributors and you may have hit on the answer. 
RIght now when you click through from  here:
https://www.openstack.org/community
<https://www.openstack.org/community> You land at the top level
Cinder documentation page which is incredibly overwhelming for a
new person: https://docs.openstack.org/cinder/latest/
<https://docs.openstack.org/cinder/latest/>

If the new contributor page instead lands here:
https://docs.openstack.org/cinder/latest/contributor/index.html
<https://docs.openstack.org/cinder/latest/contributor/index.html>
It would give me a page to craft for new users looking for
information to get started.

Thoughts on this approach?

Kendall and Mike ... Does the above approach make sense?

Jay



__
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
<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] [PTG] Summary of Discussions

2018-03-13 Thread Jay S Bryant



On 3/13/2018 1:38 PM, Petr Kovar wrote:

On Thu, 8 Mar 2018 12:54:06 -0600
Jay S Bryant <jungleb...@gmail.com> wrote:


Good overview.  Thank you!

One additional goal I want to mention on the list, for awareness, is the
fact that we would like to eventually get some consistency to the pages
that the 'Contributor Guide' lands on for each of the projects.  Needs
to be a page that is friendly to new contributors, makes it easy to
learn about the project and is not overwhelming.

What exactly that looks like isn't defined yet but I have talked to
Manila about this.  They were interested in working together on this.
Cinder and Manila will work together to get something consistent put
together and then we can work on spreading that to other projects once
we have agreement from the SIG that the approach is agreeable.

This is a good cross-project goal, I think. We discussed a similar approach
in the docs room wrt providing templates to project teams that they can
use to design their landing pages for admin, user, configuration docs; that
would also include the main index page for project docs.

As for the project-specific contributor guides,
https://docs.openstack.org/doc-contrib-guide/project-guides.html specifies
that any contributor content should go to doc/source/contributor/. This will
allow us to use templates to generate lists of links, similarly to what
we do for other content areas.

Cheers,
pk


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

Petr,

Good point.  I was trying to think of how to make a better landing page 
for new contributors and you may have hit on the answer.  RIght now when 
you click through from  here: https://www.openstack.org/community  You 
land at the top level Cinder documentation page which is incredibly 
overwhelming for a new person:  https://docs.openstack.org/cinder/latest/


If the new contributor page instead lands here: 
https://docs.openstack.org/cinder/latest/contributor/index.html It would 
give me a page to craft for new users looking for information to get 
started.


Thoughts on this approach?

Kendall and Mike ... Does the above approach make sense?

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] [oslo] cinder.conf generation is broken for my_ip, building non-reproducibly

2018-03-12 Thread Jay S Bryant

Thomas,

Thanks for finding this.  I have opened a bug and submitted a patch.

Patch:  https://review.openstack.org/552134

Bug:  https://bugs.launchpad.net/cinder/+bug/1755282

Jay

(jungleboyj)


On 3/12/2018 3:17 AM, Thomas Goirand wrote:

Hi,

When inspecting Cinder's (Queens release) cinder.conf, I can see:

# Warning: Failed to format sample for my_ip
# unhashable type: 'HostAddress'

So it seems there's an issue in either Cinder or Oslo. How can I
investigate and fix this?

It's very likely that I'm once more the only person in the OpenStack
community that is really checking config file generation (it used to be
like that for past releases), and therefore the only one who noticed it.

Also, looking at the code, this seems to be yet-another-instance of
"package cannot be built reproducible" [1] with the build host config
leaking in the configuration (well, once that's fixed...). Indeed, in
the code I can read:

 cfg.HostAddressOpt('my_ip',
default=netutils.get_my_ipv4(),
help='IP address of this host'),

This means that, when that's repaired, build Cinder will write something
like this:

#my_ip = 1.2.3.4

With 1.2.3.4 being the value of netutils.get_my_ipv4(). This is easily
fixed by adding something like this:

sample-default=''

I'm writing this here for Cinder, but there's been numerous cases like
this already. The most common mistake being the hostname of the build
host leaking in the configuration. While this is easily fixed at the
packaging level fixing the config file after generating it with
oslo.config, often that config file is also built with the sphinx doc,
and then that file isn't built reproducibly. That's harder to detect,
and easier fixed upstream.

Cheers,

Thomas Goirand (zigo)

[1] https://reproducible-builds.org/

__
OpenStack Development Mailing 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] [PTG] Summary of Discussions

2018-03-08 Thread Jay S Bryant

Good overview.  Thank you!

One additional goal I want to mention on the list, for awareness, is the 
fact that we would like to eventually get some consistency to the pages 
that the 'Contributor Guide' lands on for each of the projects.  Needs 
to be a page that is friendly to new contributors, makes it easy to 
learn about the project and is not overwhelming.


What exactly that looks like isn't defined yet but I have talked to 
Manila about this.  They were interested in working together on this.  
Cinder and Manila will work together to get something consistent put 
together and then we can work on spreading that to other projects once 
we have agreement from the SIG that the approach is agreeable.


Jay

(jungleboyj)



On 3/5/2018 2:00 PM, Kendall Nelson wrote:

Hello Everyone :)

It was wonderful to see and talk with so many of you last week! For 
those that couldn't attend our whole day of chats or those that 
couldn't attend at all, I thought I would put forth a summary of our 
discussions which were mostly noted in the etherpad[1]


#Contributor Guide#

- Walkthrough: We walked through every section of what exists and came 
up with a variety of improvements on what is there. Most of these 
items have been added to our StoryBoard project[2]. This came up again 
Tuesday in docs sessions and I have added those items to StoryBoard as 
well.


- Google Analytics: It was discussed we should do something about 
getting the contributor portal[3] to appear higher in Google searches 
about onboarding. Not sure what all this entails. NEEDS AN OWNER IF 
ANYONE WANTS TO VOLUNTEER.


#Mission Statement#

We updated our mission statement[4]! It now states:

To provide a place for new contributors to come for information and 
advice. This group will also analyze and document successful 
contribution models while seeking out and providing information to new 
members of the community.


#Weekly Meeting#

We discussed beginning a weekly meeting- optimized for APAC/Europe and 
settled on 800 UTC in #openstack-meeting on Wednesdays. Proposed 
here[5]. For now I added a section to our wiki for agenda 
organization[6]. The two main items we want to cover on a weekly basis 
are new contributor patches in gerrit and if anything has come up on 
ask.openstack.org  about contributors so 
those will be standing agenda items.


#Forum Session#

We discussed proposing some forum sessions in order to get more 
involvement from operators. Currently, our activities focus on 
development activities and we would like to diversify. When this SIG 
was first proposed we wanted to have two chairs- one to represent 
developers and one to represent operators. We will propose a session 
or two when the call for forum proposals go out (should be today).


#IRC Channels#
We want to get rid of #openstack-101 and begin using #openstack-dev 
instead. The 101 channel isn't watched closely enough anymore and it 
makes more sense to move onboarding activities (like in OpenStack 
Upstream Institute) to a channel where there are people that can 
answer questions rather than asking those to move to a new channel. 
For those concerned about noise, OUI is run the weekend before the 
summit when most people are traveling to the Summit anyway.


#Ongoing Onboarding Efforts#

- GSOC: Unfortunately we didn't get accepted this year. We will try 
again next year.


- Outreachy: Applications for the next round of interns are due March 
22nd, 2018 [7]. Decisions will be made by April and then internships 
run May to August.


- WoO Mentoring: The format of mentoring is changing from 1x1 to 
cohorts focused on a single goal. If you are interested in helping 
out, please contact me! I NEED HELP :)


- Contributor guide: Please see the above section.

- OpenStack Upstream Institute: It will be run, as usual, the weekend 
before the Summit in Vancouver. Depending on how much progress is made 
on the contributor guide, we will make use of it as opposed to slides 
like previous renditions. There have also been a number of OpenStack 
Days requesting we run it there as well. More details of those to come.


#Project Liaisons#

The list is filling out nicely, but we still need more coverage. If 
you know someone from a project not listed that might be willing to 
help, please reach out to them and get them added to our list [8].


I thiink that is just about everything. Hopefully I at least 
covered everything important :)


Thanks Everyone!

- Kendall Nelson (diablo_rojo)

[1] PTG Etherpad https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG
[2] StoryBoard Tracker https://storyboard.openstack.org/#!/project/913 


[3] Contributor Portal https://www.openstack.org/community/
[4] Mission Statement Update https://review.openstack.org/#/c/548054/
[5] Meeting Slot Proposal https://review.openstack.org/#/c/549849/
[6] Meeting Agenda 

Re: [openstack-dev] Pros and Cons of face-to-face meetings

2018-03-08 Thread Jay S Bryant



On 3/8/2018 12:22 PM, Anita Kuno wrote:

On 2018-03-08 09:03 AM, Jens Harbott wrote:

With the current PTG just finished and seeing discussions happen about
the format of the next[0], it seems that the advantages of these seem
to be pretty clear to most, so let me use the occasion to remind
everyone of the disadvantages.

Every meeting that is happening is excluding those contributors that
can not attend it. And with that it is violating the fourth Open
principle[1], having a community that is open to everyone. If you are
wondering whom this would affect, here's a non-exclusive (sic) list of
valid reasons not to attend physical meetings:

- Health issues
- Privilege issues (like not getting visa or travel permits)
- Caretaking responsibilities (children, other family, animals, plants)
- Environmental concerns


I'll add dislike for travel, which affects some of our contributors.



So when you are considering whether it is worth the money and effort
to organise PTGs or similar events, I'd like you also to consider
those being excluded by such activities. It is not without a reason
that IRC and emails have been settled upon as preferred means of
communication. I'm not saying that physical meetings should be dropped
altogether, but maybe more effort can be placed into providing means
of remote participation, which might at least reduce some effects.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html

[1] https://governance.openstack.org/tc/reference/opens.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



Keep in mind that the alternative to the Project Teams Gathering is 
not no Project Teams Gathering, it is projects meeting face-to-face 
after each of them organizied their own meeting. These used to be 
called mid-cycle meetups and the majority of them used to be held in 
the United States. Now I can't predict what will happen in the future, 
but should there be a void in frequency of face-to-face meetings that 
the PTG is currently filling, I would not be surprised to see 
individual projects plan their own face-to-face meetings of some kind 
regardless of what they are called.


Thank you,
Anita

__ 


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

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

Anita,

We have already discussed this with the Cinder team and agreed that we 
would want to go back to our mid-cycles in the absence of a PTG.


Jay
(jungleboyj)

__
OpenStack Development Mailing 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] Pros and Cons of face-to-face meetings

2018-03-08 Thread Jay S Bryant


On 3/8/2018 12:06 PM, Jeremy Stanley wrote:

On 2018-03-08 17:49:35 + (+), Flint WALRUS wrote:

Pretty easy, put the PTG online with a livestream on
YouTube/Hangout/whatever platform that will then be saved and could even be
watched later on!

It’s just a matter of some hardware and a decent internet bandwidth that’s
already available to almost every places where a PTG took place.

Problem solved.

[...]

Have you ever actually tried it? I know this seems simple to "solve"
with technology, but put 50 people in a room having a heated
conversation (or sometimes several conversations at once) and then
try to bridge some people in via phone, video conference, whatever
and see how it works out in reality.

The times it's been tried, either the remote participants get
frustrated because nobody is paying attention to them/speaking into
microphones/keeping discussion to one thread at a time, or the
in-person participants get frustrated because they have to start
acting like they're all on separate telephones and drag down the
bandwidth of the conversation to the point where it may as well be
100% remote/separate participation anyway.

We've made it work to varying degrees in the past, but it's not so
simple as you would seem to imply no matter how good the technology.


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

Jeremy,

Cinder has been doing this for many years and it has worked relatively 
well.  It requires a good remote speaker and it also requires the people 
in the room to be sensitive to the needs of those who are remote.  I.E. 
planning topics at a time appropriate for the remote attendees, ensuring 
everyone speaks up, etc.  If everyone, however, works to be inclusive 
with remote participants it works well.


We have even managed to make this work between separate mid-cycles 
(Cinder and Nova) in the past before we did PTGs.


Jay
(jungleboyj)
__
OpenStack Development Mailing 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][summit] Forum topic proposal etherpad created ...

2018-03-08 Thread Jay S Bryant

All,

I just wanted to share the fact that I have created the etherpad for 
proposing topics for the Vancouver Forum.  [1]


Please take a few moments to add topics there.  I will need to propose 
the topics we have in the next two weeks so this will need attention 
before that point in time.


Thanks!

Jay

(jungleboyj)

[1] https://etherpad.openstack.org/p/YVR-cinder-brainstorming


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


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

2018-03-06 Thread Jay S Bryant

Team,

I have collected all of our actions and agreements out of the three days 
of etherpads into the following summary page:  [1] . The etherpad 
includes links to the original etherpads and video clips.


I am planning to use the wiki to help guide our development during Rocky.

Let me know if you have any questions or concerns over the content.

Thanks!

Jay

(jungleboyj)

[1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary


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


Re: [openstack-dev] [cinder][ptg] Dinner Outing Update and Photo Reminder ...

2018-03-02 Thread Jay S. Bryant

Ivan,

I sent another note but will also respond in this thread.

Yes, they will serve us tonight.  It is a somewhat limited menu but I 
stopped to look at it and it still looked good.


Sidewalks on the way to the restaurant were not in too bad of shape.

Jay


On 3/2/2018 10:48 AM, Ivan Kolodyazhny wrote:

Hi Jay,

Will Fagans serve us tonight?

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

On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant <jungleb...@gmail.com 
<mailto:jungleb...@gmail.com>> wrote:




On 3/1/2018 6:50 AM, Sean McGinnis wrote:

On Feb 28, 2018, at 16:58, Jay S Bryant
<jungleb...@gmail.com <mailto:jungleb...@gmail.com>> wrote:

Team,

Just a reminder that we will be having our team photo at 9
am tomorrow before the Cinder/Nova cross project session. 
Please be at the registration desk before 9 to be in the
photo.

We will then have the Cross Project session in the Nova
room as it sounds like it is somewhat larger.  I will have
sound clips in hand to make sure things don't get too serious.

Finally, an update on dinner for tomorrow night.  I have
moved dinner to a closer venue:

Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower,
Drumcondra, Dublin 9

I have reservations for 7:30 pm.  It isn't too difficult a
walk from Croke Park (even in a blizzard) and it is a
great pub.

Thanks for a great day today!

See you all tomorrow!  Let's make it a great one!  ;-)
Jay

Any plan now that there is a 4pm curfew?

Dinner has been rescheduled for Friday night 3/2 or 2/3 depending
on your country of origin.  6:30 at Fagans.

I will update the etherpad.

Jay


__
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
<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] Dinner Outing Update and Photo Reminder ...

2018-03-01 Thread Jay S Bryant



On 3/1/2018 6:50 AM, Sean McGinnis wrote:

On Feb 28, 2018, at 16:58, Jay S Bryant <jungleb...@gmail.com> wrote:

Team,

Just a reminder that we will be having our team photo at 9 am tomorrow before 
the Cinder/Nova cross project session.  Please be at the registration desk 
before 9 to be in the photo.

We will then have the Cross Project session in the Nova room as it sounds like 
it is somewhat larger.  I will have sound clips in hand to make sure things 
don't get too serious.

Finally, an update on dinner for tomorrow night.  I have moved dinner to a 
closer venue:

Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra, Dublin 9

I have reservations for 7:30 pm.  It isn't too difficult a walk from Croke Park 
(even in a blizzard) and it is a great pub.

Thanks for a great day today!

See you all tomorrow!  Let's make it a great one!  ;-)
Jay


Any plan now that there is a 4pm curfew?

Dinner has been rescheduled for Friday night 3/2 or 2/3 depending on 
your country of origin.  6:30 at Fagans.


I will update the etherpad.

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][ptg] Dinner Outing Update and Photo Reminder ...

2018-03-01 Thread Jay S Bryant

On 3/1/2018 6:50 AM, Sean McGinnis wrote:


On Feb 28, 2018, at 16:58, Jay S Bryant <jungleb...@gmail.com> wrote:

Team,

Just a reminder that we will be having our team photo at 9 am tomorrow before 
the Cinder/Nova cross project session.  Please be at the registration desk 
before 9 to be in the photo.

We will then have the Cross Project session in the Nova room as it sounds like 
it is somewhat larger.  I will have sound clips in hand to make sure things 
don't get too serious.

Finally, an update on dinner for tomorrow night.  I have moved dinner to a 
closer venue:

Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra, Dublin 9

I have reservations for 7:30 pm.  It isn't too difficult a walk from Croke Park 
(even in a blizzard) and it is a great pub.

Thanks for a great day today!

See you all tomorrow!  Let's make it a great one!  ;-)
Jay


Any plan now that there is a 4pm curfew?

Don't think this impacts the plan.  The curfew is just a recommendation 
and not a requirement.


I will ensure that the restaurant is still open but they were planning 
to be last night.


I will be there for anyone who wants to join.

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][ptg] Dinner Outing Update and Photo Reminder ...

2018-02-28 Thread Jay S Bryant

Team,

Just a reminder that we will be having our team photo at 9 am tomorrow 
before the Cinder/Nova cross project session.  Please be at the 
registration desk before 9 to be in the photo.


We will then have the Cross Project session in the Nova room as it 
sounds like it is somewhat larger.  I will have sound clips in hand to 
make sure things don't get too serious.


Finally, an update on dinner for tomorrow night.  I have moved dinner to 
a closer venue:


Fagan's Bar and Restaurant:  146 Drumcondra Rd Lower, Drumcondra, Dublin 9

I have reservations for 7:30 pm.  It isn't too difficult a walk from 
Croke Park (even in a blizzard) and it is a great pub.


Thanks for a great day today!

See you all tomorrow!  Let's make it a great one!  ;-)
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][ptg] Team Photo Rescheduled!!!

2018-02-27 Thread Jay S Bryant

Team,

Some people had conflicts with the 12:50 time for our Team Photo due to 
lunch and presentations so I have decided to reschedule the photo.


We are going to squeeze it in before the Nova/Cinder cross project 
meeting at 9:00 am on Thursday 3/1.  So, be punctual to get to the pitch 
on Thursday morning and bring a smile!


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][ptg] Cinder Dinner and Ghost Tour Night ...

2018-02-23 Thread Jay S. Bryant

Team,

There are a couple of events I am setting up that I would like you aware of:

First, is more details on the dinner Thursday night we already planned.  
Dinner will be at 7:45 at J. Sheehan's Irish Pub: 
http://sheehanspub.com/  I had dinner there tonight and it was 
wonderful.  Think it will work great for our group.  I have made 
reservations for those who have responded on the Etherpad. 
https://etherpad.openstack.org/p/cinder-ptg-rocky  If you want to add 
your name, please do so by EOD Tuesday as I need to confirm the number 
of people.


Second, I am putting together a Ghost tour night on Wednesday 2/28/18.  
The Gravedigger Ghost Tour comes highly recommended and is with a tour 
group that we have had very good experience with. I have not made 
official arrangements here, but anyone who wants to join me that night 
is more than welcome.  You can book tickets here: 
https://www.viator.com/tours/Dublin/Dublin-Gravedigger-Ghost-Tour/d503-5299GRAVE?_redirect=no=02=gdsarlsa=28353=true=52446860344=kl=s=216090288444=1t1=c=g=aud-298992519106:dsa-348108672214=1007850==EAIaIQobChMIxO6o5pq92QIVqLvtCh2vYgdcEAAYASAAEgLPWPD_BwE


Look forward to seeing you all next week!

Ping me on IRC if you have any questions.

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] [PTL][SIG][PTG]Team Photos

2018-02-15 Thread Jay S Bryant

All,

I have moved Cinder's time to the slot before lunch on Thursday. We can 
just break early for lunch so it will not be a huge disruption.


Jay


On 2/15/2018 3:56 PM, Kendall Nelson wrote:

Updates!

So, we have gotten permission to do photos down on the pitch at the 
stadium which is awesome!


The only issue is that we need to condense into a more dense blocks 
(Tuesday afternoon or Thursday morning) so looking at the schedule we 
have to move some teams. If the following teams could move their times 
so that we can make this happen:


  * QA
  * SIG K8s
  * Cyborg
  * Neutron
  * Octavia
  * Requirements
  * Release Mgmt
  * OpenStack Ansible
  * Cinder

I'm really sorry to make you guys move, but since we need to pay for 
an escort (with a 4 hour minimum) and don't want to conflict with 
lunch, we need to shift.


We will have your team meet at registration at your selected time. 
Because we get to go on the pitch and this requires an escort, you 
NEED TO BE AT REG ON TIME OR EARLY. If you aren't, you will miss your 
chance to be in the photo.


I will send out a reminder on Monday of PTG week.

-Kendall (diablo_rojo)

On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson > wrote:


This link might work better for everyone:

https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing


-Kendall (diablo_rojo)


On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson
> wrote:

Hello PTLs and SIG Chairs!

So here's the deal, we have 50 spots that are first come,
first served. We have slots available before and after lunch
both Tuesday and Thursday.

The google sheet here[1] should be set up so you have access
to edit, but if you can't for some reason just reply directly
to me and I can add your team to the list (I need team/sig
name and contact email).

I will be locking the google sheet on *Monday February 26th so
I need to know if your team is interested by then. *

See you soon!

- Kendall Nelson (diablo_rojo)

[1]

https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing






__
OpenStack Development Mailing 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 Weekly Meeting 2/21/18 or 2/28/18

2018-02-14 Thread Jay S Bryant

Team,

We will not be having a weekly meeting on 2/21/2018 or 2/28/2018 due to 
people traveling to the PTG and the PTG itself.


Regular meeting will return on 3/7/2018 .

See you all at the PTG!

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][ptl] Rocky PTL Candidacy ...

2018-02-05 Thread Jay S Bryant

All,

This note is to declare my candidacy for the Cinder, Rocky PTL position.

I can't believe that Queens is already drawing to a close and that I 
have been PTL for a whole release already.  I have enjoyed this new 
challenge and learned so much more about OpenStack as a result of being 
able to serve as a PTL.  It has grown not only my understanding of 
Cinder but of OpenStack and what it has to offer our end users.


I feel that the Queens release has gone smoothly and as I have been 
looking at the notes from the Queens PTG I think we have been successful 
at addressing many of the goals that the team set back in Denver.  We 
have been successful in getting the development team to take ownership 
of our documentation.  We have focused on fixing bugs in Cinder and 
improving our existing functions as I had hoped we would be able to do.  
We have even seen some return to growth in the development team.  All 
momentum that I would like to see us maintain.


So, I hope that you all will give me a chance to apply what I have 
learned during the last 6 months by supporting me in another term as 
Cinder's PTL.


Sincerely,

Jay Bryant (jungleboyj)



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


  1   2   3   >