Re: [openstack-dev] [vote][kolla] Splitting out Ansible into a separate deliverable

[Steven Dake (stdake)]

We have far exceeded a majority for choice C (which is my preferred choice as 
well).  So once 3.0.0 tags, it is all hands on deck to make the repo split 
happen as well as get started on the osic documentation which we owe the OSIC 
team.  There were no other votes for other choices.  While not everyone has 
chimed in, I think we have a clear consensus.

Regards
-steve


From: Steven Dake 
Date: Wednesday, September 14, 2016 at 11:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [vote][kolla] Splitting out Ansible into a separate deliverable

Core Reviewers:

The facts:
We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be 
closed out as dupes, fixed, wontfix, or the like.
The core reviewer team has had various discussions around splitting the 
repository at various times but has not come to a concrete conclusion via a 
vote.
Once RC1 is tagged, the stable/newton branch will be created automatically.
All rc2 bug fixes will require bug IDs and backports to stable/newton to enable 
the ability to manage the release of rc2 and 3.0.0.
There is an expectation for core reviewers to do the work of backporting to 
stable/newton – only our backports team typically does this work – however 
during release we really need everyone’s participation.

My understanding of general consensus beliefs:
We believe splitting out the Ansible implementation into a separate repository 
will produce a better outcome for both Kolla-Ansible and Kolla-Kubernetes
We have been unable to achieve consensus on the right timing for a repo split 
in the past but generally believe the timing is right at some point between rc1 
and Summit or shortly thereafter, if we are to do the repo split during Newton 
or very early Ocata.)

This vote is a multiple choice (one choice please) vote.  Feel free to discuss 
before making a decision.

Please vote:

a)  Do not split the repository between rc1 and Summit or shortly 
thereafter at all, keeping the Ansible implementation intact in Ocata

b)  Split the repository shortly after tagging RC1 – creating of a 
kolla-ansible deliverable for Ocata.

c)  Split the repository shortly after tagging 3.0.0 – creating a 
kolla-ansible deliverable for Ocata.

Voting is open for 7 days until September 21st, 2016. Please do not abstain on 
this critical vote.  Remember, no veto vote is available in roll-call votes.  
If a majority can’t be reached on any one choice, but there is a majority 
around B & C, (which are the same idea, but different timing) a second vote 
will be triggered around when to split the repository.  The implication there 
is if you vote for b or c, your voting for a repository split.  If you vote for 
A you are voting for no repository split.  I hate to overload voting in this 
way.  It is only an optimization to speed things up as execution may need to 
happen now, or can be pushed out a month, or may not be needed at this time.

Regards
-steve
__
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] [vote][kolla] Splitting out Ansible into a separate deliverable

[Steven Dake (stdake)]

Core Reviewers:

The facts:
We have roughly 250 bugs in rc2.  Of those, I suspect over half can just be 
closed out as dupes, fixed, wontfix, or the like.
The core reviewer team has had various discussions around splitting the 
repository at various times but has not come to a concrete conclusion via a 
vote.
Once RC1 is tagged, the stable/newton branch will be created automatically.
All rc2 bug fixes will require bug IDs and backports to stable/newton to enable 
the ability to manage the release of rc2 and 3.0.0.
There is an expectation for core reviewers to do the work of backporting to 
stable/newton – only our backports team typically does this work – however 
during release we really need everyone’s participation.

My understanding of general consensus beliefs:
We believe splitting out the Ansible implementation into a separate repository 
will produce a better outcome for both Kolla-Ansible and Kolla-Kubernetes
We have been unable to achieve consensus on the right timing for a repo split 
in the past but generally believe the timing is right at some point between rc1 
and Summit or shortly thereafter, if we are to do the repo split during Newton 
or very early Ocata.)

This vote is a multiple choice (one choice please) vote.  Feel free to discuss 
before making a decision.

Please vote:

a)   Do not split the repository between rc1 and Summit or shortly 
thereafter at all, keeping the Ansible implementation intact in Ocata

b)   Split the repository shortly after tagging RC1 – creating of a 
kolla-ansible deliverable for Ocata.

c)   Split the repository shortly after tagging 3.0.0 – creating a 
kolla-ansible deliverable for Ocata.

Voting is open for 7 days until September 21st, 2016. Please do not abstain on 
this critical vote.  Remember, no veto vote is available in roll-call votes.  
If a majority can’t be reached on any one choice, but there is a majority 
around B & C, (which are the same idea, but different timing) a second vote 
will be triggered around when to split the repository.  The implication there 
is if you vote for b or c, your voting for a repository split.  If you vote for 
A you are voting for no repository split.  I hate to overload voting in this 
way.  It is only an optimization to speed things up as execution may need to 
happen now, or can be pushed out a month, or may not be needed at this time.

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

Re: [openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Steven Dake (stdake)]

Jeffrey,

The broad Kolla team made Kolla come true.  Thank you for the kind words; they 
means a lot coming from you. ☺

Regards
-steve

On 9/13/16, 8:41 PM, "Jeffrey Zhang"  wrote:

Thank Steve for all you do to make Kolla come true.

On Wed, Sep 14, 2016 at 10:19 AM, Vikram Hosakote (vhosakot)
 wrote:
> Thanks a lot Steve for being a great PTL, leader and a mentor!
>
> Regards,
> Vikram Hosakote
> IRC:  vhosakot
    >
> From: "Steven Dake (stdake)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Monday, September 12, 2016 at 1:04 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL 
for
> Ocata cycle
>
> To the OpenStack Community,
>
>
>
> Consider this email my self non-nomination for PTL of Kolla for
>
> the coming Ocata release.  I let the team know in our IRC team meeting
>
> several months ago I was passing the on baton at the conclusion of Newton,
>
> but I thought the broader OpenStack community would appreciate the
> information.
>
>
>
> I am super proud of what our tiny struggling community produced starting
>
> 3 years ago with only 3 people to the strongly emergent system that is 
Kolla
>
> with over 467 total contributors [1] since inception and closing in on 
5,000
>
> commits today.
>
>
>
> In my opinion, the Kolla community is well on its way to conquering the 
last
>
> great challenge OpenStack faces: Making operational deployment management
> (ODM)
>
> of OpenStack cloud platforms straight-forward, easy, and most importantly
>
> cost effective for the long term management of OpenStack.
>
>
>
> The original objective the Kolla community set out to accomplish, 
deploying
>
> OpenStack in containers at 100 node scale has been achieved as proven by
> this
>
> review [2].  In these 12 scenarios, we were able to deploy with 3
>
> controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
>
> storage and run rally as well as tempest against the deployment.
>
>
>
> Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.
>
>
>
> I have developed a strong leadership pipeline and expect several 
candidates
>
> to self-nominate.  I wish all of them the best in the future PTL 
elections.
>
>
>
> Finally, I would like to thank all of the folks that have supported 
Kolla’s
>
> objectives.  If I listed the folks individually this email would be far 
too
>
> long, but you know who you are J Thank you for placing trust in my
> judgement.
>
>
>
> It has been a pleasure to serve as your leader.
>
>
>
> Regards
>
> -steak
>
>
>
> [1] http://stackalytics.com/report/contribution/kolla-group/2000
>
> [2] https://review.openstack.org/#/c/352101/
>
>
>
>
> __
> 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
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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



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

[openstack-dev] [kolla] Removal of folks from kolla-drivers

[Steven Dake (stdake)]

Forgot kolla tag.  See message inside.

From: Steven Dake 
Date: Tuesday, September 13, 2016 at 8:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Removal of folks from kolla-drivers

Hey folks,

I removed several folks which appeared inactive for the Newton cycle from the 
kolla-drivers team on launchpad.  As a reminder, the reason we add people to 
the kolla-drivers team is to do bug triage, move blueprint states around, and 
distribute the process of handling the release.  If folks are inactive, they 
need not have permissions to do these things.

If I removed anyone in error, please respond to this email off-line and I’ll 
add you back in. (It is possible I did such a thing).

Regards
-steve

__
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] Removal of folks from kolla-drivers

[Steven Dake (stdake)]

Hey folks,

I removed several folks which appeared inactive for the Newton cycle from the 
kolla-drivers team on launchpad.  As a reminder, the reason we add people to 
the kolla-drivers team is to do bug triage, move blueprint states around, and 
distribute the process of handling the release.  If folks are inactive, they 
need not have permissions to do these things.

If I removed anyone in error, please respond to this email off-line and I’ll 
add you back in. (It is possible I did such a thing).

Regards
-steve

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

Re: [openstack-dev] [kolla] warning about PBR issue for kolla operators

[Steven Dake (stdake)]

pip install –e . is not viable either for a variety of reasons.  We expect 
developers to be able to find their way to the tools directory and operate the 
commands directly from there.

Regards
-steve


From: Clay Gerrard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, September 13, 2016 at 5:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] warning about PBR issue for kolla operators

There's a note in the "for development" section [1] that notes the development 
instructions don't include anything that puts kolla in your sys.path or any bin 
scripts copied out anywhere into the PATH - i.e. it's not installed

That seems less than ideal for a developer - did I miss a `pip install -e .` 
somewhere?

-Clay

1. 
http://docs.openstack.org/developer/kolla/quickstart.html#installing-kolla-and-dependencies-for-development

On Tue, Sep 13, 2016 at 4:33 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Hey folks,

The quickstart guide was modified as a result of a lot of painful debugging 
over the last cycle approximately a month ago.  The only solution available to 
us was to split the workflow into an operator workflow (working on stable 
branches) and a developer workflow (working on master).  We recognize operators 
are developers and the docs indicate as much.  Many times operators want to 
work with master as they are evaluating Newton and planning to place it into 
production.

I’d invite folks using master with the pip install ./ method to have a re-read 
of the quickstart documentation. The documentation was changed in subtle ways 
(with warning and info boxes) but folks that have been using Kolla prior to the 
quckstart change may be using kolla in the same way the quickstart previously 
recommended.  Folks tend to get jammed up on this issue – we have helped 70-100 
people work past this problem before we finally sorted out a workable solution 
(via documentation).

The real issue lies in how PBR operates and pip interacts with Kolla and is 
explained in the quickstart.  From consulting with Doug Hellman and others in 
the release team, it appears the issue that impacts Kolla is not really 
solveable within PBR itself.  (I don’t mean to put words in Doug’s mouth, but 
that is how I parsed our four+ hour discussion) on the topic.

The documentation is located here:
http://docs.openstack.org/developer/kolla



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [kolla] warning about PBR issue for kolla operators

[Steven Dake (stdake)]

Hey folks,

The quickstart guide was modified as a result of a lot of painful debugging 
over the last cycle approximately a month ago.  The only solution available to 
us was to split the workflow into an operator workflow (working on stable 
branches) and a developer workflow (working on master).  We recognize operators 
are developers and the docs indicate as much.  Many times operators want to 
work with master as they are evaluating Newton and planning to place it into 
production.

I’d invite folks using master with the pip install ./ method to have a re-read 
of the quickstart documentation. The documentation was changed in subtle ways 
(with warning and info boxes) but folks that have been using Kolla prior to the 
quckstart change may be using kolla in the same way the quickstart previously 
recommended.  Folks tend to get jammed up on this issue – we have helped 70-100 
people work past this problem before we finally sorted out a workable solution 
(via documentation).

The real issue lies in how PBR operates and pip interacts with Kolla and is 
explained in the quickstart.  From consulting with Doug Hellman and others in 
the release team, it appears the issue that impacts Kolla is not really 
solveable within PBR itself.  (I don’t mean to put words in Doug’s mouth, but 
that is how I parsed our four+ hour discussion) on the topic.

The documentation is located here:
http://docs.openstack.org/developer/kolla


__
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] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Steven Dake (stdake)]

To the OpenStack Community,

Consider this email my self non-nomination for PTL of Kolla for
the coming Ocata release.  I let the team know in our IRC team meeting
several months ago I was passing the on baton at the conclusion of Newton,
but I thought the broader OpenStack community would appreciate the information.

I am super proud of what our tiny struggling community produced starting
3 years ago with only 3 people to the strongly emergent system that is Kolla
with over 467 total contributors [1] since inception and closing in on 5,000
commits today.

In my opinion, the Kolla community is well on its way to conquering the last
great challenge OpenStack faces: Making operational deployment management (ODM)
of OpenStack cloud platforms straight-forward, easy, and most importantly
cost effective for the long term management of OpenStack.

The original objective the Kolla community set out to accomplish, deploying
OpenStack in containers at 100 node scale has been achieved as proven by this
review [2].  In these 12 scenarios, we were able to deploy with 3
controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
storage and run rally as well as tempest against the deployment.

Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.

I have developed a strong leadership pipeline and expect several candidates
to self-nominate.  I wish all of them the best in the future PTL elections.

Finally, I would like to thank all of the folks that have supported Kolla’s
objectives.  If I listed the folks individually this email would be far too
long, but you know who you are ☺ Thank you for placing trust in my judgement.

It has been a pleasure to serve as your leader.

Regards
-steak

[1] http://stackalytics.com/report/contribution/kolla-group/2000
[2] https://review.openstack.org/#/c/352101/

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

Re: [openstack-dev] [kolla] Problem regarding named volume data location

[Steven Dake (stdake)]

I believe what Pual was indicating was


On 9/2/16, 12:59 PM, "Christian Berendt"  wrote:

> On 02 Sep 2016, at 19:04, Jeffrey Zhang  wrote:
> 
> I think the right solution should warn the end-user: you need configure a 
large partition for /var/lib/docker.

Confirmed. The volumes of Mongodb and of Mariadb are getting pretty big as 
well. Using /var/lib/nova (or /var/lib/mariadb, ..) on the local filesystem 
instead of a named volume will change nothing.

I think it is the best to stay with named volumes and to document the host 
requirements.

While using named volumes it is also possible to use alternative Docker 
volume plugins like Convoy.

Christian.

I believe what Paull was indicating was with /var/lib/nova and 
/var/lib/mariadb, it is possible to mount /var/lib/nova to /dev/sdb and 
/var/lib/mariadb to /dev/sdc.  This permits custom sizing of partitions.  I am 
not in favor – named volumes work with docker natively and permit all lkinds of 
good activity for the one tradeoff that they must be on the same filesystem and 
device.

I wonder if Paul’s use case could be met by moutning 
/var/lib/docker/_volumes/whateer to a specific disk.

The proper answer here is plugins, which can route the named volume to whatever 
backend storage is desired.  I don’t know if any plugins exist, but the 
tradeoff of bindmounting the host filesystem without docker manging the volume 
appears very problematic to me.

Regards
-steve


__
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] [kolla] Please add kolla-kubernetes to your watched prjoects

[Steven Dake (stdake)]

Kollagues,

The reviews on kolla-kubernetes are going slowly.  I suspect the reason is 
folks don’t have kolla-kubernetes enabled in their watched projects list.  If 
you need instruction on how to do that, please contact me on IRC.

We need to work as a team to get the kolla-kubernetes backed-up reviews merged. 
 Even if you don’t feel totally comfortable reviewing the code, we operate as 
one community and as such I’d request reviewers to take care to review 
kolla-kubernetes patches.

Regards
-steve
__
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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Steven Dake (stdake)]

Kolla core reviewer team,

It is my pleasure to nominate Christian Berendt for the Kolla core team.

Christian’s output over the last cycle has been fantastic – cracking the top 10 
reviewer list for the full cycle.  His 30 day stats [1] place him in solid 7th 
position, and considering the size of the core review team we have, this is a 
great accomplishment.  Christian also has solid 60 day review stats [2] place 
him in solid 7th position.  But more importantly his reviews are of high 
quality.  He has great IRC participation as well as having implemented all 
kinds of bug fixes all over the code base.  He clearly understands Kolla by the 
quality of his reviews.

Consider this nomination a +1 vote from me.

A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote 
indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until 
September 15th, or a unanimous response is reached or a veto vote occurs.  If a 
unanimous response is reached or a veto occurs, voting will close early.

Regards,
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60

__
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] [poll][kolla] Name of baremetal role/group

[Steven Dake (stdake)]

Sean,

I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)

I’d also add a duplicate API of “deploy” and mark deploy as deprecated and 
follow the standard deprecation policies.  I’d recommend making the new 
OpenStack specific deploy command deploy-openstack

Regards
-steve


From: "sean.k.moo...@intel.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, September 7, 2016 at 11:51 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group

Hi
I recently introduced a new baremetal role/group which is used as part of the 
kolla-host playbook.
https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
This baremetal role is used to install all the dependencies required to deploy 
kolla containers on a “baremetal” host.
The host does not have to be baremetal it can be a vm but the term baremetal 
was originally chosen as unlike other rules in
Kolla it installs and configures packages on the host os.

Given that kolla also has baremetal as a service via ironic and baremetal 
provision of servers with bifrost the question I would like
To ask is should we change the name of the current role to install the kolla 
dependencies to something else.

I have created a strawpoll link for this here http://www.strawpoll.me/11175159
The options available in the strawpool are:

· kolla-host

· host

· baremetal

· pre-install
If there are any other suggestions fell free to discuss them in this thread.
I will check the poll Friday evening gmt and submit a patch for review if 
consensus is that it should be changed.

Regards
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] [kolla] Problem regarding named volume data location

[Steven Dake (stdake)]

On 9/2/16, 8:48 AM, "Paul Bourke"  wrote:

>Hi Kolla,
>
>We have been experiencing a long running issue with Kolla that I have 
>brought up briefly a few times, but not made too much noise about.
>
>I'm taking the time to write about it in the hopes that a) as a 
>community we may be able to solve it, and b) if other operators start 
>complaining down the line we'll have discussed it.
>
>The issue is that right now all data is stored using named volumes under 
>/var/lib/docker. We have encountered users who are not happy with this. 
>As well as issues of scale, even with a large /var/ partition this is 
>liable to fill up fast, as (in a default setup) it has to store both 
>docker images, glance images, nova instance data, and other potentially 
>large files such as logs. It's not typical for operators to be expected 
>to store all of this on one partition, and doesn't offer the choice 
>expected from a standard (non containerised) deploy.
>
>In our Kilo based solution we were solving this using host bind mounts, 
>e.g. -v /var/lib/nova:/var/lib/nova, where the directory on the left 
>hand side can be mounted wherever you like. Two major issues with this 
>approach are:
>
>1) Kolla tasks have to be refactored in many places to replace 
>"nova_data:/var/lib/kolla" with "/var/lib/nova:/var/lib/nova" (easily 
>solvable)
>
>2) This appears to be incompatible with the 'drop root' work done, as 
>even though /var/lib/nova is created and chowned during the build 
>process, it's permissions are replaced with those of root when bind 
>mounted from the host.
>
>Other avenues I've explored are seeing the docker volume driver can be 
>configured to place data elsewhere (appears not), and symlinking the 
>location of the volume to another filesystem as suggested by Michał. 
>Symlinking unfortunately also appears to not play well with the Docker 
>volume mechanisms.
>
>Do people see this is a potential limitation of Kolla (or maybe 
>Docker?), or are we (and our users) being unreasonable in expecting to 
>be able to place data on more than one filesystem?

Paul,

I don’t think it is an unreasonable request, but at present our architecture 
highly depends on named volumes.  I think this more of a problem for docker to 
solve (how to distribute /var/lib/docker over the host OS or many host Oses.

I think for the second case to work well, we need to stick with named volumes 
and let the Docker community sort it out.

The next step would be to file an issue with Docker's github account and 
essentially write down our requirements.

It is possible they are already working on this problem.

The fact that storage plugins are available with docker is one possible 
solution (storing /var/lib/docker in some third party storage such as Swift, 
AWS, CEPH, etc) that Docker Inc could possibly accelerate to meet the specific 
problem you have.

Meanwhile, I think it makes good sense to document that our "40gb disk space" 
is for compute nodes when used with ceph, and document the disk space 
requirements for control nodes separately (which can be 30-50gb/day with debug 
enabled).

Also we need to sort out log rotation of elasticsearch.  I think this is a 
pretty easy problem to solve, possibly even using the logrotate tool and cron.  
This would permit operators to specify the max size of disk space they want 
consumed by the control node, and we could use that to do log 
rotation/compression and eventually removal from elasticsearch's file-based 
database.

Regards
-steve
>
>Thanks,teve

>-Paul
>
>__
>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] [kolla] Barcelona Summit Friday Scheduling

[Steven Dake (stdake)]

Hey folks,

Summit space is a bit more constrained compared to Austin and there are more 
teams to accommodate.  Also there are no full day contributor meetups.  As a 
result, unlike past summits Koalleans have participated in, Friday is being 
scheduled by the foundation for workroom sessions and afternoon half-day 
contributor meetups.

The result is Friday is not really an optional day as it has been typically 
viewed in the past.

I'd ask that you do what you can to arrange your schedule if your interested in 
participating in Kolla design sessions around departing at the earliest 
Saturday of summit week to allow for full participation in the half day 
contributor meetup.  Also it is highly likely that some design sessions will be 
scheduled Friday morning as well.

That said, the scheduling hasn't finalized and we may not be granted a half day 
contributor meetup or workroom sessions on Friday morning.  I will provide 
further details relating to the Friday schedule as the OpenStack foundation 
completes scheduling.  I don't know when the scheduling will complete but will 
provide further details as soon as I have relevant information.

Regards
-steve

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

Re: [openstack-dev] [kolla] Requirement for bug when reno is present

[Steven Dake (stdake)]

From: Dave Walker mailto:em...@daviey.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 30, 2016 at 4:24 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Requirement for bug when reno is present


On 30 August 2016 at 11:42, Paul Bourke 
mailto:paul.bou...@oracle.com>> wrote:
Kolla,

Do people feel we still want to require a bug-id in the commit message for 
features, when reno notes are present? My understanding is that till now we've 
required people to add bugs for non trivial features in order to track them as 
part of releases. Does/should reno supersede this?

-Paul

I'm guess you raised this because my recent comment on a change you did... but 
actually, I agree with you.  I don't think it is a good process, but 
standardisation is key.

The issue comes around because Kolla wanted to use bugs to track potential 
backports to stable/*.  However, I think this is generally overrated and the 
Change-ID is suitable for this purpose.

Open to other options in the future.  Can you explain how change Ids can be 
used to track which bugs need to be backported?


I really hate raising bugs "just because", when realistically many of them are 
not bugs and contain one-line style "Add this $feature" bug description.  It 
just burns through Launchpad bug numbers, and will likely never be looked at 
again.

We shouldn't be using bugs for features IMO and definitely not for release 
candidates where an FFE hasn't been given.

Regards
-seve


--
Kind Regards,
Dave Walker
__
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] [kolla] important instructions or Newton Milestone #3 Release today 8/31/2015 @ ~23:30 UTC

[Steven Dake (stdake)]

Hey folks,

Milestone 3 will be submitted for tagging to the release team today around my 
end of work day.  All milestone 3 blueprints and bugs will be moved to rc1 in 
the case they don't make the August 31st(today) deadline.

We require fernet in rc1, so if there is anything that can be done to 
accelerate Shuan's work there, please chip in.  I'd like this to be our highest 
priority blueprint merge.  The earlier it merges (when functional) the more 
time we have to test the changes.  Please iterate on this review and review 
daily until merged.

We have made tremendous progress in milestone 3.  We ended up carrying over 
some blueprints as FFEs to rc1 which are all in review state right now and 
nearly complete.

The extension for  features concludes September 15th, 2016 when rc1 is tagged.  
If features don't merge by that time, they will be retargeted for Ocata.  When 
we submit the rc1 tag, master will branch.  After rc1, we will require bug 
backports from master to newton (and mitaka and liberty if appropriate).

We have a large bug backlog.  If folks could tackle that, it would be 
appreciated.  I will be spending most of my time doing that sort of work and 
would appreciate everyone on the team to contribute.  Tomorrow afternoon I will 
have all the rc1 bugs prioritized as seems fitting.

Please do not workflow+1 any blueprint work in the kolla repo until rc1 has 
been tagged.  Master of kolla is frozen for new features not already listed in 
the rc1 milestone.  Master of kolla-kubernetes is open for new features as we 
have not made a stable deliverable out of this repository (a 1.0.0 release).  
As a result, no branch will be made of the kolla-kubernetes repository (I 
think..).  If a branch is made, I'll request it be deleted.

If you have a bug that needs fixing and it doesn't need a backport, just use 
TrivialFix to speed up the process.  If it needs a backport, please use a bug 
id.  After rc1, all patches will need backports so everything should have a bug 
id.  I will provide further guidance after rc1.

A big shout out goes to our tremendous community that has pulled off 3 
milestones on schedule and in functional working order for the Kolla repository 
while maintaining 2 branches and releasing 4 z streams on a 45 day schedule.  
Fantastic work everyone!

Kolla-kubernetes also deserves a shout out – we have a functional compute-kit 
kubernetes underlay that deploys Kolla containers using mostly native 
kuberenetes functionality  We are headed towards a fully Kubernetes 
implementation.  The deployment lacks the broad feature-set of kolla-ansible 
but uses the json API to our containers and is able to spin up nova virtual 
machines with full network (OVS) connectivity – which is huge!

Cheers!
-steve
__
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] [kolla] Deadline Aug 31 for Newton Milestone #3

[Steven Dake (stdake)]

Hey folks,

The deadline for milestone #3 is August 31st (this is when we are tagging 
milestone #3).  We then have until September 15th to stabilize the release and 
tag rc1.  The release team branches occata at rc1, so if a feature doesn’t make 
rc1, its not making newton.  After rc1, any patches in master required for 
newton need to be backported into the stable/newton branch.

As far as bugs are concerned, we have a bit more time to release 3.0.0 because 
we use the cycle_trailing model.  However, our m1/m2/m3/rc1/rc2 must be on 
schedule.

Regards
-stee

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

Re: [openstack-dev] [kolla] Requirement for bug when reno is present

[Steven Dake (stdake)]

The bug id and blueprint id are for automatic tracking via Launchpad.  If they 
are omitted, managing the release becomes especially difficult.  Unfortunately 
launchpad doesn't know about reno because then I'd agree, that would be an 
optimal way too go.

Regards
-steve




On 8/30/16, 3:42 AM, "Paul Bourke"  wrote:

>Kolla,
>
>Do people feel we still want to require a bug-id in the commit message 
>for features, when reno notes are present? My understanding is that till 
>now we've required people to add bugs for non trivial features in order 
>to track them as part of releases. Does/should reno supersede this?
>
>-Paul
>
>__
>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] [kolla][osic] Ubuntu scale testing completed - now need CentOS deployed

[Steven Dake (stdake)]

Britt, Paul, and Michal,

We are in need of centos deployed on the osic cluster (but not the deployment 
node).  I'm not sure if we have time to get through all of the scenarios we 
have but I'd like to have data on centos as well.

When you wake up, if you could sort out getting centos deployed (and kolla 
master on top of it) that would be super helpful.

I have updated the review with the ubuntu data.

Regards
-steve

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

Re: [openstack-dev] [kolla][oisc] scenario #8 running - need help deploying centos next

[Steven Dake (stdake)]

Scenario #8 was running about 12 hours (mitaka rally and tempest testing) and 
was only half way done.  Inspection of the control machines showed out of disk 
space errors on the control nodes (which only have a 50gb total partition for 
where /var/lib/docker was stored).  Elasticsearch produces about 25gb/day under 
our rally benchmarks, so a cleanup was necessary.  Note during the out of disk 
space problem, OpenStack made forward progress, it was just extremely slow and 
many tests that would have passed with sufficient disk space did not.

Expect scenario #8 to complete and 4-6 hours and scenario #9 to take 2 hours.

Then the next step is a reload of the base os on al target deployment nodes to 
centos.  Ping me before undertaking this activity such that all data is 
captured for ubuntu.

Regards,
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 27, 2016 at 1:20 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][oisc] scenario #5 running

Scenario #6 is running – should finish in 4-6 hours.

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 27, 2016 at 4:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][oisc] scenario #5 running

Hey folks,

I didn't undo any of what Dave did to the cluster.  I wrote a simple shell 
script to run time on all of the operations.  We will be doing the same thing 
for liberty and mitaka.  I expect the test of all operations will take about 40 
minutes to 2 hours.

Full instructions are on the tmux screen for scenario 6 when scenario 5 
finishes.  Note you will need to undo the things Dave has done.  Ping me if you 
have questions on irc if you get to it before I do.

Regards
-steve

__
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] [kolla][ironic][bifrost][osic] future of bifrost & Ironic for Kolla

[Steven Dake (stdake)]

Hey Stackers & Sean :),

I just wanted to provide a quick update on where we think Kolla will be when 
ironic and bare metal config are fully fleshed out (landing in Newton).

3 controller, 20 storage, 100 compute with 
ceph+ovs+cinder+enable_central_logging on OSIC 130 node cluster

Currently openstack-only deployment takes 20 minutes
A bare metal dependency install and configuration takes about 10-15 minutes 
(the current playbook craters so this is just a rough estimate)
We would like to see the bifrost deployment complete in 35 minutes (we were 
unable to test this at 123 node scale because the patches haven't landed and we 
are out of osic time).

The goal is to keep a total deploy of 1 hour for 123 nodes from nothing to 
fully operational OpenStack cloud.

As far as subject, I feel pretty happy with the bifrost implementation as it 
exists today .  The idea of turning biforst into thin containers isn't hot on 
my list of things to do.  I am pretty happy with treating bifrost as a fat 
container and using containers here solely for dependency management to keep 
the host os tidy.

That isn't to say we won't ask for further changes to bifrost (and do the work 
to make them so).  I just don't see a strong  rationale for thin-containerizing 
bifrost.  We could change our minds in the future especially if the bifrost 
team were supportive of this idea.  For now I think its fruit at the top of the 
tree without much benefit.  The dependency management and integration with 
kolla will land in newton.

We also have a full ironic implementation that is thin-containerized that is 
nearing completion (tech preview for Newton) to serve the bare metal as a 
service use case.  We plan to use this for bare metal deployment via nova – 
much as is done with virtual machines by selecting a flavor and using nova 
boot.  We are not going to use bifrost for this portion of the job.  Most of 
the work here is getting ironic to cooperate with Vms in the nova scheduler via 
flavors.  I suspect we will have a design session at summit around this very 
topic but its really up to the next PTL.

Hope to see the Ironic  and Kolla community there in this critical (atleast to 
Kolla) cross-project integration effort.

Regards
-seve



__
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] [kolla] NOTICE: Deadline of 31st for milestone #3 - PLEASE UPDATE BLUEPRINT STATUS

[Steven Dake (stdake)]

Please take heed of the subject line.  It would be immensely helpful if people 
working on the 35 blueprints would get them into he correct state (good 
progress or NEEDS REVIEW) so we can best select which features land in Newton.  
Ping any of the cores on #openstack-kolla if you don’t have permissions to 
change the blueprint status.

Regards
-steve

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

Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Steven Dake (stdake)]

This vote has passed unanimously prior to August 30th, therefore, closing 
voting early.

Welcome to the core reviewer team Dave!  If you have any questions, feel free 
to ask any core reviewer or myself.  I have made the necessary changes in 
gerrit.

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 23, 2016 at 1:45 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][vote] Core nomination for Dave Walker (Daviey 
on irc)

Kolla core reviewers,

I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day 
review stats [1] place him in the middle of the pack for reviewers and his 60 
day stats[2] are about equivalent.  Dave participates heavily in IRC and has 
done some good technical work including the Watcher playbook and container.  He 
also worked on Sensu, but since we are unclear if we are choosing Sensu or Tig, 
that work is on hold.  He will also be helping us sort out how to execute with 
PBR going into the future on our stable and master branches.  Dave has proven 
to me his reviews are well thought out and he understands the Kolla 
Architecture.  Dave is part time like many Kolla core reviewers and is 
independent of any particular affiliation.

Consider this nomination as a +1 from me.

As a reminder, a +1 vote indicates you approve of the candidate, an abstain 
vote indicates you don't care or don't know for certain, and a –1 vote 
indicates a veto.  If a veto occurs or a unanimous response is reached prior to 
our 7 day voting window which concludes on August 30th, voting will be closed 
early.

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][oisc] scenario #5 running

[Steven Dake (stdake)]

Scenario #6 is running – should finish in 4-6 hours.

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 27, 2016 at 4:34 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][oisc] scenario #5 running

Hey folks,

I didn't undo any of what Dave did to the cluster.  I wrote a simple shell 
script to run time on all of the operations.  We will be doing the same thing 
for liberty and mitaka.  I expect the test of all operations will take about 40 
minutes to 2 hours.

Full instructions are on the tmux screen for scenario 6 when scenario 5 
finishes.  Note you will need to undo the things Dave has done.  Ping me if you 
have questions on irc if you get to it before I do.

Regards
-steve

__
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] [kolla][oisc] scenario #5 running

[Steven Dake (stdake)]

Hey folks,

I didn't undo any of what Dave did to the cluster.  I wrote a simple shell 
script to run time on all of the operations.  We will be doing the same thing 
for liberty and mitaka.  I expect the test of all operations will take about 40 
minutes to 2 hours.

Full instructions are on the tmux screen for scenario 6 when scenario 5 
finishes.  Note you will need to undo the things Dave has done.  Ping me if you 
have questions on irc if you get to it before I do.

Regards
-steve

__
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] [kolla] OSIC scale testing

[Steven Dake (stdake)]

Hey folks,

We have nearly automated all of the OSIC testing and there are instructions to 
follow in NEXTSTEPS.  They take about 1 hour to execute (to setup a test0 and 
then all done.  We have the cluster until the 30th.  I need folks that have 
access to help out as much as possible between now and the 30th so we can 
finish our data gathering.

Also as people go through the scenarios, can you give an update on the mailing 
list that you put in your hour on the NEXTSTEPS execution?  Thanks.

Regards
-steve

__
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] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Steven Dake (stdake)]

Kolla core reviewers,

I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day 
review stats [1] place him in the middle of the pack for reviewers and his 60 
day stats[2] are about equivalent.  Dave participates heavily in IRC and has 
done some good technical work including the Watcher playbook and container.  He 
also worked on Sensu, but since we are unclear if we are choosing Sensu or Tig, 
that work is on hold.  He will also be helping us sort out how to execute with 
PBR going into the future on our stable and master branches.  Dave has proven 
to me his reviews are well thought out and he understands the Kolla 
Architecture.  Dave is part time like many Kolla core reviewers and is 
independent of any particular affiliation.

Consider this nomination as a +1 from me.

As a reminder, a +1 vote indicates you approve of the candidate, an abstain 
vote indicates you don't care or don't know for certain, and a –1 vote 
indicates a veto.  If a veto occurs or a unanimous response is reached prior to 
our 7 day voting window which concludes on August 30th, voting will be closed 
early.

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/23/16, 7:05 AM, "Gerard Braad"  wrote:

>On Tue, Aug 23, 2016 at 9:56 PM, lương hữu tuấn  wrote:
>> I also prefer a dedicated user ("kolla" seems the best choice) as same > On 
>> Tue, Aug 23, 2016 at 3:51 PM, Paul Bourke  wrote:
>>> In my experience operators prefer a dedicated user (kolla:kolla), though I
>
>kolla:kolla seems more logical and simpler to reason about.
>

kolla:kolla still works with multi-user approach and permissions 660 on 
/etc/kolla files.

Regards
-steve

>
>-- 
>
>   Gerard Braad | http://gbraad.nl
>   [ Doing Open Source Matters ]
>
>__
>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] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/23/16, 1:04 AM, "duon...@vn.fujitsu.com"  wrote:

>Hi S.Dake,
>
>>> Hello Kollish,
>>>
>>> I am working on bp ansible-specific-task-become so I need community opinion 
>>> about Kolla configuration files owner and permissions.
>>>
>>> For files in "/var/lib/kolla", it's quite clear that the owner should be 
>>> 'root' as currently.
>>>
>>> For files in "/etc/kolla":  After discussion with S.Dake on IRC, he 
>>> recommends /etc/kolla is owned by root and all files in it is 660 (writable 
>>> by a group).
>>
>> Just to add a bit of clarity, the rationale for this idea is that a group of 
>> operators could add themselves to the kolla group on all of the nodes and 
>> use their specific ssh keys to operate OpenStack.  > This is why the group 
>> concept in unix was invented 50 odd years ago ;)
>
>I just notice that if the directory has 660, so non-root user cannot access 
>file in this folder. It seems conflict with group purpose.
>Should it be 770 for folders?

Yes 770 for folders 660 for files seeded by the user ids and their ssh keys in 
the host playbook that is in the review queue.  Changes to the host playbook in 
the review queue should come later for this group based model.

The real question is what do operators prefer?  Single user (non-root), 
Multi-user (non-root), or Single user (root).

Regards
-steve
>
>> Regards
>> -steve
>
>
>Best regards,
>
>duonghq
>PODC - Fujitsu Vietnam Ltd.
>
>
>
>__
>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] [kolla] Kolla configuration files owner and permission

[Steven Dake (stdake)]

On 8/22/16, 7:24 PM, "duon...@vn.fujitsu.com"  wrote:

>Hello Kollish,
>
>I am working on bp ansible-specific-task-become so I need community opinion 
>about Kolla configuration files owner and permissions.
>
>For files in "/var/lib/kolla", it's quite clear that the owner should be 
>'root' as currently.
>
>For files in "/etc/kolla":  After discussion with S.Dake on IRC, he recommends 
>/etc/kolla is owned by root and all files in it is 660 (writable by a group).

Just to add a bit of clarity, the rationale for this idea is that a group of 
operators could add themselves to the kolla group on all of the nodes and use 
their specific ssh keys to operate OpenStack.  This is why the group concept in 
unix was invented 50 odd years ago ;)

Regards
-steve

>
>Anybody has idea about this topic?
>
>Best regards,
>
>Ha Quang Duong (Mr.)
>PODC - Fujitsu Vietnam Ltd.
>
>
>__
>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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Steven Dake (stdake)]

Eduardo,

Their was a unanimous response in votes with no veto on this core reviewer 
nomination.  As a result, voting is closed early.

Welcome to the Kolla core review team!  Looking for further good work from you! 
 I have added you to the kolla-core team in gerrit.  You should have access to 
full +2/-2 voting rights on patches, as well as voting rights on Kolla's policy 
votes.  If you need a primer ping me or another core reviewer.

Regards
-steve


From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 18, 2016 at 4:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [vote][kolla] Core nomination proposal for Eduardo 
Gonzalez Gutierrez (egonzales90 on irc)

Kolla Core Review Team:

I am nominating Eduardo for the core reviewer team.  His reviews are fantastic, 
as I'm sure most of you have seen after looking over the review queue.  His 30 
day stats place him at #3 by review count [1] and 60 day stats [2] at #4 by 
review count.  He is also first to review a significant amount of the time - 
which is impressive for someone new to Kolla.  He participates in IRC and he 
has done some nice code contribution as well [3] including the big chunk of 
work on enabling Senlin in Kolla, the dockerfile customizations work, as well 
as a few documentation fixes.  Eduardo is not affiliated with any particular 
company.  As a result he is not full time on Kolla like many of our other core 
reviewers.  The fact that he is part time and still doing fantastically well at 
reviewing is a great sign of things to come :)

Consider this nomination as my +1 vote.

Voting is open for 7 days until August 24th.  Joining the core review team 
requires a majority of the core review team to approve within a 1 week period 
with no veto (-1) votes.  If a veto or unanimous decision is reached prior to 
August 24th, voting will close early.

Regards
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60
[3] 
https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22
__
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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Steven Dake (stdake)]

Coolsvap mentioned he wasn't receiving his emails at his home email
server, so he will respond from a different mail service.  Just bringing
this up again so he can see the thread.

Regards
-steve

On 8/19/16, 7:09 AM, "Kwasniewska, Alicja" 
wrote:

>+1 :)
>
>-Original Message-
>From: Ryan Hallisey [mailto:rhall...@redhat.com]
>Sent: Friday, August 19, 2016 2:50 PM
>To: OpenStack Development Mailing List (not for usage questions)
>
>Subject: Re: [openstack-dev] [vote][kolla] Core nomination proposal for
>Eduardo Gonzalez Gutierrez (egonzales90 on irc)
>
>+1
>
>-Ryan
>
>- Original Message -
>From: "Steven Dake (stdake)" 
>To: "OpenStack Development Mailing List (not for usage questions)"
>
>Sent: Thursday, August 18, 2016 7:09:35 PM
>Subject: [openstack-dev] [vote][kolla] Core nomination proposal for
>Eduardo Gonzalez Gutierrez (egonzales90 on irc)
>
>Kolla Core Review Team:
>
>I am nominating Eduardo for the core reviewer team. His reviews are
>fantastic, as I'm sure most of you have seen after looking over the
>review queue. His 30 day stats place him at #3 by review count [1] and 60
>day stats [2] at #4 by review count. He is also first to review a
>significant amount of the time ­ which is impressive for someone new to
>Kolla. He participates in IRC and he has done some nice code contribution
>as well [3] including the big chunk of work on enabling Senlin in Kolla,
>the dockerfile customizations work, as well as a few documentation fixes.
>Eduardo is not affiliated with any particular company. As a result he is
>not full time on Kolla like many of our other core reviewers. The fact
>that he is part time and still doing fantastically well at reviewing is a
>great sign of things to come :)
>
>Consider this nomination as my +1 vote.
>
>Voting is open for 7 days until August 24th. Joining the core review team
>requires a majority of the core review team to approve within a 1 week
>period with no veto (-1) votes. If a veto or unanimous decision is
>reached prior to August 24th, voting will close early.
>
>Regards 
>-steve 
>
>[1] http://stackalytics.com/report/contribution/kolla/30
>[2] http://stackalytics.com/report/contribution/kolla/60
>[3] 
>https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2
>540gmail.com%253E%22
>
>__
>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 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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Steven Dake (stdake)]

Kolla Core Review Team:

I am nominating Eduardo for the core reviewer team.  His reviews are fantastic, 
as I'm sure most of you have seen after looking over the review queue.  His 30 
day stats place him at #3 by review count [1] and 60 day stats [2] at #4 by 
review count.  He is also first to review a significant amount of the time - 
which is impressive for someone new to Kolla.  He participates in IRC and he 
has done some nice code contribution as well [3] including the big chunk of 
work on enabling Senlin in Kolla, the dockerfile customizations work, as well 
as a few documentation fixes.  Eduardo is not affiliated with any particular 
company.  As a result he is not full time on Kolla like many of our other core 
reviewers.  The fact that he is part time and still doing fantastically well at 
reviewing is a great sign of things to come :)

Consider this nomination as my +1 vote.

Voting is open for 7 days until August 24th.  Joining the core review team 
requires a majority of the core review team to approve within a 1 week period 
with no veto (-1) votes.  If a veto or unanimous decision is reached prior to 
August 24th, voting will close early.

Regards
-steve

[1] http://stackalytics.com/report/contribution/kolla/30
[2] http://stackalytics.com/report/contribution/kolla/60
[3] 
https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22
__
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] [kuryr][kolla] keystone v3 support status and plans?

[Steven Dake (stdake)]

Hey kuryrians,

Kolla has a kuryr review in our queue and its looking really solid from Hui 
Kang.  The last key problem blocking the merge (and support of Kuryr in Kolla) 
is that Kolla only supports keystone v3 (and later when that comes from 
upstream).  As a result we are unable to merge kuryr because we can't validate 
it.  The work on the kolla side is about 98% done (need a few keystone v3 
config options).  Wondering if keystone v3 will magically land in this cycle?  
Its not all that challenging, but I realize the kuryr team may have other 
things that are higher priority on their plates.

FWIW lack of keystone v3 support will be an adoption barrier for kuryr beyond 
kolla as well.

Comments welcome.

Regards
-steve

__
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] [kolla] FW: [all][ptl][tc] extra ATCs for newton

[Steven Dake (stdake)]

Koalligans,

I can't think of anyone off the top of my head that hasn't submitted a
patch for Newton that would qualify for an ATC pass under the bylaws [1]
and TC Charter [2], but would like to open up nominations from core
reviewers since I am not omnipotent.

The only candidates that even come to mind are the folks in OSIC that
facilitated the usage of the OSIC 131 node cluster for Kolla scale testing
under work in this review:
https://review.openstack.org/#/c/352101/


Please see inside for more details.

Apologies or short deadline, but nominations close August 14th, 2016 - in
time for me to prepare a patch, if one needs to be prepared.

Thanks!
-steve

On 8/10/16, 9:24 AM, "Doug Hellmann"  wrote:

>It's time to make sure we have all of our active technical contributors
>(ATCs) identified for Newton.
>
>Following the Foundation bylaws [1] and TC Charter [2], Project
>teams should identify contributors who have had a significant impact
>this cycle but who would not qualify for ATC status using the regular
>process because they have not submitted a patch.  Contributions
>might include, but aren't limited to, bug triage, design work, and
>documentation -- there is a lot of leeway in how teams define
>contribution for ATC status.
>
>The resulting list of names should be submitted as a patch to the
>"extra-atcs" section in openstack/governance/reference/projects.yaml
>for review by the TC.
>
>Although extra ATCs can be nominated at any point, there is a
>deadline to be included in the electorate for the next release
>cycle. The ATC list needs to be approved by the TC by 25 Aug, and
>in order to appear on the TC agenda to be discussed, the proposals
>need to be submitted by 16 Aug.
>
>PTLs can delegate preparing the patch to the governance repository, but
>please +1 the patch indicating that you agree with the list to avoid
>delays in the TC review.
>
>Thanks,
>Doug
>
>[1] http://www.openstack.org/legal/technical-committee-member-policy/
>[2] 
>http://governance.openstack.org/reference/charter.html#voters-for-tc-seats
>-atc
>
>__
>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] [kolla] Question about kolla git tag

[Steven Dake (stdake)]

Confirming Chao's statement.  We support this model all the time on the 
#openstack-kollal.

Thanks Chao.

Regards
-steve

From: 韩潮 mailto:hanc...@iscas.ac.cn>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 11, 2016 at 12:52 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Question about kolla git tag

IMHO, as the tag 2.0.2 and 2.0.3 are both Mitaka release based tag with minor
fixes, it should support and work to the same release legacy images. But then,
the built image tag needs to be specified before/during the "kolla-ansible
prechecks/deploy" process.

This is the experience that I tried with Liberty release with the tag 1.x.x.
Hope it also works for your situation.

Br,
Chao

> -原始邮件-
> 发件人: hu.zhiji...@zte.com.cn
> 发送时间: 2016年8月11日 星期四
> 收件人: 
> openstack-dev@lists.openstack.org
> 抄送:
> 主题: [openstack-dev]  [kolla] Question about kolla git tag
>
> Hi
>
> The image we built before is tagged automatically as 2.0.2. and now the
> kolla code has been upgrade to 2.0.3. I would like to ask if it is OK to
> use code 2.0.3 do deploy images 2.0.2, or we'd better to sync the version
> by using "git tag" command according to the image version?
>
> B.R.,
> Zhijiang
>
>
> __
> 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] [kolla][ironic][odm][ACTION NEEDED] Kolla's BiFrost and kolla-host work

[Steven Dake (stdake)]

Sean has done a fantastic job on the BiFrost work and kolla-host work.  What is 
needed is the last step - which is a final thorough technical review from the 
core review team so we can get it merged by end of week.  If your struggling to 
find the work in the review queue, use this link:

https://review.openstack.org/#/q/owner:%22sean+mooney+%253Csean.k.mooney%2540intel.com%253E%22

Finally a huge thanks to cinemera and the rest of the Ironic team for 
supporting our efforts to consume this upstream.

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

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Steven Dake (stdake)]

Well don't let me stop ya :)

On 8/9/16, 7:21 AM, "Ian Cordasco"  wrote:

> 
>
>-Original Message-----
>From: Steven Dake (stdake) 
>Reply: OpenStack Development Mailing List (not for usage questions)
>
>Date: August 6, 2016 at 07:48:01
>To: OpenStack Development Mailing List (not for usage questions)
>
>Subject:  Re: [openstack-dev]
>[Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project
>
>> an,
>>  
>> I value your input, but concern still stands. Amazon's compute API
>>moves slowly in comparison
>> to Docker registry's API. Making a parity implementation to the Docker
>>v2 registry API  
>> is a complex and difficult challenge. It is much more significant then
>>simply making  
>> an API. An implementation needs to stand behind that API.
>
>I don't disagree. I just have a higher opinion of the community's ability
>to achieve this goal and use Glare as the backend.
>
>>  
>> From: Ian Cordasco >
>> Reply-To: "OpenStack Development Mailing List (not for usage
>>questions)" >  
>> Date: Saturday, August 6, 2016 at 4:52 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" >
>> Subject: Re: [openstack-dev]
>>[Glance][TC][Heat][App-Catalog][Murano][Tacker]
>> Glare as a new Project
>>  
>>  
>> However, interested parties could start a project like the ec2 project
>>that is independently
>> released and provides that compatibility using glare
>>  
>> On Aug 6, 2016 5:18 AM, "Steven Dake (stdake)" >
>> wrote:
>> Kevin,
>>  
>> Agree it would be a very useful feature, however, easier said then
>>done. Part of Docker's
>> approach is to "move fast";they schedule releases every 2 months. I'm
>>sure the glare  
>> team is quite competent, however, keeping API parity on such a fast
>>moving project such
>> as the docker registry API is a big objective not to be undertaken
>>lightly. If there isn't
>> complete API parity with the docker rregistry v2 API, the work wouldn't
>>be particularly  
>> useful to many in the container communities inside OpenStack as Hongbin
>>pointed out.  
>>  
>> Regards
>> -steve
>>  
>> From: "Fox, Kevin M" >
>> Reply-To: "OpenStack Development Mailing List (not for usage
>>questions)" >  
>> Date: Friday, Mooney"OpenStack Development Mailing List (not for usage
>>questions)"  
>> son between Image API and Artifact API is not
>> correct. Moreover, in my opinion Image API imposes artificial
>>constraints. Just imagine
>> that your file system can only store images in JPG format (more
>>precisely, it could store
>> any data, but it is imperative that all files must have the extension
>>".jpg"). Likewise
>> Glance - I can put there any data, it can be both packages and
>>templates, as well as video
>> from my holiday. And this interface, though not ideal, may not work for
>>all services.  
>> But those artificial limitations that have been created, do Glance
>>uncomfortable even
>> for storing images.
>>  
>> On the other hand Glare provides unified interface for all possible
>>binary data types.
>> If we take the example with filesystem, in Glare's case it supports all
>>file extensions, 
>> folders, history of file changes on your disk, data validation and
>>conversion, import/export
>> files from different computers and so on. These features are not
>>presented in Glance
>> and I think they never will, because of deficiencies in the
>>architecture.
>>  
>> For this reason I think Glare's adoption is important and it will be a
>>huge step forward
>> for OpenStack and the whole community.
>>  
>> Thanks again! If you want to support us, please vote for our talk on
>>Barcelona summit -
>> https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/
>>Search  
>> "Glare" and there will be our presentation.
>>  
>> Best,
>> Mike
>>  
>> On Fri, Aug 5, 2016 at 5:22 PM, Jonathan D. Proulx >
>> wrote:
>>  
>> I don't have a strong opinion on the split vs stay discussion. It
>> does seem there's been sustained if ineffective attempts to keep this
>> together so I lean toward supporting the divorce.
>>  
>> But let's not pretend there are no costs for this.
>>  
>> On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:
>> :On 0

Re: [openstack-dev] [glare][kolla][odm] timing of release of glare and request for technical interview on IRC wherever the glare team wants to have it

[Steven Dake (stdake)]

Mike was kind enough to drop by the IRC channel today to help the
operational deployment managers (ODMs) understand the impact of Glare for
technical planning purposes.

The log of the discussion is here:
http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-koll
a.2016-08-08.log.html#t2016-08-08T16:01:50


Thanks again Mike.

Regards,
-steve

On 8/8/16, 8:01 AM, "Jay Pipes"  wrote:

>On 08/08/2016 07:48 AM, Steven Dake (stdake) wrote:
>> Cool thanks for the response.  Appreciate it.  I think the big take away
>> is all the ODMs are free from churn in Newton and have a full cycle to
>> adapt to the changes which is great news!
>
>Yes, that is absolutely the case.
>
>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


__
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] [glare][kolla] timing of release of glare and request for technical interview on IRC wherever the glare team wants to have it

[Steven Dake (stdake)]

Cool thanks for the response.  Appreciate it.  I think the big take away is all 
the ODMs are free from churn in Newton and have a full cycle to adapt to the 
changes which is great news!

Thanks!
-steve


From: Mikhail Fedosin mailto:mfedo...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 8, 2016 at 3:09 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [glare][kolla] timing of release of glare and 
request for technical interview on IRC wherever the glare team wants to have it

Hello Steven!
Our plans for Glare in Newton are: 1. Implement beta version of App-Catalog, 
based on Glare v1; 2. Develop an experimental support (POC) for Murano, Heat 
and probably Tacker. It means that all big updates will be in Ocata, and 
despite the fact that the code will be ready in this cycle, I do not think we 
need an immediate adoption in Kolla.

And for sure, I'll be glad to answer all your questions, 1600 UTC today works 
for me. So, let's meet at this time in your channel.

Best,
Mike

On Sat, Aug 6, 2016 at 2:21 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Hey folks,

I guess the split of glare and glance have been in the works for awhile.  It is 
challenging for operational deployment managers (ODMs) such as Kolla to keep up 
with the internal goings-on of every big tent project (or projects that shave 
off from big-tent projects).  Just to be clear up front, the Kolla community 
doesn't care that glare split the work out.  The Kolla development team adapts 
very quickly to upstream changes.  What we do care about is that we present an 
accurate deployment for Newton that represents the best that OpenStack has to 
offer and offer a seamless operational experience - within Kolla's capacity 
constraints.

 I need information on when the code base will be ready to consume (from a 
tarball on tarballs.oo).  Is this planned for milestone 3 - or post Newton?  
I'd recommend post-Newton for the split to be consumable - it would ease the 
difficulty of adoption if the various ODMs (and Operators) had more then 3 
weeks to work with on what is clearly a project required by every deployment 
based upon the threads I read.

I have some other technical questions related to how the glance registry 
disappears (I believe this point was mentioned in another thread by Jay) as 
well as the upgrade mechanism (if any is needed) that would best be served by a 
high bandwidth conversation on IRC (and those conversations are recorded on 
eavesdrop for others to benefit).

Would one of the technical cats from glare team drop by #opentack-kolla so we 
can get a quick (30 minutes) technical interview on the work to understand how 
this change impacts OpenStack in the short term (prior to Newton) and the long  
term layout of the two projects so we can make a determination a to how to 
proceed technically?  I don't necessarily need to be there - any of our core 
reviewer team can handle the Q&A - but would like to be there if possible.

If that doesn't work for the glare team, could we get 30 minutes of agenda time 
in what I'm sure is a busy glare team meeting to have the same technical 
discussion?

If that doesn't work for the glare team, we can host the topic in the kolla 
team meeting (UTC1600 on Wednesdays) if a glare core reviewer or the glare PTL 
can stop by.

Please let me know how you wish to proceed.

TIA
-steve


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [osic][kolla] Start of OSIC scale testing documentation [WIP]

[Steven Dake (stdake)]

Hey Koalaians,

See review:
https://review.openstack.org/352101

What I'd like to see happen is everyone working on scale testing commit their 
work by pulling down that review, modifying it, and submitting it to gerrit.  
Lets not mege it until the OSIC cluster is no longer in our hands.  If you want 
to review the documentation along the way that works too - so we can fix any 
problems found.  I think this will be better then a etherpad->git conversion 4 
weeks from now.  Lets do the conversion along the way.

TIA :)
-steve

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

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Steven Dake (stdake)]

Ian,

I value your input, but concern still stands.  Amazon's compute API moves 
slowly in comparison to Docker registry's API.  Making a parity implementation 
to the Docker v2 registry API is a complex and difficult challenge.  It is much 
more significant then simply making an API.  An implementation needs to stand 
behind that API.

Regards
-steve

From: Ian Cordasco mailto:sigmaviru...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 6, 2016 at 4:52 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project


However, interested parties could start a project like the ec2 project that is 
independently released and provides that compatibility using glare

On Aug 6, 2016 5:18 AM, "Steven Dake (stdake)" 
mailto:std...@cisco.com>> wrote:
Kevin,

Agree it would be a very useful feature, however, easier said then done.  Part 
of Docker's approach is to "move fast";they schedule releases every 2 months.  
I'm sure the glare team is quite competent, however, keeping API parity on such 
a fast moving project such as the docker registry API is a big objective not to 
be undertaken lightly.  If  there isn't complete API parity with the docker 
rregistry v2 API, the work wouldn't be particularly useful to many in the 
container communities inside OpenStack as Hongbin pointed out.

Regards
-steve

From: "Fox, Kevin M" mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 5, 2016 at 2:29 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

If glare was docker repo api compatible though, I think it would be quite 
useful. then each tenant doesn't have to set one up themselves.

Thanks,
Kevin


From: Hongbin Lu [hongbin...@huawei.com<mailto:hongbin...@huawei.com>]
Sent: Friday, August 05, 2016 1:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

Replied inline.

From: Mikhail Fedosin [mailto:mfedo...@mirantis.com]
Sent: August-05-16 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

Thank you all for your responses!

>From my side I can add that our separation is a deliberate step. We 
>pre-weighed all pros and cons and our final decision was that moving forward 
>as a new project is the lesser of two evils. Undoubtedly, in the short term it 
>will be painful, but I believe that in the long run Glare will win.

Also, I want to say, that Glare was designed as an open project and we want to 
build a good community with members from different companies. Glare suppose to 
be a backend for Heat (and therefore TripleO), App-Catalog, Tacker and 
definitely Nova. In addition we are considering the possibility of storage 
Docker containers, which may be useful for Magnum.

[Hongbin Lu] Magnum doesn’t have any plan to store docker images at Glare, 
because COE (i.e. Kubernetes) is simply incompatible with any API other than 
docker registry. Zun might have use cases to store docker images at Glare if 
Glare is part of Glance, but I am reluctant to set a dependency on Glare if 
Glare is a totally branch new service.

Then, I think that comparison between Image API and Artifact API is not 
correct. Moreover, in my opinion Image API imposes artificial constraints. Just 
imagine that your file system can only store images in JPG format (more 
precisely, it could store any data, but it is imperative that all files must 
have the extension ".jpg"). Likewise Glance - I can put there any data, it can 
be both packages and templates, as well as video from my holiday. And this 
interface, though not ideal, may not work for all services. But those 
artificial limitations that have been created, do Glance uncomfortable even for 
storing images.

On the other hand Glare provides unified interface for all possible binary data 
types. If we take the example with filesystem, in Glare's case it supports all 
file extensions, folders, history of file changes on your disk, data validation 
and conversion, import/export files from different computers and so on. These 
features are not presented in Glance and I think they never will, because of 
deficiencies in the arch

Re: [openstack-dev] [kolla] I need help on multisite deploy

[Steven Dake (stdake)]

Lu Yao,

Please drop by #openstack-kolla and our community can help you get rolling.  
Although now isn't a particularly good time (4:30 AM PST) - I'm awake and can 
get you up and running.  My nick is sdake.

Regards,
-steve

From: "lu.yao...@zte.com.cn" 
mailto:lu.yao...@zte.com.cn>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 6, 2016 at 12:52 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] I need help on multisite deploy

When I deploy multinode with kolla，one of the hosts raise error as follows， I 
need help to solve the problem. Can you help me？ Thanks！


ASK: [neutron | Starting openvswitch-vswitchd container] *
<10.43.114.20> ESTABLISH CONNECTION FOR USER: root
<10.43.114.48> ESTABLISH CONNECTION FOR USER: root
<10.43.114.20> REMOTE_MODULE kolla_docker 
image=10.43.177.190:4000/kolla/centos-binary-openvswitch-vswitchd:2.0.3 
action=start_container name=openvswitch_vswitchd
<10.43.114.48> REMOTE_MODULE kolla_docker 
image=10.43.177.190:4000/kolla/centos-binary-openvswitch-vswitchd:2.0.3 
action=start_container name=openvswitch_vswitchd
<10.43.114.20> EXEC ssh -C -tt -v -o ControlMaster=auto -o ControlPersist=60s 
-o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o 
KbdInteractiveAuthentication=no -o 
PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o 
PasswordAuthentication=no -o ConnectTimeout=10 10.43.114.20 /bin/sh -c 'mkdir 
-p $HOME/.ansible/tmp/ansible-tmp-1470384034.9-178486079034193 && echo 
$HOME/.ansible/tmp/ansible-tmp-1470384034.9-178486079034193'
<10.43.114.48> EXEC ssh -C -tt -v -o ControlMaster=auto -o ControlPersist=60s 
-o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o 
KbdInteractiveAuthentication=no -o 
PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o 
PasswordAuthentication=no -o ConnectTimeout=10 10.43.114.48 /bin/sh -c 'mkdir 
-p $HOME/.ansible/tmp/ansible-tmp-1470384034.9-111241252335895 && echo 
$HOME/.ansible/tmp/ansible-tmp-1470384034.9-111241252335895'
<10.43.114.20> PUT /tmp/tmppMwwNZ TO 
/root/.ansible/tmp/ansible-tmp-1470384034.9-178486079034193/kolla_docker
<10.43.114.48> PUT /tmp/tmp9l7GF6 TO 
/root/.ansible/tmp/ansible-tmp-1470384034.9-111241252335895/kolla_docker
<10.43.114.20> EXEC ssh -C -tt -v -o ControlMaster=auto -o ControlPersist=60s 
-o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o 
KbdInteractiveAuthentication=no -o 
PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o 
PasswordAuthentication=no -o ConnectTimeout=10 10.43.114.20 /bin/sh -c 'LANG=C 
LC_CTYPE=C /usr/bin/python 
/root/.ansible/tmp/ansible-tmp-1470384034.9-178486079034193/kolla_docker; rm 
-rf /root/.ansible/tmp/ansible-tmp-1470384034.9-178486079034193/ >/dev/null 
2>&1'
<10.43.114.48> EXEC ssh -C -tt -v -o ControlMaster=auto -o ControlPersist=60s 
-o ControlPath="/root/.ansible/cp/ansible-ssh-%h-%p-%r" -o 
KbdInteractiveAuthentication=no -o 
PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o 
PasswordAuthentication=no -o ConnectTimeout=10 10.43.114.48 /bin/sh -c 'LANG=C 
LC_CTYPE=C /usr/bin/python 
/root/.ansible/tmp/ansible-tmp-1470384034.9-111241252335895/kolla_docker; rm 
-rf /root/.ansible/tmp/ansible-tmp-1470384034.9-111241252335895/ >/dev/null 
2>&1'
failed: [10.43.114.20] => {"changed": true, "failed": true}
msg: APIError(HTTPError(u'409 Client Error: Conflict for url: 
http+docker://localunixsocket/v1.23/containers/create?name=openvswitch_vswitchd',),)
changed: [10.43.114.48] => {"changed": true, "result": false}
__
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] [glare][kolla] timing of release of glare and request for technical interview on IRC wherever the glare team wants to have it

[Steven Dake (stdake)]

Hey folks,

I guess the split of glare and glance have been in the works for awhile.  It is 
challenging for operational deployment managers (ODMs) such as Kolla to keep up 
with the internal goings-on of every big tent project (or projects that shave 
off from big-tent projects).  Just to be clear up front, the Kolla community 
doesn't care that glare split the work out.  The Kolla development team adapts 
very quickly to upstream changes.  What we do care about is that we present an 
accurate deployment for Newton that represents the best that OpenStack has to 
offer and offer a seamless operational experience - within Kolla's capacity 
constraints.

 I need information on when the code base will be ready to consume (from a 
tarball on tarballs.oo).  Is this planned for milestone 3 - or post Newton?  
I'd recommend post-Newton for the split to be consumable - it would ease the 
difficulty of adoption if the various ODMs (and Operators) had more then 3 
weeks to work with on what is clearly a project required by every deployment 
based upon the threads I read.

I have some other technical questions related to how the glance registry 
disappears (I believe this point was mentioned in another thread by Jay) as 
well as the upgrade mechanism (if any is needed) that would best be served by a 
high bandwidth conversation on IRC (and those conversations are recorded on 
eavesdrop for others to benefit).

Would one of the technical cats from glare team drop by #opentack-kolla so we 
can get a quick (30 minutes) technical interview on the work to understand how 
this change impacts OpenStack in the short term (prior to Newton) and the long  
term layout of the two projects so we can make a determination a to how to 
proceed technically?  I don't necessarily need to be there - any of our core 
reviewer team can handle the Q&A - but would like to be there if possible.

If that doesn't work for the glare team, could we get 30 minutes of agenda time 
in what I'm sure is a busy glare team meeting to have the same technical 
discussion?

If that doesn't work for the glare team, we can host the topic in the kolla 
team meeting (UTC1600 on Wednesdays) if a glare core reviewer or the glare PTL 
can stop by.

Please let me know how you wish to proceed.

TIA
-steve

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

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Steven Dake (stdake)]

Kevin,

Agree it would be a very useful feature, however, easier said then done.  Part 
of Docker's approach is to "move fast";they schedule releases every 2 months.  
I'm sure the glare team is quite competent, however, keeping API parity on such 
a fast moving project such as the docker registry API is a big objective not to 
be undertaken lightly.  If  there isn't complete API parity with the docker 
rregistry v2 API, the work wouldn't be particularly useful to many in the 
container communities inside OpenStack as Hongbin pointed out.

Regards
-steve

From: "Fox, Kevin M" mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 5, 2016 at 2:29 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

If glare was docker repo api compatible though, I think it would be quite 
useful. then each tenant doesn't have to set one up themselves.

Thanks,
Kevin


From: Hongbin Lu [hongbin...@huawei.com]
Sent: Friday, August 05, 2016 1:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

Replied inline.

From: Mikhail Fedosin [mailto:mfedo...@mirantis.com]
Sent: August-05-16 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

Thank you all for your responses!

>From my side I can add that our separation is a deliberate step. We 
>pre-weighed all pros and cons and our final decision was that moving forward 
>as a new project is the lesser of two evils. Undoubtedly, in the short term it 
>will be painful, but I believe that in the long run Glare will win.

Also, I want to say, that Glare was designed as an open project and we want to 
build a good community with members from different companies. Glare suppose to 
be a backend for Heat (and therefore TripleO), App-Catalog, Tacker and 
definitely Nova. In addition we are considering the possibility of storage 
Docker containers, which may be useful for Magnum.

[Hongbin Lu] Magnum doesn’t have any plan to store docker images at Glare, 
because COE (i.e. Kubernetes) is simply incompatible with any API other than 
docker registry. Zun might have use cases to store docker images at Glare if 
Glare is part of Glance, but I am reluctant to set a dependency on Glare if 
Glare is a totally branch new service.

Then, I think that comparison between Image API and Artifact API is not 
correct. Moreover, in my opinion Image API imposes artificial constraints. Just 
imagine that your file system can only store images in JPG format (more 
precisely, it could store any data, but it is imperative that all files must 
have the extension ".jpg"). Likewise Glance - I can put there any data, it can 
be both packages and templates, as well as video from my holiday. And this 
interface, though not ideal, may not work for all services. But those 
artificial limitations that have been created, do Glance uncomfortable even for 
storing images.

On the other hand Glare provides unified interface for all possible binary data 
types. If we take the example with filesystem, in Glare's case it supports all 
file extensions, folders, history of file changes on your disk, data validation 
and conversion, import/export files from different computers and so on. These 
features are not presented in Glance and I think they never will, because of 
deficiencies in the architecture.

For this reason I think Glare's adoption is important and it will be a huge 
step forward for OpenStack and the whole community.

Thanks again! If you want to support us, please vote for our talk on Barcelona 
summit - https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/ 
Search "Glare" and there will be our presentation.

Best,
Mike

On Fri, Aug 5, 2016 at 5:22 PM, Jonathan D. Proulx 
mailto:j...@csail.mit.edu>> wrote:

I don't have a strong opinion on the split vs stay discussion. It
does seem there's been sustained if ineffective attempts to keep this
together so I lean toward supporting the divorce.

But let's not pretend there are no costs for this.

On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:
:On 08/04/2016 06:40 PM, Clint Byrum wrote:

:>But, if I look at this from a user perspective, if I do want to use
:>anything other than images as cloud artifacts, the story is pretty
:>confusing.
:
:Actually, I beg to differ. A unified OpenStack Artifacts API,
:long-term, will be more user-friendly and less confusing since a
:single API can be used for various kinds of similar artifacts --
:images, Heat templates, Tosca flows, Murano app ma

Re: [openstack-dev] [kolla][osic][bifrost] OSIC cluster status

[Steven Dake (stdake)]

Hey folks,

Thanks for the video, those are great - if not a little hard for the
casual observer to follow.

That said, benchmark results of scale testing can be a dangerous game to
play, so lets not play games about it.

I'd like to see a full characterization of the hardware gear and topology
under test so others can duplicate the results if they so desire.  Lets
get this stuff in the repo in the doc directory asap - starting now (or
Monday, since its the weekend and our team needs some well earned R&R).
I'll login to the OSIC cluster this weekend and get the documentation
started with what I think would be helpful information for folks
evaluating scale testing benchmarks.  Since I wasn't actively involved
with the gear setup, I will be requiring help (in a starred set of
reviews) to correctly identify the hardware under test, how the networks
are setup, how the filesystems are setup, how the raid is setup, how
docker is configured, the exact make and model of the CPU, chipset, brand
and model of nvme SSDs, and memory bandwidth (I assume its quad channel
memory, but more details are needed).  I'd like to objectively benchmark
performance of /var/lib/docker, the root filesystem, and the memory
bandwidth of the using respected third party benchmarking tools.

The results in this thread are just preliminary to share with the
community, but please wait for the final documentation in our repository
to be completed in about 3 weeks to pass judgement on the scale
performance.

One thing that is clear from the video Michal produced is indeed Kolla can
scale to 4 controller nodes and 101 compute nodes (IIRC I believe on IRC
he indicated this was the system configuration used during our dead
chicken testing) with no problems other then human error (which Sean
Mooney is rapidly working to eliminate via his team's bare metal
deployment work with BiFrost thanks in no small part to the contributions
of the BiFrost and Ironic community).  The deployment is very fast (20
minutes) on very fast hardware (the OSIC kit is super fantastically fast).
 We also intend to measure day 2 scenarios (such as upgrade and
reconfigure) with a variety of configuration options (including ceph as a
storage system).

One thing that wasn't mentioned in these threads is some basic testing of
the OpenStack cluster was done to validate it was functional in the
control and data planes of the system.

These results are real with video evidence but as I'e stated the
characterization is incomplete.

I'd like to thank OSIC for facilitating this community effort to help
gather some real-wrold benchmarks of how well atleast Kolla performs in
deployment and operational functionality.

If folks have other interests in specific data please weigh in.  Once our
loan of the hardware is up, it may be some time before we have another
shot at using it.

We are far from finished with using the OSIC cluster - we have a tough
slog ahead finishing our scale testing benchmarking results - thanks to
the Kolla community for sticking with it and doing their best to produce
objective results for consumption by a variety of individuals.

I'm sure there is something I missed in the need to characterize the
systems under test, so if I missed something above, please point it out so
we can fix it up front.

Thanks and fantastic work!
-steve


On 8/5/16, 11:53 AM, "Michał Jastrzębski"  wrote:

>And we finished our first deployment
>We had some hurdles due to misconfiguration, you can see it in along
>with a fix. After these fixes and cleanups performed (we don't want to
>affect resulting time now do we?), we deployed functional openstack
>successfully within 20min:) More videos and tests to come!
>
>https://www.youtube.com/watch?v=RNZMtym5x1c
>
>
>
>On 5 August 2016 at 11:48, Paul Bourke  wrote:
>> Hi Kolla,
>>
>> Thought it will be helpful to send a status mail once we hit
>>checkpoints in
>> the osic cluster work, so people can keep up to speed without having to
>> trawl IRC.
>>
>> Reference: https://etherpad.openstack.org/p/kolla-N-midcycle-osic
>>
>> Work began on the cluster Wed Aug 3rd, item 1) from the etherpad is now
>> complete. The 131 bare metal nodes have been provisioned with Ubuntu
>>14.04,
>> networking is configured, and all Kolla prechecks are passing.
>>
>> The default set of images (--profile default) have been built and
>>pushed to
>> a registry running on the deployment node, the build taking a very
>>speedy
>> 5m37.040s.
>>
>> Cheers,
>> -Paul
>>
>> 
>>_
>>_
>> 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] [docker] [magnum] Magnum account on Docker Hub

[Steven Dake (stdake)]

Tango,

Sorry to hear that, but glad I could help clarify things :)

Regards
-steve

From: Ton Ngo mailto:t...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 5, 2016 at 7:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub


Thanks Steve, Spyros. I checked with Docker Hub support and the "magnum" 
account is not registered to Steve,
so we will just use the new account "openstackmagnum".
Ton,

[Inactive hide details for Spyros Trigazis ---08/02/2016 09:27:38 AM---I just 
filed a ticket to acquire the username openstackma]Spyros Trigazis 
---08/02/2016 09:27:38 AM---I just filed a ticket to acquire the username 
openstackmagnum. I included Hongbin's contact informat

From: Spyros Trigazis mailto:strig...@gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: 08/02/2016 09:27 AM
Subject: Re: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub





I just filed a ticket to acquire the username openstackmagnum.

I included Hongbin's contact information explaining that he's the project's PTL.

Thanks Steve,
Spyros


On 2 August 2016 at 13:29, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

Ton,

I may or may not have set it up early in Magnum's development.  I just don't 
remember.  My recommendation is to file a support ticket with docker and see if 
they will tell you who it belongs to (as in does it belong to one of the 
founders of Magnum) or if it belongs to some other third party.  Their support 
is very fast.  They may not be able to give you the answer if its not an 
openstacker.

Regards
-steve


From: Ton Ngo mailto:t...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 1, 2016 at 1:06 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub
Hi everyone,
At the last IRC meeting, the team discussed the need for hosting some container 
images on Docker Hub
to facilitate development. There is currently a Magnum account on Docker Hub, 
but this is not owned by anyone
on the team, so we would like to find who the owner is and whether this account 
was set up for OpenStack Magnum.
Thanks in advance!
Ton Ngo,

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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<mailto: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] [kolla] Needing volunteers for Geography Coordinators for making use of OSIC cluster

[Steven Dake (stdake)]

Typo is subject tag - please see inside :)

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 5, 2016 at 6:52 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kollla] Needing volunteers for Geography Coordinators 
for making use of OSIC cluster

Hey folks,

The kind folks at OSIC have granted the Kolla team access to 132 nodes of super 
high powered gear for scale testing Kolla.  The objectives are 3 fold:

  1.  Determine if Kolla can scale to 132 nodes for a variety of test cases - 
if not fix bugs around those problems
  2.  If scalable to 132 nodes, record benchmark data around our various test 
scenarios as outlined in the etherpad
  3.  Produce documentation in our repository at conclusion of OSIC scale 
testing indicating the results we found

The geography coordinators are responsible for coordinating various testing 
going on within their respective geography to coordinate the activities taking 
place on the loaned OSIC gear so we can "follow-the-sun" and make the most use 
of the gear while we have it.  The geo coordinators are also responsible for 
ensuring all bugs related to problems found during osic scale testing are 
tagged with "osic" in launchpad.

We need a geo coordinator for APAC, EMEA, and US.  First individual to respond 
on list gets the job (per geo - need 3 volunteers)

We have the gear for 4 weeks.  We are making use of the first 3 weeks to do 
scale testing of existing Kolla and the last week to test / validate / debug 
Sean's bifrost automated bare metal deployment work at scale.

The current state is the hardware is undergoing manual bare metal deployment at 
present - closing in on this task being completed hopefully by end of day 
(Friday Aug 5th, 2016).

For more information, please reference the Etherpad here:
https://etherpad.openstack.org/p/kolla-N-midcycle-osic

TIA to volunteers.

Cheers,
-steak
__
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] [kollla] Needing volunteers for Geography Coordinators for making use of OSIC cluster

[Steven Dake (stdake)]

Hey folks,

The kind folks at OSIC have granted the Kolla team access to 132 nodes of super 
high powered gear for scale testing Kolla.  The objectives are 3 fold:

  1.  Determine if Kolla can scale to 132 nodes for a variety of test cases - 
if not fix bugs around those problems
  2.  If scalable to 132 nodes, record benchmark data around our various test 
scenarios as outlined in the etherpad
  3.  Produce documentation in our repository at conclusion of OSIC scale 
testing indicating the results we found

The geography coordinators are responsible for coordinating various testing 
going on within their respective geography to coordinate the activities taking 
place on the loaned OSIC gear so we can "follow-the-sun" and make the most use 
of the gear while we have it.  The geo coordinators are also responsible for 
ensuring all bugs related to problems found during osic scale testing are 
tagged with "osic" in launchpad.

We need a geo coordinator for APAC, EMEA, and US.  First individual to respond 
on list gets the job (per geo - need 3 volunteers)

We have the gear for 4 weeks.  We are making use of the first 3 weeks to do 
scale testing of existing Kolla and the last week to test / validate / debug 
Sean's bifrost automated bare metal deployment work at scale.

The current state is the hardware is undergoing manual bare metal deployment at 
present - closing in on this task being completed hopefully by end of day 
(Friday Aug 5th, 2016).

For more information, please reference the Etherpad here:
https://etherpad.openstack.org/p/kolla-N-midcycle-osic

TIA to volunteers.

Cheers,
-steak
__
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] Project mascots update

[Steven Dake (stdake)]

From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 4, 2016 at 9:13 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] Project mascots update

Steve Dake asked: "Heidi, I received a related question from a Kolla core 
reviewer. Do the project teams have input into the mascot design? If this has 
already been discussed on the list, I may have missed it."

HJ: While we haven't discussed this on the ML, we referenced a bit in the web 
page. Our intent is to create a family of logos that have a distinctive design 
style that is unique to OpenStack community projects. That illustration style 
is something my colleague Todd Morey (OSF creative director) has been working 
on with several professional illustrators, choosing the best of the bunch, and 
developing a handful of logos that will serve as guideposts for the rest of 
design.

We don't have illustration resources sufficient to seek team input on 
individual designs-that's why we emphasized team input on the mascot concept. 
(As I told Steve Hardy, I'm happy to talk to anyone who has special requests on 
how their mascot is portrayed.) Also, while nearly everyone has an opinion 
about design, those opinions will be varied (and often contradictory). I hope 
you'll be willing to trust the excellent design leadership that produced our 
Summit designs, craveable shirts and stickers, and OpenStack's evolving visual 
identity. That said, I'll be thrilled to hear from anyone with opinions on 
design to find out more about your perspective. I love talking about this stuff.



Heidi,

Of course we trust the excellent design leadership that has produced all of the 
great creative work that the OpenStack foundation has produced representing our 
visual identity.  It was a question that came up in our team meeting and one of 
our core reviewers wanted an answer (and I wasn't sure).  Thanks for answering 
:)

Regards
-steve


__
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] Project mascots update

[Steven Dake (stdake)]

On 8/3/16, 10:37 AM, "Steven Hardy"  wrote:

>On Wed, Aug 03, 2016 at 10:19:10AM -0700, Heidi Joy Tretheway wrote:
>>Thanks to all of you for contributing unique and inspiring ideas to
>>choose
>>a team mascot. You can view a list of projects that have chosen their
>>mascots here: http://www.openstack.org/project-mascots, and more
>>will be
>>added soon as the last handful of teams finalize theirs.
>>Illustrators are
>>working now to produce a family of great logos for you that will
>>come out
>>closer to the Barcelona Summit. Feel free to drop me a note with
>>questions.
>
>I have one question regarding the review process for the logos when they
>are drafted?
>
>In the cases where projects have their existing community generated logos
>I can imagine there will be a preference to stick with something that's
>somehow derived from their existing logo, and in cases where a new logo is
>produced I'm sure community enthusiasm and acceptance will be greater if
>team members have played a part in the logo design process or at least
>provided some feedback prior to the designs being declared final?
>
>Thanks!
>
>Steve Hardy

Heidi,

I received a related question from a Kolla core reviewer.  "Do the project
teams have input into the mascot design."

If this has already been discussed on the list, I may have missed it.

Thanks
-steve

>
>__
>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] persistently single-vendor projects

[Steven Dake (stdake)]

Responses inline:

On 8/2/16, 8:13 AM, "Hayes, Graham"  wrote:

>On 02/08/2016 15:42, Flavio Percoco wrote:
>> On 01/08/16 10:19 -0400, Sean Dague wrote:
>>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
 Thierry, Ben, Doug,

 How can we distinguish between. "Project is doing the right thing, but
 others are not joining" vs "Project is actively trying to keep people
 out"?
>>>
>>> I think at some level, it's not really that different. If we treat them
>>> as different, everyone will always believe they did all the right
>>> things, but got no results. 3 cycles should be plenty of time to drop
>>> single entity contributions below 90%. That means prioritizing bugs /
>>> patches from outside groups (to drop below 90% on code commits),
>>> mentoring every outside member that provides feedback (to drop below
>>>90%
>>> on reviews), shifting development resources towards mentoring / docs /
>>> on ramp exercises for others in the community (to drop below 90% on
>>>core
>>> team).
>>>
>>> Digging out of a single vendor status is hard, and requires making that
>>> your top priority. If teams aren't interested in putting that ahead of
>>> development work, that's fine, but that doesn't make it a sustainable
>>> OpenStack project.
>>
>>
>> ++ to the above! I don't think they are that different either and we
>>might not
>> need to differentiate them after all.
>>
>> Flavio
>>
>
>I do have one question - how are teams getting out of
>"team:single-vendor" and towards "team:diverse-affiliation" ?
>
>We have tried to get more people involved with Designate using the ways
>we know how - doing integrations with other projects, pushing designate
>at conferences, helping DNS Server vendors to add drivers, adding
>drivers for DNS Servers and service providers ourselves, adding
>features - the lot.
>
>We have a lot of user interest (41% of users were interested in using
>us), and are quite widely deployed for a non tc-approved-release
>project (17% - 5% in production). We are actually the most deployed
>non tc-approved-release project.
>
>We still have 81% of the reviews done by 2 companies, and 83% by 3
>companies.

By the objective criteria of team:single-vendor Designate isn't a single
vendor project.  By the objective criteria of team:diverse-affiliation
your not a diversely affiliated project either.  This is why I had
suggested we need a third tag which accurately represents where Designate
is in its community building journey.
>
>I know our project is not "cool", and DNS is probably one of the most
>boring topics, but I honestly believe that it has a place in the
>majority of OpenStack clouds - both public and private. We are a small
>team of people dedicated to making Designate the best we can, but are
>still one company deciding to drop OpenStack / DNS development from
>joining the single-vendor party.

Agree Designate is important to OpenStack.  But IMO it is not a single
vendor project as defined by the criteria given the objective statistics
you mentioned above.

>
>We are definitely interested in putting community development ahead of
>development work - but what that actual work is seems to difficult to
>nail down. I do feel sometimes that I am flailing in the dark trying to
>improve this.

Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
struggling is part of the activity.
>
>If projects could share how that got out of single-vendor or into
>diverse-affiliation this could really help teams progress in the
>community, and avoid being removed.

You bring up a fantastic point here - and that is that teams need to share
techniques for becoming multi-vendor and some day diversely affiliated.  I
am a super busy atm, or I would volunteer to lead a cross-project effort
with PTLs to coordinate community building from our shared knowledge pool
of expert Open Source contributors in the wider OpenStack community.

That said, I am passing the baton for Kolla PTL at the conclusion of
Newton (assuming the leadership pipeline I've built for Kolla wants to run
for Kolla PTL), and would be pleased to lead a cross project effort in
Occata on moving from single-vendor to multi-vendor and beyond if there is
enough PTL interest.  I take mentorship seriously and the various single
vendor (and others) PTL's won't be disappointed in such an effort.

>
>Making grand statements about "work harder on community" without any
>guidance about what we need to work on do not help the community.

Agree - lets fix that.  Unfortunately it can't be fixed in an email thread
- it requires a cross-project team based approach with atleast 6 months of
activity.

If PTLs can weigh in on this thread and commit to participation in such a
cross-project subgroup, I'd be happy to lead it.

Regards
-steve


>
>- Graham
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje

Re: [openstack-dev] [tc] persistently single-vendor projects

[Steven Dake (stdake)]

On 8/2/16, 7:17 AM, "Ed Leafe"  wrote:

>On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake)  wrote:
>
>> For example tripleo is single-vendor, but is doing all the right things
>>to
>> dig out of single vendor by doing actual community building.  They
>>aren't
>> just trying, but are trying *very* hard with their activities.  They
>>have
>> the right intent but how to measure intent objectively?  That would be
>>my
>> major concern.
>
>This is exactly the sort of reason why an automatic expulsion is not
>being proposed, but rather a review by humans.
>
>-- Ed Leafe
>
Ed,

Concern answered.  Thanks!

-steve

>
>
>
>
>
>__
>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] persistently single-vendor projects

[Steven Dake (stdake)]

On 8/1/16, 8:38 AM, "Doug Hellmann"  wrote:

>Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +:
>> I am struggling to understand why we would want to remove projects from
>>our big tent at all, as long as they are being actively developed under
>>the principles of "four opens". It seems to me that working to
>>disqualify such projects sends an alarming signal to our ecosystem. The
>>reason we made the big tent to begin with was to set a tone of
>>inclusion. This whole discussion seems like a step backward. What
>>problem are we trying to solve, exactly?
>> 
>> If we want to have tags to signal team diversity, that's fine. We do
>>that now. But setting arbitrary requirements for big tent inclusion
>>based on who participates definitely sounds like a mistake.
>
>Membership in the big tent comes with benefits that have a real
>cost born by the rest of the community. Space at PTG and summit
>forum events is probably the one that's easiest to quantify and to
>point to as something limited that we want to use as productively
>as possible. If 90% of the work of a project is being done by a
>single company or organization (our current definition for
>single-vendor), and that doesn't change after 18 months, then I
>would take that as a signal that the community isn't interested
>enough in the project to bear the associated costs.
>
>I'm interested in hearing other reasons that we should keep these
>sorts of projects, though. I'm not yet ready to propose the change
>to the policy myself.

Doug,

As a community, we need to carefully consider this action.  The costs to
OpenStack are high for single vendor projects but they do add value if
they behave with community in mind.  I don't think removal from Big Tent
is all that big of a deal as long as the projects can still participate in
the openstack namespace and use gerrit/ci and still be part of OpenStack
as you have previously stated.  My biggest concern is some projects are
really trying hard to increase their diversity while others are not trying
so much.  Unfortunately measuring intent objectively is difficult.  I
severely dislike exceptions, but perhaps projects could apply for
exceptions to this policy change if they are actively digging out of
single vendor by their activities.  Forgive me for singling out a single
project, but deployment is where I've spent the last 3 years of my life
and have an intimate understanding of what is happening in these
communities.

For example tripleo is single-vendor, but is doing all the right things to
dig out of single vendor by doing actual community building.  They aren't
just trying, but are trying *very* hard with their activities.  They have
the right intent but how to measure intent objectively?  That would be my
major concern.

There are more single vendor projects then non-single-vendor projects (the
last time I looked which was several months ago) covering many areas, so
tripleo is just one example of many that may be doing the right things to
build more diverse affiliations.

I don't have any insight into the community building going on in various
communities outside of deployment - perhaps some of those teams PTLs could
weigh in on this thread?

All that said the proposal for 18 months is super generous; Nearly any
project can dig out of single vendor in a 18 month window if they
prioritize it.  It would be better for these projects in the long run to
prioritize moving to more diversity for a whole slew of reasons.  In my 20
years of training, team affiliation diversity is _more_ important than
starting from an empty repository and is a best practice.

To fix the problem, perhaps another tag is needed - something between
single-vendor and diverse-affilliation (spitball -
single-vendor-with-diverse-affiliation.  Single-vendor would have an 18
month window associated with it, while the new tag would guarantee big
tent as long as the objective 90%  percentages were maintained.  The only
problem there is that could put OpenStack back on an
incubation/integration track which from my experience with founding Heat
was a serious hurdle for OpenStack in general and Ceilometer and Heat
specifically.

Regards,
-steve
>
>Doug
>
>> 
>> --
>> Adrian
>> 
>> > On Aug 1, 2016, at 5:11 AM, Sean Dague  wrote:
>> > 
>> >> On 07/31/2016 02:29 PM, Doug Hellmann wrote:
>> >> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28
>>+:
>> >>> Kevin,
>> >>> 
>> >>> Just assessing your numbers, the team:diverse-affiliation tag
>>covers what
>> >>> is required to maintain that tag.  It covers more then core
>>reviewers -
>> >>> also covers commits and

Re: [openstack-dev] [kolla] Why base image always be built each time build a specific image.

[Steven Dake (stdake)]

Paul,

I think the cache isn't working exactly as you described for the base
image.  Not sure what is going on there - it could just be my
misperception.  However, as you point out the time spent "rebuilding" the
base image is very small (under 30 seconds) so I don't believe its a
pressing emergency as compared to the sheer amount of outstanding reviews
that need reviews or correcctions.

Zhijiang - to answer one of your questions, there is no way to just build
a container without its dependencies.

Regards
-steve

On 8/2/16, 3:40 AM, "Paul Bourke"  wrote:

>Zhijiang,
>
>You will see lines relating to the base image each time you build,
>however, they should be cached so will add almost no additional time to
>the build.
>
>-Paul
>
>On 21/07/16 09:48, hu.zhiji...@zte.com.cn wrote:
>> Hi,
>>
>> When I use the following command to build keystone image, I saw
>> base/openstack-base image was built for the first time as the
>>dependances,
>> which is OK.
>>
>> kolla-build --registry 127.0.0.1:4000 --push keystone
>>
>> But right after that, when I was building another image (for example
>> rabbitmq), I saw base image was built again. Why that happend and is
>>that
>> necessary? Is there any way to keep the already built images to save
>> building time?
>>
>>
>> Thanks,
>> Zhijiang
>>
>> 
>> ZTE Information Security Notice: The information contained in this mail
>>(and any attachment transmitted herewith) is privileged and confidential
>>and is intended for the exclusive use of the addressee(s).  If you are
>>not an intended recipient, any disclosure, reproduction, distribution or
>>other dissemination or use of the information contained is strictly
>>prohibited.  If you have received this mail in error, please delete it
>>and notify us immediately.
>>
>> 
>>_
>>_
>> 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 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] [docker] [magnum] Magnum account on Docker Hub

[Steven Dake (stdake)]

Ton,

I may or may not have set it up early in Magnum's development.  I just don't 
remember.  My recommendation is to file a support ticket with docker and see if 
they will tell you who it belongs to (as in does it belong to one of the 
founders of Magnum) or if it belongs to some other third party.  Their support 
is very fast.  They may not be able to give you the answer if its not an 
openstacker.

Regards
-steve


From: Ton Ngo mailto:t...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 1, 2016 at 1:06 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub


Hi everyone,
At the last IRC meeting, the team discussed the need for hosting some container 
images on Docker Hub
to facilitate development. There is currently a Magnum account on Docker Hub, 
but this is not owned by anyone
on the team, so we would like to find who the owner is and whether this account 
was set up for OpenStack Magnum.
Thanks in advance!
Ton Ngo,
__
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] persistently single-vendor projects

[Steven Dake (stdake)]

On 7/31/16, 11:29 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +:
>> Kevin,
>> 
>> Just assessing your numbers, the team:diverse-affiliation tag covers
>>what
>> is required to maintain that tag.  It covers more then core reviewers -
>> also covers commits and reviews.
>> 
>> See:
>> 
>>https://github.com/openstack/governance/blob/master/reference/tags/team_d
>>iv
>> erse-affiliation.rst
>> 
>> 
>> I can tell you from founding 3 projects with the
>>team:diverse-affiliation
>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
>> meet.  I don't think its wise to have such strict requirements on single
>> vendor projects as those objectively defined in
>>team:diverse-affiliation.
>> 
>> But Doug's suggestion of timelines could make sense if the timelines
>>gave
>> plenty of time to meet whatever requirements make sense and the
>> requirements led to some increase in diverse affiliation.
>
>To be clear, I'm suggesting that projects with team:single-vendor be
>given enough time to lose that tag. That does not require them to grow
>diverse enough to get team:diverse-affiliation.
>
>Doug
Doug,

That makes sense and doesn't send the wrong message.  I wasn't trying to
suggest that either; was just pointing out Kevin's numbers are more in
line with diverse-affiliation than single vendor.  My personal thoughts
are single vendor projects are ok in OpenStack if they are undertaking
community-building activities to increase their diversity of contributors.

Regards
-steve

>
>> 
>> The 45% core requirement sort of goes against the tag name
>> "single-vendor".
>> 
>> I know of many single vendor projects that would like to have a diverse
>> affiliation, strive for it, and actively promote the integration of new
>> community members into their respective sub-communities.  We don't want
>>to
>> send these folks the wrong message they aren't welcome.
>> 
>> Regards
>> -steve
>> 
>> On 7/31/16, 8:59 AM, "Fox, Kevin M"  wrote:
>> 
>> >This sounds good to me.
>> >
>> >What about making it iterative but with a delayed start. Something
>>like:
>> >
>> >There is a grace period of 1 year for projects that newly join the big
>> >tent. After which, the following criteria will be evaluated to keep a
>> >project in the big tent, evaluated at the end of each OpenStack release
>> >cycle to keep the project for the next cycle. The project should not
>>have
>> >active cores from one company in the amount greater then 45% of the
>> >active core membership. If that number is higher, the project is given
>> >notice they are under diverse and have 6 months of remaining in the big
>> >tent to show they are attempting to increase diversity by shifting the
>> >ratio to a more diverse active core membership. The active core
>> >membership percentage by the over represented company, called X%, will
>>be
>> >shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%).
>>If
>> >the criteria is met, the project can remain in the big tent and a new
>> >cycle will begin. (another notification and 6 months if still out of
>> >compliance)
>> >
>> >This should allow projects that are, or become under diverse a path
>> >towards working on project membership diversity. It gives projects that
>> >are very far out of wack a while to fix it. It basically gives projects
>> >over represented:
>> > * (80%, 100%] -  gets 18 months to fix it
>> > * (60%, 80%] - gets 12 months
>> > * (45%, 60%] - gets 6 months
>> >
>> >Thoughts? The numbers should be fairly easy to change to make for
>> >different amounts of grace period.
>> >
>> >Thanks,
>> >Kevin
>> >
>> >From: Doug Hellmann [d...@doughellmann.com]
>> >Sent: Sunday, July 31, 2016 7:16 AM
>> >To: openstack-dev
>> >Subject: [openstack-dev] [tc] persistently single-vendor projects
>> >
>> >Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>> >Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>> >
>> >Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> >> Doug Hellmann wrote:
>> >> > There is only one way for a repository's contents to be considered
>>

Re: [openstack-dev] [tc] persistently single-vendor projects

[Steven Dake (stdake)]

Kevin,

Just assessing your numbers, the team:diverse-affiliation tag covers what
is required to maintain that tag.  It covers more then core reviewers -
also covers commits and reviews.

See:
https://github.com/openstack/governance/blob/master/reference/tags/team_div
erse-affiliation.rst


I can tell you from founding 3 projects with the team:diverse-affiliation
tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to
meet.  I don't think its wise to have such strict requirements on single
vendor projects as those objectively defined in team:diverse-affiliation.

But Doug's suggestion of timelines could make sense if the timelines gave
plenty of time to meet whatever requirements make sense and the
requirements led to some increase in diverse affiliation.

The 45% core requirement sort of goes against the tag name
"single-vendor". 

I know of many single vendor projects that would like to have a diverse
affiliation, strive for it, and actively promote the integration of new
community members into their respective sub-communities.  We don't want to
send these folks the wrong message they aren't welcome.

Regards
-steve

On 7/31/16, 8:59 AM, "Fox, Kevin M"  wrote:

>This sounds good to me.
>
>What about making it iterative but with a delayed start. Something like:
>
>There is a grace period of 1 year for projects that newly join the big
>tent. After which, the following criteria will be evaluated to keep a
>project in the big tent, evaluated at the end of each OpenStack release
>cycle to keep the project for the next cycle. The project should not have
>active cores from one company in the amount greater then 45% of the
>active core membership. If that number is higher, the project is given
>notice they are under diverse and have 6 months of remaining in the big
>tent to show they are attempting to increase diversity by shifting the
>ratio to a more diverse active core membership. The active core
>membership percentage by the over represented company, called X%, will be
>shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If
>the criteria is met, the project can remain in the big tent and a new
>cycle will begin. (another notification and 6 months if still out of
>compliance)
>
>This should allow projects that are, or become under diverse a path
>towards working on project membership diversity. It gives projects that
>are very far out of wack a while to fix it. It basically gives projects
>over represented:
> * (80%, 100%] -  gets 18 months to fix it
> * (60%, 80%] - gets 12 months
> * (45%, 60%] - gets 6 months
>
>Thoughts? The numbers should be fairly easy to change to make for
>different amounts of grace period.
>
>Thanks,
>Kevin
>
>From: Doug Hellmann [d...@doughellmann.com]
>Sent: Sunday, July 31, 2016 7:16 AM
>To: openstack-dev
>Subject: [openstack-dev] [tc] persistently single-vendor projects
>
>Starting a new thread from "Re: [openstack-dev] [Kolla] [Fuel] [tc]
>Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off"
>
>Excerpts from Thierry Carrez's message of 2016-07-31 11:37:44 +0200:
>> Doug Hellmann wrote:
>> > There is only one way for a repository's contents to be considered
>> > part of the big tent: It needs to be listed in the projects.yaml
>> > file in the openstack/governance repository, associated with a
>> > deliverable from a team that has been accepted as a big tent member.
>> >
>> > The Fuel team has stated that they are not ready to include the
>> > work in these new repositories under governance, and indeed the
>> > repositories are not listed in the set of deliverables for the Fuel
>> > team [1].
>> >
>> > Therefore, the situation is clear, to me: They are not part of the
>> > big tent.
>>
>> Reading this thread after a week off, I'd like to +1 Doug's
>> interpretation since it was referenced to describe the status quo.
>>
>> As others have said, we wouldn't even have that discussion if the new
>> repositories didn't use "fuel" as part of the naming. We probably
>> wouldn't have that discussion either if the Fuel team affiliation was
>> more diverse and the new repositories were an experiment of a specific
>> subgroup of that team.
>>
>> NB: I *do* have some concerns about single-vendor OpenStack projects
>> that don't grow more diverse affiliations over time, but that's a
>> completely separate topic.
>
>I'm starting to think that perhaps we should add some sort of
>expectation of a time-frame for projects that join the big tent as
>single-vendor to attract other contributors.
>
>We removed the requirement that new projects need to have some
>minimal level of diversity when they join because projects asserted
>that they would have a better chance of attracting other contributors
>after becoming official. It might focus the team's efforts on that
>priority if we said that after a year or 18 months without any
>increased diversity, the project would be removed from the big tent.
>
>Doug
>
>_

Re: [openstack-dev] [kolla][stable] Please consider our application for stable:follows-policy for Kolla

[Steven Dake (stdake)]

Hey folks,

I just wanted to let the core team and others in the community know this tag 
application was rejected.  The Kolla core team made a choice when we decided to 
make Liberty non-dangerous.  We knew at the time it would imperil an 
application for stable:follows-policy.  We thought at the time, and I still 
believe we made the right call that having a working Liberty was more important 
then having a tag in the governance repository.

The tag does explain expectations, which we should follow even though our 
application was rejected.  We as a team have already committed to supporting 
Kolla z streams (aka maintenance releases) on a 45 day schedule and to follow 
the stable policy.  Let's continue to stick with that activity, follow 
stable:follows-policy, and do the right thing for Operators and OpenStack.

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, July 23, 2016 at 12:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][stable] Please consider our application for 
stable:follows-policy for Kolla

[Forgot kolla tag]

From: Steven Dake mailto:std...@cisco.com>>
Date: Saturday, July 23, 2016 at 12:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [stable] Please consider our application for stable:follows-policy for 
Kolla

Hey folks,

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Thanks Doug.  I didn't pick up on your choice of Zane's point #1.  If that
is how the rest of the TC feels about it, that wfm.  I will be submitting
a resolution with your wording so clarity is reached and not lost in a
mailing list thread in the future when this issue occurs again.

Regards
-steve


On 7/28/16, 1:13 PM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-28 19:40:29 +:
>> 
>> On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:
>> 
>> >Steven,
>> >
>> >Please see response from Doug:
>> >http://markmail.org/message/yp7fpojnzufb5jki
>> 
>> Dims,
>> 
>> Are you implying Doug's position represents that of the TC?
>> 
>> I have read Doug's position, and it completely ignores Zane's assessment
>> of the problem at hand.
>
>I did not ignore his assessment. If I was not clear, I am saying
>that his interpretation #1 is the correct interpretation, that
>members of official teams can contribute to repositories that are
>not under governance.
>
>If you disagree with my conclusion or think further action is needed,
>then I suggest you formally propose something be added to the TC
>agenda. I consider this resolved, but it is well within your rights
>as a community member to propose topics for discussion yourself and
>I whole-heartedly encourage you to exercise those rights if you
>think you are not being heard and that the full TC needs to be
>involved to take more formal action.
>
>To add an agenda item, all you have to do is edit the wiki page [1]
>but please note there are some stipulations about timing at the
>bottom of the page, so read those first to ensure that your
>expectations are set correctly. If you have any known schedule
>conflicts, include that information so we can be sure to schedule
>the discussion for a week when you can be present to participate.
>
>Doug
>
>[1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
>
>> 
>> Clarity has not been reached.  I could restate the problem for you if
>>you
>> like.
>> 
>> >
>> >If anyone disagrees with that position, please file a resolution.
>> >
>> >Let's stop this thread now please.
>> 
>> 
>> Asking for a thread to be stopped before a resolution is reached is not
>> the right thing.
>> 
>> Regards
>> -steve
>> 
>> >
>> >Thanks,
>> >Dims
>> >
>> >On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake)
>>
>> >wrote:
>> >> Dims,
>> >>
>> >> I personally think its the responsibility of the TC to resolve this
>> >> problem via a resolution.  That’s why we elected you folks :)
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >>
>> >> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>> >>
>> >>>Zane, Steve,
>> >>>
>> >>>I'd say go for it! Can you please write up a proposal for the TC to
>> >>>consider? 
>> >>>(https://review.openstack.org/#/q/project:openstack/governance)
>> >>>
>> >>>Thanks,
>> >>>-- Dims
>> >>>
>> >>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake)
>>
>> >>>wrote:
>> >>>> Jay,
>> >>>>
>> >>>> I'll be frank.  I have been receiving numerous complaints which
>>mirror
>> >>>> Zane's full second understanding of what it means to be an
>>OpenStack
>> >>>>big
>> >>>> tent project.  These are not just Kolla developers.  These are
>>people
>> >>>>from
>> >>>> all over the community.  They want something done about it.  I
>>agree
>> >>>>with
>> >>>> Zane if clarity is provided by the TC via a resolution, the problem
>> >>>>would
>> >>>> disappear.  We are all adults and can live by the rules, even if we
>> >>>> disagree with them.  This contract is the agreement under which
>> >>>> democracies are created, and one of the most appealing properties
>>of
>> >>>> OpenStack.
>> >>>>
>> >>>> In this case there is no policy and one is obviously necessary to
>> >>>>avoid
>> >>>> these scenarios in the future.
>> >>>>
>> >>>> The TC has four options as I see it:
>> >>>

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:

>Steven,
>
>Please see response from Doug:
>http://markmail.org/message/yp7fpojnzufb5jki

Dims,

Are you implying Doug's position represents that of the TC?

I have read Doug's position, and it completely ignores Zane's assessment
of the problem at hand.

Clarity has not been reached.  I could restate the problem for you if you
like.

>
>If anyone disagrees with that position, please file a resolution.
>
>Let's stop this thread now please.


Asking for a thread to be stopped before a resolution is reached is not
the right thing.

Regards
-steve

>
>Thanks,
>Dims
>
>On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
>wrote:
>> Dims,
>>
>> I personally think its the responsibility of the TC to resolve this
>> problem via a resolution.  That’s why we elected you folks :)
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>>
>>>Zane, Steve,
>>>
>>>I'd say go for it! Can you please write up a proposal for the TC to
>>>consider? 
>>>(https://review.openstack.org/#/q/project:openstack/governance)
>>>
>>>Thanks,
>>>-- Dims
>>>
>>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>>>wrote:
>>>> Jay,
>>>>
>>>> I'll be frank.  I have been receiving numerous complaints which mirror
>>>> Zane's full second understanding of what it means to be an OpenStack
>>>>big
>>>> tent project.  These are not just Kolla developers.  These are people
>>>>from
>>>> all over the community.  They want something done about it.  I agree
>>>>with
>>>> Zane if clarity is provided by the TC via a resolution, the problem
>>>>would
>>>> disappear.  We are all adults and can live by the rules, even if we
>>>> disagree with them.  This contract is the agreement under which
>>>> democracies are created, and one of the most appealing properties of
>>>> OpenStack.
>>>>
>>>> In this case there is no policy and one is obviously necessary to
>>>>avoid
>>>> these scenarios in the future.
>>>>
>>>> The TC has four options as I see it:
>>>> 1) do nothing
>>>> 2) write a resolution mirroring Zane's first analysis
>>>> 3) write a resolution mirroring Zane's second analysis
>>>> 4) write a different resolution that is a compromise of the first
>>>>analysis
>>>> and second analysis
>>>>
>>>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>>>> Vladimir!).
>>>>
>>>> Regards
>>>> -steve
>>>>
>>>>
>>>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>>>
>>>>>I don't see what is unclear about any of it.
>>>>>
>>>>>What exactly is it that you wish Mirantis to state?
>>>>>
>>>>>Zane says there needs to be some guidance from the TC "about what it
>>>>>means for a repo to be part of the OpenStack tent".
>>>>>
>>>>>But the fuel-ccp repos aren't listed in the governance repo, for
>>>>>reasons
>>>>>that were clearly stated by Mirantis engineers. They want to innovate
>>>>>in
>>>>>this area without all the politics that this thread exposes.
>>>>>
>>>>>Mirantis engineers have clearly laid out the technical reasons that
>>>>>Kolla doesn't fit the needs that Fuel has of these image definitions
>>>>>and
>>>>>orchestration tooling.
>>>>>
>>>>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>>>>guidance about what it means for a repo to be part of the OpenStack
>>>>>tent
>>>>>be useful here?
>>>>>
>>>>>-jay
>>>>>
>>>>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>>>>>> Jay,
>>>>>>
>>>>>> That resolution doesn't clarify Zane's argument.
>>>>>>
>>>>>> Regards,
>>>>>> -steve
>>>>>>
>>>>>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>>>>>
>>>>>>> The TC has given guidance on this already:
>>>>>>&g

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Dims,

I personally think its the responsibility of the TC to resolve this
problem via a resolution.  That’s why we elected you folks :)

Regards
-steve


On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:

>Zane, Steve,
>
>I'd say go for it! Can you please write up a proposal for the TC to
>consider? (https://review.openstack.org/#/q/project:openstack/governance)
>
>Thanks,
>-- Dims
>
>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>wrote:
>> Jay,
>>
>> I'll be frank.  I have been receiving numerous complaints which mirror
>> Zane's full second understanding of what it means to be an OpenStack big
>> tent project.  These are not just Kolla developers.  These are people
>>from
>> all over the community.  They want something done about it.  I agree
>>with
>> Zane if clarity is provided by the TC via a resolution, the problem
>>would
>> disappear.  We are all adults and can live by the rules, even if we
>> disagree with them.  This contract is the agreement under which
>> democracies are created, and one of the most appealing properties of
>> OpenStack.
>>
>> In this case there is no policy and one is obviously necessary to avoid
>> these scenarios in the future.
>>
>> The TC has four options as I see it:
>> 1) do nothing
>> 2) write a resolution mirroring Zane's first analysis
>> 3) write a resolution mirroring Zane's second analysis
>> 4) write a different resolution that is a compromise of the first
>>analysis
>> and second analysis
>>
>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>> Vladimir!).
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>
>>>I don't see what is unclear about any of it.
>>>
>>>What exactly is it that you wish Mirantis to state?
>>>
>>>Zane says there needs to be some guidance from the TC "about what it
>>>means for a repo to be part of the OpenStack tent".
>>>
>>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>>>that were clearly stated by Mirantis engineers. They want to innovate in
>>>this area without all the politics that this thread exposes.
>>>
>>>Mirantis engineers have clearly laid out the technical reasons that
>>>Kolla doesn't fit the needs that Fuel has of these image definitions and
>>>orchestration tooling.
>>>
>>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>>guidance about what it means for a repo to be part of the OpenStack tent
>>>be useful here?
>>>
>>>-jay
>>>
>>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>>>> Jay,
>>>>
>>>> That resolution doesn't clarify Zane's argument.
>>>>
>>>> Regards,
>>>> -steve
>>>>
>>>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>>>
>>>>> The TC has given guidance on this already:
>>>>>
>>>>>
>>>>>http://governance.openstack.org/resolutions/20160119-stackforge-retire
>>>>>me
>>>>>nt
>>>>> .html
>>>>>
>>>>> "In order to simplify software development lifecycle transitions of
>>>>> Unofficial and Official OpenStack projects, all projects developed
>>>>> within the OpenStack project infrastructure will be permitted to use
>>>>>the
>>>>> “openstack/” namespace. The use of the term “Stackforge” to describe
>>>>> unofficial projects should be considered deprecated."
>>>>>
>>>>> The Fuel CCP repos are projects that are not official OpenStack
>>>>>projects.
>>>>>
>>>>> They are in the openstack/ git namespace because they use the common
>>>>> infrastructure and there isn't any formal plan to have the repos join
>>>>> the "official OpenStack projects" (i.e. the ones listed in the
>>>>> projects.yaml file in the openstack/governance repository).
>>>>>
>>>>> Could they be proposed in the future as official OpenStack projects?
>>>>> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>>>>>of
>>>>> time.
>>>>>
>>>>> Please stop using a marketing press release as some indication of
>>>>>what
>>>>>

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Jay,

I'll be frank.  I have been receiving numerous complaints which mirror
Zane's full second understanding of what it means to be an OpenStack big
tent project.  These are not just Kolla developers.  These are people from
all over the community.  They want something done about it.  I agree with
Zane if clarity is provided by the TC via a resolution, the problem would
disappear.  We are all adults and can live by the rules, even if we
disagree with them.  This contract is the agreement under which
democracies are created, and one of the most appealing properties of
OpenStack.

In this case there is no policy and one is obviously necessary to avoid
these scenarios in the future.

The TC has four options as I see it:
1) do nothing
2) write a resolution mirroring Zane's first analysis
3) write a resolution mirroring Zane's second analysis
4) write a different resolution that is a compromise of the first analysis
and second analysis

I don't wish Mirantis to state anything.  Vladimir did that (thanks
Vladimir!).

Regards
-steve


On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:

>I don't see what is unclear about any of it.
>
>What exactly is it that you wish Mirantis to state?
>
>Zane says there needs to be some guidance from the TC "about what it
>means for a repo to be part of the OpenStack tent".
>
>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>that were clearly stated by Mirantis engineers. They want to innovate in
>this area without all the politics that this thread exposes.
>
>Mirantis engineers have clearly laid out the technical reasons that
>Kolla doesn't fit the needs that Fuel has of these image definitions and
>orchestration tooling.
>
>The repos *aren't in the OpenStack tent* so how precisely would TC
>guidance about what it means for a repo to be part of the OpenStack tent
>be useful here?
>
>-jay
>
>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>> Jay,
>>
>> That resolution doesn't clarify Zane's argument.
>>
>> Regards,
>> -steve
>>
>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>
>>> The TC has given guidance on this already:
>>>
>>> 
>>>http://governance.openstack.org/resolutions/20160119-stackforge-retireme
>>>nt
>>> .html
>>>
>>> "In order to simplify software development lifecycle transitions of
>>> Unofficial and Official OpenStack projects, all projects developed
>>> within the OpenStack project infrastructure will be permitted to use
>>>the
>>> “openstack/” namespace. The use of the term “Stackforge” to describe
>>> unofficial projects should be considered deprecated."
>>>
>>> The Fuel CCP repos are projects that are not official OpenStack
>>>projects.
>>>
>>> They are in the openstack/ git namespace because they use the common
>>> infrastructure and there isn't any formal plan to have the repos join
>>> the "official OpenStack projects" (i.e. the ones listed in the
>>> projects.yaml file in the openstack/governance repository).
>>>
>>> Could they be proposed in the future as official OpenStack projects?
>>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>>> time.
>>>
>>> Please stop using a marketing press release as some indication of what
>>> the "intent" is for these repos or even that there *is* any intent at
>>> this point. It's really early on and these repos are intended as a
>>>place
>>> to experiment and innovate. I don't see why there is so much anger
>>>about
>>> that.
>>>
>>> Best,
>>> -jay
>>>
>>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>>>> Doug,
>>>>
>>>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>>>> clarification can solve this situation.
>>>>
>>>> Regards
>>>> -steve
>>>>
>>>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>>>
>>>>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>>>>>> Fuel-ccp repositories are public, everyone is welcome to
>>>>>>participate.
>>>>>> I
>>>>>> don¹t see where we violate ³4 opens². These repos are now
>>>>>> experimental.
>>>>>> At the moment the team is working on building CI pipeline and
>>>>>> developing
>>>>>> functional tests that are to be run as a part of CI p

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Jay,

That resolution doesn't clarify Zane's argument.

Regards,
-steve

On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:

>The TC has given guidance on this already:
>
>http://governance.openstack.org/resolutions/20160119-stackforge-retirement
>.html
>
>"In order to simplify software development lifecycle transitions of
>Unofficial and Official OpenStack projects, all projects developed
>within the OpenStack project infrastructure will be permitted to use the
>“openstack/” namespace. The use of the term “Stackforge” to describe
>unofficial projects should be considered deprecated."
>
>The Fuel CCP repos are projects that are not official OpenStack projects.
>
>They are in the openstack/ git namespace because they use the common
>infrastructure and there isn't any formal plan to have the repos join
>the "official OpenStack projects" (i.e. the ones listed in the
>projects.yaml file in the openstack/governance repository).
>
>Could they be proposed in the future as official OpenStack projects?
>Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>time.
>
>Please stop using a marketing press release as some indication of what
>the "intent" is for these repos or even that there *is* any intent at
>this point. It's really early on and these repos are intended as a place
>to experiment and innovate. I don't see why there is so much anger about
>that.
>
>Best,
>-jay
>
>On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>> Doug,
>>
>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>> clarification can solve this situation.
>>
>> Regards
>> -steve
>>
>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>
>>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>>>> Fuel-ccp repositories are public, everyone is welcome to participate.
>>>>I
>>>> don¹t see where we violate ³4 opens². These repos are now
>>>>experimental.
>>>> At the moment the team is working on building CI pipeline and
>>>>developing
>>>> functional tests that are to be run as a part of CI process. These
>>>>repos
>>>> are not to be a part of Fuel Newton release. From time to time we add
>>>> and retire git repos and it is a part of development process. Not all
>>>> these repos are to become a part of Big tent.
>>>
>>> It seems to me that there are two different interpretations of what it
>>> means for a repo to be part of the OpenStack tent, and that these
>>> differing interpretations are at the root of the arguments in this
>>>thread.
>>>
>>> The first interpretation is that repos listed as belonging to a team in
>>> the governance repo are part of a deliverable that is released each
>>> development cycle, and that the same team may also control other repos
>>> that are not deliverables and hence not part of OpenStack. It's easy to
>>> see how people could have developed this interpretation in good faith.
>>>
>>> The second interpretation is that the TC blesses a team; that the only
>>> criterion for receiving this blessing is for the project to be "one of
>>> us", which in practice effectively means following the Four Opens; and
>>> that all repos which the team intends to operate in this manner,
>>>subject
>>> to TC oversight, should be listed in the governance repo. It's also
>>>easy
>>> to see how people could have developed this interpretation in good
>>> faith. (In fact, I was following the big tent discussions very closely
>>> at the time and this was always my understanding of what it meant.)
>>>
>>> The only additional thing needed to explain this thread is the
>>> (incorrect) assumption on behalf of all participants that everyone has
>>> the same interpretation :)
>>>
>>> Assuming everyone holds the first interpretation, the current
>>> designation of the fuel-ccp repo looks completely logical and the
>>> complaints about it look like sour grapes.
>>>
>>> Assuming everyone holds the second interpretation, the current
>>> designation of the fuel-ccp repo looks like an attempt to avoid TC
>>> oversight in order to violate the Four Opens while using the name of an
>>> official project (and issuing press releases identifying it as part of
>>> said official project), and the complaints look like a logical attempt
>>> to defend OpenStack from at least the appearance of openwashing.
>>&

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:

>On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>> Fuel-ccp repositories are public, everyone is welcome to participate. I
>> don¹t see where we violate ³4 opens². These repos are now experimental.
>> At the moment the team is working on building CI pipeline and developing
>> functional tests that are to be run as a part of CI process. These repos
>> are not to be a part of Fuel Newton release. From time to time we add
>> and retire git repos and it is a part of development process. Not all
>> these repos are to become a part of Big tent.
>
>It seems to me that there are two different interpretations of what it
>means for a repo to be part of the OpenStack tent, and that these
>differing interpretations are at the root of the arguments in this thread.
>
>The first interpretation is that repos listed as belonging to a team in
>the governance repo are part of a deliverable that is released each
>development cycle, and that the same team may also control other repos
>that are not deliverables and hence not part of OpenStack. It's easy to
>see how people could have developed this interpretation in good faith.
>
>The second interpretation is that the TC blesses a team; that the only
>criterion for receiving this blessing is for the project to be "one of
>us", which in practice effectively means following the Four Opens; and
>that all repos which the team intends to operate in this manner, subject
>to TC oversight, should be listed in the governance repo. It's also easy
>to see how people could have developed this interpretation in good
>faith. (In fact, I was following the big tent discussions very closely
>at the time and this was always my understanding of what it meant.)
>
>The only additional thing needed to explain this thread is the
>(incorrect) assumption on behalf of all participants that everyone has
>the same interpretation :)
>
>Assuming everyone holds the first interpretation, the current
>designation of the fuel-ccp repo looks completely logical and the
>complaints about it look like sour grapes.
>
>Assuming everyone holds the second interpretation, the current
>designation of the fuel-ccp repo looks like an attempt to avoid TC
>oversight in order to violate the Four Opens while using the name of an
>official project (and issuing press releases identifying it as part of
>said official project), and the complaints look like a logical attempt
>to defend OpenStack from at least the appearance of openwashing.
>
>I believe this entire controversy will evaporate if the TC can clarify
>what it means for a repository to be listed in the governance repo.
>
>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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Thanks for the clarity Doug.

Regards
-steve

On 7/28/16, 8:37 AM, "Doug Hellmann"  wrote:

>Excerpts from Flavio Percoco's message of 2016-07-28 16:43:35 +0200:
>> On 28/07/16 04:45 +0000, Steven Dake (stdake) wrote:
>> >
>> >
>> >On 7/27/16, 2:12 PM, "Jay Pipes"  wrote:
>> >
>> >>On 07/27/2016 04:42 PM, Ed Leafe wrote:
>> >>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M 
>>wrote:
>> >>>
>> >>>> Its not an "end user" facing thing, but it is an "operator" facing
>> >>>>thing.
>> >>>
>> >>> Well, the end user for Kolla is an operator, no?
>> >>>
>> >>>> I deploy kolla containers today on non kolla managed systems in
>> >>>>production, and rely on that api being consistent.
>> >>>>
>> >>>> I'm positive I'm not the only operator doing this either. This
>>sounds
>> >>>>like a consumable api to me.
>> >>>
>> >>> I don¹t think that an API has to be RESTful to be considered an
>> >>>interface for we should avoid duplication.
>> >>
>> >>Application *Programming* Interface. There's nothing that is being
>> >>*programmed* or *called* in Kolla's image definitions.
>> >>
>> >>What Kolla is/has is not an API. As Stephen said, it's more of an
>> >>Application Binary Interface (ABI). It's not really an ABI, though, in
>> >>the traditional sense of the term that I'm used to.
>> >>
>> >>It's an agreed set of package bases, installation
>>procedures/directories
>> >>and configuration recipes for OpenStack and infrastructure components.
>> >
>> >Jay,
>> >
>> >From my perspective, this isn't about ABI proliferation or competition.
>> >This is about open public discourse.
>> >
>> >It is the responsibility of all community members to protect the four
>> >opens.
>> >
>> >Given the intent of fuel-ccp to fully adopt K8S into Fuel described
>>here:
>> 
>>>https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-
>>>top
>> >-of-kubernetes/
>> >
>> >
>> >It is hard to understand the arguments in the reviews related to "this
>>is
>> >an experimental project, so its not targeted towards big tent" yet
>>Boris
>> >wrote in that press release its Fuel's next big thing.
>> >
>> >I raised the objection early on that a mission statement change was
>>needed
>> >by Fuel if they wanted to proceed down this path, to which I was told
>>K8S
>> >support is not going into big tent.
>> >
>> >As a result of Mirantis's change in mind about fuel-ccp being NOT
>> >experimental and being targeted for big tent, I'd like the record set
>> >straight in the governance repository since the intentions are being
>> >published in the press and the current intentions of this project are
>> >public.
>> 
>> If I can be honest, I think this whole thread is not going anywhere
>>because it
>> just started based on the wrong assumption, the wrong tone and with poor
>> wording. I'd have asked for clarifications before demanding changes
>>from anyone.
>> To me, the way this thread started violates one of principles of our
>>community,
>> which is assuming good faith. I'll assume good faith now and interpret
>>this
>> thread as a hope to clarify the goals and intentions of this projects
>>and not as
>> a way to bluntly point fingers, which is how some people might have
>>perceived
>> it.
>
>+1
>
>I'm not sure how/why this escalated so quickly. It seems there's some
>history between these teams, though. If Kevin's summary of the issues on
>the universal containers spec is correct, it seems like there's room for
>compromise. That said, I agree with Russell and Flavio that there's also
>plenty of room for different implementations in the deployment space,
>whether are part of the big tent or not.
>
>> 
>> >I could see how people could perceive many violations of the four
>>opens in
>> >all of the activities related to the fuel-ccp project.  We as a
>>community
>> >value open discourse because we are all intelligent human beings.  We
>> >value honesty and integrity because trust is the foundation of how our
>> >community

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

On 7/27/16, 2:12 PM, "Jay Pipes"  wrote:

>On 07/27/2016 04:42 PM, Ed Leafe wrote:
>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:
>>
>>> Its not an "end user" facing thing, but it is an "operator" facing
>>>thing.
>>
>> Well, the end user for Kolla is an operator, no?
>>
>>> I deploy kolla containers today on non kolla managed systems in
>>>production, and rely on that api being consistent.
>>>
>>> I'm positive I'm not the only operator doing this either. This sounds
>>>like a consumable api to me.
>>
>> I don¹t think that an API has to be RESTful to be considered an
>>interface for we should avoid duplication.
>
>Application *Programming* Interface. There's nothing that is being
>*programmed* or *called* in Kolla's image definitions.
>
>What Kolla is/has is not an API. As Stephen said, it's more of an
>Application Binary Interface (ABI). It's not really an ABI, though, in
>the traditional sense of the term that I'm used to.
>
>It's an agreed set of package bases, installation procedures/directories
>and configuration recipes for OpenStack and infrastructure components.

Jay,

>From my perspective, this isn't about ABI proliferation or competition.
This is about open public discourse.

It is the responsibility of all community members to protect the four
opens.

Given the intent of fuel-ccp to fully adopt K8S into Fuel described here:
https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
-of-kubernetes/


It is hard to understand the arguments in the reviews related to "this is
an experimental project, so its not targeted towards big tent" yet Boris
wrote in that press release its Fuel's next big thing.

I raised the objection early on that a mission statement change was needed
by Fuel if they wanted to proceed down this path, to which I was told K8S
support is not going into big tent.

As a result of Mirantis's change in mind about fuel-ccp being NOT
experimental and being targeted for big tent, I'd like the record set
straight in the governance repository since the intentions are being
published in the press and the current intentions of this project are
public.

I could see how people could perceive many violations of the four opens in
all of the activities related to the fuel-ccp project.  We as a community
value open discourse because we are all intelligent human beings.  We
value honesty and integrity because trust is the foundation of how our
community operates.  I feel the best way for Fuel to repair the perceived
violations of the four opens going forward is to:

1. Alter the mission statement of fuel to match the reality being
published by the press and Mirantis's executive team
2. Include these non-experimental repos in the projects.yaml governance
repository

That would satisfy my four opens concerns.

If the Fuel PTL doesn't want to do these two things, I'd like a public
explanation as to why from Vladimir who thus far has remained quiet on
this thread.

Thanks
-steve




>
>I see no reason for the OpenStack community to standardize on those
>things, frankly. It's like asking RedHat and Canonical to agree to "just
>use RPM" as their package specification format. I wonder how that
>conversation would go.
>
>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


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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

One correction inside:

On 7/27/16, 12:02 PM, "Jay Pipes"  wrote:

>On 07/27/2016 01:59 PM, Fox, Kevin M wrote:
>> Kolla is providing a public api for docker containers and kubernetes
>>templates though. So its not just a deployment tool issue. Its not
>>specifically rest, but does that matter?
>
>Yes, it matters.
>
>Kolla isn't providing a user-interfacing HTTP API for doing something in
>a cloud. Kolla is providing a prescriptive way of building Docker images
>from a set of Dockerfiles and various configuration file templates. That
>isn't a consumable API. That's a reference manual.
>
>Best,
>-jay

Not that I think this discussion is all that productive but it should be
based on facts.  Kolla container images do provide a standardized
consumable ABI and we have claimed such for over two cycles.

Regards
-steve

>
>> 
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Wednesday, July 27, 2016 10:36 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is
>>getting Fuel CCP (docker/k8s) kicked off
>>
>> On 07/27/2016 10:10 AM, Chris Friesen wrote:
>>> On 07/27/2016 09:59 AM, Ed Leafe wrote:
 On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
 wrote:

>> Whether to have competing projects in the big tent was debated by
>> the TC
>> at the time and my recollection is that we decided that was a good
>> thing
>> -- if someone wanted to develop a Nova replacement, then let them
>>do it
>> in public with the community. It would either win or lose based on
>>its
>> merits. Why is this not something which can happen here as well?
>
> For real, I (or someone) can start a nova replacement without getting
> rejected (or yelled at or ...) by the TC saying it's a competing
> project??? Wow, this is news to me...

 No, you can¹t start a Nova replacement and still call yourself
OpenStack.

 The sense I have gotten over the years from the TC is that gratuitous
 competition is strongly discouraged.
>>>
>>> I seem to recall that back during the "big tent" discussion people were
>>> talking about allowing competing projects that performed the same task,
>>> and letting natural selection decide which one survived.
>>>
>>> For example, at
>>> 
>>>"http://www.joinfu.com/2014/09/answering-the-existential-question-in-ope
>>>nstack/"
>>> Jay Pipes said that being under the big tent should not mean that the
>>> project is the only/best way to provide a specific function to
>>>OpenStack
>>> users.
>>>
>>> On the other hand, the OpenStack new projects requirements *do*
>>> explicitly state that "Where it makes sense, the project cooperates
>>>with
>>> existing projects rather than gratuitously competing or reinventing the
>>> wheel."
>>>
>>> Maybe it boils down to the definition of "gratuitous" competition.
>>
>> For the record I think I've always been clear that I don't see
>> competition as a bad thing within the OpenStack ecosystem however I have
>> always been a proponent of having a *single consistent REST API* for a
>> particular service type. I think innovation should happen at the
>> implementation layer, but the public HTTP APIs should be collated and
>> reviewed for overlap and inconsistencies.
>>
>> This was why in the past I haven't raised a stink about multiple
>> deployment tools, since there was no OpenStack HTTP API for deployment
>> of OpenStack itself. But I have absolutely raised concerns over overlap
>> of HTTP APIs, like is the case with Monasca and various Telemetry
>> project APIs. Again, implementation diversity cool. Public HTTP API
>> diversity, not cool.
>>
>> 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
>>
>> 
>>_
>>_
>> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] repo split

[Steven Dake (stdake)]

Martin,

Thanks for your feedback.  This vote has expired without a consensus.  I
think we need to try a new vote once the core team gets comfortable with
the backporting process I spoke about earlier in a different thread this
vote would likely pass.

Regards
-steve

On 7/27/16, 3:09 AM, "Martin André"  wrote:

>On Thu, Jul 21, 2016 at 5:21 PM, Steven Dake (stdake) 
>wrote:
>> I am voting -1 for now, but would likely change my vote after we branch
>> Newton.  I'm not a super big fan of votes way ahead of major events
>>(such
>> as branching) because a bunch of things could change between now and
>>then
>> and the vote would be binding.
>>
>> Still community called the vote - so vote stands :)
>
>IIUC, if split there is, it's scheduled for when we branch out Newton
>which is only 1 month ahead.
>
>I'm +1 on splitting ansible deployment code into kolla-ansible.
>
>Martin
>
>> Regards
>> -steve
>>
>>
>> On 7/20/16, 1:48 PM, "Ryan Hallisey"  wrote:
>>
>>>Hello.
>>>
>>>The repo split discussion that started at summit was brought up again at
>>>the midcycle.
>>>The discussion was focused around splitting the Docker containers and
>>>Ansible code into
>>>two separate repos [1].
>>>
>>>One of the main opponents to the split is backports.  Backports will
>>>need
>>>to be done
>>>by hand for a few releases.  So far, there hasn't been a ton of
>>>backports, but that could
>>>always change.
>>>
>>>As for splitting, it provides a much clearer view of what pieces of the
>>>project are where.
>>>Kolla-ansible with its own repo will sit along side kolla-kubernetes as
>>>consumers of the
>>>kolla repo.
>>>
>>>The target for the split will be for day 1 of Occata. The core team will
>>>vote on
>>>the change of splitting kolla into kolla-ansible and kolla.
>>>
>>>Cores please respond with a +1/-1 to approve or disapprove the repo
>>>split. Any community
>>>member feel free to weigh in with your opinion.
>>>
>>>+1
>>>-Ryan
>>>
>>>[1] - https://etherpad.openstack.org/p/kolla-N-midcycle-repo-split
>>>
>>>
>>>__
>>>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 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Michael,

Response inline.

From: Michael Still mailto:mi...@stillhq.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, July 27, 2016 at 5:30 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On Tue, Jul 26, 2016 at 4:44 PM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:

[snip]

The issue is, as I see it, a parallel activity to one of the that is currently 
accepted into the Big Tent, aka Containerized Deployment

[snip]

This seems to be the crux of the matter as best as I can tell. Is it true to 
say that the concern is that Kolla believes they "own" the containerized 
deployment space inside the Big Tent?

I can't give you Kevin's thinking on this, but my thinking is that every 
project has a right to innovate even if it means competing with an established 
project.  Even if that competition involves a straight up fork or serious copy 
and paste from the competitive project.These are permitted things in big 
tent.  Kolla has been forked a few times with people seeding competitive 
projects.  The license permits this, and fwiw I don't see any problem with it.  
There is nothing more appealing to an engineer then forking a code base for 
whatever reason.  Hence I disagree about your assertion that competition is the 
crux of the matter.

It is easier to copy a successful design then to innovate your own the hard way.

I have already stated where the problem is, and I'll state it once again using 
C&P:

"
Given the strong language around partnership between Intel, Mirantis, and
Google in that press release, and the activity in the review queue (2
pages of outstanding reviews) it seems clear to me that the intent is for
this part of Fuel to participate in the big tent.  The right thing to do
here is for fuel-ccp to submit their repos to TC oversight by adding them
to the official project list.

Fuel requires a mission change, or it may be perceived that Fuel itself
does not adhere to the Four Opens [1] specifically Open Development and
Open Community.
"

[snip]


Michael




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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Jim,

Thinking like Kevin's below are the reason I asked for the two requested
changes.  He isn't the only person to think along these lines.  His
argument is coherent and logical and if you analyze his response he
indicates his perception is the four opens are not being followed by Fuel.

It is the responsibility of every OpenStack community member to protect
the four opens.  The four opens are the founding of OpenStack's
fundamental tenants.  Even if the reality is Fuel is participating in the
OpenStack community using the four opens, people may not perceive it as
such based upon the many reviews linked in this thread.

As can be seen by Kevin's email, perception matters.

Clearly Mirantis is committed to this effort with two pages of Mirantis
reviews outstanding.

What precisely is the harm in acknowledging the _truth_ directly in the
governance repo?

Regards
-steve

On 7/26/16, 4:44 PM, "Fox, Kevin M"  wrote:

>Hi Jim,
>
>The issue is, as I see it, a parallel activity to one of the that is
>currently accepted into the Big Tent, aka Containerized Deployment:
>Kolla's mission:
>To provide production-ready containers and deployment tools for operating
>OpenStack clouds.
>
>Fuel's mission:
>To streamline and accelerate the process of deploying, testing and
>maintaining various configurations of OpenStack at scale.
>
>To me, this totally lets both projects work together, fuel providing the
>bare metal provisioning/kubernetes provisioning, the k8s orchestration to
>manage pods/deployments/etc, its awesome ui, etc, and using
>kolla-kubernetes/kolla for the container bits/k8s templates. Otherwise
>there's a quite a bit duplication of work. This feels in line with fuel
>trying to reimplement another core openstack project (say, nova)
>
>When fuel-ccp was proposed, it was proposed as more of a proof of concept
>and not a big tent thing: https://review.openstack.org/#/c/331139/
>
>If you look at contributions to each of kolla-kubernetes its a fairly
>diverse set of contributors:
>http://stackalytics.com/?module=kolla-kubernetes
>fuel-ccp doesn't show up in stackalytics but if you check the commit log
>its very heavily dominated by one company. That's not really open
>development.
>
>The kolla-kubernetes project was having discussions about how to work
>with the Fuel team to ensure that their needs were met, when they
>suddenly stopped talking and spawned a new project. This doesn't feel
>like working with the community. Our differences didn't feel unsolvable
>to the point of spawning a new, competing project.
>
>Now its being advertised very openly. This feels like it was snuck in the
>back door, behind the communities back then pushed hard.
>
>OpenStack is already distressingly fractured already. Can we try and work
>together rather then keep making an already pretty bad situation worse?
>Are the technical differences really that far apart to prevent it?
>
>Does that help to clarify the concern?
>
>Thanks,
>Kevin
>
>
>
>
>
>
>From: Jim Rollenhagen [j...@jimrollenhagen.com]
>Sent: Tuesday, July 26, 2016 3:28 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is
>getting Fuel CCP (docker/k8s) kicked off
>
>On Tue, Jul 26, 2016 at 09:42:10PM +, Steven Dake (stdake) wrote:
>>
>>
>> On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:
>>
>> >On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
>> >> Dims,
>> >>
>> >> The project-config addition was debated by Andreas before this
>> >>partnership
>> >> in this press release was announced and the full intent of the
>>project
>> >>was
>> >> understood.  The argument I see used in the review  is that since
>> >>fuel-ccp
>> >> not part of Newton, it doesn't need to be in the projects.yaml file.
>> >> Given the intent of the project is obvious (to me) from the press
>> >>release
>> >> to join the big tent, my two requests still apply.  At present this
>> >> project may be perceived as "flying under the radar" and further not
>> >> following the four opens as I already stated.
>> >
>> >I'm confused, what specifically is happening that is against the four
>> >opens? What part of the press release implies big tent in the future?
>>
>> My exact words were proceeded by "may be perceived"
>
>Okay, I'm still confused what part of it may be perceived as not
>following the four opens.
>
>>

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

On 7/26/16, 2:13 PM, "Jim Rollenhagen"  wrote:

>On Tue, Jul 26, 2016 at 08:36:01PM +, Steven Dake (stdake) wrote:
>> Dims,
>> 
>> The project-config addition was debated by Andreas before this
>>partnership
>> in this press release was announced and the full intent of the project
>>was
>> understood.  The argument I see used in the review  is that since
>>fuel-ccp
>> not part of Newton, it doesn't need to be in the projects.yaml file.
>> Given the intent of the project is obvious (to me) from the press
>>release
>> to join the big tent, my two requests still apply.  At present this
>> project may be perceived as "flying under the radar" and further not
>> following the four opens as I already stated.
>
>I'm confused, what specifically is happening that is against the four
>opens? What part of the press release implies big tent in the future?

My exact words were proceeded by "may be perceived"

The press release itself implies a big effort with big contributors hence
big tent.

>
>> 
>> The two requests were:
>> 
>> 1. Please submit the repositories for projects.yaml TC oversight
>> 2. Please change Fuel's mission statement to match reality of this
>> announcement 
>
>Why? The current mission statement is "To streamline and accelerate the
>process of deploying, testing and maintaining various configurations of
>OpenStack at scale." I don't see why anything about this announcement
>doesn't fit into that mission statement.

That mission statement doesn't match intent, which is to produce a
kubernetes deployment of openstack.  I don't feel "various configurations"
cuts it.

But its really up to the Fuel team, not you or I.

Regards
-steve

>
>// jim
>
>> 
>> Regards
>> -steve
>> 
>> On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:
>> 
>> >Steven,
>> >
>> >fyi, This was debated in the project-config review:
>> >https://review.openstack.org/#/c/335584/
>> >
>> >
>> >Thanks,
>> >Dims
>> >
>> >On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake)
>>
>> >wrote:
>> >> Dims,
>> >>
>> >> Given the strong language around partnership between Intel, Mirantis,
>> >>and
>> >> Google in that press release, and the activity in the review queue (2
>> >> pages of outstanding reviews) it seems clear to me that the intent is
>> >>for
>> >> this part of Fuel to participate in the big tent.  The right thing
>>to do
>> >> here is for fuel-ccp to submit their repos to TC oversight by adding
>> >>them
>> >> to the official project list.
>> >>
>> >> Fuel requires a mission change, or it may be perceived that Fuel
>>itself
>> >> does not adhere to the Four Opens [1] specifically Open Development
>>and
>> >> Open Community.
>> >>
>> >> Regards
>> >> -steve
>> >>
>> >> [1] 
>> 
>>>>https://github.com/openstack/governance/blob/master/reference/opens.rst
>> >>
>> >> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
>> >>
>> >>>And. it's here in OpenStack:
>> >>>
>> >>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
>> >>>search
>> 
>>>>>https://review.openstack.org/#/q/status:open+branch:master+project:^op
>>>>>en
>> >>>st
>> >>>ack/fuel-ccp.*
>> >>>
>> >>>-- Dims
>> >>>
>> >>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
>> >>>wrote:
>> >>>> They are starting their own project.
>> >>>> 
>> >>>> From: Stephen Hindle [shin...@llnw.com]
>> >>>> Sent: Tuesday, July 26, 2016 10:35 AM
>> >>>> To: OpenStack Development Mailing List (not for usage questions)
>> >>>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is
>>getting
>> >>>>Fuel CCP (docker/k8s) kicked off
>> >>>>
>> >>>> So just saw this:
>> >>>>
>> 
>>>>>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-K
>>>>>>ub
>> >>>>er
>> >>>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>&

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Dims,

The project-config addition was debated by Andreas before this partnership
in this press release was announced and the full intent of the project was
understood.  The argument I see used in the review  is that since fuel-ccp
not part of Newton, it doesn't need to be in the projects.yaml file.
Given the intent of the project is obvious (to me) from the press release
to join the big tent, my two requests still apply.  At present this
project may be perceived as "flying under the radar" and further not
following the four opens as I already stated.

The two requests were:

1. Please submit the repositories for projects.yaml TC oversight
2. Please change Fuel's mission statement to match reality of this
announcement 

Regards
-steve

On 7/26/16, 1:18 PM, "Davanum Srinivas"  wrote:

>Steven,
>
>fyi, This was debated in the project-config review:
>https://review.openstack.org/#/c/335584/
>
>
>Thanks,
>Dims
>
>On Tue, Jul 26, 2016 at 3:47 PM, Steven Dake (stdake) 
>wrote:
>> Dims,
>>
>> Given the strong language around partnership between Intel, Mirantis,
>>and
>> Google in that press release, and the activity in the review queue (2
>> pages of outstanding reviews) it seems clear to me that the intent is
>>for
>> this part of Fuel to participate in the big tent.  The right thing to do
>> here is for fuel-ccp to submit their repos to TC oversight by adding
>>them
>> to the official project list.
>>
>> Fuel requires a mission change, or it may be perceived that Fuel itself
>> does not adhere to the Four Opens [1] specifically Open Development and
>> Open Community.
>>
>> Regards
>> -steve
>>
>> [1] 
>>https://github.com/openstack/governance/blob/master/reference/opens.rst
>>
>> On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:
>>
>>>And. it's here in OpenStack:
>>>
>>>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit
>>>search
>>>https://review.openstack.org/#/q/status:open+branch:master+project:^open
>>>st
>>>ack/fuel-ccp.*
>>>
>>>-- Dims
>>>
>>>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M 
>>>wrote:
>>>> They are starting their own project.
>>>> 
>>>> From: Stephen Hindle [shin...@llnw.com]
>>>> Sent: Tuesday, July 26, 2016 10:35 AM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
>>>>Fuel CCP (docker/k8s) kicked off
>>>>
>>>> So just saw this:
>>>>
>>>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kub
>>>>er
>>>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>>>>
>>>> Wonder if that means we'll get more devs or maybe some prebuilt
>>>> containers for Kolla?
>>>>
>>>>
>>>> --
>>>> Stephen Hindle - Senior Systems Engineer
>>>> 480.807.8189 480.807.8189
>>>> www.limelight.com Delivering Faster Better
>>>>
>>>> Join the conversation
>>>>
>>>> at Limelight Connect
>>>>
>>>> --
>>>> The information in this message may be confidential.  It is intended
>>>>solely
>>>> for
>>>> the addressee(s).  If you are not the intended recipient, any
>>>>disclosure,
>>>> copying or distribution of the message, or any action or omission
>>>>taken
>>>>by
>>>> you
>>>> in reliance on it, is prohibited and may be unlawful.  Please
>>>>immediately
>>>> contact the sender if you have received this message in error.
>>>>
>>>>
>>>>
>>>>___
>>>>__
>>>>_
>>>> 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-bi

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Dims,

Given the strong language around partnership between Intel, Mirantis, and
Google in that press release, and the activity in the review queue (2
pages of outstanding reviews) it seems clear to me that the intent is for
this part of Fuel to participate in the big tent.  The right thing to do
here is for fuel-ccp to submit their repos to TC oversight by adding them
to the official project list.

Fuel requires a mission change, or it may be perceived that Fuel itself
does not adhere to the Four Opens [1] specifically Open Development and
Open Community.

Regards
-steve

[1] https://github.com/openstack/governance/blob/master/reference/opens.rst

On 7/26/16, 11:15 AM, "Davanum Srinivas"  wrote:

>And. it's here in OpenStack:
>
>Look for fuel-ccp-* in http://git.openstack.org/cgit/ or the gerrit search
>https://review.openstack.org/#/q/status:open+branch:master+project:^openst
>ack/fuel-ccp.*
>
>-- Dims
>
>On Tue, Jul 26, 2016 at 1:53 PM, Fox, Kevin M  wrote:
>> They are starting their own project.
>> 
>> From: Stephen Hindle [shin...@llnw.com]
>> Sent: Tuesday, July 26, 2016 10:35 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Kolla] [Fuel] Looks like Mirantis is getting
>>Fuel CCP (docker/k8s) kicked off
>>
>> So just saw this:
>>   
>>http://www.computerweekly.com/blog/Open-Source-Insider/OpenStack-on-Kuber
>>netes-Mirantis-fuels-Fuel-with-Google-Intel-heat
>>
>> Wonder if that means we'll get more devs or maybe some prebuilt
>> containers for Kolla?
>>
>>
>> --
>> Stephen Hindle - Senior Systems Engineer
>> 480.807.8189 480.807.8189
>> www.limelight.com Delivering Faster Better
>>
>> Join the conversation
>>
>> at Limelight Connect
>>
>> --
>> The information in this message may be confidential.  It is intended
>>solely
>> for
>> the addressee(s).  If you are not the intended recipient, any
>>disclosure,
>> copying or distribution of the message, or any action or omission taken
>>by
>> you
>> in reliance on it, is prohibited and may be unlawful.  Please
>>immediately
>> contact the sender if you have received this message in error.
>>
>>
>> 
>>_
>>_
>> 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
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [release][kolla] Error in tagging process by release liason

[Steven Dake (stdake)]

On 7/26/16, 5:55 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-07-23 18:27:00 +:
>> Doug and friends,
>> 
>> I made a pretty serious error when tagging kolla-kubernetes originally.
>> Kolla-kubernetes is in development and not in a production ready state.
>> We also don't intend to apply for many if any tags for this repository
>>until it becomes more mature.  We do not intend to do backports to this
>>repository once Newton is released.
>> 
>> The original tag should have been 0.1.0.0b1.  The second milestone tag
>>was 0.1.1 (which should have been 0.1.0.0b2).  I caught this during
>>Doug's review but it was merged before I had a chance to talk to the
>>release team about solutions to this problem.
>> 
>> I don't expect to rewrite the tags or any of that.  I'd like guidance
>>on what to do for milestone 3 and Ocatta as well (where I guess we can
>>just reset on 0.2.0.0b1).
>> 
>> Regards
>> -steve
>
>kolla-kubernetes uses the release:independent model, for which we don't
>really intend to support beta-style milestone tags. The version number
>is already a pre-1.0 version, which should clearly indicate instability
>and immaturity to anyone consuming it.
>
>Milestone 3 should continue to use semantic versioning and either
>use 0.1.2 or 0.2.0 depending on the content. If you want to change
>the release model to cycle-with-milestones for Ocata, we can do
>that between the end of Newton and the first Ocata milestone.
>
>Doug

Doug,

Great news thanks.  I think maybe we had this conversation once over IRC
in various contexts, and I struggled to put them all together.

I've got it now.  I don't think we will be changing release cycles until
we have a proper 1.0.0 release of kolla-kubernetes.

Regards
-steve

>
>__
>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] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Response inline

On 7/25/16, 11:54 AM, "Matthias Runge"  wrote:

>On 25/07/16 09:57, Julien Danjou wrote:
>> On Sun, Jul 24 2016, Mathias Ewald wrote:
>> 
>>> 5. InfluxDB to store metrics
>>> 6. Grafana to dashboard metrics
>> 
>> Would be nice to leverage scalable and open source solution built your
>> fellow OpenStack community, i.e. Gnocchi and its Grafana support.
>> 
>Yes, I'd like to repeat the question here: Is there any reason to
>introduce another quite complex tool instead of something developed,
>supported and used by the OpenStack community?

I'm not sure how to respond to this question since I don't understand all
of the technical details of all these different solutions and what they
do.  I'd ask someone to draw me a picture but that is probably overkill.
When this thread got kicked off, my general thinking was we might end up
with more then one monitoring solution.

I think digging in deeper, there are 3 layers:
Data acquisition layer (e.g. Collectd)
Data storage layer (e.g. Influxdb)
Data modeling layer (e.g. Grafana)

I'm not a big fan of picking winners although there appears to be little
to no competition at the data modeling layer (unless that is what Sensu
does, still learning), so its the other layers that require the ability to
be mixed and matched.  Nobody has said we would reject such changes.
Operators have told me time and time again, flexibility is why Kolla is
chosen against other operational deployment managers (ODMs).  What google
tells me is that the data acquisition layer has 4 or 5 choices and the
data storage layer has 4 or 5 choices.  We enable and disable each service
individually on intention in Kolla.

I see no reason why this work can't be made to operate in that framework.
Someone needs to show up to do the work and both mewald and daviey have.
Their initial solutions don't include gnocchi (Kolla does not yet have
ansible playbooks for gnocci unfortunately).  I never tell people to go
"work on that" (unless someone asks when ramping up) - people choose to
work on what they want in this project.  I'm likely never changing my
perspective on this last point, fwiw :)

If someone does the work for gnocchi implementation, it will be merged
(unless some other core reviewer -2's the work which is unlikely but
possible - my opinion only counts once:)

Regards
-steve



>
>Matthias
>
>-- 
>Matthias Runge 
>
>Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>Commercial register: Amtsgericht Muenchen, HRB 153243,
>Managing Directors: Charles Cachera, Michael Cunningham,
>Michael O'Neill, Eric Shander
>
>__
>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] [kolla][vote] Applying for stable-follows tag

[Steven Dake (stdake)]

Cool,; a mentorship like relationship would be super helpful :)

I've modified the review.

Regards
-steve


From: Dave Walker mailto:em...@daviey.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 25, 2016 at 10:23 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

Hi,

I'm not currently kolla-core, but I am a member of stable-maint-core (cross 
project).  I've been pretty involved with Kolla this cycle, some 7 landed 
commits and 34 patchsets pushed up.. So I have a good understanding of both 
sides of the camp.  I'd be happy to throw my head into the ring for 
kolla-stable-maint.

--
Kind Regards,
Dave Walker

On 22 July 2016 at 10:47, Kwasniewska, Alicja 
mailto:alicja.kwasniew...@intel.com>> wrote:
+1 too

From: Mauricio Lima 
[mailto:mauricioli...@gmail.com<mailto:mauricioli...@gmail.com>]
Sent: Tuesday, July 19, 2016 5:29 PM

To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1

2016-07-19 12:23 GMT-03:00 Vikram Hosakote (vhosakot) 
mailto:vhosa...@cisco.com>>:
+1 sure.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski mailto:inc...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 19, 2016 at 9:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 ofc

On 19 July 2016 at 06:02, Ryan Hallisey 
mailto:rhall...@redhat.com>> wrote:
+1

-Ryan

- Original Message -
From: "Jeffrey Zhang" mailto:zhang.lei@gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Sent: Monday, July 18, 2016 9:16:09 PM
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
mailto:m...@coolsvap.net>> wrote:
On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke 
mailto:paul.bou...@oracle.com>> wrote:
Hi Steve,

+1 to applying. I'll volunteer for the backport team also.

-Paul


On 18/07/16 13:07, Steven Dake (stdake) wrote:

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.
   Full details are here:


http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is
possible that we may not be able to apply for this tag until Liberty
falls into EOL.  Still I personally believe intent matters most, and our
intent has always been for these to be stable low-rate-of-change
no-feature-backport branches.  There are some exceptions I think we
would fit under for the Liberty case, so I think it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for
Kolla reviews specifically.  These folks would be the only folks that
could ACK patches in the stable branch maintenance queue.  Anyone could
continue to submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core
reviewers) or until there is a unanimous vote.  If there is not, then we
won't apply.  The deadline for this vote is July 25th.

Thanks!
-steve




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

+1 to apply for stable follows policy.
I would like to volunteer for the backport team.

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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

Re: [openstack-dev] [kolla] Monitoring tooling

[Steven Dake (stdake)]

This 218 issue looks like it has a full solution to containerizing telegraf.  I 
suspect collectd is VERY similar in nature – so if your up for two challenges 
instead of one, collectd would be a good second target :)

Regards
-steve

From: Mathias Ewald mailto:mew...@evoila.de>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 25, 2016 at 4:48 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Monitoring tooling

I believe I found a possible (partial) solution: 
https://github.com/influxdata/telegraf/issues/218 I will test it and report 
back.

2016-07-25 12:58 GMT+02:00 Mathias Ewald 
mailto:mew...@evoila.de>>:
Excellent point ... I just checked what happens when running telegraf in a 
container: You'll get paths like

/etc/hostname
/etc/hosts
/var/log/kolla

and others as available file systems. I guess it makes no sense at all then to 
containerize monitoring agents ... Sensu is going to have the same problems.

Any suggestions?


2016-07-25 9:39 GMT+02:00 Jeffrey Zhang 
mailto:zhang.lei@gmail.com>>:
I am open to the choice of tools. But i am worried on thing: how to
get all the host disk usage when containerized the monitor tool?



On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald 
mailto:mew...@evoila.de>> wrote:
> Understood.
>
> 2016-07-25 7:34 GMT+02:00 Matthias Runge 
> mailto:mru...@redhat.com>>:
>>
>> On 25/07/16 06:38, Mathias Ewald wrote:
>> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>> > tenants rather than cloud ops? If that's the case I wont find info like
>> > "controller cpu usage" or "hypervisor memory usage".
>> >
>> > Cheers
>> > Mathias
>> >
>> Uhm, in this scenario, gnocchi just used as time-series database. It's
>> up to you, what you feed in. collectd collects whatever you want and put
>> it into your database.
>>
>> Best,
>> Matthias
>>
>> --
>> Matthias Runge mailto:mru...@redhat.com>>
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham,
>> Michael O'Neill, Eric Shander
>>
>> __
>> 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
>
>
>
>
> --
> Mobil: +49 176 10567592
> E-Mail: mew...@evoila.de
>
> evoila GmbH
> Wilhelm-Theodor-Römheld-Str. 34
> 55130 Mainz
> Germany
>
> Geschäftsführer: Johannes Hiemer
>
> Amtsgericht Mainz HRB 42719
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If You
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> __
> 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
>



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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



--
Mobil: +49 176 10567592
E-Mail: mew...@evoila.de

evoila GmbH
Wilhelm-Theodor-Römheld-Str. 34
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.

This e-mail may contain confidential and/or privileged information. If You are 
not the intended recipient (or have receiv

Re: [openstack-dev] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Collectd is how you obtain the host disk usage.  It can be done although
collectd is nearing the complexity of turning nova into a container so it
may need someone experienced with Kolla to execute.

Regards
-steve

On 7/25/16, 12:39 AM, "Jeffrey Zhang"  wrote:

>I am open to the choice of tools. But i am worried on thing: how to
>get all the host disk usage when containerized the monitor tool?
>
>
>
>On Mon, Jul 25, 2016 at 2:12 PM, Mathias Ewald  wrote:
>> Understood.
>>
>> 2016-07-25 7:34 GMT+02:00 Matthias Runge :
>>>
>>> On 25/07/16 06:38, Mathias Ewald wrote:
>>> > Hi, correct me if wrong please: Isn't gnocchi more targeting cloud
>>> > tenants rather than cloud ops? If that's the case I wont find info
>>>like
>>> > "controller cpu usage" or "hypervisor memory usage".
>>> >
>>> > Cheers
>>> > Mathias
>>> >
>>> Uhm, in this scenario, gnocchi just used as time-series database. It's
>>> up to you, what you feed in. collectd collects whatever you want and
>>>put
>>> it into your database.
>>>
>>> Best,
>>> Matthias
>>>
>>> --
>>> Matthias Runge 
>>>
>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>> Managing Directors: Charles Cachera, Michael Cunningham,
>>> Michael O'Neill, Eric Shander
>>>
>>> 
>>>
>>>__
>>> 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
>>
>>
>>
>>
>> --
>> Mobil: +49 176 10567592
>> E-Mail: mew...@evoila.de
>>
>> evoila GmbH
>> Wilhelm-Theodor-Römheld-Str. 34
>> 55130 Mainz
>> Germany
>>
>> Geschäftsführer: Johannes Hiemer
>>
>> Amtsgericht Mainz HRB 42719
>>
>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>>E-Mail
>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> Weitergabe dieser Mail ist nicht gestattet.
>>
>> This e-mail may contain confidential and/or privileged information. If
>>You
>> are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and destroy this e-mail. Any
>> unauthorised copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden.
>>
>> 
>>_
>>_
>> 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
>>
>
>
>
>-- 
>Regards,
>Jeffrey Zhang
>Blog: http://xcodest.me
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [kolla][stable] Please consider our application for stable:follows-policy for Kolla

[Steven Dake (stdake)]

[Forgot kolla tag]

From: Steven Dake mailto:std...@cisco.com>>
Date: Saturday, July 23, 2016 at 12:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [stable] Please consider our application for stable:follows-policy for 
Kolla

Hey folks,

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

[openstack-dev] [stable] Please consider our application for stable:follows-policy for Kolla

[Steven Dake (stdake)]

Hey folks,

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Steven Dake (stdake)]

This vote passed unanimously prior to the July 25th deadline.

Lets apply :)

Regards
-steve

From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 18, 2016 at 5:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla][vote] Applying for stable-follows tag

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.  Full 
details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is possible 
that we may not be able to apply for this tag until Liberty falls into EOL.  
Still I personally believe intent matters most, and our intent has always been 
for these to be stable low-rate-of-change no-feature-backport branches.  There 
are some exceptions I think we would fit under for the Liberty case, so I think 
it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for Kolla 
reviews specifically.  These folks would be the only folks that could ACK 
patches in the stable branch maintenance queue.  Anyone could continue to 
submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core 
reviewers) or until there is a unanimous vote.  If there is not, then we won't 
apply.  The deadline for this vote is July 25th.

Thanks!
-steve


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

[openstack-dev] [release][kolla] Error in tagging process by release liason

[Steven Dake (stdake)]

Doug and friends,

I made a pretty serious error when tagging kolla-kubernetes originally.  
Kolla-kubernetes is in development and not in a production ready state.  We 
also don't intend to apply for many if any tags for this repository until it 
becomes more mature.  We do not intend to do backports to this repository once 
Newton is released.

The original tag should have been 0.1.0.0b1.  The second milestone tag was 
0.1.1 (which should have been 0.1.0.0b2).  I caught this during Doug's review 
but it was merged before I had a chance to talk to the release team about 
solutions to this problem.

I don't expect to rewrite the tags or any of that.  I'd like guidance on what 
to do for milestone 3 and Ocatta as well (where I guess we can just reset on 
0.2.0.0b1).

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

Re: [openstack-dev] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Thanks for pointing that out.  Brain out to lunch today it appears :(

I think choices are a good thing even though they increase our
implementation footprint.  Anyone opposed to implementing both with
something in globals.yml like
monitoring: grafana or
monitoring: sensu

Comments questions or concerns welcome.

Regards
-steve

On 7/22/16, 3:42 PM, "Stephen Hindle"  wrote:

>Don't forget mewalds implementation as well - we now have 2 monitoring
>options for kolla :-)
>
>On Fri, Jul 22, 2016 at 3:15 PM, Steven Dake (stdake) 
>wrote:
>> Hi folks,
>>
>> At the midcycle we decided to push off implementing Monitoring until
>>post
>> Newton.  The rationale for this decision was that the core review team
>>has
>> enough on their plates and nobody was super keen to implement any
>>monitoring
>> solution given our other priorities.
>>
>> Like all good things, communities produce new folks that want to do new
>> things, and Sensu was proposed as Kolla's monitoring solution (atleast
>>the
>> first one).  A developer that has done some good work has shown up to
>>do the
>> job as well :)  I have heard good things about Sensu, minus the fact
>>that it
>> is implemented in Ruby and I fear it may end up causing our gate a lot
>>of
>> hassle.
>>
>> https://review.openstack.org/#/c/341861/
>>
>>
>> Anyway I think we can work through the gate problem.
>>
>> Does anyone have any better suggestion?  I'd like to unblock Dave's work
>> which is blocked on a ­2 pending a complete discussion of our monitoring
>> solution.  Note we may end up implementing more than one down the road ­
>> Sensu is just where the original interest was.
>>
>> Please provide feedback, even if you don't have a preference, whether
>>your a
>> core reviewer or not.
>>
>> My take is we can merge this work in non-prioirty order, and if it
>>makes the
>> end of the cycle fantastic ­ if not, we can release it in Ocatta.
>>
>> Regards
>> -steve
>>
>>
>> 
>>_
>>_
>> 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
>>
>
>
>
>-- 
>Stephen Hindle - Senior Systems Engineer
>480.807.8189 480.807.8189
>www.limelight.com Delivering Faster Better
>
>Join the conversation
>
>at Limelight Connect
>
>-- 
>The information in this message may be confidential.  It is intended
>solely 
>for
>the addressee(s).  If you are not the intended recipient, any disclosure,
>copying or distribution of the message, or any action or omission taken
>by 
>you
>in reliance on it, is prohibited and may be unlawful.  Please immediately
>contact the sender if you have received this message in error.
>
>
>__
>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] [Magnum] Remove Davanum Srinivas from Magnum core team

[Steven Dake (stdake)]

Your a class act Dims.  It was good working with you on Magnum :)

Regards
-steve

On 7/22/16, 2:15 PM, "Davanum Srinivas"  wrote:

>Thanks Hongbin!
>
>On Fri, Jul 22, 2016 at 5:13 PM, Hongbin Lu  wrote:
>> Hi all,
>>
>>
>>
>> Based on Dims¹s request, I removed him from the Magnum core reviewer
>>team.
>> Dims¹s contribution started from the first commit of the Magnum tree,
>>and he
>> was served as a Magnum core reviewer for a long time. I am sorry to hear
>> that Dims want to leave the team, but thanks for his contribution and
>> guidance to the project.
>>
>>
>>
>> Note: this removal doesn¹t require a vote because Dims requested to be
>> removed.
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>>
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>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] [kolla] Please start getting in the habit of breaking up containers from ansible changes

[Steven Dake (stdake)]

Precisely!

From: "Fox, Kevin M" mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, July 22, 2016 at 3:03 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Please start getting in the habit of 
breaking up containers from ansible changes

I think its an interesting idea. If nothing else, it will show what it would be 
like to have a split set of repo's before it actually is a thing and can't be 
undone.

Thanks,
Kevin

From: Dave Walker [em...@daviey.com<mailto:em...@daviey.com>]
Sent: Friday, July 22, 2016 2:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Please start getting in the habit of 
breaking up containers from ansible changes


On 22 July 2016 at 21:35, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
>
> Hey folks,
>
> I know it doesn't make a lot of sense to break up containers from ansible 
> changes to people outside the core review team, but for anything with 
> backport potential, please do so.  We are considering in Occata splitting the 
> kolla repo into two (kolla = containers & build, kolla-ansible = playbooks).  
> I think the timing is right after we branch Kolla Newton, but I don't want to 
> crater our backport process in the process.  By keeping the changes separate 
> we can still have a tidy backport experience.
>
> Even for small changes - 2-3 liner, please break them up using Partial-Bug.
>
> Core reviewers please start enforcing this.
>
> TIA!
> -steve
>

Hi Steve,

Why would this cause a problem in current Master?  As I understand it, you want 
to make sure that changes that touch both Dockerfiles and Playbooks are in 
isolated commits so they can be backported.  However, this surely won't be 
relevant until Newton is cut and Occata is opened, as Newton is remaining as a 
single tree.  So, the splitting of commits is only relevant in Occata+1, where 
splitting will already be enforced - by the splitting of the trees in Occata?  
I say O+1, as split trees will only start in O.. So for Newton, O commits will 
still backport cleanly... as they will be separated by the nature of the tree 
split.

Or... Have I horribly misunderstood your push?

With Occata, will kolla and kolla-ansible have common ancestry? As in, will 
they both be based on current Master with irrelevant files removed from each 
tree?

--
Kind Regards,
Dave Walker
__
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] [kolla] Monitoring tooling

[Steven Dake (stdake)]

Hi folks,

At the midcycle we decided to push off implementing Monitoring until post 
Newton.  The rationale for this decision was that the core review team has 
enough on their plates and nobody was super keen to implement any monitoring 
solution given our other priorities.

Like all good things, communities produce new folks that want to do new things, 
and Sensu was proposed as Kolla's monitoring solution (atleast the first one).  
A developer that has done some good work has shown up to do the job as well :)  
I have heard good things about Sensu, minus the fact that it is implemented in 
Ruby and I fear it may end up causing our gate a lot of hassle.


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


Anyway I think we can work through the gate problem.

Does anyone have any better suggestion?  I'd like to unblock Dave's work which 
is blocked on a -2 pending a complete discussion of our monitoring solution.  
Note we may end up implementing more than one down the road - Sensu is just 
where the original interest was.

Please provide feedback, even if you don't have a preference, whether your a 
core reviewer or not.

My take is we can merge this work in non-prioirty order, and if it makes the 
end of the cycle fantastic - if not, we can release it in Ocatta.

Regards
-steve

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

Re: [openstack-dev] [kolla] Please start getting in the habit of breaking up containers from ansible changes

[Steven Dake (stdake)]

From: Dave Walker mailto:em...@daviey.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, July 22, 2016 at 2:19 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Please start getting in the habit of 
breaking up containers from ansible changes


On 22 July 2016 at 21:35, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
>
> Hey folks,
>
> I know it doesn't make a lot of sense to break up containers from ansible 
> changes to people outside the core review team, but for anything with 
> backport potential, please do so.  We are considering in Occata splitting the 
> kolla repo into two (kolla = containers & build, kolla-ansible = playbooks).  
> I think the timing is right after we branch Kolla Newton, but I don't want to 
> crater our backport process in the process.  By keeping the changes separate 
> we can still have a tidy backport experience.
>
> Even for small changes - 2-3 liner, please break them up using Partial-Bug.
>
> Core reviewers please start enforcing this.
>
> TIA!
> -steve
>

Hi Steve,

Why would this cause a problem in current Master?  As I understand it, you want 
to make sure that changes that touch both Dockerfiles and Playbooks are in 
isolated commits so they can be backported.  However, this surely won't be 
relevant until Newton is cut and Occata is opened, as Newton is remaining as a 
single tree.  So, the splitting of commits is only relevant in Occata+1, where 
splitting will already be enforced - by the splitting of the trees in Occata?  
I say O+1, as split trees will only start in O.. So for Newton, O commits will 
still backport cleanly... as they will be separated by the nature of the tree 
split.

Or... Have I horribly misunderstood your push?

With Occata, will kolla and kolla-ansible have common ancestry? As in, will 
they both be based on current Master with irrelevant files removed from each 
tree?

Dave,

This causes no problem in current master or in Newton.

Newton, Mitaka, and Liberty will be one repository.  I want to run a 
semi-experiment to see if people complain about splitting up the changes to the 
point that it causes harm to the project and want to get the core reviewer team 
in the habit for looking for those sorts of issues.  Its a slight change in our 
workflow.

With Occata and the common ancestry question, if I were doing the work, I'd 
copy one repo to another, and remove irrelevant files as to not lose history.  
What we end up doing will likely be driven by community consensus not my best 
guess  at speculation of how it should be done so YMMV.

Regards
-steve

Regards
-steve


--
Kind Regards,
Dave Walker
__
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] [kolla] Please start getting in the habit of breaking up containers from ansible changes

[Steven Dake (stdake)]

Hey folks,

I know it doesn't make a lot of sense to break up containers from ansible 
changes to people outside the core review team, but for anything with backport 
potential, please do so.  We are considering in Occata splitting the kolla repo 
into two (kolla = containers & build, kolla-ansible = playbooks).  I think the 
timing is right after we branch Kolla Newton, but I don't want to crater our 
backport process in the process.  By keeping the changes separate we can still 
have a tidy backport experience.

Even for small changes - 2-3 liner, please break them up using Partial-Bug.

Core reviewers please start enforcing this.

TIA!
-steve

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

Re: [openstack-dev] [kolla] repo split

[Steven Dake (stdake)]

I am voting -1 for now, but would likely change my vote after we branch
Newton.  I'm not a super big fan of votes way ahead of major events (such
as branching) because a bunch of things could change between now and then
and the vote would be binding.

Still community called the vote - so vote stands :)

Regards
-steve


On 7/20/16, 1:48 PM, "Ryan Hallisey"  wrote:

>Hello.
>
>The repo split discussion that started at summit was brought up again at
>the midcycle.
>The discussion was focused around splitting the Docker containers and
>Ansible code into
>two separate repos [1].
>
>One of the main opponents to the split is backports.  Backports will need
>to be done
>by hand for a few releases.  So far, there hasn't been a ton of
>backports, but that could
>always change.
>
>As for splitting, it provides a much clearer view of what pieces of the
>project are where.
>Kolla-ansible with its own repo will sit along side kolla-kubernetes as
>consumers of the
>kolla repo.
>
>The target for the split will be for day 1 of Occata. The core team will
>vote on
>the change of splitting kolla into kolla-ansible and kolla.
>
>Cores please respond with a +1/-1 to approve or disapprove the repo
>split. Any community
>member feel free to weigh in with your opinion.
>
>+1
>-Ryan
>
>[1] - https://etherpad.openstack.org/p/kolla-N-midcycle-repo-split
>
>__
>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] [kolla] our mascot - input needed

[Steven Dake (stdake)]

On 7/18/16, 6:12 AM, "Michał Jastrzębski"  wrote:

>I refuse to be cut out of this thread. It is my right to freely say
>what's in my mind in this, very important for our glorious project,
>issue!
>
>So here it is:
>
>Koala that holds openstack square'y logo and makes docker whale jumps
>through it

that's actually pretty good but I'm sure OpenStack trademark folks would
mention "infringement!" of some type.  OR docker would :)

Regards
-steve
>
>See? No glue or any narcotics involved.
>Meanwhile I'll keep using my own logo which will be reserved for kolla
>inner circle. Also develop a secret handshake while I'm at it.
>
>On 17 July 2016 at 21:16, Jeffrey Zhang  wrote:
>> koala +1
>>
>> On Mon, Jul 18, 2016 at 9:07 AM, Ryan Hallisey 
>>wrote:
>>> koala bear
>>>
>>> -Ryan
>>>
>>> - Original Message -
>>> From: "Vikram Hosakote (vhosakot)" 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>
>>> Sent: Saturday, July 16, 2016 1:24:08 PM
>>> Subject: Re: [openstack-dev] [kolla] our mascot - input needed
>>>
>>> Sorry, I missed the kolla mid-cycle summit as I was at a conference.
>>>
>>> I will review the mid-cycle etherpad.
>>>
>>> Yes for the koala bear!! :)
>>>
>>> Regards,
>>> Vikram Hosakote
>>> IRC: vhosakot
>>>
>>> From: "Steven Dake (stdake)" < std...@cisco.com >
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)" < openstack-dev@lists.openstack.org >
>>> Date: Thursday, July 14, 2016 at 1:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>>openstack-dev@lists.openstack.org >
>>> Subject: [openstack-dev] [kolla] our mascot - input needed
>>>
>>> Hey folks,
>>>
>>> The OpenStack foundation is putting together mascots for every project
>>>with a proper artist doing the work. The cool thing about this is we a)
>>>get stickers b) have consistent look and feel among mascots in
>>>OpenStack.
>>>
>>> The downside is we have to make a decision. The foundation wants 3-5
>>>choices.
>>>
>>> The mascot must be an animal and it can't involve glue or other inc007
>>>inspired ideas :)
>>>
>>> Obviously Koala bear is probably everyone's first choice since we have
>>>sort of been using that as a mascot since day one. Anyone else have
>>>anything else for me to provide the foundation with a choices 2-5?
>>>
>>> Please respond quickly, the foundation needs the information shortly.
>>>I'd like to offer up two alternatives just in case.
>>>
>>> Regards
>>> -steve
>>>
>>>
>>>
>>> 
>>>
>>>__
>>> 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
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
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] [kolla][vote] Applying for stable-follows tag

[Steven Dake (stdake)]

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.  Full 
details are here:

http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is possible 
that we may not be able to apply for this tag until Liberty falls into EOL.  
Still I personally believe intent matters most, and our intent has always been 
for these to be stable low-rate-of-change no-feature-backport branches.  There 
are some exceptions I think we would fit under for the Liberty case, so I think 
it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for Kolla 
reviews specifically.  These folks would be the only folks that could ACK 
patches in the stable branch maintenance queue.  Anyone could continue to 
submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core 
reviewers) or until there is a unanimous vote.  If there is not, then we won't 
apply.  The deadline for this vote is July 25th.

Thanks!
-steve


__
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] [kolla] Patches needing review

[Steven Dake (stdake)]

Hey folks,

If you have spare cycles to burn on reviews, the following would help:

https://etherpad.openstack.org/p/R3rVu81fGU

__
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] [kolla] our mascot - input needed

[Steven Dake (stdake)]

Hey folks,

The OpenStack foundation is putting together mascots for every project with a 
proper artist doing the work.  The cool thing about this is we a) get stickers 
b) have consistent look and feel among mascots in OpenStack.

The downside is we have to make a decision.  The foundation wants 3-5 choices.

The mascot must be an animal and it can't involve glue or other inc007 inspired 
ideas :)

Obviously Koala bear is probably everyone's first choice since we have sort of 
been using that as a mascot since day one.  Anyone else have anything else for 
me to provide the foundation with a choices 2-5?

Please respond quickly, the foundation needs the information shortly.  I'd like 
to offer up two alternatives just in case.

Regards
-steve


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

Re: [openstack-dev] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Matt,

I'd like to add our CentOS / Oracle Linux gates work great with Red Hat's
feature-reduced version (not totally sure on the feature reduced part - I
saw it in a Red Hat summit slidedeck) of QEMU 2.3.0 shipped with RDO (not
sure on version of libvirt).

On 7/14/16, 9:34 AM, "Paul Bourke"  wrote:

>Hi Matt,
>
>Here is the failure from nova_compute on trying to start an instance:
>
>2016-07-13 18:04:12.634378 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service [req-0d77b2c1-43c8-41de-b57f-8aaa974b9807 - - - -
>-] Error starting thread.
>2016-07-13 18:04:12.634410 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service Traceback (most recent call last):
>2016-07-13 18:04:12.634463 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/servic
>e.py", 
>line 708, in run_service
>2016-07-13 18:04:12.634499 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service service.start()
>2016-07-13 18:04:12.634549 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py",
>line 117, in start
>2016-07-13 18:04:12.634583 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self.manager.init_host()
>2016-07-13 18:04:12.634652 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manage
>r.py", 
>line 1122, in init_host
>2016-07-13 18:04:12.634686 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self.driver.init_host(host=self.host)
>2016-07-13 18:04:12.634739 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 467, in init_host
>2016-07-13 18:04:12.634770 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service self._parse_migration_flags()
>2016-07-13 18:04:12.634834 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 689, in _parse_migration_flags
>2016-07-13 18:04:12.634869 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service live_migration_flags, live_config_name)
>2016-07-13 18:04:12.634930 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service   File
>"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/d
>river.py", 
>line 644, in _handle_live_migration_auto_converge
>2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service migration_flags &=
>~libvirt.VIR_MIGRATE_AUTO_CONVERGE
>2016-07-13 18:04:12.635022 | 2016-07-13 18:01:34.560 1 ERROR
>oslo_service.service AttributeError: 'module' object has no attribute
>'VIR_MIGRATE_AUTO_CONVERGE'
>
>The full log can be viewed at
>http://logs.openstack.org/76/339776/7/check/gate-kolla-dsvm-deploy-ubuntu-
>source/0849a74/console.html#_2016-07-13_18_04_12_526704
>
>-Paul
>
>On 14/07/16 17:13, Matt Riedemann wrote:
>> On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:
>>>
>>> We are not making the deploy gates voting at this time, although the
>>> plan is to do so once we stablize the last of the gate issues.  I think
>>> we are just down to one issue now, and that is that ubuntu source fails
>>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>> bug.  If the nova community has any bones to throw us on how to fix
>>> this, it would be appreciated.  I'd cut and paste the log, but for some
>>> reason C&P isn't working in my email client at present.
>>>
>>
>> What version of libvirt/qemu do you have in the image/job you're
>>running?
>>
>> See:
>>
>> 
>>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff02
>>9495a6/nova/virt/libvirt/driver.py#L278
>>
>>
>> If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
>> get these values from libvirt:
>>
>> 
>>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff02
>>9495a6/nova/virt/libvirt/driver.py#L633
>>
>>
>> Could be something patched out of the versions you're using from the
>> distro maybe?
>>
>> The actual failure paste/trace would help.
>>
>
>__
>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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Matt,

My computer is bust, but I've asked Paul and Serguei to get back to you
with answers to your questions in the next 30 minutes.

Regards
-steve

On 7/14/16, 9:13 AM, "Matt Riedemann"  wrote:

>On 7/14/2016 9:21 AM, Steven Dake (stdake) wrote:
>>
>> We are not making the deploy gates voting at this time, although the
>> plan is to do so once we stablize the last of the gate issues.  I think
>> we are just down to one issue now, and that is that ubuntu source fails
>> with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>> bug.  If the nova community has any bones to throw us on how to fix
>> this, it would be appreciated.  I'd cut and paste the log, but for some
>> reason C&P isn't working in my email client at present.
>>
>
>What version of libvirt/qemu do you have in the image/job you're running?
>
>See:
>
>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029
>495a6/nova/virt/libvirt/driver.py#L278
>
>If you have libvirt>=1.2.3 and qemu>=1.6.0 then it's going to try and
>get these values from libvirt:
>
>https://github.com/openstack/nova/blob/92a388a1e34559b2ce69d31fdef996ff029
>495a6/nova/virt/libvirt/driver.py#L633
>
>Could be something patched out of the versions you're using from the
>distro maybe?
>
>The actual failure paste/trace would help.
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__
>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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Antia,

Thanks for the correction.  I've been at this about 5 years, and agree -
things are muddy :)

Kolla cores - when reading this email, please keep Anita's comments in
mind.

Regards
-steve

On 7/14/16, 7:37 AM, "Anita Kuno"  wrote:

>On 07/14/2016 10:21 AM, Steven Dake (stdake) wrote:
>> Hey folks,
>> 
>> At the midcycle, we had a session on gating.
>> 
>> Out of that session came the decision to make the build gates voting
>
>Jobs, you have voting jobs, gates do not vote.
>
>We have an overload of technical terms as it is. Newcomers look to
>existing members to understand terminology and culture. Someone
>continuing to call a term a slang version perpetuates and creates
>confusion and frustration for people who believed they were using the
>correct term.
>
>http://docs.openstack.org/project-team-guide/testing.html#project-gating
>
>Thank you,
>Anita.
>
>
>> as soon as the mirroring is finished for ubuntu first (because that is
>>closer for us to get mirroring sorted out) followed by CentOS/Oracle
>>Linux.  I am taking this work on (mirroring specifically) and expect it
>>to finish in the next 1-2 weeks (ubuntu only).  After that I will sort
>>out the centos mirroring.  I'm not sure who got the mirroring work
>>kicked off in infrastructure - I think it was Jessie Pretorious - if the
>>credit is wrong apologies, but whoever it was, - huge thanks from me
>>personally :)
>> 
>> We are not making the deploy gates voting at this time, although the
>>plan is to do so once we stablize the last of the gate issues.  I think
>>we are just down to one issue now, and that is that ubuntu source fails
>>with an error about VIR MIGRATE AUTO CONVERGE.  This looks to be a nova
>>bug.  If the nova community has any bones to throw us on how to fix
>>this, it would be appreciated.  I'd cut and paste the log, but for some
>>reason C&P isn't working in my email client at present.
>> 
>> If folks know of other consistent deploy gate failures, can you please
>>respond on this thread with either a bug link or a link to a log of the
>>failure in question.
>> 
>> The review where it fails is 339776.
>> 
>> Regards
>> -steve
>> 
>> 
>> 
>> 
>>_
>>_
>> 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 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] [kolla][nova][infra] Voting gates

[Steven Dake (stdake)]

Hey folks,

At the midcycle, we had a session on gating.

Out of that session came the decision to make the build gates voting as soon as 
the mirroring is finished for ubuntu first (because that is closer for us to 
get mirroring sorted out) followed by CentOS/Oracle Linux.  I am taking this 
work on (mirroring specifically) and expect it to finish in the next 1-2 weeks 
(ubuntu only).  After that I will sort out the centos mirroring.  I'm not sure 
who got the mirroring work kicked off in infrastructure - I think it was Jessie 
Pretorious - if the credit is wrong apologies, but whoever it was, - huge 
thanks from me personally :)

We are not making the deploy gates voting at this time, although the plan is to 
do so once we stablize the last of the gate issues.  I think we are just down 
to one issue now, and that is that ubuntu source fails with an error about VIR 
MIGRATE AUTO CONVERGE.  This looks to be a nova bug.  If the nova community has 
any bones to throw us on how to fix this, it would be appreciated.  I'd cut and 
paste the log, but for some reason C&P isn't working in my email client at 
present.

If folks know of other consistent deploy gate failures, can you please respond 
on this thread with either a bug link or a link to a log of the failure in 
question.

The review where it fails is 339776.

Regards
-steve
__
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] [kolla] ended up with extra 85watt magsafe power supply

[Steven Dake (stdake)]

Hey folks,

I ended up with an extra power supply for a mac.  I'm not sure if it is from 
someone at the midcycle or from the Ansible HQ offices.  If its from the 
Ansible HQ offices, I'll have my wife take it with her next time she visits.  
If it was a midcycle attendee, please contact me off list with your address and 
I'll ship it to you.

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

Re: [openstack-dev] [kolla] New specs process - a dicussion

[Steven Dake (stdake)]

Josh,

We did have the discussion at summit.  We aren't even going to have a "big
spec".  We are going to run as bare minimal of a spec as possible.  The
reason I brought up spec additions is because Kolla has become so large,
managing the project using current techniques is not optimal.  I don't
like process but in the future, the PTL will need an easy on-ramp to
managing Kolla output.

I agree with all of the risks you point out related to usage of specs.  I
am hopeful we can make this is a super lightweight process without the
nitpicking that occurs in other projects.  That said, the rollcall vote
specs I expect to be as painful as they currently are (by design).

Regards
-steve


On 7/12/16, 4:03 PM, "Joshua Harlow"  wrote:

>Something for consideration to make the specs process not to painful and
>one that I think (?) glance pioneered is to have a 'bigger spec' and a
>'smaller spec' template.
>
>https://github.com/openstack/glance-specs/blob/master/specs/lite-specs.rst
> 
>(smaller)
>
>https://github.com/openstack/glance-specs/blob/master/specs/template.rst
>(bigger)
>
>Just my 2 cents, don't bog down people to much with just big specs and
>nit picking and trying to develop the whole feature in the spec (cause
>that will off-put new people and senior people and ...).
>
>-Josh
>
>Michał Jastrzębski wrote:
>> Hey guys,
>>
>> Since our project matured, we decided that we should have a discussion
>> regarding our spec process.
>>
>> https://etherpad.openstack.org/p/kolla-N-midcycle-specs
>>
>> Currently we do specs for most critical things, and they require
>>majority vote.
>>
>> We want to introduce another way, to enable non-nuclear specs.
>> To summarize our discussion so far:
>>
>> 1. Specs will require only 2 * +2 by default
>> 2. Specs sit at minimum 2 weeks in gerrit before first +2 arrives, so
>> other people will have time to look at it
>> 3. Any core can require a rollcall vote - then it becomes rollcall vote
>> 4. If nobody calls for rollcall vote, after 2 weeks spec can be merged
>> with normal 2 * +2
>>
>> Thoughts?
>> Michal
>>
>> 
>>_
>>_
>> 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 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