Re: [openstack-dev] TC election by the numbers

[Matt Joyce]

On one hand, I agree a member of the TC should be a very active member
of the development community.  Something I have not been, much to my shame.

However, there are obviously some fundamental issues in how the TC has been
governing OpenStack in the past few releases.  Very serious issues in the
project have been largely ignored.  Foremost in my mind, among them, is
the lack of an upgradability path.  I remember there being large discussion
and agreement to address this at folsom, and further back.  I have seen no
meaningful effort made to address a functionality requirement that has been
requested repeatedly and emphatically since as far back as austin.

I can raise other issues that continue to plague usership, such as neutron
failing to take over for nova-network now two releases after it's planned
obsolescence.  My concern, is that the TC comprised entirely of active 
developers ( most of whom are full time on the open source side of this
project ), is trapped in something of an echo chamber.  I have no real
reason to suggest this is the case, beyond the obvious failure by the 
project to address concerns that have been paramount in the eyes of users
for years now.  But, the concern lingers.  

I fear that the TC is beholden entirely to the voice of the development
community and largely ignorant of the concerns of others.  Certainly,
the incentives promote that.  The problem of course, is that the TC is
responsible for driving purogratives in development that reflect more
than the development communities desires.

-Matt



On Fri, Oct 31, 2014 at 11:25:13AM -0400, Sean Dague wrote:
> On 10/31/2014 08:29 AM, Russell Bryant wrote:
> > On 10/30/2014 09:15 PM, Adam Lawson wrote:
> >> I was thinking after reading all this; besides modifying the number of
> >> required patches, perhaps we could try a blind election; candidate names
> >> are removed so ballots have to be cast based on the merit of each
> >> candidate's responses to the questions and/or ideas - which I think
> >> effectively eliminates the possibility of partisan voting based name
> >> recognition or based on the fact they are a well-known as PTL for a
> >> specific project i.e. nothing to do with TC but their prominence within
> >> the development hierarchy.
> >>
> >> Or something along those lines. If we aren't electing names, might as
> >> well cast ballots that eliminates them form the equation. ; ) Might be
> >> another 'when hell freezes over' suggestion but I thought I'd at least
> >> throw it out there for discussion.
> > 
> > I actually hope *nobody* votes purely on a candidacy email.  I would
> > hate to see someone get elected who was just able to write a really nice
> > email and does not otherwise participate regularly in the development
> > community.  I find someone's reputation based on the results they
> > produce from ongoing involvement in the project even more important.
> 
> +1
> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Matt Joyce]

On Wed, Aug 06, 2014 at 11:51:27AM -0400, Eoghan Glynn wrote:
> 
> 
> You've touched on multiple trains-of-thought that could indeed
> justify separate threads of their own.
> 
> I agree with your read on the diverging growth rates in the
> strategic versus the tactical elements of the community.
> 
> I would also be supportive of the notion of taking a cycle out to
> fully concentrate on solving existing quality/scaling/performance
> issues, if that's what you meant by pausing to define key cycle
> goals while deferring everything else.
> 
> Though FWIW I think scaling back the set of currently integrated
> projects is not the appropriate solution to the problem of over-
> stretched strategic resources on the QA/infra side of the house.
> 
> Rather, I think the proposed move to in-project functional
> testing, in place of throwing the kitchen sink into Tempest,
> is far more likely to pay dividends in terms of making the job
> facing the QA Trojans more tractable and sustainable.
> 
> Just my $0.02 ...
> 
> Cheers,
> Eoghan
> 

This is where complexity theory trumps automation.

And frankly the problem we're facing here is a monumental one that
has plagued developers for decades.  I think Denis Ritchie got closest
to getting it right.  Small tools that do one job well.  Really well.

Make those tools obey some common rules of behavior and interaction.

But don't let a tool do more than one thing well.  When you do, you
end up with infighting among developers and complexity that's
unsustainable.

I think glance is a great example of going one step too far with
artifacts.  This isn't in scope for what glance is.  It's really
enough of a deviation from glances core function to merit the spin
up of a new tool.  And we shouldn't be afraid of letting people
spin up tools.  Hell they will anyways.  If there's a road block
in front of a developer they'll route around it.

What we need to do is make sure that developers have a list of
requirements they can meet so as not to end up routing too far
around and ending up in some dangerous territory.  We have some
of that already, but it could be cleaned up and codified better.

That's not to say cenralized clearing houses don't work.  Oslo 
works because it's just a clearing house of small bits of 
functionality that people can commonly focus on.  Kind of like GNU 
tools.  That's n-scaling nested in an umbrella project.

Tempest is a vertical.  Glance artifacts are the first step
in turning glance into a vertical.  These are things we need
to try to avoid.

That's my USD$.02

-Matt

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

[openstack-dev] [Horizon] Hacking Standards for Javascript

[Matt Joyce]

Do we have any standards for Javascript?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

[Matt Joyce]

review response time matches up to accepted practices in infosec for
quantifying risk exposure in terms of incident response times.

so this is actually a suggest best practice in other areas.

-matt


On Fri, Jun 28, 2013 at 10:30 AM, Russell Bryant  wrote:

> On 06/28/2013 12:18 PM, Matt Riedemann wrote:
> > Hey I made the list!
> >
> > _https://review.openstack.org/#/c/25355/_
> >
> > Just wanted to point out for nova in longest-waiting reviews based on
> > first revision:
> >
> >
> > 1.94 days, 12 hours, 49 minutes
> > - _https://review.openstack.org/25355_ (PowerVM resize and migrate test
> > cases)
> >
> > This one is a bit skewed because it was abandoned due to inactivity and
> > then I picked it back up by assigning the bug to myself and contributing
> > to the original review.
> >
> > Is there a way to take that into account in the metrics?  Or is this a
> > process issue, i.e. should I have left this abandoned and pushed up a
> > new review based on the original?
>
> I think what you did is definitely the right thing to do.  The stat is
> still accurate for how long it is taking to get the patch to completion.
>  Having some really high numbers here doesn't worry me, because it's
> reality, and is often out of the control of reviewers.
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Best way to do something MySQL-specific?

[Matt Joyce]

far be it from me to ask.  but isn't this something that should be
addressed in oslo common db, and made configurable as an class definition
or method argument?

-matt


On Tue, Jul 9, 2013 at 9:27 AM, Monty Taylor  wrote:

>
>
> On 07/09/2013 11:21 AM, Clint Byrum wrote:
>
> >>> You may want to update your snark! MySQL has its warts which are pretty
> >>> easy to take shots at, but it has been a "real" ACID compliant database
> >>> for well over a decade.
> >> My snark is more recently generated than that.  There are plenty of
> >> places where MySQL has fallen down.
> >>
> >> InnoDB support was not mandatory, and without it, MySQL was not really
> >> ACID compliant.  Using InnoDB was troublesome enough that the RHEL 6
> >> version of MySQL defaults to MyISAM.
> >>
> >
> > Its not so much that it was troublesome to use InnoDB as it was that
> > people were used to MyISAM's few mis-features (fulltext and delayed
> > inserts mostly) and needed a long warning (run up to 5.5) that the
> > default was changing. Before 5.5 was released, Drizzle _completely
> > removed_ MyISAM because it causes way more problems than it solves.
>
> Let's try to avoid snarky database flame wars. There are enough of us in
> this community with massive experience in each database that they are
> useless to have.
>
> MySQL and PostGres are both lovely databases that are both completely
> valid choices for production. If anyone out there wants to have a beer
> and attempt to convince me otherwise, you are welcome to. You will not
> succeed. All snark aside, the current body of evidence for the current
> state of both databases will vastly outweigh any snark. The_historical_
> body of evidence for both databases has ridiculous warts, but is pointless.
>
> That said, we, as a project, seem to have made the decision that we find
> it important to support any biases you may have as a deployer by
> supporting multiple database backends via SQLalchemy. However, OpenStack
> is intended to be something that can be used for real large-scale
> production workloads. Most large scale database apps are NOT written in
> a database agnostic manner, because every database out there has
> performance quirks that have to be considered, and has a different set
> of tools for making things work.
>
> How do we deal with that dichotomy? I think it might behoove us to
> figure out a _sensible_ way to allow for engine-specific overrides of
> sqlalchemy behavior where appropriate. The sqlaclchemy code should be
> totally functional and correct, but there are clearly times when a
> single well-crafted query, or taking advantage of a database-specific
> extension could make a massive difference for a large deploy.
>
> I don't think we should start peppering our code with a bunch of ifs. If
> we want this, we need an understandable, sensible and repeatable
> mechanism for engine-specific optimizations. Something tells me this
> will not be the last time the question comes up.
>
> Monty
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

[Matt Joyce]

Wondering if heat should be performing this orchestration.

Would provide for a more pluggable front end to the action set.

-matt

On Feb 25, 2015 2:37 PM, Joe Gordon  wrote:
>
>
>
> On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell  wrote:
>>
>>
>> A few inline comments and a general point
>>
>> How do we handle scenarios like volumes when we have a per-component janitor 
>> rather than a single co-ordinator ?
>>
>> To be clean,
>>
>> 1. nova should shutdown the instance
>> 2. nova should then ask the volume to be detached
>> 3. cinder could then perform the 'project deletion' action as configured by 
>> the operator (such as shelve or backup)
>> 4. nova could then perform the 'project deletion' action as configured by 
>> the operator (such as VM delete or shelve)
>>
>> If we have both cinder and nova responding to a single message, cinder would 
>> do 3. Immediately and nova would be doing the shutdown which is likely to 
>> lead to a volume which could not be shelved cleanly.
>>
>> The problem I see with messages is that co-ordination of the actions may 
>> require ordering between the components.  The disable/enable cases would 
>> show this in a worse scenario.
>
>
> You raise two good points. 
>
> * How to clean something up may be different for different clouds
> * Some cleanup operations have to happen in a specific order
>
> Not sure what the best way to address those two points is.  Perhaps the best 
> way forward is a openstack-specs spec to hash out these details.
>
>  
>>
>> Tim
>>
>> > -Original Message-
>> > From: Ian Cordasco [mailto:ian.corda...@rackspace.com]
>> > Sent: 19 February 2015 17:49
>> > To: OpenStack Development Mailing List (not for usage questions); Joe 
>> > Gordon
>> > Cc: openstack-operat...@lists.openstack.org
>> > Subject: Re: [Openstack-operators] [openstack-dev] Resources owned by a
>> > project/tenant are not cleaned up after that project is deleted from 
>> > keystone
>> >
>> >
>> >
>> > On 2/2/15, 15:41, "Morgan Fainberg"  wrote:
>> >
>> > >
>> > >On February 2, 2015 at 1:31:14 PM, Joe Gordon (joe.gord...@gmail.com)
>> > >wrote:
>> > >
>> > >
>> > >
>> > >On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg
>> > > wrote:
>> > >
>> > >I think the simple answer is "yes". We (keystone) should emit
>> > >notifications. And yes other projects should listen.
>> > >
>> > >The only thing really in discussion should be:
>> > >
>> > >1: soft delete or hard delete? Does the service mark it as orphaned, or
>> > >just delete (leave this to nova, cinder, etc to discuss)
>> > >
>> > >2: how to cleanup when an event is missed (e.g rabbit bus goes out to
>> > >lunch).
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >I disagree slightly, I don't think projects should directly listen to
>> > >the Keystone notifications I would rather have the API be something
>> > >from a keystone owned library, say keystonemiddleware. So something like
>> > this:
>> > >
>> > >
>> > >from keystonemiddleware import janitor
>> > >
>> > >
>> > >keystone_janitor = janitor.Janitor()
>> > >keystone_janitor.register_callback(nova.tenant_cleanup)
>> > >
>> > >
>> > >keystone_janitor.spawn_greenthread()
>> > >
>> > >
>> > >That way each project doesn't have to include a lot of boilerplate
>> > >code, and keystone can easily modify/improve/upgrade the notification
>> > mechanism.
>> > >
>> > >
>>
>>
>> I assume janitor functions can be used for
>>
>> - enable/disable project
>> - enable/disable user
>>
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >Sure. I’d place this into an implementation detail of where that
>> > >actually lives. I’d be fine with that being a part of Keystone
>> > >Middleware Package (probably something separate from auth_token).
>> > >
>> > >
>> > >—Morgan
>> > >
>> >
>> > I think my only concern is what should other projects do and how much do we
>> > want to allow operators to configure this? I can imagine it being 
>> > preferable to
>> > have safe (without losing much data) policies for this as a default and to 
>> > allow
>> > operators to configure more destructive policies as part of deploying 
>> > certain
>> > services.
>> >
>>
>> Depending on the cloud, an operator could want different semantics for 
>> delete project's impact, between delete or 'shelve' style or maybe disable.
>>
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >--Morgan
>> > >
>> > >Sent via mobile
>> > >
>> > >> On Feb 2, 2015, at 10:16, Matthew Treinish  wrote:
>> > >>
>> > >>> On Mon, Feb 02, 2015 at 11:46:53AM -0600, Matt Riedemann wrote:
>> > >>> This came up in the operators mailing list back in June [1] but
>> > >>>given the  subject probably didn't get much attention.
>> > >>>
>> > >>> Basically there is a really old bug [2] from Grizzly that is still a
>> > >>>problem  and affects multiple projects.  A tenant can be deleted in
>> > >>>Keystone even  though other resources in other projects are under
>> > >>>that project, and those  resources aren't cleaned up.
>> > >>
>> > >> I agree thi

Re: [openstack-dev] [Openstack-operators] OpenStack "S" Release Naming Preliminary Results

[Matt Joyce]

+1

On Thu, Mar 22, 2018 at 10:03 AM, Jonathan Proulx  wrote:

> On Wed, Mar 21, 2018 at 08:32:38PM -0400, Paul Belanger wrote:
>
> :6. Spandau  loses to Solar by 195–88, loses to Springer by 125–118
>
> Given this is at #6 and formal vetting is yet to come it's probably
> not much of an issue, but "Spandau's" first association for many will
> be Nazi war criminals via Spandau Prison
> https://en.wikipedia.org/wiki/Spandau_Prison
>
> So best avoided to say the least.
>
> -Jon
>
> ___
> 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] [Openstack-operators] Speaker Selection Process: OpenStack Summit Berlin

[Matt Joyce]

CFP work is hard as hell.  Much respect to the review panel members.  It's
a thankless difficult job.

So, in lieu of being thankless,  THANK YOU

-Matt

On Mon, Aug 13, 2018 at 9:59 AM, Allison Price 
wrote:

> Hi everyone,
>
> One quick clarification. The speakers will be announced on* August 14 at
> 1300 UTC / 4:00 AM PDT.*
>
> Cheers,
> Allison
>
>
> On Aug 13, 2018, at 8:53 AM, Jimmy McArthur  wrote:
>
> Greetings!
>
> The speakers for the OpenStack Summit Berlin will be announced August 14,
> at 4:00 AM UTC. Ahead of that, we want to take this opportunity to thank
> our Programming Committee!  They have once again taken time out of their
> busy schedules to help create another round of outstanding content for the
> OpenStack Summit.
>
> The OpenStack Foundation relies on the community-nominated Programming
> Committee, along with your Community Votes to select the content of the
> summit.  If you're curious about this process, you can read more about it
> here
> 
> where we have also listed the Programming Committee members.
>
> If you'd like to nominate yourself or someone you know for the OpenStack
> Summit Denver Programming Committee, you can do so here:
> https://openstackfoundation.formstack.com/forms/openstackdenver2019_
> programmingcommitteenom
>
> Thanks a bunch and we look forward to seeing everyone in Berlin!
>
> 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-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