Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Erno Kuvaja]

On Fri, Oct 13, 2017 at 1:45 PM, Flavio Percoco  wrote:
> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe this
> is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all, how
> you
> think we could make our community more inclusive. What areas would you
> improve
> first?
>
> Thank you,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

First of all, I'm not running for the position, so if this is
inappropriate clutter by your view, skip and move on. I just think
this is big enough topic to chip into the conversation and if doing so
I get some of the current and/or future
community/tc/ member thinking, I've more than
succeeded.

We've been talking about how we need to be more welcoming, inclusive,
diverse and many more terms for achieving the same goal. And me if
anyone as a one of the cores for top help wanted list project should
be there in the front line yelling that we need more hands on the
deck. Yet still I think we're trying to solve wrong problem by saying
that we need to make OpenStack as welcoming as possible for everyone.

There has been raised few issues we can all more or less stand behind,
like Doug mentioning the -1s for typos, variable name disagreements
etc. I totally disagree with his solution. We have brilliant mechanism
to tackle that already, even the gerrit web ui provides one edit
directly on the review, but it's culturally "not ok to touch someone
else's patch (as this is individual contribution, not teamwork)". We
need cultural attitude change to fix many of these issues as it's not
the best usage of our gating nor reviewing resources to have yet
another patch there in the queue to fix that typo. We likely still can
all agree that the problem exists and is super annoying for everyone,
but it's just one small thing.

Taking that further we need to stop telling new contributors to find a
typo and fix it as their first commit. We (Glance team) have even set
disallowed change as part of our contribution guide for non-user
facing typo fixes as they really don't benefit anyone but makes more
work trying to keep the review queues in check and if one needs to
figure out when (and why) some change was made, that clutter is not
helpful in something like `git blame` either. That first commit is big
thing, no doubt, and it's even bigger and more hooking thing when you
actually do something meaningful with it! I still remember my fist
commit as it was just after feature freeze, agreed as exception
because it was part of making actually possible to run Images API v2.
If that patch was comment typo fix, I probably couldn't be proudly
telling about it now years later. That single word typo fix drowns so
easily into the queue and the person proposing it has likely moved on
week ago before the review is first time even eyeballed. This is
likely one of the reasons to what Amrith said seeing, so many one
commit contributors. The statistics does not tell how long it took to
get that first commit merged (even if it was only one revision) and if
the person was any way involved anymore when it did.

Fei Long mentioned that he had work for long time to get there and it
wasn't easy. It wasn't easy for me either when I joined, but guess
what, we're both still here! And we're both still working hard to
adjust ourselves and the community to be able to work effectively
together, That happened because we were motivated to be part of the
community, not just because it was made easy for us to so.

That leads to my point here. We have amazing community, by no means
it's perfect, but nevertheless we totally suck marketing it. I know
people who likes to work with OpenStack as it's cool technology but
don't want to deal with the bollox and politics in the community. And
it's really not that bad, but when ever we talk about these things
(publicly) we send out the message that we totally suck and we're
super hostile to get anyone joining and that's most important thing we
need to work on, time after time, year after year. If I was looking
this as outsider now I likely wouldn't want to make the effort when
the community itself claims that it sucks and it can't change in past
(or future) year(s).

What we really need to focus on is to get people _wanting_ to join us.
There is next to nothing easy in OpenStack with all it's complexity
and that's perfectly fine. Easy is not fun, we all want to challenge
ourselves. And we have amazing community to support those who wants to
join and make the difference. That is the group we need to grow and
when we run out of scalability of helping the 

[openstack-dev] [all][elections] Voting for the TC Election is now open

[Kendall Nelson]

Hello All,

Voting for the TC Election is now open and will remain open until 23:45
October 20th, 2017 UTC.

We are selecting 6 TC members, please rank all candidates in your order of
preference.

You are eligible to vote if you are a Foundation individual member[1] that
also has committed to one of the official programs projects[2] over
the Ocata-Pike timeframe (September, 2016 23:59 UTC to August 3rd , 2017
23:59 UTC or if you are one of the extra-atcs.[3]

What to do if you don't see the email and have a commit in at least one of
the official programs projects[2]:
* check the trash or spam folder of your gerrit Preferred Email address[4],
in case it went into trash or spam
* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the program project repos[2] and
email the election officials[1]. If we can confirm that you are entitled to
vote, we will add you to the voters list and you will be emailed a ballot.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote.

Candidate statements/platforms can be found linked to Candidate names[6].

Happy voting,
Thank you,

-Kendall Nelson (diablo_rojo)

[1]: http://www.openstack.org/community/members/
[2]:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections
[3]: Look for the extra-atcs element in [2]
[4]: Sign into review.openstack.org: Go to Settings > Contact Information.
Look at the email listed as your Preferred Email. That is where the ballot
has been sent.
[5]: http://governance.openstack.org/election/#election-officials
[6]: http://governance.openstack.org/election/#queens-tc-candidates
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400:
> Replying to myself here, to avoid singling anyone in particular out. I 
> want to rephrase the question, because people are overwhelmingly either 
> failing to understand or refusing to answer it in the way I intended it.
> 
> Most of the candidates are essentially saying that the answer is 'everyone'.
> 
> I'm glad that we have such a bunch of next-level geniuses running for 
> the TC that they are able to analyse the needs of all 7 billion people 
> and evaluate every decision they make against all of them in real time. 
> Me, I'm just an ordinary guy who can only hold a few things in his head 
> at once, so I just try to focus on those and collaborate with people who 
> have different perspectives to make sure that a range of needs are 
> covered. This is kind of the founding principle of the Open Source 
> (note: not Free Software) movement, actually. None of us is as smart as 
> all of us (present company excepted, apparently). So it's good, but 
> somewhat surprising that y'all are still here, given that you would be 
> guaranteed insta-billionaires if you went out and started a proprietary 
> software company.
> 
> All sarcasm aside though, 'everyone' is a BS non-answer. It's the 
> politician's answer.

Blaming the respondents for answering a imprecisely worded question
in a way other than it was intended? We can do better.

Your original question "Who are _you_ building OpenStack for?" was
much more vague than the rephrasing below that specifically asks
about advocacy. Even the rewritten question can be answered
legitimately using several different personas by people with a bit
of experience.  I have worked at a public cloud provider and two
distributors with a wide range of customers, and I use OpenStack
clouds myself. I hope that all of that background feeds into my
contributions.

> 
> Not only because engineering trade-offs are a real thing, and some use 
> cases will *definitely* be excluded in order to better serve others, but 
> because the average user doesn't exist. If you design for the 'average' 
> user then you are designing for nobody, because nobody is the average 
> user. We shouldn't be designing for 'everybody' (aka nobody in 
> particular), but for a large variety of somebodies.
> 
> As an example, look at the Keystone discussion that I linked below.
> - If you were designing Keystone for an individual user, you'd might 
> just have one account per tenant.
> - If you were designing Keystone for a team deploying semi-autonomous 
> apps, you might design a way for multiple agents to authenticate to each 
> tenant.
> - If you were designing Keystone for 'everyone', you might have a matrix 
> of users, tenants and roles - the most generic solution, right? - and 
> spend half a decade polishing it without ever realising that individual 
> users don't need it and teams can't use it.

Or you might conclude that the real problem isn't in the identity
service data model, but in the services that don't yet have an
operation to transfer ownership of resources when a user is
deactivated.

> 
> One of these solutions works for both individuals and teams. The other 
> two only work for individuals. As an added bonus, one of those is also 
> expensive to develop and hard to operate. That's why we should design 
> for someones, not for 'everyone'. This is not a problem limited to 
> Keystone - throughout OpenStack we often fail to develop solutions that 
> can actually be used by the people whom we say we're building them for, 
> IMHO.
> 
> I'm not asking y'all to say that some group of end-users is unimportant 
> even though the question is trying to keep the bar extremely low by 
> asking about only one group. Nor am I asking y'all to say that operators 
> are unimportant, even though the question is *explicitly* *NOT* about 
> operators.
> 
> I'm asking if you can describe, to a modest level of detail, even one 
> *end* user persona for OpenStack that you're familiar enough with to be 
> comfortable advocating for on the TC.
> 
> So far the answer I'm hearing mostly translates as 'no'. (Props to the 
> folks who did actually answer though!) Does anybody want to try again?

We have, so far, maintained an air of civility during "campaign season".
Let's try to stick to that, please.

Doug

> 
> cheers,
> Zane.
> 
> On 12/10/17 12:51, Zane Bitter wrote:
> > In my head, I have a mental picture of who I'm building OpenStack for. 
> > When I'm making design decisions I try to think about how it will affect 
> > these hypothetical near-future users. By 'users' here I mean end-users, 
> > the actual consumers of OpenStack APIs. What will it enable them to do? 
> > What will they have to work around? I think we probably all do this, at 
> > least subconsciously. (Free tip: try doing it consciously.)
> > 
> > So my question to the TC candidates (and incumbent TC members, or anyone 
> > else, if they want to answer) is: what does the 

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel returns

[Sam Matzek]

Thanks.  I will try to fix the legacy-trove-functional.

On Sat, Oct 14, 2017 at 12:58 AM, Andreas Jaeger  wrote:
> On 2017-10-14 03:30, Sam Matzek wrote:
>> The legacy-trove-functional-dsvm-mysql and
>> legacy-trove-legacy-functional-dsvm-mysql jobs are running the wrong
>> post_test_hook and have the trove-integration project in $PROJECTS.
>
> Looking at zuul/layout.yaml the change
> trove-legacy-functional-dsvm-mysql should only run on stable/newton -
> but trove-functional-dsvm-mysql on anything newer.
> done with https://review.openstack.org/511997 Fix trove
> legacy-trove-legacy-functional-dsvm-mysql
>
>> As such they will always vote -1. The functional integration tests
>> moved into Trove proper in Ocata.  I've added more details and links
>> to the zuulv3-issues etherpad.
>>
>> I'm not familiar enough with the job definitions to be able to work on
>> the fix reviews for these but would like to learn.
>
> Those are in openstack-zuul-jobs, the file is
> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy/trove-functional-dsvm-mysql/run.yaml.
>
> Do you want to fix it yourself and sync with the v2 version that is in
> project-config/jenkins/jobs/trove.yaml?
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>

__
OpenStack Development Mailing 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] (no subject)

[Trinath Somanchi]

What you really want to achieve ? What setup you are trying ?


Best Regards,
Trinath Somanchi | NXP | HSDC, INDIA

From: Raja Siddharth Raju [mailto:rsrajuoffic...@gmail.com]
Sent: Saturday, October 14, 2017 3:19 PM
To: openstack@lists.openstack.org
Subject: [Openstack] (no subject)


3:15 PM  I have been asked to.put host ip during installation of 
openstack . I am running ubuntu 16.43 in oracle virtual box.

Can you please help me with the solution ?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] (no subject)

[Raja Siddharth Raju]

3:15 PM ** I have been asked to.put host ip during installation
of openstack . I am running ubuntu 16.43 in oracle virtual box.

Can you please help me with the solution ?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Andrea Frittoli]

On Fri, Oct 13, 2017 at 1:46 PM Flavio Percoco  wrote:

> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe
> this is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all,
> how you
> think we could make our community more inclusive. What areas would you
> improve
> first?
>

Hi Flavio,

I'd continue promoting asynchronous communication, office hours and a good
use
of meetbot to generate good summaries (it's true that all IRC communication
is logged,
but it can be a lot of text to go through sometimes).

I'd propose we write training material on inclusiveness to be included in
the great work
of the upstream institute. We can use this to build and maintain awareness
in the
community.

It's important we don't think that training and educations are only for
new-comers into
the community. Especially after a few years in the community one may be
tempted
to fall into routines and/or preconceptions - it's important to keep an
open mind towards
people and ideas.

One idea that has been bouncing in mind is trainings for newly elected PTLs
or TCs or
any other interested individuals. I'm thinking especially of leaders since
their words
often bear a stronger impact on the community.

Perhaps self paced trainings where we present community guiding principles,
code of
conduct and vision or dedicated sessions at the PTG.

Faithfully,

Andrea Frittoli (andreaf)


> Thank you,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
> __
> OpenStack Development Mailing 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-Infra] Nominating new project-config and zuul job cores

[Andreas Jaeger]

On 2017-10-13 19:01, Jeremy Stanley wrote:
> On 2017-10-13 09:25:52 -0700 (-0700), Clark Boylan wrote:
>> I'd like to nominate a few people to be core on our job related
>> config repos.
> [...]
> 
> Count me heartily in favor of all four mentioned additions. They've
> been doing excellent work.

Fully agreed! count me in for these 4,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel returns

[Andreas Jaeger]

On 2017-10-14 03:30, Sam Matzek wrote:
> The legacy-trove-functional-dsvm-mysql and
> legacy-trove-legacy-functional-dsvm-mysql jobs are running the wrong
> post_test_hook and have the trove-integration project in $PROJECTS.

Looking at zuul/layout.yaml the change
trove-legacy-functional-dsvm-mysql should only run on stable/newton -
but trove-functional-dsvm-mysql on anything newer.
done with https://review.openstack.org/511997 Fix trove
legacy-trove-legacy-functional-dsvm-mysql

> As such they will always vote -1. The functional integration tests
> moved into Trove proper in Ocata.  I've added more details and links
> to the zuulv3-issues etherpad.
> 
> I'm not familiar enough with the job definitions to be able to work on
> the fix reviews for these but would like to learn.

Those are in openstack-zuul-jobs, the file is
http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/playbooks/legacy/trove-functional-dsvm-mysql/run.yaml.

Do you want to fix it yourself and sync with the v2 version that is in
project-config/jenkins/jobs/trove.yaml?

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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