Re: [openstack-dev] Propose changes of the core team

[Rikimaru Honjo]

Hi,

On 2017/10/13 18:39, Sam P wrote:

Hi All Masakari Cores,

  I would like to propose following changes to Masakari core team.

Current core team:
Masahito Muroi
Rikimaru Honjo
Sampath Priyankara (samP)
Takashi Kajinami
Toshikazu Ichikawa
Tushar Patil
Yukinori Sagara

(A) Proposed to remove from Core team:
(1) Toshikazu Ichikawa
  He was one of the initial members of the project and did a great work
on design the initial Masakari API and Masakari architecture.
However, he is no longer a active member of the community.
I would like to take this opportunity to thank Toshikazu for his work
on Masakari.

I will vote +1 if Toshikazu agrees this proposal.



(B) Confirm your availability as Core member:
  Following members, please confirm your ability to contribute to
Masakari in Queens and future cycles.
(1) Takashi Kajinami
(2) Masahito Muroi
I understand that you are extremely busy with other tasks or other projects
in OpenStack. If it is difficult for you to contribute to Masakari,
I suggest that you step down from core team for now. In future, if you are
wish to participate again, then we can discuss about reinstate you as a core
member of the team.

(C) Add to new members to core team:
(1) Adam Spiers (Suse)
   I would like to add  Adam to core team. He is the current maintainer
of the openstack-resource-agents and leader of the OpenStack HA team.
Considering his technical knowledge of the subject, and past work he
has done in Masakari and related work[1][2],
I think Adam is one of the best persons we can have in our team.

(2) Kengo Takahara (NTT-TX)
  Kengo has been an active contributor to the Masakari project from Newton
  and heavily contribute to crate masakari-monitors and python-masakariclient
  from scratch [3].

I vote +1 for each persons.
Because I've known their achievements.


All Masakari core members, please respond with your comments and objections.
Please cast your vote on (A) and (C).

[1] 
https://review.openstack.org/#/q/project:openstack/openstack-resource-agents-specs
[2] https://etherpad.openstack.org/p/newton-instance-ha
[3] 
http://stackalytics.com/?project_type=all=all=commits_id=takahara.kengo@as.ntts.co.jp

--- Regards,
Sampath

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




--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp




__
OpenStack Development Mailing 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] [puppet] Proposing Alfredo Moralejo core on puppet-openstack-integration

[钟生平]

+1

On Fri, Oct 13, 2017 at 1:21 PM, Emilien Macchi  wrote:
> Alfredo has been doing an incredible work on maintaining Puppet
> OpenStack CI; by always testing OpenStack from trunk and taking care
> of issues. He has been involved in fixing the actual CI problems in
> OpenStack projects but also maintaining puppet-openstack-integration
> repository in a consistent and solid manner.
> Also, he has an excellent understanding how things work in this
> project and I would like to propose him part of p-o-i maintainers
> (among the rest of the whole core team and also dmsimard).
>> As usual, feel free to vote and give feedback.
>> Thanks,
> --
> Emilien Macchi
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jeremy Stanley]

There is no Jenkins, only Zuul.

Zuul v3 rollout is complete as of 23:00 UTC. At that time, v2 jobs
reported by the "Jenkins" account ceased to be relevant, and v3 jobs
reported by the "Zuul" account are now used to determine whether
your changes can merge.

We have an expedited priority "infra-check" pipeline for changes to
the project-config repository so that emergency fixes for legacy
jobs can be merged quickly, and we'll be keeping this for some time
after the transition until it ceases to be necessary. If you're
still seeing any unexpected failures from migrated "legacy" jobs for
your projects and aren't immediately certain how to address these,
please bring them to our attention as soon as possible (in
#openstack-infra on the Freenode IRC network, or replying on-list to
this announcement) and we're happy to help you work on fixing them.
It also helps to get them onto the triage list we have been
maintaining here:

https://etherpad.openstack.org/p/zuulv3-issues

We're assembling a sort of FAQ in the migration guide:

https://docs.openstack.org/infra/manual/zuulv3.html

...and we also have some more content in progress at:

https://etherpad.openstack.org/p/zuulv3-migration-faq

Thanks for your patience throughout this process, and hopefully
you'll agree the new features were worth the wait!
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Dragonflow] Virtual PTG

[Omer Anson]

Hello, all.

A quick reminder that this exists.

The schedule is still here:
https://etherpad.openstack.org/p/dragonflow-queens . Video instructions
will be posted there as well.

Thanks,
Dragonflow team.

On 26 September 2017 at 22:21, Omer Anson  wrote:

> Hello, all.
>
> Since the Dragonflow team didn't hold any meetings during the last PTG, we
> thought of holding a virtual PTG with video streaming where others can join
> remotely.
>
> The dates are set for the 18th-19th October (2017, for those of us from
> the future). The times are flexible for now. The schedule is being
> constructed here[1]. So if a specific topic interests you, we can navigate
> the schedule so that it will be during relatively comfortable hours. Feel
> free to add topics, suggestions, requests, etc.
>
> The technical specifics on how to connect will be sent later.
>
> [1] https://etherpad.openstack.org/p/dragonflow-queens
>
> Thanks,
> Dragonflow team.
>
__
OpenStack Development Mailing 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][election] Question for all candidates in TC election: What will you do if you don't win?

[Paul Belanger]

On Sun, Oct 15, 2017 at 08:15:51AM -0400, Amrith Kumar wrote:
> Full disclosure, I'm running for election as well. I intend to also
> provide an answer to the question I pose here, one that I've posed
> before on #openstack-tc in an office hours session.
> 
> Question 1:
> 
> "There are M open slots for the TC and there are N (>>M) candidates
> for those open slots. This is a good problem to have, no doubt.
> Choice, is a good thing, enthusiasm and participation are good things.
> 
> But clearly, (N-M) candidates will not be elected.
> 
> If you are one of those (N-M) candidates, what then? What do you
> believe you can do if you are not elected to the TC, and what will you
> do? (concrete examples would be good)"
>
++

I'd like to see (N-M) candidates continue with TC by helping support M.
Personally, I plan on participating more in TC office hours regardless of
results. Or even reach out to TC and ask what non-TC members could do to help TC
more.

Once thing I've noticed in the question period before elections was 'What more
could the TC do'. I think it is also valid that we look at it the other way
around as 'What more could the non-TC member do' like Amrith asks above.

> Question 2:
> 
> "If you are one of the M elected candidates, the N-M candidates who
> were not elected represent a resource?
> 
> Would you look to leverage/exploit that resource, and if so, how?
> (concrete examples would be good)"
> 
Yah, I'd love to see 'pair programming' style for TC and non-TC memeber. Clearly
we have interested parties in becoming TC, and I would think the N-M candidates
would also try running again in 6 months.  So why not help those N-M member
become M, just like we do for non-core / core members on OpenStack projects.

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

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

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

[James Bottomley]

On Thu, 2017-10-12 at 12:51 -0400, Zane Bitter wrote:
> So my question to the TC candidates (and incumbent TC members, or
> anyone else, if they want to answer) is: what does the hypothetical
> OpenStack user that is top-of-mind in your head look like? Who are
> _you_ building OpenStack for?

There's a fundamental misconception in the way you just asked the
question: in any open source project the question "who am I building
this for?" and "who is my target end user?" aren't necessarily the
same.

The honest answer to "who am I building this open source project for?"
should always be "me".  There's nothing magical about this: all open
source/free software projects are driven by developer enthusiasm.  If
the reason you're in the project isn't something inside yourself (like
fascination with some aspect of the code or need to use it personally)
then you're unlikely to be a good contributor.  The principle is
actually universal: having been an engineering manager in industry I
know that if someone is only in the project for the paycheque then I
need to replace them ASAP with someone who's actually fascinated by
some aspect of the project because the productivity of the latter will
be way higher.  It's the most annoying aspect of Engineering Project
Management: engineers aren't fungible resources, they have enthusiasms
that have to be engaged.

There's a corollary to this that allows you to test the health of your
project: "If I weren't being paid to do this, would I still do it?".
 The majority answer for a healthy project should be "yes".  There's no
industrial counterpart here because if they don't pay you, you don't
get access to the code base.

The question of who is the end user is usually either "me" because you
have a use for the project or more likely "I don't know" because you
care mostly about the engineering aspects.  That's not to say that some
contributors can't get fascinated by user problems because it does
happen; however, it's not usually the majority.

User base tends to come about because of goal alignment: once a project
has a reasonable number of committers, feature addition becomes more a
matter of negotiation, but these negotiations tend to produce better
code and a set of common goals (the aligned goals of the contributors).
 Industrial contributors are attracted if some of the project goals
align reasonably with business goals and it looks like contribution
from the industry partner could achieve further alignment.  One of the
key goals of Industry is to get paid by consumers, so the Industrial
contributors tend to bring along the users (Again Industry does this by
canvassing end user requirements and seeing what the alignment with the
project is and whether it could be improved.  They don't do this for
"community" they do it because they make more money if the alignment is
better).  By the way, this pragmatic goal alignment without necessarily
sharing any philosophical belief in "code freedom" is the main
difference between open source and free software.

That's not to say every successful open source/free software project
has to have a large user base.  The Linux Desktop would be a classic
example here: excluding mobile, it's a complete failure in terms of
world domination of user base.  However, in terms of "built by geeks
for geeks" it's very much alive and healthy ... just look at the OS
running on laptops at any Linux conference, for instance.

James


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

[openstack-dev] [tc][election] Question for all candidates in TC election: What will you do if you don't win?

[Amrith Kumar]

Full disclosure, I'm running for election as well. I intend to also
provide an answer to the question I pose here, one that I've posed
before on #openstack-tc in an office hours session.

Question 1:

"There are M open slots for the TC and there are N (>>M) candidates
for those open slots. This is a good problem to have, no doubt.
Choice, is a good thing, enthusiasm and participation are good things.

But clearly, (N-M) candidates will not be elected.

If you are one of those (N-M) candidates, what then? What do you
believe you can do if you are not elected to the TC, and what will you
do? (concrete examples would be good)"

Question 2:

"If you are one of the M elected candidates, the N-M candidates who
were not elected represent a resource?

Would you look to leverage/exploit that resource, and if so, how?
(concrete examples would be good)"

-amrith

__
OpenStack Development Mailing 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][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Fri, Oct 13, 2017 at 2: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
>
> First, we need more data. We need a better gender study that doesn't rely
on first-name analysis and takes into account non-binary contributors. We
need data on who is participating from which country (I'm reasonably sure
this exists but I haven't found it published), what language they speak,
whether they are participating in IRC meetings and why or why not (time
zone problems? language barriers?). We need data on contribution by
ethnicity.

A major problem in the tech world is not just attracting underrepresented
contributors, but retaining them. They leave their communities or careers
because of bias problems. To my knowledge, that doesn't happen in
OpenStack, but just because I can't see it doesn't mean it's not there. A
long-term study of participation by underrepresented demographics will help
us answer this and fix it if necessary.

We do already know that we need to attract a more diverse contributor base.
To do that, we need to expand and support outreach programs, especially
things like Outreachy. It might not be a bad idea to start an
OpenStack-specific Outreachy-type thing. We need to offer more mentors to
the program so that we can support more interns.

We need to be friendlier to new people. You might have no idea how much a
negative interaction on your first patch or your first question in IRC can
frame your opinion of a community. A new person can't help but wonder if
they are being treated that way because they have a feminine IRC nick or
because their English wasn't good. I certainly think no one here tries to
be unfriendly but I'm sure we could all do better to keep it in mind. I
think Feilong's point about being publicly shamed for making a language and
culture mistake is especially unfriendly and an example of something we can
do better at.

Thanks for the great question.

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

[Colleen Murphy]

On Fri, Oct 13, 2017 at 9:21 PM, Zane Bitter  wrote:

> 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.
>
> 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.
>
> 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?
>
> 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 hypothetical OpenStack user
>> that is top-of-mind in your head look like? Who are _you_ building
>> OpenStack for?
>>
>> There's a description of mine in this email, as an example:
>> http://lists.openstack.org/pipermail/openstack-dev/2017-Octo
>> ber/123312.html
>>
>> To be clear, for me at least there's only one wrong answer ("person who
>> needs somewhere to run their IRC bouncer"). What's important in my opinion
>> is that we have a bunch of people with *different* answers on the TC,
>> because I think that will lead to better discussion and hopefully better
>> decisions.
>>
>> Discuss.
>>
>> cheers,
>> Zane.
>>
>
> What an interesting thread this has been. Thanks to Doug for speaking up -
it's unfair to pose a very general question, say "there are no wrong
answers", and then call everyone out for getting the answer wrong.

It's still a good question, though, since it was designed to expose the
fact that most of us are building clouds for operators, not