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

[David Medberry]

and any talks I give in Denver (Forum, Ops, Main) will include "sl". It's
handy in a variety of ways.

On Thu, Oct 18, 2018 at 9:39 AM David Medberry 
wrote:

> I'm fine with Train but I'm also fine with just adding it to the list and
> voting on it. It will win.
>
> Also, for those not familiar with the debian/ubuntu command "sl", now is
> the time to become so.
>
> apt install sl
> sl -Flea #ftw
>
> On Thu, Oct 18, 2018 at 12: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
>>
>> 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-sigs mailing list
>> openstack-s...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>
__
OpenStack Development Mailing 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] [all] Naming the T release of OpenStack

[David Medberry]

I'm fine with Train but I'm also fine with just adding it to the list and
voting on it. It will win.

Also, for those not familiar with the debian/ubuntu command "sl", now is
the time to become so.

apt install sl
sl -Flea #ftw

On Thu, Oct 18, 2018 at 12: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
>
> 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-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
OpenStack Development Mailing 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

[David Medberry]

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.

On Wed, Aug 8, 2018 at 5:30 AM, Colleen Murphy  wrote:

> On Wed, Aug 8, 2018, at 12:18 PM, Adam Spiers wrote:
> > Matthew Thode  wrote:
> > >On 18-08-07 23:18:26, David Medberry wrote:
> > >> Requests have finally been made (today, August 7, 2018) to end the
> horns on
> > >> the train from Denver to Denver International airport (within the city
> > >> limits of Denver.) Prior approval had been given to remove the
> FLAGGERS
> > >> that were stationed at each crossing intersection.
> > >>
> > >> Of particular note (at the bottom of the article):
> > >>
> > >> There’s no estimate for how long it could take the FRA to approve
> quiet
> > >> zones.
> > >>
> > >> ref:
> > >> https://www.9news.com/article/news/local/next/denver-
> officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094
> > >>
> > >> I'd recommend bringing your sleeping aids, ear plugs, etc, just in
> case not
> > >> approved by next month's PTG. (The Renaissance is within Denver
> proper as
> > >> near as I can tell so that nearby intersection should be covered by
> this
> > >> ruling/decision if and when it comes down.)
> > >
> > >Thanks for the update, if you are up to it, keeping us informed on this
> > >would be nice, if only for the hilarity.
> >
> > Thanks indeed for the warning.
> >
> > If the approval doesn't go through, we may need to resume the design
> > work started last year; see lines 187 onwards of
> >
> > https://etherpad.openstack.org/p/queens-PTG-feedback
>
> Luckily the client work for this is already started:
> https://github.com/dtroyer/osc-choochoo
>
> __
> OpenStack Development Mailing 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] PTG Denver Horns

[David Medberry]

Requests have finally been made (today, August 7, 2018) to end the horns on
the train from Denver to Denver International airport (within the city
limits of Denver.) Prior approval had been given to remove the FLAGGERS
that were stationed at each crossing intersection.

Of particular note (at the bottom of the article):

There’s no estimate for how long it could take the FRA to approve quiet
zones.

ref:
https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094

I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
approved by next month's PTG. (The Renaissance is within Denver proper as
near as I can tell so that nearby intersection should be covered by this
ruling/decision if and when it comes down.)

See y'all soon.

-dave
 Praemonitus, praemunitus Forewarned is forearmed.
__
OpenStack Development Mailing 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] Fwd: Follow Up: Private Enterprise Cloud Issues

[David Medberry]

There was a great turnout at the Private Enterprise Cloud Issues session
here in Vancouver. I'll propose a follow-on discussion for Denver PTG as
well as trying to sift the data a bit and pre-populate. Look for that
sifted data soon.

For folks unable to participate locally, the etherpad is here:

https://etherpad.openstack.org/p/YVR-private-enterprise-cloud-issues

(and I've cached a copy offline in case it gets reset/etc.)

-- 
-dave
__
OpenStack Development Mailing 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] Ops Mid Cycle in Tokyo Mar 7-8 2018

[David Medberry]

Hi all,

Broad distribution to make sure folks are aware of the upcoming Ops Meetup
in Tokyo.

You can help "steer" this meetup by participating in the planning meetings
or more practically by editing this page (respectfully):
https://etherpad.openstack.org/p/TYO-ops-meetup-2018

Sign up for the meetup is here:https://goo.gl/HBJkPy

We'll see you there!

-dave
__
OpenStack Development Mailing 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-operators] Ops Meetups team minutes + main topics

[David Medberry]

Jon,

I think the Foundation staff were very very wary of extending the PTG or
doing dual sites simultaneously due to not saving a thing logistically.
Yes, it would conceivably save travel for folks that need to go to two
separate events (as would the other colo options on the table) but not
saving a thing logistically over two separate events as we have now. A six
or seven day sprint/thing/ptg would also mean encroaching on one or both
weekends (above and beyond travel dates) and that may really limit venue
choices as private parties (weddings, etc) tend to book those locales on
weekends.

On Tue, Nov 21, 2017 at 10:06 AM, Jonathan Proulx  wrote:

> :On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan 
> wrote:
>
> :> The big topic of debate, however, was whether subsequent meetups should
> be
> :> co-located with OpenStack PTG. This is a question for the wider
> OpenStack
> :> operators community.
>
> For people who attend both I thnik this would be a big win, if they
> were in the same location (city anyway) but held in series.  One
> (longer) trip but no scheduling conflict.
>
> Downside I see is that makes scheduling constraints pretty tight
> either for having two sponsorslocation available in a coordinated time
> and place or making a much bigger ask of a single location.
>
> Those are my thoughts, not sure if the amount to an opinion.
>
> -Jon
>
>
>
__
OpenStack Development Mailing 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-operators] Ops Meetups team minutes + main topics

[David Medberry]

I'm actually pushing this out to a broader list and modifying the title as
well. We need to try and get all operators viewing this (even if they are
also devels, deployers, sigs.)

Feel free to reply to me about spamming lists, but I think we need lots of
eyes on this.



On Tue, Nov 21, 2017 at 9:15 AM, Chris Morgan  wrote:

> We had a busy meeting today. Here are the minutes
>
> Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/
> 2017/ops_meetup_team.2017-11-21-14.00.html
> 10:01 AM Minutes (text): http://eavesdrop.openstack.
> org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-11-21-14.00.txt
> 10:01 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/
> 2017/ops_meetup_team.2017-11-21-14.00.log.html
>
> The next Operators focused meeting is to be in Tokyo next March. Planning
> is going well (more on this later).
>
> The big topic of debate, however, was whether subsequent meetups should be
> co-located with OpenStack PTG. This is a question for the wider OpenStack
> operators community.
>
> The three broad options as I see it are
>
> 1. continue completely separate events
> 2. 2 events under one roof (PTG and ops meet ups at same venue, same days,
> but distinct)
> 3. redefine ops meetups (and to some extent PTG) so that days 1 and 2 are
> community inter-working between devs and operators.
>
> I would like to request a full and open discussion on this because the
> meetups team alone can't decide something like this, obviously, and yet
> we'll need to know what the community as a whole would like to do if future
> events are to succeed. Some of the issues around this are captured here
> (thanks to Melvin Hillman for starting this doc) :
>
> https://docs.google.com/document/d/1BgICOa-Mct9pKwjUEuYp_BSD1V_GdRLL_IM-
> BU0iPUw
>
> Thanks!
>
> Chris
>
> --
> Chris Morgan 
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing 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] Queens PTG team photos

[David Medberry]

Are you sure Dan @get_offmylawn wasn't just photoshopped from one pic to
the other?

On Mon, Sep 18, 2017 at 10:27 AM, Matt Riedemann 
wrote:

> Here are the links to the Nova team photos from the PTG.
>
> https://photos.app.goo.gl/JoYZyouzm0J670mH3
>
> https://photos.app.goo.gl/YMo96j6KKc044XdG2
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] openstack/openstackclient vs openstack/python-openstackclient

[David Medberry]

What's the relationship between

openstack/openstackclient

and

openstack/python-openstackclient

(the first appears to depend upon the latter but I can't ken much more than
that.)
__
OpenStack Development Mailing 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] Thanks gibi!

[David Medberry]

and now recommended for Core too, quite the feat of accomplishments
(resting on the solid work!)

On Fri, Aug 11, 2017 at 1:40 AM, Balazs Gibizer  wrote:

> On Thu, Aug 10, 2017 at 8:43 PM, Jay Pipes  wrote:
>
>> On 08/10/2017 01:57 PM, Matt Riedemann wrote:
>> > Apparently we don't have community contributor awards at the PTG, only
>> > the summit, and seeing as that's several months away now, which is kind
>> > of an eternity, I wanted to take the time now to thank gibi (Balazs
>> > Gibizer to his parents) for all the work he's been doing in Nova.
>> >
>> > Not only does gibi lead the versioned notification transformation work,
>> > which includes running a weekly meeting (that only one other person
>> > shows up to) and sending a weekly status email, and does it in a
>> > ridiculously patient and kind way, but he's also been identifying
>> > several critical issues late in the release related to the Placement and
>> > claims in the scheduler work that's going on.
>> >
>> > And it's not just doing manual testing, reporting a bug and throwing it
>> > over the wall - which is a major feat in OpenStack on it's own - but
>> > also taking the time to write automated functional regression tests to
>> > exhibit the bugs so when we have a fix we can tell it's actually
>> > working, plus he's been fixing some on his own also.
>> >
>> > So with all that, I just wanted to formally and publicly say thanks to
>> > gibi for the great work he's doing which often goes overlooked when
>> > we're crunching toward a deadline.
>>
>> Couldn't agree more. Thank you Gibi for your hard work and valuable
>> contributions over the last cycle and more. Your efforts have not gone
>> unnoticed.
>>
>
> Thank you guys for the nice words, the support, and the encouragement. I
> enjoy working with the community. So I'm planning to continue sending those
> bug reports in the future too.
>
> Cheers,
> gibi
>
>
>
>
>> All the best,
>> -jay
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [Nova] [Cells] Stupid question: Cells v2 & AZs

[David Medberry]

Thanks all.

On Wed, May 24, 2017 at 8:08 AM, Dan Smith  wrote:

> > Thanks for answering the base question. So, if AZs are implemented with
> > haggs, then really, they are truly disjoint from cells (ie, not a subset
> > of a cell and not a superset of a cell, just unrelated.) Does that
> > philosophy agree with what you are stating?
>
> Correct, aggregates are at the top level, and they can span cells if you
> so desire (or not if you don't configure any that do). The aggregate
> stuff doesn't know anything about cells, it only knows about hosts, so
> it's really independent.
>
> --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] [Nova] [Cells] Stupid question: Cells v2 & AZs

[David Medberry]

Thanks Belmiro. So, when using Host Aggregates (haggs) as pure haggs, and
not as AZs, is their any conflict/interaction if we then enable AZs? This
is more of a philosophical question.

Thanks for answering the base question. So, if AZs are implemented with
haggs, then really, they are truly disjoint from cells (ie, not a subset of
a cell and not a superset of a cell, just unrelated.) Does that philosophy
agree with what you are stating?

Many thanks.

-dave

On Wed, May 24, 2017 at 12:38 AM, Belmiro Moreira <
moreira.belmiro.email.li...@gmail.com> wrote:

> Hi David,
> AVZs are basically aggregates.
> In cells_v2 aggregates are defined in the cell_api, so it will be possible
> to have
> multiple AVZs per cell and AVZs that spread between different cells.
>
> Belmiro
>
> On Wed, May 24, 2017 at 5:14 AM, David Medberry <openst...@medberry.net>
> wrote:
>
>> Hi Devs and Implementers,
>>
>> A question came up tonight in the Colorado OpenStack meetup regarding
>> cells v2 and availability zones.
>>
>> Can a cell contain multiple AZs? (I assume this is yes.)
>>
>> Can an AZ contain mutliple cells (I assumed this is no, but now in
>> thinking about it, that's probably not right.)
>>
>> What's the proper way to think about this? In general, I'm considering
>> AZs primarily as a fault zone type of mechanism (though they can be used in
>> other ways.)
>>
>> Is there a clear diagram/documentation about this?
>>
>> And consider this to be an Ocata/Pike and later only type of question.
>>
>> Thanks.
>>
>> -dave
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [tc][all] Etcd as a base service for ALL OpenStack installations

[David Medberry]

On Wed, May 24, 2017 at 6:14 AM, Davanum Srinivas  wrote:

> http://tarballs.openstack.org/etcd/


There are older versions of etcd (3.1.0) in both Debian and Ubuntu. Is that
new enough or do we need 3.1.7?

As an operator, I'd much prefer to see a packaged version of this available
if we're going to make it a strict requirement.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] [Cells] Stupid question: Cells v2 & AZs

[David Medberry]

Hi Devs and Implementers,

A question came up tonight in the Colorado OpenStack meetup regarding cells
v2 and availability zones.

Can a cell contain multiple AZs? (I assume this is yes.)

Can an AZ contain mutliple cells (I assumed this is no, but now in thinking
about it, that's probably not right.)

What's the proper way to think about this? In general, I'm considering AZs
primarily as a fault zone type of mechanism (though they can be used in
other ways.)

Is there a clear diagram/documentation about this?

And consider this to be an Ocata/Pike and later only type of question.

Thanks.

-dave
__
OpenStack Development Mailing 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] Boston Forum Schedule

[David Medberry]

Are the three rooms roughly the same size?

On Mon, Apr 10, 2017 at 3:35 AM, Tom Fifield  wrote:

> Hi everyone,
>
> Thank you for the many excellent topics submitted for our first Forum. We
> have updated the topic submission site with the status of each - please
> check yours.
>
> Please also find attached in PDF the proposed schedule for the Forum in
> Boston.
>
>
> Let us know if you see major issues with it. As Thierry said in design
> summits past; "It's difficult to make too many changes at this stage as
> they quickly cascade into breaking all sorts of constraints, but we may
> still be able to accommodate some." :)
>
> Eagle-eyed readers will see that there are a number of slots in gray (on
> Thursday afternoon). These are being deliberately kept aside for the usual
> few critical topics that come up in the next few weeks and also for the
> discoveries we make in the first 3 days of the summit.
>
> We'll soon publish the Forum sessions on the main schedule, using the
> title, abstracts and moderators you submitted, but look forward to your
> feedback in the mean-time!
>
> Thank you all very much for making our first Forum a success.
>
>
> Regards,
>
> Doug, Emilien, Melvin, Mike, Shamail & Tom
> Forum Scheduling Committee
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] Please give your opinion about "openstack server migrate" command.

[David Medberry]

Replying more to the "thread" and stream of thought than a specific message.

1) Yes, it is confusing. Rikimaru's description is more or less what I
believe.
2) Because it is confusing, I continue to use NovaClient commands instead
of OpenstackClient

I don't know what drove the creation of the OpenStack Client server
commands the way that they are it might be a good deep dive of launchpad
and git to find out. i.e., I can't "guess" what drove the design as it
seems wrong and overly opaque and complex.

On Fri, Feb 17, 2017 at 3:38 AM, Rikimaru Honjo <
honjo.rikim...@po.ntts.co.jp> wrote:

> Hi Marcus,
>
>
> On 2017/02/17 15:05, Marcus Furlong wrote:
>
>> On 17 February 2017 at 16:47, Rikimaru Honjo
>>  wrote:
>>
>>> Hi all,
>>>
>>> I found and reported a unkind behavior of "openstack server migrate"
>>> command
>>> when I maintained my environment.[1]
>>> But, I'm wondering which solution is better.
>>> Do you have opinions about following my solutions by operating point of
>>> view?
>>> I will commit a patch according to your opinions if those are gotten.
>>>
>>> [1]https://bugs.launchpad.net/python-openstackclient/+bug/1662755
>>> ---
>>> [Actual]
>>> If user run "openstack server migrate --block-migration ",
>>> openstack client call Cold migration API.
>>> "--block migration" option will be ignored if user don't specify
>>> "--live".
>>>
>>> But, IMO, this is unkindly.
>>> This cause unexpected operation for operator.
>>>
>>
>> +1 This has confused/annoyed me before.
>>
>>
>>> P.S.
>>> "--shared-migration" option has same issue.
>>>
>>
>> For the shared migration case, there is also this bug:
>>
>>https://bugs.launchpad.net/nova/+bug/1459782
>>
>> which, if fixed/implemented would negate the need for
>> --shared-migration? And would fix also "nova resize" on shared
>> storage.
>>
> In my understanding, that report says about libvirt driver's behavior.
> In the other hand, my report says about the logic of openstack client.
>
> Current "openstack server migrate" command has following logic:
>
> * openstack server migrate
>+-User don't specify "--live"
>| + Call cold-migrate API.
>|   Ignore "--block-migration" and "--shard-migration" option if user
> specify those.
>|
>+-User specify "--live"
>| + Call live-migration API.
>|
>+-User specify "--live --block-migration"
>| + Call block-live-migration API.
>|
>+-User specify "--live --shared-migration"
>  + Call live-migration API.[1]
>
> [1]
> "--shared-migration" means live-migration(not block-live-migrate) in
> "server migrate" command.
> In other words, "server migrate --live" and "server migrate --live
> --shared-migration"
> are same operation.
> I'm wondering why "--shared-migration" is existed...
>
>
> Cheers,
>> Marcus.
>>
>>
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> ＮＴＴソフトウェア株式会社
> クラウド&セキュリティ事業部 第一事業ユニット（CS1BU）
> 本上力丸
> TEL.  :045-212-7539
> E-mail:honjo.rikim...@po.ntts.co.jp
> 〒220-0012
>   横浜市西区みなとみらい4丁目4番5号
>   横浜アイマークプレイス 13階
>
>
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
OpenStack Development Mailing 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] allow_resize_to_same_host true needed for affinity

[David Medberry]

hmmm, it says "not for usage questions" so maybe I'll just propose a change
to nova/conf/compute.py as supporting affined hosts is a perfectly valid
PRODUCTION reason for setting this (above and beyond the single node
testing.)

On Sat, Jan 28, 2017 at 5:15 PM, David Medberry <openst...@medberry.net>
wrote:

> Hi,
>
> If you allow "affinity" server via the ServerGroupAffinityFilter it looks
> like you need to set allow_resize_to_same_host to true. Should I add a bit
> more description that this is needed to the description (reason) in the
> config file?
>
> (Users do need to sometimes resize things that are in an affinity group.
> This fails if you can't resize back to the same host.)
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] allow_resize_to_same_host true needed for affinity

[David Medberry]

Hi,

If you allow "affinity" server via the ServerGroupAffinityFilter it looks
like you need to set allow_resize_to_same_host to true. Should I add a bit
more description that this is needed to the description (reason) in the
config file?

(Users do need to sometimes resize things that are in an affinity group.
This fails if you can't resize back to the same host.)
__
OpenStack Development Mailing 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] Ops Lightning Talks

[David Medberry]

Dear Readers,

We have TWO back-to-back (double sessions) of Lightning Talks for
Operators. And by "for Operators" I mean largely that Operators will be the
audience.

If you have an OpenStack problem, thingamajig, technique, simplification,
gadget, whatzit that readily lends itself to a Lightning talk. please email
me and put it into the etherpad here:

https://etherpad.openstack.org/p/BCN-ops-lightning-talks

There are two sessions... but I'd prefer to fill the first one and cancel
the second one. But if your schedule dictates that you are only available
for the second, we'll hold both.

(And in spite of my natural levity, it can be a serious talk, a serious
problem, or something completely frivolous but there might be tomatoes in
the audience so watch it.)

-dave

David Medberry
OpenStack Guy and your friendly moderator.
__
OpenStack Development Mailing 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] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

[David Medberry]

+1 james bottomley

On Sun, Jan 17, 2016 at 11:55 PM, James Bottomley <
james.bottom...@hansenpartnership.com> wrote:

> On Fri, 2016-01-15 at 15:38 +, Daniel P. Berrange wrote:
> > On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote:
> > > This isn't the first time I'm calling for it. Let's hope this time,
> > > I'll
> > > be heard.
> > >
> > > Randomly, contributors put their company names into source code.
> > > When
> > > they do, then effectively, this tells that a given source file
> > > copyright
> > > holder is whatever is claimed, even though someone from another
> > > company
> > > may have patched it.
> > >
> > > As a result, we have a huge mess. It's impossible for me, as a
> > > package
> > > maintainer, to accurately set the copyright holder names in the
> > > debian/copyright file, which is a required by the Debian FTP
> > > masters.
> >
> > I don't think OpenStack is in a different situation to the vast
> > majority of open source projects I've worked with or seen. Except
> > for those projects requiring copyright assignment to a single
> > entity, it is normal for source files to contain an unreliable
> > random splattering of Copyright notices. This hasn't seemed to
> > create a blocking problem for their maintenance in Debian. Loooking
> > at the debian/copyright files I see most of them have just done a
> > grep for the 'Copyright' statements & included as is - IOW just
> > ignored the fact that this is essentially worthless info and included
> > it regardless.
> >
> > > I see 2 ways forward:
> > > 1/ Require everyone to give-up copyright holding, and give it to
> > > the
> > > OpenStack Foundation.
> > > 2/ Maintain a copyright-holder file in each project.
> >
> > 3/ Do nothing, just populate debian/copyright with the random
> >set of 'Copyright' lines that happen to be the source files,
> >as appears to be common practice across many debian packages
> >
> >eg the kernel package
> >
> > http://metadata.ftp-master.debian.org/changelogs/main/l/linux/lin
> > ux_3.16.7-ckt11-1+deb8u3_copyright
> >
> > "Copyright: 1991-2012 Linus Torvalds and many others"
> >
> >if its good enough for the Debian kernel package, it should be
> >good enough for openstack packages too IMHO.
>
> This is what I'd vote for.  It seems to be enough to satisfy the debian
> policy on copyrights and it means nothing has to change in Openstack.
>
> James
>
>
> __
> OpenStack Development Mailing 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] BoF OVN call for ideas/discussion points

[David Medberry]

Hi,

There is a Birds of a Feather session on OVN at Austin.
If you've got experience or questions or issues with OVN, you can register
them here:

https://etherpad.openstack.org/p/AUS-BoF-OVN

and participate in the session:
Wednesday, April 27, 1:50pm-2:30pm

https://www.openstack.org/summit/austin-2016/summit-schedule/events/6871?goback=1

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

Re: [openstack-dev] OpenStack Contributor Awards

[David Medberry]

On Tue, Mar 1, 2016 at 8:30 AM, Tom Fifield  wrote:

> Excellent, excellent.
>
> What's the best place to buy Raspberry Pis these days?
>

Raspberry Pi 3 is available to buy today from our partners element14
 and RS
Components ,
and other resellers.
ref:
https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

Pi 3 intro'd yesterday or day before.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] PTL Non-Candidacy

[David Medberry]

Thanks Mike. Enjoy a break (albeit thin and brief.) I've appreciated your
guiding the Cinder cats.

On Mon, Sep 14, 2015 at 10:15 AM, Mike Perez  wrote:

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

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

[David Medberry]

Glad to see you weighed in on this. -d

On Sat, Aug 1, 2015 at 3:50 PM, Matt Fischer m...@mattfischer.com wrote:

 Agree that you guys are way over thinking this. You don't need to rotate
 keys at exactly the same time, we do it in within a one or two hours
 typically based on how our regions are setup. We do it with puppet, puppet
 runs on one keystone node at a time and drops the keys into place. The
 actual rotation and generation we handle with a script that then proposes
 the new key structure as a review which is then approved and deployed via
 the normal process. For this process I always drop keys 0, 1, 2 into place,
 I'm not bumping the numbers like the normal rotations do.

 We had also considered ansible which would be perfect for this, but that
 makes our ability to setup throw away environments with a single click a
 bit more complicated. If you don't have that requirement, a simple ansible
 script is what you should do.


 On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Boris Bobrov's message of 2015-08-01 14:18:21 -0700:
  On Saturday 01 August 2015 16:27:17 bdobre...@mirantis.com wrote:
   I suggest to use pacemaker multistate clone resource to rotate and
  rsync
   fernet tokens from local directories across cluster nodes. The
 resource
   prototype is described here
   https://etherpad.openstack.org/p/fernet_tokens_pacemaker Pros:
  Pacemaker
   will care about CAP/split-brain stuff for us, we just design rotate
 and
   rsync logic. Also no shared FS/DB involved but only Corosync CIB - to
  store
   few internal resource state related params, not tokens. Cons: Keystone
   nodes hosting fernet tokens directories must be members of pacemaker
   cluster. Also custom OCF script should be created to implement this.
 __
   Regards,
   Bogdan Dobrelya.
   IRC: bogdando
 
  Looks complex.
 
  I suggest this kind of bash or python script, running on Fuel master
 node:
 
  0. Check that all controllers are online;
  1. Go to one of the controllers, rotate keys there;
  2. Fetch key 0 from there;
  3. For each other controller rotate keys there and put the 0-key
 instead of
  their new 0-key.
  4. If any of the nodes fail to get new keys (because they went offline
 or for
  some other reason) revert the rotate (move the key with the biggest
 index
  back to 0).
 
  The script can be launched by cron or by button in Fuel.
 
  I don't see anything critically bad if one rotation/sync event fails.
 

 This too is overly complex and will cause failures. If you replace key 0,
 you will stop validating tokens that were encrypted with the old key 0.

 You simply need to run rotate on one, and then rsync that key repository
 to all of the others. You _must not_ run rotate again until you rsync to
 all of the others, since the key 0 from one rotation becomes the primary
 token encrypting key going forward, so you need it to get pushed out to
 all nodes as 0 first.

 Don't over think it. Just read http://lbragstad.com/?p=133 and it will
 remain simple.

 __
 OpenStack Development Mailing 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] [Openstack] Rescinding the M name decision

[David Medberry]

Thanks Lauren. Mi taco es su taco.

On Tue, Jul 14, 2015 at 12:53 PM, Lauren Sell lau...@openstack.org wrote:

 Good news. After finalizing the trademark checks and giving the community
 time to weigh in, Mitaka will be the name of the M release.

 Thanks again for the great discussion around this topic, and for the
 willingness to be responsive to the concerns of fellow community members.


  On Jul 9, 2015, at 2:18 PM, Tim Bell tim.b...@cern.ch wrote:
 
  Feel free to give input on the Mitaka proposal.
 
  Tim
 
  -Original Message-
  From: Jonathan Bryce [mailto:jbr...@jbryce.com]
  Sent: 09 July 2015 20:52
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
 
  On Jul 9, 2015, at 9:35 AM, Russell Bryant rbry...@redhat.com wrote:
 
  On 07/09/2015 09:19 AM, Neil Jerram wrote:
  In the hope of forestalling an unnecessary sub-thread...
 
  Mita was #1 in the vote, so has presumably already been ruled out by
  OpenStack's legal review.
 
  That is correct.
 
 
  Hi everyone,
 
  I’ve really loved seeing everyone’s understanding and engagement on this
  thread as we worked through the release cycle naming for ‘M’. This was
 the
  first attempt to follow a new process, so not surprisingly, we found
 some
  improvements in the algorithm for the future. Still it’s awesome to see
 how
  constructive and positive the whole conversation has been.
 
  I wanted to provide a quick update on the status of the Foundation’s
  reviews of the names. First, as Russell mentioned above, after the
 voting
  was completed, we asked our trademark counsel to do checks on the top 3
  names. The first two both had significant trademark issues with existing
  trademark holders in the same space that would have prevented us from
  using the names in most jurisdictions where we have our largest
  communities (US, Europe and Asia). The 3rd choice was relatively low
 risk
  and so we passed word back to Monty who announced it. Once we realized
  there were other issues with Meiji, we asked for an expedited check of
 the
  next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
  that Mitaka and Meguro both present an acceptable level of risk, while
  Musashi is higher on the risk scale and would probably create problems
 for
  usage.
 
  At this time, we’re going to do a deeper check on Mitaka, which was the
 #4
  candidate in voting and would be next in line after Meiji. I know
 Itoh-san
  mentioned the Mitaka locale has the potential to be associated with
 certain
  corporations in Japan, but my personal feeling is that may not be
 significant
  enough to override it’s position in the voting and it’s availability
 for use.
 
  I’d encourage anyone with other concerns about Mitaka to post those
  within the next 24 hours so we can appropriately consider and discuss
  them. We should have results on the deeper trademark check by next week
  as well and can hopefully settle on a final name.
 
  Thanks again for all the discussion and participation and especially to
  Monty who’s been on the front lines of helping us navigate this. Feel
 free to
  let me know if you have any other questions,
 
  Jonathan
  210-317-2438
 
 
  __
  
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: OpenStack-dev-
  requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

[David Medberry]

On Fri, May 29, 2015 at 7:41 AM, Thierry Carrez thie...@openstack.org
wrote:

 If you were a consumer of those and will miss them, please explain why.
 In particular, please let us know how consuming that version (which was
 only made available every n months) is significantly better than picking
 your preferred time and get all the current stable branch HEADs at that
 time.


If vendor packages are used (as many folks do) they will need to weigh in
before operators can really give valid feedback.
I've already heard from one vendor that they will continue to do
point-like releases that they will support, but we probably need a more
complete answer.

Another issue, operators pulling from stable will just need to do a bit
more diligence themselves (and this is probably appropriate.) One thing we
will do in this diligence is something of tracking rate of new bugs and
looking for windows of opportunity where there may be semi-quiescence.

The other issue I'm aware of is that there will essentially be no syncing
across projects (except by the vendors). Operators using upstream will need
to do a better job (ie, more burden) in making sure all of the packages
work together.)
__
OpenStack Development Mailing 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 2015.1.0 for Debian Sid and Jessie

[David Medberry]

Neil, I haven't inspected these packages but historically they are
independent.

On Fri, May 15, 2015 at 2:37 AM, neil.jer...@metaswitch.com wrote:

 Out of interest, have you done this by re-releasing the Ubuntu packaging?
 Or have you taken an independent approach?

 Regards,
 Neil


   Original Message
 From: Thomas Goirand
 Sent: Thursday, 14 May 2015 22:21
 To: OpenStack Operators; Openstack; OpenStack Development Mailing List
 (not for usage questions)
 Reply To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] OpenStack 2015.1.0 for Debian Sid and Jessie

 Hi,

 I am pleased to announce the general availability of OpenStack 2015.1.0
 (aka Kilo) in Debian unstable (aka Sid) and through the official Debian
 backports repository for Debian 8.0 (aka Sid).

 Debian 8.0 Jessie just released
 ===
 As you may know, Debian 8.0 was released on the 25th of April, just a
 few days before OpenStack Kilo (on the 30th of April). Just right after
 Debian Jessie got released, OpenStack Kilo was uploaded to unstable, and
 slowly migrated the usual way to the new Debian Testing, named Stretch.

 As a lot of new packages had to go through the Debian FTP master NEW
 queue for review (they check mainly for the copyright / licensing
 information, but also if the package is conform to the Debian policy).
 I'd like here to publicly thank Paul Tagliamonte from the Debian FTP
 team for his prompt work, which allowed Kilo to reach the Debian
 repositories just a few days after its release (in fact, Kilo was fully
 available in Unstable more than a week ago).

 Debian Jessie Backports
 ===
 Previously, each release of OpenStack, as a backport for Debian Stable,
 was only available through private repositories. This wasn't a
 satisfying solution, and we wanted to address it by uploading to the
 official Debian backports. And the result is now available: all of
 OpenStack Kilo has been uploaded to Debian jessie-backports. If you want
 to use these repositories, just add them to your sources.list (note that
 the Debian installer proposes to add it by default):

 deb http://httpredir.debian.org/debian jessie-backports main

 (of course, you can use any Debian mirror, not just the httpredir)

 All of the usual OpenStack components are currently available in the
 official backports, but there's still some more to come, like for
 example Heat, Murano, Trove or Sahara. For Heat, it's because we're
 still waiting for python-oslo.versionedobjects 0.1.1-2 to migrate to
 Stretch (as a rule: we can't upload to backports unless a package is
 already in Testing). For the last 3, I'm not sure if they will be
 backported to Jessie. Please provide your feedback and tell the Debian
 packaging team if they are important for you in the official
 jessie-backports repository, or if Sid is enough. Also, at the time of
 writing of this message, Horizon and Designate are still in the
 backports FTP master NEW queue (but it should be approved very soon).

 Also, I have just uploaded a first version of Barbican (still in the NEW
 queue waiting for approval...), and there's a package for Manila that is
 currently on the work by a new contributor.

 Note on Neutron off-tree drivers
 
 The neutron-lbaas, neutron-fwaas and neutron-vpnaas packages have been
 uploaded and are part of Sid. If you need it through jessie-backports,
 please just let me know.

 All vendor-specific drivers have been separated from Neutron, and are
 now available as separate packages. I wrote packages for them all, but
 the issue is that most of them wouldn't even build due to failed unit
 tests. For most of them, it used to work in the Kilo beta 3 of Neutron
 (it's the case for all but 2 of them who were broken at the time), but
 they appeared broken with the Kilo final release, as they didn't update
 after the Kilo release.

 I have repaired some of them, but working on these packages has shown to
 be a very frustrating work, as they receive very few updates from
 upstream. I do not plan to work much on them unless one of the below
 condition:
 - My employer needs them
 - things are moving forward upstream, and that these unit tests are
 repaired in the stackforge repository.

 If you are a network hardware vendor and read this, please push for more
 maintenance, as it's in a really bad state ATM. You are welcome to get
 in touch with me, and I'll be happy to help you to help.

 Bug report
 ==
 If you see any issue in the packages, please do report them to the
 Debian bug tracker. Instructions are available here:
 https://www.debian.org/Bugs/Reporting

 Happy installation,

 Thomas Goirand (zigo)

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

Re: [openstack-dev] OpenStack 2015.1.0 for Debian Sid and Jessie

[David Medberry]

and a quick checks shows that there are number of differences just in the
nova source package, so I believe they remain independent.

On Fri, May 15, 2015 at 5:01 AM, David Medberry openst...@medberry.net
wrote:

 Neil, I haven't inspected these packages but historically they are
 independent.

 On Fri, May 15, 2015 at 2:37 AM, neil.jer...@metaswitch.com wrote:

 Out of interest, have you done this by re-releasing the Ubuntu packaging?
 Or have you taken an independent approach?

 Regards,
 Neil


   Original Message
 From: Thomas Goirand
 Sent: Thursday, 14 May 2015 22:21
 To: OpenStack Operators; Openstack; OpenStack Development Mailing List
 (not for usage questions)
 Reply To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] OpenStack 2015.1.0 for Debian Sid and Jessie

 Hi,

 I am pleased to announce the general availability of OpenStack 2015.1.0
 (aka Kilo) in Debian unstable (aka Sid) and through the official Debian
 backports repository for Debian 8.0 (aka Sid).

 Debian 8.0 Jessie just released
 ===
 As you may know, Debian 8.0 was released on the 25th of April, just a
 few days before OpenStack Kilo (on the 30th of April). Just right after
 Debian Jessie got released, OpenStack Kilo was uploaded to unstable, and
 slowly migrated the usual way to the new Debian Testing, named Stretch.

 As a lot of new packages had to go through the Debian FTP master NEW
 queue for review (they check mainly for the copyright / licensing
 information, but also if the package is conform to the Debian policy).
 I'd like here to publicly thank Paul Tagliamonte from the Debian FTP
 team for his prompt work, which allowed Kilo to reach the Debian
 repositories just a few days after its release (in fact, Kilo was fully
 available in Unstable more than a week ago).

 Debian Jessie Backports
 ===
 Previously, each release of OpenStack, as a backport for Debian Stable,
 was only available through private repositories. This wasn't a
 satisfying solution, and we wanted to address it by uploading to the
 official Debian backports. And the result is now available: all of
 OpenStack Kilo has been uploaded to Debian jessie-backports. If you want
 to use these repositories, just add them to your sources.list (note that
 the Debian installer proposes to add it by default):

 deb http://httpredir.debian.org/debian jessie-backports main

 (of course, you can use any Debian mirror, not just the httpredir)

 All of the usual OpenStack components are currently available in the
 official backports, but there's still some more to come, like for
 example Heat, Murano, Trove or Sahara. For Heat, it's because we're
 still waiting for python-oslo.versionedobjects 0.1.1-2 to migrate to
 Stretch (as a rule: we can't upload to backports unless a package is
 already in Testing). For the last 3, I'm not sure if they will be
 backported to Jessie. Please provide your feedback and tell the Debian
 packaging team if they are important for you in the official
 jessie-backports repository, or if Sid is enough. Also, at the time of
 writing of this message, Horizon and Designate are still in the
 backports FTP master NEW queue (but it should be approved very soon).

 Also, I have just uploaded a first version of Barbican (still in the NEW
 queue waiting for approval...), and there's a package for Manila that is
 currently on the work by a new contributor.

 Note on Neutron off-tree drivers
 
 The neutron-lbaas, neutron-fwaas and neutron-vpnaas packages have been
 uploaded and are part of Sid. If you need it through jessie-backports,
 please just let me know.

 All vendor-specific drivers have been separated from Neutron, and are
 now available as separate packages. I wrote packages for them all, but
 the issue is that most of them wouldn't even build due to failed unit
 tests. For most of them, it used to work in the Kilo beta 3 of Neutron
 (it's the case for all but 2 of them who were broken at the time), but
 they appeared broken with the Kilo final release, as they didn't update
 after the Kilo release.

 I have repaired some of them, but working on these packages has shown to
 be a very frustrating work, as they receive very few updates from
 upstream. I do not plan to work much on them unless one of the below
 condition:
 - My employer needs them
 - things are moving forward upstream, and that these unit tests are
 repaired in the stackforge repository.

 If you are a network hardware vendor and read this, please push for more
 maintenance, as it's in a really bad state ATM. You are welcome to get
 in touch with me, and I'll be happy to help you to help.

 Bug report
 ==
 If you see any issue in the packages, please do report them to the
 Debian bug tracker. Instructions are available here:
 https://www.debian.org/Bugs/Reporting

 Happy installation,

 Thomas Goirand (zigo

Re: [openstack-dev] [Cinder] Static Ceph mon connection info prevents VM restart

[David Medberry]

Josh,

Certainly in our case the the monitor hosts (in addition to IPs) would have
made a difference.

On Thu, May 7, 2015 at 3:21 PM, Josh Durgin jdur...@redhat.com wrote:

 Hey folks, thanks for filing a bug for this:

 https://bugs.launchpad.net/cinder/+bug/1452641

 Nova stores the volume connection info in its db, so updating that
 would be a workaround to allow restart/migration of vms to work.
 Otherwise running vms shouldn't be affected, since they'll notice any
 new or deleted monitors through their existing connection to the
 monitor cluster.

 Perhaps the most general way to fix this would be for cinder to return
 any monitor hosts listed in ceph.conf (as they are listed, so they may
 be hostnames or ips) in addition to the ips from the current monmap
 (the current behavior).

 That way an out of date ceph.conf is less likely to cause problems,
 and multiple clusters could still be used with the same nova node.

 Josh

 On 05/06/2015 12:46 PM, David Medberry wrote:

 Hi Arne,

 We've had this EXACT same issue.

 I don't know of a way to force an update as you are basically pulling
 the rug out from under a running instance. I don't know if it is
 possible/feasible to update the virsh xml in place and then migrate to
 get it to actually use that data. (I think we tried that to no avail.)
 dumpxml=massage cephmons=import xml

 If you find a way, let me know, and that's part of the reason I'm
 replying so that I stay on this thread. NOTE: We did this on icehouse.
 Haven't tried since upgrading to Juno but I don't note any change
 therein that would mitigate this. So I'm guessing Liberty/post-Liberty
 for a real fix.



 On Wed, May 6, 2015 at 12:57 PM, Arne Wiebalck arne.wieba...@cern.ch
 mailto:arne.wieba...@cern.ch wrote:

 Hi,

 As we swapped a fraction of our Ceph mon servers between the
 pre-production and production cluster
 -- something we considered to be transparent as the Ceph config
 points to the mon alias--, we ended
 up in a situation where VMs with volumes attached were not able to
 boot (with a probability that matched
 the fraction of the servers moved between the Ceph instances).

 We found that the reason for this is the connection_info in
 block_device_mapping which contains the
 IP adresses of the mon servers as extracted by the rbd driver in
 initialize_connection() at the moment
 when the connection is established. From what we see, however, this
 information is not updated as long
 as the connection exists, and will hence be re-applied without
 checking even when the XML is recreated.

 The idea to extract the mon servers by IP from the mon map was
 probably to get all mon servers (rather
 than only one from a load-balancer or an alias), but while our
 current scenario may be special, we will face
 a similar problem the day the Ceph mons need to be replaced. And
 that makes it a more general issue.

 For our current problem:
 Is there a user-transparent way to force an update of that
 connection information? (Apart from fiddling
 with the database entries, of course.)

 For the general issue:
 Would it be possible to simply use the information from the
 ceph.conf file directly (an alias in our case)
 throughout the whole stack to avoid hard-coding IPs that will be
 obsolete one day?

 Thanks!
   Arne

 --
 Arne Wiebalck
 CERN IT

 __
 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

__
OpenStack Development Mailing 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] [swift] Go! Swift!

[David Medberry]

On Thu, May 7, 2015 at 2:10 PM, Chuck Thier cth...@gmail.com wrote:

 What started as a simple experiment by Mike Barton, has turned into quite
 a significant improvement in performance and builds a base that can be
 built off of for future improvements.  This wasn't built because of it
 being shiny but out of direct need, and is currently being tested with
 great results on production workloads.


Excellent and congrats to the team. Also very happy that it has been posted
and not made secret sauce. Much appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?

[David Medberry]

If you need a local guy to go twist Jon Corbets arm, there are plenty of us
within arms/cars reach. I think this would be the best possible outcome.

Although LWN is primarily subscriber funded, realize that many of those
subscribers are corporate subscribers that provide access to all their
employees. Having corporate subscribers in addition to the OpenStack
Foundation is probably key.

I'm not privy to their detailed business model, but that's my experience
and present understanding.

On Wed, May 6, 2015 at 7:13 PM, Hugh Blemings h...@blemings.org wrote:

 On 6/05/2015 23:34, James Bottomley wrote:

 On Wed, 2015-05-06 at 11:54 +0200, Thierry Carrez wrote:

 Hugh Blemings wrote:

 +2

 I think asking LWN if they have the bandwidth and interest to do this
 would be ideal - they've credibility in the Free/Open Source space and a
 proven track record.  Nice people too.


 On the bandwidth side, as a regular reader I was under the impression
 that they struggled with their load already, but I guess if it comes
 with funding that could be an option.

 On the interest side, my past tries to invite them to the OpenStack
 Summit so that they could cover it (the way they cover other
 conferences) were rejected, so I have doubts in that area as well.

 Anyone having a personal connection that we could leverage to pursue
 that option further ?


 Sure, be glad to.

 I've added Jon to the cc list (if his openstack mail sorting scripts
 operate like mine, that will get his attention).

 I already had a preliminary discussion with him: lwn.net is interested
 but would need to hire an extra person to cover the added load.  That
 makes it quite a big business investment for them.


 Excellent - I think Jon and Co. could bring a great deal to the table here
 and if that means finding a way to provide funding that would be effort
 well spent.

 Cheers,
 Hugh





 __
 OpenStack Development Mailing 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] Static Ceph mon connection info prevents VM restart

[David Medberry]

Hi Arne,

We've had this EXACT same issue.

I don't know of a way to force an update as you are basically pulling the
rug out from under a running instance. I don't know if it is
possible/feasible to update the virsh xml in place and then migrate to get
it to actually use that data. (I think we tried that to no avail.)
dumpxml=massage cephmons=import xml

If you find a way, let me know, and that's part of the reason I'm replying
so that I stay on this thread. NOTE: We did this on icehouse. Haven't tried
since upgrading to Juno but I don't note any change therein that would
mitigate this. So I'm guessing Liberty/post-Liberty for a real fix.



On Wed, May 6, 2015 at 12:57 PM, Arne Wiebalck arne.wieba...@cern.ch
wrote:

 Hi,

 As we swapped a fraction of our Ceph mon servers between the
 pre-production and production cluster
 -- something we considered to be transparent as the Ceph config points to
 the mon alias--, we ended
 up in a situation where VMs with volumes attached were not able to boot
 (with a probability that matched
 the fraction of the servers moved between the Ceph instances).

 We found that the reason for this is the connection_info in
 block_device_mapping which contains the
 IP adresses of the mon servers as extracted by the rbd driver in
 initialize_connection() at the moment
 when the connection is established. From what we see, however, this
 information is not updated as long
 as the connection exists, and will hence be re-applied without checking
 even when the XML is recreated.

 The idea to extract the mon servers by IP from the mon map was probably to
 get all mon servers (rather
 than only one from a load-balancer or an alias), but while our current
 scenario may be special, we will face
 a similar problem the day the Ceph mons need to be replaced. And that
 makes it a more general issue.

 For our current problem:
 Is there a user-transparent way to force an update of that connection
 information? (Apart from fiddling
 with the database entries, of course.)

 For the general issue:
 Would it be possible to simply use the information from the ceph.conf file
 directly (an alias in our case)
 throughout the whole stack to avoid hard-coding IPs that will be obsolete
 one day?

 Thanks!
  Arne

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

__
OpenStack Development Mailing 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] Adding Joshua Harlow to oslo-core

[David Medberry]

Not a voting member, but +1 from me. He's core in my book.

On Tue, May 5, 2015 at 11:27 AM, Ben Nemec openst...@nemebean.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 +1 from me as well!

 On 05/05/2015 09:47 AM, Julien Danjou wrote:
  Hi fellows,
 
  I'd like to propose that we add Joshua Harlow to oslo-core. He is
  already maintaining some of the Oslo libraries (taskflow, tooz...)
  and he's helping on a lot of other ones for a while now. Let's
  bring him in for real!
 
 
 
  __
 
 
 
 OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVSP2fAAoJEDehGd0Fy7uqEggH/3VMflb10XVGXFQb/061yrmo
 B1boYZdeqVeBOlURSgsSouKJwY8OahMygu18GhedLXHaefYUlMgZRW/nSeGoS8/7
 fPWc1E4ebn/xupXPtSDo41CT8VswpeDZKod1DV74mTapMVQPzlslwnEmOwaik44h
 uuAwNEaMOPrelpHhv2qbINanOZco431BPmWqbPEEoRrOEkBJi0j7ikY36gHGL1Ny
 UTvtUW0rXDGOEswVi6/F9S6hZLYtvsyTFs+4ZspwQeHgQ+oTNdtFuw9w25oYhxLl
 lTJAKO29b7tcbZ3NHTJRBY1tldx3GVP9DkPAPWmXbZElwLvdfWMTKeLSrPbIdds=
 =aXKU
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Elections] Results of the TC Election

[David Medberry]

On Thu, Apr 30, 2015 at 7:15 AM, Tristan Cacqueray 
tristan.cacque...@enovance.com wrote:

 Here's to Libery,


and Liberty too!

Thanks for officiating Tristan.

-dave
__
OpenStack Development Mailing 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] Congrats (I think) to the new TC

[David Medberry]

Hey guys,

Congrats to the new TC leaders.

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688

Please reach out to me (and openstack-operat...@lists.openstack.org) if you
ever need operator input (that you aren't already getting.)

And many thanks for volunteering so much of your time this go round
__
OpenStack Development Mailing 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] Question for the TC candidates

[David Medberry]

On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote:


 What can and should the TC at large, and you specifically, do to ensure
 quality improves for the developers, end-users and operators of
 OpenStack as a full system, both as a project being developed and a
 product being used?


Hello Chris et al,

OpenStack quality will improve for the operators with a strong operator
voice that helps focus developers and the overall technical focus on usage.
OpenStack quality improves for developers in other ways: by hearing from
end users and operators they can in part anticipate (or respond more
quickly) to issues that will otherwise become truly raging hotspots (crises
if you will.)

The other way to directly improve quality for OpenStack Devs is to improve
test coverage and gate checks on more production-like systems. As an
operator and advocate, I can persuade or motivate other operators to offer
up resources (people as well as systems) to aid in this area of improvement.

These are indeed new times with operators playing a very critical role in
OpenStack.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] TC Candidacy

[David Medberry]

Announcing my candidacy for the TC.

I would bring an operator's perspective (ie, operator, user, super-user and
dev) to the Technical Committee.

I've been involved in OpenStack for four years. I gave talks at San Diego,
Atlanta, Paris, and soon Vancouver as a contributor, community organizer,
and operator.

I would consent to serve a single term.

-dave
__
OpenStack Development Mailing 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] Fwd: [stable] Request stable freeze exception: 162112 and 162113 libvirt live migration progress loop

[David Medberry]

Change requests https://review.openstack.org/162113 and
https://review.openstack.org/16211 https://review.openstack.org/1621132
are effecting a lot of operators (any who perform live migration) in Juno

Request stable/juno freeze exception to get these two added.

David Medberry
__
OpenStack Development Mailing 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] [summit] Youtube stream from Design Summit?

[David Medberry]

On Fri, Nov 1, 2013 at 3:25 PM, Stefano Maffulli stef...@openstack.orgwrote:

 This lead us to give up trying for Hong Kong. We searched for
 alternatives (see the infra meeting logs a few months back and my
 personal experiments [1] based on UDS experience) and the only solid
 one was to use a land line to call in the crucial people that *have to*
 be in a session. In the end I and Thierry made a judgement call to drop
 that too because we didn't hear anyone demanding it and setting them up
 in a reliable way for all sessions required a lot of efforts (that in
 the past we felt went wasted anyway).


Ah, bad planning on my part. I was kind of counting on the remote access
just getting better and better.

I'll just have to play catchup afterwards. As I'm unable to be there this
week.


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