[openstack-dev] Arrivederci

[Ian Cordasco]

Hi everyone,

Friday 24 March 2017 will be my last day working on OpenStack. I'll remove
myself from teams (glance, craton, security, hacking) on Friday and unsubscribe
from the OpenStack mailing lists.

I want to thank all of you for the last ~3 years. I've learned quite a bit
from all of you. It's been a unique privilege to call the people in this
community my colleagues. Treat each other well. Don't let minor technical
arguments cause rifts in the community. Lift each other up.

As for me, I'm moving onto something completely different. You all are welcome
to keep in touch via email, IRC, or some other method. At the very
least, I'll see y'all
around PyCon, the larger F/OSS world, etc.

-- 
Ian Cordasco
IRC/Git{Hub,Lab}/Twitter: sigmavirus24

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

Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3

[Ian Cordasco]

On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair <cor...@inaugust.com> wrote:
> David Moreau Simard <d...@redhat.com> writes:
>
>> I don't have a horse in this race or a strong opinion on the topic, in
>> fact I'm admittedly not very knowledgeable when it comes to low-level
>> encryption things.
>>
>> However, I did have a question, even if just to generate discussion.
>> Did we ever consider simply leaving secrets out of Zuul and offloading
>> that "burden" to something else ?
>>
>> For example, end-users could use something like git-crypt [1] to crypt
>> files in their git repos and Zuul could have a mean to decrypt them at
>> runtime.
>> There is also ansible-vault [2] that could perhaps be leveraged.
>>
>> Just trying to make sure we're not re-inventing any wheels,
>> implementing crypto is usually not straightfoward.
>
> We did talk about some other options, though unfortunately it doesn't
> look like a lot of that made it into the spec reviews.  Among them, it's
> probably worth noting that there's nothing preventing a Zuul deployment
> from relying on some third-party secret system -- if you can use it with
> Ansible, you should be able to use it with Zuul.  But we also want Zuul
> to have these features out of the box, and, wearing our sysadmin hits,
> we're really keen on having source control and code review for the
> system secrets for the OpenStack project.
>
> Vault alone doesn't meet our requirements here because it relies on
> symmetric encryption, which means we need users to share a key with
> Zuul, implying an extra service with out-of-band authn/authz.  However,
> we *could* use our PKCS#1 style system to share a vault key with Zuul.
> I don't think that has come up as a suggestion yet, but seems like it
> would work.

I suppose Barbican doesn't meet those requirements either, then, yes?

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [craton] Nomination of Thomas Maddox as Craton core

[Ian Cordasco]

+1. Welcome to the team, Thomas

On Mar 21, 2017 3:43 PM, "Jim Baker"  wrote:

> *I nominate Thomas Maddox as a core reviewer for the Craton project.*
>
> Thomas has shown extensive knowledge of Craton, working across a range of
> issues in the core service, including down to the database modeling; the
> client; and corresponding bugs, blueprints, and specs. Perhaps most notably
> he has contributed a number of end-to-end patches, such as his work with
> project support.
> https://review.openstack.org/#/q/owner:thomas.maddox
>
> He has also expertly helped across a range of reviews, while always being
> amazingly positive with other team members and potential contributors:
> https://review.openstack.org/#/q/reviewer:thomas.maddox
>
> Other details can be found here on his contributions:
> http://stackalytics.com/report/users/thomas-maddox
>
> In my opinion, Thomas has proven that he will make a fantastic addition to
> the core review team. In particular, I'm confident Thomas will help further
> improve the velocity for our project as a whole as a core reviewer. I hope
> others concur with me in this assessment!
>
> - Jim
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry] Moving Gnocchi out

[Ian Cordasco]

On Mon, Mar 20, 2017 at 12:10 PM, gordon chung <g...@live.ca> wrote:
>
>
> On 20/03/17 11:37 AM, Thomas Goirand wrote:
>
>>
>> I really don't understand why the Telemetry team insists in being
>> release-independent, out of big tent and such, when the reality is that
>> all of released Telemetry components are *very tightly* bound to a
>> specific versions of OpenStack. IMO, it doesn't make sense upstream, or
>> downstream of Telemetry.
>
> i believe the tightly coupled perception between gnocchi+ceilometer is a
> misconception. ceilometer can be configured to output to various targets
> that are not gnocchi. based on dev questions in irc, this is a common
> workflow that people are actively leveraging. aodh and panko are
> definitely more bound to ceilometer as they don't have any other sources
> (currently).
>
>>
>> Now, having Gnocchi out of the OpenStack infra is to me a step in the
>> wrong direction. We should aim at full integration with the rest of
>> OpenStack, not getting out.
>>
>
> i should re-iterate, this won't change our testing or integration.
> ceilometer has a gate that ensures compatibility with gnocchi as a
> target. this will remain and the auto-scaling
> aodh+ceilometer+gnocchi+heat use case will continue to be validated. not
> sure how we can quantify/qualify 'full integration' but we remain
> committed to ensuring gnocchi+ceilometer works.
>
> the use case for gnocchi is generic. if you have to store a bunch of
> timestamp+value data, use gnocchi. the use case definitely fits
> openstack's requirement, but i believe you can see it isn't just limited
> to that.
>
> i'm glad we have your opinion here, i had previously asked jd about
> effects on packaging and while i think Red Hat has a plan already, it'd
> be interesting to get your feedback on how this will affects other distros.

Keep in mind, that OpenStack inside of Debian is just Thomas for a
variety of reasons. Others have tried to help and are trying to help
and aren't really able to stick around.

The effects on downstreams shouldn't be significant. People packaging
Ceilometer likely already package Gnocchi. How those packagers choose
to consume deliverables is what will change. In a similar vein,
OpenStack Infra has a signing key for each release cycle that Gnocchi
is likely currently signed with when tarballs are released. You may
receive complaints that new releases aren't verifiable in the same
way, but that and needing a decent MANIFEST.in (assuming you're also
dropping your usage of PBR) will probably be the largest problems
(beyond where downstreams get the actual deliverable).

In the end, I think this should inform your decision but not make it.
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [telemetry] Moving Gnocchi out

[Ian Cordasco]

-Original Message-
From: Chris Friesen <chris.frie...@windriver.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: March 20, 2017 at 11:39:38
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [telemetry] Moving Gnocchi out

> On 03/20/2017 10:10 AM, Chris Dent wrote:
> > On Mon, 20 Mar 2017, Thomas Goirand wrote:
> >
> >> I really don't understand why the Telemetry team insists in being
> >> release-independent, out of big tent and such, when the reality is that
> >> all of released Telemetry components are *very tightly* bound to a
> >> specific versions of OpenStack. IMO, it doesn't make sense upstream, or
> >> downstream of Telemetry.
> >
> > This simply isn't the case with gnocchi. Gnocchi is an independent
> > timeseries, metrics and resources data service that _happens_ to
> > work with OpenStack.
> >
> > By making it independent of OpenStack, its ability to draw
> > contribution and engagement from people outside the OpenStack
> > community increases. As a result it can become a better tool for
> > more people, including OpenStack people. Not all, or even many, of
> > the OpenStack projects are like that, but gnocchi is. More eyes,
> > less bugs, right?
>
> I'm curious why being independent of OpenStack would make it more attractive.
>
> Is the perception that requiring people to sign the Contributor Agreement is
> holding back external contribution? Or is it just that the mere idea of it
> being an OpenStack project is discouraging people from getting involved?
>
> Just as an example, if I want to get involved with libvirt because I have an
> itch to scratch the fact that it's basically a RedHat project isn't going to
> turn me off...

Contributing to OpenStack is intimidating, if not utterly
discouraging, to people unfamiliar with CLAs and Gerrit. There's a lot
of process that goes into contributing. Moving this to a friendlier
(if not inferior) developer platform makes sense if there is interest
from companies not interested in participating in the OpenStack
community.

--
Ian Cordasco

__
OpenStack Development Mailing 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][appcat][murano][app-catalog] The future of the App Catalog

[Ian Cordasco]

g to figure out how to make
> applications an easy to run thing on OpenStack. I've also been trying
> to find a community of people who are looking for that, and it doesn't
> seem like they've materialized; possibly because that community
> doesn't exist? Or else we just haven't been able to figure out where
> they're hiding ;)
>
> The one consideration that is pretty important here is what this would
> mean to the Murano community. Those folks have been contributed time
> and resources to the app catalog project. They've also standardized
> on the app catalog as the distribution mechanism, intending to make
> the app catalog UI a native component for Murano. We do need to make
> sure that if the app catalog is retired, it doesn't hamper or impact
> people who have already deployed Murano and are counting on finding
> the apps in the app catalog.

All of this is true. But Murano still doesn't have a stable way to
store artifacts. In fact, it seems like Murano relies on a lot of
unstable OpenStack infrastructure. While lots of people have
contributed time, energy, sweat, and tears to the project there are
still plenty of things that make Murano less than desirable. Perhaps
that's why the project has found so few adopters. I'm sure there are
plenty of people who want to use an OpenStack cloud to deploy
applications. In fact, I know there are companies that try to provide
that kind of support via Heat templates. All that said, I don't think
allowing for competition with Murano is a bad thing.

--
Ian Cordasco

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

Re: [openstack-dev] [docs][release][ptl] Adding docs to the release schedule

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita <rosmaita.foss...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: March 2, 2017 at 16:55:10
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [docs][release][ptl] Adding docs to the
release schedule

> On 3/2/17 9:45 AM, Ian Cordasco wrote:
> > -Original Message-
> > From: Telles Nobrega
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: March 2, 2017 at 08:01:29
> > To: OpenStack Development Mailing List (not for usage questions)
> >
> > Cc: openstack-d...@lists.openstack.org
> > Subject: Re: [openstack-dev] [docs][release][ptl] Adding docs to the
> > release schedule
> >
> >> I really believe that this idea will makes us work harder on keeping our
> >> docs in place and will make it for a better documented producted by release
> >> date.
> >> As shared before, I do believe that this is isn't easy and will demand a
> >> lot of effort from some teams, specially smaller teams with too much to do,
> >> but we from Sahara are on board with this approach and will try our best to
> >> do so.
> >
> > Most things worth doing are difficult. =) This seems to be one of
> > them. If deliverable teams really work together, they may end up in a
> > situation like Glance did this cycle where we kind of just sat on our
> > hands after RC-1 was tagged. That time *could* have been better spent
> > reviewing all of our documentation.
>
> At the risk of sounding defensive here, what exactly are you referring
> to? The api-ref [0], the dev docs in the glance repo [1], and the api
> docs in the glance-specs repo [2] all had patches up for review after RC-1.
>
> [0] https://review.openstack.org/#/c/426603/
> [1] https://review.openstack.org/#/c/429341/
> [2] https://review.openstack.org/#/c/426605/

I'm not trying to say we did something wrong. Just that there were
quite a few people who were focusing on things other than the Ocata
documentation. Hence the emphasis on "could". I think Glance came out
of Ocata looking great. I think we could look even better if we spent
more time on improving our documentation.

--
Ian Cordasco

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

Re: [openstack-dev] [docs][release][ptl] Adding docs to the release schedule

[Ian Cordasco]

-Original Message-
From: Telles Nobrega <tenob...@redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: March 2, 2017 at 08:01:29
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Cc: openstack-d...@lists.openstack.org <openstack-d...@lists.openstack.org>
Subject:  Re: [openstack-dev] [docs][release][ptl] Adding docs to the
release schedule

> I really believe that this idea will makes us work harder on keeping our
> docs in place and will make it for a better documented producted by release
> date.
> As shared before, I do believe that this is isn't easy and will demand a
> lot of effort from some teams, specially smaller teams with too much to do,
> but we from Sahara are on board with this approach and will try our best to
> do so.

Most things worth doing are difficult. =) This seems to be one of
them. If deliverable teams really work together, they may end up in a
situation like Glance did this cycle where we kind of just sat on our
hands after RC-1 was tagged. That time *could* have been better spent
reviewing all of our documentation.

I know projects go sideways all the time. I think this was Glance's
first cycle like this in a few cycles. But if we can make a habit of
creating excellent release candidates, we can spend the intermediate
time on documentation. I think that's a good compromise.

--
Ian Cordasco

__
OpenStack Development Mailing 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][swg] per-project "Business only" moderated mailing lists

[Ian Cordasco]

-Original Message-
From: Chris Dent <cdent...@anticdent.org>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: March 2, 2017 at 06:50:11
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all][swg] per-project "Business only"
moderated mailing lists

> On Mon, 27 Feb 2017, Clint Byrum wrote:
>
> > So, I'll ask more generally: do you believe that the single openstack-dev
> > mailing list is working fine and we should change nothing? If not, what
> > problems has it created for you?
>
> No, it is not working fine, but that may be normal and the best we
> can do.

Specifically, it seems to be *broken* for our Release Team that needs
to communicate in an efficient way with PTLs and Release CPLs.

I understand the purpose of these business-only lists would also allow
for mascots to be sent to that, but I liked the ability to participate
in the discussions of other mascots. Granted, I didn't do it, but I
was also happy to read their conversations.

I don't think there's enough "noise" traffic to justify individual
lists. Would it perhaps be better to have a mailing list that the
release team can use to reach PTLs and Release CPLs with
notifications? Would that satisfy it? At that point, it would be up to
each PTL to subscribe, etc., but it also prevents the Release team
from having to generate N emails where N is the number of
"business-only" lists.

--
Ian Cordasco

__
OpenStack Development Mailing 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][swg] per-project "Business only" moderated mailing lists

[Ian Cordasco]

-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 27, 2017 at 11:19:25
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all][swg] per-project "Business only"
moderated mailing lists

> Dean Troyer wrote:
> > On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum wrote:
> >> This is not for users who only want to see some projects. That is a well
> >> understood space and the mailman filtering does handle it. This is for
> >> those who want to monitor the overall health of the community, address
> >> issues with cross-project specs, or participate in so many projects it
> >> makes little sense to spend time filtering.
> >
> > Monday morning and the caffiene is just beginning to reach my brain,
> > but this seems counter-intuitive to me. I consider myself someone who
> > _does_ want to keep in touch with the majority of the community, and
> > breaking things into N additional mailing lists makes that harder, not
> > easier. I _do_ include core team updates, mascots, social meetings in
> > that set of things to pay a little attention to here, especially
> > around summit/PTG/Forum/etc times.
> >
> > I've seen a couple of descriptions of who this proposal is not
> > intended to address, who exactly is expected to benefit from more
> > mailing lists?
>
> I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
> that would go to the -business lists) is worth the hassle of setting up
> 50 new lists, have people subscribe to them, and have overworked PTL
> moderate them...
>
> Also from my experience moderating such a -business list (the
> openstack-tc list) I can say that it takes significant effort to avoid
> having general-interest discussions there (or to close them when they
> start from an innocent thread). Over those 50+ -business mailing-lists
> I'm pretty sure a few would diverge and use the convenience of isolated
> discussions without "outsiders" potentially chiming in. And they would
> be pretty hard to detect...

I agree and would like to point out that it will likely confuse
newcomers. Where would they send their message to about whatever
feature their management is pressuring them to develop? Most likely
they'll try openstack-{project} first and then the PTL + their team
will have to read through it and guide the person to the openstack-dev
list. Core project teams already occasionally bicker over changes
being approved that one half wouldn't have approved. This will
introduce yet another place for subjective reasoning between trusted
members of the community.

I'm not sure there's a great deal of value in those lists considering
the likely costs.

--
Ian Cordasco

__
OpenStack Development Mailing 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-ansible] So long, farewell, auf wiedersehen

[Ian Cordasco]

-Original Message-
From: Truman, Travis <travis_tru...@comcast.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 22, 2017 at 10:49:57
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

> OpenStack-Ansible team,
>
> I've very much enjoyed being part of the OpenStack community over the past 14 
> months.
> My time in the OpenStack-Ansible community has been one of the most rewarding 
> experiences
> of my career. However, my career is changing directions and I'll no longer be 
> able to invest
> the time and energy required to maintain my involvement in the community.
>
> As a result, I'm resigning my core reviewer status effective immediately.
>
> Thank you to all of you in the community that I've worked with in IRC, at 
> summits in Austin
> and Barcelona and to all of you who gave your time to review and improve my 
> contributions.

Thank you for all your work on OSA Travis! Your reviews and
contributions have been very valuable.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [stable] [glance] revising the stable-maintenance list

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita <rosmaita.foss...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 17, 2017 at 10:21:17
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [glance] revising the core list

> Finally, the following people are dropped from the Glance core list due
> to inactivity during Ocata. On behalf of the entire Glance team, I
> thank each of you for your past service to Glance, and hope to see you
> again as Glance contributors:
> - Kairat Kushaev
> - Mike Fedosin
> - Louis Taylor

On the heels of this removal, I'd like to propose also removing Mike
Fedosin from the stable-maintenance team for Glance.

--
Ian Cordasco
Glance Stable Branch Liaison

__
OpenStack Development Mailing 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] [governance] Where is project:type documented?

[Ian Cordasco]

In openstack/releases in the deliverables directory, e.g.,
https://github.com/openstack/releases/blob/master/deliverables/ocata/glance.yaml

Please excuse my top-posting and brevity as I am sending this from my phone

On Feb 20, 2017 5:01 PM, "Kenny Johnston"  wrote:

> I saw in the cold upgrades tag page[1] that in order to receive the
> designation projects must also be "already tagged as type:service." Where
> do we maintain that distinction? I couldn't find it in projects.yaml[2].
>
> --
> Kenny Johnston | irc:kencjohnston | @kencjohnston
> [1]https://governance.openstack.org/tc/reference/
> tags/assert_supports-upgrade.html
> [2]https://github.com/openstack/governance/blob/
> master/reference/projects.yaml
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][heat] Heat stable-maint additions

[Ian Cordasco]

-Original Message-
From: Thomas Herve <the...@redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 17, 2017 at 09:40:23
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [stable][heat] Heat stable-maint additions

> On Fri, Feb 17, 2017 at 4:14 PM, Matt Riedemann wrote:
> > On 2/15/2017 12:40 PM, Zane Bitter wrote:
> >>
> >> Traditionally Heat has given current and former PTLs of the project +2
> >> rights on stable branches for as long as they remain core reviewers.
> >> Usually I've done that by adding them to the heat-release group.
> >>
> >> At some point the system changed so that the review rights for these
> >> branches are no longer under the team's control (instead, the
> >> stable-maint core team is in charge), and as a result at least the
> >> current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly
> >> others (Thomas Herve, Sergey Kraynev), haven't been added to the group.
> >> That's slowing down getting backports merged, amongst other things.
> >>
> >> I'd like to request that we update the membership to be the same as
> >> https://review.openstack.org/#/admin/groups/152,members
> >>
> >> Rabi Mishra
> >> Rico Lin
> >> Sergey Kraynev
> >> Steve Baker
> >> Steven Hardy
> >> Thomas Herve
> >> Zane Bitter
> >>
> >> I also wonder if the stable-maint team would consider allowing the Heat
> >> team to manage the group membership again if we commit to the criteria
> >> above (all current/former PTLs who are also core reviewers) by just
> >> adding that group as a member of heat-stable-maint?
> >>
> >> thanks,
> >> Zane.
> >>
> >
> > Reviewing patches on stable branches have different guidelines, expressed
> > here [1]. In the past when this comes up I've asked if the people being
> > asked to be added to the stable team for a project have actually been doing
> > reviews on the stable branches to show they are following the guidelines,
> > and at times when this has come up the people proposed (usually PTLs)
> > haven't, so I've declined at that time until they start actually doing
> > reviews and can show they are following the guidelines.
>
> Respecting the guidelines is totally fair, but review stats won't tell
> you much, at least in my case: I barely do any stable reviews because
> I don't have approve rights. In the case of Heat, 90% of the backports
> are without conflicts, so stable reviews are just about verifying the
> guidelines and that the patch matches what's in master.
>
> But, I've been working on Heat for 4 years, I made about 1400 reviews
> on it, and I've been PTL. And the same for the other people that Zane
> mentioned. I feel we should be trusted on stable branches.

That seems like a very poor excuse - "I can't approve so I don't
review". I'm a stable maintenance core because I was reviewing stable
branch changes first. I had a good track record, and both the existing
Glance stable maint core reviewers and the global team agreed I had
displayed sound judgment for those.

Without being able to assess the quality of your reviews, how should
anyone else trust you with the stability of those branches?

> > There are reviewstats tools for seeing the stable review numbers for Heat, I
> > haven't run that though to check against those proposed above, but it's
> > probably something I'd do first before just adding a bunch of people.
>
> I appreciate your guidance and input, but shouldn't we decide our
> stable maintainers, the same way we decide cores? The current list
> contains at least one person that doesn't contribute anymore, so it's
> not like it's super curated.

This is how every other service team works (Nova, Keystone, Glance,
etc.). Just because the global stable maint team hasn't removed an
inactive person doesn't invalidate their assessment of potential core
reviewers.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Ed Leafe <e...@leafe.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 16, 2017 at 10:13:51
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> On Feb 16, 2017, at 10:07 AM, Doug Hellmann wrote:
>
> > When we signed off on the Big Tent changes we said competition
> > between projects was desirable, and that deployers and contributors
> > would make choices based on the work being done in those competing
> > projects. Basically, the market would decide on the "optimal"
> > solution. It's a hard message to hear, but that seems to be what
> > is happening.
>
> This.
>
> We got much better at adding new things to OpenStack. We need to get better 
> at letting go
> of old things.

I agree with the idea of making it easier for new contributors from
outside our walled garden of paid contributors. I won't further derail
this thread with my opinions of how corporations will begin to exploit
that and invest less directly in OpenStack's development though.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Dean Troyer <dtro...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 16, 2017 at 08:27:12
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco wrote:
> > It seems like a lot of people view "developing OpenStack" as more
> > attractive than "making it easy to deploy OpenStack" (via the
> > deployment tools in the tent). Doing both is really something project
> > teams should do, but I don't think shoving all of the deployment
> > tooling in repo makes that any better frankly. If we put our tooling
> > in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> > in repo as well.
>
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.

Right, I understand that.

> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those. I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.

Next week it'll be 7. ;)

> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up. (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)

Right. And we've seen teams like the UCA team be selective in what
they add (rightfully so).

> The solution I see is to have a mechanism by which important things
> can be communicated from the project developers that can be consumed
> by the packager/deployer community. Today, however sub-optimal it
> seems to be, that is release notes. Maybe adding a specific section
> for packaging would be helpful, but in practice that adds one more
> thing to remember to write to a list that is already hard to get devs
> to do.

I would think the mailing list (with a certain tag) might be better.

> Ad Doug mentions elsewhere in this thread, the liaison approach has
> worked in other areas, it may be a useful approach here. But I know
> as the PTL of a very small project I do not want 5 more hats to wear.
> Maybe one.

Right. And teams like Glance are struggling with their review queue
given the contraction you mention later on.

> We have encouraged the packaging groups to work together in the past,
> with mixed results, but it seems to me that a lot of the things that
> need to be discovered and learned in new releases will be similar for
> all of the downstream consumers. Maybe if that downstream community
> could reach a critical mass and suggest a single common way to
> communicate the deployment considerations in a release it would get
> more traction. And a single project liaison for the collective rather
> than one for each deployment project.

We also have packaging teams that repeatedly denegrate others who
create derivatives of their work while discouraging and denigration
others' participation. I think that coordination will be hard until
those packagers learn the hard lessons of their harmful actions.

> > I think what would help improve willing bidirectional communication
> > between service and deployment/packaging teams would be an
> > understanding that without the deployment/packaging teams, the service
> > teams will likely be out of a job. People will/can not deploy
> > OpenStack without the tooling these other teams provide.
>
> True in a literal sense. This is also true for our users, without
> them nobody will deploy a cloud in the first place. That has not
> changed anything unfortunately, we still regularly give our users
> miserable experiences because it is too much effort to participate
> with the (now comatose) UX team or prioritize making a common log
> format or reduce the number of knobs available to twiddle to make each
> cloud a unique snowflake.
>
> We can not sustain being all things to all people. Given the
> contraction of investment being considered and implemented by many of
> our foundation member companies, we will have to make some hard
> decisions about where to spend the resources we have left. Some of
> those decision are made for us by those member companies promoting
> their own priorities (your example o

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

[Ian Cordasco]

-Original Message-
From: Doug Hellmann <d...@doughellmann.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 16, 2017 at 07:06:25
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> Excerpts from Sylvain Bauza's message of 2017-02-16 10:55:14 +0100:
> >
> > Le 16/02/2017 10:17, Neil Jerram a écrit :
> > > On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow > > > > wrote:
> > >
> > > Radical idea, have each project (not libraries) contain a dockerfile
> > > that builds the project into a deployable unit (or multiple dockerfiles
> > > for projects with multiple components) and then it becomes the projects
> > > responsibility for ensuring that the right code is in that dockerfile to
> > > move from release to release (whether that be a piece of code that does
> > > a configuration migration).
> > >
> > >
> > > I've wondered about that approach, but worried about having the Docker
> > > engine as a new dependency for each OpenStack node. Would that matter?
> > > (Or are there other reasons why OpenStack nodes commonly already have
> > > Docker on them?)
> > >
> >
> > And one could claim that each project should also maintain its Ansible
> > playbooks. And one could claim that each project should also maintain
> > its Chef cookbooks. And one could claim that each project should also
> > maintain its Puppet manifests.
> >
> > I surely understand the problem that it is stated here and how it is
> > difficult for a deployment tool team to cope with the requirements that
> > every project makes every time it writes an upgrade impact.
> >
> > For the good or worst, as a service project developer, the only way to
> > signal the change is to write a release note. I'm not at all seasoned by
> > all the quirks and specifics of a specific deployment tool, and it's
> > always hard time for figuring out if what I write can break other things.
> >
> > What could be the solution to that distributed services problem ? Well,
> > understanding each other problem is certainly one of the solutions.
> > Getting more communication between teams can also certainly help. Having
> > consistent behaviours between heteregenous deployment tools could also
> > be a thing.
>
> Right. The liaison program used by other cross-project teams is
> designed to deal with this communication gap by identifying someone
> to focus on ensuring the communication happens. Perhaps we need to
> apply that idea to to some of the deployment projects as well.

I know the OpenStack-Ansible project went out of its way to try to
create a liaison program with the OpenStack services it works on. The
only engagement (that I'm aware) of it seeing has been from other
Rackspace employees whose management has told them to work on the
Ansible roles to ship the project they work on.

It seems like a lot of people view "developing OpenStack" as more
attractive than "making it easy to deploy OpenStack" (via the
deployment tools in the tent). Doing both is really something project
teams should do, but I don't think shoving all of the deployment
tooling in repo makes that any better frankly. If we put our tooling
in repo, we'll likely then start collecting RPM/Debian/etc. packaging
in repo as well.

I think what would help improve willing bidirectional communication
between service and deployment/packaging teams would be an
understanding that without the deployment/packaging teams, the service
teams will likely be out of a job. People will/can not deploy
OpenStack without the tooling these other teams provide.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

[Ian Cordasco]

-Original Message-
From: Andrey Kurilin <akuri...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 16, 2017 at 07:08:19
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Do we need service types at all?!
(Re: [octavia][sdk] service name for octavia)

> On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski > > wrote:
>
> > I think that you have to remember that OpenStack doesn't only work with
> > officially approved OpenStack services, but with any services that have a
> > conforming API.
> >
>
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone
> or MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

As others are trying to explain, what you want is the "OpenStack
Identity API", not a service whose name matches "*Keystone*". Keystone
is the implementation "Identity" is the thing it does and what you're
looking for from a service that is not Keystone.

Same goes for clouds that swap out RadosGW for Swift. They're looking
for an OpenStack Object Store API. They're not fuzzy matching on
project name.

--
Ian Cordasco

__
OpenStack Development Mailing 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] import urllib3 problem

[Ian Cordasco]

-Original Message-
From: Carmine Annunziata <carmine.annunziat...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 14, 2017 at 10:46:09
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] import urllib3 problem

> Hi,
> I upgraded ubuntu 14.04 to 16.04 LTS and now during the ./stack.sh i got
> this problem.
> I upgraded with:
> sudo pip install urllib3 --upgrade
> but the problem is still there:
>
> 2017-02-14 15:54:40.894 | Traceback (most recent call last):
> 2017-02-14 15:54:40.894 | File "/opt/stack/requirements/.venv/bin/pip",
> line 7, in
> 2017-02-14 15:54:40.894 | from pip import main
> 2017-02-14 15:54:40.894 | File "/opt/stack/requirements/.
> venv/local/lib/python2.7/site-packages/pip/__init__.py", line 21, in
>
> 2017-02-14 15:54:40.895 | from
> pip._vendor.requests.packages.urllib3.exceptions
> import DependencyWarning
> 2017-02-14 15:54:40.895 | File "/opt/stack/requirements/.
> venv/local/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py",
> line 62, in
> 2017-02-14 15:54:40.895 | from .packages.urllib3.exceptions import
> DependencyWarning
> 2017-02-14 15:54:40.895 | File "/opt/stack/requirements/.
> venv/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/__init__.py",
> line 29, in
> 2017-02-14 15:54:40.895 | import urllib3
> 2017-02-14 15:54:40.895 | ImportError: No module named urllib3
> 2017-02-14 15:54:40.904 | +inc/python:pip_install:1
> exit_trap
> 2017-02-14 15:54:40.908 | +./stack.sh:exit_trap:487 local
> r=1
> 2017-02-14 15:54:40.924 | ++./stack.sh:exit_trap:488 jobs
> -p
> 2017-02-14 15:54:40.935 | +./stack.sh:exit_trap:488 jobs=
> 2017-02-14 15:54:40.948 | +./stack.sh:exit_trap:491 [[ -n
> '' ]]
> 2017-02-14 15:54:40.952 | +./stack.sh:exit_trap:497
> kill_spinner
> 2017-02-14 15:54:40.967 | +./stack.sh:kill_spinner:383 '['
> '!' -z '' ']'
> 2017-02-14 15:54:40.982 | +./stack.sh:exit_trap:499 [[ 1
> -ne 0 ]]
> 2017-02-14 15:54:40.998 | +./stack.sh:exit_trap:500 echo
> 'Error on exit'
> 2017-02-14 15:54:40.999 | Error on exit
> 2017-02-14 15:54:41.002 | +./stack.sh:exit_trap:501
> generate-subunit 1487087613 67 fail
> 2017-02-14 15:54:41.817 | +./stack.sh:exit_trap:502 [[ -z
> /opt/stack/logs ]]
> 2017-02-14 15:54:41.821 | +./stack.sh:exit_trap:505
> /home/stack/devstack/tools/worlddump.py -d /opt/stack/logs
> 2017-02-14 15:54:43.088 | +./stack.sh:exit_trap:511 exit 1
> stack@coritel-VirtualBox:~/devstack$ sudo gedit
> /opt/stack/requirements/.venv/local/lib/python2.7/site-
> packages/pip/_vendor/requests/packages/__init__.py

Hi Carmine,

It looks like your virtualenv needs to be recreated. The version of
pip inside of it seems to be thoroughly broken.

--
Ian Cordasco

__
OpenStack Development Mailing 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][glance][glare][all] glance/glare/artifacts/images at the PTG

[Ian Cordasco]

ere requested by cloud operators for a long time.
> >
> > Fyi, now we in Nokia are preparing additional API, which corresponds to the
> > ETSI VNF Packaging Specification [1]. So support of Image v2 API is not an
> > impossible task, and we may implement it as an alternative way of
> > interaction with "Images" artifact type. In this case Nova and other
> > services using Glance are absolutely indifferent to what service provides
> > Image API.
> >
>
> If you can make it 100% API compatible with Image v2, you'll go a long way
> to helping users smoothly switch over.
>
> > All tasks related to documentation and packaging are solvable. We’re
> > working on them together with Nokia, so I can assure you that the documents
> > and packages will be available this spring. The same story is for Ansible
> > and Puppet.
> >
> > Now back again to our question. What I'd like is that Glare will receive
> > due recognition. Doing a project on the outskirts of OpenStack is not I
> > really want to. Therefore, it would be nice to develop Glare as a natural
> > evolution of Glance, associated with the requirements of operators and the
> > market in general. For Glance team is a good chance to try something new
> > and interesting, and of course gain new experience.
> >
>
> I support you in your attempt to have a natural evolution. I think
> it's going to be harder and harder the longer you're developing Glare's
> features without pushing for a transition to it. The heavier weight it
> gets, the less people will want it (again, remember how hard it was to
> get the community behind Neutron?)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

__
OpenStack Development Mailing 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][glance][glare][all] glance/glare/artifacts/images at the PTG

[Ian Cordasco]

-Original Message-
From: Jeremy Stanley <fu...@yuggoth.org>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 13, 2017 at 10:14:24
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [tc][glance][glare][all]
glance/glare/artifacts/images at the PTG

> On 2017-02-13 18:23:19 +0300 (+0300), Mikhail Fedosin wrote:
> [...]
> > Almost every project works with some binary data and must store it
> > somewhere, and almost always storage itself is not the part of the
> > project's mission. This issue has often been neglected. For this reason
> > there is no single recommended method for storing of binary data, which
> > would have a unified public api and hide all the things of the internal
> > storage infrastructure.
> [...]
>
> If you'll forgive the sarcasm, it sounds like you're proposing that
> OpenStack components should be able to rely on the existence of a
> standard service suitable for generalized storage and retrieval of
> arbitrary blobs of data through an API. Our trademark
> interoperability requirements may even guarantee the presence of one
> already in any compliant deployment; I'll have to check... ;)

Well it's a storage service, so I hope the name doesn't start with "S". ;D

--
Ian Cordasco

__
OpenStack Development Mailing 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][glance][glare][all] glance/glare/artifacts/images at the PTG

[Ian Cordasco]

y is not on board.
> >
> > Anyway, that's what we're going to discuss. I've booked one of the
> > fishbowl rooms so we can get input from people beyond just the Glance
> > and Glare projects.
> >
>
> Does anybody else feel like this is deja vu of Neutron's inception?
>
> While I understand sometimes there are just incompatibilities in groups,
> I think we should probably try again. Unfortunately, it sounds like
> Glare already did the Neutron thing of starting from scratch and sort
> of overlapping in functionality, instead of the Cinder thing where you
> forklift the code from one project into a new one and pay close attention
> to the peaceful transition of users. But we've been here before and we
> can do better. :)
>
> Given that, I'm hoping some folks who helped with the Neutron transition
> can attend this session and share what Neutron learned so that if Glare
> does take over for images, we don't end up in a multi-cycle quagmire
> where Glance is frozen and Glare is moving too fast for Glance devs to
> transition.
>
> FWIW, I think a generic control plane service to catalog blobs of
> useful data uploaded by users for other services is a good idea. I do
> not think the end product should have a data plane component (we have
> Swift for that).

So I 100% agree with you that these shouldn't have a data plane
component. The only reason the Glare team might disagree with you is
that they're talking about storing secrets (see also that thread I
started about Barbican a little while back) for users. I would expect
they would want some kind of control (assuming any of the Glare team
knows how to safely and securely store such secrets at rest) over the
storage backend for those.

Further, at the moment, both Glance and Glare use some rather
inefficient ways of receiving and forwarding the blobs of data they
receive. If we look at how other systems are architected (AWS for
example) users have to upload those blobs to the data plane services
first and then tell the other control plane services where to find
them. This is why Rackspace's Images V2 is structured the way it is
and Glance is working on the image-import specifications to make v2
more interoperable.

That said, I'm convinced neither Glare nor Glance have learned the
scaling issues from the current designs. At best, the last I looked,
Glare has learned not to inherit Glance's caching design which has
been frequently (and *rightfully*) criticized for the effect on
network usage. Beyond that, Glare adds artificial constraints (which
are subpar for their design) that I suspect will only frustrate people
looking for a more generic artifact storage solution.

I'm certain, however, that none of this will be discussed at the PTG
because these tend to be glossed over (and I won't be there to push on
these pain points).

--
Ian Cordasco

__
OpenStack Development Mailing 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] pbr and warnerrors status

[Ian Cordasco]

On Feb 7, 2017 5:47 PM, "Joshua Harlow"  wrote:

Likely just never pulled the trigger.

Seems like we should pull it though.



Will have to wait until Pike given the library release freeze
__
OpenStack Development Mailing 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-stable-maint] Stable check of openstack/ceilometer failed

[Ian Cordasco]

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.
<openstack-stable-ma...@lists.openstack.org>
Reply: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Date: February 1, 2017 at 00:11:20
To: openstack-stable-ma...@lists.openstack.org
<openstack-stable-ma...@lists.openstack.org>
Subject:  [Openstack-stable-maint] Stable check of openstack/ceilometer failed

> Build failed.
>
> - periodic-ceilometer-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-mitaka/3774607/
> : SUCCESS in 4m 09s
> - periodic-ceilometer-python27-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-mitaka/ca03c38/
> : FAILURE in 4m 09s

This appears to be a problem with oslo.vmware interactions with spec'd
mocks. It looks like y'all are mocking out some underlying part of
oslo.vmware and it's being provided a parameter that it doesn't
recognize.

It also looks like ceilometer isn't using constraints on mitaka. The
lack of constraints on mitaka was a problem for Glance's docs job. If
ceilometer is using constraints on newer versions, perhaps it should
consider backporting to stable/mitaka.

> - periodic-ceilometer-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-docs-newton/49e5570/
> : SUCCESS in 3m 08s
> - periodic-ceilometer-python27-newton 
> http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-newton/2088177/
> : FAILURE in 3m 08s

This also looks like a possible constraints problem. Whatever version
of gnocchiclient is being installed, the gnocchiclient.utils module
doesn't have "encode_resource_id" present and so the tests fail.

I suspect this is caused by some newer version of gnocchiclient being
used than is actually supported for stable/newton.

Cheers!
--
Ian Cordasco

__
OpenStack Development Mailing 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-stable-maint] Stable check of openstack/glance failed

[Ian Cordasco]

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.
<openstack-stable-ma...@lists.openstack.org>
Reply: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Date: January 30, 2017 at 00:16:19
To: openstack-stable-ma...@lists.openstack.org
<openstack-stable-ma...@lists.openstack.org>
Subject:  [Openstack-stable-maint] Stable check of openstack/glance failed

> Build failed.
>
> - periodic-glance-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-mitaka/384794b/
> : FAILURE in 3m 09s

I've created an issue for
https://bugs.launchpad.net/glance/+bug/1660444. I am fairly confident
this is related to the fact that pypa/setuptools recently started hard
depending (instead of vendoring) on its dependencies. Older versions
of pip don't recognize that setuptools' dependencies must be installed
before it is installed.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [glance] new draft logo of the Glance mascot

[Ian Cordasco]

I love it!

Top-posting from my phone

On Jan 28, 2017 3:08 PM, "Brian Rosmaita" 
wrote:

> Hello Glancers,
>
> Attached is the new draft logo of the Glance mascot.  It looks to me
> like this draft captures the key features we requested (and is much more
> personable than the previous version).  If you have a contrary opinion,
> please reply quickly as Heidi Joy's team wants to have all the logos
> ready before the PTG.
>
> I just want to add that this mascot is going to need a name.  I hereby
> propose "Bikeshed, the Glance chipmunk".  But hopefully someone will
> have a better idea.
>
> cheers,
> brian
>
> On 1/26/17, 9:46 PM, "Heidi Joy Tretheway"  wrote:
> > Hi Brian and Nikhil,
>
> > I'm happy to be able to finally share a new take on the Glance
> > project mascot. We listened to your team's feedback via the survey
> > and we asked a different illustration team to make a chipmunk with
> > its cheek stuffed with nuts, as your team requested. I hope your team
> > likes it! We're pushing hard to have everything ready by the PTG, so
> > please do alert me if there's anything else of major concern. Thank
> > you!
>
> __
> OpenStack Development Mailing 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] [glance] priorities for the coming week (01/27-02/02)

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita <rosmaita.foss...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 26, 2017 at 17:03:58
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [glance] priorities for the coming week (01/27-02/02)

> First, please read the email from Ian (our release czar) about the
> feature freeze:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/111067.html
>
> We have three priorities this week. The first is an all-hands-on-deck
> super priority, namely, reviewing (and re-reviewing, as appropriate) the
> code associated with Rolling Upgrades, which has received a FFE:
>
> - https://review.openstack.org/#/c/382958/
> - https://review.openstack.org/#/c/392993/
> - https://review.openstack.org/#/c/397409/
> - https://review.openstack.org/#/c/424774/

This last patch is described (in the commit title) as a WIP and the
author is not around (they're taking time off). Is someone else
working on it/taking it over? Does it belong in this list?

> Please start your reviews now. We don't want to be in a situation next
> week where people are rush-reviewing things.
>
> The other, secondary, not as important as the above, items are:
>
> * nominate any appropriate glanceclient bugs that didn't make it into
> this week's release by tagging them in Launchpad with
> "ocata-backport-potential". Please do this earlier rather than later,
> but do it consistently with the above.
>
> * ongoing work on the security bug - actually, this one is pretty
> important. Anyone in coresec, the only excuse for not reviewing Rolling
> Upgrades patches is if you are actively working on this bug.
>
> Have a good week, everyone!
>
> cheers,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

__
OpenStack Development Mailing 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-ansible] Proposing Amy Marrich for core

[Ian Cordasco]

-Original Message-
From: Major Hayden <ma...@mhtx.net>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 27, 2017 at 08:52:58
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 01/27/2017 08:29 AM, Alexandra Settle wrote:
> > I would like to propose Amy Marrich for the core team for OpenStack-Ansible.
>
> +3.14

+2.718

--
Ian Cordasco

__
OpenStack Development Mailing 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] [Glance] Feature Freeze In Effect

[Ian Cordasco]

Hi Glancers!

Glance 14.0.0.0b3 (Ocata-3) has been released.  With that done Glance
now enters its Feature Freeze period until release.  There is *one*
exception to that freeze (as discussed in today's meeting): Rolling
Upgrades work. That includes

- https://review.openstack.org/#/c/382958/
- https://review.openstack.org/#/c/392993/
- https://review.openstack.org/#/c/397409/

If you are working on Glance, you should be reviewing those and
testing them locally.

No new feature work on Glance will be accepted until stable/ocata has
been created. I will attempt to keep track of all new feature work
coming into the review queue and I will -2 it with the appropriate
message.

If there are any patches in the review queue that aren't already
approved prior to next week's meeting, I will not wait for them to
work their way through Zuul's gate queue. It would be ideal if we do
not have to wait for anything on Thursday to create the release
request.

Note: I will be closely watching our project. If any features are
merged between now and RC-1, I will work to revert them, regardless of
whether it is accidental or not. We've had a few approvals lately that
have been suspect and I expect all of Glance's cores to be a bit more
careful.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [Glance] Ocata-3 Priorities

[Ian Cordasco]

Hi all,

Brian kindly emailed the list last week [1] with our priorities for
python-glanceclient and glance.

The python-glanceclient priorities have all been effectively reviewed
and python-glanceclient has been released. The stable/ocata branch for
it now exists as well.

If you are reviewing Glance changes, *PLEASE* focus on the remaining priorities:

- https://review.openstack.org/#/c/382958/
- https://review.openstack.org/#/c/392993/
- https://review.openstack.org/#/c/397409/

All three of those support rolling upgrades via Alembic in Glance. If
we get those finished, we have a stretch priority of fixing Glance's
compatibility with WebOb 1.7.x:

- https://review.openstack.org/423366

Please do *NOT* approve other changes unless they are on this list and
please focus on reviewing these.

I have provided several procedural -2's on patches that will not be
merged until Ocata-3 or RC-1 is tagged. I've commented on each as to
when those -2's will be lifted. As release liaison and as a fellow
reviewer, I expect you all to be focusing on these priorities.

I appreciate your cooperation in releasing the best version of Glance yet.

[1]: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110617.html
--
Ian Cordasco
Your Friendly, But Stern, Neighborhood Release CPL

__
OpenStack Development Mailing 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] Re: [kolla] A new kolla-salt deliverable

[Ian Cordasco]

-Original Message-
From: Michał Jastrzębski <inc...@gmail.com> <inc...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org> <openstack-dev@lists.openstack.org>
Date: January 24, 2017 at 11:01:14
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org> <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

> Hello everyone,
>
> We've reached our agreement!
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_28264d5a40d0088c
> New deliverable process will be lightweight - just normal +2+2+PTL
> vote is needed to add new deliverable. I'm going to create new
> deliverables.yaml file in Kolla repository which will allow us to keep
> track of deliverables. Review incoming:)

Is Kolla not using openstack/releases to track deliverables? If so, why
duplicate that information?

-- 
Ian Cordasco
__
OpenStack Development Mailing 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] [glance] Propose Dharini Chandrasekar for Glance core

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita <rosmaita.foss...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 24, 2017 at 07:37:24
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core. She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams. Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it. Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering. She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know. I plan to add Dharini to
> the core list after this week's Glance meeting.

0 concerns on my end.

Good work, Dharini!

--
Ian Cordasco

__
OpenStack Development Mailing 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-ansible] Ocata deployed on CentOS 7!

[Ian Cordasco]

-Original Message-
From: Monty Taylor <mord...@inaugust.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 19, 2017 at 10:22:23
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [openstack-ansible] Ocata deployed on CentOS 7!

> On 01/19/2017 10:14 AM, Ian Cordasco wrote:
> > -Original Message-
> > From: Adam Heczko
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: January 19, 2017 at 10:06:14
> > To: OpenStack Development Mailing List (not for usage questions)
> >
> > Subject: Re: [openstack-dev] [openstack-ansible] Ocata deployed on CentOS 7!
> >
> >> Hi Major, great news indeed.
> >> BTW are you implying that Ubuntu LTS is unstable or not stable enough to
> >> run OpenStack?
> >> I think that it would be valuable if you could share more details in this
> >> regard, point to Ubuntu specific bugs etc.
> >> Thanks.
> >
> > I think Major may be referring to some serious performance regressions
> > found in Ubuntu 16.04. The default system Python is significantly
> > slower by default. I know he's working with upstream developers to fix
> > it, but it was problematic for OSA.
>
> /me learns things and also will keep his mouth shut next time :)

You were right that this was part of an effort towards multi-distro
support though!

--
Ian Cordasco

__
OpenStack Development Mailing 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-ansible] Ocata deployed on CentOS 7!

[Ian Cordasco]

-Original Message-
From: Monty Taylor <mord...@inaugust.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 19, 2017 at 10:18:20
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [openstack-ansible] Ocata deployed on CentOS 7!

> On 01/19/2017 10:04 AM, Adam Heczko wrote:
> > Hi Major, great news indeed.
> > BTW are you implying that Ubuntu LTS is unstable or not stable enough to
> > run OpenStack?
> > I think that it would be valuable if you could share more details in
> > this regard, point to Ubuntu specific bugs etc.
>
> I believe this is more about supporting folks who want to run on
> Centos/RHEL, rather than a step to removing Ubuntu support.

That's also correct. OpenStack-Ansible is attempting to support
multiple distros at the same time. =)

--
Ian Cordasco

__
OpenStack Development Mailing 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-ansible] Ocata deployed on CentOS 7!

[Ian Cordasco]

-Original Message-
From: Adam Heczko <ahec...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 19, 2017 at 10:06:14
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [openstack-ansible] Ocata deployed on CentOS 7!

> Hi Major, great news indeed.
> BTW are you implying that Ubuntu LTS is unstable or not stable enough to
> run OpenStack?
> I think that it would be valuable if you could share more details in this
> regard, point to Ubuntu specific bugs etc.
> Thanks.

I think Major may be referring to some serious performance regressions
found in Ubuntu 16.04. The default system Python is significantly
slower by default. I know he's working with upstream developers to fix
it, but it was problematic for OSA.

--
Ian Cordasco

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

[Ian Cordasco]

-Original Message-
From: Corey Bryant <corey.bry...@canonical.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 19, 2017 at 08:52:25
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [keystone] webob 1.7

> On Wed, Jan 18, 2017 at 9:08 AM, Ian Cordasco
> wrote:
>
> > -Original Message-
> > From: Chuck Short
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: January 18, 2017 at 08:01:46
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] [keystone] webob 1.7
> >
> > > Hi
> > >
> > > We have been expericing problems with newer versions of webob (webob
> > 1.7).
> > > Reading the changelog, it seems that the upstream developers have
> > > introduced some backwards incompatibility with previous versions of webob
> > > that seems to be hitting keystone and possibly other projects as well
> > > (nova/glance in particular). For keystone this bug has been reported in
> > bug
> > > #1657452. I would just like to get more developer's eyes on this
> > particular
> > > issue and possibly get a fix. I suspect its starting to hit other distros
> > > as well or already have hit.
> >
> > Hey Chuck,
> >
> > This is also affecting Glance
> > (https://bugs.launchpad.net/glance/+bug/1657459). I suspect what we'll
> > do for now is blacklist the 1.7.x releases in openstack/requirements.
> > It seems a bit late in the cycle to bump the minimum version to 1.7.0
> > so we can safely fix this without having to deal with
> > incompatibilities between versions.
> >
> > --
> > Ian Cordasco
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Hi Ian,
>
> Were you suggesting there's a new version of webob in the works that fixes
> this so we could bump upper-constraints and blacklist 1.7.x?

No. I was suggesting that OpenStack not try to work with the 1.7
series of WebOb.

> Unfortunately at this point we're at webob 1.7.0 in Ubuntu and there's no
> going backward for us. The corresponding bugs were already mentioned in
> this thread but worth noting again, these are the bugs tracking this:
>
> https://bugs.launchpad.net/nova/+bug/1657452
> https://bugs.launchpad.net/glance/+bug/1657459
>
> So far this affects nova, glance, and keystone (David has a patch in review
> - https://review.openstack.org/#/c/422234/).

I'll have to see if we can get that prioritized for Glance next week
as a bug fix candidate post Ocata-3. We decided our priorities for the
next week just a short while ago. I'm going to see if we can move it
onto this week's list though.

Cheers,
--
Ian Cordasco

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

[Ian Cordasco]

-Original Message-
From: Chuck Short <chuck.sh...@canonical.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 18, 2017 at 08:01:46
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [keystone] webob 1.7

> Hi
>
> We have been expericing problems with newer versions of webob (webob 1.7).
> Reading the changelog, it seems that the upstream developers have
> introduced some backwards incompatibility with previous versions of webob
> that seems to be hitting keystone and possibly other projects as well
> (nova/glance in particular). For keystone this bug has been reported in bug
> #1657452. I would just like to get more developer's eyes on this particular
> issue and possibly get a fix. I suspect its starting to hit other distros
> as well or already have hit.

Hey Chuck,

This is also affecting Glance
(https://bugs.launchpad.net/glance/+bug/1657459). I suspect what we'll
do for now is blacklist the 1.7.x releases in openstack/requirements.
It seems a bit late in the cycle to bump the minimum version to 1.7.0
so we can safely fix this without having to deal with
incompatibilities between versions.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [security] FIPS compliance

[Ian Cordasco]

 different. With a wrapper in place, we ought to be able to modify the
> implementation of the wrapper to accommodate that to ensure backwards
> compatibility, during the deprecation period after the upstream fix is
> implemented.

Sure, wrappers provide us with a lot of flexibility. It would just be
convenient for the wrapper to mimic what folks would expect from that
final API. That's why the original wrapper proposal is mimicking what
Red Hat already ships.

I don't think the wrapper should have the same poor design decisions,
but I do emphatically support the idea of this wrapper and the desired
outcome whole-heartedly. I'm sorry I didn't say that sooner. :)

--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Jay Pipes <jaypi...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 17, 2017 at 12:31:21
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 01/17/2017 07:57 AM, Ian Cordasco wrote:
> > On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar wrote:
> >> Ian,
> >>
> >> This is a fascinating conversation. Let me offer two observations.
> >>
> >> First, Trove has long debated the ideal solution for storing secrets. There
> >> have been many conversations, and Barbican has been considered many times.
> >> We sought input from people who were deploying and operating Trove at 
> >> scale;
> >> customers of Tesora, self described users of the upstream Trove, and some 
> >> of
> >> the (then) active contributors who were also operators.
> >>
> >> The consensus was that installing and deploying OpenStack was hard enough
> >> and requiring the installation of yet more services was problematic. This 
> >> is
> >> not something which singles out Barbican in any way. For example, Trove 
> >> uses
> >> Swift as the default object store where backups are stored, and in
> >> implementing replication we leveraged the backup capability. This means 
> >> that
> >> to have replication, one needs to have Swift. Several deployers have
> >> objected to this since they don't have swift. But that is a dependency 
> >> which
> >> we considered to be a hard dependency and offer no alternatives; you can
> >> have Ceph if you so desire but we still access it as a swift store.
> >> Similarly we needed some capabilities of job scheduling and opted to use
> >> mistral for this; we didn't reimplement all of these capabilities in Trove.
> >>
> >> However, when it comes to secret storage, the consensus of opinion is
> >> Yet another service.
> >
> > So, what spurred this thread is that I'm currently working on Craton
> > which wants to store deployment secrets for operators and I've
> > recently received a lot of private mail about Glare and how one of its
> > goals is to replace Barbican (as well as Glance).
>
> Problem #1: private emails. Why? Encourage whomever is privately
> emailing you to instead post to the mailing list, otherwise parties are
> not acting in the Open[Stack] Way.

That has come up with those people.

> Problem #2: What does Glare have to do with secret storage? I can
> understand someone saying that Glare might eventually replace Glance,
> but I'm not aware of anyone ever building crypto use cases or
> functionality into the design of Glare. Ever.

This is exactly my understanding as well. Glare was meant to be an
artifact service, not a secrets service. I guess a reductionist could
claim all data is an artifact, but that's obviously a flawed argument.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [security] [telemetry] How to handle security bugs

[Ian Cordasco]

On Tue, Jan 17, 2017 at 8:02 AM, Julien Danjou <jul...@danjou.info> wrote:
> On Tue, Jan 17 2017, Adam Heczko wrote:
>
>> Hi Julien, I think that you should follow this [1] workflow.
>>
>> TL;DR: Pls make sure that if the bug is serious make it private on LP so
>> that only core team members can access it and propose patches. Please do
>> not send patches to Gerrit review queue but rather attach it to LP bug
>> ticket and discuss there. Contact VMT members to get more details on how to
>> get Telemetry project covered by VMT.
>>
>> [1] https://security.openstack.org/vmt-process.html
>
> IMHO that's a problem. The page is so long and the process so complex
> that if nobody has the time to do all of that, it'll never be fixed or
> I'll just send the patch to Gerrit to get it fix and be done with it.
>
> At first glance Telemetry matches all requirements to get covered by
> VMT. IIRC last time we asked for it we get punted because there was
> already too much work for the VMT team. But if that's possible, we'd be
> glad to apply again. :-)

Or, perhaps the last time people complained that the process
documentation was too detailed and the telemetry project decided it
didn't want to have to follow it? If that's the case, following the
embargoed procedures might not be what you want as a project. At that
point, you don't need to work with the VMT and you can immediately
open the bug to start collaborating on Gerrit. You of course open up
all of your deployers to being targeted, but that's the project's call
in the end I guess.

I would think that if you want the "vulnerability:managed" tag, you
might be willing to follow the process outlined. Perhaps it's verbose,
but it is verbose for good reason. OpenStack's handling of embargoed
issues is pretty much as good as it gets for a project the size of
OpenStack. It benefits deployers and users by making the issue AND the
fix known at the same time which gives deployers the ability to
immediately consume the fix.

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

On Tue, Jan 17, 2017 at 8:04 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote:
> controls than this, but they never showed up AFAIK. And that's just the
> problem - people think 'Oh, barbican is storing the cinder volume secrets,
> great, we're secure' when actually barbican has made the security situation
> worse not better. It's a pretty terrible secrets-as-a-service product at the
> moment. Fixing it is not trivial.

So this is the second time you've asserted that Barbican is "a pretty
terrible secrets-as-a-service product". Instead of repeatedly saying
the same thing, have you worked with them on this? From your own
accounts, it sounds like you're not providing the constructively
critical feedback necessary to help the Barbican team and haven't
attempted to prior to this thread (although I'd not call your
criticisms constructive). I somehow doubt you'd be accepting of this
kind of feedback if it were aimed at Cinder. Are there open bugs that
have been ignored that you've filed? Items you've brought up at their
meetings?

To be clear, I started this thread to help the Barbican team gather
actionable items to further adoption because it seems a worthwhile
goal. Yes Barbican can improve, so can Cinder. So let's keep these
discussions constructive, okay?

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [security] [telemetry] How to handle security bugs

[Ian Cordasco]

On Tue, Jan 17, 2017 at 6:26 AM, Julien Danjou <jul...@danjou.info> wrote:
> Hi,
>
> I've asked on #openstack-security without success, so let me try here
> insteead:
>
> We, Telemetry, have a security bug and we're not managed by VMT, any
> hint as how to handle our bug? Or how to get covered by VMT? 

So, in terms of process I'd advise you read
https://security.openstack.org/vmt-process.html because it describes
how the VMT process works.

I believe 
http://docs.openstack.org/project-team-guide/vulnerability-management.html
described that you need to be "security-supported" which involves
joining the list of projects with the "vulnerability:managed" tag
(https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html).

https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html#requirements
describes the requirements to attain that tag.

Cheers,
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

 have to balance what most people on this
list consider "normal" deployments of OpenStack against the increasing
demand to be able to deploy OpenStack on a FIPS compliant kernel, so
now we should all be designing our cryptographic based features in
ways that can satisfy both or have fallbacks in the case of FIPS.

Cheers
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

On Mon, Jan 16, 2017 at 6:11 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
>> Is the problem perhaps that no one is aware of other projects using
>> Barbican? Is the status on the project navigator alarming (it looks
>> like some of this information is potentially out of date)? Has
>> Barbican been deemed too hard to deploy?
>>
>> I really want to understand why so many projects feel the need to
>> implement their own secrets storage. This seems a bit short-sighted
>> and foolish. While these projects are making themselves easier to
>> deploy, if not done properly they are potentially endangering their
>> users and that seems like a bigger problem than deploying Barbican to
>> me.
>>
>
> Just food for thought, and I'm pretty sure it's probably the same for
> various others; but one part that I feel is a reason that folks don't deploy
> barbican is because most companies need a solution that works beyond
> OpenStack and whether people like it or not, a OpenStack specific solution
> isn't really something that is attractive (especially with the growing
> adoption of other things that are *not* OpenStack).
>
> Another reason, some companies have or are already building/built solutions
> that offer functionality like what's in https://github.com/square/keywhiz
> and others and such things integrate with kubernetes and **their existing**
> systems ... natively already so why would they bother with a service like
> barbican?
>
> IMHO we've got to get our heads out of the sand with regard to some of this
> stuff, expecting people to consume all things OpenStack and only all things
> OpenStack is a losing battle; companies will consume what is right for their
> need, whether that is in the OpenStack community or not, it doesn't really
> matter (maybe at one point it did).

As long as they're using something secure, that's fine by me. Instead
these projects all want to reimplement the same functionality on their
own.

Does Castellan need to become something that can integrate with
Barbican + all of these other projects?

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [security] FIPS compliance

[Ian Cordasco]

On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
> Hi, in previous threads, there have been discussions about enabling FIPS,
> and the problems we are hitting with md5 inside OpenStack:
> http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html
>
> It is important from a security perspective to enable FIPS, however
> OpenStack cannot boot with that, because of the existence of md5 calls in
> several projects. These calls are not used for security, just for hash
> generation, but even with that, FIPS is blocking them.
>
> There is a patch proposed for newest versions of python, to avoid that
> problem. The idea is that when a hash method is called, users could specify
> if these are used for security or not. If the useforsecurity flag is set to
> False, FIPS won't block the call. See: http://bugs.python.org/issue9216

This patch looks to have died off in 2013 prior to Robert's comment from today.

> This won't land until next versions of Python, however the patch is already
> on place for current RHEL and CentOS versions that are used in OpenStack
> deploys. Using that patch as a base, I have a proposal to allow FIPS
> enabling, at least in the distros that support it.
>
> The idea is to create a wrapper around md5, something like:
> md5_wrapper('string_to_hash', useforsecurity=False)

We should probably work harder on actually landing the patch in Python
first. I agree with Robert that the optional boolean parameter is
awkward. It'd be better to have a fips submodule.

> This method will check the signature of hashlib.md5, and see if that's
> offering the useforsecurity parameter. If that's offered, it will pass the
> given parameter from the wrapper. If not, we will just call
> md5('string_to_hash') .
>
> This gives us the possibility to whitelist all the md5 calls, and enabling
> FIPS kernel booting without problems. It will start to work for distros
> supporting it, and it will be ready to use generally when the patch lands in
> python upstream and another distros adopt it. At some point, when all
> projects are using newest python versions, this wrapper could disappear and
> use md5 useforsecurity parameter natively.

I'd much rather have the upstream interface fixed in Python and then
to have a wrapper that does things the correct way. Otherwise, we're
encouraging other distros to use a patch that still requires a lot of
edits to address the review comments and might be defining an API that
will never end up in Python.

> The steps needed to achieve it are:
> - create a wrapper, place it on some existing project or create a new fips
> one
> - search and replace all md5 calls used in OpenStack core projects , to use
> that new wrapper. Note that all the md5 calls will be whitelisted by
> default. We have not noted any md5 call that is used for security, but if
> that exists, it shall be better to use another algorithms, in terms of
> security.
>
> What do people think about it?

I think people should work on the Python patches *first*. Once they're
merged, *then* we should potentially create a wrapper (if it's still
necessary at that point) to do this.

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Dave McCowan (dmccowan) <dmcco...@cisco.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 13:03:41
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?
> Yep. Barbican supports four backend secret stores. [1]
>
> The first (Simple Crypto) is easy to deploy, but not extraordinarily
> secure, since the secrets are encrypted using a static key defined in the
> barbican.conf file.
>
> The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> a hardware base to encrypt and/or store the secrets.
> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
> encrypt and store the secrets.
>
> We do not currently have a secret store that is both highly secure and
> easy to deploy/manage.
>
> We, the Barbican community, are very open to any ideas, blueprints, or
> patches on how to achieve this.
> In any of the homegrown per-project secret stores, has a solution been
> developed that solves both of these?
>
>
> [1]
> http://docs.openstack.org/project-install-guide/key-manager/draft/barbican-
> backend.html

So there seems to be a consensus that Vault is a good easy and secure
solution to deploy. Can Barbican use that as a backend secret store?

--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Chris Friesen <chris.frie...@windriver.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 11:26:41
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 01/16/2017 10:31 AM, Rob C wrote:
>
> > I think the main point has already been hit on, developers don't want to
> > require that Barbican be deployed in order for their service to be
> > used.
>
> I think that this is a perfectly reasonable stance for developers to take. As
> long as Barbican is an optional component, then making your service depend on 
> it
> has a good chance of limiting your potential install base.
>
> Given that, it seems like the ideal model from a security perspective would be
> to use Barbican if it's available at runtime, otherwise use something 
> else...but
> that has development and maintenance costs.

More seriously it requires developers who aren't familiar with
securely storing that kind of data re-implement exactly what Barbican
has done, potentially.

Being realistic, and not to discount anyone's willingness to try, but
I think the largest group of people qualified to build, review, and
maintain that kind of software would be the Barbican team.

I guess the question then becomes: How many operators would be willing
to deploy Barbican versus having to update each service as
vulnerabilities are found, disclosed, and fixed in their clouds. If
Barbican is as difficult to deploy as Rob is suggesting (that even
DogTag is difficult to deploy) maybe developers should be focusing on
fixing that instead of haphazardly reimplementing Barbican?

--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Rob C <hyaku...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 10:33:20
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> Thanks for raising this on the mailing list Ian, I too share some of
> your consternation regarding this issue.
>
> I think the main point has already been hit on, developers don't want to
> require that Barbican be deployed in order for their service to be
> used.
>
> The resulting spread of badly audited secret management code is pretty
> ugly and makes certifying OpenStack for some types of operation very
> difficult, simply listing where key management "happens" and what
> protocols are in use quickly becomes a non-trivial operation with some
> teams using hard coded values while others use configurable algorithms
> and no connection between any of them.
>
> In some ways I think that the castellan project was supposed to help
> address the issue. The castellan documentation[1] is a little sparse but
> my understanding is that it exists as an abstraction layer for
> key management, such that a service can just be set to use castellan,
> which in turn can be told to use either a local key-manager, provided by
> the project or Barbican when it is available.
>
> Perhaps a miss-step previously was that Barbican made no efforts to
> really provide a robust non-HSM mode of operation. An obvious contrast
> here is with Hashicorp Vault[2] which has garnered significant market
> share in key management because it's software-only* mode of operation is
> well documented, robust and cryptographically sound. I think that the
> lack of a sane non-HSM mode, has resulted in developers trying to create
> their own and contributed to the situation.
>
> I'd be interested to know if development teams would be less concerned
> about requiring Barbican deployments, if it had a robust non-HSM
> (i.e software only) mode of operation. Lowering the cost of deployment
> for organisations that want sensible key management without the expense
> of deploying multi-site HSMs.
>
> * Vault supports HSM deployments also
>
> [1] http://docs.openstack.org/developer/castellan/
> [2] https://www.vaultproject.io/

The last I checked, Rob, they also support DogTag IPA which is purely
a Software based HSM. Hopefully the Barbican team can confirm this.
--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Hayes, Graham <graham.ha...@hpe.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 09:26:00
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 16/01/2017 13:38, Ian Cordasco wrote:
> > Is the problem perhaps that no one is aware of other projects using
> > Barbican? Is the status on the project navigator alarming (it looks
> > like some of this information is potentially out of date)? Has
> > Barbican been deemed too hard to deploy?
>
> I know that historically it was considered hard to do a HA deploy of
> Barbican. When we initially evaluated DNSSEC in Designate (many years
> ago now) it was one of the sticking points.
>
> This may have (and most likely has) changed, but we seem to have long
> memories.

I know Rackspace recently made Barbican available to its cloud
customers. I suspect it's easier now to perform an HA deploy.

> It could be a side effect of the Big Tent - there are so many projects
> doing so many different things that projects don't want deployers to
> have deploy everything.

Yeah, I completely understand that. The thing is that in one case,
there's a project that currently relies on Barbican and wants to
replace that with a completely brand new service that will be doing
other things and then wants to layer secrets on top of it. It seems to
me like a terrible case of both scope creep and not actually caring
about the security the users expect from services that have to
interact with secrets. N services (besides Barbican) implementing
their own secrets storage each in their own way seem like N different
services that will be dealing with vulnerabilities and security
releases for the next few years. Perhaps that's pessimistic, but
looking at that with my operator hat on, I'd rather have to update *1*
service (barbican) rather than N if there's some vulnerability that
comes up. It's the same argument when it comes down to packaging and
vendoring dependencies. Update once instead of N times for each
package that has a copy of the library bundled in it.

> > I really want to understand why so many projects feel the need to
> > implement their own secrets storage. This seems a bit short-sighted
> > and foolish. While these projects are making themselves easier to
> > deploy, if not done properly they are potentially endangering their
> > users and that seems like a bigger problem than deploying Barbican to
> > me.
>
> +100 - One of the reasons we didn't just write our own signing was I
> am allergic to writing crypto code - I am not very good at it, and there
> is a project that people that either are, or know how to use the libs
> correctly.

I have the same allergy! This is why I've been pushing folks talking
about implementing their own secrets storage.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] Project Navigator Out of Date?

[Ian Cordasco]

Hi Tom!

-Original Message-
From: Tom Fifield <t...@openstack.org>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 10:02:24
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [barbican] Project Navigator Out of Date?

> On 16/01/17 21:55, Ian Cordasco wrote:
> >
> > Third, "Existence and quality of packages for this project in popular
> > distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and
> > OpenSUSE [5] all have packages (including in stable versions). I can't
> > speak to the quality of the packages, but knowing the hard work most
> > of our downstream redistributors put into those packages, I'm certain
> > they're good quality. This should *definitely* be updated, in my
> > opinion.
>
> https://bugs.launchpad.net/openstack-org/+bug/1656843
>
> https://github.com/OpenStackweb/openstack-org/pull/59

So, if I understand the two links correctly, changes are planned to
make that tag better and until they're made you're going to stop
displaying it using that with projects. Is that correct? Are there
other ways the community can help keep the navigator up-to-date?

--
Ian Cordasco

__
OpenStack Development Mailing 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] [barbican] Project Navigator Out of Date?

[Ian Cordasco]

Hi barbicaneers (I don't actually know what y'all call yourselves :)),

Related to the other thread I just started, I was looking at the
project navigator [1] for Barbican and found some things that look
wrong (to an outsider) and was hoping could be cleared up.

First, "Is this project maintained following the common Stable branch
policy?" appears to be "Yes" now. I notice you have stable branches
that actually look stable. Are y'all working with the stable
maintenance team on them?

Second, "Does this project follows standard deprecation?" I'm not
(yet) a user of Barbican, but are you still not following the standard
deprecation policy?

Third, "Existence and quality of packages for this project in popular
distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and
OpenSUSE [5] all have packages (including in stable versions). I can't
speak to the quality of the packages, but knowing the hard work most
of our downstream redistributors put into those packages, I'm certain
they're good quality. This should *definitely* be updated, in my
opinion.

Finally, "Are vulnerability issues managed by the OpenStack security
team?". I know that the OpenStack Security Project worked with the
Barbican team to come up with a vulnerability analysis a few midcycles
ago. Is that roughly where you all stopped? Is there a reason you
haven't attempted to work with the VMT on security issues?

Hopefully my agenda is obvious - I'd like to see fewer projects
attempting to implement their own secret storage and instead use
Barbican. Keeping the navigator up-to-date seems (to me) to be a good
way to improve Barbican's image. I would be happy to work with you all
(with what little time I have) to update the navigator to better
reflect Barbican's reality.

[1]: https://www.openstack.org/software/releases/newton/components/barbican
[2]: https://apps.fedoraproject.org/packages/s/barbican
[3]: 
https://packages.debian.org/search?keywords=barbican=all=all=all
[4]: 
http://packages.ubuntu.com/search?keywords=barbican=names=all=all
[5]: 
https://software.opensuse.org/search?utf8=✓=barbican_devel=false_unsupported=false=openSUSE:Leap:42.2

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

Hi everyone,

I've seen a few nascent projects wanting to implement their own secret
storage to either replace Barbican or avoid adding a dependency on it.
When I've pressed the developers on this point, the only answer I've
received is to make the operator's lives simpler.

I've been struggling to understand the reasoning behind this and I'm
wondering if there are more people around who can help me understand.

To help others help me, let me provide my point of view. Barbican's
been around for a few years already and has been deployed by several
companies which have probably audited it for security purposes. Most
of the technology involved in Barbican is proven to be secure and the
way the project has strung those pieces together has been analyzed by
the OSSP (OpenStack's own security group). It doesn't have a
requirement on a hardware TPM which means there's no hardware upgrade
cost. Furthermore, several services already provide the option of
using Barbican (but won't place a hard requirement on it). It stands
to reason (in my opinion) that if new services have a need for secrets
and other services already support using Barbican as secret storage,
then those new services should be using Barbican. It seems a bit
short-sighted of its developers to say that their users are definitely
not deploying Barbican when projects like Magnum have soft
dependencies on it.

Is the problem perhaps that no one is aware of other projects using
Barbican? Is the status on the project navigator alarming (it looks
like some of this information is potentially out of date)? Has
Barbican been deemed too hard to deploy?

I really want to understand why so many projects feel the need to
implement their own secrets storage. This seems a bit short-sighted
and foolish. While these projects are making themselves easier to
deploy, if not done properly they are potentially endangering their
users and that seems like a bigger problem than deploying Barbican to
me.

-- 
Ian Cordasco
Glance, Hacking, Bandit, and Craton core reviewer

__
OpenStack Development Mailing 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] [glance][tempest][api] community images, tempest tests, and API stability

[Ian Cordasco]

-Original Message-
From: Ian Cordasco <sigmaviru...@gmail.com>
Reply: Ian Cordasco <sigmaviru...@gmail.com>
Date: January 13, 2017 at 08:12:12
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
tempest tests, and API stability

> And besides "No one uses Glance" [ref: 
> http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]

I was being a bit glib when I wrote this last sentence this morning,
but in commenting on the Gerrit patch to skip the test in question, I
realized this is actually far more valid than I realized.

Let's look at the state of Glance v2 and be brutally honest:

Interoperability

    Glance v2 is currently incapable of being truly interoperable between
    existing publicly accessible clouds. There are two ways to currently
    upload images to Glance. Work is being done to add a third way that
    suits the needs of all cloud providers. This introduces further
    interoperability incompatibility (say *that* three times fast ;)) and
    honestly, I don't see it being a problem for the next reason.

    Further, the tasks API presents a huge number of interoperability
    problems. We've limited that to users with the admin role, but if you
    have an admin on two clouds operated by different people, there is a
    good likelihood the tasks will not be the same.


v2 deployment and usage

    The best anyone working on Glance can determine, v2 is rarely deployed
    for users and if it is, it isn't chosen. v2 was written to specifically
    excise some problematic "features" that some users still rely on. A
    such, you see conversations even between Glance and *other services*
    about how to migrate to v2. Nova only recently made the migration. Heat
    still has yet to do so and I think has only just relented in their
    desire to avoid it.


Security Concerns

    There are some serious security issues that will be fixed by this
    change. If we were to add the backwards compatibility shim that the QA
    team has suggested repeatedly that we add, we'd be keeping those security
    issues.


In short, I feel like the constant refrain from the QA team has been two fold:

- "This will cause interoperability problems"
- "This is backwards incompatible"

The Glance team has come to terms with this over the course of several
cycles. I don't think anyone is thrilled about the prospect of
potentially breaking some users' workflows. If we had been that
enthusiastic about it, then we simply would have acted on this when it
was first proposed. It would have completely gone unnoticed except by
some users. There's no acceptable way (without sacrificing security -
which let's be clear, is entirely unacceptable) that we can maintain a
backwards compatibility shim and Glance v2 already has loads of
interoperability problems. We're working on fixing them, but we're
also working on fixing the user experience, which is a big part of
this patch.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [glance][tempest][api] community images, tempest tests, and API stability

[Ian Cordasco]

-Original Message-
From: Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 12, 2017 at 13:35:56
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
tempest tests, and API stability

> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> > The issue is that we are proposing to introduce an incompatible change
> > in order to address an incoherence with image visibility semantics. We
> > have acknowledged that this is a breaking change, but the impact of the
> > change is mitigated by the way that the default visibility value is
> > assigned in Ocata.
> >
> > As I've documented earlier in the thread, we have discussed this change
> > with the wider community and the API Working Group, and they are OK with it.
> >
> > The current tempest test has done its duty and identified an
> > incompatibility in the Ocata code. We acknowledge that and salute you.
> > On balance, however, this change will be better for users (and as I've
> > documented earlier in the thread, we've minimized the impact of the
> > change), and we want to make it anyway.
>
> It is difficult to expect the impact of API change is small by us as 
> developers.

We're not claiming it is small. We have done our best to minimize the
impact though.

> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.

We really wanted to include this in our last beta release but the
Tempest test we're talking about right now prevented exactly that. We
might have been able to garner more information from users that way
but alas, we likely won't have time for users to adopt the changes,
provide us feedback, *and* give us time to revert if it does end up
being as disruptive as some are claiming it will be. (Honestly, I
think it'll probably end up being somewhere between where Brian and
others think it will be and where the QA team is claiming it will be.)

> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.

Right. Microversions do sometimes make changes like this better. That
said, microversioning would probably cause yet *more* confusion around
this change than a hard break would and would likely further introduce
security issues. A microversioned API here would (probably) map
"shared" and "private" in what we're proposing to "private" in what
already exists. That means someone continuing with the old version
could add members to a private image and there would *need* to be an
implicit conversion on the new side. This means someone could create
an image as "private" in our new version, switch to the old and
*force* it to be shared. That's all kinds of awful.

Microversions are great. But they're not a panacea. They would not
have helped us had we already had them. I would like Glance to add
them, but there's a vocal minority among our team that's opposed.

Moving past the microversioning conversation (that we've had far too
many times to date), it sounds like the tempest project still sees
itself as a sort of wiser and older sibling to other projects. Other
projects breaking their APIs (intentionally, to improve the user
experience) are then treated as if they're children and talked down
to, in each email on a topic. That's probably not at all the team's
intention, but that is absolutely how it feels on this side of the
conversation. (And as a reminder, intentions don't magically fix
things.) I'm surprised by this behaviour. It's not at all what I
expected from another project in OpenStack. I understand the QA team
feels as if it is defending some idealized user, but the reality is
that as of the last User Survey, *at least* 40% of users are *still*
using Kilo. If and when they upgrade, they'll be encountering far more
disruptive changes than tempest can prevent. Most are internal
implementation details that will require a whole lot more work to fix
for large clouds than fixing some API interactions.

In short, the Glance team is ready, willing, and able to own the
responsibility for any breakage this causes users and any
interoperability problems this will pose. We'd really appreciate
cooperation on this.

And besides "No one uses Glance" [ref:
http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]
;)

--
Ian Cordasco

___

Re: [openstack-dev] updating to pycryptome from pycrypto

[Ian Cordasco]

-Original Message-
From: Ian Cordasco <sigmaviru...@gmail.com>
Reply: Ian Cordasco <sigmaviru...@gmail.com>
Date: January 11, 2017 at 11:09:11
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] updating to pycryptome from pycrypto

> -Original Message-
> From: Matthew Thode
> Reply: prometheanf...@gentoo.org , OpenStack Development
> Mailing List (not for usage questions)
> Date: January 11, 2017 at 04:53:41
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] updating to pycryptome from pycrypto
>
> > So, pycrypto decided to rename themselves a while ago. At the same time
> > they did an ABI change. This is causing projects that dep on them to
> > have to handle both at the same time. While some projects have
> > migrated, most have not.
> >
> > A problem has come up where a project has a CVE (pysaml2) and the fix is
> > only in versions after they changed to pycryptome. This means that in
> > order to consume the fix in a python-native way all the pycrypto
> > dependency would need to be updated to pycryptome in all projects in the
> > same namespace that pysaml2 is installed.
> >
> > Possible solutions:
> >
> > update everything to pycryptome
> > * would be the best going forward
> > * a ton of work very late in the cycle
> >
> > have upstream pysaml2 release a fix based on the code before the change
> > * less work
> > * should still circle around and update the world in pike
> > * 4.0.2 was the last release 4.0.3 was the change
> > * would necessitate a 4.0.2.1 release
> > * tag was removed, can hopefully be recovered for checkout/branch
> >
> >
> > Here's the upstream bug to browse at your leisure :)
> >
> > https://github.com/rohe/pysaml2/issues/366
>
> I don't think pycrypto actually willfully renamed itself. [1] As I understand 
> it, pycryptome
> is a fork of pycrypto made after pycrypto decided that they wanted to tell 
> people to use
> pyca/cryptography instead. Frankly, given pycrypto's history (and the history 
> that
> pycryptome has probably inherited), I'd suspect that the best effort for 
> those of us
> interested, is to help pysaml2 express the deficits it has with cryptography 
> so it can
> move to a better project. If there are no deficits, then we should focus on 
> helping pysaml2
> port to cryptography.
>
>
> [1]: I'm verifying this with some people who know better

So I did verify that there are *several* hostile forks of PyCrypto.
That said, the work to move pysaml2 to cryptography has been finished:
https://github.com/rohe/pysaml2/pull/385

I'd ask OpenStackers to not start a brigade of +1s on the thread, but
if y'all want to watch it and help convince the maintainer (*if* they
need convincing) to merge this, that would be appreciated.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] updating to pycryptome from pycrypto

[Ian Cordasco]

-Original Message-
From: Matthew Thode <prometheanf...@gentoo.org>
Reply: prometheanf...@gentoo.org <prometheanf...@gentoo.org>,
OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 11, 2017 at 04:53:41
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] updating to pycryptome from pycrypto

> So, pycrypto decided to rename themselves a while ago. At the same time
> they did an ABI change. This is causing projects that dep on them to
> have to handle both at the same time. While some projects have
> migrated, most have not.
>
> A problem has come up where a project has a CVE (pysaml2) and the fix is
> only in versions after they changed to pycryptome. This means that in
> order to consume the fix in a python-native way all the pycrypto
> dependency would need to be updated to pycryptome in all projects in the
> same namespace that pysaml2 is installed.
>
> Possible solutions:
>
> update everything to pycryptome
> * would be the best going forward
> * a ton of work very late in the cycle
>
> have upstream pysaml2 release a fix based on the code before the change
> * less work
> * should still circle around and update the world in pike
> * 4.0.2 was the last release 4.0.3 was the change
> * would necessitate a 4.0.2.1 release
> * tag was removed, can hopefully be recovered for checkout/branch
>
>
> Here's the upstream bug to browse at your leisure :)
>
> https://github.com/rohe/pysaml2/issues/366

I don't think pycrypto actually willfully renamed itself. [1] As I
understand it, pycryptome is a fork of pycrypto made after pycrypto
decided that they wanted to tell people to use pyca/cryptography
instead. Frankly, given pycrypto's history (and the history that
pycryptome has probably inherited), I'd suspect that the best effort
for those of us interested, is to help pysaml2 express the deficits it
has with cryptography so it can move to a better project. If there are
no deficits, then we should focus on helping pysaml2 port to
cryptography.


[1]: I'm verifying this with some people who know better

Cheers,
--
Ian Cordasco

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

[Ian Cordasco]

-Original Message-
From: Joel Parker <joel.parker...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 9, 2017 at 10:25:36
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] STIG Tools

> I am new to the STIG hardening process and wanted to see if there was a
> standard way to diff between releases (RHEL STIG 7 draft 0.2 and 0.3 for
> example) or between RHEL 5 and 6 or something. Obviously the reason for
> this is too quickly check / implement the diff instead of going through the
> whole STIG again.

Hi Joel,

I'm not sure you meant to send this to the OpenStack mailing list, but
in case you did, I don't know of a good way of doing that. That said,
there is at least one project that attempts to automate it for you
(openstack-ansible-security). I've CC'd one of the cores to grab their
attention in case they can help you.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] [Security] Shorter Meetings

[Ian Cordasco]

-Original Message-
From: Rob C <hyaku...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 5, 2017 at 12:10:43
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [Security] Shorter Meetings

> Hi All,
>
> As per our IRC meeting today[1] we've decided to try shortening the
> Security IRC meetings to 30 minutes per week. The other option was to have
> meetings every two weeks but we all agreed that would lead to missed
> meetings, confusion around holidays etc.
>
> The main reason for shortening our meetings is because we have found that
> many of our members are finding that the amount of time they have to
> dedicate to OpenStack is shrinking, in response we're going to try to
> shorten our meetings by being more disciplined in following our weekly
> agenda[2].
>
> I'd encourage everyone participating in the project to ensure they can make
> the 30 minutes for the meeting which is every week, at 1700 UTC in the
> #openstack-meeting-alt room on Freenode.
>
> Cheers
> -Rob
>
> [1]
> http://eavesdrop.openstack.org/meetings/security/2017/security.2017-01-05-16.59.html
> [2] https://etherpad.openstack.org/p/security-agenda

Also, if you have something to bring up at the meeting, it doesn't
hurt to mention it here first. The [Security] tag should be watched by
the OSSP and having the lion's share of the conversation here should
allow for shorter, concise, and conclusive discussions in the meetings
(if they're necessary at all).

Cheers!
--
Ian Cordasco

__
OpenStack Development Mailing 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] [Release-job-failures] Release of openstack/glance failed

[Ian Cordasco]

-Original Message-
From: Tony Breeds <t...@bakeyournoodle.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>, OpenStack Development Mailing
List (not for usage questions) <openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 00:18:38
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [Release-job-failures] Release of
openstack/glance failed

> On Mon, Dec 12, 2016 at 09:46:54AM -0600, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Andreas Jaeger
> > Reply: OpenStack Development Mailing List (not for usage questions)
> > Date: December 12, 2016 at 01:39:17
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [Release-job-failures] Release of 
> > openstack/glance
> failed
> >
> > > On 2016-12-12 08:34, Andreas Jaeger wrote:
> > > > On 2016-12-12 06:20, Tony Breeds wrote:
> > > >> On Mon, Dec 12, 2016 at 04:44:18AM +, jenk...@openstack.org wrote:
> > > >>> Build failed.
> > > >>>
> > > >>> - glance-docs-ubuntu-xenial 
> > > >>> http://logs.openstack.org/38/38f199507aff8bfcaf81ad9ea58ea326224faf5f/release/glance-docs-ubuntu-xenial/de7d73e/
> > > : FAILURE in 1m 44s
> > > >>
> > > >> This boils down to [1] which is a known problem with newer 
> > > >> cryptography (and
> > > >> the interaction with openssl). What I don't understand is how we got 
> > > >> there
> > > >> with constratints working[2]. Perhaps it's the openssl on the release 
> > > >> sigining
> > > >> node is "newer" than general nodepool nodes?
> > > >
> > > > glance does not use constraints in venv environment.
> > > >
> > > > It can be used since a few months. I'll send a change for master,
> > >
> > > I expect this needs backporting to stable branches - stable or glance
> > > team, please review and backport yourself:
> > >
> > > https://review.openstack.org/409642
> >
> >
> > Thank you Andreas!
>
> https://review.openstack.org/#/c/410536 is the backport but it's still failing
> with the same
> issue with cryptography and openssl[1] :(
>
> Yours Tony.
> [1] 
> http://logs.openstack.org/36/410536/1/check/gate-glance-releasenotes/46c2615/console.html#_2016-12-14_05_13_53_002878

Hi Tony,

So if I understand correctly, presently:

- There is no 11.0.3 tag for glance which is what we planned to use to
tag liberty-eol
- There is no 11.0.3 tarball for glance
- There is no good way to generate a 11.0.3 tarball because of the
cryptography & openssl conflict
- There is also no good way to generate a liberty-eol tarsal because
of that issue.

I believe you asked in another thread (that I cannot locate) if it was
acceptable to the Glance team to not have an 11.0.3 tarball on
openstack.org. With Brian on vacation, I'm hoping the other stable
maintenance cores will chime in. I, for one, (as Release CPL and a
Stable branch core reviewer) don't think the tarballs are critical for
Glance. I'm fairly certain that most of the deployment projects use
the Git repository directly or Distro provided packages (which are
built from git tags). With that in mind, I don't think this should
block Glance being EOL'd.

I'm sorry for the delay in my reply. I took a little over a week of
time off myself.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] Using \ for multiline statements

[Ian Cordasco]

On Tue, Dec 27, 2016 at 12:00 PM, Ed Leafe <e...@leafe.com> wrote:
> On Dec 27, 2016, at 11:33 AM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
>>
>>> There is a problem with the use of backslash at the end of the line, where
>>> if you also put a space after it, it no longer does what it seemingly
>>> should.
>>
>> Oooh. nice. This is the good technical reason I was looking for. So there
>> really is a valid reason to avoid this, other than just preference of
>> readability and coding style. Thanks!
>
> True, but we also have a pep8 check for spaces at the end of lines.
>
> -- Ed Leafe

Worth noting, though, that if you are using multiple context managers
in a single 'with' statement that you can't use ()s to split them
across multiple lines, you *must* use \s, otherwise it is
syntactically invalid. (Weird, yes, I know. Guido has refused to make
this consistent on python-dev several times iirc.)

-- 
Ian Cordasco

__
OpenStack Development Mailing 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] Using \ for multiline statements

[Ian Cordasco]

On Thu, Dec 22, 2016 at 6:02 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
>>
>> By the way, can we finally all agree that commit message titles need to be a
>> proper ('merican) English grammatically correct sentence that begins with a
>> capital letter and ends with a period. And flavor is flavor, it's not
>> flavour.
>>
>> Happy holidays.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>
> Hah, now you're just trying to start the flames! :D

In my opinion, the Queen's English is imperially better... or is it
empirically? =P

As a side note, I could have sworn I remembered pep8/pycodestyle
warning on using backslashes instead of ()s but I seem to have been
wrong. All it warns about is using a backslash inside parentheses
because it's redundant.

As a maintainer of pycodestyle, I'd be happy to add one, especially
since the PEP-0008 document's preferred way is ()s [1]. That said,
it's possible that check was removed at some point and I'm just too
tired to do the archaeology for it. (It also might have been buggy at
the time.)

Either way, -1'ing over style issues is silly if the tool allows it
(or as is usually the case in OpenStack, is configured to allow it).
At that point it's subjective and a bit of a waste of people's time to
argue over it. From a perspective of personal preference, I prefer ()s
but that's just my $0.02.

[1]: https://www.python.org/dev/peps/pep-0008/#maximum-line-length
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

On Wed, Dec 21, 2016 at 11:20 PM, Zhenyu Zheng
<zhengzhenyul...@gmail.com> wrote:
> Agreed with Amrith, it might be useful and maybe also good for new
> contributors to learn how to have a commit to OpenStack. BUT over 130
> identical patches to 130 different projects from one company/person in one
> run? I don't think this is going to help OpenStack growing. We should not
> let this happen.
>
> On Thu, Dec 22, 2016 at 12:44 AM, Amrith Kumar <amr...@tesora.com> wrote:
>>
>> For those who would like to know exactly what this set of changes cost in
>> the CI, the answer is approximately 1050 jobs which consumed 190 compute
>> hours of CI time.
>>
>> -amrith
>>
>> -Original Message-
>> From: Amrith Kumar [mailto:amr...@tesora.com]
>> Sent: Wednesday, December 21, 2016 11:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
>> projects
>>
>> Ian, Andreas, Emilien,
>>
>> My sentiments on the subject of these kinds of "production line" changes
>> is unchanged from [1] and [2]. A complete list of these changes is at [3].
>>
>> I've updated all of the changes in this thread with a block comment and a
>> -1. My apologies to other reviewers (and active contributors in those
>> projects) for this automated comment across 131 commits.
>>
>> It is high time we eliminated these kinds of changes which do little to
>> improve the overall quality of the product and serve merely to generate a
>> huge amount of pointless work on the CI systems, and boost some meaningless
>> statistics that someone wants to put on a slide someplace.
>>
>> -amrith
>>
>> [1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
>> [2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
>> [3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

So, I want to reiterate why I started this thread:

I want a productive outcome of this contributor's efforts. -1'ing
everyone of their changes was not something I was looking for. Having
people pile on after those -1s is also not something that leads to a
productive outcome.

Yes, these mass produced changes are annoying. I get it. We're all a
little jaded, ostensibly because we've all seen the statistical
nonsense that people at our very own companies use for marketing or
whatever else. I understand it quite well.

All of that aside, I specifically asked that we not turn this thread into that.

There is some ambiguity right now with projects as to where to put
easy-to-find documentation (even if it is just a brief paragraph with
a link to longer-form documentation) into our repositories. Let's
focus on that discussion here. We can come up with a productive
conclusion and work with this contributor. While you've chosen (and
yes, you've chosen this) to have a negative assumption about this
contributor's efforts, I've chosen to believe they're looking to fill
a gap. Increasing the productivity of new contributors to OpenStack is
a positive improvement for our community. It may not fix a bug or add
a feature, but it helps ramp up the people who will do that.

So please, let's keep this productive. If you want to discuss ways of
ratelimiting patchset contributions or some other nonsense, please
start a new thread.

Cheers,
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [craton] [api] Pagination Specification

[Ian Cordasco]

Hey all,

As promised I've worked out a tiny, but hopefully informative,
pagination specification for Craton. It's available at
https://review.openstack.org/413735 and I might update it to include
more information as I go along today. Regardless, nothing is decided
in that. Following the spirit of our last specification, I've put all
our options into one place and once we've started to reject them we
can move them to the Alternatives section with explanations.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

-Original Message-
From: Andrey Kurilin <akuri...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 21, 2016 at 10:11:42
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> Hi stackers!
>  
> On Wed, Dec 21, 2016 at 5:33 PM, Emilien Macchi wrote:
>  
> > On Wed, Dec 21, 2016 at 10:22 AM, Ian Cordasco  
> > wrote:
> > > Hey everyone,
> > >
> > > It seems a contributor has written a script to add CONTRIBUTING.rst
> > > files to each OpenStack project that exists. [1]
> >
> > Thanks Ian for starting this discussion, it's very appreciated.
> >
> > It would have been great if the author of these patches would have run
> > this discussion before.
> > Just for Puppet OpenStack projects, it has consumed ~450 CI jobs
> > for... nothing (all patches will require some adjustments if we decide
> > to keep this file).
> >
>  
> You can configure your heavy jobs to not be launched on *.rst changes ;)
>  
>  
> > I can't imagine how many resources we consumed across all OpenStack
> > projects with this batch of patches...
> >
> > > As a community we've struggled with new contributors creating tonnes
> > > of patches like this at once, and that is emphatically not the purpose
> > > of this email. Instead, I'd like to discuss the actual merits of this
> > > change for OpenStack.
> > >
> > > What is CONTRIBUTING.rst?
> > > =
> > >
> > > It's a convention created by GitHub to make up for the lack of issue
> > > templating and encourage collaborators/contributors to read some
> > > documentation before filing new issues or pull requests. It does this
> > > by adding an unobtrusive link at the top of the New Issue and New Pull
> > > Request pages for projects that have these files.
> > >
> > > In my experience using these files on projects, they've been wildly
> > ineffective.
> > >
> > > Is there value in having a CONTRIBUTING.rst to OpenStack?
> > > =
> > >
> > > Well, let's consider a few things:
> > >
> > > * The canonical source for OpenStack repositories is
> > https://git.openstack.org/
> > > * OpenStack /mirrors/ to GitHub so when we add Badges to our README,
> > > they're displayed there for people who find the projects there
> >
>  
> Adding Badges is a sign that there are a lot of people who like finding
> everything in project
> repository.
> GitHub is just a mirror, but it is a first link of results list while
> googling, git.openstack.org is:
> - a second link in case of "openstack nova git" query;
> - a third link in case of "openstack keystone git;"
> - a fourth link in case of "openstack horizon git".
>  
> GitHub is a nice entry-point for new contributors. I do not want to say
> them
> "forget everything you know".

Except that learning to contribute to projects on GitHub is far from useful for 
them when looking at a project like ours or an Apache Software Foundation 
project or some of the projects open sourced by companies like Google.

> If CONTRIBUTING.rst is widely used and it can help newcomers, I'm for
> adding it.

Anecdotally speaking, it doesn't help new contributors though. Hence why I sent 
this email. If I felt it would have a measurable positive impact, I wouldn't 
have written this email. :)

> > > * OpenStack auto-closes all pull requests made to the GitHub mirrors
> > > with instructions on how to contribute
> > > * Having these files isn't really a *standard*. Other services
> > > (GitLab, BitBucket) have added support for these files, but when you
> > > look at projects not hosted on one of those service, these files
> > > aren't as common.
> >
>  
> If GitHub, GitLab, BitBucket support that file, having CONTRIBUTING.rst
> sounds like
> a standard for me.

That's not what defines a standard. One company coming up with a bandaid that a 
few others scrambled to support isn't a standard, it's a fad.

> > > * GitHub now allows the files that they look for to be in a .github
> > > directory so the root of the repository isn't cluttered with markdown
> > > and other files that only GitHub cares about for providing poorly made
> > > bandaids for serious issues in their platform.
> > >
> > > I'm not su

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

-Original Message-
From: Andrey Kurilin <akuri...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 21, 2016 at 10:13:09
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger wrote:
>  
> > On 2016-12-21 16:22, Ian Cordasco wrote:
> > > [...]
> > > That said, I think there are two better places for this information
> > > that are already standards in OpenStack:
> > >
> > > * README.rst
> > > * HACKING.rst
> > >
> > > Most projects include links to the contributing documentation in at
> > > least one of these files. I think the effort here is to standardize,
> > > albeit in a brand new file, and that's admirable.
> >
> > If that's the goal - to standardize - then I would expect that we move
> > all the documentation out of those files in one place.
> >
> > Right now, the changes duplicate information that exists - and the new
> > information is often wrong. It points to place that do not exist or
> > where better places exist. ;(
> >
>  
> Duplication can be reduced by using `.. include:: ` directive.

That does not render anywhere except our documentation (via Sphinx). 
Git{Hub,Lab} don't render the include directive at all.

So, no, that's not an option.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

 

-Original Message-
From: Andreas Jaeger <a...@suse.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 21, 2016 at 09:48:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>  
> If that's the goal - to standardize - then I would expect that we move
> all the documentation out of those files in one place. 

The best reasoning I can come up with for a mass number of changes like this is 
to standardize a bit. I could be entirely wrong, but sending these changes in 
the interest of standardization is the best possible assumption I can make 
about the contributor's intentions.

> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or
> where better places exist. ;(

I agree. This is why I've been -1'ing or -2'ing these patches on projects.

> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,

The status quo is far from perfect, but it seems to have worked well enough for 
a few years now.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [all] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

Hey everyone,

It seems a contributor has written a script to add CONTRIBUTING.rst
files to each OpenStack project that exists. [1]

As a community we've struggled with new contributors creating tonnes
of patches like this at once, and that is emphatically not the purpose
of this email. Instead, I'd like to discuss the actual merits of this
change for OpenStack.

What is CONTRIBUTING.rst?
=

It's a convention created by GitHub to make up for the lack of issue
templating and encourage collaborators/contributors to read some
documentation before filing new issues or pull requests. It does this
by adding an unobtrusive link at the top of the New Issue and New Pull
Request pages for projects that have these files.

In my experience using these files on projects, they've been wildly ineffective.

Is there value in having a CONTRIBUTING.rst to OpenStack?
=

Well, let's consider a few things:

* The canonical source for OpenStack repositories is https://git.openstack.org/
* OpenStack /mirrors/ to GitHub so when we add Badges to our README,
they're displayed there for people who find the projects there
* OpenStack auto-closes all pull requests made to the GitHub mirrors
with instructions on how to contribute
* Having these files isn't really a *standard*. Other services
(GitLab, BitBucket) have added support for these files, but when you
look at projects not hosted on one of those service, these files
aren't as common.
* GitHub now allows the files that they look for to be in a .github
directory so the root of the repository isn't cluttered with markdown
and other files that only GitHub cares about for providing poorly made
bandaids for serious issues in their platform.

I'm not sure there's a great deal of benefit to OpenStack projects in
these patches. I'm sure most of us don't ever look to see how many
pull requests get opened against the GitHub mirrors. I doubt these
files would stop anyone from sending pull requests there in the first
place (based entirely on my own, purely anecdotal experiences).

Further, OpenStack already has a great deal of cross-project and
project-specific documentation around contributing that's easily
findable. Making that slightly more discoverable probably isn't a bad
thing.

On top of that, some projects have had CONTRIBUTING.rst files for a
while (Glance's goes back at least to 2014). Standardization about
where to look for that info wouldn't hurt us at all.

That said, I think there are two better places for this information
that are already standards in OpenStack:

* README.rst
* HACKING.rst

Most projects include links to the contributing documentation in at
least one of these files. I think the effort here is to standardize,
albeit in a brand new file, and that's admirable.

If you look at the gerrit query, some projects have already merged or
abandoned some of the patches. Let's see if we can come to an
agreement about how to improve the experience for people finding our
projects and wanting to collaborate with us.

[1]: 
https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur.com+topic:addCONTRIBUTING.rst
--
Ian Cordasco

__
OpenStack Development Mailing 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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Ian Cordasco]

-Original Message-
From: Hongbin Lu <hongbin...@huawei.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 20, 2016 at 15:01:33
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [osc][openstackclient][zun] Collision on the
keyword 'container'

> Hi OpenStackClients Team,
>
> I am from the Zun team, and my team encountered a name collision issue when 
> implementing
> a OSC plugin [1]. We wanted to use the keyword 'container' to represent a 
> linux container
> used to host a containerized application. In particular, the commands our 
> contributor
> wanted to implement was listed in the etherpad [2]. Unfortunately, this 
> keyword has
> already been taken in OSC, so we need to figure out a short-term walk round 
> and a long-term
> solution. Below are the short-term solution I can think of:
>
> * openstack appcontainer
> * openstack linuxcontainer
> * openstack zun container
> * openstack containerservice container
> * openstack containermgmt container
>
> In the long-term, I am going to propose to follow the style of AWS CLI, that 
> is prefixing
> each command with a project name. For example:
>
> $ openstack swift container
> $ openstack zun container
> $ openstack barbican container

I would be strongly opposed to using project names (which are already
confusing enough to users) in the openstackcli. That's just taking
good UX and throwing it out.

> Or
>
> $ openstack objectstore container

$ openstack object container

That could work, but forcing users to have to learn a new path to the
same functionality is incredibly bad.

> $ openstack container container

And this explains to me, rather well, why this would be a bad idea.
"container container" is terrible UX.

> $ openstack secret container

I don't think using service names is going to work better either,
especially provided that to retrofit that would be a *severe* breaking
change.

> Thoughts?
>
> [1] https://review.openstack.org/#/c/411786/
> [2] https://etherpad.openstack.org/p/zunclient_openstack-client-cli
>
> Best regards,
> Hongbin
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

erences, but they did. Regardless of whether they intended to or not, the 
Kolla team is being told that was the *actual effect*. That means that Kolla 
*did* exclude people. Continuing to hold these meetings, means that whatever 
Kolla's intentions were doesn't matter because they have shown that "landing 
code" (or "velocity", or whatever you want to call it) is far more important 
than including the people who have chosen to tell us about their experiences.

No one is saying "Michał is evil" or "Michał is a bad person" or "Kolla is a 
contributor-hostile project". What we're saying is - Kolla did some things that 
excluded collaborators. Kolla has received feedback about those things. And 
Kolla should work to address that feedback. Unfortunately, all that's happened 
is that Kolla is defending its practices and stating rather adamantly that it 
intends to continue these exclusionary practices. Whatever the Kolla team's 
intentions going forward, they now know very well the harmful effects their 
actions may have on their colleagues.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Michał Jastrzębski <inc...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 17:20:21
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> I agree that meeting notes are crucial to this type of meeting.I just say
> that gerrit PoC/demo is valid form of 'notes' if meeting was about some
> implementional detail, which I assume is the case for this type of meetings.

It really isn't though. It only covers the conclusion. It doesn't explain how 
that conclusion was reached. By not providing that information, you are hiding 
the path to that conclusion from the rest of the community that could not 
participate in the meeting. By saying "the final patchset makes this obvious" 
you're excluding:

- Users who don't review the code
- Users who won't have time to dig through commit history to find the commit 
that may or may not have an accurate summary of how that conclusion was reached
- Fellow developers who can't attend the meetings based on time
- Fellow developers who can attend the meetings but can't follow them (for 
various reasons)

If it's just "some implementation detail" then I really don't understand why it 
is important enough to need several developers to join a video call. If it was 
important enough or controversial enough to need a collaboration that 
significant, it's worth documenting in a form other than the commit itself.

> Do we agree that as hoc hangout meetings are acceptable form of cooperation
> if invitation is own and notes are published?

Well I think we all agree that Google Hangouts aren't acceptable as they 
exclude residents of an entire nation.

I don't think anyone's against teams using impromptu video calls to help 
resolve conversations. I think each team needs to listen to its members, 
though, and respond to their concerns.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Michał Jastrzębski <inc...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 09:58:33
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> OK, I think we had some grave misunderstandings here.
>  
> 1. ad-hoc meetings *are not* and *were never meant to be* replacement
> for weekly meetings. Kolla community is single community across all
> its deliverables and we hold common meetings, chats and mailing list.
> Also, as long as I'm PTL, I'm unwilling to change that.

Unwilling to change holding video meetings that appear to be exclusive to 
members of your own community? If you're taking exclusionary actions as PTL, 
that seems like you're actively discouraging community involvement in the 
subject(s) of those meetings.

> 2. Hangouts were never exclusive purposefully. Meeting link was always
> posted on irc, and nobody were excluded apart from people not present
> on irc at given time.

Intent is not magical. The reality is that people have found them to be 
exclusive. So regardless of your intent, you need to find a better way to work 
around the communication problems or to make the results of the meeting more 
accessible.

> 3. Language barrier is something to acknowledge. I would say if we
> find ourselves in situation where one of hangout users has problem
> communicating, we either move to IRC or try hard to accommodate his or
> hers language barrier. But on few hangouts I was on, that was not the
> case. If somebody didn't join because they were ashamed, please, feel
> free to approach me on private message (or if I'm not around, hangout
> organizer) and let me know. That would be reason enough to stick to
> IRC in my book
> 4. Hangouts were never exclusive to core team. Just happened that core
> reviewers were majority of it - not planned or enforced.
> 5. Only "exclusiveness" I can think of in context of ad hoc meetings
> are that people who aren't around irc cannot have voice on this
> meeting. Simply because they aren't around and meeting was unplanned.
> That's the case with *any* discussion outside of dedicated 1hr every
> week. Granted, irc has logs. Hangouts can have notes, or outcome could
> be reflected as PoC in gerrit for example (which was the case of
> hangout in question..).
>  
> Ian, you mentioned that gerrit as outcome of hangout violates 4 opens...how?

The artifacts of any meeting should include meeting notes. IRC meetings have 
this autogenerated for us. Even if you send a summary to the mailing list saying

"Steve, Bob, and Michal were all on a call discussing this feature. We were 
having trouble agreeing between options x, y, and z. After chatting for 20 
minutes, we decided on this because of reasons a, b, and c. Review: 
https://review.openstack.org/:review_id has the final code details. Feel free 
to ping us on irc or the review with further questions."

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [glance] respecting glance priorities

[Ian Cordasco]

 

-Original Message-
From: Brian Rosmaita <rosmaita.foss...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 14:18:23
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance] respecting glance priorities

> Hello Glancers,
>  
> I realize that the weekly priority mailing is a new thing for us, so
> here's a quick reminder of how it works/what it's for.
>  
> Priorities are discussed and set at the weekly meeting and that gives us
> all some focus for what to do in the coming week.
>  
> If you're a glance core: please attend to these items first, before
> reviewing other items or merging other patches.
>  
> If you're not a glance core: priority items are important for the
> project, so a high quality review on them is a good way to get yourself
> noticed as an up-and-coming glance contributor.
>  
> These are called "priorities", not because they're the only things we're
> working on, but because we want to get them completed *first*.
>  
> If you have a patch that didn't make the list, keep in mind that
> OpenStack development is a community effort. If you review other
> people's patches, other people are more likely to review yours.
>  
> (And yes, what prompted this mailing is that I saw some patches merged
> while many of the items below have been languishing for want of
> attention. There are about 18 hours until the weekly Glance meeting, it
> would be nice to see them addressed. :) )
>  
> Here endeth the lesson.
>  
> cheers,
> brian
>  
>  
> On 12/9/16 7:14 AM, Brian Rosmaita wrote:
> > As discussed at the Glance weekly meeting yesterday, the priorities for
> > 12/1 through 12/8, unfortunately look very similar to last week's
> > priorities. Some core reviewers need to step up. The priorities are:
> >
> > Highest priority
> > 
> >
> > (1) database strategy for rolling upgrades:
> > https://review.openstack.org/#/c/331740/
> > This one has a video to enhance your reviewing pleasure and demonstrate
> > that the approach described actually is workable:
> > https://www.youtube.com/watch?v=Z4iwJRlPqOw
> >
> > (2) glance expand/contract migrations with alembic:
> > https://review.openstack.org/#/c/374278/
> > We need another +2 on this one, preferably from a non-Rackspace person.
> >
> > (3) community images spec update:
> > https://review.openstack.org/#/c/396919/
> > New to the list. The latest patch includes the migration strategy for
> > which Erno said indicated on the patch he'd change his -2 to a +2, so
> > don't let the -2 on the patch stop you from reviewing it.
> >
> > The above three specs need to be reviewed as soon as possible. We are
> > blocking Alex and Hemanth, because the Ocata database migration will
> > handle the community images changes.
> >
> >
> > Really high priority
> > 
> > (would be highest if the specs were already approved)
> >
> > (4) Patch to fix a glance_store regression:
> > https://review.openstack.org/#/c/387719/
> > and patch to prevent a related backend misconfiguration:
> > https://review.openstack.org/#/c/388944/
> >
> > (5) Patch to enable better request-id tracking:
> > https://review.openstack.org/#/c/352892/
> > This will be nice for operators, let's get it reviewed and merged!
> >
> > (6) Request for some insights and opinions for bug
> > https://bugs.launchpad.net/glance/+bug/1585917
> >
> >
> > Please take a look
> > ==
> >
> > (7) glanceclient problem: https://review.openstack.org/#/c/319960/
> >
> > thanks,
> > brian

Also worth noting that for community members with bugs/patches that are a 
priority to them, the correct place to lobby for that is in the weekly meeting. 

--  
Ian Cordasco
Release CPL/Czar

__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

-Original Message-
From: Ed Leafe <e...@leafe.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 08:08:33
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
> >
> > Taking you to the extreme of your statement, it seems there are several of 
> > these "ad hoc"  
> meetings a week (by inc0's admission). The video meetings seem to replace the 
> time that  
> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan to 
> solve for.
> >
> > Also, based on inc0's email, it seems that these meetings consistently are 
> > made up primarily  
> (if not singularly) of "cores". So they seem to be violating the open's in 
> that they're  
> effectively (even if not intentionally) creating a place where only 
> sub-groups of people  
> working on kolla (k8s) can collaborate.
> >
> > Further, the kolla team seems to think that code submissions sent after a 
> > meeting are  
> sufficient artifacts from the meeting, which there seems to be a majority who 
> feel otherwise.  
> Based on Jeffrey's descriptions, inc0's emails, and the rest of this thread, 
> it seems  
> quite clear that kolla isn't obeying one of the 4 opens.
>  
> Sorry, the conversation seems to have forked. The original issue was Kolla’s 
> practices,  
> which then forked into a more general discussion. I was responding to the 
> general side  
> of things: you can’t say that hangouts or hallway conversations are never 
> good things.  
> But when they are misused, as is described in the Kolla case, then yes, that 
> should not  
> be allowed to continue.

No worries. I was trying to bring us back to the Kolla case. If we want to 
discuss more general guidelines around this stuff, I'd rather not hijack this 
thread because it highlights serious problems in how Kolla is operating that a 
member of its team has brought up. I don't want us to side-track that 
conversation too severely. :)

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Ian Cordasco]

 

-Original Message-
From: Jeremy Stanley <fu...@yuggoth.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 08:30:22
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [release][ptl][all] self-service branch management

> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
>  
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

Awesome! Thank you so much for that answer. =D

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [release][ptl][all] self-service branch management

[Ian Cordasco]

-Original Message-
From: Doug Hellmann <d...@doughellmann.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 07:47:58
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [release][ptl][all] self-service branch management

> [Sending again due to mail delivery issues.]
>
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
>
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
>
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
>
> Thanks, as always, to the Infra team for their help in implementing
> this automation.
>
> Doug
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

This looks excellent, Doug!

Thank you Release & Infra teams!

I do have one question, will creating the branch's end-of-life
eventually work the same way? For example, Glance's projects were
missed in the recent liberty end of life work. Could we submit a
review to do that work so Josh & Tony don't have to or is that
something that isn't planned to work through openstack/releases?

Cheers,
--
Ian Cordasco

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

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Ian Cordasco]

-Original Message-
From: Joshua Hesketh <joshua.hesk...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 06:56:22
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, 
openstack-infra <openstack-in...@lists.openstack.org>
Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging 
liberty as EOL

> The repos listed[0] have had stable/liberty branch removed and replaced
> with a liberty-eol tag. Any open reviews have been abandoned.
>  
> Please let me know if there are any mistakes or latecomers to the list.
>  
> Cheers,
> Josh
>  
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>   

Glance was late to the party, but it should have had its liberty branches EOL'd 
as well.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

-Original Message-
From: Ed Leafe <e...@leafe.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 13, 2016 at 21:45:39
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> On Dec 12, 2016, at 10:30 PM, Steven Dake (stdake) wrote:
>  
> > The issue raised is they violate the 4 opens.
>  
> Not necessarily. If you have regular planning meetings and discussions in an 
> open manner  
> as prescribed, an occasional conference to discuss a particular matter is not 
> a "violation".  
> What if someone in your office is working on OpenStack too, and you meet in 
> the hallway  
> and discuss something technical? Does that violate the 4 Opens?
>  
> I think we have to balance realism with idealism.

Taking you to the extreme of your statement, it seems there are several of 
these "ad hoc" meetings a week (by inc0's admission). The video meetings seem 
to replace the time that sub-team is missing in the weekly IRC meeting, which 
Jeffrey has a plan to solve for.

Also, based on inc0's email, it seems that these meetings consistently are made 
up primarily (if not singularly) of "cores". So they seem to be violating the 
open's in that they're effectively (even if not intentionally) creating a place 
where only sub-groups of people working on kolla (k8s) can collaborate.

Further, the kolla team seems to think that code submissions sent after a 
meeting are sufficient artifacts from the meeting, which there seems to be a 
majority who feel otherwise. Based on Jeffrey's descriptions, inc0's emails, 
and the rest of this thread, it seems quite clear that kolla isn't obeying one 
of the 4 opens.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [glance] Propose Steve Lewis for Glance core

[Ian Cordasco]

+2 from me as well

On Dec 14, 2016 3:16 AM, "Erno Kuvaja"  wrote:

> On Tue, Dec 13, 2016 at 10:05 PM, Brian Rosmaita
>  wrote:
> > I'd like to propose Steve Lewis (stevelle on IRC) for Glance core.  Take
> > a look at any of his reviews, and you can see that he's thorough and
> > comprehensive in his reviewing.  He's knowledgeable about Python,
> > Glance, and software engineering in general.  He's gained a lot of
> > experience in various OpenStack projects (including experience as a core
> > reviewer), and will be a great addition to the Glance core reviewers
> team.
> >
> > If you have any concerns, please let me know.  I plan to add Steve to
> > the core list after this week's Glance meeting.
> >
> > thanks,
> > brian
> >
>
>
> Steve has been doing great job: +100!
>
> - jokke
>
> __
> OpenStack Development Mailing 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] [Release-job-failures] Release of openstack/glance failed

[Ian Cordasco]

 

-Original Message-
From: Andreas Jaeger <a...@suse.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 12, 2016 at 01:39:17
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [Release-job-failures] Release of 
openstack/glance failed

> On 2016-12-12 08:34, Andreas Jaeger wrote:
> > On 2016-12-12 06:20, Tony Breeds wrote:
> >> On Mon, Dec 12, 2016 at 04:44:18AM +, jenk...@openstack.org wrote:
> >>> Build failed.
> >>>
> >>> - glance-docs-ubuntu-xenial 
> >>> http://logs.openstack.org/38/38f199507aff8bfcaf81ad9ea58ea326224faf5f/release/glance-docs-ubuntu-xenial/de7d73e/
> >>>   
> : FAILURE in 1m 44s
> >>
> >> This boils down to [1] which is a known problem with newer cryptography 
> >> (and
> >> the interaction with openssl). What I don't understand is how we got there
> >> with constratints working[2]. Perhaps it's the openssl on the release 
> >> sigining
> >> node is "newer" than general nodepool nodes?
> >
> > glance does not use constraints in venv environment.
> >
> > It can be used since a few months. I'll send a change for master,
>  
> I expect this needs backporting to stable branches - stable or glance
> team, please review and backport yourself:
>  
> https://review.openstack.org/409642


Thank you Andreas!

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [craton] Meetings for 2016 Dec 19, 2016 Dec 26, and 2017 Jan 2 cancelled

[Ian Cordasco]

Hi Cratoneers! (Cratonistas? Cratoners? Cratons? I can never remember
what name we chose for ourselves...)

Most of the team will be taking holiday for some (if not all) of the
next two weeks, so we've decided to cancel the meetings scheduled for
then. Further, most businesses seem to be observing New Years on 2017
Jan 2 (meaning people will still be on vacation).

The next meeting will be 2017 Jan 9.

Happy New Year and Happy Holidays!
-- 
Ian Cordasco
Craton Core Reviewer

__
OpenStack Development Mailing 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] [Requirements] [Horizon] upper-constraints shenanigans and development milestones

[Ian Cordasco]

> On Dec 9, 2016, at 4:47 PM, Richard Jones  wrote:
> 
> Hi folks,
> 
> We in Horizon land are looking to update to a new version of one of
> our dependencies, Angular Bootstrap version 2.2.0. We do this through
> xstatic packaging, so the release we'll be making is actually
> xstatic-angular-bootstrap 2.2.0.0
> 
> This release is backward incompatible and breaks Horizon in many ways.
> We already have a compatibility patch in review to get us up to speed
> in Ocata, but prior versions of Horizon would break without
> upper-constraints protections. We've recently pushed through several
> changes to stable Mitaka to get those protections in place - Newton
> was already protected.
> 
> The problem is that we'll have two Ocata milestone releases out when
> 2.2.0.0 is released, and those will break because we currently pull in
> *master* upper-constraints for the milestone releases, rather than a
> stable/ocata branch of upper-constraints - there is no stable/ocata
> branch of upper-constraints yet.
> 
> Has the idea of branching at development milestones been raised previously?

Hi Richard :)

I'm not sure it has, but I'm rather certain it's not tenable. Now that you 
bring this up, Horizon isn't the only project that will get bit by this - 
Glance will too. (Until recently Glance's tests were not happy with the newest 
version(s) of oslo.log)

I don't think *branching* is the solution here, but perhaps tagging/releasing 
the requirements repository like we do other projects would be. That said, this 
introduces a significant amount more work for milestone releases. Here's how I 
imagine it would have to work:

openstack/requirements enters a freeze period leading up to a milestone. It 
tags it's Pike-1 milestone. This triggers the Requirements Bot to go around and 
update the constraints URL to the Pike-1 tag instead of "master". Once those 
are successfully merged, other projects releasing following the 
cycle-with-milestones release tag would then be able to create they own Pike-1 
tag. After a successful release, cores would have to update their tox.ini files 
to go back to master's constraints.

(And I'm not entirely certain we could get the proposal bot to ignore us 
switching constraints URLs back so that part may have to be manual too.)

The root of this discussion, however, seems to be around the idea that there 
are downstream consumers who are deploying OpenStack without 
distribution-provided packages (or using a deployment project) and who are 
using a rather naïve approach to dependency management. This is something that 
has come up within Glance as well recently (that each milestone needs to have 
certain restrictions).

Is there good evidence of this behavior anywhere? We've had trouble finding 
evidence of this happening in the real world with Glance and there's nothing in 
the project team guide that indicates the same level of support for milestone 
releases as for cycle releases.

--
Ian
__
OpenStack Development Mailing 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/mitaka CI failures (ImportError: No module named vine.five)

[Ian Cordasco]

-Original Message-
From: Gary Kotton <gkot...@vmware.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 8, 2016 at 12:59:07
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [all] stable/mitaka CI failures
(ImportError: No module named vine.five)

> Hi,
> Stable/mitaka is broken [1]. Any idea how to resolve this. Do the requiremets 
> need to
> pin a specific oslo.messaging version?
> Thanks
> Gary
>
> [1]
>
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py",
> line 1305, in patched
> return func(*args, **keywargs)
> File "vmware_nsx/tests/unit/dvs/test_plugin.py", line 55, in setUp
> super(DvsTestCase, self).setUp()
> File "/tmp/openstack/neutron/neutron/tests/base.py", line 271, in setUp
> self.setup_rpc_mocks()
> File "/tmp/openstack/neutron/neutron/tests/base.py", line 324, in 
> setup_rpc_mocks
> self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/oslo_messaging/conffixture.py",
> line 50, in __init__
> 'oslo_messaging_rabbit')
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/oslo_messaging/conffixture.py",
> line 25, in _import_opts
> __import__(module)
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py",
> line 30, in
> import kombu.connection
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/kombu/connection.py",
> line 15, in
> from kombu import exceptions
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/kombu/exceptions.py",
> line 8, in
> from kombu.five import python_2_unicode_compatible
> File 
> "/home/jenkins/workspace/gate-vmware-nsx-python27-db-ubuntu-trusty/.tox/py27/local/lib/python2.7/site-packages/kombu/five.py",
> line 6, in
> import vine.five
> ImportError: No module named vine.five

The problem is kombu 4.0.1. We encountered the same problem when 4.0.0
was released and the blacklist for that version was added.

If your project were using constraints, you would not run into this
problem. As such, what you need to do is wait for the blacklist to
pass master and be backported to the stable/mitaka branch in
openstack/requirements. The master patch has been approved and is
gating as I type this.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [glance] [stable] Liberty Periodic Failures (Was: [Openstack-stable-maint] Stable check of openstack/glance failed)

[Ian Cordasco]

This failure is caused by the fact Glance isn't using constraints on
stable/liberty. Matt is backporting those changes via:
https://review.openstack.org/#/q/topic:liberty-constraints

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.
<openstack-stable-ma...@lists.openstack.org>
Reply: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Date: December 8, 2016 at 00:50:33
To: openstack-stable-ma...@lists.openstack.org
<openstack-stable-ma...@lists.openstack.org>
Subject:  [Openstack-stable-maint] Stable check of openstack/glance failed

> Build failed.
>
> - periodic-glance-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-liberty/0720fcd/
> : SUCCESS in 4m 18s
> - periodic-glance-python27-db-liberty 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-liberty/8f68f87/
> : FAILURE in 45m 43s
> - periodic-glance-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-mitaka/43370a6/
> : FAILURE in 8m 12s
> - periodic-glance-python27-db-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-mitaka/404cb23/
> : SUCCESS in 6m 30s
> - periodic-glance-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-newton/c304f7c/
> : FAILURE in 4m 19s
> - periodic-glance-python27-db-newton 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-newton/7d0750b/
> : SUCCESS in 8m 21s

--
Ian Cordasco

__
OpenStack Development Mailing 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] Creating a new IRC meeting room ?

[Ian Cordasco]

 

-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 7, 2016 at 07:30:40
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Creating a new IRC meeting room ?

> Dolph Mathews wrote:
> > [...]
> > I think it honestly reflects our current breakdown of contributors &
> > collaboration. The artificial scarcity model only helps a vocal minority
> > with cross-project focus, and just results in odd meeting times for the
> > majority of projects that don't hold primetime meeting slots.
> >
> > While I don't think we should do away with meetings rooms, if a project
> > wants to hold meetings at a convenient time in their normal channel, I
> > think that's fine. Meeting conflicts will always exist. Major conflicts
> > will be resolved without the additional pressure of artificial scarcity.
>  
> I tend to agree with that. Like I said in my intro, we may be past the
> point where the artificial scarcity model is hurting us more than it
> helps us.
>  
> So how about:
> - we enable an #openstack-meeting-5 to instantly relieve scheduling pressure
> - we allow teams to hold meetings in their project channel if they want
> to (and show them all on the meeting agenda through the irc-meetings
> repo) as long as the channel is logged
> - we still generally recommend to use meeting rooms whenever possible,
> so that you can benefit from outside presence and easy mentions/pings
> - we will proactively add additional meeting rooms when the resource
> becomes scarce again

So I'm all for non-official projects using their own channels for meetings. My 
only wish (as someone working on a non-official project) would be that we could 
use meeting bot the same way we would in a meeting channel. If it requires 
standing up additional instances of the meeting bot, I think it's fair for the 
companies sponsoring those projects to help openstack-infra with that, and I'd 
be willing to throw my own time in there for that too if necessary.

> Options:
> - Once the change is in place, we could also limit official meeting room
> usage to official projects (since non-official projects can hold a
> meeting in their own room and still have it mentioned on the agenda)
> - If we remove artificial scarcity, we could discontinue the
> #openstack-meeting-cp channel (which was created to facilitate the
> scheduling of cross-project temporary meetings) and just tell
> cross-project initiatives to use the regular channels

I think there's still value in #openstack-meeting-cp, but I don't feel strongly 
enough to argue against its removal.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] Custom ProjectID upon creation

[Ian Cordasco]

-Original Message-
From: Andrey Grebennikov <agrebenni...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 5, 2016 at 12:22:09
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [keystone] Custom ProjectID upon creation

> Hi keystoners,

I'm not a keystoner, but I hope youu don't mind my replying.

> I'd like to open the discussion about the little feature which I'm trying
> to push forward for a while but I need some feedbacks/opinions/concerns
> regarding this.
> Here is the review I'm talking about https://review.
> openstack.org/#/c/403866/
>
> What I'm trying to cover is multi-region deployment, which includes
> geo-distributed cloud with independent Keystone in every region.
>
> There is a number of use cases for the change:
> 1. Allow users to re-use their tokens in all regions across the distributed
> cloud. With global authentication (LDAP backed) and same roles names this
> is only one missing piece which prevents the user to switch between regions
> even withing single Horizon session.

So this just doesn't sound right to me. You say above that there are
independent Keystone deployments in each region. What token type are
you using that each region could validate a token (assuming project
IDs that are identical across regions) that would do this for
"independent Keystone" deployments?

Specifically, let's presume you use Keystone's new default of fernet
tokens and you have independently deployed Keystone in each region.
Without synchronizing the keys Keystone uses to generate and validate
fernet tokens, I can't imagine how one token would work across all
regions. This sounds like a lofty goal.

Further, if Keystone is backed by LDAP, why are there projects being
created in the Keystone database at all? I thought using LDAP as a
backend would avoid that necessity. (Again, I'm not a keystone
developer ;))

> 2. Automated tools responsible for statistics collection may access all
> regions using one token (real customer's usecase)

Why can't the automated tools be updated to talk to each Keystone and
get a token while talking to that region?

> 3. Glance replication may happen because the images' parameter "owner"
> (which is a project) should be consistent across the regions.

So, Glance replication doesn't even guarantee identical image IDs
across regions. If Glance's replication isn't working because the
owner project is being synchronized directly, that sounds like a bug
in Glance, not Keystone.

> What I hear all time - "you have to replicate your database" which from the
> devops/deployment/operations perspective is totally wrong approach.

DevOps is a movement [1]. Replicating the database is not pleasant,
no, but it is your better option. I'll repeat, though, why is your
LDAP backed Keystone so reliant on Keystone's DB?

> If it is possible to avoid Galera replication over geographically
> distributed regions - then API calls should be used. Moreover, in case of 2
> DCs there will be an issue to decide which region has to take over when
> they are isolated from each other.
>
> There is a long conversation in the comments of the review, mainly with
> concerns from cores (purely developer's opinions).

You say that as if developer opinions (the folks who have to
understand and maintain your desired approach) is invalid or
worthless. That's not the case.

> Please help me to bring it to life ;)

Please give us more detail and convince us to help you. :)

[1]: https://theagileadmin.com/what-is-devops/

--
Ian Cordasco

__
OpenStack Development Mailing 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] [qa] Hacking 0.13.0 broken

[Ian Cordasco]

Hi all,

I would normally have brought this up at the QA team meeting but those
meetings are usually either quite late at night or quite early in the
morning for me and thus unattendable for me.

In the last couple weeks we've merged and released broken code that
had an underspecified use-case ostensibly because we all want to help
each other be more productive. That said, as one of the few people who
understands the interactions between what hacking uses (since Joe
left) it seems like we're not enforcing the same level of quality for
hacking that we do for other projects.

Because the use case is far too fuzzy, and the code broken (and the
code to fix it, further hardening our dependency on unsupported
versions of upstream dependencies) I'm strongly proposing we revert
the original change (https://review.openstack.org/407101).

We should be working with the upstream communities (like we used to)
and providing them with clear, unambiguous, narrowly defined use cases
that will convince them of the benefits of our feature requests.

Cheers,
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] [release] Release management team draft logo

[Ian Cordasco]

On Dec 2, 2016 3:07 AM, "Thierry Carrez"  wrote:
>
> Doug Hellmann wrote:
> > Release team, please take a look at the attached logo and let me know
> > what you think.
>
> It's not immediately obvious to me it's a shepherd dog, but then I don't
> exactly know how to make that more obvious

>From what I have observed, this had been the f feedback from several teams.
__
OpenStack Development Mailing 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] [glance][oslo] oslo.log 3.17.0 use_stderr default change

[Ian Cordasco]

-Original Message-
From: Tony Breeds <t...@bakeyournoodle.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>, OpenStack Development Mailing
List <openstack-dev@lists.openstack.org>
Date: November 28, 2016 at 00:19:36
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [glance][oslo] oslo.log 3.17.0 use_stderr
default change

> Hello Glance team!

Hello Tony!

> About a month ago the oslo team released 3.17.0 of oslo.log which contains [1]
> which switches the default for use_stderr from True to False. It hasn't made
> it into upper-constraints.txt because glance is failing[2]. There are 2 easy
> fixes:
>
> 1) switch the glance test to look at stdout rather then stderr ; or
> 2) update the glance config files to explictly set "use_stderr = true"
>
> I feel like Option 2 is correct as clearly preserves the existing behaviour 
> the
> operators/deployers can opt out if they want.

So, I'm not entirely certain we actually want use_stderr on for
everything by default. If you look at that failing test, it's
asserting there's stderr output from running one of Glance's
administrative commands (in this case glance-replicator, but it could
apply to any of the other ones). I think, what we *probably* want is
just to have stderr default to True for commands in glance.cmd
(probably excluding glance-api and glance-registry) so that operators
running those commands continue to see output.

I've been looking at this a little, and I think what we want is to do

   CONF.set_override(name='use_stderr',  default=True, enforce_type=True)

Does this sound reasonable to everyone else? If so, I already made
https://review.openstack.org/403775 which does this and adds an
upgrade release note to document the change.

I don't want it to be merged without appropriate discussion, so I've
-1'd the Workflow.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [kolla] the alternative of log processing tool

[Ian Cordasco]

File beat is maintained be elastic and a part of their product line just
like ELK. It's a fantastic tool and quite flexible given its age and size
of codebase

On Nov 26, 2016 11:59 PM, "Jeffrey Zhang"  wrote:

> Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we have
> a
> blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat.
>
> For Filebeat, it is just a replacement of logstash-forward[2]. It is not
> intent
> to replace the Logstash at all.
>
> > Filebeat is based on the Logstash Forwarder source code and replaces
> Logstash
> > Forwarder as the method to use for tailing log files and forwarding them
> to
> > Logstash.
>
> Fillebeat is a log transport tool rather than log processing too. I do not
> treat it as an alternative at all.
>
> To be honest, I'd like back to Logstash, and Logstash 5.x is released with
> high
> performance improvement[4].
>
> >  In our performance testing, we've seen consistent throughput increases
> >  across multiple configurations. In some cases, we observed up to 75%
> >  increase in events processed through Logstash.
>
> another benefit to using Logstash is the whole ELK stack is maintained by
> one
> community/company. It is well tested and easy to upgrade the whole stack
> at the
> same time. Using other tools may force us on certain elasticsearch release.
>
> So, I think we have to alternative tools.
>
> * Fluentd
> * Logstash
>
> IMO, we need to make the decision and at least prepare the migration
> solution now.
>
> [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation
> [2] https://www.elastic.co/guide/en/beats/filebeat/current/
> migrating-from-logstash-forwarder.html
> [3] http://www.fluentd.org/
> [4] https://www.elastic.co/blog/logstash-5-0-0-released
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Ian Cordasco]

-Original Message-
From: Dean Troyer <dtro...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 18, 2016 at 10:15:44
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [security] FIPS Compliance (Was: 
[requirements][kolla][security] pycrypto vs cryptography)

> > -Original Message-
> > From: Luke Hinds  
> [...]
> >> for non security related functions, but when it comes to government
> >> compliance and running OpenStack on public clouds (and even private for the
> >> Telcos / NFV), not meeting FIPS will in some cases block production getting
> >> a green light, or at least make it a big challenge to push through.
>  
> Are there any know cases of this happening? If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?

I too would be very interested in learning about these.

>  
> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco wrote:
> > Also, instead of creating bugs, I would suggest instead that we try to make 
> > this into  
> a community goal. We would work with the TC and for P or Q, make it a goal to 
> start migrating  
> off of MD5 and have a goal for a cycle or two later to completely remove 
> reliance on MD5.  
> >
> > Doing this piecemeal via bugs will not be efficient and we'll need 
> > community buy-in.  
>  
> We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>  
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.

Well it is easy for Glance (I even did a PoC sometime back). The problem with 
Glance, presently, is primarily the v1 API (the fact that it's deprecated and 
uses devices like Content-MD5 for metadata). After that we could absolutely 
return MD5 and SHA2 for a cycle or three. We would just need people integrating 
with Glance to them pick up the work.

If I remember correctly, Nova does some validation of the image based on hash 
value, and I would guess that the patch to use SHA2 when available would be 
somewhat easy. After that, it's the users writing integrations that we need to 
worry about. That's the biggest unknown piece of this puzzle to me. How many 
people integrate directly with Glance and how many of those rely on MD5 being 
the hash algorithm to determine the integrity of the image?

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

[Ian Cordasco]

 

-Original Message-
From: Luke Hinds <lhi...@redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 18, 2016 at 08:43:42
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] Fwd: Re: [requirements][kolla][security] pycrypto 
vs cryptography

> Hi,
>  
> I missed this thread, so top posting with a related topic..
>  
> We discussed FIPS 140-2 yesterday in the OSSP irc meeting.
>  
> I recently tried running OpenStack on a FIPS 140-2 enabled kernel in
> CentOS, and all of instances of MD5 use (mainly hashlib.md5) were rejected
> resulting in the various python scripts bailing out with a stack trace. As
> someone pointed out already, MD5 is considered weak, and does not meet the
> FIPS list of secure crypto. I understand some projects might well use MD5
> for non security related functions, but when it comes to government
> compliance and running OpenStack on public clouds (and even private for the
> Telcos / NFV), not meeting FIPS will in some cases block production getting
> a green light, or at least make it a big challenge to push through.
>  
> With this in mind, perhaps all projects should seriously consider migrating
> to more up to date methods such as sha256 or bcrypt, and start to
> depreciate MD5 use.
>  
> I proposed raising bugs on launchpad for each instance discovered, so that
> if anything, we at least have an idea of the extent of work needed to reach
> the needed level of compliance for FIPS 140-2.
>  
> Thoughts welcome?

Well, are they or aren't they? ;)

So, specifically talking to MD5, this is a thing I've been trying to convince 
Glance to move away from for a while. The problem we have is that we need a 
strong migration path. I suspect part of the use of MD5 initially in Glance is 
due to its age (although we already knew MD5 was weak when Glance became its 
own project) and partially due to the fact that lots of operators used Swift as 
a Glance storage mechanism.

As for deprecating MD5 in favor of other hash algorithms, I don't think we 
should just jump to the a new algorithm (SHA2 or bcrypt) because, for one 
thing, only one of those you mentioned is FIPS compliant iirc (SHA2). For 
another, is a hash really what we want to judge the integrity of all data? Are 
there not better mechanisms for this? Blake2 would be good and has variations 
that are optimized for different hardware types (but it's almost certain not 
FIPS).

On top of that, what does the migration path look like for services that use 
the MD5 sum to verify properties and integrity internally and return that using 
the `Content-MD5` header? There's no replacement for that header in the 
7230-7235 update of HTTP/1.1 and while we could make something up like 
`Content-SHA2` it probably will be confusing to users. (And no, using 
X-prefixed headers is no longer valid per RFCs and hasn't been for *years*.)

In short, I want to see us moving off MD5, but it will not be easy. I would bet 
that Glance and Swift will both be very resistant to this kind of change. We've 
had enough problems in Glance improving the usability of the *visibility* image 
attribute that I doubt we'd ever be able to migrate it to SHA2.

Also, instead of creating bugs, I would suggest instead that we try to make 
this into a community goal. We would work with the TC and for P or Q, make it a 
goal to start migrating off of MD5 and have a goal for a cycle or two later to 
completely remove reliance on MD5.

Doing this piecemeal via bugs will not be efficient and we'll need community 
buy-in.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] important changes to pep8 python jobs

[Ian Cordasco]

-Original Message-
From: Paul Belanger <pabelan...@redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 16, 2016 at 12:13:26
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] important changes to pep8 python jobs

> On Thu, Nov 03, 2016 at 12:29:09PM -0400, Paul Belanger wrote:
> > Greetings,
> >
> > We (openstack-infra) are proposing a change to the current pep8[1] job for
> > python jobs, and would like to bring your attention to it.
> >
> > We'll be removing the extra-index-url field from pip.conf which forces the 
> > job
> > to manually build any missing wheels as dependencies. The reason for this, 
> > is
> > to force a way for jobs to ensure the proper OS dependencies are installed.
> >
> > There is a chance your project pep8 job may break, which is why we are 
> > sending
> > out this email. We encourage each project to be using bindep[2], binary
> > dependency management tool, to ensure any OS packages are needed. If your
> > project needs a specific binary to be installed to compile your project, 
> > simply
> > add it to the bindep.txt file in your project repo.
> >
> > We'll be approving the change on Nov. 16, 2016 and send out another message 
> > as
> > we move closer to the date.
> >
> > If you have any questions, feel free to reply or use #openstack-infra on
> > freenode.
> >
> Greetings all,
>  
> We have just approved this change and it will be live shortly. Again, if you 
> are
> having problems, please join us in #openstack-infra.

Thank y'all for your hard work on this!

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [release] [glance] Immutability of migrations between beta releases

[Ian Cordasco]

Hi all,

Glance was hoping to include our Community Images feature work in
Ocata-1, but we have had some 11th hour communications about how
migrations will look to and affect end users and operators. For now,
we're not going to include that feature, but it raised a discussion
during our meeting today.

Some of our team members are under the impression that if we merge a
migration in Ocata-1, we can't then modify that migration in Ocata-2
or Ocata-3. We all agree that once 14.0.0 would be tagged and
released, we couldn't touch that migration script, but there is no
agreement about modifications between beta releases.

Does the release team have or TC guidelines about this? A search
hasn't turned up any documentation about this.

On the other hand, I did find
http://docs.openstack.org/project-team-guide/ptl.html?highlight=migration#at-the-beginning-of-a-new-cycle
which seems to allow for squashing a previous cycle's migrations at
the start of a cycle.

Help and opinions are appreciated,
--
Ian Cordasco
Glance Release Liaison

__
OpenStack Development Mailing 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] [glance] Flakey functional test (Was: [Openstack-stable-maint] Stable check of openstack/glance failed)

[Ian Cordasco]

-Original Message-
From: tomislav.suk...@telekom.de <tomislav.suk...@telekom.de>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 16, 2016 at 09:48:40
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance] Flakey functional test (Was: 
[Openstack-stable-maint] Stable check of openstack/glance failed)

> > > Since there's nothing pointing to any problems here, I would just ask is
> > > it possible that log file is not created if there's nothing to log?
> >
> > I don't think that's possible. We start glance's services (when under test)
> > with debug=True and verbose=True which means the config options that are
> > collected and then parsed should be logged to the file, at least.
>  
> It's true, in my case the log file has around 75kB. At least wsgi start is
> captured properly as INFO. However, parsing of configuration options is not
> there.
>  
> > > (and only if that is the case - I would suggest adding some dummy request
> > > Which would result in log entry; if not - please ignore this idea)
> >
> > Thanks for the help though, Tomislav! Did you look for the hash seed that
> > tox was using and try running the tests that way? I've been swamped with
> > other responsibilities this week so I haven't had time to investigate this
> > myself.
>  
> I tried with random seed (without specification), I tried with that specific
> seed and I tried both running all tests (py27) and just a specific one in
> both cases, all that several times. It just doesn't fail. I used Newton
> primarily but also tried on upstream version - just cannot reproduce.
> Although, the only difference which I see is that my machine is a bit slower,
> plus it uses only 2 workers.

Okay, we'll start keeping track of where these tests fail. We might be able to 
identify a specific provider and region and narrow this down to donated 
resources. Thanks Tomislav, you've been very helpful.

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [Craton] NFV planned host maintenance

[Ian Cordasco]

dmin should see link to external tool when querying services via services
> API. This might be formed like: {base URL}/{host_name}
> - Project should have a project specific link to external tool when querying
> via Nova servers API. This might be: {base URL}/project/{hostId}.
> hostId is exposed to project as it do not tell exact host, but otherwise as
> a unique identifier for host:
> hashlib.sha224(projectid + host_name).hexdigest()

I'm a little confused by these problems, so I'll have to re-read them
a few times and reply later.

Thanks again Tomi!

--
Ian Cordasco

__
OpenStack Development Mailing 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] [glance] Flakey functional test (Was: [Openstack-stable-maint] Stable check of openstack/glance failed)

[Ian Cordasco]

 

-Original Message-
From: tomislav.suk...@telekom.de <tomislav.suk...@telekom.de>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 16, 2016 at 07:46:18
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [glance] Flakey functional test (Was: 
[Openstack-stable-maint] Stable check of openstack/glance failed)

> > Hi Glance team members,
> >
> > Over the weekend one of our stable periodic jobs failed. It failed on
> > a test (glance.tests.functional.test_reload.TestReload.test_reload)
> > that I've seen fail a couple times previously. I've created a bug for
> > this: https://bugs.launchpad.net/glance/+bug/1641670 And I'm hoping
> > someone will be able to reproduce it and fix it.
> >
> > I suspect, this is a matter of resource contention in the donated VMs
> > that our CI uses, but I can't be certain.
> >
> > The stable team would greatly appreciate help diagnosing and fixing this 
> > issue.
>  
> Hi,
>  
> Even I was unable to reproduce the issue, I found something slightly odd.
> The reloaded log file is named etcnew.log and placed in the same directory
> as api.log, registry.log and others. Look like this is due to the name
> construction (in glance/tests/functional/test_reload.py:245):
>  
> conf_dir = os.path.join(self.test_dir, 'etc')
> log_file = conf_dir + 'new.log'
>  
> Although this might be nice to fix, it doesn't look like a problem to me.
>  
> Since there's nothing pointing to any problems here, I would just ask is
> it possible that log file is not created if there's nothing to log?

I don't think that's possible. We start glance's services (when under test) 
with debug=True and verbose=True which means the config options that are 
collected and then parsed should be logged to the file, at least.

> (and only if that is the case - I would suggest adding some dummy request
> Which would result in log entry; if not - please ignore this idea)

Thanks for the help though, Tomislav! Did you look for the hash seed that tox 
was using and try running the tests that way? I've been swamped with other 
responsibilities this week so I haven't had time to investigate this myself.

--  
Ian Cordasco


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

Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting

[Ian Cordasco]

 

-Original Message-
From: Ian Cordasco <sigmaviru...@gmail.com>
Reply: Ian Cordasco <sigmaviru...@gmail.com>
Date: November 16, 2016 at 07:06:27
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting
> -Original Message-
> From: Tony Breeds  
> Reply: OpenStack Development Mailing List (not for usage questions) ,  
> OpenStack Development Mailing List (not for usage questions)  
> Date: November 15, 2016 at 16:55:36
> To: OpenStack Development Mailing List (not for usage questions)  
> Subject: Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting
>  
> > On Tue, Nov 15, 2016 at 10:25:26AM -0800, Ian Cordasco wrote:
> > > Hi all,
> > >
> > > So the stable-maintenance team (and liaisons to it) have had a meeting
> > > scheduled for a while now. Recently, however, we've had trouble
> > > getting more than one person to attend meetings when we have them.
> >
> > I need to apologise for letting this happen.
>  
> I'd like to emphasize that I don't see this as any one person's fault. I just 
> was thinking  
> aloud about whether or not we find much use. We're not exactly a high 
> activity team and  
> we do communicate very well via this very medium.
>  
> > The current arrangement with 2
> > meetings US/EU and US/AU means that I can only attend the US/AU timeslot, 
> > and I
> > failed to set someone to run the US/EU meeting. I'd like to propose that we
> > switch the arrantment to:
> >
> > US/AU: #openstack-meeting-4 2100 UTC Monday (same time as now different 
> > room)
> > AU/EU: #openstack-meeting-4 1000 UTC Monday
>  
> This sounds fine to me. It might even be less confusing than having two 
> separate days and  
> channels too.
>  
> > Alternate weeks, although we *could* run both meetings on the same day every
> > 2nd week if people wanted.
> >
> > > I wonder if it would be more useful to less frequent meetings (perhaps
> > > every other week) and if we need to reschedule them to better serve
> > > those who plan to attend.
> >
> > As always it's a question of less often is harder to form a habit. I'd like 
> > to
> > request we try the new schedule until the PTG and then re-evaluate.
>  
> That sounds fine with me. I just wanted to gather some other feedback. :)

I submitted https://review.openstack.org/398363 so that folks can see how this 
translates to their calendar using the generated ics files.

Cheers!
--  
Ian Cordasco


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

Re: [openstack-dev] [api]

[Ian Cordasco]

If you're including me as a vote for nin, you should also consider me as a vote 
for not_in. Otherwise, count me as half a vote for either. I still think not_in 
is just ever-so slightly better than nin. 

-Original Message-
From: milanisko k <vetri...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: November 16, 2016 at 02:47:12
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [api]

> Guys,
>  
> thanks for the responses, so far we've got (if I'm not mistaken):
>  
> ?state=nin: 3 (including me)
> ?state=not_in: 1
> ?state=out: 0
> ?not_state=in: 0
>  
> I'd like to finish this poll by EOW so that more folks have the opportunity
> to express their preference.
>  
> Cheers,
> milan
>  
>  
> 2016-11-15 13:50 GMT+01:00 Miles Gould :
>  
> > On 14/11/16 20:52, Ian Cordasco wrote:
> >
> >> not_in is nice and explicit while nin and out are a bit, more clever. I
> >> think we should avoid trying to be clever.
> >>
> >
> > Agreed - I think not_in is more intelligible and guessable than the other
> > suggestions.
> >
> > Miles
> >
> >
> > __  
> > OpenStack Development Mailing 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
>  

--  
Ian Cordasco


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

Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting

[Ian Cordasco]

 

-Original Message-
From: Tony Breeds <t...@bakeyournoodle.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>, OpenStack Development Mailing List (not 
for usage questions) <openstack-dev@lists.openstack.org>
Date: November 15, 2016 at 16:55:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [Stable] Usefulness of Weekly Meeting

> On Tue, Nov 15, 2016 at 10:25:26AM -0800, Ian Cordasco wrote:
> > Hi all,
> >
> > So the stable-maintenance team (and liaisons to it) have had a meeting
> > scheduled for a while now. Recently, however, we've had trouble
> > getting more than one person to attend meetings when we have them.
>  
> I need to apologise for letting this happen.

I'd like to emphasize that I don't see this as any one person's fault. I just 
was thinking aloud about whether or not we find much use. We're not exactly a 
high activity team and we do communicate very well via this very medium.

> The current arrangement with 2
> meetings US/EU and US/AU means that I can only attend the US/AU timeslot, and 
> I
> failed to set someone to run the US/EU meeting. I'd like to propose that we
> switch the arrantment to:
>  
> US/AU: #openstack-meeting-4 2100 UTC Monday (same time as now different room)
> AU/EU: #openstack-meeting-4 1000 UTC Monday

This sounds fine to me. It might even be less confusing than having two 
separate days and channels too.

> Alternate weeks, although we *could* run both meetings on the same day every
> 2nd week if people wanted.
>  
> > I wonder if it would be more useful to less frequent meetings (perhaps
> > every other week) and if we need to reschedule them to better serve
> > those who plan to attend.
>  
> As always it's a question of less often is harder to form a habit. I'd like to
> request we try the new schedule until the PTG and then re-evaluate.

That sounds fine with me. I just wanted to gather some other feedback. :)

Cheers!
--  
Ian Cordasco


__
OpenStack Development Mailing 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] [Stable] Usefulness of Weekly Meeting

[Ian Cordasco]

Hi all,

So the stable-maintenance team (and liaisons to it) have had a meeting
scheduled for a while now. Recently, however, we've had trouble
getting more than one person to attend meetings when we have them.

I wonder if it would be more useful to less frequent meetings (perhaps
every other week) and if we need to reschedule them to better serve
those who plan to attend.

Cheers,
-- 
Ian Cordasco

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