[openstack-dev] [kolla] Triaging and resolution of rc2 bugs.

Kolla developers and bug triagers, Our Mitaka rc2 is scheduled for April 1st. It would be fantastic if anyone that wants to contribute to Kolla in the next two weeks could do the following: 1. Confirm bugs in the "Triaged" state if not the original reporter - that way a developer can

Re: [openstack-dev] lvm2 and docker issue

Ccing mailing list for eveyrone's advantage. From: "Serguei Bezverkhi (sbezverk)" > Date: Tuesday, March 15, 2016 at 8:26 PM To: Steven Dake > Subject: lvm2 and docker issue Hi Steven, I have run few tests

[openstack-dev] [kolla] ubuntu deploy gate

The ubuntu deploy gate is failing because of commit 7f6de0a7e0d784181a6f99270768712e761f113a. Please see review https://review.openstack.org/#/c/290243/ for more details. For the moment ignore the ubuntu deploy gate

[openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

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

Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent

On 3/27/16, 2:50 PM, "Matt Riedemann" <mrie...@linux.vnet.ibm.com> wrote: > > >On 3/26/2016 11:27 AM, Steven Dake (stdake) wrote: >> Hey fellow PTLs and core reviewers of those projects, >> >> Kolla at present deploys the compute kit, and some other

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

Kevin, I am not directly answering your question, but from the perspective of Kolla, our upgrades are super simple because we don't make a big mess in the first place to upgrade from. In my experience, this is the number one problem with upgrades – everyone makes a mess of the first

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

On 4/12/16, 10:37 AM, "Jeremy Stanley" wrote: >On 2016-04-01 15:50:57 + (+), Hayes, Graham wrote: >> If a team has already done a TA (e.g. as part of an internal >> product TA) (and produced all the documentation) would this meet >> the requirements? >> >> I ask, as

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

On 4/11/16, 1:38 AM, "Gerard Braad" <m...@gbraad.nl> wrote: >Hi, > >On Mon, Apr 11, 2016 at 4:20 PM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> On 4/11/16, 12:54 AM, "Gerard Braad" <m...@gbraad.nl> wrote: >> as &g

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

On 4/11/16, 12:54 AM, "Gerard Braad" <m...@gbraad.nl> wrote: >Hi Steven, > >On Mon, Apr 11, 2016 at 3:37 PM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> However, when new >> contributors see the nitpicking going on in reviews, I thi

[openstack-dev] [kolla][vote] Nit-picking documentation changes

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

[openstack-dev] [kolla] Using reno

Hey folks, Reno is in our master codebase and mitaka. Every new feature should use reno at the conclusion of the patch set. The full documentation is here: http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes In short, to create a reno note, just run pip install reno

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

ill leave docs patch after code merge, but well, we can take over >docs review. > >What do you think guys? I'd really like to keep high quality standard >all the way and don't scare off new commiters at the same time. > >Cheers, >Michal > >On 11 April 2016 at 03:50, Steven Dake

[openstack-dev] [kolla][ptl] Kolla PTL Candidacy for Steven Dake

My Peers, Kolla in Mitaka introduced many significant features, and in my opinion is the first version of Kolla to offer a fully functional deployment system. Our community has completely decoupled Kolla from various upstream releases of Docker>=1.10.0, resolved the data container data loss

Re: [openstack-dev] [kolla][release] Announcement of release of Mitaka rc1!

stack-dev] [kolla][release] Announcement of release of Mitaka rc1! Steve, Congratulations on the release!!! Regards, Daneyon On Mar 17, 2016, at 9:32 AM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: The Kolla community is pleased to announce the release of M

[openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

Technical Committee, Please accept my proposal of a new type of project called a deployment [1]. If people don't like the type name, we can change it. The basic idea is there are a class of projects unrepresented by type:service and type:library which are deployment projects including but

[openstack-dev] [kolla] Managing bug backports to Mitaka branch

Hi folks, Thierry (ttx in the irc log at [1]) proposed the standard way projects typically handle backports of newton fixes that should be fixed in an rc, while also maintaining the information in our rc2/rc3 trackers. Here is an example bug with the process applied:

[openstack-dev] [tc][deb][kolla][rpm] Introduce a new tag for type:packaging

Technical Committee, Thierry in this thread [1] suggested we need a type:packaging tag. Please accept my proposal for this work in this review [2]. Thanks! -steve [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090096.html [2] https://review.openstack.org/295972

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On 3/22/16, 2:15 AM, "Thierry Carrez" <thie...@openstack.org> wrote: >Steven Dake (stdake) wrote: >> Technical Committee, >> >> Please accept my proposal of a new type of project called a deployment >> [1]. If people don¹t like the type

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

On 3/23/16, 2:36 PM, "Steven Hardy" wrote: >On Wed, Mar 23, 2016 at 01:01:03AM +, Fox, Kevin M wrote: >> +1 for TripleO taking a look at Kolla. >> >> Some random thoughts: >> >> I'm in the middle of deploying a new cloud and I couldn't use either >>TripleO or Kolla for

[openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

Hey folks, These branches are essentially unmaintained and we have completely given up on them. That's ok - they were paths of our development. I didn't really want to branch them in the first place, but the community demanded it, so I delivered that :) Now that our architecture is fairly

[openstack-dev] [kolla] Gift from the OpenStack foundation

Hello core reviewers, If you will be at summit please attend one of our design or fishbowl sessions for gift distribution. If you have been in the past or currently are a core reviewer in the Kolla project and won't make summit, the foundation (or HP, not sure which) has a gift of nominal

Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent

26, 2016 at 7:10 PM To: "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent On 03/26/2016 12:2

Re: [openstack-dev] [magnum] High Availability

On 3/18/16, 12:59 PM, "Fox, Kevin M" wrote: >+1. We should be encouraging a common way of solving these issues across >all the openstack projects and security is a really important thing. >spreading it across lots of projects causes more bugs and security >related bugs

[openstack-dev] [kolla] [vote] Managing bug backports to Mitaka branch

We had an emergency voting session on this proposal on IRC in our team meeting today and it passed as documented in the meeting minutes[1]. I was asked to have a typical vote and discussion on irc by one of the participants of the vote, so please feel free to discuss and vote again. I will

Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

A majority was reached so closing voting early and removing these branches. Regards -steve From: Steven Dake > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

[openstack-dev] [ptl][kolla][release] Deploying the big tent

Hey fellow PTLs and core reviewers of those projects, Kolla at present deploys the compute kit, and some other services that folks have added over time including other projects like Ironic, Heat, Mistral, Murano, Magnum, Manilla, and Swift. One of my objectives from my PTL candidacy was to

[openstack-dev] Gating scripts in different TLD

Hey folks, Warning - this is pure gold plating :) I'd like to see our gating tools in the test directory, rather then the tools directory. I was thinking kolla/test/gate as the TLD for all gating related scripts. The work would be something like: Modify infrastructure gating to test for the

[openstack-dev] [kolla] gate failures

Currently the Kolla gate is completely busted. I have spent today fixing it here: https://review.openstack.org/#/c/297945/ What this means is any patch that has been submitted in abut the past 48 hours that has gate failures needs rechecks applied to it once the above merges. The above

Re: [openstack-dev] [Kolla] DocImpact in reviews

I don't think we can really expect new contributors to understand all the magic flags. This isn't a typical problem - typically DocImpact is used correctly. But it is the responsibility of the core reviewers to make sure that new contributors aren't needlessly wasting time by triggering

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

The vote is unanimous. Welcome to the core reviewer team Alicja! Ping me when you get online next and our timezone overlaps, and I'll walk you through the differences in the gerrit interface you should know. I have made appropriate changes in gerrit. Regards -steve From: Steven Dake

Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

Exceptions can always be rationalized which is one reason exceptions are evil among many. The facts however speak for themselves. If we don't have a way to introduce new content in liberty when CVEs are fixed, stable/liberty is just as flawed as the data loss problem which was the original

Re: [openstack-dev] [kolla][security][release] Obtaining the vulnerability:managed tag

in the codebase and working with the OpenStack VMT (vulnerability management team) to release the changes in a synchronized fashion. Regards, -steve On 3/1/16, 12:11 PM, "Steven Dake (stdake)" <std...@cisco.com> wrote: > > >On 3/1/16, 10:47 AM, "Tristan Cacquera

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

My position on this is simple. Operators are used to using specific distros because that is what they used in the 90s,and the 00s, and the 10s. Yes, 25 years of using a distro, and you learn it inside and out. This means you don't want to relearn a new distro, especially if your an RPM user

[openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

Hi folks, It was never really discussed if we would back-port upgrades to liberty. This came up during an irc conversation Friday [1], and a vote was requested. Tthe facts of the discussion distilled are: * We never agreed as a group to do back-port of upgrade during our back-port

Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

am +1 to get upgrades into Liberty, I hope this >makes sense. > >Regards, >-Paul > >[0] >http://lists.openstack.org/pipermail/openstack-dev/2015-December/081467.ht >ml > >On 07/03/16 16:00, Sam Yaple wrote: >> On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake)

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

are passionate about them. The issue also isn't about how difficult or not it is. The problem we want to avoid is spending precious time guaranteeing that new features and bug fixes make it through multiple distros. Corey On Fri, Mar 4, 2016 at 11:18 AM Steven Dake (stdake) <std...@cisco.com<

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

Core Reviewers, Alicja has been instrumental in our work around jinja2 docker file creation, removing our symlink madness. She has also been instrumental in actually getting Diagnostics implemented in a sanitary fashion. She has also done a bunch of other work that folks in the community

[openstack-dev] [kolla] Reminder our next meeting is 23:00 UTC

Reminder our next meeting is Wednesday at 23:00 UTC to accommodate APAC/US folks. This is a change from the past, where we only had meeting at 16:30 UTC. For more details see: https://wiki.openstack.org/wiki/Meetings/Kolla Regards, -steve

[openstack-dev] [kolla][security] Obtaining the vulnerability:managed tag

Core reviewers, Please review this document: https://github.com/openstack/governance/blob/master/reference/tags/vulnerability_managed.rst It describes how vulnerability management is handled at a high level for Kolla. When we are ready, I want the kolla delivery repos vulnerabilities to be

Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

The vote was not exactly unanimous. I counted the following: 1.1.0 Steven Dake +1 Paul Bourke +1 Martin Andre +1 Michal Rostecki -1 Jeff Peeler +1 Ryan Hallisey +1 Michal Rosteki -1 Michal Jasterzebski -1 Since there are 6 votes in favor out of the 11 person core review team, 1.1.0 will

[openstack-dev] [release][kolla] Announcing release of Kolla Mitaka rc3

Hey folks, We did a bangup job in the last 7 days fixing 25 bugs in Kolla. Our weekly capacity to solve bugs as a community is 25-30 bugs. Our final deadline is April 8th. Targeted for 2.0.0 (April 8tih) are currently 22 bugs. Many of these don't have owners, so if you want to contribute,

[openstack-dev] Announcing release of Kolla Mitaka rc3

Hey folks, We did a bangup job in the last 7 days fixing 25 bugs in Kolla. Our weekly capacity to solve bugs as a community is 25-30 bugs. Our final deadline is April 8th. Targeted for 2.0.0 (April 8tih) are currently 22 bugs. Many of these don't have owners, so if you want to contribute,

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

Graham, Responses inline. On 4/1/16, 8:50 AM, "Hayes, Graham" wrote: >>> On 3/31/16, 12:15 PM, "michael mccune" wrote: >>> > >>> one of the big questions seems to be who should be doing these analysis, especially given that the ossp

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

quot;OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO On Thu, 2016-03-31

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

On 4/3/16, 6:38 PM, "Dan Prince" wrote: > > > >On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote: >> As of the Liberty release, Magnum now supports provisioning Mesos >> clusters, so TripleO wouldn't have to maintain the installer for >> that >> either. (The choice of

[openstack-dev] [kolla] containers are a hot topic at the operator summit

Fellow Kolla developers, If you plan to be in Austin on Monday of OpenStack Summit week, there is a fantastic opportunity for us to receive feedback from Operators that Carol Barrett pointed out to me. The official Operator summit schedule is yet to be defined. The Operator summit planning

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

Yolanda, That is a fantastic objective. Matthieu asked why build our own images if the upstream images work and need no further customization? Regards -steve On 3/29/16, 1:57 AM, "Yolanda Robla Mota" wrote: >Hi >The idea is to build own images using

[openstack-dev] [election][tc] Annoouncing candidacy for the technical committee election

All My Peers, TL;DR - I will increase adoption of OpenStack by removing governance RED TAPE and mentoring individuals interested in these objectives. A brief history of time: I started my journey in OpenStack by doing a gap analysis of AWS to OpenkStack at my previous employer Red Hat,

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

locally cached in glance in each >of the clouds used by OpenStack infra. The local caching of the glance >images will produce much faster gate testing times. I don¹t care about >how the images are built, but we really do care about the performance >outcome. > >Adrian > >&g

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

Michal, We can't commit to that. We discussed it at midcycle and unable to commit to it then. We are essentially abandoning the 1.0.0 release and replacing it with 1.1.0 because of the documentation outlined here: http://docs.openstack.org/developer/kolla/liberty-deployment-warning.html If

Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

From: Jeffrey Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, March 30, 2016 at 12:29 AM To: "OpenStack

[openstack-dev] [kolla] IRC channel renamed to #openstack-kolla

See Subject. Note #kolla automatically redirects to openstack-kolla now, so if folks have #kolla in their client list, they will join #openstack-kolla if they have a recent IRC client. If your already in the channel leave and rejoin or restart your client and you will be connected with the

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

iner orchestration and containers, it should be pretty easy to do. While doing it with just packages would be very hard. Thanks, Kevin From: Steven Dake (stdake) Sent: Thursday, March 31, 2016 1:22:21 AM To: OpenStack Development Mailing List (not for usage que

Re: [openstack-dev] [kolla] Gift from the OpenStack foundation

On 3/28/16, 2:49 AM, "Thierry Carrez" <thie...@openstack.org> wrote: >Steven Dake (stdake) wrote: >> [...] >> If you have been in the past or currently are a core reviewer in the >> Kolla project and won't make summit, the foundation (or HP, not sure

Re: [openstack-dev] [kolla] Gift from the OpenStack foundation

quot; <thie...@openstack.org<mailto:thie...@openstack.org>> wrote: > > Steven Dake (stdake) wrote: >> >> [...] >> >> If you have been in the past or currently are a core reviewer in the >> Kolla project and won't make summit, the foundation (or HP, not sur

[openstack-dev] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag

Please see my review here as requested in this thread [1]: https://review.openstack.org/300698 The purpose of this review is two fold: 1. Permit sponsoring companies of single vendor projects or projects with low company affiliation diversity to allow their own security experts to sign

[openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

Technical Committee, Please accept my change prior to our April 8th deadline for tagging Mitaka 2.0.0 of Kolla. To be clear, this is a clunky workaround but I feel as though we are not permitted to participate in the marketing that takes place on the releases website, and this is the lesser

[openstack-dev] [ptl] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag

Apologies for not copying the [ptl] tag, since this change affects mostly the PTLs and the projects for which they facilitate. Note PTL's the purpose of this change is to make your lives easier and streamline the VMT application process, but keep the spirit of the original requirement in

Re: [openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

On 4/2/16, 10:01 AM, "Jeremy Stanley" <fu...@yuggoth.org> wrote: >On 2016-04-02 16:13:28 +0000 (+0000), Steven Dake (stdake) wrote: >[...] >> I feel as though we are not permitted to participate in the >> marketing that takes place on the releases website >

Re: [openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

A big correction to this thread below. On 4/2/16, 10:05 AM, "Steven Dake (stdake)" <std...@cisco.com> wrote: > > >On 4/2/16, 10:01 AM, "Jeremy Stanley" <fu...@yuggoth.org> wrote: > >>On 2016-04-02 16:13:28 + (+), Steven Da

Re: [openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing

On 4/2/16, 1:08 PM, "Doug Hellmann" <d...@doughellmann.com> wrote: > >> On Apr 2, 2016, at 1:20 PM, Steven Dake (stdake) <std...@cisco.com> >>wrote: >> >> A big correction to this thread below. >> >> On 4/2/16, 10:05 AM, "Stev

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

On 4/4/16, 5:53 AM, "Dan Prince" <dpri...@redhat.com> wrote: >On Mon, 2016-04-04 at 02:31 +, Steven Dake (stdake) wrote: >> >> On 4/3/16, 6:38 PM, "Dan Prince" <dpri...@redhat.com> wrote: >> >> > >> >

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

The vote is unanimous in favor of Vikram joining the core reviewer team. I have made the appropriate permission changes in gerrit. Welcome to the core reviewer team Vikram! Regards -steve From: Steven Dake > Reply-To: "OpenStack Development Mailing

[openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty within the Liberty branch

Dear cores, inc0 has been investigating our backport options for 1.1.0 and they look bleak. At this time we would have to backport heka because of changes in Docker 1.10.z which are incompatible with the syslog dev file. We had originally spoken about just taking Mitaka and placing it in

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

On 3/22/16, 2:15 AM, "Thierry Carrez" <thie...@openstack.org> wrote: >Steven Dake (stdake) wrote: >> Technical Committee, >> >> Please accept my proposal of a new type of project called a deployment >> [1]. If people don¹t like the type

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

From: Jesse Pretorius > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Tuesday, March 22, 2016 at 7:40 AM To: "OpenStack

Re: [openstack-dev] [kolla] branching Mitaka March 21, 2016 (important note for CRs)

From: Steven Dake > Reply-To: "openstack-dev@lists.openstack.org" > Date: Monday, March 21, 2016 at 9:02 AM To:

Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

Including tc and kolla Michael, Sounds good. I'll get the governance changes rolling for debate at the next TC meeting. Note I added this cross project topic for discussion Tuesday at summit (last item in the list) https://etherpad.openstack.org/p/newton-cross-project-sessions Regards, -steve

Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

Responses inline. From: Sergey Lukjanov > Reply-To: OpenStack Development Mailing List > Date: Friday, April 22, 2016 at 11:17 AM To: OpenStack Development Mailing

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

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. Regards -steve On 4/22/16, 8:01 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote: >On 2016-04-23 00:08:03 +0000 (+0000),

[openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

Fellow Core Reviewers, Since many of the engineers working on the kolla-mesos repository are moving on to other things[1], possibly including implementing Kubernetes as an underlay for OpenStack containers, I propose we move the kolla-mesos repository into the attic[2]. This will allow folks

[openstack-dev] [kolla] Meetup in Salon B - split between Magnum and Kolal

Hey folks, The meet up room for this morning is split between two rooms so we will be sharing a room in Salon B. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

On 4/24/16, 10:05 PM, "Tomasz Pa" <ss7...@gmail.com> wrote: >On Sat, Apr 23, 2016 at 2:27 AM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> >> Trying to understand the issue here, do you believe the current jinja2 >> Dockerfiles are not re

Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

Tomasz, Response inline. On 4/25/16, 12:32 AM, "Tomasz Pa" wrote: >On Mon, Apr 25, 2016 at 5:51 AM, Jeffrey Zhang >wrote: >> >> I do not think this is the issue of Kolla. It is a issue of Docker >> images. All the docker images has such issue. This

Re: [openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes

On 4/23/16, 1:26 PM, "Jay Pipes" <jaypi...@gmail.com> wrote: >On 04/22/2016 08:27 PM, Steven Dake (stdake) wrote: >> * Repository per OpenStack and Infra component, e.g. one from nova, >> one for neutron and etc. - to contain all needed container images &

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

Hey folks, This vote passed with 8 core reviewers +1ing the retirement of the kolla-mesos repository. As such I will submit patches in the following week to retire this project and remove it from the technical committee's governance repository for the Kolla Project. Regards -steve From:

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

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

Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

This should be obvious to core reviewers, but for Mauricio to join the core reviewer team, there must be no veto votes and a majority of +1s. Apologies for leaving that out. Regards -steve From: Steven Dake > Reply-To:

[openstack-dev] [kolla][security] Finishing the job on threat analysis for Kolla

Rob and Doug, At Summit we had 4 hours of highly productive work producing a list of "things" that can be "threatened". We have about 4 or 5 common patterns where we follow the principle of least privilege. On Friday of Summit we produced a list of all the things (in this case deployed

Re: [openstack-dev] [kolla] How to contribute to kolla

Hu, I'd recommend joining irc and asking on #openstack-infra. They can help you live debug your connection to gerrit. I have also seen Qiming's response, which may or may not help. Regards -steve From: "hu.zhiji...@zte.com.cn"

[openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer

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

[openstack-dev] [kolla] Prepare for Ansible 2.0

Hey folks, As distros move to Ansible 2.0 and Ansible 1.9 is unsupported by upstream and essentially unmaintained, I suggest we move Kolla to Ansible 2.y series. The blueprint is here: https://blueprints.launchpad.net/kolla/+spec/ansible2 I'm not sure if Jeffrey is actively working on this,

[openstack-dev] [kolla] Newton Milestone #1 and #2 obectives

Hey OpenStackers, I'd like to point out a few commitments made at OpenStack summit during various discussions among the community. Our direction (if your looking for work to do ;) should be the following: * Ansible 2.0 implementation. * Making the dashboard load automated. *

Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes

Tom, Devil's advocate here.. :) Can you offer examples of other OpenStack API services which behave in this way with a API? I'm struggling to think of any off the top of my head, but admittedly don't know all the ins and outs of OpenStack ;) Thanks -steve On 5/16/16, 2:28 AM, "Cammann,

Re: [openstack-dev] [kolla] [bifrost] bifrost container poc update

From: "Mooney, Sean K" > Date: Friday, May 13, 2016 at 2:14 PM To: "OpenStack Development Mailing List (not for usage questions)" >, Steven Dake

Re: [openstack-dev] [kolla] Vagrant environment for kolla-kubernetes

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

Re: [openstack-dev] [kolla][gate] Add a gating check job for precheck

Hui, I am planning to add a general gating blueprint with work items for the 24 gates we identified. Just g o ahead and get started and I'll have the gate blueprint ready to go by tomorrow. Regards -steve On 5/2/16, 8:41 PM, "Hui Kang" wrote: >Fellow kolla developers,

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

gt;difficult to pull them apart. > >The images, ansible, and k8n need to be separate. The alternative is not >scalable. > >Thanks, >-Paul > >On 03/05/16 00:39, Angus Salkeld wrote: >> On Mon, May 2, 2016 at 7:07 AM Steven Dake (stdake) <std...@cisco.com >&

[openstack-dev] [kolla][kubernetes] How to join the core team of kolla-kubernetess

Hey folks, A lot of folks have signed up as developers for kolla-kubernetes in the spec, but one thing that hasn't been discussed in much detail is how to join the core reviewer team. To do that, simply provide one (or preferrably a bunch) of reviews on the kolla-kubernetes spec. This will

Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean, Thanks for taking this on :) I didn't know you had such an AR :) From: "Mooney, Sean K" > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [kolla] xenial or trusty

On 5/6/16, 8:32 AM, "Emilien Macchi" wrote: >On Fri, May 6, 2016 at 9:09 AM, Jesse Pretorius > wrote: >> On 4 May 2016 at 19:21, Emilien Macchi wrote: >>> >>> On Wed, May 4, 2016 at 1:52 PM, Jeffrey Zhang

[openstack-dev] [kolla] rax-ord misbehaving in the gate

Hey folks, We really need to solve rax-ord in the gate. For awhile it was removed because consistently across openstack this gate jobs were failing. Does anyone have any idea why it is failing in the Kolla case? Thanks -steve

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

On 5/1/16, 1:23 PM, "Ryan Hallisey" wrote: >snip >Trust isn't the issue here. The spec that people signed up for says >"Create kolla-kubernetes repo". > >In this thread there seems to be two votes. One is the split repo >discussion Kolla had at summit. The second is to

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

f a separate repo. But also core's are welcome to chime in. Regard -steve On May 1, 2016 4:06 PM, "Steven Dake (stdake)" <std...@cisco.com<mailto:std...@cisco.com>> wrote: Ryan had rightly pointed out that when we made the original proposal 9am morning we had asked folks if t

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

convince me having these orchesetration engines in separate repos are a good idea. :) Regards -steve > >-Ryan > >- Original Message - >From: "Steven Dake (stdake)" <std...@cisco.com> >To: "OpenStack Development Mailing List (not for usage questions)"

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

Ryan had rightly pointed out that when we made the original proposal 9am morning we had asked folks if they wanted to participate in a separate repository. I don't think a separate repository is the correct approach based upon one off private conversations with folks at summit. Many people

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

arate repo's >much or is the majority of the work in the end going to be focused there? >If most of the code ends up landing there, then its probably not worth >splitting? > >Thanks, >Kevin > >From: Steven Dake (stdake) [std...@cisco.com

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

ded/reasonable. This should be done >regardless of if there are 1or 2 repo's in the end. > >Thanks, >Kevin >________ >From: Steven Dake (stdake) [std...@cisco.com] >Sent: Monday, May 02, 2016 11:14 AM >To: OpenStack Development Mailing List (no

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

uot; <jpee...@redhat.com> wrote: >On Sun, May 1, 2016 at 5:03 PM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> I don't think a separate repository is the correct approach based upon >>one >> off private conversations with folks at summit. Many people f

[openstack-dev] [kolla][kubernetes] kolla-kubernetes underway

Hey folks, There was a majority vote result on the separate repository vote and as a result voting was closed early. We have voted to proceed with a separate repository for kolla-kubernetes. The kolla-kubernetes repository is in progress of creation and being added to the governance

<    1   2   3   4   5   6   7   8   >