[openstack-dev] [kolla][release] Infrastructure mailing list thread about how to handle our stable/liberty branch

Hey folks. Our stable/liberty branch is essentially broken beyond repair because of a fatal flaw in our usage of data containers. We have fixed this in Mitaka using named volumes. Our plan is to make Liberty equivalent to Mitaka and then make stable/liberty deploy Liberty. It will require

[openstack-dev] [kolla][ssecurity] Threat Analysis Design Session

Hey Folks, I've scheduled the Threat Analysis Design session on Thursday 11:50-12:30 in room MR415A. This slot was the best slot I could find that didn't conflict with any security projects. If the security team has a conflict with this slot that I didn't see or am unaware of, please speak

[openstack-dev] [release][kolla] Release of kolla 2.0.0.0rc4

Hey folks, We had originally planned to release 2.0.0 today but there are a few more bugs left to resolve before our final tag. Hence, we made a decision to move the final 2.0.0 release to Thursday, April 21st. I am super pleased to announce the release of 2.0.0.0 rc4 which fixes 37 bugs,

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

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

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

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

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

[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] [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] [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, 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 >

[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

[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

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

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

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

[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

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

[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

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

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

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

[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

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

[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

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

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

[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

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

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

[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

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

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

The Kolla community is pleased to announce the release of Mitaka milestone RC1. This may look like a large list of features, but really it was finishing the job on 1 or 2 services that were missing for each of our major blueprints for Mitaka. Mitaka RC1 Features: * MariaDB lights out

[openstack-dev] [kolla][security][tc] Next steps for Kolla vulnerability:managed tag

The Technical Committee, Please see this review which offers threat analysis as an option for the vulnerability:managed tag: https://review.openstack.org/#/c/294212/ Kolla coresec team: In this IRC meeting on Security, I requested an audit, and the security team came back with a threat

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

Re: [openstack-dev] [kolla] [infra] Size of images built in the gate

.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] [infra] Size of images built in the gate Steve, overlayfs does not reduce the disk usage at all Paul, we can bump the size of the docker mountpoint up to ~20GB if you check all the gates for the approp

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

the choice. Such criteria will be subject to community consensus. This should allow for free experimentation with alternates to allow for innovation. See how this is not locking in a single OS vendor? Adrian On Mar 14, 2016, at 12:41 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std.

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

awei.com>> wrote: From: Adrian Otto [mailto:adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>] Sent: March-04-16 6:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro St

Re: [openstack-dev] [kolla] [infra] Size of images built in the gate

Vikarm, /var/lib/docker is a btrfs filesystem. It would be nice to just use overlayfs as it doesn't take nearly as much disk space and is much faster then btrfs. I use overlay daily and it works like a champ unless I want to rebuild, in which case I think a bug in the ovl yum plugin prevents

[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] Mitaka release schedules and priorities - only 30 days left!

Hi Koala Bears! The release candidate schedules are as follows: We are in feature freeze. No new features in Kolla until after Mitaka is released on April 4th-April 8th. We may lag this date a little bit depending on the state of the tarballs repo for build from source, or we may just tag

[openstack-dev] [kolla][release] Announcing Kolla Mitaka-3 milestone release \o/

Fellow OpenStackers, The Kolla community is pleased to announce the release of Mitaka milestone #3. Angus Salkeld has agreed to be our release manager for the kolla-mesos repository. As an aside, we held our midcycle during mitaka-3 development, for which the notes can be found here:

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

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][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] 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] 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)

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

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

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] [kolla][security] Obtaining the vulnerability:managed tag

ith vulnerability management process of Kolla and become a member of Kolla VMT team. I have experience and expertise in IT security and related to it processes. Best regards, Adam On Tue, Mar 1, 2016 at 5:55 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wro

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

e responsive about private >security bug to confirm the issue and discuss the scope of any >vulnerability along with potential solutions. > > > >> Thanks, >> -Ryan >> >> - Original Message - >> From: "Steven Dake (stdake)" <std...@cisc

[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] unblocking the gate

On 2/29/16, 12:26 AM, "Andreas Jaeger" <a...@suse.com> wrote: >On 2016-02-29 06:59, Steven Dake (stdake) wrote: >> Hey folks, >> >> It should be obvious that commiters should be testing their changes, but >> unfortunately this is not always the

Re: [openstack-dev] [kolla] unblocking the gate

The gate is still blocked apparently by yet another gate-breaking regression. That regression is resolved in this change set: https://review.openstack.org/#/c/285875/ Please rebase once that hits green and hits the repository. From: Steven Dake >

[openstack-dev] [kolla] unblocking the gate

Hey folks, It should be obvious that commiters should be testing their changes, but unfortunately this is not always the case. With the recent state of the gate relating to the introduction of Docker 1.10.z breaking the gate for 1 week followed by a keystone change upstream breaking the gate

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

Angus, You received 7 +1 votes with no veto votes in the voting window and we require 6 votes or more to join the core team at the time you were proposed. As a result, I have removed you from kolla-mesos-core and added you to kolla-core. Welcome to the core reviewer team! Regards -steve

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

it needs to be injected into our post jobs without us having to check our credentials into the repository. Regards -steve On 2/23/16, 9:58 AM, "Steven Dake (stdake)" <std...@cisco.com> wrote: >Ricardo, > >Apologies in lag, I remember reading your email but not answerin

Re: [openstack-dev] [kolla] New Meeting Times altrernating 16:30 and 23; 00 UTC.

> in #openstack-meeting-4 (IRC webclient<https://webchat.freenode.net/?randomnick=1=%23openstack-meeting-4=1=d4>) On Wed, Feb 24, 2016 at 8:50 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: Hey folks, We agreed some time ago to be more inclusiv

[openstack-dev] [kolla] New Meeting Times altrernating 16:30 and 23; 00 UTC.

Hey folks, We agreed some time ago to be more inclusive and have an APAC/US meeting. I am happy to announce that work has completed. Please see: http://eavesdrop.openstack.org/#Kolla_Team_Meeting >From there you can download an ical file which will insert directly into your >calendar for

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

ace, >> do you have an estimate of storage needed? >> >> Regards >> >> 2016-02-20 14:21 GMT+01:00 Steven Dake (stdake) <std...@cisco.com>: >>> >>> Infra folks, >>> >>> I'd like to see a full CI/CD pipeline of Kolla to an OpenSt

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On 2/22/16, 10:13 AM, "Jeff Peeler" <jpee...@redhat.com> wrote: >On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> The issue isn't about reviewing patches in my opinion. Obviously people >> shouldn't jam patches

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Hi folks, I thought long and hard as how to not make this an exception and came up with the following. I would be in favor (+1) of this particular feature addition, on the conditions that: 1. This does not set a precedent that features will be backported by the typical +2/+2/+W 2. Any

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

1:13 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company Le 20 févr. 2016 18:

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

lt;openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company On 20 February 2016 at 12:58, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

following: * the union of the memberships of the core review teams associated with the git repositories managed by the team > >I will show myself out now, ha. > >-Josh > >On 02/20/2016 09:09 AM, Steven Dake (stdake) wrote: >> Hey folks, >> >> Mirantis

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

2 cores from the same company cannot +2 the same patch, but again i am against such things personally.. Disclaimer: i am not personally involved in Kolla or know how things are running there. On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>

[openstack-dev] [kolla] discussion about core reviewer limitations by company

Hey folks, Mirantis has been developing a big footprint in the core review team, and Red Hat already has a big footprint in the core review team. These are all good things, but I want to avoid in the future a situation in which one company has a majority of core reviewers. Since core

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

these nice stuff, I'd be happier person;) Cheers, Michal On 20 February 2016 at 07:40, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: > Just clarifying, this is not a "revote" - there were not enough core > reviewers in favor of this idea at the K

[openstack-dev] [kolla] Metting schedule changes - next IRC meeting at 16:30 UTC!

Hi folks, With this review[1] our meeting times have been changed as follows based upon a community vote[2] of the best US/APAC time: Our US/EMEA meeting time remains unchanged. We don't have a EMEA/APAC meeting because there is not enough core reviewers to hold such a meeting. Even work

Re: [openstack-dev] [kolla]

Wade, My guess is you have six installed via both pip and RPM and they are different versions. If you want help, join us on irc on #freenode, and we can get you going. Its much faster then debugging over a mailing list. Regards -steve From: Wade Holler

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

Michal, I want to make sure we fix all of the problems, not just the timezone issue (which in progress by the apac friendly meeting). On 1/15/16, 4:38 AM, "Michal Rostecki" wrote: >Hi, > >Currently we're discussing stuff about kolla-mesos project on kolla IRC

<    1   2   3   4   5   6   7   8   >