Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Jeff Peeler]

+1 - I don't know why we wouldn't go forward with this plan.

On Mon, Oct 26, 2015 at 11:02 PM, Ryan Hallisey  wrote:
> +1
>
> I think it's an excellent addition to kolla.
> I think this should help tremendously with usability and building better docs 
> around how to use kolla.
>
> -Ryan
>
>> On Oct 23, 2015, at 5:33 PM, Harm Weites  wrote:
>>
>> +1 this sort of stuff makes live a lot better :)
>>
>> Swapnil Kulkarni schreef op 2015-10-23 07:08:
>>> On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake)
>>>  wrote:
 Hello Folks,
 Oracle has developed a CLI tool for managing OpenStack Kolla
 clusters.  Several months ago at our midcycle, the topic was
 brought up an I suggested to go ahead and get started on the work.
 We clearly didn't spend enough time discussing how it should be
 integrated into the code base or developed or even what its features
 should be, and that is my error.
 What ended up happening is sort of a code dump, which is not ideal,
 but I can only work so many 20 hour days ;)  I didn't believe our
 community had the bandwidth to deal with integrating a CLI directly
 into the tree while we were focused on our major objective of
 implementing Ansible deployment of OpenStack in Docker containers.
 Possibly the wrong call, but it is what it is and it is my error,
 not Oracles.
>>> I think user experience will of the one of the major milestones for
>>> Kolla in Mitaka, e.g. user facing documentation, operator integration
>>> etc. a CLI would be helpful in that.
 The code can be cloned from:
 git clone git://oss.oracle.com/git/openstack-kollacli.git [1]
 The code as is is very high quality but will likely need to go
 through alot of refactoring to ReST-ify it.  There are two major
 authors of the code, Borne Mace and Steve Noyes.
 I'd like a majority vote from the core team as to whether we should
 add this repository to our list of governed repositories in the
 OpenStack Kolla governance repository here:
>>> hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
 [2]
 Consider this email a +1 vote from me.
>>> +1 from me
 A completely separate email thread and decision will be made by the
 community about core team membership changes to handle maintenance
 of the code.  Assuming this code is voted into Kolla's governance,
 I plan to propose Borne as a core reviewer, which will be open to
 core team vote as a separate act with our 3 +1 votes no vetos within
 1 week period.  We will address that assuming a majority vote of
 the code merge wins.  Steve can follow the normal processes for
 joining the core team if he wishes (reviewing patches) - clearly his
 code contributions are there.  Borne already does some reviews, and
 although he isn't a top reviewer, he does have some contribution in
 this area making it into the top 10 for the Liberty cycle.

 Kolla CLI Features:
 * dynamic ansible inventory manipulation via the host, group and
 service commands
 * ssh key push via the host setup command
 * ssh key validation via the host check command
 * ansible deployment via the deploy command
 * property viewing and modification with the property list, set and
 clear commands
 * cleanup of docker containers on a single, multiple or all hosts
 via the host destroy command
 * debug data collection via the dump command
 * configuration of openstack passwords via the password command
 * Lines of python = 2700
 * Lines of  test case code =  1800
 * ~ 200 commits

__
OpenStack Development Mailing 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] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Jeff Peeler]

On Mon, Nov 2, 2015 at 12:02 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> We had an informal vote at the mid cycle from the core reviewers, and it was
> a majority vote, so we went ahead and started the process of the
> introduction of mesos orchestration into Kolla.
>
> For background for our few core reviewers that couldn’t make it and the
> broader community, Angus Salkeld has committed himself and 3 other Mirantis
> engineers full time to investigate if Mesos could be used as an
> orchestration engine in place of Ansible.  We are NOT dropping our Ansible
> implementation in the short or long term.  Kolla will continue to lead with
> Ansible.  At some point in Mitaka or the N cycle we may move the ansible
> bits to a repository called “kolla-ansible” and the kolla repository would
> end up containing the containers only.
>
> The general consensus was that if folks wanted to add additional
> orchestration systems for Kolla, they were free to do so if they did the
> development and made a commitment to maintaining one core reviewer team with
> broad expertise among the core reviewer team of how these various systems
> work.
>
> Angus has agreed to the following
>
> A new team called “kolla-mesos-core” with 2 members.  One of the members is
> Angus Salkeld, the other is selected by Angus Salkeld since this is a cookie
> cutter empty repository.  This is typical of how new projects would operate,
> but we don’t want a code dump and instead want an integrated core team.  To
> prevent a situation which the current Ansible expertise shy away from the
> Mesos implementation, the core reviewer team has committed to reviewing the
> mesos code to get a feel for it.
> Over the next 6-8 weeks these two folks will strive to join the Kolla core
> team by typical means 1) irc participation 2) code generation 3) effective
> and quality reviews 4) mailing list participation
> Angus will create a technical specification which will we will roll-call
> voted and only accepted once a majority of core review team is satisfied
> with the solution.
> The kolla-mesos deliverable will be under Kolla governance and be managed by
> the Kolla core reviewer team after the kolla-mesos-core team is deprecated.
> If the experiment fails, kolla-mesos will be placed in the attic.  There is
> no specific window for the experiments, it is really up to Angus to decide
> if the technique is viable down the road.
> For the purpose of voting, the kolla-mesos-core team won’t be permitted to
> vote (on things like this or other roll-call votes in the community) until
> they are “promoted” to the koala-core reviewer team.
>
>
> The core reviewer team has agreed to the following
>
> Review patches in kolla-mesos repository
> Actively learn how the mesos orchestration system works in the context of
> Kolla
> Actively support Angus’s effort in the existing Kolla code base as long as
> it is not harmful to the Kolla code base
>
> We all believe this will lead to a better outcome then Mirantis developing
> some code on their own and later dumping it into the Kolla governance or
> operating as a fork.
>
> I’d like to give the core reviewers another chance to vote since the voting
> was semi-rushed.
>
> I am +1 given the above constraints.  I think this will help Kolla grow and
> potentially provide a better (or arguably different) orchestration system
> and is worth the investigation.  At no time will we put the existing Kolla
> Ansible + Docker goodness into harms way, so I see no harm in an independent
> repository especially if the core reviewer team strives to work as one team
> (rather then two independent teams with the same code base).
>
> Abstaining is the same as voting as –1, so please vote one way or another
> with a couple line blob about your thoughts on the idea.
>
> Note of the core reviewers there, we had 7 +1 votes (and we have a 9
> individual core reviewer team so there is already a majority but I’d like to
> give everyone an opportunity weigh in).

As one of the core reviewers who couldn't make the summit, this sounds
like a very exciting direction to go in. I'd love to see more docs (I
realize it's still early) on how mesos will be utilized and what
additional frameworks may be used as well. Is kubernetes planned to be
part of this mix since mesos works with it now?

__
OpenStack Development Mailing 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] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Jeff Peeler]

On Tue, Nov 3, 2015 at 1:44 AM, Michal Rostecki  wrote:
> Hi,
>
> +1 to what Steven said about Kubernetes.
>
> I'd like to add that these 3 things (pid=host, net=host, -v) are supported
> by Marathon, so probably it's much less problematic for us than Kubernetes
> at this moment.

I don't actively track Kubernetes upstream, so this seemed like a
natural point of reevaluation. If Kubernetes still doesn't support the
Docker features Kolla needs, obviously it's a non-starter. Nice to
hear that Marathon does though.

__
OpenStack Development Mailing 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] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

[Jeff Peeler]

On Tue, Nov 3, 2015 at 1:25 PM, Michal Rostecki  wrote:
> On 11/03/2015 04:16 PM, Jeff Peeler wrote:
>>
>> On Tue, Nov 3, 2015 at 1:44 AM, Michal Rostecki 
>> wrote:
>>>
>>> Hi,
>>>
>>> +1 to what Steven said about Kubernetes.
>>>
>>> I'd like to add that these 3 things (pid=host, net=host, -v) are
>>> supported
>>> by Marathon, so probably it's much less problematic for us than
>>> Kubernetes
>>> at this moment.
>>
>>
>> I don't actively track Kubernetes upstream, so this seemed like a
>> natural point of reevaluation. If Kubernetes still doesn't support the
>> Docker features Kolla needs, obviously it's a non-starter. Nice to
>> hear that Marathon does though.
>>
>
> After taking a look on docs, issues and pull requests in Kubernetes I have
> to admit that:
>
> - net=host is supported now -
> https://github.com/kubernetes/kubernetes/pull/5886
> - volumes seems to be supported -
> https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/volumes.md#hostpath
> - the question is whether this option provides 'rw' mode
>
> I couldn't find any info about pid=host. But if there is a support for that,
> I will have to change my mind about Kubernetes.

This might be helpful:
https://github.com/kubernetes/kubernetes/pull/3817

I don't have any vested interest in usage of Kubernetes, just thought
it was worth looking into.

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

[openstack-dev] [tripleO] appropriate location for docker image uploading

[Jeff Peeler]

I'm looking at introducing the ability for tripleoclient to upload
docker images into a docker registry (planning for it to be installed
in the undercloud [1]). I wanted to make sure something like this
would be accepted or get suggestions on an alternate approach.
Ultimately may end up looking something like the patch below, which
I'm still waiting for further feedback on:
https://review.openstack.org/#/c/239090/


[1] https://review.openstack.org/#/c/238238/

__
OpenStack Development Mailing 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] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Jeff Peeler]

> On 12/11/15 08:41, Steven Dake (stdake) wrote:
>
> Hey folks,
>
> Its been awhile since we have had a core reviewer nomination, but I
> really feel like Michal has the right stuff. If you look at the 30 day
> stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in
> a 30 day period. He is beating 2/3rds of our core reviewer team on all
> stats. I think his reviews, while could use a little more depth, are
> solid and well considered. That said he participates on the mailing
> list more then others and has been very active in IRC. He has come up
> to speed on the code base in quick order and I expect if he keeps pace,
> the top reviewers in Kolla will be challenged to maintain their spots :)
> Consider this proposal as a +1 vote from me.
>
> As a reminder, our core review process requires 3 core reviewer +1
> votes, with no core reviewer –1 (veto) votes within a 1 week period. If
> your on the fence, best to abstain :) I'll close voting November 20th,
> or sooner if there I a veto vote or a unanimous vote.
>
> Regards
> -steve
>
> http://stackalytics.com/report/contribution/kolla-group/30

+1!

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

Re: [openstack-dev] [Heat] core team changes

[Jeff Peeler]

On Wed, Jan 28, 2015 at 11:36:41AM +1000, Angus Salkeld wrote:

Hi all

After having a look at the stats:
http://stackalytics.com/report/contribution/heat-group/90
http://stackalytics.com/?module=heat-group&metric=person-day

I'd like to propose the following changes to the Heat core team:

Add:
Qiming Teng
Huang Tianhua

Remove:
Bartosz Górski (Bartosz has indicated that he is happy to be removed and
doesn't have the time to work on heat ATM).

Core team please respond with +/- 1.


+1

__
OpenStack Development Mailing 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 vote -> Removal of Harm Weites from the core reviewer team

[Jeff Peeler]

+1, I think this has been a good upholding of openstack core team
policy. Always a nice reminder that any previous core member can be
fast tracked back into place if they decide to become active again.

On Fri, Jan 15, 2016 at 8:44 AM, Michał Jastrzębski  wrote:
> That's an unfortunate +1, it's always sad to lose one of our own. Hope
> we'll see you back soon! Thanks for all the fis...reviews!
>
> On 15 January 2016 at 06:59, Ryan Hallisey  wrote:
>> Hello all,
>>
>> Harm, really appreciate all your reviews.  You were always very thorough and 
>> insightful.  You'll always be welcome back to the core team in the future. 
>> Thanks for everything Harm!
>>
>> +1
>> -Ryan
>>
>> - Original Message -
>> From: "Michal Rostecki" 
>> To: openstack-dev@lists.openstack.org
>> Sent: Friday, January 15, 2016 6:46:43 AM
>> Subject: Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites 
>> from the core reviewer team
>>
>> On 01/15/2016 01:12 AM, Steven Dake (stdake) wrote:
>>> Hi fellow core reviewers,
>>>
>>> Harm joined Kolla early on with great enthusiasm and did a bang-up job
>>> for several months working on Kolla.  We voted unanimously to add him to
>>> the core team.  Over the last 6 months Harm hasn't really made much
>>> contribution to Kolla.  I have spoken to him about it in the past, and
>>> he indicated his work and other activities keep him from being able to
>>> execute the full job of a core reviewer and nothing environmental is
>>> changing in the near term that would improve things.
>>>
>>> I faced a similar work/life balance problem when working on Magnum as a
>>> core reviewer and also serving as PTL for Kolla.  My answer there was to
>>> step down from the Magnum core reviewer team [1] because Kolla needed a
>>> PTL more then Magnum needed a core reviewer.  I would strongly prefer if
>>> folks don't have the time available to serve as a Kolla core reviewer,
>>> to step down as was done in the above example.  Folks that follow this
>>> path will always be welcome back as a core reviewer in the future once
>>> they become familiar with the code base, people, and the project.
>>>
>>> The other alternative to stepping down is for the core reviewer team to
>>> vote to remove an individual from the core review team if that is deemed
>>> necessary.  For future reference, if you as a core reviewer have
>>> concerns about a fellow core reviewer's performance, please contact the
>>> current PTL who will discuss the issue with you.
>>>
>>> I propose removing Harm from the core review team.  Please vote:
>>>
>>> +1 = remove Harm from the core review team
>>> -1 = don't remove Harm from the core review team
>>>
>>> Note folks that are voted off the core review team are always welcome to
>>> rejoin the core team in the future once they become familiar with the
>>> code base, people, and the project.  Harm is a great guy, and I hope in
>>> the future he has more time available to rejoin the Kolla core review
>>> team assuming this vote passes with simple majority.
>>>
>>> It is important to explain why, for some folks that may be new to a core
>>> reviewer role (which many of our core reviewers are), why a core
>>> reviewer should have their +2/-2 voting rights removed when they become
>>> inactive or their activity drops below an acceptable threshold for
>>> extended or permanent periods.  This hasn't happened in Harm's case, but
>>> it is possible that a core reviewer could approve a patch that is
>>> incorrect because they lack sufficient context with the code base.  Our
>>> core reviewers are the most important part of ensuring quality software.
>>>   If the individual has lost context with the code base, their voting
>>> may be suspect, and more importantly the other core reviewers may not
>>> trust the individual's votes.  Trust is the cornerstone of a software
>>> review process, so we need to maximize trust on a technical level
>>> between our core team members.  That is why maintaining context with the
>>> code base is critical and why I am proposing a vote to remove Harm from
>>> the core reviewer team.
>>>
>>> On a final note, folks should always know, joining the core review team
>>> is never "permanent".  Folks are free to move on if their interests take
>>> them into other areas or their availability becomes limited.  Core
>>> Reviewers can also be removed by majority vote.  If there is any core
>>> reviewer's performance you are concerned with, please contact the
>>> current PTL to first work on improving performance, or alternatively
>>> initiating a core reviewer removal voting process.
>>>
>>> On a more personal note, I want to personally thank Harm for his many
>>> and significant contributions to Kolla and especially going above and
>>> beyond by taking on the responsibility of a core reviewer.  Harm's
>>> reviews were always very thorough and very high quality, and I really do
>>> hope in the future Harm will rejoin the Kolla core team.
>>>
>>> Regards,
>>> -steve
>>>
>>> 

Re: [openstack-dev] [kolla] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc

[Jeff Peeler]

+1 from me as well

On Tue, Jan 19, 2016 at 1:52 PM, Gareth  wrote:
> +1 to lei :)
>
> On Wed, Jan 20, 2016 at 12:57 AM, Swapnil Kulkarni  wrote:
>> On Tue, Jan 19, 2016 at 1:56 PM, Steven Dake (stdake) 
>> wrote:
>>>
>>> Hi folks,
>>>
>>> I would like to propose Lei Zhang for our core reviewer team.  Count this
>>> proposal as a +1 vote from me.  Lei has done a fantastic job in his reviews
>>> over the last 6 weeks and has managed to produce some really nice
>>> implementation work along the way.  He participates in IRC regularly, and
>>> has a commitment from his management team at his employer to work full time
>>> 100% committed to Kolla for the foreseeable future (although things can
>>> always change in the future :)
>>>
>>> Please vote +1 if you approve of Lei for core reviewer, or –1 if wish to
>>> veto his nomination.  Remember just one –1 vote is a complete veto, so if
>>> your on the fence, another option is to abstain from voting.
>>>
>>> I would like to change from our 3 votes required, as our core team has
>>> grown, to requiring a simple majority of core reviewers with no veto votes.
>>> As we have 9 core reviewers, this means Lei requires 4 more  +1 votes with
>>> no veto vote in the voting window to join the core reviewer team.
>>>
>>> I will leave the voting open for 1 week as is the case with our other core
>>> reviewer nominations until January 26th.  If the vote is unanimous or there
>>> is a veto vote before January 26th I will close voting.  I'll make
>>> appropriate changes to gerrit permissions if Lei is voted into the core
>>> reviewer team.
>>>
>>> Thank you for your time in evaluating Lei for the core review team.
>>>
>>> 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] Location of Heka Lua plugins

[Jeff Peeler]

On Thu, Feb 4, 2016 at 9:22 AM, Michał Jastrzębski  wrote:
> TLDR; +1 to have lua in tree of kolla, not sure if we want to switch later
>
> So I'm not so sure about switching. If these git repos are in
> /openstack/ namespace, then sure, otherwise I'd be -1 to this, we
> don't want to add dependency here. Also we're looking at pretty simple
> set of files that won't change anytime soon probably. Also we might
> introduce new service that fuel does not have, and while I'm sure we
> can push new file to this repo, it's bigger issue than just coding it
> in tree.

I wouldn't think there'd be any opposition to having additional
contributed Lua scripts for additional services that Fuel doesn't yet
have. It's always easier to commit to one tree, but distinct
components like this separated out encourages code sharing (done
properly). I did assume that the new repo would be in the OpenStack
namespace, but even if it weren't I'd still think a separate repo is
best. Sure the files are small, but given the purpose of these files
small changes could potentially have a huge impact on the logs.

In summary, +1 to temporarily having the Lua scripts in tree until
they can be properly migrated to a new repository.

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

[openstack-dev] [TripleO] [Heat] [kolla] Deploying containerized services with Heat

[Jeff Peeler]

This email is loosely related to the recent thread of docker, puppet, 
and Heat here:

http://lists.openstack.org/pipermail/openstack-dev/2015-August/071492.html

I'd really like to get some feedback about work done to use Heat for 
deploying Kolla containers. Ultimately, the hope is to use this work for 
usage in tripleO. Here is an example of what the undercloud could look 
like [1]. The repo is currently messy and out of date, but illustrates 
bootstrapping Heat directly on a host with nothing installed except 
Docker. The idea was to utilize Kolla containers without any changes 
(and was also developed before the config external functionality came 
along).


A very incomplete template example for the undercloud 
(deploy-undercloud.yaml) exists in the heat-standalone directory.  
However, I've been struggling with the perceived template simplicity vs 
supportability due to the usage of the Heat docker driver.


A very similar approach of a containerized overcloud [2] was attempted 
on master [3] for the undercloud. My understanding was that it still has 
a problem with the os-*-config tools signaling back to Heat. I apologize 
I can't elaborate further on that. Note that is has been a primary 
objective to not use Nova for deploying containerized services (with 
both approaches) and I believe that contributed to the signaling problem 
mentioned before.


Thoughts on the above would be most welcome. Instead of further 
developing on something that ultimately goes nowhere, I'd rather consult 
the tripleO experts! Since there has been some contention for usage of 
the Heat docker driver, please also evaluate the Heat fat container for 
deployment usage.


Apologies in advance if any of this is unclear.

Jeff

[1] 
https://github.com/jpeeler/kolla/tree/694df62d47cf6d930bf04231386c917f5cb4da58$

[2] https://review.openstack.org/#/c/178840/
[3] https://github.com/jpeeler/kolla/commits/master$

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

Re: [openstack-dev] [TripleO] [Heat] [kolla] Deploying containerized services with Heat

[Jeff Peeler]

On Fri, Aug 07, 2015 at 11:31:52AM -0400, Jeff Peeler wrote:
[1] 
https://github.com/jpeeler/kolla/tree/694df62d47cf6d930bf04231386c917f5cb4da58

[2] https://review.openstack.org/#/c/178840/
[3] https://github.com/jpeeler/kolla/commits/master


If it's not obvious, please note that links 1 and 3 in the previous 
message need to have the terminating '$' character removed (modified 
links correctly here).


__
OpenStack Development Mailing 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] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

[Jeff Peeler]

On Fri, Aug 14, 2015 at 01:29:10PM +, Steven Dake (stdake) wrote:

Hi folks,

Swapnil has done a bunch of great technical work, participates heavily 
in IRC, and has contributed enormously to the implementation of Kolla.  
I’d like to see more reviews from Swapnil, but he has committed to 
doing more reviews and already has gone from something like 0 reviews 
to 90 reviews in about a month.  Count this proposal as a +1 from me.


His 90 day stats are:
http://stackalytics.com/report/contribution/kolla-group/90

The process we go to select new core reviewers is that we require a 
minimum of 3 +1 votes within a 1 week voting window.  A vote of –1 is a 
veto.  It is fine to abstain as well without any response to this 
email.  If the vote is unanimous or there is a veto vote prior to the 
end of the voting window, I’ll close voting then.


The voting is open until Friday August 21st.


+1!

__
OpenStack Development Mailing 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] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

[Jeff Peeler]

Hi folks,

I'm currently looking at supporting Ironic in the Kolla project [1], but
was unsure if it would be possible to run separate instances of nova
compute and controller (and scheduler too?) to enable both baremetal and
libvirt type deployments. I found this mailing list post from two years ago
[2], asking the same question. The last response in the thread seemed to
indicate work was being done on the scheduler to support multiple
configurations, but the review [3] ended up abandoned.

Are the current requirements the same? Perhaps using two availability zones
would work, but I'm not clear if that works on the same host.

[1] https://review.openstack.org/#/c/219747/
[2] http://lists.openstack.org/pipermail/openstack/2013-August/000504.html
[3] https://review.openstack.org/#/c/37407/
__
OpenStack Development Mailing 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] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

[Jeff Peeler]

I'd greatly prefer using availability zones/host aggregates as I'm trying
to keep the footprint as small as possible. It does appear that in the
section "configure scheduler to support host aggregates" [1], that I can
configure filtering using just one scheduler (right?). However, perhaps
more importantly, I'm now unsure with the network configuration changes
required for Ironic that deploying normal instances along with baremetal
servers is possible.

[1]
http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html

On Wed, Sep 9, 2015 at 1:13 PM, Jim Rollenhagen 
wrote:

> On Wed, Sep 02, 2015 at 03:42:20PM -0400, Jeff Peeler wrote:
> > Hi folks,
> >
> > I'm currently looking at supporting Ironic in the Kolla project [1], but
> > was unsure if it would be possible to run separate instances of nova
> > compute and controller (and scheduler too?) to enable both baremetal and
> > libvirt type deployments. I found this mailing list post from two years
> ago
> > [2], asking the same question. The last response in the thread seemed to
> > indicate work was being done on the scheduler to support multiple
> > configurations, but the review [3] ended up abandoned.
> >
> > Are the current requirements the same? Perhaps using two availability
> zones
> > would work, but I'm not clear if that works on the same host.
>
> At Rackspace we run Ironic in its own cell, and use cells filters to
> direct builds to the right place.
>
> The other option that supposedly works is host aggregates. I'm not sure
> host aggregates supports running two scheduler instances (because you'll
> want different filters), but maybe it does?
>
> // jim
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [tripleo] [kolla] Possible to support multiple compute drivers?

[Jeff Peeler]

On Wed, Sep 9, 2015 at 10:25 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Jeff Peeler" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > I'd greatly prefer using availability zones/host aggregates as I'm trying
> > to keep the footprint as small as possible. It does appear that in the
> > section "configure scheduler to support host aggregates" [1], that I can
> > configure filtering using just one scheduler (right?). However, perhaps
> > more importantly, I'm now unsure with the network configuration changes
> > required for Ironic that deploying normal instances along with baremetal
> > servers is possible.
> >
> > [1]
> >
> http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html
>
> Hi Jeff,
>
> I assume your need for a second scheduler is spurred by wanting to enable
> different filters for baremetal vs virt (rather than influencing scheduling
> using the same filters via image properties, extra specs, and boot
> parameters (hints)?
>
> I ask because if not you should be able to use the hypervisor_type image
> property to ensure that images intended for baremetal are directed there
> and those intended for kvm etc. are directed to those hypervisors. The
> documentation [1] doesn't list ironic as a valid value for this property
> but I looked into the code for this a while ago and it seemed like it
> should work... Apologies if you had already considered this.
>
> Thanks,
>
> Steve
>
> [1]
> http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html


I hadn't considered that, thanks. It's still unknown to me though if a
separate compute service is required. And if it is required, how much
segregation is required to make that work.

Not being a networking guru, I'm also unsure if the Ironic setup
instructions to use a flat network is a requirement or is just a sample of
possible configuration. In a brief out of band conversation I had, it does
sound like Ironic can be configured to use linuxbridge too, which I didn't
know was possible.
__
OpenStack Development Mailing 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] Fwd: [kolla] Planned maintenance for Delorean instance - September 14-15

[Jeff Peeler]

FYI

-- Forwarded message --
From: Javier Pena 
Date: Thu, Sep 10, 2015 at 11:50 AM
Subject: [Rdo-list] [delorean] Planned maintenance for Delorean instance -
September 14-15
To: rdo-list 

Dear all,

Due to a planned maintenance of the infrastructure supporting the Delorean
instance (trunk.rdoproject.org), it is expected to be offline between
September 14 (~ 9PM EDT) and September 15 (~ 9PM EDT).

We will be sending updates to the list if there is any additional
information or change in the plans, and keep you updated on the status.

Please let us know if you have any questions or concerns.

Regards,
Javier


Javier Peña, RHCAemail: javier.p...@redhat.com
Senior Software Engineer phone: +34 914148872
EMEA OpenStack Engineering
__
OpenStack Development Mailing 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] [Ironic] Suggestion to split install guide

[Jeff Peeler]

On Fri, Sep 11, 2015 at 9:44 AM, Jim Rollenhagen 
wrote:

> On Fri, Sep 11, 2015 at 10:56:07AM +0200, Dmitry Tantsur wrote:
> > Hi all!
> >
> > Our install guide is huge, and I've just approved even more text for it.
> > WDYT about splitting it into "Basic Install Guide", which will contain
> bare
> > minimum for running ironic and deploying instances, and "Advanced Install
> > Guide", which will the following things:
> > 1. Using Bare Metal service as a standalone service
> > 2. Enabling the configuration drive (configdrive)
> > 3. Inspection
> > 4. Trusted boot
> > 5. UEFI
> >
> > Opinions?
>
> +1, our guide is impossibly long. I like the idea of splitting out the
> optional bits so folks don't think that it's all required.
>

I agree as well! As somebody who is currently going through the install
guide, I might add that changing the ordering would be nice. Specifically
putting the image requirements and flavor creation last since they sort of
interrupt further server setup instructions.
__
OpenStack Development Mailing 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] Followup to review in gerrit relating to RHOS + RDO types

[Jeff Peeler]

On Mon, Sep 14, 2015 at 8:53 AM, Swapnil Kulkarni 
wrote:

>
>
> On Mon, Sep 14, 2015 at 5:14 PM, Sam Yaple  wrote:
>
>>
>> On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke 
>> wrote:
>>
>>>
>>>
>>> On 13/09/15 18:34, Steven Dake (stdake) wrote:
>>>
 Response inline.

 From: Sam Yaple mailto:sam...@yaple.net>>
 Reply-To: "s...@yaple.net" >>> s...@yaple.net>>
 Date: Sunday, September 13, 2015 at 1:35 AM
 To: Steven Dake mailto:std...@cisco.com>>
 Cc: "OpenStack Development Mailing List (not for usage questions)" <
 openstack-dev@lists.openstack.org>>> openstack-dev@lists.openstack.org>>
 Subject: Re: [kolla] Followup to review in gerrit relating to RHOS +
 RDO types

 On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake) >>> > wrote:
 Response inline.

 From: Sam Yaple mailto:sam...@yaple.net>>
 Reply-To: "s...@yaple.net" >>> s...@yaple.net>>
 Date: Saturday, September 12, 2015 at 11:34 PM
 To: Steven Dake mailto:std...@cisco.com>>
 Cc: "OpenStack Development Mailing List (not for usage questions)" <
 openstack-dev@lists.openstack.org>>> openstack-dev@lists.openstack.org>>
 Subject: Re: [kolla] Followup to review in gerrit relating to RHOS +
 RDO types



 Sam Yaple

 On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake) >>> > wrote:


 From: Sam Yaple mailto:sam...@yaple.net>>
 Reply-To: "s...@yaple.net" >>> s...@yaple.net>>
 Date: Saturday, September 12, 2015 at 11:01 PM
 To: Steven Dake mailto:std...@cisco.com>>
 Cc: "OpenStack Development Mailing List (not for usage questions)" <
 openstack-dev@lists.openstack.org>>> openstack-dev@lists.openstack.org>>
 Subject: Re: [kolla] Followup to review in gerrit relating to RHOS +
 RDO types


 On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake) <
 std...@cisco.com> wrote:
 Hey folks,

 Sam had asked a reasonable set of questions regarding a patchset:
 https://review.openstack.org/#/c/222893/

 The purpose of the patchset is to enable both RDO and RHOS as binary
 choices on RHEL platforms.  I suspect over time, from-source deployments
 have the potential to become the norm, but the business logistics of such a
 change are going to take some significant time to sort out.

 Red Hat has two distros of OpenStack neither of which are from source.
 One is free called RDO and the other is paid called RHOS.  In order to
 obtain support for RHEL VMs running in an OpenStack cloud, you must be
 running on RHOS RPM binaries.  You must also be running on RHEL.  It
 remains to be seen whether Red Hat will actively support Kolla deployments
 with a RHEL+RHOS set of packaging in containers, but my hunch says they
 will.  It is in Kolla’s best interest to implement this model and not make
 it hard on Operators since many of them do indeed want Red Hat’s support
 structure for their OpenStack deployments.

 Now to Sam’s questions:
 "Where does 'binary' fit in if we have 'rdo' and 'rhos'? How many more
 do we add? What's our policy on adding a new type?”

 I’m not immediately clear on how binary fits in.  We could make binary
 synonymous with the community supported version (RDO) while still
 implementing the binary RHOS version.  Note Kolla does not “support” any
 distribution or deployment of OpenStack – Operators will have to look to
 their vendors for support.

 If everything between centos+rdo and rhel+rhos is mostly the same then
 I would think it would make more sense to just use the base ('rhel' in this
 case) to branch of any differences in the templates. This would also allow
 for the least amount of change and most generic implementation of this
 vendor specific packaging. This would also match what we do with
 oraclelinux, we do not have a special type for that and any specifics would
 be handled by an if statement around 'oraclelinux' and not some special
 type.

 I think what you are proposing is RHEL + RHOS and CENTOS + RDO.  RDO
 also runs on RHEL.  I want to enable Red Hat customers to make a choice to
 have a supported  operating system but not a supported Cloud environment.
 The answer here is RHEL + RDO.  This leads to full support down the road if
 the Operator chooses to pay Red Hat for it by an easy transition to RHOS.

 I am against including vendor specific things like RHOS in Kolla
 outright like you are purposing. Suppose another vendor comes along with a
 new base and new packages. They are willing to maintain it, but its
 something that no one but their customers with their licensing can use.
 This is not something that belongs in Kolla and I am unsur

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Jeff Peeler]

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M  wrote:

> I agree. Lots of projects have this issue. I submitted a bug fix once that
> literally was 3 characters long, and it took:
> A short commit message, a long commit message, and a full bug report being
> filed and cross linked. The amount of time writing it up was orders of
> magnitude longer then the actual fix.
>
> Seems a bit much...
>
> Looking at this review, I'd go a step farther and argue that code cleanups
> like this one should be really really easy to get through. No one likes to
> do them, so we should be encouraging folks that actually do it. Not pile up
> roadblocks.


It is indeed frustrating. I've had a few similar reviews (in other projects
- hopefully it's okay I comment here) as well. Honestly, I think if a given
team is willing to draw the line as for what is permissible to commit
without bug creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come
release time having the list of bugs fixed in a given release is handy,
spelling errors included.
__
OpenStack Development Mailing 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] proposing Michal Jastrzebski (inc0) for core reviewer

[Jeff Peeler]

On Tue, Sep 29, 2015 at 6:20 PM, Steven Dake (stdake)  wrote:
> Hi folks,
>
> I am proposing Michal for core reviewer.  Consider my proposal as a +1 vote.
> Michal has done a fantastic job with rsyslog, has done a nice job overall
> contributing to the project for the last cycle, and has really improved his
> review quality and participation over the last several months.

Agreed, +1!

__
OpenStack Development Mailing 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] new yaml format for all.yml, need feedback

[Jeff Peeler]

The patch I just submitted[1] modifies the syntax of all.yml to use
dictionaries, which changes how variables are referenced. The key
point being in globals.yml, the overriding of a variable will change
from simply specifying the variable to using the dictionary value:

old:
api_interface: 'eth0'

new:
network:
api_interface: 'eth0'

Preliminary feedback on IRC sounded positive, so I'll go ahead and
work on finishing the review immediately assuming that we'll go
forward. Please ping me if you hate this change so that I can stop the
work.

[1] https://review.openstack.org/#/c/229535/

__
OpenStack Development Mailing 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] discussion about core reviewer limitations by company

[Jeff Peeler]

On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake)  wrote:
> The issue isn't about reviewing patches in my opinion.  Obviously people
> shouldn't jam patches through the review queue that they know will be
> counter-productive to the majority view of the core reviewers.  If they do,
> they can easily be reverted by 3 different core reviewers.  Our core
> reviewers are adults and don't behave in this way.  I have seen a couple
> patches "jammed through" and not reverted, from multiple companies rather
> then just one company and it just made everyone angry.  I think folks have
> learned from that and tend not to "jan through contentious changes" unless
> it is time critical (as in breaking gate, or busted master, or milestone
> deadline).
>
> The issue is around policy setting.  The PTL should NOT be a dictator and
> set policy on their own whim.  The way we set policy in Kolla (and I believe
> in other OpenStack projects) is by formal majority vote.  For example, one
> policy we have set is that we permit third party proprietary distros and
> plugins to interact and even be a part of our Dockerfile.j2 if someone steps
> up to maintain them.  NB our specs directory are actually policy "direction"
> rather then hard policies.  That is why spec's require a majority vote to
> approve.
>
> Folks that have responded on this thread thus far have seem to missed this
> policy point and focused on the reviewing of patches.

I think the reason people are so focused on reviewing patches is
because that is the "core" job of a core reviewer. I feel like the
Kolla project votes a lot more on policy than other projects (I'm
including IRC and during formal gatherings), so that may be why policy
is not at the forefront of the discussion.

> All that said, I hear what your saying regarding motivation.  The original
> discussion was about protecting the project from a lack of diversity in the
> core reviewer team which could potentially lead to majority-rules by one
> corporate affiliation on policy matters.  What would be an ideal outcome in
> my opinion is to keep motivation intact but meet the diversity requirements
> set forth in the governance repository to avoid a majority-rules by one
> corporate affiliation situation.  There are two ways to do this that I can
> think of:
>
> Add core reviewers that aren't quite there yet, but close to meet the
> diversity requirements

(Label: solution #1)
Perhaps instead of this a specific group such as the drivers team (or
bugs, whatever) can be allowed to vote on policy. This role change
would widen the pool of available candidates while not adding people
prematurely to core status.

> Or
> Limit core reviewers

As stated in another thread, this policy wouldn't be acceptable for
some smaller projects with limited diversity.

> Or
> Another simple solution is to permit a a veto vote from any core reviewer
> within the 1 week voting window if a majority (or some other value, such as
> 35%) from one corporate affiliation votes yes on a policy decision.  This
> could be gamed, but at least does not permit policy changes by one corporate
> affiliation.  With our current core review team, that means 3 people could
> vote from RHT (out of the 4 core reviewers) before triggering the veto rule.

(Label: solution #2)
This sounds like to me prevention of "jamming through" which I'm not
sure is necessary, but I do like this option best of those presented
by Steve. Some policies simply aren't that significant, but others
are. I think this is why it's important to bring major policy
decisions to the mailing list. It gives people time to really think
about their opinions/facts and broadens the scope of the discussion.

> Or
> Permit a veto vote on policy changes (I really don't like this option, as it
> gives too much "power" to one individual over the project policy)

Agreed.

> I'd like to hear what other core reviewers as well as Kolla developers have
> to say about the matter.
>
> As a final note, I am very very (!) anti-process.  A project should only
> have as much process as it needs to succeed.  Many/most projects(not
> OpenStack, but other projects) go overboard on process.  Process just
> creates needless complication, so I am also not hot on setting a bunch of
> policies (which require process to execute).  The main problem with process
> is it creates too many rules for people to make sure they are compliant
> with.  This slows the system down, and the system should be fast, nimble,
> and agile.
>
> When I open discussion on a policy change, its not like I do it for my
> health - its because I see a serious issue coming down the road.  In this
> case I don't know precisely how to correct this particular problem, which is
> why we are having this discussion.  I'd prefer if folks focus on what we can
> do to fix it, rather then saying "no lets not do anything".

Although you mentioned you didn't want the PTL to serve as a dictator,
I think that having the PTL resolve unresolvable dis

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

[Jeff Peeler]

+1

On Mon, Mar 7, 2016 at 3:57 AM, Michal Rostecki  wrote:
> +1
>
>
> __
> OpenStack Development Mailing 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] exception for backporting upgrades to liberty/stable

[Jeff Peeler]

On Mon, Mar 7, 2016 at 11:00 AM, Sam Yaple  wrote:
>
> Obviously I am +1 on committing to a stable _stable_ branch. And that has
> always required Z upgrades. Luckily the work we did in master is also usable
> for z upgrades. Without the ability to perform an update after a
> vulnerability, we have to stable branch.

Assuming Sam meant "we have no stable branch" above, I think this is
crux of the matter. If we follow the purist developer philosophy
behind a stable branch, then maybe upgrades wouldn't be backported.
But if operators then can't count on using Liberty at that point, what
does it matter?

In the future I'm sure we can follow strict "developer level"
adherence to backports for Mitaka. So if it's not clear, +1 to
including this in 1.1.0.

> I would remind every one we _did_ have this conversation in Tokyo when we
> discussed pinning to stable versions of other projects rather than using
> head of thier stable branch. We currently do that and there is a review for
> a tool to make that even easier to maintain [1]. There was even talk of a
> bot to purpose these bumps in versions. That means z upgrades were expected
> for Liberty. Anyone thinking otherwise has a short memory.
>
> [1] https://review.openstack.org/#/c/248481/

This review has been merged now.

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

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Jeff Peeler]

On Wed, Mar 23, 2016 at 1:34 PM, Zane Bitter  wrote:
> On 23/03/16 07:54, Ryan Hallisey wrote:
>>
>> *Snip*
>>
>>> Indeed, this has literally none of the benefits of the ideal Heat
>>> deployment enumerated above save one: it may be entirely the wrong tool
>>> in every way for the job it's being asked to do, but at least it is
>>> still well-integrated with the rest of the infrastructure.
>>
>>
>>> Now, at the Mitaka summit we discussed the idea of a 'split stack',
>>> where we have one stack for the infrastructure and a separate one for
>>> the software deployments, so that there is no longer any tight
>>> integration between infrastructure and software. Although it makes me a
>>> bit sad in some ways, I can certainly appreciate the merits of the idea
>>> as well. However, from the argument above we can deduce that if this is
>>> the *only* thing we do then we will end up in the very worst of all
>>> possible worlds: the wrong tool for the job, poorly integrated. Every
>>> single advantage of using Heat to deploy software will have evaporated,
>>> leaving only disadvantages.
>>
>>
>> I think Heat is a very powerful tool having done the container integration
>> into the tripleo-heat-templates I can see its appeal.  Something I learned
>> from integration, was that Heat is not the best tool for container
>> deployment,
>> at least right now.  We were able to leverage the work in Kolla, but what
>> it
>> came down to was that we're not using containers or Kolla to its max
>> potential.
>>
>> I did an evaluation recently of tripleo and kolla to see what we would
>> gain
>> if the two were to combine. Let's look at some items on tripleo's roadmap.
>> Split stack, as mentioned above, would be gained if tripleo were to adopt
>> Kolla.  Tripleo holds the undercloud and ironic.  Kolla separates config
>> and deployment.  Therefore, allowing for the decoupling for each piece of
>> the stack.  Composable roles, this would be the ability to land services
>> onto separate hosts on demand.  Kolla also already does this [1]. Finally,
>> container integration, this is just a given :).
>>
>> In the near term, if tripleo were to adopt Kolla as its overcloud it would
>> be provided these features and retire heat to setting up the baremetal
>> nodes
>> and providing those ips to ansible.  This would be great for kolla too
>> because
>> it would provide baremetal provisioning.
>>
>> Ian Main and I are currently working on a POC for this as of last week
>> [2].
>> It's just a simple heat template :).
>>
>> I think further down the road we can evaluate using kubernetes [3].
>> For now though,  kolla-anisble is rock solid and is worth using for the
>> overcloud.
>
>
> My concern about kolla-ansible is that the requirements might start getting
> away from what the original design was intended to cope with, and that it
> may prove difficult to extend. For example, I wrote about the idea of doing
> the container deployments with pure Heat:
>
>>> What's more, we are going to need some way of redistributing services
>>> when a machine in the cluster fails, and ultimately we would like that
>>> process to be automated, which would *require* a template generation
>>> service.
>>>
>>> We certainly *could* build all of that. But we definitely shouldn't
>
>
> and to my mind kolla-ansible is in a similar category in that respect (it
> does, of course, have an existing community and in that sense is still
> strictly superior to the pure-Heat approach). There's lots of stuff in e.g.
> Kubernetes that it seems likely we'll want and, while there's no
> _theoretical_ obstacle to implementing them in Ansible, these are hard,
> subtle problems which are presumably better left to a specialist project.

Fully agree with Zane here. I'm not really excited by using anything
other than Kubernetes for container orchestration (unless it's mesos,
but my understanding is it's a bit more heavyweight). Though I am
certainly okay with using kolla-ansible to generate config for all the
OpenStack services, but if it's faster to use puppet then that's fine
too.

The only drawback that I know of is that the Kolla containers would
need modifying since Kubernetes has no notion of dependencies. But
perhaps I'm getting ahead of myself...

> I'd be happy to hear other opinions on that though. Maybe we don't care
> about any of that container cluster management stuff, and if something fails
> we just let everything run degraded until we can pull in a replacement? I
> don't know.

__
OpenStack Development Mailing 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] Just make Mitaka deploy Liberty within the Liberty branch

[Jeff Peeler]

On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake)  wrote:
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, March 30, 2016 at 12:29 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty
> within the Liberty branch
>
> +1
>
> A lot of changes has been make in Mitaka. Backport is difficult.
>
> But using Mitaka deploy Liberty also has *much works*. For example,
> revert config file change which deprecated in Mitaka and Liberty support.
>
> A important one is the `keystone-manage bootstrap` command to create the
> keystone admin account. This is adderecently and only exist in the Mitaka
> branch. So when using this method, we should revert some commit and use
> the old way method.
>
>
> Agreed.

I'm sure there will be some checking and such once all the code has
been shuffled around, but I think doing this work is better than
abandoning a branch. So +1 to proposal.

__
OpenStack Development Mailing 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] Nominating Vikram Hosakot for Core Reviewer

[Jeff Peeler]

+1

On Tue, Mar 29, 2016 at 12:07 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> Consider this proposal a +1 in favor of Vikram joining the core reviewer
> team.  His reviews are outstanding.  If he doesn’t have anything useful to
> add to a review, he doesn't pile on the review with more –1s which are
> slightly disheartening to people.  Vikram has started a trend amongst the
> core reviewers of actually diagnosing gate failures in peoples patches as
> opposed to saying gate failed please fix.  He does this diagnosis in nearly
> every review I see, and if he is stumped  he says so.  His 30 days review
> stats place him in pole position and his 90 day review stats place him in
> second position.  Of critical notice is that Vikram is ever-present on IRC
> which in my professional experience is the #1 indicator of how well a core
> reviewer will perform long term.   Besides IRC and review requirements, we
> also have code requirements for core reviewers.  Vikram has implemented only
> 10 patches so far, butI feel he could amp this up if he had feature work to
> do.  At the moment we are in a holding pattern on master development because
> we need to fix Mitaka bugs.  That said Vikram is actively working on
> diagnosing root causes of people's bugs in the IRC channel pretty much 12-18
> hours a day so we can ship Mitaka in a working bug-free state.
>
> Our core team consists of 11 people.  Vikram requires at minimum 6 +1 votes,
> with no veto –2 votes within a 7 day voting window to end on April 7th.  If
> there is a veto vote prior to April 7th I will close voting.  If there is a
> unanimous vote prior to April 7th, I will make appropriate changes in
> gerrit.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla-group/30
> [2] http://stackalytics.com/report/contribution/kolla-group/90
>
> __
> OpenStack Development Mailing 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] Nit-picking documentation changes

[Jeff Peeler]

On Mon, Apr 11, 2016 at 3:37 AM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> The reviewers in Kolla tend to nit-pick the quickstart guide to death during
> reviews.  I'd like to keep that high bar in place for the QSG, because it is
> our most important piece of documentation at present.  However, when new
> contributors see the nitpicking going on in reviews, I think they may get
> discouraged about writing documentation for other parts of Kolla.
>
> I'd prefer if the core reviewers held a lower bar for docs not related to
> the philosophy or quiickstart guide document.  We can always iterate on
> these new documents (like the operator guide) to improve them and raise the
> bar on their quality over time, as we have done with the quickstart guide.
> That way contributors don't feel nitpicked to death and avoid improving the
> documentation.
>
> If you are a core reveiwer and agree with this approach please +1, if not
> please –1.

I'm fine with relaxing the reviews on documentation. However, there's
a difference between having a missed comma versus the whole patch
being littered with misspellings. In general in the former scenario I
try to comment and leave the code review set at 0, hoping the
contributor fixes it. The danger is that a 0 vote people sometimes
miss, but it doesn't block progress.

__
OpenStack Development Mailing 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] Place kolla-mesos in openstack-attic

[Jeff Peeler]

On Sat, Apr 23, 2016 at 12:06 AM, Steven Dake (stdake)  wrote:
> Jeremy,
>
> Thanks for the information - you can tell I'm a bit dated ;)
>
> Folks, take this vote to mean what Jeremy has stated as far as repo
> deprecation goes.

+1

__
OpenStack Development Mailing 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][kubernetes] One repo vs two

[Jeff Peeler]

On Mon, May 2, 2016 at 9:50 AM, Andreas Jaeger  wrote:
> On 05/02/2016 03:05 PM, Steven Dake (stdake) wrote:
>> Swapnil,
>>
>> I gather this is what people want but this cannot be done with git and
>> maintain history.  To do this, we would have to "cp oldrepo/files to
>> newrepo/files" and the git history would be lost.  That is why choosing
>> two repositories up front is irreversible.
>
>
> On the other hand: If you start with one and want to split later, you can
> use git-filter to create a copy of the repo with just the kubernetes files
> in it and set up a new repository with that content. So, you would keep the
> history...

Andreas, could you also not do the reverse with two separate
repositories and merge them to preserve the history using subtree
merging [1]? If I'm not correct, I'm sure repository merging can be
done somehow as Linus merged gitk into git years ago with history
preservation. So really, I don't think git history should be part of
this discussion.

[1] 
https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

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

Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Jeff Peeler]

Also +1 for working on kolla-kubernetes. (Please read this thread if
you haven't yet):

http://lists.openstack.org/pipermail/openstack-dev/2016-May/093575.html

On Mon, May 2, 2016 at 10:56 AM, Ryan Hallisey  wrote:
> +1 to start kolla-kubernetes work.
>
> - Original Message -
> From: "Swapnil Kulkarni" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, May 2, 2016 12:59:40 AM
> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] 
> kolla-kubernetes repository management proposal up for vote
>
> On Mon, May 2, 2016 at 10:08 AM, Vikram Hosakote (vhosakot)
>  wrote:
>> A separate repo will land us in the same spot as we had with kolla-mesos
>> originally.  We had all kinds of variance in the implementation.
>>
>> I’m in favor of a single repo.
>>
>> +1 for the single repo.
>>
>
> I agree with you Vikram, but we should consider the bootstrapping
> requirements for new deployment technologies and learn from our
> failures with kolla-mesos.
>
> At the same time, it will help us evaluate the deployment technologies
> going ahead without distrupting the kolla repo which we can treat as a
> repo with stable images & associated deployment tools.
>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: Vikram Hosakote 
>> Date: Sunday, May 1, 2016 at 11:36 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
>> kolla-kubernetes repository management proposal up for vote
>>
>> Please add me too to the list!
>>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: Michał Jastrzębski 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Saturday, April 30, 2016 at 9:58 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
>> kolla-kubernetes repository management proposal up for vote
>>
>> Add me too please Steven.
>>
>> On 30 April 2016 at 09:50, Steven Dake (stdake)  wrote:
>>
>> Fellow core reviewers,
>>
>> We had a fantastic turnout at our fishbowl kubernetes as an underlay for
>> Kolla session.  The etherpad documents the folks interested and discussion
>> at summit[1].
>>
>> This proposal is mostly based upon a combination of several discussions at
>> open design meetings coupled with the kubernetes underlay discussion.
>>
>> The proposal (and what we are voting on) is as follows:
>>
>> Folks in the following list will be added to a kolla-k8s-core group.
>>
>>   This kolla-k8s-core group will be responsible for code reviews and code
>> submissions to the kolla repository for the /kubernetes top level directory.
>> Individuals in kolla-k8s-core that consistently approve (+2) or disapprove
>> with a (-2) votes to TLD directories other then kubernetes will be handled
>> on a case by case basis with several "training warnings" followed by removal
>> of the kolla-k8s-core group.  The kolla-k8s-core group will be added as a
>> subgroup of the kolla-core reviewer team, which means they in effect have
>> all of the ACL access as the existing kolla repository.  I think it is
>> better in this case to trust these individuals to the right thing and only
>> approve changes for the kubernetes directory until proposed for the
>> kolla-core reviewer group where they can gate changes to any part of the
>> repository.
>>
>> Britt Houser
>>
>> mark casey
>>
>> Steven Dake (delta-alpha-kilo-echo)
>>
>> Michael Schmidt
>>
>> Marian Schwarz
>>
>> Andrew Battye
>>
>> Kevin Fox (kfox)
>>
>> Sidharth Surana (ssurana)
>>
>>   Michal Rostecki (mrostecki)
>>
>>Swapnil Kulkarni (coolsvap)
>>
>>MD NADEEM (mail2nadeem92)
>>
>>Vikram Hosakote (vhosakot)
>>
>>Jeff Peeler (jpeeler)
>>
>>Martin Andre (mandre)
>>
>>Ian Main (Slower)
>>
>> Hui Kang (huikang)
>>
>> Serguei Bezverkhi (sbezverk)
>>
>> Alex Polvi (polvi)
>>
>> Rob Mason
>>
>> Alicja Kwasniewska
>>
>> sean mooney (sean-k-mooney)
>>
>> Keith Byrne (kbyrne)
>>
>> Zdenek Janda (xdeu)
>>
>> Brandon Jozsa (v1k0d3n)
>>
>> Rajath Agasthya (rajathagasthya)
>>
>>
>> If yo

Re: [openstack-dev] [kolla][kubernetes] One repo vs two

[Jeff Peeler]

On Sun, May 1, 2016 at 5:03 PM, Steven Dake (stdake)  wrote:
> I don't think a separate repository is the correct approach based upon one
> off private conversations with folks at summit. Many people from that list
> approached me and indicated they would like to see the work integrated in
> one repository as outlined in my vote proposal email.  The reasons I heard
> were:
>
> Better integration of the community
> Better integration of the code base
> Doesn't present an us vs them mentality that one could argue happened during
> kolla-mesos
> A second repository makes k8s a second class citizen deployment architecture
> without a voice in the full deployment methodology
> Two gating methods versus one
> No going back to a unified repository while preserving git history
>
> I favor of the separate repositories I heard
>
> It presents a unified workspace for kubernetes alone
> Packaging without ansible is simpler as the ansible directory need not be
> deleted
>
> There were other complaints but not many pros.  Unfortunately I failed to
> communicate these complaints to the core team prior to the vote, so now is
> the time for fixing that.

I favor the repository split, but the reason being is that I think
Ansible along with Kubernetes should each be a separate repository.
Keeping a monolithic repository is the opposite of the "Unix
philosophy". It was even recommended at one point to split every
single service into a separate repository [1].

Repository management, backports, and additional gating are all things
that I'll admit are more work with more than one single repository.
However, the ease of ramping up where everything is separated out
makes it worth it in my opinion. I believe the success of a given
community is partially due to proper delineation of expertise
(otherwise, why not put all OpenStack services in one gigantic repo?).
I'm echoing this comment somebody said at the summit: stretching the
core team across every orchestration tool is not scalable. I'm really
hoping more projects will grow around the Kolla ecosystem and can do
so without being required to become proficient with every other
orchestration system.

One argument for keeping a single repository is to compare to the
mesos effort (that has stopped now) in a different repository. But as
it has already been said, mesos should have been given fairness with
ansible split out as well. If everything were in a single repository,
it has been suggested that the community will review more. However, I
don't personally believe that with gerrit in use that affects things
at all. OpenStack even has a gerrit dashboard creator [2], but I think
developers are capable enough at easily finding what they want to
consistently review.

As I said in a previous reply [3], I don't think git history should
affect this decision as we can make it work in either scenario. ACL
permissions seem overly complicated to be in the same repository, even
if we can arrange for a feature branch to have different permissions
from the main repo.

My views here are definitely focused on the long term view. If any
short term plans can be made to allow ourselves to eventually align
with having separate repositories, I don't think I'd have a problem
with that. However, I thought the Ansible code was supposed to have
been separated out a long time ago. This is a natural inflection point
to change policy and mode of operating, which is why I don't enjoy the
idea of waiting any longer. Luckily, having Ansible in the same
repository currently does not inhibit any momentum with Kubernetes in
a separate repository.

As far as starting the repositories split and then merging them in the
future (assuming Ansible also stays in one repo), I don't know why we
would want that. But perhaps after the Kubernetes effort has
progressed we can better determine if that makes sense with a clear
view of what the project files actually end up looking like. I don't
think that any project that changes the containers' ABI is suitable to
be labeled as "Kolla", so there wouldn't be any dockerfiles part of
the repository.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093213.html
[2] https://github.com/openstack/gerrit-dash-creator
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093645.html

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

Re: [openstack-dev] [kolla] Kolla rpm distribution

[Jeff Peeler]

On Fri, May 6, 2016 at 2:54 AM,   wrote:
>
> Hi，
>
> One of our application would like to use Kolla as an upstream deployment
> tools. As the application may run in the environment without internet
> connections, we are trying to packaging Kolla as well as its requirements,
> such as jinja2, into rpm packages and deliver them along with the
> application. We would like to get some advises about:
> 1) Is it the right way to go for our application to build rpms for upstream
> python packages?

If you don't want to rely on pip, then you have to use RPM or some
other method of installing the requirements. It is on the to do list
to create a document to help people mirror content so that they can
build faster, though I'm not sure if it would fully cover no access to
the internet at all.

> 2) Is there any plan for Kolla project to implement rpm packaging. As we are
> working on that, I think we can do some contributions.

Kolla just consumes RPMs (and debs). Package availability would
obviously depend on what distribution you're using, but python-jinja2
seems to already be packaged for Fedora:
https://admin.fedoraproject.org/pkgdb/package/rpms/python-jinja2/

__
OpenStack Development Mailing 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] Ironic broken on Ubuntu

[Jeff Peeler]

On Thu, May 5, 2016 at 1:51 PM, Franck Barillaud  wrote:
> All the containers are started expect for 'ironic_inspector' and
> 'nova_compute_ironic'.  Looking at the
> 'kolla/docker/ironic/ironic-inspector' shows no contruct for Ubuntu.

Yes, it's a feature gap that is known:
https://bugs.launchpad.net/kolla/+bug/1565936

> Rebuilt successufully the ironic containers on centos. The question is how
> can I deploy them ? Using 'kolla-ansible deploy' does not support 'mixed'
> environments.

The "mixed" environment issue [1][2] is one reason why the containers
are turned off by default. For reference, to enable the service you
modify it in /etc/kolla/globals.yml (after copying it) [3]. I really
struggled to on how to produce a Kolla compatible environment for
Ironic to operate in. Kolla is currently looking to integrate with
Bifrost in order to utilize ironic's services - stay tuned.

[1] http://lists.openstack.org/pipermail/openstack/2015-September/013986.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073530.html
[3] 
https://github.com/openstack/kolla/blob/2e396fec9807d1bfdb7a51027e85257f7d53a991/etc/kolla/globals.yml#L114

__
OpenStack Development Mailing 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] Vagrant environment for kolla-kubernetes

[Jeff Peeler]

On Fri, May 13, 2016 at 2:57 AM, Britt Houser (bhouser)
 wrote:
> Would we ever run AIO-k8s vagrant w/o Kolla repo?  If not, then it makes 
> sense to me just to extend Vagrant kolla repo.
>
> Thx,
> britt

As Kolla developers we may not, but somebody else may want to. Either
way, having the Vagrant configuration in the place with the least
amount of burden makes sense.

__
OpenStack Development Mailing 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] Vagrant environment for kolla-kubernetes

[Jeff Peeler]

(continuing to top post)

I wasn't arguing otherwise for the record. My comment was merely to
remind that coupling between the two repos should be kept at a
minimum. But I'm fully in favor of any coupling that eliminates code
duplication.

On Fri, May 13, 2016 at 2:51 PM, Steven Dake (stdake)  wrote:
> Jeff,
>
> I'd like to see Kolla defaults for k8s come from one place rather then
> two, so I suggested to Dims in a previous review to depend on the kolla
> repo for those files rather then copy them and maintain them in two places.
>
> Therefore, I don¹t see a viable path forward without the Kolla package
> installed that doesn't create a maintenance nightmare for the core
> reviewers.
>
> Regards
> -steve
>
> On 5/13/16, 11:10 AM, "Jeff Peeler"  wrote:
>
>>On Fri, May 13, 2016 at 2:57 AM, Britt Houser (bhouser)
>> wrote:
>>> Would we ever run AIO-k8s vagrant w/o Kolla repo?  If not, then it
>>>makes sense to me just to extend Vagrant kolla repo.
>>>
>>> Thx,
>>> britt
>>
>>As Kolla developers we may not, but somebody else may want to. Either
>>way, having the Vagrant configuration in the place with the least
>>amount of burden makes sense.

__
OpenStack Development Mailing 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] Proposing Mauricio Lima for core reviewer

[Jeff Peeler]

+1!

On Tue, May 17, 2016 at 3:00 PM, Steven Dake (stdake)  wrote:
> Hello core reviewers,
>
> I am proposing Mauricio (mlima on irc) for the core review team.  He has
> done a fantastic job reviewing appearing in the middle of the pack for 90
> days [1] and appearing as #2 in 45 days [2].  His IRC participation is also
> fantastic and does a good job on technical work including implementing
> Manila from zero experience :) as well as code cleanup all over the code
> base and documentation.  Consider my proposal a +1 vote.
>
> I will leave voting open for 1 week until May 24th.  Please vote +1
> (approve), or –2 (veto), or abstain.  I will close voting early if there is
> a veto vote, or a unanimous vote is reached.
>
> Thanks,
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/90
> [2] http://stackalytics.com/report/contribution/kolla/45

__
OpenStack Development Mailing 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] Proposal for changing 1600UTC meeting to 1700 UTC

[Jeff Peeler]

On Mon, Jun 08, 2015 at 05:15:54PM +, Steven Dake (stdake) wrote:

Folks,

Several people have messaged me from EMEA timezones that 1600UTC fits 
right into the middle of their family life (ferrying kids from school 
and what-not) and 1700UTC while not perfect, would be a better fit 
time-wise.


For all people that intend to attend the 1600 UTC, could I get your 
feedback on this thread if a change of the 1600UTC timeslot to 1700UTC 
would be acceptable?  If it wouldn’t be acceptable, please chime in as 
well.


Both 1600 and 1700 UTC are fine for me.

Jeff

__
OpenStack Development Mailing 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] Proposal for new core-reviewer Harm Waites

[Jeff Peeler]

On Sun, Jun 14, 2015 at 05:48:48PM +, Steven Dake (stdake) wrote:

I am proposing Harm Waites for the Kolla core team.


+1!

__
OpenStack Development Mailing 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] Proposal for Paul Bourke for Kolla Core

[Jeff Peeler]

On Tue, Jul 14, 2015 at 01:56:16PM +0200, Harm Weites wrote:


no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic 
job getting Kolla into shape to support multiple distros and from 
source/from binary installation. His statistics are fantastic 
including both code and reviews. His reviews are not only voluminous, 
but consistently good. Paul is helping on many fronts and I would feel 
make a fantastic addition to our core reviewer team.


Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a 
veto for the candidate, so if you are on the fence, best to abstain :) 
We require 3 core reviewer votes to approve a candidate. I will leave 
the voting open until July 20th  UTC. If the vote is unanimous 
prior to that time or a veto vote is received, I’ll close voting and 
make appropriate adjustments to the gerrit groups.


+1!

__
OpenStack Development Mailing 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] Propose Andre Martin for kolla-core

[Jeff Peeler]

On Tue, Feb 17, 2015 at 03:07:31AM +, Steven Dake (stdake) wrote:

Hi folks,

I’d am proposing Andre Martin to join the kolla-core team.  Andre has been 
providing mostly code implementation, but as he contributes heavily, has 
indicated he will get more involved in our peer reviewing process.

He has contributed 30% of the commits for the Kilo development cycle, acting as 
our #1 commit contributor during Kilo.

http://stackalytics.com/?project_type=all&module=kolla&metric=commits

Kolla-core members please vote +1/abstain/-1.  Remember that a any –1 
vote is a veto.


+1

__
OpenStack Development Mailing 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] [Heat] Stepping down from core

[Jeff Peeler]

As discussed during the previous Heat meeting, I'm going to be stepping 
down from core on the Heat project. My day to day focus is going to be 
more focused on TripleO for the foreseeable future, and I hope to be 
able to soon focus on reviews there.


Being part of Heat core since day 0 has been a good experience, but 
keeping up with multiple projects is a lot to manage. I don't know how 
some of you do it!


Jeff

__
OpenStack Development Mailing 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 Meeting Times Wednesday 1600UTC (even)/2200UTC (odd)

[Jeff Peeler]

On Sun, May 10, 2015 at 08:49:11PM +, Steven Dake (stdake) wrote:

I have closed the doodle poll for our new meeting times.  We will be meeting in 
#openstack-meeting-3 (yes there is that much contention for our time slots – 
must be a reason ;).

The times are:
Weekly Wednesday 1600 UTC (even weeks)
Weekly Wednesday 2200 UTC (odd weeks)

To determine if it is an even or odd week run:
date "+%U”


It's actually date "+%V" to get the ISO week numbering. The wiki has 
been updated for this along with the correct IRC channel information.


https://wiki.openstack.org/wiki/Meetings/Kolla#Weekly_Kolla_team_meeting

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

Re: [openstack-dev] [kolla] Add core approver Sam Yaple

[Jeff Peeler]

On Mon, May 25, 2015 at 06:59:15PM +, Steven Dake (stdake) wrote:

Hi folks,

I propose Sam Yaple for core approver for the Kolla team.  Sam has a 
lot of great ideas and has done some really cool work lately.  Sam is 
active in IRC and is starting to pick up more reviews.  Of particular 
interest to me his his idea of merging the work he has done on YAODU 
into Kolla.  This would be fantastic for Kolla and allow us to deliver 
on our goals of providing high availability which depends on multi-node 
deployment in our container architecture.


Some really complex and nice improvements to the codebase:
https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z
https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z
https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z

Sam's stats for Liberty and Kilo:
http://stackalytics.com/?project_type=all&user_id=s8m&module=kolla&release=all

Count my proposal as a +1.  Since our core team is only 5 people 
presently, I think it makes sense to only require one additional +1.  
Typically projects require 3 +1 votes but have larger core teams, so we 
will use that in the future.  -1 = veto, so vote wisely.  Folks often 
abstain if they are not certain how their vote should go – so don’t 
feel compelled to vote.


+1, don't even need to look at the above links

__
OpenStack Development Mailing 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] gate failing sporadically

[Jeff Peeler]

On Sat, May 30, 2015 at 03:00:04AM +, Steven Dake (stdake) wrote:

Hey Folks,

I noticed the Kolla functional gate is failing sporadically.

It seems that sometimes an image doesn’t build.

http://logs.openstack.org/75/186475/1/check/check-kolla-functional-f21/8f23913/console.html


(For the record, due to the compressing of the logs it's best to post 
the link to the directory of the logs.)


One thing that looks off there is barbican is not building a —release 
image (I.e. Tag =atest).  Shouldn’t it?


The other failures I’ve noticed follow the same pattern.  Is there a 
problem in our build scripts?


All the images are handled the same. I didn't see the atest tag you 
mentioned, but I see that the latest build did succeed. It appears that 
a yum mirror failure was to blame and affected other reviews as well.  
Hopefully mirror reliability doesn't become a frequent problem.


I imagine all of this has been figured out, but mailing list posts 
without a reply are less useful for the archives.


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

Re: [openstack-dev] [heat] Nomination for heat-core

[Jeff Peeler]

On Thu, Dec 19, 2013 at 03:21:46PM +1300, Steve Baker wrote:
> I would like to nominate Bartosz Górski to be a heat-core reviewer. His
> reviews to date have been valuable and his other contributions to the
> project have shown a sound understanding of how heat works.
> 
> Here is his review history:
> https://review.openstack.org/#/q/reviewer:bartosz.gorski%2540ntti3.com+project:openstack/heat,n,z
> 
> If you are heat-core please reply with your vote.

+1

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

Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core

[Jeff Peeler]

On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote:
> I would like to nominate Jason Dunsmore for heat-core.
> 
> His reviews are valuable and prolific, his code contributions have
> demonstrated a good knowledge of heat internals, and he has endured a
> sound hazing to get multi-engine into heat.
> 
> http://russellbryant.net/openstack-stats/heat-reviewers-60.txt
> http://www.stackalytics.com/?release=icehouse&metric=commits&user_id=jasondunsmore
> 
> Heat cores, please reply with your vote.

+1!

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

Re: [openstack-dev] [heat] Proposal for new heat-core member

[Jeff Peeler]

On 10/25/2013 03:12 PM, Steven Dake wrote:

I would like to propose Randall Burt for Heat Core.
Please have a vote +1/-1 and take into consideration: 
https://wiki.openstack.org/wiki/Heat/CoreTeam


[1]http://russellbryant.net/openstack-stats/heat-reviewers-180.txt 

[2]http://russellbryant.net/openstack-stats/heat-reviewers-30.txt 


+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

[Jeff Peeler]

+1

On 10/06/2014 04:41 PM, Zane Bitter wrote:

I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team.

Pavlo has been a consistently active member of the Heat community - he's
a regular participant in IRC and at meetings, has been making plenty of
good commits[1] and maintains a very respectable review rate[2] with
helpful comments. I think he's built up enough experience with the code
base to be ready for core.

Heat-cores, please vote by replying to this thread. As a reminder of
your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as
a veto.


Obviously past 5 +1 votes here, but showing full support doesn't hurt.



cheers,
Zane.

[1]
https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z

[2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
[3]
https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members



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

Re: [openstack-dev] [kolla] making Daneyon Hansen core

[Jeff Peeler]

On 10/22/2014 11:04 AM, Steven Dake wrote:

A few weeks ago in IRC we discussed the criteria for joining the core
team in Kolla.  I believe Daneyon has met all of these requirements by
reviewing patches along with the rest of the core team and providing
valuable comments, as well as implementing neutron and helping get
nova-networking implementation rolling.

Please vote +1 or -1 if your kolla core.  Recall a -1 is a veto.  It
takes 3 votes.  This email counts as one vote ;)


definitely +1


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

Re: [openstack-dev] Proposal for check network connectivity after vm boot

[Jeff Peeler]

On 08/11/2013 04:13 AM, Jae Sang Lee wrote:

Hi stackers,

I registerd a blueprint for this proposal, 
https://blueprints.launchpad.net/nova/+spec/check-network-connectivity


If you have permission to approve who read this mail, please review 
and approve my blueprint.


Thanks.


I would think compulsory instance probing would not be welcomed. 
However, I do wonder if new functionality (for Neutron) along the lines 
of security-group-rule-test   would be helpful. 
Not sure how UDP checking would work though.



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

Re: [openstack-dev] [heat] Propose Liang Chen for heat-core

[Jeff Peeler]

On 08/22/2013 11:57 AM, Steven Hardy wrote:

Hi,

I'd like to propose that we add Liang Chen to the heat-core team[1]

Liang has been doing some great work recently, consistently providing good
review feedback[2][3], and also sending us some nice patches[4][5], implementing
several features and fixes for Havana.

Please respond with +1/-1.

+1!


Thanks!

[1] https://wiki.openstack.org/wiki/Heat/CoreTeam
[2] http://russellbryant.net/openstack-stats/heat-reviewers-90.txt
[3] https://review.openstack.org/#/q/reviewer:cbjc...@linux.vnet.ibm.com,n,z
[4] 
https://github.com/openstack/heat/graphs/contributors?from=2013-04-18&to=2013-08-18&type=c
[5] https://review.openstack.org/#/q/owner:cbjc...@linux.vnet.ibm.com,n,z

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



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

[openstack-dev] [kolla] stepping down from core

[Jeff Peeler]

Hi all,

This is my official announcement to leave core on Kolla /
Kolla-Kubernetes. I've enjoyed working with all of you and hopefully
we'll cross paths again!

Jeff

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