Re: [openstack-dev] [designate] Meeting Times - change to office hours?

[Jens Harbott]

2018-04-23 13:11 GMT+02:00 Graham Hayes :
> Hi All,
>
> We moved our meeting time to 14:00UTC on Wednesdays, but attendance
> has been low, and it is also the middle of the night for one of our
> cores.
>
> I would like to suggest we have an office hours style meeting, with
> one in the UTC evening and one in the UTC morning.
>
> If this seems reasonable - when and what frequency should we do
> them? What times suit the current set of contributors?

My preferred range would be 06:00UTC-14:00UTC, Mon-Thu, though
extending a couple of hours in either direction might be possible for
me, too.

If we do alternating times, with the current amount of work happening
we maybe could make each of them monthly, so we end up with a roughly
bi-weekly schedule.

I also have a slight preference for continuing to use one of the
meeting channels as opposed to meeting in the designate channel, if
that is what "office hours style meeting" is meant to imply.

__
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] [tripleo] CI Community Meeting tomorrow (2018-04-24)

[Matt Young]

Greetings,

Tomorrow the CI team will be hosting its weekly Community Meeting. We
welcome any/all to join.  The meeting is a place to discuss any concerns /
questions / issues from the community regarding CI.

It will (as usual) be held immediately following the general #tripleo
meeting on BlueJeans [2], typically ~14:30 UTC.  Please feel free to add
items to the agenda [2] or simply come and chat.

Thanks,

Matt

[1] https://bluejeans.com/7050859455

[2] https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
__
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] [masakari] Introspective Instance Monitoring through QEMU Guest Agent

[Sam P]

Hi Louie,
 Thanks for bring this up.
 I add this topic to today's meeting agenda.

--- Regards,
Sampath


On Tue, Apr 24, 2018 at 5:15 AM, Kwan, Louie 
wrote:

> Submitted the following review on January 17, 2018,
>
> https://review.openstack.org/#/c/534958/
>
> Would like to know who else could be on the reviewer list ? or anything
> else is needed for the next step?
>
> Also, I am planning to attend our coming Masakari Weekly meeting,  April
> 24, 0400 UTC in #openstack-meeting
> and would like add an agenda item to  follow up how to move the  review
> forward.
>
> Thanks.
> Louie
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Public Cloud WG PTG Summary

[Zhipeng Huang]

Hi team,

Sorry for this long overdue summary. During the Dublin PTG as a WG we held
two successful discussion sessions on Mon and Tues, and below are the
conclusions for this year's planning as far as I could recall. Please feel
free to provide further feedback :)


   - Passport Program v2
  - We want to push forward the passport program into the v2 stage this
  year, including QR code promotion, more member clouds (APAC and North
  America) and possibly a blockchain experiment (cloud ledger proposal [0])
  targeting Berlin Summit if the testnet proves to be successful.
  - We will be also looking into the possibility of having OpenLab as a
  special member of Passport Program to help ease some of the
difficulties of
  purely business facing or academic clouds to join the initiative.
   -  Public Cloud Feature List
   - We will look at a more formal draft of the feature list [1] ready for
  Vancouver and gather some additional requirement at Vancouver
summit. It is
  also possible for us to do a white paper based upon the feature list
  content this year, to help user and operators alike better understanding
  what OpenStack public cloud could offer.
   - Public Cloud SDK Certification
  - Chris Hoge, Dims and Melvin have been helping putting up a testing
  plan for public cloud sdk certification based upon the initial
work OpenLab
  team has achieved. Public Cloud WG will provide a interop-like guideline
  based upon the testing mechanism.
   - Public Cloud Meetup
  - We look forward to have more :)

[0]
https://docs.google.com/presentation/d/1RYRq1YdYEoZ5KNKwlDDtnunMdoYRAHPjPslnng3VqcI/edit?usp=sharing


[1]
https://docs.google.com/spreadsheets/d/1Mf8OAyTzZxCKzYHMgBl-QK_2-XSycSkOjqCyMTIedkA/edit?usp=sharing


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [tripleo] roadmap on containers workflow

[Tony Breeds]

On Sun, Apr 15, 2018 at 07:24:58PM -0700, Emilien Macchi wrote:

> This patch: https://review.openstack.org/#/c/561377 is deploying Docker and
> Docker Registry v2 *before* containers deployment in the docker_steps.
> It's using the external_deploy_tasks interface that runs right after the
> host_prep_tasks, so still before starting containers.
> 
> It's using the Ansible role that was prototyped on Friday, please take a
> look and raise any concern.
> Now I would like to investigate how we can run container workflows between
> the deployment and docker and containers deployments.

This looks pretty good to me and if I understand correctly as it's
creating a v2 registry then we'll get manifest list images (for
multi-arch) by default which is a massive win for me.

Thanks Emilien
> -- 
> Emilien Macchi

> __
> 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

Yours Tony.


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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rochelle Grober]

Doug Hellmann wrote:
> I would like for us to collect some more data about what efforts teams are
> making with encouraging new contributors, and what seems to be working or
> not. In the past we've done pretty well at finding new techniques by
> experimenting within one team and then adapting the results to scale them
> out to other teams.
> 
> Does anyone have any examples of things that we ought to be trying more
> of?
> 

Okay, here I am sticking my foot in it after reading all the other excellent 
replies.  Lots of good suggestions.  Matt, Zane, Chris, Rico, etc.  Here are is 
another one:

I've noticed that as the projects mature, they have developed some new 
processes that are regular, but not daily.  Some are baked into the schedule, 
others are scheduled on a semi recurring basis but not "official.  One that 
I've seen a few times is the "bug swat day".  Some projects are scheduling 
triage and fix days throughout the cycle.  One project just decided to make it 
monthly.  This is great.  Invite Ops and users to participate.  Invite the 
folks who filed the bugs you might fix to participate.  Use IRC, paste and 
etherpad to develop the fixes and show the symptoms.  Maybe to develop the test 
to demonstrate the fix works, too.  If an operator really wants to see a bug 
fixed, they let the project know and let them know when she will turn up in IRC 
to help.  If they help enough, add them as co-owner of the patch.  Don't make 
them get all the accounts (if that's possible with Gerrit), just put their name 
on it.  They'll be overjoyed to both have the bug fixed *and* get some credit 
for stepping up.  This get devs, users and ops all on the same IRC page, 
focusing on enduser problems and collaborating on solutions in a regularly 
scheduled day(time) slot.  And the "needs more info" problem for bugs gets 
solved.

You can also invite everyone to Spec review days, or test writing days, or 
documentation days.  And you can invites students, academicians, etc.  If 
people know to show up, and they know *if* they show up *and* they are willing 
to discuss symptoms, ask questions, provide logs, whatever, that some pain in 
their butt will be closer to getting fixed, some will show up.  You give them 
credit and they'll feel even better showing up.

Not quite drive-by contributors, but it means pain points get addressed based 
on participation and existing contributors partner with the people who know the 
pain points to solve them.  On a regularly scheduled basis.  Oh, and you can 
put these days on the OpenStack event schedule, too.

--Rocky
__
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][Election] Rocky TC Election Voting Begins!

[Jeremy Stanley]

On 2018-04-24 00:03:55 + (+), Kendall Nelson wrote:
> The poll for the TC Election is now open and will remain open
> until Apr 30, 2018 23:45 UTC.
[...]

In finest OpenStack scaling tradition, we seem to have overloaded
CIVS with the volume of ballots we wanted to send and so ended up
readding around 15% (the ones which looked like they generated
errors according to the WebUI feedback). If you receive a second
ballot E-mail, you can discard it. They're just duplicates with the
same unique URL in them, so not good for a second vote. ;)
-- 
Jeremy Stanley


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

[openstack-dev] [All][Election] Rocky TC Election Voting Begins!

[Kendall Nelson]

 Hello Everyone!

The poll for the TC Election is now open and will remain open until Apr 30,
2018 23:45 UTC.

We are selecting 7 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
Pike-Queens timeframe (2017-02-21T23:59 to 2018-02-28T23:59) 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=apr-2018-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/#rocky-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] [tc] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

One more I'll add which is touched on a little below. Contributors spawn from a 
healthy Userbase/Operatorbase. If their needs are not met, then they go 
elsewhere and the contributor base shrinks. OpenStack has created artificial 
walls between the various Projects. It shows up, for example, as holes in 
usability at a user level or extra difficulty for operators juggling around so 
many projects. Users and for the most part, Operators don't really care about 
project organization, or ptls, or cores or such.  OpenStack has made some 
progress this direction with stuff like the unified cli. But OpenStack is not 
very unified. I think OpenStack, as a whole, needs to look at ways to minimize 
how its archetecture impacts Users/Operators so they don't continue to migrate 
to platforms that do minimize the stuff they have the operator/user deal with. 
One goes to a cloud so you don't have to deal so much with the details.

Thanks,
Kevin

_
___
From: Zane Bitter [zbit...@redhat.com]
Sent: Monday, April 23, 2018 1:47 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

On 23/04/18 10:06, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?

There's probably two separate groups we need to consider. The first is
operators and users of OpenStack. We want those folks to contribute when
they see a problem or an opportunity to improve, and their feedback is
extremely valuable because they know the product best. We need to
encourage new contributors in this group and retain existing ones by:

* Reducing barriers to contributing, like having to register for
multiple services, sign a CLA  We're mostly aware of the problems in
this area and have been making incremental progress on them over a long
period of time.

* Encouraging people to get involved. Low-hanging-fruit bug lists are
useful. Even something like a link on every docs page indicating where
to edit the source would help encourage people to take that first step.
(Technically we have this when you click the 'bug' link - but it's not
obvious, and you need to sign up for a Launchpad account to use it...
see above.) Once people have done the initial setup work for a first
patch, they're more likely to contribute again. The First Contact SIG is
doing great work in this area.

* The most important one: provide prompt, actionable feedback on
changes. Nothing kills contributor motivation like having your changes
ignored for months. Unfortunately this is also the hardest one to deal
with; the situation is different in every project, and much depends on
the amount of time available from the existing contributors. Adding more
core reviewers helps; finding ways to limit the proportion of the code
base that a core reviewer is responsible for (either by splitting up
repos or giving cores a specific area of responsibility in a repo) would
be one way to train them quicker.

Another way, which I already alluded to in my candidacy message, is to
expand the pool of OpenStack users. One of my goals is to make OpenStack
an attractive cloud platform to write applications against, and not
merely somewhere to get a VM to run your application in. If we can
achieve that we'll increase the market for OpenStack and hence the
number of users and thus potential contributors. But those new users
would be more motivated than anyone to find and fix bugs, and they're
already developers so they'd be disproportionately more likely to
contribute code in addition to documentation or bug reports (which are
also important contributions).


The second group is those who are paid specifically to spend a portion
of their time on upstream contribution, which brings us to...

> Where else should we be looking for contributors?

Companies who are making money from OpenStack! It's their responsibility
to maintain the commons and, collectively speaking at least, their
problem if they don't.

For a start, we need to convince anybody who is maintaining a fork of
OpenStack to do something more useful with 

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Bios interface support
- RPC Interfaces https://review.openstack.org/#/c/511714/
- Hardware type cleanup
- https://review.openstack.org/#/q/status:open+topic:hw-types
- Python-ironicclient things
- Accept a version on set_provision_state
- https://review.openstack.org/#/c/557850/
- Wire in header microversion into client negotiion
- https://review.openstack.org/#/c/558027/
- Remaining Rescue patches
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.) (Rebased by TheJulia 20180416)
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/
- Bug Fixes
- To be written:
- "periodic tasks of non-classic driver Interfaces aren't run" 
https://storyboard.openstack.org/#!/story/2001884
- Bifrost pip10 failure
- House Keeping:
- https://review.openstack.org/#/c/557441/ 2x+2 and +A, CI failure, 
rechecked.

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
None
irmc:
None - a few works are work in progress
oneview:
None at this time - No subteam at present.
xclarity:
Fix XClarity parameters discrepancy: 
https://review.openstack.org/#/c/561405/

Subproject priorities
-
bifrost:

ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- I still did not, may find some time this week
- Stats (diff between  12 Mar 2018 and 19 Mar 2018)
- Ironic: 225 bugs (+14) + 250 wishlist items (+2). 15 new (+10), 152 in 
progress, 1 critical, 36 high (+3) and 26 incomplete (+2)
- Inspector: 15 bugs (+1) + 26 wishlist items. 1 new (+1), 14 in progress, 0 
critical, 3 high and 4 incomplete
- Nova bugs with Ironic tag: 14 (-1). 1 new, 0 critical, 0 high
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/ MERGED - Backport to stable/queens 
proposed

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- spec for deployment steps framework has merged: 
https://review.openstack.org/#/c/549493/
- waiting for code from rloo, no timeframe yet

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 23 April 2018:
- Spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/generic-bios-config.html
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162
agreed that column type of bios setting value is string, blocked by the gate 
failure
- Add bios_interface db field https://review.openstack.org/528609   
   many +2s, can be merged soon after the patch above is merged
- BIOS Settings: Add DB API: https://review.openstack.org/511402
1x +1, actively reviewed and updated
- BIOS Settings: Add RPC object https://review.openstack.org/511714
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- story: https://storyboard.openstack.org/#!/story/2001795
- (april 23) spec has good feedback, one issue to resolve, should be able to 
land this week
- https://review.openstack.org/#/c/559420/

Reference architecture guide (dtantsur, jroll)
--
- story: https://storyboard.openstack.org/#!/story/2001745
- status as of 23 April 2018:
- Dublin PTG consensus was to start with small architectural building 
blocks.
- list of cases from the Denver PTG - 

Re: [openstack-dev] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Doug Hellmann]

Excerpts from Andrey Pavlov's message of 2018-04-23 21:42:56 +0300:
> Hello Sean,
> 
> EC2-api team always used manual tagging because I know only this procedure.
> I thought that it's more convenient for me cause I can manage
> commits/branches.
> But in fact I don't mind to switch to automatic scheme.
> If somethig else is needed from please let me know.
> 
> Regards,
> Andrey Pavlov.

You will still need to trigger tags, you will just do it in a different
way. See
http://git.openstack.org/cgit/openstack/releases/tree/README.rst for
details and drop in to #openstack-release or send email to this list
with the subject tag "[release]" if you have any questions.

Doug

> 
> >
> 
> Hello teams,
> 
> I am following up on some recently announced changes regarding governed
> projects and tagging rights. See [1] for background.
> 
> It was mostly followed before that when a project came under official
> governance that all tagging and releases would then move to using the
> openstack/releases repo and associated automation. It was not officially 
> stated
> until recently that this was one of the steps of coming under governance, so
> there were a few projects that became official but that continued to do their
> own releases.
> 
> We've cleaned up most projects' rights to push tags, but for the ones listed
> here we waited:
> 
> - rally
> - dragflow
> - ec2-api
> - networking-powervm
> - nova-powervm
> - yaql
> 
> We would like to finish cleaning up the ACLs for these, but I wanted to check
> with the teams to make sure there wasn't a reason why these repos had 
> continued
> tagging separately. Please let me know, either here or in the
> #openstack-release channel, if there is something we are overlooking.
> 
> Thanks for your attention.
> 
> ---
> Sean (smcginnis)

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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Arvind N]

>
> 1. Fail in the API saying you can't rebuild with a new image with new
> required traits.



Pros: - Simple way to keep the new image off a host that doesn't support it.
> - Similar solution to volume-backed rebuild with a new image.



Cons: - Confusing user experience since they might be able to rebuild with
> some new images but not others with no clear explanation about the
> difference.



Still want to get thoughts on Option 1 from the community, the only main
con can be addressed by a better error message.

My main concern is the amount of complexity being introduced now but also
what we are setting ourselfs up for the future.

When/If we decide to support forbidden traits, granular resource traits,
preferred traits etc based on image properties, we would have to handle all
those complexities for the rebuild case and possibly re-implement some of
the logic already within placement to handle these cases.

IMHO, i dont see a whole lot of benefit when weighing against the cost.
Feedback is appreciated. :)

Arvind

On Mon, Apr 23, 2018 at 3:02 PM, Eric Fried  wrote:

> > for the GET
> > /resource_providers?in_tree==, nested
> > resource providers and allocation pose a problem see #3 above.
>
> This *would* work as a quick up-front check as Jay described (if you get
> no results from this, you know that at least one of your image traits
> doesn't exist anywhere in the tree) except that it doesn't take sharing
> providers into account :(
>
> __
> 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
>



-- 
Arvind N
__
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] campaign question: How "active" should the TC be?

[Jeremy Stanley]

On 2018-04-23 16:56:28 -0500 (-0500), Sean McGinnis wrote:
[...]
> I think Howard had an excellent idea of the TC coming up with
> themes for each cycle. I think that could be used to create a good
> cadence or focus to make sure we are making progress in key areas.
> 
> It struck me that we came up with the long term vision, but there
> really isn't too much attention paid to it. At least not in a
> regular way that keeps some of these goals in mind.
> 
> We could use the idea of cycle themes to make sure we are
> targetting key areas of that long term vision to help us move
> towards bringing that vision to reality.

So (straw man!) we can make Rocky "the constellations cycle"?
-- 
Jeremy Stanley


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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Eric Fried]

> for the GET
> /resource_providers?in_tree==, nested
> resource providers and allocation pose a problem see #3 above.

This *would* work as a quick up-front check as Jay described (if you get
no results from this, you know that at least one of your image traits
doesn't exist anywhere in the tree) except that it doesn't take sharing
providers into account :(

__
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] ​ [mistral] timeout and retry

[Vitalii Solodilov]

Hi Renat, Can you explain me and Dougal how timeout policy should work with 
retry policy?

I guess there is bug right now.
The behaviour is something like this https://ibb.co/hhm0eH
Example: https://review.openstack.org/#/c/563759/ 
Logs: 
http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083
Even we will fix this bug and after task timeout we will not retry task. I 
don't understand which problem is decided by this timeout and retry.
Other problem. What about task retry? I mean using mistral api. The problem is 
that timeout delayed calls was not created.

IMHO the combination of these policies should work like this 
https://ibb.co/fe5tzH
It is not a timeout per action because when task retry it move to some complete 
state and then back to RUNNING state. And it will work fine with with-items 
policy.
The main advantage is executor and rabbitmq HA. I can specify small timeout if 
executor will die the task retried by timeout and create new action.
The second is predictable behaviour. When I specify timeout: 10 and 
retry.count: 5 I know that will be create maximum 5 action before SUCCESS state 
and every action will be executes no longer than 10 seconds.

-- 
Best regards,

Vitalii Solodilov


__
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] campaign question: How "active" should the TC be?

[Sean McGinnis]

> 
> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).
> 

I'm going to skip over some of the other questions in this one for now, but I
wanted to chime in on this one.

I think Howard had an excellent idea of the TC coming up with themes for each
cycle. I think that could be used to create a good cadence or focus to make
sure we are making progress in key areas.

It struck me that we came up with the long term vision, but there really isn't
too much attention paid to it. At least not in a regular way that keeps some of
these goals in mind.

We could use the idea of cycle themes to make sure we are targetting key areas
of that long term vision to help us move towards bringing that vision to
reality.

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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Arvind N]

Thanks for the detailed options Matt/eric/jay.

Just few of my thoughts,

For #1, we can make the explanation very clear that we rejected the request
because the original traits specified in the original image and the new
traits specified in the new image do not match and hence rebuild is not
supported.

For #2,

Other Cons:

   1. None of the filters currently make other API requests and my
   understanding is we want to avoid reintroducing such a pattern. But
   definitely workable solution.
   2. If the user disables the image properties filter, then traits based
   filtering will not be run in rebuild case

For #3,

Even though it handles the nested provider, there is a potential issue.

Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), another
one with some kind of offload feature(VF2).(Described by alex)

Initial instance launch happens with VF:1 allocated, rebuild launches with
modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the
instance to be allocated VF2.

But the original allocation happens against VF1 and since in rebuild the
original allocations are not changed, we have wrong allocations.

for #4, there is good amount of pushback against modifying the
allocation_candiadates api to not have resources.

Jay:
for the GET /resource_providers?in_tree==,
nested resource providers and allocation pose a problem see #3 above.

I will investigate erics option and update the spec.
-- 
Arvind N
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Jay Pipes]

On 04/23/2018 03:48 PM, Matt Riedemann wrote:
We seem to be at a bit of an impasse in this spec amendment [1] so I 
want to try and summarize the alternative solutions as I see them.


The overall goal of the blueprint is to allow defining traits via image 
properties, like flavor extra specs. Those image-defined traits are used 
to filter hosts during scheduling of the instance. During server create, 
that filtering happens during the normal "GET /allocation_candidates" 
call to placement.


The problem is during rebuild with a new image that specifies new 
required traits. A rebuild is not a move operation, but we run through 
the scheduler filters to make sure the new image (if one is specified), 
is valid for the host on which the instance is currently running.


What you are discussing above is simple a validation that the compute 
node performing the rebuild for an instance supports the capabilities 
that were required by the original image.


How about just having the conductor call GET 
/resource_providers?in_tree==, see if 
there is a result, and if not, don't even call the scheduler at all 
(because conductor would already know there would be a NoValidHost 
returned)?


If there's no image traits,  or if there is a result from GET 
/resource_providers, continue to do the existing call-the-scheduler 
behaviour in order to fulfill the ComputeCapabilitiesFilter and 
ImageMetadataFilter requirements that exist today.


So, in short, just do a quick pre-flight check from the conductor if 
image traits are found before ever calling the scheduler. Otherwise, 
proceed as normal.


Best,
-jay

__
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] [tripleo] Proposing Marius Cornea core on upgrade bits

[Emilien Macchi]

Thanks everyone for your positive feedback.
I've updated Gerrit!

Welcome Marius and thanks again for your hard work!

On Mon, Apr 23, 2018 at 4:55 AM, James Slagle 
wrote:

> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi 
> wrote:
> > Greetings,
> >
> > As you probably know mcornea on IRC, Marius Cornea has been contributing
> on
> > TripleO for a while, specially on the upgrade bits.
> > Part of the quality team, he's always testing real customer scenarios and
> > brings a lot of good feedback in his reviews, and quite often takes care
> of
> > fixing complex bugs when it comes to advanced upgrades scenarios.
> > He's very involved in tripleo-upgrade repository where he's already core,
> > but I think it's time to let him +2 on other tripleo repos for the
> patches
> > related to upgrades (we trust people's judgement for reviews).
> >
> > As usual, we'll vote!
> >
> > Thanks everyone for your feedback and thanks Marius for your hard work
> and
> > involvement in the project.
>
> +1
>
>
> --
> -- James Slagle
> --
>
> __
> 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
>



-- 
Emilien Macchi
__
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] [tripleo] Proposing Marius Cornea core on upgrade bits

[Alex Schultz]

+1

On Mon, Apr 23, 2018 at 5:55 AM, James Slagle  wrote:
> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi  wrote:
>> Greetings,
>>
>> As you probably know mcornea on IRC, Marius Cornea has been contributing on
>> TripleO for a while, specially on the upgrade bits.
>> Part of the quality team, he's always testing real customer scenarios and
>> brings a lot of good feedback in his reviews, and quite often takes care of
>> fixing complex bugs when it comes to advanced upgrades scenarios.
>> He's very involved in tripleo-upgrade repository where he's already core,
>> but I think it's time to let him +2 on other tripleo repos for the patches
>> related to upgrades (we trust people's judgement for reviews).
>>
>> As usual, we'll vote!
>>
>> Thanks everyone for your feedback and thanks Marius for your hard work and
>> involvement in the project.
>
> +1
>
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Eric Fried]

Following the discussion on IRC, here's what I think you need to do:

- Assuming the set of traits from your new image is called image_traits...
- Use GET /allocations/{instance_uuid} and pull out the set of all RP
UUIDs.  Let's call this instance_rp_uuids.
- Use the SchedulerReportClient.get_provider_tree_and_ensure_root method
[1] to populate and return the ProviderTree for the host.  (If we're
uncomfortable about the `ensure_root` bit, we can factor that away.)
Call this ptree.
- Collect all the traits in the RPs you've got allocated to your instance:

 traits_in_instance_rps = set()
 for rp_uuid in instance_rp_uuids:
 traits_in_instance_rps.update(ptree.data(rp_uuid).traits)

- See if any of your image traits are *not* in those RPs.

 missing_traits = image_traits - traits_in_instance_rps

- If there were any, it's a no go.

 if missing_traits:
 FAIL(_("The following traits were in the image but not in the
instance's RPs: %s") % ', '.join(missing_traits))

[1]
https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L986

On 04/23/2018 03:47 PM, Matt Riedemann wrote:
> On 4/23/2018 3:26 PM, Eric Fried wrote:
>> No, the question you're really asking in this case is, "Do the resource
>> providers in this tree contain (or not contain) these traits?"  Which to
>> me, translates directly to:
>>
>>   GET /resource_providers?in_tree=$rp_uuid={$TRAIT|!$TRAIT, ...}
>>
>> ...which we already support.  The answer is a list of providers. Compare
>> that to the providers from which resources are already allocated, and
>> Bob's your uncle.
> 
> OK and that will include filtering the required traits on nested
> providers in that tree rather than just against the root provider? If
> so, then yeah that sounds like an improvement on option 2 or 3 in my
> original email and resolves the issue without having to call (or change)
> "GET /allocation_candidates". I still think it should happen from within
> ImagePropertiesFilter, but that's an implementation detail.
> 

__
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] campaign question: How can we make contributing to OpenStack easier?

[Sean McGinnis]

> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
> 
> Which of those would you change, and how?
> 

Comparing OpenStack contribution to other open source projects, the biggest and
most obvious thing coming in to it is our use of gerrit vs GitHub pull
requests. For those used to contributing to other current large scale projects,
this can be a non-intuitive thing for them to learn. Luckily, I think we have a
lot of guidance documented on how our workflow works. And having worked with
both types of projects, I definitely would not propose or support moving away
from Gerrit, even with it's warts.

One of the bigger challenges I see for new or casual contributors is the
tendency for a lot of projects to only accept perfection. I don't know if this
is a side effect of the explosive growth years, something we have indirectly
encouraged with the way we do code reviews, or some other factor, but I have
seen plenty of patches proposed that are clear improvements, but get downvoted
for comment spelling, preferred variable naming, or other minor things that
either are not ultimately too important or would be easy to clean up with a
later patch.

I do think it's important we have high standards for new code accepted into our
projects. We need to make sure we are delivering high quality services and
tools. But for things that do not end up changing the end user or operator
experience of using OpenStack, I feel we need to be more relaxed. This can
easily change things for a new or casual contributor. They might get excited to
find something they can quickly change in the code to improve things, but then
get discouraged and leave and never come back if we make it look like we are
more concerned about grammatically correct code comments than functioning code.

I would also love to see more of our existing members spend time helping new
contributors. But I don't know how we can really change any policies to make
this more likely to happen. Speaking from experience, even for full time
contributors (or maybe especially for full time contributors?) we are usually
already busy with several other things that make it hard to carve out the time
to work with someone new. But I do feel it is an important way to welcome new
contributors and make sure it is not always the same folks overloaded on trying
to address several issues at the same time.

We do have some great work done with our onboarding documentation and our
regular events with the Upstream Institute. We just need to make some effort to
help consumers of those resources move on past that point.

Which makes me think of some of the discussion we've had about getting people
to core. I am actually not sure if this is the right focus. I do think it would
be great to have a lot of core members or potential candidates, but I think
there are plenty of contributors that would like to be involved and would be
able really help out projects without necessarily wanting or needing to be
cores to do so. I would like to see more focus on helping people contribute
without needing to commit to taking on more responsibilities.

> Where else should we be looking for contributors?
> 

Universities are a good one. And being an open source project in a relatively
easy to learn programming language, I think we could do more to encourage
formal programs with CS schools as something students could do. I've brought up
the idea of "internships" in the past. It would be great if we could work with
schools to set up some sort of program where we are able to help someone new
through accomplishing a discrete set up tasks that can benefit all involved.

I do think the majority of our resources will be through commercial interests
though, with vendors using or benefitting from OpenStack contributing
development, infrastructure, or testing to help the project continue to meet
their customers' needs. NFV is a big area now where I think there are some
resistant to changes being driven to meet their use cases, but I think it's
important that we are open to those types of changes in order for OpenStack to
be able to meet their needs.

Sean

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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

On 4/23/2018 3:26 PM, Eric Fried wrote:

No, the question you're really asking in this case is, "Do the resource
providers in this tree contain (or not contain) these traits?"  Which to
me, translates directly to:

  GET /resource_providers?in_tree=$rp_uuid={$TRAIT|!$TRAIT, ...}

...which we already support.  The answer is a list of providers. Compare
that to the providers from which resources are already allocated, and
Bob's your uncle.


OK and that will include filtering the required traits on nested 
providers in that tree rather than just against the root provider? If 
so, then yeah that sounds like an improvement on option 2 or 3 in my 
original email and resolves the issue without having to call (or change) 
"GET /allocation_candidates". I still think it should happen from within 
ImagePropertiesFilter, but that's an implementation detail.


--

Thanks,

Matt

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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zane Bitter]

On 23/04/18 10:06, Doug Hellmann wrote:

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

Over the last year we have seen some contraction in the number of
companies and individuals contributing to OpenStack. At the same
time we have started seeing contributions from other companies and
individuals. To some degree this contraction and shift in contributor
base is a natural outcome of changes in OpenStack itself along with
the rest of the technology industry, but as with any change it
raises questions about how and whether we can ensure a smooth
transition to a new steady state.

What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?

Which of those would you change, and how?


There's probably two separate groups we need to consider. The first is 
operators and users of OpenStack. We want those folks to contribute when 
they see a problem or an opportunity to improve, and their feedback is 
extremely valuable because they know the product best. We need to 
encourage new contributors in this group and retain existing ones by:


* Reducing barriers to contributing, like having to register for 
multiple services, sign a CLA  We're mostly aware of the problems in 
this area and have been making incremental progress on them over a long 
period of time.


* Encouraging people to get involved. Low-hanging-fruit bug lists are 
useful. Even something like a link on every docs page indicating where 
to edit the source would help encourage people to take that first step. 
(Technically we have this when you click the 'bug' link - but it's not 
obvious, and you need to sign up for a Launchpad account to use it... 
see above.) Once people have done the initial setup work for a first 
patch, they're more likely to contribute again. The First Contact SIG is 
doing great work in this area.


* The most important one: provide prompt, actionable feedback on 
changes. Nothing kills contributor motivation like having your changes 
ignored for months. Unfortunately this is also the hardest one to deal 
with; the situation is different in every project, and much depends on 
the amount of time available from the existing contributors. Adding more 
core reviewers helps; finding ways to limit the proportion of the code 
base that a core reviewer is responsible for (either by splitting up 
repos or giving cores a specific area of responsibility in a repo) would 
be one way to train them quicker.


Another way, which I already alluded to in my candidacy message, is to 
expand the pool of OpenStack users. One of my goals is to make OpenStack 
an attractive cloud platform to write applications against, and not 
merely somewhere to get a VM to run your application in. If we can 
achieve that we'll increase the market for OpenStack and hence the 
number of users and thus potential contributors. But those new users 
would be more motivated than anyone to find and fix bugs, and they're 
already developers so they'd be disproportionately more likely to 
contribute code in addition to documentation or bug reports (which are 
also important contributions).



The second group is those who are paid specifically to spend a portion 
of their time on upstream contribution, which brings us to...



Where else should we be looking for contributors?


Companies who are making money from OpenStack! It's their responsibility 
to maintain the commons and, collectively speaking at least, their 
problem if they don't.


For a start, we need to convince anybody who is maintaining a fork of 
OpenStack to do something more useful with their money. Like, for 
example, building it into a big pile and setting fire to it to keep warm.


Maybe education is something that can help here. For a lot of folks, 
OpenStack is their first direct contact with an open source community. 
If we could help them to learn why contributing is in their best 
interest, and how to do it effectively, then we could make some 
progress. It's pretty remarkable that there are Foundation board members 
still asking the TC to direct employees of other companies to work on 
the stuff they want them to for free.


cheers,
Zane.

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

[openstack-dev] [nova] Do we need bp/list-show-all-server-migration-types?

[Matt Riedemann]

Looking over the things in the runways queue [1], excluding the zVM 
driver (because I'm not sure what the status is on that thread), the 
next in line is blueprint list-show-all-server-migration-types [2].


I know this has been approved since Pike, but I wanted to raise some 
questions again [3] about whether or not we actually need this.


Looking at the spec, the problem description is totally tied to the 
abort in-progress cold migration blueprint [4] which we haven't agreed 
to do. We talked about that blueprint at the PTG in Dublin and the 
action item [5] was for Takashi to follow up in the mailing list (dev 
and operators) to determine if that is functionality people actually 
need. I haven't seen that happen yet.


If we aren't going to add the ability to abort a cold migration, I'm not 
sure why we need list-show-all-server-migration-types. The use case in 
the spec is something an admin can do today with the GET /os-migrations 
API [6]. That should at least be an alternative in the spec.


So beyond being a dependency to abort an in-progress cold migration, 
what would be the other reasons for 
list-show-all-server-migration-types? Because if that is the only thing, 
I think it likely should be held up and dependent on [4] being approved, 
otherwise I feel it's churn for little gain. If there are other reasons 
for this beyond a dependency for abort cold migration, the spec should 
likely be updated to clearly indicate what they are.


[1] https://etherpad.openstack.org/p/nova-runways-rocky
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/list-show-all-server-migration-types.html
[3] 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115494.html

[4] https://blueprints.launchpad.net/nova/+spec/abort-cold-migration
[5] https://etherpad.openstack.org/p/nova-ptg-rocky (L362)
[6] https://developer.openstack.org/api-ref/compute/#list-migrations

--

Thanks,

Matt

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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Mohammed Naser]

On Mon, Apr 23, 2018 at 10:06 AM, Doug Hellmann  wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?

I think that for the most part, the most vocal audience is the one
that contributes the most is
mostly very comfortable with the tools and processes that we have in
place today.  However,
I think we may have become 'blind' to the viewpoint of new
contributors and forgot some of
our habits might be very difficult pain points for other users.

## Communication

There is a significant amount of communication and work that happens
over IRC.  I'll admit,
it's one of my most preferable ways of communicating.  However, it's
not something that
is common for newer contributors to use.  Our developer manual lists
it before anything:

https://docs.openstack.org/infra/manual/developers.html#irc-account

There are a few other communities which are growing quickly and
they're using alternative
ways of communication.  I personally prefer  IRC, but maybe we should
put our preferences
aside and look at what's sustainable, because we have to be
progressive and move quickly.

Perhaps we should look into a OpenStack Slack community in combination
with an IRC
bridge?

 ## Tooling

The majority of long time OpenStack contributors are very comfortable
with the Gerrit
workflow.  They're also very comfortable with rebasing patches,
pushing them, setting
up dependencies, etc.

The newer developer might have some Gerrit experience but more than
likely, they might
probably have more of a GitHub workflow experience and that's the
easiest way that
the can submit code.

While my own preference is to use Gerrit, I think that perhaps looking
into opening up a
way for contributions via GitHub to be available could be an
interesting option.  Now, the
technical side of me can imagine all the challenges, but again, we
must keep things easy
and approachable.

If submitting a patch to the OpenStack community involves setting up
an account in the
Canonical "Ubuntu One" OpenID, creating a username in Gerrit
afterwards, sign the CLA,
which could get complicated depending on your organization, upload
your keys, setup
git-review before being able to push up a single patch (and then
there's Launchpad for
bugs and some projects are on Storyboard, etc)

That's a lot of extra work that we're putting on new potential
contributors.  I don't mind it,
but I think we have to collectively think about new potential
contributors rather than
our preferences.

I'm giving a lot of ideas that I might not have technical solutions in
place, but I think putting
them out might bring up some other ways that we can come to a
compromise and make it work
to make contributing to OpenStack easy.

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

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

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Eric Fried]

Semantically, GET /allocation_candidates where we don't actually want to
allocate anything (i.e. we don't want to use the returned candidates) is
goofy, and talking about what the result would look like when there's no
`resources` is going to spider into some weird questions.

Like what does the response payload look like?  In the "good" scenario,
you would be expecting an allocation_request like:

"allocations": {
$rp_uuid: {
"resources": {
# Nada
}
},
}

...which is something we discussed recently [1] in relation to "anchor"
providers, and killed.

No, the question you're really asking in this case is, "Do the resource
providers in this tree contain (or not contain) these traits?"  Which to
me, translates directly to:

 GET /resource_providers?in_tree=$rp_uuid={$TRAIT|!$TRAIT, ...}

...which we already support.  The answer is a list of providers. Compare
that to the providers from which resources are already allocated, and
Bob's your uncle.

(I do find it messy/weird that the required/forbidden traits in the
image meta are supposed to apply *anywhere* in the provider tree.  But I
get that that's probably going to make the most sense.)

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129408.html

On 04/23/2018 02:48 PM, Matt Riedemann wrote:
> We seem to be at a bit of an impasse in this spec amendment [1] so I
> want to try and summarize the alternative solutions as I see them.
> 
> The overall goal of the blueprint is to allow defining traits via image
> properties, like flavor extra specs. Those image-defined traits are used
> to filter hosts during scheduling of the instance. During server create,
> that filtering happens during the normal "GET /allocation_candidates"
> call to placement.
> 
> The problem is during rebuild with a new image that specifies new
> required traits. A rebuild is not a move operation, but we run through
> the scheduler filters to make sure the new image (if one is specified),
> is valid for the host on which the instance is currently running.
> 
> We don't currently call "GET /allocation_candidates" during rebuild
> because that could inadvertently filter out the host we know we need
> [2]. Also, since flavors don't change for rebuild, we haven't had a need
> for getting allocation candidates during rebuild since we're not
> allocating new resources (pretend bug 1763766 [3] does not exist for now).
> 
> Now that we know the problem, here are some of the solutions that have
> been discussed in the spec amendment, again, only for rebuild with a new
> image that has new traits:
> 
> 1. Fail in the API saying you can't rebuild with a new image with new
> required traits.
> 
> Pros:
> 
> - Simple way to keep the new image off a host that doesn't support it.
> - Similar solution to volume-backed rebuild with a new image.
> 
> Cons:
> 
> - Confusing user experience since they might be able to rebuild with
> some new images but not others with no clear explanation about the
> difference.
> 
> 2. Have the ImagePropertiesFilter call "GET
> /resource_providers/{rp_uuid}/traits" and compare the compute node root
> provider traits against the new image's required traits.
> 
> Pros:
> 
> - Avoids having to call "GET /allocation_candidates" during rebuild.
> - Simple way to compare the required image traits against the compute
> node provider traits.
> 
> Cons:
> 
> - Does not account for nested providers so the scheduler could reject
> the image due to its required traits which actually apply to a nested
> provider in the tree. This is somewhat related to bug 1763766.
> 
> 3. Slight variation on #2 except build a set of all traits from all
> providers in the same tree.
> 
> Pros:
> 
> - Handles the nested provider traits issue from #2.
> 
> Cons:
> 
> - Duplicates filtering in ImagePropertiesFilter that could otherwise
> happen in "GET /allocation_candidates".
> 
> 4. Add a microversion to change "GET /allocation_candidates" to make two
> changes:
> 
> a) Add an "in_tree" filter like in "GET /resource_providers". This would
> be needed to limit the scope of what gets returned since we know we only
> want to check against one specific host (the current host for the
> instance).
> 
> b) Make "resources" optional since on a rebuild we don't want to
> allocate new resources (again, notwithstanding bug 1763766).
> 
> Pros:
> 
> - We can call "GET /allocation_candidates?in_tree= UUID>=" and if nothing is returned,
> we know the new image's required traits don't work with the current node.
> - The filtering is baked into "GET /allocation_candidates" and not
> client-side in ImagePropertiesFilter.
> 
> Cons:
> 
> - Changes to the "GET /allocation_candidates" API which is going to be
> more complicated and more up-front work, but I don't have a good idea of
> how hard this would be to add since we already have the same "in_tree"
> logic in "GET 

[openstack-dev] [masakari] Introspective Instance Monitoring through QEMU Guest Agent

[Kwan, Louie]

Submitted the following review on January 17, 2018,

https://review.openstack.org/#/c/534958/

Would like to know who else could be on the reviewer list ? or anything else is 
needed for the next step?

Also, I am planning to attend our coming Masakari Weekly meeting,  April 24, 
0400 UTC in #openstack-meeting  
and would like add an agenda item to  follow up how to move the  review forward.

Thanks.
Louie

__
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] [ceilometer] Ceilometer-file-publisher-compression-csv-format

[Kwan, Louie]

Submitted the following review on April 19, 

https://review.openstack.org/#/c/562768/

Would like to know who else could be on the reviewer list and anything else for 
the next step?

Thanks.
Louie
__
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] [horizon] Release of openstack/xstatic-angular-vis failed

[Andreas Jaeger]

On 2018-04-23 21:45, Sean McGinnis wrote:
> See below for logs from a failed xstatic release job. It appears something is
> not set up right with this job.
> 
> "can't open file 'xstatic_check_version.py': [Errno 2] No such file or
> directory"
> 
> I missed it initially, but this release did not actually contain any 
> functional
> change, so I think it is fine that it failed. We can just hold off on doing
> anything with it until there are actual changes made that need to be 
> delivered.
> 
> But it did at least act as a good pipecleaner in that it found this job
> failure. I don't know enough about the release job itself, but please feel 
> free
> to reach out in the #openstack-release channel if there is anything the 
> release
> team can do to help get this sorted out and ready for when an actual release 
> is
> needed.

https://review.openstack.org/563752 should fix it,

Andreas

> Thanks,
> Sean
> 
> - Forwarded message from z...@openstack.org -
> 
> Date: Mon, 23 Apr 2018 17:03:18 +
> From: z...@openstack.org
> To: release-job-failu...@lists.openstack.org
> Subject: [Release-job-failures] Release of openstack/xstatic-angular-vis 
> failed
> Reply-To: openstack-dev@lists.openstack.org
> 
> Build failed.
> 
> - xstatic-check-version 
> http://logs.openstack.org/59/591c61a6bf706434e19de85809f4c37adc612280/release/xstatic-check-version/613f7fc/
>  : FAILURE in 2m 23s
> - release-openstack-python release-openstack-python : SKIPPED
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
> 
> - End forwarded message -
> 
> __
> 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
> 


-- 
 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

[openstack-dev] [os-upstream-institute] Prep call for Vancouver today

[Ildiko Vancsa]

Hi Training Team,

It is a friendly reminder that we will have a conference call on Zoom today at 
2200 UTC as opposed to the weekly meeting to better sync up before the training 
in Vancouver.

You can find the call details here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

Please let me know if you have any questions.

Thanks,
Ildikó
(IRC: ildikov)



__
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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Thomas Herve]

On Mon, Apr 23, 2018 at 8:09 PM, Dan Sneddon  wrote:

> We could add the ControlPlaneDefaultRoute and ControlPlaneSubnetCidr to
> network_data.yaml, but this would involve some duplication of configuration
> data, since those are currently defined in undercloud.conf. A more robust
> solution might be to generate network_data.yaml from that info in
> undercloud.conf, but currently we don't modify any files in the
> tripleo-heat-templates package after it gets installed.

Right, it seems getting those values from Neutron is better.

> I can't speak to the roadmap of Heat/Neutron/Nova on the undercloud, for the
> immediate future I don't see us moving away from Heat entirely due to
> upgrade requirements.
>
> I can see another use case for this Heat functionality, which is that I
> would like to be able to generate a report using Heat that lists all the
> ports in use in the entire deployment. This would be generated
> post-deployment, and could be used to populate an external DNS server, or
> simply to report on which IPs belong to which nodes.

Jiri wrote a small tool that does mostly that:
https://gist.github.com/jistr/ad385d77db7600c18e8d52652358b616
We could make that more official, but we already have the info.

-- 
Thomas

__
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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Thomas Herve]

On Mon, Apr 23, 2018 at 7:16 PM, Harald Jensås  wrote:
> On Fri, 2018-04-20 at 14:44 +0200, Thomas Herve wrote:

>> To make it clear, what you want to prevent is the need to add more
>> keys in network_data.yaml?
>>
>> As those had to be provided at some point, I wonder if tripleo can't
>> find a way to pass them again on the overcloud deploy.
>>
> No, the networks defined in network_data.yaml is fine, that is the data
> used to create the neutron stuff so passing the data from there is
> already in place to some extent.
>
> But, the ctlplane network is not defined in network_data.yaml.

OK.
>> If you can list the attributes you care about that'd be great.
>>
>
> Guess what I envision is a client_config attribute, a map with data
> useful to configure a network interface on the client. (I put * on the
> ones I believe could be useful for TripleO)
>
> * /v2.0/networks/{network_id}/mtu
> /v2.0/networks/{network_id}/dns_domain
> * /v2.0/subnets/{subnet_id}/dns_nameservers
> * /v2.0/subnets/{subnet_id}/host_routes
> /v2.0/subnets/{subnet_id}/ip_version
> * /v2.0/subnets/{subnet_id}/gateway_ip
> * /v2.0/subnets/{subnet_id}/cidr
> * /v2.0/subnets/{subnet_id}/ipv6_address_mode
> * /v2.0/subnets/{subnet_id}/ipv6_ra_mode
> /v2.0/ports/{port_id}/description - Why not?
> /v2.0/ports/{port_id}/dns_assignment
> /v2.0/ports/{port_id}/dns_domain
> /v2.0/ports/{port_id}/dns_name
> * /v2.0/ports/{port_id}/fixed_ips - We have this already
> /v2.0/ports/{port_id}/name- Why not?

I think we have most of those on resources already. From the required
ones, I think the only ones mising are ipv6_address_mode and
ipv6_ra_mode on subnets. If we make external resources work, it'll be
easy to provide what you need.

-- 
Thomas

__
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] [mistral] September PTG in Denver

[Sean McGinnis]

On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> Hey Dougal,
> 
> I think I had said May 2nd in my initial email asking about attendance. If
> you can get an answer out of your team by then I would greatly appreciate
> it! If you need more time please let me know by then (May 2nd) instead.
> 
> -Kendall (diablo_rojo)
> 

Do we need to collect this data for September already by the beginning of May?

Granted, the sooner we know details and can start planning, the better. But as
I started looking over the survey, it just seems really early to predict where
things will be 5 months from now. Especially considering we will have a
different set of PTLs for many projects by then, and it is too early for some
of those hand off discussions to have started yet.

Sean

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

[openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Matt Riedemann]

We seem to be at a bit of an impasse in this spec amendment [1] so I 
want to try and summarize the alternative solutions as I see them.


The overall goal of the blueprint is to allow defining traits via image 
properties, like flavor extra specs. Those image-defined traits are used 
to filter hosts during scheduling of the instance. During server create, 
that filtering happens during the normal "GET /allocation_candidates" 
call to placement.


The problem is during rebuild with a new image that specifies new 
required traits. A rebuild is not a move operation, but we run through 
the scheduler filters to make sure the new image (if one is specified), 
is valid for the host on which the instance is currently running.


We don't currently call "GET /allocation_candidates" during rebuild 
because that could inadvertently filter out the host we know we need 
[2]. Also, since flavors don't change for rebuild, we haven't had a need 
for getting allocation candidates during rebuild since we're not 
allocating new resources (pretend bug 1763766 [3] does not exist for now).


Now that we know the problem, here are some of the solutions that have 
been discussed in the spec amendment, again, only for rebuild with a new 
image that has new traits:


1. Fail in the API saying you can't rebuild with a new image with new 
required traits.


Pros:

- Simple way to keep the new image off a host that doesn't support it.
- Similar solution to volume-backed rebuild with a new image.

Cons:

- Confusing user experience since they might be able to rebuild with 
some new images but not others with no clear explanation about the 
difference.


2. Have the ImagePropertiesFilter call "GET 
/resource_providers/{rp_uuid}/traits" and compare the compute node root 
provider traits against the new image's required traits.


Pros:

- Avoids having to call "GET /allocation_candidates" during rebuild.
- Simple way to compare the required image traits against the compute 
node provider traits.


Cons:

- Does not account for nested providers so the scheduler could reject 
the image due to its required traits which actually apply to a nested 
provider in the tree. This is somewhat related to bug 1763766.


3. Slight variation on #2 except build a set of all traits from all 
providers in the same tree.


Pros:

- Handles the nested provider traits issue from #2.

Cons:

- Duplicates filtering in ImagePropertiesFilter that could otherwise 
happen in "GET /allocation_candidates".


4. Add a microversion to change "GET /allocation_candidates" to make two 
changes:


a) Add an "in_tree" filter like in "GET /resource_providers". This would 
be needed to limit the scope of what gets returned since we know we only 
want to check against one specific host (the current host for the instance).


b) Make "resources" optional since on a rebuild we don't want to 
allocate new resources (again, notwithstanding bug 1763766).


Pros:

- We can call "GET /allocation_candidates?in_tree=UUID>=" and if nothing is returned, 
we know the new image's required traits don't work with the current node.
- The filtering is baked into "GET /allocation_candidates" and not 
client-side in ImagePropertiesFilter.


Cons:

- Changes to the "GET /allocation_candidates" API which is going to be 
more complicated and more up-front work, but I don't have a good idea of 
how hard this would be to add since we already have the same "in_tree" 
logic in "GET /resource_providers".

- Potentially slows down the completion of the overall blueprint.

===

My personal thoughts are, I don't like option 1 since it adds technical 
debt which we'll eventually just need to solve later (think about [4]). 
Similar feelings for #2. #3 might be a short-term solution until #4 is 
done, but I think the best long-term solution to this problem is #4.


[1] https://review.openstack.org/#/c/560718/
[2] https://review.openstack.org/#/c/546357/
[3] https://bugs.launchpad.net/nova/+bug/1763766
[4] https://review.openstack.org/#/c/532407/

--

Thanks,

Matt

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

[openstack-dev] [horizon] Release of openstack/xstatic-angular-vis failed

[Sean McGinnis]

See below for logs from a failed xstatic release job. It appears something is
not set up right with this job.

"can't open file 'xstatic_check_version.py': [Errno 2] No such file or
directory"

I missed it initially, but this release did not actually contain any functional
change, so I think it is fine that it failed. We can just hold off on doing
anything with it until there are actual changes made that need to be delivered.

But it did at least act as a good pipecleaner in that it found this job
failure. I don't know enough about the release job itself, but please feel free
to reach out in the #openstack-release channel if there is anything the release
team can do to help get this sorted out and ready for when an actual release is
needed.

Thanks,
Sean

- Forwarded message from z...@openstack.org -

Date: Mon, 23 Apr 2018 17:03:18 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/xstatic-angular-vis failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- xstatic-check-version 
http://logs.openstack.org/59/591c61a6bf706434e19de85809f4c37adc612280/release/xstatic-check-version/613f7fc/
 : FAILURE in 2m 23s
- release-openstack-python release-openstack-python : SKIPPED
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

__
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] [mistral] September PTG in Denver

[Kendall Nelson]

Hey Dougal,

I think I had said May 2nd in my initial email asking about attendance. If
you can get an answer out of your team by then I would greatly appreciate
it! If you need more time please let me know by then (May 2nd) instead.

-Kendall (diablo_rojo)

On Fri, Apr 20, 2018 at 8:17 AM Dougal Matthews  wrote:

> Hey all,
>
> You may have seen the news already, but yesterday the next PTG location
> was announced [1]. It will be in Denver again.
>
> Can you let me know if you are planning to attend and go to Mistral
> sessions? I have been asked about numbers and need to reply by May 5th.
>
> Thanks,
> Dougal
>
>
> [1]:
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129564.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-23 16:28:13 + (+), Tim Bell wrote:
> One of the challenges in the academic sector is the time from
> lightbulb moment to code commit. Many of the academic resource
> opportunities are short term (e.g. PhDs, student projects,
> government funded projects) and there is a latency in current
> system to onboard, get the appropriate recognition in the
> community (such as by reviewing other changes) and then get the
> code committed. This is a particular problem for the larger
> projects where the patch is not in one of the project goal areas
> for that release.
[...]

Not to seem pessimistic (I'm not!) but I have hopes that with a
trend of decreasing full-time investment from companies
"productizing" OpenStack we'll see a corresponding decrease in
project velocity as well. I think that one of the primary scaling
challenges we have which translates to a negative experience for
casual contributors is the overall change volume in some of our
larger projects. We've optimized our processes for people who are
going to work on many things in parallel, so that the amount of time
any one of those things takes to land is less of a problem for their
effective personal throughput.

As the pace of development slows and the hype continues to cool,
this could at least partly self-correct. We'll be taking on changes
from users and other casual contributors out of necessity when
they're all we have. What we need to do is fill in the gaps in the
meantime and carefully manage the transition so that we increase
ease of contribution for them ahead of that curve rather than once
it's too late.
-- 
Jeremy Stanley


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

[openstack-dev] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights

[Andrey Pavlov]

Hello Sean,

EC2-api team always used manual tagging because I know only this procedure.
I thought that it's more convenient for me cause I can manage
commits/branches.
But in fact I don't mind to switch to automatic scheme.
If somethig else is needed from please let me know.

Regards,
Andrey Pavlov.

>

Hello teams,

I am following up on some recently announced changes regarding governed
projects and tagging rights. See [1] for background.

It was mostly followed before that when a project came under official
governance that all tagging and releases would then move to using the
openstack/releases repo and associated automation. It was not officially stated
until recently that this was one of the steps of coming under governance, so
there were a few projects that became official but that continued to do their
own releases.

We've cleaned up most projects' rights to push tags, but for the ones listed
here we waited:

- rally
- dragflow
- ec2-api
- networking-powervm
- nova-powervm
- yaql

We would like to finish cleaning up the ACLs for these, but I wanted to check
with the teams to make sure there wasn't a reason why these repos had continued
tagging separately. Please let me know, either here or in the
#openstack-release channel, if there is something we are overlooking.

Thanks for your attention.

---
Sean (smcginnis)
__
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] campaign question: How can we make contributing to OpenStack easier?

[Matt Riedemann]

On 4/23/2018 1:24 PM, Jeremy Stanley wrote:

Some of us also urged existing leaders in various projects to record
videos encouraging contributors to get more involved by demystifying
processes like code review or bug triage. This could be as simple as
signing up for an available lightning talk slot at one of our
conferences and then performing what you consider to be mundane but
much-needed activities while narrating an explanation of what's
going on in your head. What we've failed to do, as far as I'm aware,
is aggregate links to these somewhere and promote that in ways that
the intended audience will find them.


This reminded me of something I linked into the nova contributor docs 
based on a presentation that stephenfin and bauzas gave in Sydney about 
bug triage:


https://docs.openstack.org/nova/latest/contributor/how-to-get-involved.html#how-to-do-great-bug-triage

Over time I've tried to link more and more relevant summit videos into 
the nova docs for things like Placement, Cells v2, and really anything 
that is specific to a domain of nova for new contributors.


We spend so much time working on these presentations that it's a shame 
when we don't actually link them back into our docs for people to find 
later when they are trying to learn.


--

Thanks,

Matt

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

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Zane Bitter]

On 23/04/18 09:27, Doug Hellmann wrote:

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

We frequently have discussions about whether the TC is active enough,
in terms of driving new policies, technology choices, and other
issues that affect the entire community.


I guess you can put me in the camp of wanting the TC to be proactive as 
well as reactive. I don't want to say it's not being active enough, but 
I do think it's valuable to proactively consider other ways in which we 
can be proactive.



Please describe one case where we were either active or reactive
and how that was shown to be the right choice over time.


A couple of examples that come to mind of the TC being actively involved 
in driving changes would be the addition of etcd3 to the required set of 
base services (alongside RabbitMQ and MySQL/MariaDB), and the 
project-wide goals initiative.


Those are both examples of decisions that need to be co-ordinated across 
the whole of OpenStack. Since the TC is the only elected body that 
represents the whole technical community, it needs to have a role in 
decisions such as those - either by making them directly or by 
delegating them to some group of experts. If it doesn't, we'll generally 
be stuck with the status quo by default. In my experience, major 
decisions getting made by default is a common failure mode in a lot of 
bad products.



Please describe another case where the choice to be active or
reactive ended up being the wrong choice.


This is a difficult one to answer, in part because being purely reactive 
need not be a choice - it's the default.


One example, that's closely related to the other thread, might be the 
way we've chosen to define the scope of OpenStack. That's largely been 
by reactively approving or rejecting projects as they requested to join, 
rather than by attempting to lay out a vision in more detail than our 
mission statement and correcting course when necessary in response to 
new project applications.


The picture that has emerged from that process has essentially been one 
of a full-featured cloud (which, for the record, I fully agree with) - 
most projects were approved. But as Chris pointed out there are plenty 
of folks out there who disagree with that. By not having a proactive 
debate we've missed an opportunity to gain a deeper understanding of 
their concerns and address them as far as is possible. I believe there 
are a lot of folks still working at cross-purposes without a unified 
vision of what we're trying to build as a result.



If you think the TC should tend to be more active in driving change
than it is today, please describe the changes (policy, culture,
etc.) you think would need to be made to do that effectively (not
which policies you want us to be more active on, but *how* to
organize the TC to be more active and have that work within the
community culture).


One of my concerns is that the dropping of the weekly TC meeting with a 
published agenda in favour of the unstructured office hours has 
diminished the TC's ability to be proactive. For example, the 
constellations initiative was adopted by the TC as a goal to get 
underway by 2019 (barely more than 8 months away). Who is working on it? 
What is the status? What are the open questions requiring feedback? I 
don't know, and I follow #openstack-tc and the TC mailing list fairly 
closely compared to most people.


I definitely don't want to get rid of office hours, and I think the 
reasons for dropping the meeting (encouraging geographically diverse 
participation) are still valid. I'd like to see the TC come up with a 
program of work for the term after each Summit, and actively track the 
progress of it using asynchronous tools - perhaps Storyboard supported 
by follow-ups on the mailing list.


Perhaps we can also do more to, for example, empower SIGs to make 
recommendations on community-wide issues that the TC would then commit 
to either ratifying or rejecting within a fixed time frame. One reason 
that I think the TC is (correctly) wary of promulgating too many edicts 
is that they're perceived as difficult to change as circumstances 
demand. So reducing the cost of changes is key to allowing the TC to 
take a more active role without stifling the community.


cheers,
Zane.


If you think the TC should tend to be less active in driving change
overall, please describe what policies you think the TC should be
taking an active role in implementing.

Doug


__
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] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

2018-04-24 1:26 GMT+08:00 Doug Hellmann :
>
> Excerpts from Rico Lin's message of 2018-04-24 00:54:14 +0800:
> > ** What aspects of our policies or culture make contributing to
> > OpenStackmore difficult than contributing to other open source
projects?To
> > fully understand the map of OpenStack services is a huge challenge,
> > especially for new join developers. And for project teams, might not
>
> This is an interesting point that I haven't heard raised before.
> Typically the number of projects is used as an example of something
> that is confusing to users or deployers, but can you elaborate on
> how it is confusing to contributors?
Because in some cases, users provide contributors and when a user feature
jump in,
to clarify which projects to might be part of that feature will cause time
when they weren't in
OpenStack for long (as a contributor working on cross communities).
And usually,  when he/she send out an ML for such a cross-projects
usecase won't get much replied (really depends on teams).
For other cases, user rely on what developers' report to decides where they
should put resource on,
but developers just provides the first match (and seems usable) project he
can find in repositories.

>
> > provide new contributors guidelines to be quicker to become part of the
> > team. Finally, the format or WG/SIG/Team might confuse contributors.*
Which
>
> Do you mean because it isn't clear what sort of group to start in order
> to accomplish something?
exactly
>
> > of those would you change, and how?IMO to provides clear landscape will
> > help on give people better view on the whole map and might get the
better
> > idea on how to fit in their plan without spending too much time on
finding
> > where to contribute. Also, we need provides better ways to communicate
to
> > new contributors to at least make them feel welcome. Which maybe we can
try
> > to add in PTL/TC's (or other possible position) duty and to provide
better
> > guidelines to new join contributors who seems got no clue on what's the
> > project been working on or where the project needs help. Only people we
>
> What role do you think the First Contact SIG might play in that?

I think in this specific scenario, First Contact SIG can help define the
scope and suggest
the guideline. Because new developers always reach to SIG/project team
directly, and if it's
not working,  they might just try to work around issues and skip the
chances to join
OpenStack community.
>
> > really understand that project can provide such judgment, and it seems
like
> > a duty to provide guidelines to others (Aka help people working with
you).
> > Finally, I personally think it's a good idea to have SIG in OpenStack,
but
> > I think we need to provide technical guidelines to SIGs, so they can
make a
> > clear decision on what's their mission, where are the resources they can
> > use, and how they might be able to use it. A clear vision makes clear
> > actions.* Where else should we be looking for contributors?IMO we
actually
> > got a bunch new contributors around OpenStack (mostly for nova and
neutron
> > of course) and trying to figure out what they can/should do. Also
possibly
> > from other projects which might be doing overlapping jobs. Also to form
SIG
> > might be a more productive way to collect contributors.*
> >
> >
> >
> > May The Force of OpenStack Be With You,
> >
> > *Rico Lin*irc: ricolin
> >
> > 2018-04-23 22:06 GMT+08:00 Doug Hellmann :
> >
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > Over the last year we have seen some contraction in the number of
> > > companies and individuals contributing to OpenStack. At the same
> > > time we have started seeing contributions from other companies and
> > > individuals. To some degree this contraction and shift in contributor
> > > base is a natural outcome of changes in OpenStack itself along with
> > > the rest of the technology industry, but as with any change it
> > > raises questions about how and whether we can ensure a smooth
> > > transition to a new steady state.
> > >
> > > What aspects of our policies or culture make contributing to OpenStack
> > > more difficult than contributing to other open source projects?
> > >
> > > Which of those would you change, and how?
> > >
> > > Where else should we be looking for contributors?
> > >
> > > Doug
> > >
> > >
__
> > > 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 

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Jeremy Stanley]

On 2018-04-23 13:18:22 -0400 (-0400), Doug Hellmann wrote:
[...]
> I would like for us to collect some more data about what efforts
> teams are making with encouraging new contributors, and what seems
> to be working or not. In the past we've done pretty well at finding
> new techniques by experimenting within one team and then adapting
> the results to scale them out to other teams.
> 
> Does anyone have any examples of things that we ought to be trying
> more of?

A while back (and I'm sorry I seem to be failing at finding the
right keywords to locate any of it) it was pointed out that the
Kolla team has a handbook for how to become a core reviewer for
their deliverables with a process that contributors interested in
getting more involved that way can follow. While perhaps not
necessarily applicable everywhere, and certainly would be extremely
team-specific, it sounded like an intriguing solution. I'd be
curious to follow up and find out whether that model has continued
to work out for them.

Some of us also urged existing leaders in various projects to record
videos encouraging contributors to get more involved by demystifying
processes like code review or bug triage. This could be as simple as
signing up for an available lightning talk slot at one of our
conferences and then performing what you consider to be mundane but
much-needed activities while narrating an explanation of what's
going on in your head. What we've failed to do, as far as I'm aware,
is aggregate links to these somewhere and promote that in ways that
the intended audience will find them.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Graham Hayes]

On 23/04/18 14:27, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> We frequently have discussions about whether the TC is active enough,
> in terms of driving new policies, technology choices, and other
> issues that affect the entire community.
> 
> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.

I think the best example of the TC being proactive and it being the
right choice is the Visioning document and exercise.

> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.

The InterOp testing and Tempest situation is the most vivid in my mind
(after being in the centre of it for months). Members of the TC were
proactive, but the TC as a whole was passive on it.

The TC reacted 3 or 4 days after the board had approved the program -
when we should have had an answer months before.

> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).

I do think the TC should be more active in driving OpenStack forward.
I think the TC has a role in listening to the developers who are driving
the projects forward, and connecting them with other project developers
where appropriate, while also co-ordinating with the User Committee, to
see where commonalities are, and then using its voice to drive change
in the foundation, and member companies (via the Board, foundation staff
and other potentially more informal avenues).

But for that, the TC will need to find a collective voice, that is
pro-active, as trying to drive a project in the manner above cannot
be reactive - by the time we develop a position that we are reacting
with it, it will be too late.

I think introducing more formal in-person blocks of time as a group is
important, with a time blocked agenda, and enforced chairing could help
us do that.

I know it is not a popular opinion, but a 1/2 day every 6 months where
all TC members can be available and attend the meeting can really help
a group find a mutual voice.

> If you think the TC should tend to be less active in driving change
> overall, please describe what policies you think the TC should be
> taking an active role in implementing.
> 
> Doug
> 
> __
> 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
> 



signature.asc
Description: OpenPGP 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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Dan Sneddon]

On Mon, Apr 23, 2018 at 10:16 AM, Harald Jensås  wrote:

> On Fri, 2018-04-20 at 14:44 +0200, Thomas Herve wrote:
> > On Thu, Apr 19, 2018 at 2:59 PM, Harald Jensås 
> > wrote:
> > > Hi,
> >
> > Hi, thanks for sending this. Responses inline.
> >
> > > When configuring TripleO deployments with nodes on routed ctlplane
> > > networks we need to pass some per-network properties to the
> > > NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp``
> > > property using get_attr, but the NIC configs need a couple of more
> > > parameters[2], for example: ``ControlPlaneSubnetCidr``,
> > > ``ControlPlaneDefaultRoute`` and ``DnsServers``.
> > >
> > > Since queens these templates are jinja templated, to generate
> > > things
> > > from from network_data.yaml. When using routed ctlplane networks,
> > > the
> > > parameters ``ControlPlaneSubnetCidr`` and
> > > ``ControlPlaneDefaultRoute``
> > > will be different. So we need to use static per-role
> > > Net::SoftwareConfig templates, and add parameters such as
> > > ``ControlPlaneDefaultRouteLeafX``.
> > >
> > > The values the use need to pass in for these are already available
> > > in
> > > the neutron ctlplane network configuration on the undercloud. So
> > > ideally we should not need to ask the user to provide them in
> > > parameter_defaults, we should resolve the correct values
> > > automatically.
> >
> > To make it clear, what you want to prevent is the need to add more
> > keys in network_data.yaml?
> >
> > As those had to be provided at some point, I wonder if tripleo can't
> > find a way to pass them again on the overcloud deploy.
> >
> No, the networks defined in network_data.yaml is fine, that is the data
> used to create the neutron stuff so passing the data from there is
> already in place to some extent.
>
> But, the ctlplane network is not defined in network_data.yaml.
>

We could add the ControlPlaneDefaultRoute and ControlPlaneSubnetCidr to
network_data.yaml, but this would involve some duplication of configuration
data, since those are currently defined in undercloud.conf. A more robust
solution might be to generate network_data.yaml from that info in
undercloud.conf, but currently we don't modify any files in the
tripleo-heat-templates package after it gets installed.


>
> > Inspecting neutron is an elegant solution, though.
> >
>
>
> > > : We can get the port ID using get_attr:
> > >
> > >  {get_attr: [, addresses, , 0, port]}
> > >
> > > : From there outside of heat we can get the subnet_id:
> > >
> > >  openstack port show 2fb4baf9-45b0-48cb-8249-c09a535b9eda \
> > >  -f yaml -c fixed_ips
> > >
> > >  fixed_ips: ip_address='172.20.0.10', subnet_id='2b06ae2e-423f-
> > > 4a73-
> > > 97ad-4e9822d201e5'
> > >
> > > : And finally we can get the gateway_ip and cidr of the subnet:
> > >
> > >   openstack subnet show 2b06ae2e-423f-4a73-97ad-4e9822d201e5 \
> > >   -f yaml -c gateway_ip -c cidr
> > >
> > >  cidr: 172.20.0.0/26
> > >  gateway_ip: 172.20.0.62
> > >
> > >
> > > The problem is getting there using heat ...
> > > a couple of ideas:
> > >
> > > a) Use heat's ``external_resource`` to create a port resource,
> > >and then  a external subnet resource. Then get the data
> > >from the external resources. We probably would have to make
> > >it possible for a ``external_resource`` depend on the server
> > >resource, and verify that these resource have the required
> > >attributes.
> >
> > I believe that's a relatively easy fix. It's unclear why we didn't
> > allow that in the first place, probably because we were missing a use
> > case, but it seems valuable here.
> >
> > > b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
> > >well probably) to include the data.
> > >
> > >If we do this we should probably aim to be in parity with
> > >what is made available to clients getting the configuration
> > >from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
> > >gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
> > >etc.)
> >
> > I'm with you on exposing more neutron data to the Port resource. It
> > can be complicated because some of them are implementation specific,
> > but we can look into those.
> >
> > I don't think adding them directly to the Server resource makes a ton
> > of sense though.
> >
> In tripleo, the ctlplane interface is an implicit port created by the
> server resource. :( (Attempts where made to change this, but upgrades
> would'nt work) So the server resource is where I would find it most
> useful. (Adding attributes to the port resource, and then using
> external resource for the implicit server ports may be a compromise.
> Nested dependencies for external_resources might be hard?)
>

Yes, the port is currently created as part of the Ironic server resource.
We would have more flexibility if this were a separate Neutron port, but we
need to be able to support upgrades. This would require the ability in Heat
to detach 

Re: [openstack-dev] [tc] campaign question related to new projects

[Rico Lin]

2018-04-23 22:43 GMT+08:00 Doug Hellmann :
>
> Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800:
> > Thanks, Doug, for raising this campaign question
> >
> >
> > Here are my answers:
> >
> >
> > ***How you would evaluate a project's application in general
> >
> > First I would work through the requirements ([1]) to evaluate projects.
> > Since most of the requirements are specific enough. And here's more
> > important part, to leave evaluate logs or comments for projects which we
> > considered but didn't reach some requirements. It's very important to
guide
> > projects to cross over requirements (and remember, a `-1` only means we
> > trying to help).
> >
> > Then, I work on questions, like:
> >
> > `How many user are interesting to/needs the functionality that service
> > provided?`
> >
> > `How active is this project and how's the diversity of contributors?`
>
> Our current policy is to allow projects with contributors from a small
> number of affiliations (even a single employer), under the theory that
> bringing a team into the community officially will help them grow by
> showing them the benefits of being more diverse and by making it easier
> for other community members who have employer restrictions on their open
> source work to justify contributing.
>
> Would you change that policy in any way?
I'm fine with the number of developers involved in the project. we should
encourage
people working on any crazy ideas. But the point is `is that developer
active?
and will he/she helps others to join that projects or just waiting for
others?`.
If we can try to put such requirement in policy will be better IMO.
Otherwise,
we can keep the policy but the diversity of developers might help to reduce
chances of that risk.
>
> >
> > `Is this project required cross communities/projects cooperation? If
yes,
> > how's the development workflows  are working between
communities/projects?`
> >
> > And last but is one of the most important questions,
> >
> > `Is this service aligns with the OpenStack Mission`? (and let's jump to
> > next question to answer this part)
> >
> >
> >
> > **What sorts of things do you consider when deciding whether a project
> > "aligns with the OpenStack Mission," for example?*
> >
> > I would consider things like:
> >
> > `Is the project's functionality complete the OpenStack infrastructure
map?`
> >
> > Asking from user requirement and functionality point of view, `how's the
> > project(services) will make OpenStack better infrastructure for
> > user/operators?` and `how's this functionality provide a better life for
> > OpenStack developers?`
> >
> > `Is the project provides better integration point between communities`
> >
> > To build a better infrastructure, IMO it's also important to ask if a
> > project (service) really help on integration with other communities like
> > Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active
> > infrastructure to solutions is part of our mission too.
> >
> > `Is it providing functionality which we can integrate with current
projects
> > or SIG instead?`
> >
> > In short, we should be gathering our development energy, to really
achieve
> > the jobs which is exactly why we spend times on trying to find official
> > projects and said this is part of our mission to work on. So when new
> > projects jump out, it's really important to discuss cross-project `is it
> > suitable for projects integrated and join force on specific
functionality?`
> > (to do this while evaluating a project instead of when it's creating
might
> > not be the best time to said `please integrate or join forces with other
> > teams together`(not even with a smiling face), but it's never too late
for
> > a non-official/incubating project to consider about this). I really
don't
> > like to to see any project get higher chances to die just because
> > developers chance their developing focus. It's happening when projects
are
> > all willing to do the functionality, but no communication between(some
> > cases, not even now other projects exists), and new/old projects dead,
then
> > TC needs to spend the time to pick those projects out. So IMO, it's
worth
> > to spend times to investigate on whether projects can be joined. Or
ideally
> > to put a resolution said, it's project's obligation to help on this, and
> > help other join force to be part of the team.
>
> Please see my other question about projects with overlapping feature
> sets [1].
Done:)
>
> Doug
>
> [1]
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>
> >
> > `Can projects provide cross-project gating?`
> >
> > Do think if it's possible, we should consider this when asking if a
service
> > aligns with our mission because not breaking rest of infrastructure is
part
> > of the definition of `to build`. And providing cross-project gate jobs
> > seems like a way to go. To stable the integration between projects and
> > prevent released a failed feature when 

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-04-23 12:35:07 -0500:
> On 4/23/2018 12:18 PM, Doug Hellmann wrote:
> > I would like for us to collect some more data about what efforts
> > teams are making with encouraging new contributors, and what seems
> > to be working or not. In the past we've done pretty well at finding
> > new techniques by experimenting within one team and then adapting
> > the results to scale them out to other teams.
> > 
> > Does anyone have any examples of things that we ought to be trying more
> > of?
> 
> The nova team is now trying runways [1] for trying to focus reviews on 
> blueprints which are ready but otherwise don't get the focus from the 
> core team.
> 
> The certificate validation stuff in there for the John Hopkins team is a 
> prime example of how this is putting focus on something that has 
> otherwise been getting deferred since at least the Ocata summit.
> 
> [1] https://etherpad.openstack.org/p/nova-runways-rocky
> 

Great example. It sounds like it's helping, and I look forward to
hearing the retrospective at the end of the cycle.

Doug

__
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] campaign question: How "active" should the TC be?

[Rico Lin]

*IMO TC should be more active as possible. Since we try to use this
position to make policies, we should also consider hard how we can
broadcast those policies to each developer to provide guidelines and to get
possible feedbacks.To reach out current/potential technical contributors,
to sell this technical community and to communicate with other parts
(UC/Board/other communities/ops/users) and bring ideas/actions to renew our
policies or to the entire technical community. That will need TCs jump into
local/global events, meetings and MLs.I believe it's not just about what TC
defines our own duty, but most of the developers believe in TC's
governance.So I think we should definitely be more active and keep trying
to renew our goals. Here's example, I pretty sure a lot of developers from
our community doesn't know exactly what policy we were made.Which provides
the higher risk for gaps between what TCs think OpenStack and what they try
to present in their local community. I'm pretty sure such gaps exist in the
most local community (which developers learn what's current OpenStack looks
like) in Asia.As for the discussion on how to organize TCs to be more
active. To make a policy for that actually make sense to me since all TCs
should read through and follow policies which they made. Second to try to
reach out to project teams, rest of community, and other communities should
be a good start.*


2018-04-23 21:27 GMT+08:00 Doug Hellmann :

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> We frequently have discussions about whether the TC is active enough,
> in terms of driving new policies, technology choices, and other
> issues that affect the entire community.
>
> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.
>
> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.
>
> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).
>
> If you think the TC should tend to be less active in driving change
> overall, please describe what policies you think the TC should be
> taking an active role in implementing.
>
> Doug
>
> __
> 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
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] campaign question: How can we make contributing to OpenStack easier?

[Matt Riedemann]

On 4/23/2018 12:18 PM, Doug Hellmann wrote:

I would like for us to collect some more data about what efforts
teams are making with encouraging new contributors, and what seems
to be working or not. In the past we've done pretty well at finding
new techniques by experimenting within one team and then adapting
the results to scale them out to other teams.

Does anyone have any examples of things that we ought to be trying more
of?


The nova team is now trying runways [1] for trying to focus reviews on 
blueprints which are ready but otherwise don't get the focus from the 
core team.


The certificate validation stuff in there for the John Hopkins team is a 
prime example of how this is putting focus on something that has 
otherwise been getting deferred since at least the Ocata summit.


[1] https://etherpad.openstack.org/p/nova-runways-rocky

--

Thanks,

Matt

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

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

On 23/04/18 18:14, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100:
>> On 23/04/18 17:14, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
 On 23/04/18 16:04, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>> 7On 20/04/18 22:26, Doug Hellmann wrote:
>> 
>>> Without letting the conversation devolve too much into a discussion
>>> of Adjutant's case, please talk a little about how you would evaluate
>>> a project's application in general.  What sorts of things do you
>>> consider when deciding whether a project "aligns with the OpenStack
>>> Mission," for example?
>>>
>>> Doug
>>>
>>
>> For me, the most important thing for a project that wants to join is
>> that they act like "one of us" - what I think ttx refered to as "culture
>> fit".
>>
>> This is fairly wide ranging, but includes things like:
>>
>> * Do they use the PTIs[0]
>> * Do they use gerrit, or if they use something else, do they follow
>>   the same review styles and mechanisms?
>> * Are they on IRC?
>> * Do they use the mailing list for long running discussion?
>>   ** If a project doesn't have long running discussions and as a result
>>  does not have ML activity, I would see that as OK - my problem
>>  would be with a team that ran their own list.
>> * Do they use standard devstack / -infra jobs for testing?
>> * Do they use the standard common libraries (where appropriate)?
>>
>> If a project fails this test (and would have been accepted as something
>> that drives the mission), I see no issue with the TC trying to bring
>> them into the fold by helping them work like one of us, and accepting
>> them when they have shown that they are willing to change how they
>> do things.
>>
>> For the "product" fit, it is a lot more subjective. We used to have a
>> system (pre Big Tent) where the TC picked "winners" in a space and
>> blessed one project as the way to do $thing. Then, in big tent we
>> started to not pick winners, and allow anyone who was one of us, and
>> had a "cloud" application.
>>
>> Recently, we have moved back to seeing if a project overlaps with
>> another. The real test for this (from my viewpoint) is if the
>> perceived overlap is an area that the team that is currently in
>> OpenStack is interested in pursuing - if not we should default to
>> adding the project.
>
> We've always considered overlap to some degree, but it has come up
> more explicitly in a few recent discussions because of the nature
> of the projects.  Please see the other thread on this topic [1].
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>
>> Personally, if the project adds something that we currently lack,
>> and have lacked for a long time (not to get too close to the current
>> discussion), or tries to reduce the amount of extra tooling that
>> deployers currently write in house, we should welcome them.
>>
>> The acid test for me is "How would I use this?" or "Have I written
>> tooling or worked somewhere that wrote tooling to do this?"
>>
>> If the answer is yes, it is a good indication that they fit with the
>> mission.
>
> This feels like the ideal open source approach, in which contributors
> are "scratching their own itch." How can we encourage more deployers
> and users of OpenStack to consider contributing their customization
> and integration projects? Should we?

 I think a lot of our major users are good citizens and are doing some or
 all of this work in the open - we just have a discoverability issue.

 A lot of the benefit of joining the foundation as a project, is the
 increased visibility gained from it, so that others who are deploying
 OpenStack in a similar layout can find a project and use it.

 I think at the very least we should find a way to promote them (this
 is where constellations could really help, as we could add non member
 projects to constellations where they are appropriate.
>>>
>>> Do you foresee any issues with adding unofficial projects to the
>>> constellations?
>>>
>>> Doug
>>
>> No (from my viewpoint anyway) - I think they will be important to
>> include in any true collection of use cases - for example we definitely
>> will want to have a "PaaS" Constellation that includes things like
>> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
>> OpenStack works in the entire open source infrastructure community
>> and not just how it works internally - and showing how you can use other
>> open source software components *with* OpenStack is vital for that.
> 
> Would you make a distinction between things that have 

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Rico Lin's message of 2018-04-24 00:54:14 +0800:
> ** What aspects of our policies or culture make contributing to
> OpenStackmore difficult than contributing to other open source projects?To
> fully understand the map of OpenStack services is a huge challenge,
> especially for new join developers. And for project teams, might not

This is an interesting point that I haven't heard raised before.
Typically the number of projects is used as an example of something
that is confusing to users or deployers, but can you elaborate on
how it is confusing to contributors?

> provide new contributors guidelines to be quicker to become part of the
> team. Finally, the format or WG/SIG/Team might confuse contributors.* Which

Do you mean because it isn't clear what sort of group to start in order
to accomplish something?

> of those would you change, and how?IMO to provides clear landscape will
> help on give people better view on the whole map and might get the better
> idea on how to fit in their plan without spending too much time on finding
> where to contribute. Also, we need provides better ways to communicate to
> new contributors to at least make them feel welcome. Which maybe we can try
> to add in PTL/TC's (or other possible position) duty and to provide better
> guidelines to new join contributors who seems got no clue on what's the
> project been working on or where the project needs help. Only people we

What role do you think the First Contact SIG might play in that?

> really understand that project can provide such judgment, and it seems like
> a duty to provide guidelines to others (Aka help people working with you).
> Finally, I personally think it's a good idea to have SIG in OpenStack, but
> I think we need to provide technical guidelines to SIGs, so they can make a
> clear decision on what's their mission, where are the resources they can
> use, and how they might be able to use it. A clear vision makes clear
> actions.* Where else should we be looking for contributors?IMO we actually
> got a bunch new contributors around OpenStack (mostly for nova and neutron
> of course) and trying to figure out what they can/should do. Also possibly
> from other projects which might be doing overlapping jobs. Also to form SIG
> might be a more productive way to collect contributors.*
> 
> 
> 
> May The Force of OpenStack Be With You,
> 
> *Rico Lin*irc: ricolin
> 
> 2018-04-23 22:06 GMT+08:00 Doug Hellmann :
> 
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> >
> > Over the last year we have seen some contraction in the number of
> > companies and individuals contributing to OpenStack. At the same
> > time we have started seeing contributions from other companies and
> > individuals. To some degree this contraction and shift in contributor
> > base is a natural outcome of changes in OpenStack itself along with
> > the rest of the technology industry, but as with any change it
> > raises questions about how and whether we can ensure a smooth
> > transition to a new steady state.
> >
> > What aspects of our policies or culture make contributing to OpenStack
> > more difficult than contributing to other open source projects?
> >
> > Which of those would you change, and how?
> >
> > Where else should we be looking for contributors?
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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

Re: [openstack-dev] [tc] campaign question related to new projects

[Jeremy Stanley]

On 2018-04-23 13:14:59 -0400 (-0400), Doug Hellmann wrote:
[...]
> I hope that no one considers any of this "noise," so thank you for
> highlighting that point.

Oh, yes I didn't mean to imply that any of the responses so far have
been noise, but I was walking a thin line on it being a hollow sort
of "me too" reply. I have added this as one of my suggested bullet
points for proposed forum discussion
http://forumtopics.openstack.org/cfp/details/122 as well.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

Excerpts from Chris Dent's message of 2018-04-23 17:50:31 +0100:
> On Mon, 23 Apr 2018, Tim Bell wrote:
> 
> > One of the challenges in the academic sector is the time from
> > lightbulb moment to code commit. Many of the academic resource
> > opportunities are short term (e.g. PhDs, student projects,
> > government funded projects) and there is a latency in current
> > system to onboard, get the appropriate recognition in the
> > community (such as by reviewing other changes) and then get the
> > code committed.  This is a particular problem for the larger
> > projects where the patch is not in one of the project goal areas
> > for that release.
> 
> This. Many times over this.
> 
> The latency that a casual contributor may experience when
> interacting with one of the larger OpenStack projects is
> discouraging and a significant impedance mismatch for the
> contributor.
> 
> One thing that might help is what I implied in one of my responses
> elsewhere in Doug's collection of questions: Professional OpenStack
> developers could be oriented towards enabling and attending to
> casual contributors more than addressing feature development. This
> is a large shift in how OpenStack is done, but makes sense in a
> world where we are trying to maintain an existing and fairly mature
> thing: We need maintainers.

I would like for us to collect some more data about what efforts
teams are making with encouraging new contributors, and what seems
to be working or not. In the past we've done pretty well at finding
new techniques by experimenting within one team and then adapting
the results to scale them out to other teams.

Does anyone have any examples of things that we ought to be trying more
of?

Doug

__
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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Harald Jensås]

On Fri, 2018-04-20 at 14:44 +0200, Thomas Herve wrote:
> On Thu, Apr 19, 2018 at 2:59 PM, Harald Jensås 
> wrote:
> > Hi,
> 
> Hi, thanks for sending this. Responses inline.
> 
> > When configuring TripleO deployments with nodes on routed ctlplane
> > networks we need to pass some per-network properties to the
> > NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp``
> > property using get_attr, but the NIC configs need a couple of more
> > parameters[2], for example: ``ControlPlaneSubnetCidr``,
> > ``ControlPlaneDefaultRoute`` and ``DnsServers``.
> > 
> > Since queens these templates are jinja templated, to generate
> > things
> > from from network_data.yaml. When using routed ctlplane networks,
> > the
> > parameters ``ControlPlaneSubnetCidr`` and
> > ``ControlPlaneDefaultRoute``
> > will be different. So we need to use static per-role
> > Net::SoftwareConfig templates, and add parameters such as
> > ``ControlPlaneDefaultRouteLeafX``.
> > 
> > The values the use need to pass in for these are already available
> > in
> > the neutron ctlplane network configuration on the undercloud. So
> > ideally we should not need to ask the user to provide them in
> > parameter_defaults, we should resolve the correct values
> > automatically.
> 
> To make it clear, what you want to prevent is the need to add more
> keys in network_data.yaml?
> 
> As those had to be provided at some point, I wonder if tripleo can't
> find a way to pass them again on the overcloud deploy.
> 
No, the networks defined in network_data.yaml is fine, that is the data
used to create the neutron stuff so passing the data from there is
already in place to some extent.

But, the ctlplane network is not defined in network_data.yaml.

> Inspecting neutron is an elegant solution, though.
> 


> > : We can get the port ID using get_attr:
> > 
> >  {get_attr: [, addresses, , 0, port]}
> > 
> > : From there outside of heat we can get the subnet_id:
> > 
> >  openstack port show 2fb4baf9-45b0-48cb-8249-c09a535b9eda \
> >  -f yaml -c fixed_ips
> > 
> >  fixed_ips: ip_address='172.20.0.10', subnet_id='2b06ae2e-423f-
> > 4a73-
> > 97ad-4e9822d201e5'
> > 
> > : And finally we can get the gateway_ip and cidr of the subnet:
> > 
> >   openstack subnet show 2b06ae2e-423f-4a73-97ad-4e9822d201e5 \
> >   -f yaml -c gateway_ip -c cidr
> > 
> >  cidr: 172.20.0.0/26
> >  gateway_ip: 172.20.0.62
> > 
> > 
> > The problem is getting there using heat ...
> > a couple of ideas:
> > 
> > a) Use heat's ``external_resource`` to create a port resource,
> >and then  a external subnet resource. Then get the data
> >from the external resources. We probably would have to make
> >it possible for a ``external_resource`` depend on the server
> >resource, and verify that these resource have the required
> >attributes.
> 
> I believe that's a relatively easy fix. It's unclear why we didn't
> allow that in the first place, probably because we were missing a use
> case, but it seems valuable here.
> 
> > b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
> >well probably) to include the data.
> > 
> >If we do this we should probably aim to be in parity with
> >what is made available to clients getting the configuration
> >from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
> >gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
> >etc.)
> 
> I'm with you on exposing more neutron data to the Port resource. It
> can be complicated because some of them are implementation specific,
> but we can look into those.
> 
> I don't think adding them directly to the Server resource makes a ton
> of sense though.
> 
In tripleo, the ctlplane interface is an implicit port created by the
server resource. :( (Attempts where made to change this, but upgrades
would'nt work) So the server resource is where I would find it most
useful. (Adding attributes to the port resource, and then using
external resource for the implicit server ports may be a compromise.
Nested dependencies for external_resources might be hard?)

> > c) Create a new heat function to read properties of any
> >openstack resource, without having to make use of the
> >external_resource in heat.
> 
> It's an interesting idea, but I think it would look a lot like what
> external resources are supposed to be.
> 
> I see a few changes:
>  * Allow external resource to depend on other resources
>  * Expose more port attributes
>  * Expose more subnet attributes
> 
> If you can list the attributes you care about that'd be great.
> 

Guess what I envision is a client_config attribute, a map with data
useful to configure a network interface on the client. (I put * on the
ones I believe could be useful for TripleO)

* /v2.0/networks/{network_id}/mtu  
/v2.0/networks/{network_id}/dns_domain
* /v2.0/subnets/{subnet_id}/dns_nameservers
* /v2.0/subnets/{subnet_id}/host_routes
/v2.0/subnets/{subnet_id}/ip_version
* 

Re: [openstack-dev] [tc] campaign question related to new projects

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-04-23 17:02:07 +:
> On 2018-04-23 12:02:14 -0400 (-0400), Zane Bitter wrote:
> [...]
> > The main thing I will be looking out for in those cases is that
> > the project followed the Four Opens *from the beginning*. Projects
> > that start from a code dump are much less likely to attract other
> > contributors in my view. Open Source is not a verb.
> [...]
> 
> Not to add more noise, but I wanted to mention that I _really_ like
> this point in particular. We've definitely seen plenty of
> applications for inclusion which started out as an
> internally-developed tool behind closed doors somewhere. When they
> get "flung over the wall" to the community they tend to flounder in
> their attempts to gain traction as properly open projects in their
> own right. I don't think we do a good enough job at highlighting
> this risk (yet), and will remember to point it out more often when I
> spot it in the future. Thanks!

I hope that no one considers any of this "noise," so thank you for
highlighting that point.

Doug

__
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] campaign question related to new projects

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100:
> On 23/04/18 17:14, Doug Hellmann wrote:
> > Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
> >> On 23/04/18 16:04, Doug Hellmann wrote:
> >>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>  7On 20/04/18 22:26, Doug Hellmann wrote:
>  
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> >
> > Doug
> >
> 
>  For me, the most important thing for a project that wants to join is
>  that they act like "one of us" - what I think ttx refered to as "culture
>  fit".
> 
>  This is fairly wide ranging, but includes things like:
> 
>  * Do they use the PTIs[0]
>  * Do they use gerrit, or if they use something else, do they follow
>    the same review styles and mechanisms?
>  * Are they on IRC?
>  * Do they use the mailing list for long running discussion?
>    ** If a project doesn't have long running discussions and as a result
>   does not have ML activity, I would see that as OK - my problem
>   would be with a team that ran their own list.
>  * Do they use standard devstack / -infra jobs for testing?
>  * Do they use the standard common libraries (where appropriate)?
> 
>  If a project fails this test (and would have been accepted as something
>  that drives the mission), I see no issue with the TC trying to bring
>  them into the fold by helping them work like one of us, and accepting
>  them when they have shown that they are willing to change how they
>  do things.
> 
>  For the "product" fit, it is a lot more subjective. We used to have a
>  system (pre Big Tent) where the TC picked "winners" in a space and
>  blessed one project as the way to do $thing. Then, in big tent we
>  started to not pick winners, and allow anyone who was one of us, and
>  had a "cloud" application.
> 
>  Recently, we have moved back to seeing if a project overlaps with
>  another. The real test for this (from my viewpoint) is if the
>  perceived overlap is an area that the team that is currently in
>  OpenStack is interested in pursuing - if not we should default to
>  adding the project.
> >>>
> >>> We've always considered overlap to some degree, but it has come up
> >>> more explicitly in a few recent discussions because of the nature
> >>> of the projects.  Please see the other thread on this topic [1].
> >>>
> >>> [1] 
> >>> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
> >>>
>  Personally, if the project adds something that we currently lack,
>  and have lacked for a long time (not to get too close to the current
>  discussion), or tries to reduce the amount of extra tooling that
>  deployers currently write in house, we should welcome them.
> 
>  The acid test for me is "How would I use this?" or "Have I written
>  tooling or worked somewhere that wrote tooling to do this?"
> 
>  If the answer is yes, it is a good indication that they fit with the
>  mission.
> >>>
> >>> This feels like the ideal open source approach, in which contributors
> >>> are "scratching their own itch." How can we encourage more deployers
> >>> and users of OpenStack to consider contributing their customization
> >>> and integration projects? Should we?
> >>
> >> I think a lot of our major users are good citizens and are doing some or
> >> all of this work in the open - we just have a discoverability issue.
> >>
> >> A lot of the benefit of joining the foundation as a project, is the
> >> increased visibility gained from it, so that others who are deploying
> >> OpenStack in a similar layout can find a project and use it.
> >>
> >> I think at the very least we should find a way to promote them (this
> >> is where constellations could really help, as we could add non member
> >> projects to constellations where they are appropriate.
> > 
> > Do you foresee any issues with adding unofficial projects to the
> > constellations?
> > 
> > Doug
> 
> No (from my viewpoint anyway) - I think they will be important to
> include in any true collection of use cases - for example we definitely
> will want to have a "PaaS" Constellation that includes things like
> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
> OpenStack works in the entire open source infrastructure community
> and not just how it works internally - and showing how you can use other
> open source software components *with* OpenStack is vital for that.

Would you make a distinction between things that have their own
community like kubernetes, and things that 

Re: [openstack-dev] [tc] campaign question related to new projects

[Chris Dent]

On Mon, 23 Apr 2018, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2018-04-23 12:09:42 +0100:

I'd like to see us work harder to refine the long term goals we are
trying to satisfy with the projects that make up OpenStack. This
will require us to continue the never-ending discussion about
whether OpenStack is a "Software Defined Infrastructure Framework"
or a "Cloud Solution" (plenty of people talk the latter, but plenty
of other people are spending energy on the former). And then


Do you consider those two approaches to be mutually exclusive?


No, but I do think how we balance and think about them them helps
us understand how to make progress.


In the past our community has had trouble defining "infrastructure"
in a way that satisfies everyone. Some people stop at "allocating
what you need to run a VM" while others consider it closer to
"everything you need to run an application".

How do you define "infrastructure"?


In this context I'm thinking of infrastructure in terms of plumbing,
using the plumbing and porcelain metaphor sometimes associted with
git:

https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

So in your terms "allocating what you need to run a VM" but with
some tweaks.

In Zane's response on this topic, he talks a lot about the
applications that are using the "cloud" and some of the additional
tooling that is needed to satisfy that (some of which might be
considered porcelain). Since my introduction to OpenStack that's
what I've hoped we are trying to build. An Open Source "Cloud
Solution" that enables a healthy application environment that is a
clear and complete alternative to the big three clouds.

However, over the years it has become increasingly evident that a
great deal of our energy is spent working at a different angle to
enable software defined data centers (including data centers that
are decomposed to the edge) that are hyper-aware of hardware and
networks and making that hardware available in the most cost
effective way possible. That's a useful thing to do but our
attention to it is not well aligned with building elastic web
services.

(In this particular case I'm speaking from experience perhaps
overly informed by Nova, where so much work is devoted to
NFV-related use cases. To such extent that people joke about
hardware defined software.)

While I don't think we need to say that we are doing one thing or
the other, we may make some decisions easier by being more willing
to identify which domain or perspective we are thinking about in any
given decision.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] campaign question related to new projects

[Jeremy Stanley]

On 2018-04-23 12:02:14 -0400 (-0400), Zane Bitter wrote:
[...]
> The main thing I will be looking out for in those cases is that
> the project followed the Four Opens *from the beginning*. Projects
> that start from a code dump are much less likely to attract other
> contributors in my view. Open Source is not a verb.
[...]

Not to add more noise, but I wanted to mention that I _really_ like
this point in particular. We've definitely seen plenty of
applications for inclusion which started out as an
internally-developed tool behind closed doors somewhere. When they
get "flung over the wall" to the community they tend to flounder in
their attempts to gain traction as properly open projects in their
own right. I don't think we do a good enough job at highlighting
this risk (yet), and will remember to point it out more often when I
spot it in the future. Thanks!
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

[Rico Lin]

*Thanks, Doug for bringing out this campaign questionI think we have a
start now with providing a decent map to show services in OpenStack and
fill in with projects. What we should have and will be nice is to ask
projects to search through the map (with a brief introduction of services)
when they're registering. To prevent overlapping from the very beginning
seems to be the most ideal, which might also mean it's actually our
responsibility to search through what exactly a project aims to and what
kind of feature it will provide when we allow people to register a project.
We can also discuss about to let projects know that we encourage new ideas
but we not encourage provides overlapping features just because you think
the service is bad and you don't like to fix it (IMO to encourage people to
point out problems and even try to fix it is very important when talking
about continuing efforts). And to give credits instead of warnings might
work better.* How (and whether) the community would be able to replace the
implementationof any given component with a new set of technologies by
"startingfrom scratch".With try to make such action as a long-term
community goal, might be possible to said we're able to do it (if this new
technology does matters, like containerize), and it might be even better
than wait for people to pick up the job and keep asking him `are we there
yet?`. We have to be really careful to prevent changing the behavior of
services or cause a huge burden to developers.* Where do you draw the line
at "gratuitous"?When a project is about more than 80% chances to dead or no
maintainer, and pure overlapping effort.* What benefits and drawbacks do
you see in supporting multiple toolswith similar features?It's good and
allow people from multiple tools to help construct the bridge to us
together. What I concern is we should try to decide a pattern and make it a
success instead of letting parallel jobs works on similar features. So we
can have a preview version of all other paths. And if we can make sure our
success path first, we can even look back and provide features plus bug
fixes to other tools. That brings a question back, `what're users using the
most?`* How would our community be different, in positive and negative
ways,if we were more strict about avoiding such overlap?To allow
concentrate our development energy on features, also to prevent lack of
diversity/ideas/activity for those projects we promise to provide guideline
when we allow them to stay under TC's governance. What we should also try
to prevent it when it's overlap but exists project didn't provide fair
communication or close their mind to new features/fixes. Which we should
strong/change part of our TC resolutions and prevent this because that
might just lead to a negative way that people quitting on providing new
innovation.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin


2018-04-23 21:50 GMT+08:00 Doug Hellmann :

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
>
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
>
> Where do you draw the line at "gratuitous"?
>
> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?
>
> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?
>
> Doug
>
> [1] https://governance.openstack.org/tc/reference/new-projects-
> requirements.html
>
> __
> 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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Rico Lin]

** What aspects of our policies or culture make contributing to
OpenStackmore difficult than contributing to other open source projects?To
fully understand the map of OpenStack services is a huge challenge,
especially for new join developers. And for project teams, might not
provide new contributors guidelines to be quicker to become part of the
team. Finally, the format or WG/SIG/Team might confuse contributors.* Which
of those would you change, and how?IMO to provides clear landscape will
help on give people better view on the whole map and might get the better
idea on how to fit in their plan without spending too much time on finding
where to contribute. Also, we need provides better ways to communicate to
new contributors to at least make them feel welcome. Which maybe we can try
to add in PTL/TC's (or other possible position) duty and to provide better
guidelines to new join contributors who seems got no clue on what's the
project been working on or where the project needs help. Only people we
really understand that project can provide such judgment, and it seems like
a duty to provide guidelines to others (Aka help people working with you).
Finally, I personally think it's a good idea to have SIG in OpenStack, but
I think we need to provide technical guidelines to SIGs, so they can make a
clear decision on what's their mission, where are the resources they can
use, and how they might be able to use it. A clear vision makes clear
actions.* Where else should we be looking for contributors?IMO we actually
got a bunch new contributors around OpenStack (mostly for nova and neutron
of course) and trying to figure out what they can/should do. Also possibly
from other projects which might be doing overlapping jobs. Also to form SIG
might be a more productive way to collect contributors.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin



2018-04-23 22:06 GMT+08:00 Doug Hellmann :

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?
>
> Doug
>
> __
> 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
>



-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] campaign question: How can we make contributing to OpenStack easier?

[Chris Dent]

On Mon, 23 Apr 2018, Tim Bell wrote:


One of the challenges in the academic sector is the time from
lightbulb moment to code commit. Many of the academic resource
opportunities are short term (e.g. PhDs, student projects,
government funded projects) and there is a latency in current
system to onboard, get the appropriate recognition in the
community (such as by reviewing other changes) and then get the
code committed.  This is a particular problem for the larger
projects where the patch is not in one of the project goal areas
for that release.


This. Many times over this.

The latency that a casual contributor may experience when
interacting with one of the larger OpenStack projects is
discouraging and a significant impedance mismatch for the
contributor.

One thing that might help is what I implied in one of my responses
elsewhere in Doug's collection of questions: Professional OpenStack
developers could be oriented towards enabling and attending to
casual contributors more than addressing feature development. This
is a large shift in how OpenStack is done, but makes sense in a
world where we are trying to maintain an existing and fairly mature
thing: We need maintainers.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] campaign question: How should we handle projects with overlapping feature sets?

[Zane Bitter]

On 23/04/18 09:50, Doug Hellmann wrote:

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

In the course of evaluating new projects that have asked to join
as official members of the OpenStack community, we often discuss
whether the feature set of the project overlaps too much with other
existing projects. This came up within the last year during Glare's
application, and more recently as part of the Adjutant application.

Our current policy regarding Open Development is that a project
should cooperate with existing projects "rather than gratuitously
competing or reinventing the wheel." [1] The flexibility provided
by the use of the term "gratuitously" has allowed us to support
multiple solutions in the deployment and telemetry problem spaces.
At the same time it has left us with questions about how (and
whether) the community would be able to replace the implementation
of any given component with a new set of technologies by "starting
from scratch".

Where do you draw the line at "gratuitous"?


I'd want to see sound technical reasons for taking a different approach 
that addresses, or partially addresses, the same problem. If people are 
starting their own projects to avoid having to work with the existing 
team then I'd label that gratuitous.


Evidence of co-operation with the existing project, and the provision of 
migration paths for existing operators and users, would be points in 
favour of a project wanting to go down this route.



What benefits and drawbacks do you see in supporting multiple tools
with similar features?

How would our community be different, in positive and negative ways,
if we were more strict about avoiding such overlap?


We used to have that rule, of course, and the primary result was that 
some folks who were for all intents and purposes part of our community 
got left out in the cold, officially speaking, only because some other 
folks got there first. I don't think it even contributed much to 
interoperability - Monasca is the project that comes to mind, and people 
who wanted to run that instead of Ceilometer did so regardless of the 
official status.


On the other hand, the Telemetry projects have completely transformed 
themselves since the days when people used to complain about the 
scalability of Ceilometer, and they did so while maintaining an orderly 
deprecation and migration of the APIs. Perhaps if if we'd doubled down 
on that path we'd have ended up with less fragmentation for the same 
benefit?


It's really hard to say, and I think that is perhaps the point. None of 
us have all that much confidence in our ability to predict the future, 
so we have chosen to err on the side of not picking winners.


cheers,
Zane.

__
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] campaign question: How can we make contributing to OpenStack easier?

[Chris Dent]

On Mon, 23 Apr 2018, Doug Hellmann wrote:


What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?


Size, isolation, and perfectionism.

Size in at least three dimensions:

* the entire community
* individual projects in terms of humans and scope
* individual projects in terms of lines of code (per repo and per
  file)

Isolation in at least two dimensions:

* For someone who is not "of OpenStack", OpenStack is kind of "over
  there, doing its own thing". Non-OpenStack colleagues wonder about
  the tempestuous teapot I'm in.

* Individual members of project teams sometimes self-identify as
  members of that that team, not of OpenStack.

Perfectionism:

* In at least some teams project teams (see, look at me
  identifying and isolating project teams) proposed specs and code
  can be nitpicked to death and forward progress delayed while every
  edge case is considered. We should strive to iterate more.

* At the same time there is too strong and attachment to master
  needing to be perfect. A bug on master is an invitation addressed
  to a potential new contributor.


Which of those would you change, and how?


I think we've started making a more conscious effort on all three of
these areas. We talk more often about incomplete bug fixes being
adopted experienced contributors. Decomposing repositories to harden
contractual and social boundaries is increasingly common. Actively
working with other communities (notably Kubernetes) is on the rise.

But there is plenty more to do in each of these areas.


Where else should we be looking for contributors?


I agree with Thierry that academia is a good place to look and that
we made a mistake when we highlighted and enforced an artificial
boundary between developers and operators. Ideally many features and
bug fixes would come from people who _use_ OpenStack as their day
job. The people who think of _developing_ OpenStack as their day job
should be most focused on enabling those other people and cleaning
up and refining what already exists.

I also think that we need to figure out, if possible, some way to
make OpenStack relevant and interesting to individuals who are
technically curious enough to want to try playing with their own
mini cloud at home. If we can make OpenStack accessible to amateurs
(not amateurish!) there's a big world of good input to come.
Something as one stop, integrated in the documentation and official
seeming as minikube is for Kubernetes.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Catching missing or stale package requirements in requirements.txt

[Ken Giusti]

Hi Folks,

Some of the Oslo libraries have a tox test that does the above [0].
This ensures that our requirements.txt file is kept current with the
code.

This test uses a tool called pip_check_reqs [1].  Unfortunately this
tool is not compatible with pip version 10, and it appears as if the
github project hasn't seen any development activity in the last 2
years.  Seems unlikely that pip 10 support will be added anytime soon.

Can anyone recommend a suitable alternative to the pip_check_reqs tool?

Thanks in advance,

[0] https://git.openstack.org/cgit/openstack/oslo.messaging/tree/tox.ini#n116
[1] https://github.com/r1chardj0n3s/pip-check-reqs
-- 
Ken Giusti  (kgiu...@gmail.com)

__
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] campaign question: How can we make contributing to OpenStack easier?

[Tim Bell]

One of the challenges in the academic sector is the time from lightbulb moment 
to code commit. Many of the academic resource opportunities are short term 
(e.g. PhDs, student projects, government funded projects) and there is a 
latency in current system to onboard, get the appropriate recognition in the 
community (such as by reviewing other changes) and then get the code committed. 
 This is a particular problem for the larger projects where the patch is not in 
one of the project goal areas for that release.

Not sure what the solution is but I would agree that there is a significant 
opportunity.

Tim

-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 23 April 2018 at 18:11
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

> Where else should we be looking for contributors?

Like other large open source projects, OpenStack has a lot of visibility
in the academic sector. I feel like we are less successful than others
in attracting contributions from there, and we could do a lot better by
engaging with them more directly.

-- 
Thierry Carrez (ttx)

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


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

Re: [openstack-dev] [tc] campaign question related to new projects

[Graham Hayes]

On 23/04/18 17:14, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
>> On 23/04/18 16:04, Doug Hellmann wrote:
>>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
 7On 20/04/18 22:26, Doug Hellmann wrote:
 
> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?
>
> Doug
>

 For me, the most important thing for a project that wants to join is
 that they act like "one of us" - what I think ttx refered to as "culture
 fit".

 This is fairly wide ranging, but includes things like:

 * Do they use the PTIs[0]
 * Do they use gerrit, or if they use something else, do they follow
   the same review styles and mechanisms?
 * Are they on IRC?
 * Do they use the mailing list for long running discussion?
   ** If a project doesn't have long running discussions and as a result
  does not have ML activity, I would see that as OK - my problem
  would be with a team that ran their own list.
 * Do they use standard devstack / -infra jobs for testing?
 * Do they use the standard common libraries (where appropriate)?

 If a project fails this test (and would have been accepted as something
 that drives the mission), I see no issue with the TC trying to bring
 them into the fold by helping them work like one of us, and accepting
 them when they have shown that they are willing to change how they
 do things.

 For the "product" fit, it is a lot more subjective. We used to have a
 system (pre Big Tent) where the TC picked "winners" in a space and
 blessed one project as the way to do $thing. Then, in big tent we
 started to not pick winners, and allow anyone who was one of us, and
 had a "cloud" application.

 Recently, we have moved back to seeing if a project overlaps with
 another. The real test for this (from my viewpoint) is if the
 perceived overlap is an area that the team that is currently in
 OpenStack is interested in pursuing - if not we should default to
 adding the project.
>>>
>>> We've always considered overlap to some degree, but it has come up
>>> more explicitly in a few recent discussions because of the nature
>>> of the projects.  Please see the other thread on this topic [1].
>>>
>>> [1] 
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
>>>
 Personally, if the project adds something that we currently lack,
 and have lacked for a long time (not to get too close to the current
 discussion), or tries to reduce the amount of extra tooling that
 deployers currently write in house, we should welcome them.

 The acid test for me is "How would I use this?" or "Have I written
 tooling or worked somewhere that wrote tooling to do this?"

 If the answer is yes, it is a good indication that they fit with the
 mission.
>>>
>>> This feels like the ideal open source approach, in which contributors
>>> are "scratching their own itch." How can we encourage more deployers
>>> and users of OpenStack to consider contributing their customization
>>> and integration projects? Should we?
>>
>> I think a lot of our major users are good citizens and are doing some or
>> all of this work in the open - we just have a discoverability issue.
>>
>> A lot of the benefit of joining the foundation as a project, is the
>> increased visibility gained from it, so that others who are deploying
>> OpenStack in a similar layout can find a project and use it.
>>
>> I think at the very least we should find a way to promote them (this
>> is where constellations could really help, as we could add non member
>> projects to constellations where they are appropriate.
> 
> Do you foresee any issues with adding unofficial projects to the
> constellations?
> 
> Doug

No (from my viewpoint anyway) - I think they will be important to
include in any true collection of use cases - for example we definitely
will want to have a "PaaS" Constellation that includes things like
Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
OpenStack works in the entire open source infrastructure community
and not just how it works internally - and showing how you can use other
open source software components *with* OpenStack is vital for that.

- Graham

>>
>>> Doug
>>>

 - Graham

 0 -
 https://governance.openstack.org/tc/reference/project-testing-interface.html
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

[Graham Hayes]

On 23/04/18 14:50, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
> 
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
> 
> Where do you draw the line at "gratuitous"?

Does the project basically promise "$OTHER_PROJECT but better"?
For example, for me, if a project re-created another projects API - I
would call that gratuitous.

> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?

It depends on the context - for example with deployment tooling,
companies may have pre existing DC orchestration tools, and having
and OpenStack deployment tool in $CONFIGMGMT can help people run
quicker.

Having 2 image stores, not so much, as there is then confusion about
what tool to deploy, or deploy both, and any issues may need to have 2
different solutions, or at least 2 patches.

There may be circumstances where 2 tools make sense (e.g. Messaging as a
Service did have 2 projects, but they served 2 different use cases, so
it made sense)

> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?

For deployment tooling - having the one true way to deploy OpenStack
would have made a lot of the work I have done in the last 4 or 5 years
redundant :) - We would probably be using bash scripts, but not having
people re-create the flow of installing OpenStack in $CFGMGMT_TOOL
de-jour in OpenStack may have focused resource. Or just forced
deployment teams out of OpenStack to somewhere else.

OS packing is definitely a good thing for duplication.

I don't think we have many service project areas that we have
duplication that would not have failed some of the stricter "culture
fit" discussions we have now had in the post Big Tent OpenStack.

We would have probably blocked things like Octavia (as Neutron LBaaS
existed), Designate (as Nova DNS was a thing back then), Monasca,
Neutron itself (as Nova Network was a thing).

> Doug
> 
> [1] 
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
> 
> __
> 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
> 



signature.asc
Description: OpenPGP 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] [tc] campaign question related to new projects

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200:
>> For the product fit, there is also a lot of room for interpretation. For
>> me it boils down to whether "OpenStack" (the product) is better with
>> that project "in" rather than with that project "out". Sometimes it's an
>> easy sell: if a group wants to collaborate on packaging OpenStack for a
>> certain format/distro/deployment tool, it's clearly a win. In that case>> 
>> more is always better. But in most cases it's not as straightforward.
>> There is always tension between added functionality on one side, and
>> complexity / dilution / confusion on the other. Every "service" project
>> we add makes OpenStack more complex to explain, cross-project work more
>> difficult and interoperability incrementally harder. Whatever is added
>> has to be damn interesting to counterbalance that. The same goes for
> 
> Why do you think OpenStack has more trouble explaining our feature set
> than other cloud systems that have a similarly diverse array of
> features?

You mean compared to AWS ? It's not the same thing to explain a set of
APIs to end users of the cloud and to describe available components to
the deployers of the cloud, especially newcomers. For example, Zun API
users don't have to know if it relies on Heat, Magnum or Nova to
actually do its magic behind the scenes. A Zun deployer absolutely needs
to know that.

I hope that the Constellation concept will help the latter traverse our
product map more efficiently.

-- 
Thierry Carrez (ttx)

__
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] campaign question related to new projects

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
> On 23/04/18 16:04, Doug Hellmann wrote:
> > Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
> >> 7On 20/04/18 22:26, Doug Hellmann wrote:
> >> 
> >>> Without letting the conversation devolve too much into a discussion
> >>> of Adjutant's case, please talk a little about how you would evaluate
> >>> a project's application in general.  What sorts of things do you
> >>> consider when deciding whether a project "aligns with the OpenStack
> >>> Mission," for example?
> >>>
> >>> Doug
> >>>
> >>
> >> For me, the most important thing for a project that wants to join is
> >> that they act like "one of us" - what I think ttx refered to as "culture
> >> fit".
> >>
> >> This is fairly wide ranging, but includes things like:
> >>
> >> * Do they use the PTIs[0]
> >> * Do they use gerrit, or if they use something else, do they follow
> >>   the same review styles and mechanisms?
> >> * Are they on IRC?
> >> * Do they use the mailing list for long running discussion?
> >>   ** If a project doesn't have long running discussions and as a result
> >>  does not have ML activity, I would see that as OK - my problem
> >>  would be with a team that ran their own list.
> >> * Do they use standard devstack / -infra jobs for testing?
> >> * Do they use the standard common libraries (where appropriate)?
> >>
> >> If a project fails this test (and would have been accepted as something
> >> that drives the mission), I see no issue with the TC trying to bring
> >> them into the fold by helping them work like one of us, and accepting
> >> them when they have shown that they are willing to change how they
> >> do things.
> >>
> >> For the "product" fit, it is a lot more subjective. We used to have a
> >> system (pre Big Tent) where the TC picked "winners" in a space and
> >> blessed one project as the way to do $thing. Then, in big tent we
> >> started to not pick winners, and allow anyone who was one of us, and
> >> had a "cloud" application.
> >>
> >> Recently, we have moved back to seeing if a project overlaps with
> >> another. The real test for this (from my viewpoint) is if the
> >> perceived overlap is an area that the team that is currently in
> >> OpenStack is interested in pursuing - if not we should default to
> >> adding the project.
> > 
> > We've always considered overlap to some degree, but it has come up
> > more explicitly in a few recent discussions because of the nature
> > of the projects.  Please see the other thread on this topic [1].
> > 
> > [1] 
> > http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
> > 
> >> Personally, if the project adds something that we currently lack,
> >> and have lacked for a long time (not to get too close to the current
> >> discussion), or tries to reduce the amount of extra tooling that
> >> deployers currently write in house, we should welcome them.
> >>
> >> The acid test for me is "How would I use this?" or "Have I written
> >> tooling or worked somewhere that wrote tooling to do this?"
> >>
> >> If the answer is yes, it is a good indication that they fit with the
> >> mission.
> > 
> > This feels like the ideal open source approach, in which contributors
> > are "scratching their own itch." How can we encourage more deployers
> > and users of OpenStack to consider contributing their customization
> > and integration projects? Should we?
> 
> I think a lot of our major users are good citizens and are doing some or
> all of this work in the open - we just have a discoverability issue.
> 
> A lot of the benefit of joining the foundation as a project, is the
> increased visibility gained from it, so that others who are deploying
> OpenStack in a similar layout can find a project and use it.
> 
> I think at the very least we should find a way to promote them (this
> is where constellations could really help, as we could add non member
> projects to constellations where they are appropriate.

Do you foresee any issues with adding unofficial projects to the
constellations?

Doug

> 
> > Doug
> > 
> >>
> >> - Graham
> >>
> >> 0 -
> >> https://governance.openstack.org/tc/reference/project-testing-interface.html
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 

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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Thierry Carrez]

Doug Hellmann wrote:
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
> 
> Which of those would you change, and how?

Our focus for the past 7 years was on handling the enormous growth of
the OpenStack project. If you asked me in 2010 how many total code
contributors we'd have by 2018, my answer would probably have been
closer to 700 than to 7000. We've built systems and processes to sustain
that growth, and we were very successful at it.

The issue is that systems and processes designed to sustain times of
inflation do not work so well in a deflation period, or even a
stagnation period. It's urgent now to have a critical look at them, see
what is useful and what is a scale optimization we could do away with.

Our largest reserve of potential contributors lies in the vast number of
users we have. In my opinion, one of the mistakes we made was to create
an "operators" community separate from the "developers" community,
almost in reaction to it. That makes it more difficult to smoothly
transition users into contributors and ultimately into code
contributions. Melvin and I have been busy over the past two cycles
fixing that in various ways, but there is still a lot of work to do.

> Where else should we be looking for contributors?

Like other large open source projects, OpenStack has a lot of visibility
in the academic sector. I feel like we are less successful than others
in attracting contributions from there, and we could do a lot better by
engaging with them more directly.

-- 
Thierry Carrez (ttx)

__
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] campaign question: How should we handle projects with overlapping feature sets?

[Chris Dent]

On Mon, 23 Apr 2018, Doug Hellmann wrote:


Where do you draw the line at "gratuitous"?

What benefits and drawbacks do you see in supporting multiple tools
with similar features?

How would our community be different, in positive and negative ways,
if we were more strict about avoiding such overlap?


This is a tough question. We've held API stability and
interoperability as such important factors that any discussion of
overlapping of competing projects has to consider whether we are
willing to bend on that. It's also never been entirely clear the
extent to which new projects eat into the resource pool that is
available to existing projects. But if we set aside those issues for
a moment:

I would say that "gratuitous" overlap would be when a project wants
to provide a service similar to one that already exists and has
failed utterly to engage with the existing service. It would not,
however, be gratuitous if a potential project, after presenting their
alternate proposal to the similar project and getting a "not
interested" or "we can't attend to that any time in the next
$TIME_PERIOD", chose to go ahead.

For example, one can imagine a world where someone thinks up a
project to create a different service for managing VMs. One that
intends to "innovate" in the compute API space (breaking
compatibility with nova's API) and manage compute nodes using etcd
in a way somewhat like Kubernetes. Nova is approached and says
"yeah, interesting, but not going to happen, we are booked up solid
for the next two years". If the people involved in the potential
project are numerous and diverse enough to have a chance of getting
something done, then I think they should be encouraged, for the sake
of innovation, diversity, attracting new contributors and
leapfrogging ourselves into the future.

It's quite likely that during discussions a "compute api v2.x
compatibility layer" would be negotiated.

A real world example where things could have gone better is with
Mogan: https://review.openstack.org/#/c/508400/

There are some fairly obvious costs from overlapping projects:

* potential drains on the resource pool
* confusion and churn for people downstream (packagers, client
  makers, deployers, every day users)

These are potentially countered by:

* new or rejuvenated contributors, inspired by new stuff
* advancements in capability provided by new technologies
* a potential for positive and collaborative competition between the
  two related projects

People's needs evolve and change. OpenStack needs to as well.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] campaign question related to new projects

[Zane Bitter]

On 20/04/18 17:26, Doug Hellmann wrote:

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]


Thanks Doug, I think this is a really helpful question.


We are discussing adding at least one new project this cycle, and
the specific case of Adjutant has brought up questions about the
criteria we use for evaluating new projects when they apply to
become official.  Although the current system does include some
well-defined requirements [1], it was also designed to rely on TC
members to use their judgement in some other areas, to account for
changing circumstances over the life of the project and to reflect
the position that governance is not something we can automate away.

Without letting the conversation devolve too much into a discussion
of Adjutant's case, please talk a little about how you would evaluate
a project's application in general.  What sorts of things do you
consider when deciding whether a project "aligns with the OpenStack
Mission," for example?

Doug

[1] https://governance.openstack.org/tc/reference/new-projects-requirements.html



The first thing to mention is that I take a fairly expansive view of 
what IaaS comprises. (For example, I think a message queue like Zaqar is 
a critical component of an IaaS, which often surprises people, but how 
can an application use its infrastructure as a server without 
notifications about what's going on in the infrastructure? I guess we 
could try to optimise for polling in a thousand different places, but 
it's much simpler to expose events in one place and optimising polling 
of that.) A while back[1] I threw together a non-exhaustive list of the 
kinds of goals I think OpenStack should be working towards:


* Infinite scaling - the ability in principle to scale from zero to an 
arbitrarily large number of users without rewriting your application 
(e.g. if your application can store one file in Swift then there's no 
theoretical limit to how many it can store. c.f. Cinder where at some 
point you'd have to start juggling multiple volumes.)
* Granularity of allocation - pay only for the resources you actually 
use, rather than to allocate a chunk that you may or may not be using 
(so Nova->containers->FaaS, Cinder->Swift, Trove->??? [RIP MagnetoDB], )
* Full control of infrastructure - notwithstanding the above, maintain 
Nova/Cinder/Neutron/Trove/ so that legacy applications, highly 
specialised applications, and higher-level services like PaaS can make 
fully customised use of the virtual infrastructure.
* Hardware virtualisation - make anything that might typically be done 
in hardware available in a multi-tenant software-defined environment: 
servers, routers, load balancers, firewalls, video codecs, GPGPUs, FPGAs...
* Built-in reliability - don't require even the smallest apps to have 3 
VMs + a cluster manager to enforce any reliability guarantees; provide 
those guarantees using multi-tenant services that efficiently share 
resources between applications (see also: Infinite scaling, Granularity 
of allocation).
* Application control - (securely) give applications control over their 
own infrastructure, so that no part of the application needs to reside 
outside of the cloud.
* Integration - cloud services that effectively form part of the user's 
application can communicate amongst themselves, where appropriate, 
without the need for client-side glue (see also: Built-in reliability).
* Interoperability - the same applications can be deployed on a variety 
of private and public OpenStack clouds.


I'm definitely not claiming to have captured the full range of 
possibilities there (notably it doesn't attempt to cover e.g. 
deployment-related projects), but at a minimum any project contributing 
to one or more of those points is something I would consider to be 
aligned with OpenStack's mission. (That, of course, is only one of 
several criteria that are considered.)


I would love to see us have a conversation as a community to figure out 
what we all, collectively, think that list should look like and document 
it. Ideally new projects shouldn't have to wait until they've applied to 
join OpenStack to get a sense of whether we believe they're furthering 
our mission or not.


To be clear, although I don't expect it to come up, something like a 
PaaS (think CloudFoundry, or OpenShift) would be *not* be in-scope for 
OpenStack in my view. (We should definitely to encourage them to 
integrate with Keystone anyway though!)


One thing I think the TC needs to be wary of is that at this stage of 
maturity there may be a temptation to engage in a sort of 'regulatory 
arbitrage': to try to land your pet feature wherever it's easiest to get 
it accepted, rather than where it makes the most technical sense. 
Indulging that temptation works against interoperability, which is a 
critical 

Re: [openstack-dev] [ironic] Monthly bug day?

[Sam Betts (sambetts)]

100% on board with this, I think it was really productive!

Sam

On 23/04/2018, 15:44, "Jim Rollenhagen" 
> wrote:

On Mon, Apr 23, 2018 at 8:04 AM, Michael Turek 
> wrote:
Hey everyone!

We had a bug day about two weeks ago and it went pretty well! At last week's 
IRC meeting the idea of having one every month was thrown around.

What does everyone think about having Bug Day the first Thursday of every month?

I'd totally support a monthly bug day! I'm not sure Thursday is the best day 
for me but I may be able to make it work.

// 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

Re: [openstack-dev] [tc] campaign question related to new projects

[Sean McGinnis]

> > 
> > I think one of the important things is if it fits in to furthering what is
> > "OpenStack", as far as whether it is a service or functionality that is 
> > needed
> > and useful for those running an OpenStack cloud. This is one of the parts 
> > that
> > may be more on the subjective side. We need to see that adding the new 
> > project
> > in question will enhance the use or operation of an OpenStack environment.
> 
> What do you think we can do to be better informed about whether
> something is actually useful, or just appears useful?
> 

This is definitely a tricky part. We need to be willing to get out and make
connections outside of our small group and learn what we can about how things
are used in the real world. This is one of the main reasons I've been involved
in the ops meetups. I want to be able to hear directly from the folks running
OpenStack clouds what their challenges are and how they are addressing those
challenges today. That helps inform later decisions about whether some new
service fits in with what they need, or if it would be something that doesn't
actually fit with what is commonly done.

> > 
> > There is the question about overlap with existing projects. While I think 
> > it's
> > true that a new project can come along that meets a need in a better way 
> > than
> > an existing solution, I think that bar needs so be raised a lot higher. I
> > personally would much rather see resources joining together on an existing
> > solution than a bunch of resources used to come up with a competing 
> > solution.
> > Even with a less than ideal solution, there is a lot that is learned from 
> > the
> > process that can be fed into and combined with new ideas to create a better
> > solution than just having a new replacement.
> 
> Where should we draw the line with building something new and using
> tools available from other communities?
> 

Fighting "not invented here" tendencies is always a challenge. There's usually
no clear line with these things from my experience. I think we need to be
willing to take a look at what something is trying to solve, and able to take a
look around and see if there is already something solving it, or doing
something close enough to be easily adapted to fit our specific usage.

Even if there is a potential existing tool available, we also need to evaluate
whether that tools technology (programming language, platform, etc) fit and
whether its community is compatible enough with our. For example, are they
willing to work with outside consumers like us that may have some different
needs than their current user base? Are they an open community and not a vendor
of a proprietary tool?

__
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] campaign question: How "active" should the TC be?

[Chris Dent]

On Mon, 23 Apr 2018, Doug Hellmann wrote:


We frequently have discussions about whether the TC is active enough,
in terms of driving new policies, technology choices, and other
issues that affect the entire community.


Another good question. Like all the others I wish they had come a
bit earlier so that we had more time to deliberate and converse
before the elections start tonight. These deserve considerable
thought.

I hope it's no secret that I think the TC should be more active in
its leadership, both technically and culturally. Often the TC
operates as a kind of supreme court, leading from behind. Since I
joined the community four years ago I've often wished for a more
unified leadership from the front, and I think the representative
model provided by the TC (a model which transcends the individual
projects and concentrates on the bigger picture) could provide
that if we want it to.


Please describe one case where we were either active or reactive
and how that was shown to be the right choice over time.

Please describe another case where the choice to be active or
reactive ended up being the wrong choice.


I think the recent process which eventually led to clarification on
interop testing at https://review.openstack.org/#/c/550571/ is a
relatively good example of what might be described as active
reaction. Through consultation with many involved parties we changed
the rules to better reflect reality and support projects more
effectively.

At the same time, we failed to act quickly enough on the same topic
with https://review.openstack.org/#/c/521602/ , where though some
parties had identified some clear problems, the TC (as a group)
failed to act in a timely fashion (there's a nearly two month gap
with no comments) to resolve them, in part because there wasn't
agreement that it was a domain that the TC should legislate.

My feeling is that if technical contributors to OpenStack are
involved, then that's a place where the TC can and should engage.


If you think the TC should tend to be more active in driving change
than it is today, please describe the changes (policy, culture,
etc.) you think would need to be made to do that effectively (not
which policies you want us to be more active on, but *how* to
organize the TC to be more active and have that work within the
community culture).


Despite my use of the term "legislate" above I think Howard's idea
of "a new direction outlook per cycle or per year" is a critical
aspect of what the TC should be doing. Setting tone and overarching
themes to help distinguish between what matters and what does not
matter. The vision statement was somewhat useful in this regard, but
we also need something that is more immediate term: thematic goals
for this cycle. OpenStack-wide goals are also helpful, but they tend
to be very specific and don't do much to help answer "no" to the
question: "is this thing I'm considering aligned with the current
themes?"

We've talked in the past about using time at the PTG to express
these themes but I think we need to do more than that. As you
(Doug), have said before: We need to habituate people to where they
can reliably find and discover information about what matters. This
will often mean what feels like a lot of repetition.

It will take effort to make these kinds of changes. We are large
enough now, and vest so much power and self-determination in the
individual projects, that it will take a lot of convincing and
orchestrating to make a significant culture change that aligns us on
common goals.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] campaign question related to new projects

[Graham Hayes]

On 23/04/18 16:04, Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
>> 7On 20/04/18 22:26, Doug Hellmann wrote:
>> 
>>> Without letting the conversation devolve too much into a discussion
>>> of Adjutant's case, please talk a little about how you would evaluate
>>> a project's application in general.  What sorts of things do you
>>> consider when deciding whether a project "aligns with the OpenStack
>>> Mission," for example?
>>>
>>> Doug
>>>
>>
>> For me, the most important thing for a project that wants to join is
>> that they act like "one of us" - what I think ttx refered to as "culture
>> fit".
>>
>> This is fairly wide ranging, but includes things like:
>>
>> * Do they use the PTIs[0]
>> * Do they use gerrit, or if they use something else, do they follow
>>   the same review styles and mechanisms?
>> * Are they on IRC?
>> * Do they use the mailing list for long running discussion?
>>   ** If a project doesn't have long running discussions and as a result
>>  does not have ML activity, I would see that as OK - my problem
>>  would be with a team that ran their own list.
>> * Do they use standard devstack / -infra jobs for testing?
>> * Do they use the standard common libraries (where appropriate)?
>>
>> If a project fails this test (and would have been accepted as something
>> that drives the mission), I see no issue with the TC trying to bring
>> them into the fold by helping them work like one of us, and accepting
>> them when they have shown that they are willing to change how they
>> do things.
>>
>> For the "product" fit, it is a lot more subjective. We used to have a
>> system (pre Big Tent) where the TC picked "winners" in a space and
>> blessed one project as the way to do $thing. Then, in big tent we
>> started to not pick winners, and allow anyone who was one of us, and
>> had a "cloud" application.
>>
>> Recently, we have moved back to seeing if a project overlaps with
>> another. The real test for this (from my viewpoint) is if the
>> perceived overlap is an area that the team that is currently in
>> OpenStack is interested in pursuing - if not we should default to
>> adding the project.
> 
> We've always considered overlap to some degree, but it has come up
> more explicitly in a few recent discussions because of the nature
> of the projects.  Please see the other thread on this topic [1].
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
> 
>> Personally, if the project adds something that we currently lack,
>> and have lacked for a long time (not to get too close to the current
>> discussion), or tries to reduce the amount of extra tooling that
>> deployers currently write in house, we should welcome them.
>>
>> The acid test for me is "How would I use this?" or "Have I written
>> tooling or worked somewhere that wrote tooling to do this?"
>>
>> If the answer is yes, it is a good indication that they fit with the
>> mission.
> 
> This feels like the ideal open source approach, in which contributors
> are "scratching their own itch." How can we encourage more deployers
> and users of OpenStack to consider contributing their customization
> and integration projects? Should we?

I think a lot of our major users are good citizens and are doing some or
all of this work in the open - we just have a discoverability issue.

A lot of the benefit of joining the foundation as a project, is the
increased visibility gained from it, so that others who are deploying
OpenStack in a similar layout can find a project and use it.

I think at the very least we should find a way to promote them (this
is where constellations could really help, as we could add non member
projects to constellations where they are appropriate.

> Doug
> 
>>
>> - Graham
>>
>> 0 -
>> https://governance.openstack.org/tc/reference/project-testing-interface.html
> 
> __
> 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
> 



signature.asc
Description: OpenPGP 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] [tc] campaign question: How can we make contributing to OpenStack easier?

[Graham Hayes]

On 23/04/18 15:06, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?

Our scale.

To get a large feature merged can require get code
prioritised by 2 or 3 different teams, and merged into any number of
repositories.

To get a small feature merged on some projects can take some time as
well, purely from the amount of code that is submitted for review to
these projects.

> Which of those would you change, and how?

Well, I definitely wouldn't change our scale. What I think we need to is
start breaking down some of the gigantic mono repos we have, so that
reviewing a small feature does not need large amounts of contextual
knowledge. I think this is happening organically in some teams already
with a few teams completely plugin based and distributed (like the docs
team).

When code can be reviewed in isolation without the fear of breaking
something 2 projects away, it helps both review time, and new
contributor experience.

> Where else should we be looking for contributors?

Honestly, I don't know. The kind of work that our contributors do, does
require a certain level of equipment, and "upstream time" that makes any
serious feature development hard for a casual weekend contributor.

> Doug
> 
> __
> 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
> 



signature.asc
Description: OpenPGP 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] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jeremy Stanley]

On 2018-04-23 15:36:32 +0100 (+0100), Graham Hayes wrote:
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
> 
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.
> 
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
> 
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.
[...]

Taking this further, I really think that the spirit of our
requirement that certain member organizations dedicate staff to
contributing is that they be applied to under-served commons in the
project (whether that's helping in horizontal teams and on
cross-project goals, or triaging bugs and answering random usage
questions). If they get to count the staff they put on some feature
they needed for their new product launch, that's rather self-serving
and doesn't really help us much.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-23 15:36:32 +0100:
> On 18/04/18 11:38, Chris Dent wrote:
> > On Tue, 17 Apr 2018, Thierry Carrez wrote:
> > 
> >> So... Is there any specific topic you think we should cover in that
> >> meeting ?
> > 
> > The topics:
> > 
> > 1. What are we to do, as a community, when external pressures for
> > results are not matched by contribution of resources to produce
> > those results? There are probably several examples of this, but one
> > that I'm particularly familiar with is the drive to be able to
> > satisfy complex hardware topologies demanded by virtual network
> > functions and related NFV use cases. Within nova, and I suspect other
> > projects, there is intense pressure to make progress and intense
> > effort that is removing resources from other areas. But the amount
> > of daily, visible contribution from the interest companies [1] is
> > _sometimes_ limited. There are many factors in this, and obviously
> > "throw more people at it" is not a silver bullet, but there are
> > things to talk about here that need the input from all the segments.
> > 
> > 2. We've made progress of late with acknowledging the concepts
> > and importance of casual contribution and "drive-by bug fixing" in
> > our changing environment. But we've not yet made enough progress in
> > changing the way we do work. Corporate foundation members need to be
> > more aware and more accepting that the people they provide to work
> > "mostly upstream" need to be focused on making other people capable
> > of contribution. Not on getting features done. And those of us who
> > do have the privilege of being "mostly upstream" need to adjust our
> > priorities.
> > 
> > Somewhere in that screed are, I think, some things worth talking
> > about, but they need to be distilled out.
> > 
> > [1] http://superuser.openstack.org/articles/5g-open-source-att/
> 
> 
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
> 
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.

A while back Jay Pipes suggested that we ask contributing companies
to summarize their work. I think that was in the context of
understanding what platinum members are doing, but it could apply
to everyone. By leaving the definition of "contribution" open-ended
and asking as a way to celebrate those contributions, we could avoid
any sense of shaming as well as see what the companies consider to
be important.

> 
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
> 
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.

This topic has come up a few times. I wonder if we could get more
traction here if we had details about how attempts in the past have
failed ("person X was given 6 months to train on the team before
being moved to a different project", etc.)? Pulling together that
sort of information might take longer than we have between now and
the Vancouver meeting.

I also anticipate the board's response being, "Tell us what you need
done." so we should have an answer to that, even if it's just "we need
help with ideas, let's form a working group".

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

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

Re: [openstack-dev] [tc] campaign question related to new projects

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
> 7On 20/04/18 22:26, Doug Hellmann wrote:
> 
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> > 
> > Doug
> > 
> 
> For me, the most important thing for a project that wants to join is
> that they act like "one of us" - what I think ttx refered to as "culture
> fit".
> 
> This is fairly wide ranging, but includes things like:
> 
> * Do they use the PTIs[0]
> * Do they use gerrit, or if they use something else, do they follow
>   the same review styles and mechanisms?
> * Are they on IRC?
> * Do they use the mailing list for long running discussion?
>   ** If a project doesn't have long running discussions and as a result
>  does not have ML activity, I would see that as OK - my problem
>  would be with a team that ran their own list.
> * Do they use standard devstack / -infra jobs for testing?
> * Do they use the standard common libraries (where appropriate)?
> 
> If a project fails this test (and would have been accepted as something
> that drives the mission), I see no issue with the TC trying to bring
> them into the fold by helping them work like one of us, and accepting
> them when they have shown that they are willing to change how they
> do things.
> 
> For the "product" fit, it is a lot more subjective. We used to have a
> system (pre Big Tent) where the TC picked "winners" in a space and
> blessed one project as the way to do $thing. Then, in big tent we
> started to not pick winners, and allow anyone who was one of us, and
> had a "cloud" application.
> 
> Recently, we have moved back to seeing if a project overlaps with
> another. The real test for this (from my viewpoint) is if the
> perceived overlap is an area that the team that is currently in
> OpenStack is interested in pursuing - if not we should default to
> adding the project.

We've always considered overlap to some degree, but it has come up
more explicitly in a few recent discussions because of the nature
of the projects.  Please see the other thread on this topic [1].

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html

> Personally, if the project adds something that we currently lack,
> and have lacked for a long time (not to get too close to the current
> discussion), or tries to reduce the amount of extra tooling that
> deployers currently write in house, we should welcome them.
> 
> The acid test for me is "How would I use this?" or "Have I written
> tooling or worked somewhere that wrote tooling to do this?"
> 
> If the answer is yes, it is a good indication that they fit with the
> mission.

This feels like the ideal open source approach, in which contributors
are "scratching their own itch." How can we encourage more deployers
and users of OpenStack to consider contributing their customization
and integration projects? Should we?

Doug

> 
> - Graham
> 
> 0 -
> https://governance.openstack.org/tc/reference/project-testing-interface.html

__
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] campaign question: How should we handle projects with overlapping feature sets?

[Thierry Carrez]

Doug Hellmann wrote:
> Where do you draw the line at "gratuitous"?

The way I interpret "gratuitous" here is: is the new project using a
technically-different approach to the same problem, or is it just
another group working at the same problem in the same way ? Is the new
project just a way to avoid openly collaborating with the existing group
? Is the new project just a way for a specific organization (or group of
organizations) to create something they have more control over ? That
would be gratuitous duplication, not motivated by a technical reason.

We don't really want copies or forks of projects that are just running
around the current group in charge. That should be solved at the
governance level (and it's the TC's role to address that).

> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?

I touched on that point a bit in my answer on considering new projects.
Allowing competition gives you options and lets a thousand flowers
bloom, but at the cost of adding complexity / dilution / confusion to
the "product" and making interoperability generally more difficult.

Generally, the closer to the "core" you are, the less competition you
should allow. It's OK to have multiple options for operational tooling
or deployment. It's less OK to have two Keystones that every component
now needs to be compatible with. Of course teh area between those two
extremes is all shades of grey.

> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?

I feel like we have been pretty strict with competitive projects. I fear
that being stricter would completely close the door to potential evolution.

-- 
Thierry Carrez (ttx)

__
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] campaign question related to new projects

[Doug Hellmann]

Excerpts from Chris Dent's message of 2018-04-23 12:09:42 +0100:
> On Fri, 20 Apr 2018, Doug Hellmann wrote:
> 
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> 
> Thanks for getting the ball rolling on some discussion, Doug.
> 
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> 
> This is an important question because project applications are one
> of the few ways in which the TC exercises any direct influence over
> the shape and direction of OpenStack. Much of the rest of the time
> the TC's influence is either indirect or limited. That's something I
> think we should change, in part because I feel the role of the TC
> should be at least as, if not more, focused on the day-to-day
> experiences and capabilities of existing contributors as it is on
> new ones.

Please see my other question about the role of the TC, and being active
or reactive. [1]

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129658.html

> I prefer that we keep a large human factor involved in the
> application process. I do not want us to be purely objective because
> such a process can never take into account the wider and ever
> changing world. The members of the TC can be human info sponges that
> do that accounting. The current process was created in part to
> overcome the far too heavy and nitpicking (and human) previous
> process but it has resulted in what amounts to a dilution in
> direction.
> 
> For me, each application tends to result in a lot of questions such
> as the list I produced on patchset 34 of the Adjutant review[1]. I
> worry that we are predisposed to accept applicants out of a general
> sense of being "nice" and a belief that growth is a sign of health.
> I'm unsure how these behaviors help to drive OpenStack in its
> mission, but while the rules [2] say something as broad as
> 
>   It should help further the OpenStack mission, by providing a
>   cloud infrastructure service, or directly building on an
>   existing OpenStack infrastructure service.
> 
> I feel we're painted into something of a corner where acceptance
> must be the default unless there are egregious interoperability or
> "four opens" violations.
> 
> I'd like to see us work harder to refine the long term goals we are
> trying to satisfy with the projects that make up OpenStack. This
> will require us to continue the never-ending discussion about
> whether OpenStack is a "Software Defined Infrastructure Framework"
> or a "Cloud Solution" (plenty of people talk the latter, but plenty
> of other people are spending energy on the former). And then

Do you consider those two approaches to be mutually exclusive?

In the past our community has had trouble defining "infrastructure"
in a way that satisfies everyone. Some people stop at "allocating
what you need to run a VM" while others consider it closer to
"everything you need to run an application".

How do you define "infrastructure"?

> actually follow through: using the outcome of those discussions to
> impact not just projects that we accept but also where existing
> project focus their attention. We need to be as capable of saying
> an informed "no" as we are of saying "yes".
> 
> In the modern OpenSource world there are so many different
> ecosystems that are cloud friendly: We don't need to provide a home
> for everyone. There are plenty of places for people to go, including
> the many different (and growing) facets of the OpenStack community.
> I would prefer that we be assertive in how we evaluate for alignment
> with the OpenStack mission. Doing that requires fairly constant
> re-evaluation of the mission and a willingness to accept that it
> does (and must) change.
> 
> [1] https://review.openstack.org/#/c/553643/
> [2] 
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
> 

__
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] campaign question related to new projects

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2018-04-22 21:01:46 -0500:
> > 
> > We are discussing adding at least one new project this cycle, and
> > the specific case of Adjutant has brought up questions about the
> > criteria we use for evaluating new projects when they apply to
> > become official.  Although the current system does include some
> > well-defined requirements [1], it was also designed to rely on TC
> > members to use their judgement in some other areas, to account for
> > changing circumstances over the life of the project and to reflect
> > the position that governance is not something we can automate away.
> > 
> 
> Good question to get the conversation going Doug. This is an interesting point
> that I think will require some longer term discussions.
> 
> It would be nice if we can narrow this down to a more defined decision tree,
> but I also think it may be too difficult to get to the point where it is
> something that can be that black and white. For better or worse, I do think
> there is some subjective evaluation that is required for each of these so far.
> 
> I think following our four opens is the basis for most decisions. They need to
> be developing projects in an open way, and open to community involvement with
> the implementation and direction of the project, as a basic starting point. If
> they are not willing to follow these basic principles then I think it is an
> easy decision to not go any further from there.
> 
> We do care about diversity in contributors. I think it is very important for
> the long term health of a project to have multiple interests involved. But I 
> do
> not consider this a bar to entry. I think it is perfectly OK for a new (but
> open) project to come in with the majority of the work coming from one vendor.
> As long as they are open and willing to get others involved in the development
> of the project, then it is good. And at least sometimes, starting off is
> sometimes better with one perspective driving things toward a focused 
> solution.
> 
> I think one of the important things is if it fits in to furthering what is
> "OpenStack", as far as whether it is a service or functionality that is needed
> and useful for those running an OpenStack cloud. This is one of the parts that
> may be more on the subjective side. We need to see that adding the new project
> in question will enhance the use or operation of an OpenStack environment.

What do you think we can do to be better informed about whether
something is actually useful, or just appears useful?

> 
> There is the question about overlap with existing projects. While I think it's
> true that a new project can come along that meets a need in a better way than
> an existing solution, I think that bar needs so be raised a lot higher. I
> personally would much rather see resources joining together on an existing
> solution than a bunch of resources used to come up with a competing solution.
> Even with a less than ideal solution, there is a lot that is learned from the
> process that can be fed into and combined with new ideas to create a better
> solution than just having a new replacement.

Where should we draw the line with building something new and using
tools available from other communities?

> 
> There's probably a lot more that can be said about all of this, but that's my
> initial take. Looking forward to seeing what everyone else has to say and
> learning from how we are the same and how we are different on this topic.
> 
> Sean
> 

__
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] campaign question related to new projects

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200:
> Doug Hellmann wrote:
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> > 
> > We are discussing adding at least one new project this cycle, and
> > the specific case of Adjutant has brought up questions about the
> > criteria we use for evaluating new projects when they apply to
> > become official.  Although the current system does include some
> > well-defined requirements [1], it was also designed to rely on TC
> > members to use their judgement in some other areas, to account for
> > changing circumstances over the life of the project and to reflect
> > the position that governance is not something we can automate away.
> > 
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> 
> Thanks for getting the discussion started, Doug.
> 
> We have two main criteria in the requirements. The "follows the
> OpenStack way" one, which I call the culture fit, and the "aligns with
> the OpenStack mission" one, which I call the product fit. In both cases
> there is room for interpretation and for personal differences in
> appreciation.
> 
> For the culture fit, while in most cases its straightforward (as the
> project is born out of our existing community members), it is sometimes
> much more blurry. When the group behind the new project is sufficiently
> disjoint from our existing team members, you are judging a future
> promise to behave in "the OpenStack way". In those cases it's really an
> opportunity to reach out and explain how and why we do things the way we
> do them, the principles behind our community norms. In the end it's a
> leap of faith. The line I personally stand on is the willingness to
> openly collaborate. If the new group is a closed group that has no
> interest in including new people and wants to retain "control" over the
> project, and is only interested in the marketing boost of being a part
> of "OpenStack", then it should really be denied. We provide a space for
> open collaboration, not for openwashing projects.
> 
> For the product fit, there is also a lot of room for interpretation. For
> me it boils down to whether "OpenStack" (the product) is better with
> that project "in" rather than with that project "out". Sometimes it's an
> easy sell: if a group wants to collaborate on packaging OpenStack for a
> certain format/distro/deployment tool, it's clearly a win. In that case

Given the number of complaints we have had over the lifetime of the
project about the difficulty of upgrading, I am starting to wonder
if we wouldn't have been better off sticking to a single deployment
tool.

> more is always better. But in most cases it's not as straightforward.
> There is always tension between added functionality on one side, and
> complexity / dilution / confusion on the other. Every "service" project
> we add makes OpenStack more complex to explain, cross-project work more
> difficult and interoperability incrementally harder. Whatever is added
> has to be damn interesting to counterbalance that. The same goes for

Why do you think OpenStack has more trouble explaining our feature set
than other cloud systems that have a similarly diverse array of
features?

> competitive / alternative projects: in some cases the net result is a
> win (different approaches to monitoring), while in some cases the net
> result would be a loss (a Keystone alternative that would make everyone
> else's life more miserable).
> 
> In summary while the rules are precise, the way we interpret them can
> still be varied. That is why this discussion is useful: comparing notes
> on how we answer that difficult question, understanding where everyone
> stands, helps us converge to a general consensus of the goals we are
> trying to achieve when defining "OpenStack" scope, even if we disagree
> on the particulars.
> 

__
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] Topics for the Board+TC+UC meeting in Vancouver

[Zhipeng Huang]

big +1 to Graham's suggestion

On Mon, Apr 23, 2018 at 10:36 PM, Graham Hayes  wrote:

> On 18/04/18 11:38, Chris Dent wrote:
> > On Tue, 17 Apr 2018, Thierry Carrez wrote:
> >
> >> So... Is there any specific topic you think we should cover in that
> >> meeting ?
> >
> > The topics:
> >
> > 1. What are we to do, as a community, when external pressures for
> > results are not matched by contribution of resources to produce
> > those results? There are probably several examples of this, but one
> > that I'm particularly familiar with is the drive to be able to
> > satisfy complex hardware topologies demanded by virtual network
> > functions and related NFV use cases. Within nova, and I suspect other
> > projects, there is intense pressure to make progress and intense
> > effort that is removing resources from other areas. But the amount
> > of daily, visible contribution from the interest companies [1] is
> > _sometimes_ limited. There are many factors in this, and obviously
> > "throw more people at it" is not a silver bullet, but there are
> > things to talk about here that need the input from all the segments.
> >
> > 2. We've made progress of late with acknowledging the concepts
> > and importance of casual contribution and "drive-by bug fixing" in
> > our changing environment. But we've not yet made enough progress in
> > changing the way we do work. Corporate foundation members need to be
> > more aware and more accepting that the people they provide to work
> > "mostly upstream" need to be focused on making other people capable
> > of contribution. Not on getting features done. And those of us who
> > do have the privilege of being "mostly upstream" need to adjust our
> > priorities.
> >
> > Somewhere in that screed are, I think, some things worth talking
> > about, but they need to be distilled out.
> >
> > [1] http://superuser.openstack.org/articles/5g-open-source-att/
>
>
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
>
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.
>
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
>
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.
>
> >
> >
> >
> > 
> __
> > 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
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] campaign question related to new projects

[Zhipeng Huang]

I think it actually relies upon the new team to actively reaching out to
the existing team. The new team cannot be lazy and wait for something
happen for them, they have to keep reaching out and believe me the core
developers from the existing official project will lend a hand in the end :)

For Cyborg, I didn't even rush the application for an official project
status. We've had more than one year just discuss the necessity and
usefulness of the project, because I was not sure as well at the time if we
are overlapping with something Nova or other project is already doing or we
are just dreaming up some use cases.

It turns out by conducting active and long discussions , we've got more
than enough help from the Nova team :) I believe this is the team that is
famous for their busy schedule, but the core developers helped tramendously
because we are the one that is actively reaching out.

SO back to topic, for TC's role, it should be to help the new team to find
a productive way to actively get in contact with any related existing
teams, not to put pressure on the existing projects :)

On Mon, Apr 23, 2018 at 10:39 PM, Doug Hellmann 
wrote:

> Excerpts from Zhipeng Huang's message of 2018-04-21 07:06:30 +0800:
> > As the one who just lead a new project into governance last year, I
> think I
> > could take a first stab at it.
> >
> > For me the current requirements in general works fine, as I emphasized in
> > my recent blog [0], the four opens are extremely important. Open Design
> is
> > one of the most important out the four I guess, because it actually will
> > lead to the diversity question. A team with a single vendor, although it
> > could satisfy all the other three easily, could not have a good open
> design
> > rather well.
> >
> > Another criteria (more related to the mission statement specifically) I
> > would consider important is the ability to demonstrate (1)its scope does
> > not overlap with existing official projects and (2) its ability to
> actively
> > work with related projects. The cross project collaboration does not have
> > to be waited after the project got anointed, rather started when the
> > project is in conception.
>
> In the past we have had challenges with existing teams having time,
> energy, or interest in working with new teams. These issues are
> often, but not always, outside of the control of the new teams.
> What role can, or should, the TC play in mediating these situations?
>
> Doug
>
> >
> > Well I guess that is my two cents :)
> >
> > [0] https://hannibalhuang.github.io/
> >
> >
> >
> > On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann 
> > wrote:
> >
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > We are discussing adding at least one new project this cycle, and
> > > the specific case of Adjutant has brought up questions about the
> > > criteria we use for evaluating new projects when they apply to
> > > become official.  Although the current system does include some
> > > well-defined requirements [1], it was also designed to rely on TC
> > > members to use their judgement in some other areas, to account for
> > > changing circumstances over the life of the project and to reflect
> > > the position that governance is not something we can automate away.
> > >
> > > Without letting the conversation devolve too much into a discussion
> > > of Adjutant's case, please talk a little about how you would evaluate
> > > a project's application in general.  What sorts of things do you
> > > consider when deciding whether a project "aligns with the OpenStack
> > > Mission," for example?
> > >
> > > Doug
> > >
> > > [1] https://governance.openstack.org/tc/reference/new-projects-
> > > requirements.html
> > >
> > > 
> __
> > > 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
> > >
> >
> >
> >
> > --
> > Zhipeng (Howard) Huang
> >
> > Standard Engineer
> > IT Standard & Patent/IT Product Line
> > Huawei Technologies Co,. Ltd
> > Email: huangzhip...@huawei.com
> > Office: Huawei Industrial Base, Longgang, Shenzhen
> >
> > (Previous)
> > Research Assistant
> > Mobile Ad-Hoc Network Lab, Calit2
> > University of California, Irvine
> > Email: zhipe...@uci.edu
> > Office: Calit2 Building Room 2402
> >
> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tc] campaign question related to new projects

[Doug Hellmann]

Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800:
> Thanks, Doug, for raising this campaign question
> 
> 
> Here are my answers:
> 
> 
> ***How you would evaluate a project's application in general
> 
> First I would work through the requirements ([1]) to evaluate projects.
> Since most of the requirements are specific enough. And here's more
> important part, to leave evaluate logs or comments for projects which we
> considered but didn't reach some requirements. It's very important to guide
> projects to cross over requirements (and remember, a `-1` only means we
> trying to help).
> 
> Then, I work on questions, like:
> 
> `How many user are interesting to/needs the functionality that service
> provided?`
> 
> `How active is this project and how's the diversity of contributors?`

Our current policy is to allow projects with contributors from a small
number of affiliations (even a single employer), under the theory that
bringing a team into the community officially will help them grow by
showing them the benefits of being more diverse and by making it easier
for other community members who have employer restrictions on their open
source work to justify contributing.

Would you change that policy in any way?

> 
> `Is this project required cross communities/projects cooperation? If yes,
> how's the development workflows  are working between communities/projects?`
> 
> And last but is one of the most important questions,
> 
> `Is this service aligns with the OpenStack Mission`? (and let's jump to
> next question to answer this part)
> 
> 
> 
> **What sorts of things do you consider when deciding whether a project
> "aligns with the OpenStack Mission," for example?*
> 
> I would consider things like:
> 
> `Is the project's functionality complete the OpenStack infrastructure map?`
> 
> Asking from user requirement and functionality point of view, `how's the
> project(services) will make OpenStack better infrastructure for
> user/operators?` and `how's this functionality provide a better life for
> OpenStack developers?`
> 
> `Is the project provides better integration point between communities`
> 
> To build a better infrastructure, IMO it's also important to ask if a
> project (service) really help on integration with other communities like
> Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active
> infrastructure to solutions is part of our mission too.
> 
> `Is it providing functionality which we can integrate with current projects
> or SIG instead?`
> 
> In short, we should be gathering our development energy, to really achieve
> the jobs which is exactly why we spend times on trying to find official
> projects and said this is part of our mission to work on. So when new
> projects jump out, it's really important to discuss cross-project `is it
> suitable for projects integrated and join force on specific functionality?`
> (to do this while evaluating a project instead of when it's creating might
> not be the best time to said `please integrate or join forces with other
> teams together`(not even with a smiling face), but it's never too late for
> a non-official/incubating project to consider about this). I really don't
> like to to see any project get higher chances to die just because
> developers chance their developing focus. It's happening when projects are
> all willing to do the functionality, but no communication between(some
> cases, not even now other projects exists), and new/old projects dead, then
> TC needs to spend the time to pick those projects out. So IMO, it's worth
> to spend times to investigate on whether projects can be joined. Or ideally
> to put a resolution said, it's project's obligation to help on this, and
> help other join force to be part of the team.

Please see my other question about projects with overlapping feature
sets [1].

Doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html

> 
> `Can projects provide cross-project gating?`
> 
> Do think if it's possible, we should consider this when asking if a service
> aligns with our mission because not breaking rest of infrastructure is part
> of the definition of `to build`. And providing cross-project gate jobs
> seems like a way to go. To stable the integration between projects and
> prevent released a failed feature when other services trying to work on new
> ways and provide no guideline, ML, or solution, just only leave words like
> `this is not part of our function to fix`.
> 
> 
> 
> And finally,
> 
> If we can answer all above questions, try to put in with the more accurate
> number (like from user survey), and provides communications it needs, will
> definitely help in finding next official projects.
> 
> Also, when the evaluation is done, we should also evaluate the how's these
> evaluation processes, how's guideline working for us? and which questions
> above doesn't make any sense?.
> 
> 
> [1]
> 

Re: [openstack-dev] [ironic] Monthly bug day?

[Jim Rollenhagen]

On Mon, Apr 23, 2018 at 8:04 AM, Michael Turek 
wrote:

> Hey everyone!
>
> We had a bug day about two weeks ago and it went pretty well! At last
> week's IRC meeting the idea of having one every month was thrown around.
>
> What does everyone think about having Bug Day the first Thursday of every
> month?
>

I'd totally support a monthly bug day! I'm not sure Thursday is the best
day for me but I may be able to make it work.

// 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

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.

I think that the work on documenting our key principles was proactive,
and it really helped to set expectations for new people in our community.

> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.

The definition of "base services" was also a proactive step, but it
failed (so far) to trigger the desired effect (solve the catch-22 around
etcd3).

> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).

Even if the proactive decisions were not all successful, I still think
the TC needs to be proactive rather than reactive. We are in a unique
position to be able to take a step back and look at the whole picture,
rather than look for the dead fish only once you start noticing the
smell. We have a few issues that bubbled up that are still unsolved
(like the decision on driver teams) which if we had addressed them
proactively would likely have been easier.

I don't think we need dramatic changes to be able to do active changes
effectively. The TC members generally have enough influence to drive
that. Some of them are a little shy in using that influence in this way,
though, so it ends up falling on the same smaller set of people to burn
their influence credit to drive governance change, and that only lasts
for so long. So I'd like to see the TC members (and more generally the
people interested in governance problems) more active in discovering
issues, proactively addressing them and owning the changes.

-- 
Thierry Carrez (ttx)

__
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] campaign question: How "active" should the TC be?

[Zhipeng Huang]

I don't have specific ideas now, but it would be great to have TC publish
something like a new direction outlook per cycle or per year, to summarize
that these x,y,z new areas are what the OpenStack Technical Committee
considers worth exploring for new directions and we will sponsor projects
that will do the development in these areas. Of course I think it would be
great for TC member to personally leading projects in these new directions,
but find a way to sponsor or encourage other people leading is also a great
choice :)

Hope this clarifies a bit :)

On Mon, Apr 23, 2018 at 10:35 PM, Doug Hellmann 
wrote:

> Excerpts from Zhipeng Huang's message of 2018-04-23 21:50:15 +0800:
> > In general I would prefer TC take an active role regarding exploring new
> > use cases and technology directions leverage the existing OpenStack
> > infrastructure. I would against TC being too active on project level
> > governance.
>
> This would be a new area for the TC to consider. Can you elaborate a bit
> on what you think we would need to change in order to support that, and
> why the TC is the best place to do it (rather than one of our other
> team-based structures like a project team or SIG)?
>
> >
> > For example we have been discussing about edge computing recently and we
> > don't have any idea on how a lightweight OpenStack should look like:
> maybe
> > no scheduling since edge is more about provisioning ? maybe a Rust
> > implementation of this lightweight version of OpenStack ? There are so
> many
> > interesting new things that yet to be explored and should be championed
> by
> > the TC.
> >
> > However regarding issues like how a project should govern itself, it is
> > better for TC to reactive and let project team driven its own structure.
> I
> > can't think of there is any concrete example on this matter now since TC
> > has been doing rather well on this matter , but I guess this could be a
> > precautious action :)
> >
> > On Mon, Apr 23, 2018 at 9:35 PM, Doug Hellmann 
> > wrote:
> >
> > > Excerpts from Doug Hellmann's message of 2018-04-23 09:27:09 -0400:
> > > > [This is meant to be one of (I hope) several conversation-provoking
> > > > questions directed at prospective TC members to help the community
> > > > understand their positions before considering how to vote in the
> > > > ongoing election.]
> > > >
> > > > We frequently have discussions about whether the TC is active enough,
> > > > in terms of driving new policies, technology choices, and other
> > > > issues that affect the entire community.
> > > >
> > > > Please describe one case where we were either active or reactive
> > > > and how that was shown to be the right choice over time.
> > > >
> > > > Please describe another case where the choice to be active or
> > > > reactive ended up being the wrong choice.
> > > >
> > > > If you think the TC should tend to be more active in driving change
> > > > than it is today, please describe the changes (policy, culture,
> > > > etc.) you think would need to be made to do that effectively (not
> > > > which policies you want us to be more active on, but *how* to
> > > > organize the TC to be more active and have that work within the
> > > > community culture).
> > > >
> > > > If you think the TC should tend to be less active in driving change
> > > > overall, please describe what policies you think the TC should be
> > > > taking an active role in implementing.
> > > >
> > > > Doug
> > >
> > > There was a question from ttx on IRC [1] about my use of the terms
> > > "active" and "reactive" here. I mean active as "going out there and
> > > doing things and anticipating issues" and reactive as "dealing with
> > > things as they come up and aren't resolved in another way".
> > >
> > > Doug
> > >
> > > [1]
> > > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%
> > > 23openstack-tc.2018-04-23.log.html
> > >
> > > 
> __
> > > 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
> > >
> >
> >
> >
> > --
> > Zhipeng (Howard) Huang
> >
> > Standard Engineer
> > IT Standard & Patent/IT Product Line
> > Huawei Technologies Co,. Ltd
> > Email: huangzhip...@huawei.com
> > Office: Huawei Industrial Base, Longgang, Shenzhen
> >
> > (Previous)
> > Research Assistant
> > Mobile Ad-Hoc Network Lab, Calit2
> > University of California, Irvine
> > Email: zhipe...@uci.edu
> > Office: Calit2 Building Room 2402
> >
> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tc] campaign question related to new projects

[Doug Hellmann]

Excerpts from Zhipeng Huang's message of 2018-04-21 07:06:30 +0800:
> As the one who just lead a new project into governance last year, I think I
> could take a first stab at it.
> 
> For me the current requirements in general works fine, as I emphasized in
> my recent blog [0], the four opens are extremely important. Open Design is
> one of the most important out the four I guess, because it actually will
> lead to the diversity question. A team with a single vendor, although it
> could satisfy all the other three easily, could not have a good open design
> rather well.
> 
> Another criteria (more related to the mission statement specifically) I
> would consider important is the ability to demonstrate (1)its scope does
> not overlap with existing official projects and (2) its ability to actively
> work with related projects. The cross project collaboration does not have
> to be waited after the project got anointed, rather started when the
> project is in conception.

In the past we have had challenges with existing teams having time,
energy, or interest in working with new teams. These issues are
often, but not always, outside of the control of the new teams.
What role can, or should, the TC play in mediating these situations?

Doug

> 
> Well I guess that is my two cents :)
> 
> [0] https://hannibalhuang.github.io/
> 
> 
> 
> On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann 
> wrote:
> 
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> >
> > We are discussing adding at least one new project this cycle, and
> > the specific case of Adjutant has brought up questions about the
> > criteria we use for evaluating new projects when they apply to
> > become official.  Although the current system does include some
> > well-defined requirements [1], it was also designed to rely on TC
> > members to use their judgement in some other areas, to account for
> > changing circumstances over the life of the project and to reflect
> > the position that governance is not something we can automate away.
> >
> > Without letting the conversation devolve too much into a discussion
> > of Adjutant's case, please talk a little about how you would evaluate
> > a project's application in general.  What sorts of things do you
> > consider when deciding whether a project "aligns with the OpenStack
> > Mission," for example?
> >
> > Doug
> >
> > [1] https://governance.openstack.org/tc/reference/new-projects-
> > requirements.html
> >
> > __
> > 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
> >
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

__
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] Topics for the Board+TC+UC meeting in Vancouver

[Graham Hayes]

On 18/04/18 11:38, Chris Dent wrote:
> On Tue, 17 Apr 2018, Thierry Carrez wrote:
> 
>> So... Is there any specific topic you think we should cover in that
>> meeting ?
> 
> The topics:
> 
> 1. What are we to do, as a community, when external pressures for
> results are not matched by contribution of resources to produce
> those results? There are probably several examples of this, but one
> that I'm particularly familiar with is the drive to be able to
> satisfy complex hardware topologies demanded by virtual network
> functions and related NFV use cases. Within nova, and I suspect other
> projects, there is intense pressure to make progress and intense
> effort that is removing resources from other areas. But the amount
> of daily, visible contribution from the interest companies [1] is
> _sometimes_ limited. There are many factors in this, and obviously
> "throw more people at it" is not a silver bullet, but there are
> things to talk about here that need the input from all the segments.
> 
> 2. We've made progress of late with acknowledging the concepts
> and importance of casual contribution and "drive-by bug fixing" in
> our changing environment. But we've not yet made enough progress in
> changing the way we do work. Corporate foundation members need to be
> more aware and more accepting that the people they provide to work
> "mostly upstream" need to be focused on making other people capable
> of contribution. Not on getting features done. And those of us who
> do have the privilege of being "mostly upstream" need to adjust our
> priorities.
> 
> Somewhere in that screed are, I think, some things worth talking
> about, but they need to be distilled out.
> 
> [1] http://superuser.openstack.org/articles/5g-open-source-att/


I think as an add on to this, would to ask the board to talk to members
and see what contributions they have made to the technical side of
OpenStack.

This should not just be Number of commits / reviews / bugs etc but
also the motivation for the work, e.g. - Feature for a product, bug fix
found in a product, cross project work or upstream project maintenance.

I don't necessarily want to shame corporate members of the foundation,
but I think it is important to understand where our contributor base
comes from, and what each member brings to the community table.

We should also ask the board to try and formulate a plan for growing
new cross project leaders (not just TC / PTLs). We need to grow more
technical contributors in the horizontal teams, which requires more
than assigning a contributor to the QA / Infra / Olso / Docs teams
for a year or so - the people should be allowed a certain amount
of stability in a role, while not necessarily driving business goals.

> 
> 
> 
> __
> 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
> 



signature.asc
Description: OpenPGP 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] [searchlight][release] Searchlight deliverable type

[Sean McGinnis]

On Mon, Apr 23, 2018 at 09:16:03AM -0500, Sean McGinnis wrote:
> Hello searchlighters,
> 
> The Rocky 1 milestone was last Thursday, and there has been no release request
> was submitted for the searchlight deliverables [1].
> 
> I remember some discussion at the last Denver PTG about searchlight and that 
> it
> is basically considered "code complete" at this point until any new
> requirements come up for it. Is this still (or ever) an accurate assessment of
> the current project state?
> 
> If so, I am wondering if this project's deliverables should be switched from
> being a cycle-based deliverable to being considered an independent 
> deliverable.
> This allows the project to release at any point as needed, and does not 
> require
> adherance to the milestone within cycle model that it is currently set up to
> follow.
> 
> I would like to hear from the team to get a better understanding of where this
> project is and how to best support its release needs.
> 

In a time honored tradition, I missed actually adding the link referred to
above.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129617.html

__
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] campaign question: How "active" should the TC be?

[Doug Hellmann]

Excerpts from Zhipeng Huang's message of 2018-04-23 21:50:15 +0800:
> In general I would prefer TC take an active role regarding exploring new
> use cases and technology directions leverage the existing OpenStack
> infrastructure. I would against TC being too active on project level
> governance.

This would be a new area for the TC to consider. Can you elaborate a bit
on what you think we would need to change in order to support that, and
why the TC is the best place to do it (rather than one of our other
team-based structures like a project team or SIG)?

> 
> For example we have been discussing about edge computing recently and we
> don't have any idea on how a lightweight OpenStack should look like: maybe
> no scheduling since edge is more about provisioning ? maybe a Rust
> implementation of this lightweight version of OpenStack ? There are so many
> interesting new things that yet to be explored and should be championed by
> the TC.
> 
> However regarding issues like how a project should govern itself, it is
> better for TC to reactive and let project team driven its own structure. I
> can't think of there is any concrete example on this matter now since TC
> has been doing rather well on this matter , but I guess this could be a
> precautious action :)
> 
> On Mon, Apr 23, 2018 at 9:35 PM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Doug Hellmann's message of 2018-04-23 09:27:09 -0400:
> > > [This is meant to be one of (I hope) several conversation-provoking
> > > questions directed at prospective TC members to help the community
> > > understand their positions before considering how to vote in the
> > > ongoing election.]
> > >
> > > We frequently have discussions about whether the TC is active enough,
> > > in terms of driving new policies, technology choices, and other
> > > issues that affect the entire community.
> > >
> > > Please describe one case where we were either active or reactive
> > > and how that was shown to be the right choice over time.
> > >
> > > Please describe another case where the choice to be active or
> > > reactive ended up being the wrong choice.
> > >
> > > If you think the TC should tend to be more active in driving change
> > > than it is today, please describe the changes (policy, culture,
> > > etc.) you think would need to be made to do that effectively (not
> > > which policies you want us to be more active on, but *how* to
> > > organize the TC to be more active and have that work within the
> > > community culture).
> > >
> > > If you think the TC should tend to be less active in driving change
> > > overall, please describe what policies you think the TC should be
> > > taking an active role in implementing.
> > >
> > > Doug
> >
> > There was a question from ttx on IRC [1] about my use of the terms
> > "active" and "reactive" here. I mean active as "going out there and
> > doing things and anticipating issues" and reactive as "dealing with
> > things as they come up and aren't resolved in another way".
> >
> > Doug
> >
> > [1]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%
> > 23openstack-tc.2018-04-23.log.html
> >
> > __
> > 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
> >
> 
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
> 
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
> 
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

__
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] campaign question: How can we make contributing to OpenStack easier?

[Zhipeng Huang]

Culture wise, being too IRC-centric is definitely not helping, from my own
experience getting new Cyborg developer joining our weekly meeting from
China. Well we could always argue it is part of a open source/hacker
culture and preferable to commercial solutions that have the constant risk
of suddenly being shut down someday. But as OpenStack becomes more
commercialized and widely adopted, we should be aware that more and more
(potential) contributors will come from the groups who are used to
non-strictly open source environment, such as product develop team which
relies on a lot of "closed source" but easy to use softwares.

The change ? Use more video conferences, and more commercial tools that
preferred in certain region. Stop being allergic to non-open source
softwares and bring more capable but not hacker culture inclined
contributors to the community.

I know this is not a super welcomed stance in the open source hacker
culture. But if we want OpenStack to be able to sustain more developers and
not have a mid-life crisis then got fringed, we need to start changing the
hacker mindset.

Another important thing, as I stated in the previous email, is that
OpenStack should keep explore new technology directions and TC should take
the lead position on it. No matter how good we could facilitate the
contributors, a stale community cannot win more contributors. I'm against
hype like any other, but reluctant or lazy on innovation is another thing
and will cost the community to lose more and more existing and potential
contributors.



On Mon, Apr 23, 2018 at 10:06 PM, Doug Hellmann 
wrote:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?
>
> Doug
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [searchlight][release] Searchlight deliverable type

[Sean McGinnis]

Hello searchlighters,

The Rocky 1 milestone was last Thursday, and there has been no release request
was submitted for the searchlight deliverables [1].

I remember some discussion at the last Denver PTG about searchlight and that it
is basically considered "code complete" at this point until any new
requirements come up for it. Is this still (or ever) an accurate assessment of
the current project state?

If so, I am wondering if this project's deliverables should be switched from
being a cycle-based deliverable to being considered an independent deliverable.
This allows the project to release at any point as needed, and does not require
adherance to the milestone within cycle model that it is currently set up to
follow.

I would like to hear from the team to get a better understanding of where this
project is and how to best support its release needs.

Thanks,
Sean


__
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] campaign question: How can we make contributing to OpenStack easier?

[Doug Hellmann]

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

Over the last year we have seen some contraction in the number of
companies and individuals contributing to OpenStack. At the same
time we have started seeing contributions from other companies and
individuals. To some degree this contraction and shift in contributor
base is a natural outcome of changes in OpenStack itself along with
the rest of the technology industry, but as with any change it
raises questions about how and whether we can ensure a smooth
transition to a new steady state.

What aspects of our policies or culture make contributing to OpenStack
more difficult than contributing to other open source projects?

Which of those would you change, and how?

Where else should we be looking for contributors?

Doug

__
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] campaign question: How should we handle projects with overlapping feature sets?

[Zhipeng Huang]

I think this depends on the nature of the project.

For deployment tools, as we also have witnessed in OPNFV, it tends to have
multiple solutions. So it is normal to have multiple such projects although
they are solving the same problem generally speaking.

For projects that has a clear definition on a specific set of features of
functionalities which are critical to any cloud infrastructure, then
overlapping should be strictly avoided. I don't think for a team that
proposes a new project that got a significant overlap with existing project
has seriously studies the community or a good intention to collaborate
within the community.

Of course there will be exceptions for implementations in different langs
but generally I would prefer to take a strong stance on strictly avoiding
the overlap. The benefit we would got as a community is that we will have
developers working on projects that is clearly defined both individually
and collaboratively without any confusion.






On Mon, Apr 23, 2018 at 9:50 PM, Doug Hellmann 
wrote:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> In the course of evaluating new projects that have asked to join
> as official members of the OpenStack community, we often discuss
> whether the feature set of the project overlaps too much with other
> existing projects. This came up within the last year during Glare's
> application, and more recently as part of the Adjutant application.
>
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
>
> Where do you draw the line at "gratuitous"?
>
> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?
>
> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?
>
> Doug
>
> [1] https://governance.openstack.org/tc/reference/new-projects-
> requirements.html
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] campaign question: How "active" should the TC be?

[Zhipeng Huang]

In general I would prefer TC take an active role regarding exploring new
use cases and technology directions leverage the existing OpenStack
infrastructure. I would against TC being too active on project level
governance.

For example we have been discussing about edge computing recently and we
don't have any idea on how a lightweight OpenStack should look like: maybe
no scheduling since edge is more about provisioning ? maybe a Rust
implementation of this lightweight version of OpenStack ? There are so many
interesting new things that yet to be explored and should be championed by
the TC.

However regarding issues like how a project should govern itself, it is
better for TC to reactive and let project team driven its own structure. I
can't think of there is any concrete example on this matter now since TC
has been doing rather well on this matter , but I guess this could be a
precautious action :)

On Mon, Apr 23, 2018 at 9:35 PM, Doug Hellmann 
wrote:

> Excerpts from Doug Hellmann's message of 2018-04-23 09:27:09 -0400:
> > [This is meant to be one of (I hope) several conversation-provoking
> > questions directed at prospective TC members to help the community
> > understand their positions before considering how to vote in the
> > ongoing election.]
> >
> > We frequently have discussions about whether the TC is active enough,
> > in terms of driving new policies, technology choices, and other
> > issues that affect the entire community.
> >
> > Please describe one case where we were either active or reactive
> > and how that was shown to be the right choice over time.
> >
> > Please describe another case where the choice to be active or
> > reactive ended up being the wrong choice.
> >
> > If you think the TC should tend to be more active in driving change
> > than it is today, please describe the changes (policy, culture,
> > etc.) you think would need to be made to do that effectively (not
> > which policies you want us to be more active on, but *how* to
> > organize the TC to be more active and have that work within the
> > community culture).
> >
> > If you think the TC should tend to be less active in driving change
> > overall, please describe what policies you think the TC should be
> > taking an active role in implementing.
> >
> > Doug
>
> There was a question from ttx on IRC [1] about my use of the terms
> "active" and "reactive" here. I mean active as "going out there and
> doing things and anticipating issues" and reactive as "dealing with
> things as they come up and aren't resolved in another way".
>
> Doug
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%
> 23openstack-tc.2018-04-23.log.html
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] campaign question: How should we handle projects with overlapping feature sets?

[Doug Hellmann]

[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]

In the course of evaluating new projects that have asked to join
as official members of the OpenStack community, we often discuss
whether the feature set of the project overlaps too much with other
existing projects. This came up within the last year during Glare's
application, and more recently as part of the Adjutant application.

Our current policy regarding Open Development is that a project
should cooperate with existing projects "rather than gratuitously
competing or reinventing the wheel." [1] The flexibility provided
by the use of the term "gratuitously" has allowed us to support
multiple solutions in the deployment and telemetry problem spaces.
At the same time it has left us with questions about how (and
whether) the community would be able to replace the implementation
of any given component with a new set of technologies by "starting
from scratch".

Where do you draw the line at "gratuitous"?

What benefits and drawbacks do you see in supporting multiple tools
with similar features?

How would our community be different, in positive and negative ways,
if we were more strict about avoiding such overlap?

Doug

[1] https://governance.openstack.org/tc/reference/new-projects-requirements.html

__
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