ecember 14, 2016 at 3:22 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla][tc] Video Meetings - input requested
On Wed, Dec 14, 2016 at 3:33 PM, Thierry Carrez
wrote:
> Ed Leafe wrote:
>> On Dec 12, 2016, at
The issue raised is they violate the 4 opens.
From: Michał Jastrzębski
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Monday, December 12, 2016 at 8:09 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla][t
Jeffrey,
I think a better balance among the core reviewer teams for the 3 core
reviewer teams we have for our 3 deliverables is warranted as you stated.
To clarify my position, I am happy to train individuals on how to manage
Launchpad, even one on one for our core reviewers that don’t know h
Hey folks,
Jeffrey delegated to me to determine the tagging structure for
kolla-kubernetes. I was under the mistaken impression we need to tag 1.0.0
with the milestone tags (such as 1.0.0.0b2/1.0.0.0b3) for kolla-kubernetes.
That is not the case. We will be tagging 0.4.0 next, then 0.5.0, th
Thierry,
I personally prefer the meeting rooms as they are; however, we do need more of
them. I am often pinged in various other meetings in the common meeting
channels and find the group communication that happens in this way preferable
to joining each specific project channel. Joining each
Paul,
This is a good question probably best sent to the operators list. I’m not sure
also if operators know the difference in Kolla’s implementation. I don’t
believe Kolla’s documentation explains it particularly well.
I never wanted COPY_ALWAYS in the code base, but I tolerated it as COPY_ON
Jeffrey,
Can’t post inline (outlook bug).
kolla-kubernetes has no use-case for COPY_ALWAYS.
The kolla-kubernetes deliverable uses a construct called EmptyDir to store
configuration files.
There is no way to hand-modify the configuration files in EmptyDir that I am
aware of nor was any of the
Jeffrey,
The kolla-kubernetes deliverable requires COPY_ONCE not COPY_ALWAYS.
Some operators prefer immutability over hand-modification of configuration
files on all nodes.
Therefore, I propose we keep both in place.
Regards
-steve
From: Jeffrey Zhang
Reply-To: "OpenStack Development Mailin
Hello folks,
Michal (inc0) is the PTL of Kolla. He has asked me to send this message since
it was my agreement with the community in the Austin Design Summit when I
served as Kolla PTL that people that participate in the implementation of the
kolla-kubernetes deliverable at the start of the de
It’s not really about easy or hard.
We don’t want to make the gating less optimal then it was pre-repo split. To
achieve that objective, cross-repo gating is necessary to validate the images
in the docker repo are correct wrt the orchestration system they were developed
against originally (whi
+1 from me ☺
-Original Message-
From: Michał Jastrzębski
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, November 29, 2016 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [kolla] Vote to add
tions)"
Date: Monday, November 28, 2016 at 2:06 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla][release][requirements] providing
constraints for transitive dependencies
On Mon, Nov 28, 2016 at 08:15:17AM +, Steven
er-constraints.txt
>
> On Mon, Nov 28, 2016 at 10:41 AM, Steven Dake (stdake)
> wrote:
>
> > Hey folks,
> >
> >
> >
> > I get a lot of requests for variance reduction of transitive
dependencies
> > in Kolla’s
usage questions)"
Date: Sunday, November 27, 2016 at 9:42 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla][release][requirements] providing
constraints for transitive dependencies
On Mon, Nov 28, 2016 at 02:41:08AM +,
Hey folks,
I get a lot of requests for variance reduction of transitive dependencies in
Kolla’s containers. As an example, we build from source nova. Nova itself we
can specify a version to install in the containers during build time. Nova’s
python dependencies, not so much. Is there a best
Jeffrey,
Logstash-forwarder is deprecated upstream, so we can’t rely on that. Elastic's
replacement is filebeat.
I’m not sure which one meets the requirements – filebeat or fluentd. In
kolla-kubernetes fluentd is being used, and is well maintained. Both
implementations are pretty green IMO.
bit terrified to
change them ;)
It may be possible to solve this via a massive reorg that is well reviewed and
-2’ed until everything can merge in one go.
Regards
-steve
On 11/21/16, 5:43 AM, "Andreas Jaeger" wrote:
>On 2016-11-21 13:24, Steven Dake (stdake) wrote:
>&g
Pete,
The main problem with that is publishing docs to docs.oo which would then
confuse the reader even more then they are already confused by reading our docs
;)
Regards
-steve
From: Pete Birley mailto:pete@port.direct>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)
Yup this is a real challenge to sort out properly. I’ve included infra for
their guidance (thanks people :).
Here is the issue
Each package should include enough docs that it stands alone after a git
checkout (IMO). We also publish docs to docs.oo which should IMO contain one
set of docs for
You mean contributing doc? Sounds like a winner to me. I am really concerned
about how to sort out back ports as it relates to the repository split, and
documenting a best practice here makes a lot of sense (once we figure out what
that simple best practice is - which I think is covered in thi
Zhu,
This isn’t the first time this question has been asked :)
Since this is a technical matter, I’ve copied openstack-dev for a wider
audience. I don’t have a clear solution to obtaining version manifests for
container content or the upstream container version. Perhaps someone in our
broade
Can we stick to one tag [kolla] for all ML discussion? A whole slew of people
already have filters setup. Kolla is one project with one mission with
multiple deliverables. No other project that has multiple deliverables tags
emails per deliverable. I don’t think this is an occasion to be a s
+1
On 11/17/16, 2:50 AM, "Paul Bourke" wrote:
>+1
>
>On 17/11/16 07:18, Martin André wrote:
>> On Wed, Nov 16, 2016 at 7:23 PM, Michał Jastrzębski wrote:
>>> Hello,
>>>
>>> In light of recent events (kolla-kubernetes becoming thriving project,
>>> kolla-ansible being split) I feel we need to
Hey folks,
Thanks to the efforts of the openstyack-infra and release teams in coaching me
through how to do the job properly, the repo split is ready to go (requires a
couple +1’s from inc0 as he is the PTL of our merry band).
What this means is some patches that are merging now may have to be
Technical Committee,
Please consider the following review for inclusion in the governance repository
once Michal has +1’ed it:
https://review.openstack.org/#/c/396901/
Regards
-steve
__
OpenStack Development Mailing List (n
Thanks,
I have done exactly as you recommended.
Regards
-steve
On 11/12/16, 10:49 AM, "Andreas Jaeger" wrote:
>On 11/12/2016 11:15 AM, Steven Dake (stdake) wrote:
>> The proposal I think you made is what I was thinking we would do, so just to
>> clarify:
>>
more challenging in general with a repo split. The
core reviewers committed to maintaining back ports properly when they voted on
the repo split.
Regards
-steve
On 11/11/16, 7:43 AM, "Doug Hellmann" wrote:
>Excerpts from Steven Dake (stdake)'s message of 2016-11
eration is optional right? I mean, as far as kolla is
concerned - it doesn't *need* to generate the passwords... If
/etc/kolla/passwords.yml is created outside of kolla-genpwd, then kolla isn't
creating any credentials itself and the algorithm, entropy and policy is
transparent to
Ok,
Pavo has told me he has exceptions in place for everything related to Kolla.
He says as long as we don’t use MD5, he is good to go for a 232 node deploy
with more to follow (assuming Kolla works out of the box at that scale - we
have only tested 123 node scale).
We do some basic PRNG to g
Thanks Jeremy.
That is a hugely helpful piece of advice. I will include a link to your email
to make sure I’m doing it correctly when I split the repo.
Regards,
-steve
On 11/8/16, 8:24 AM, "Jeremy Stanley" wrote:
>On 2016-11-08 19:07:07 +0530 (+0530), Swapnil Kulkarni wrote:
>[...]
>>
On 11/8/16, 9:08 AM, "Doug Hellmann" wrote:
>Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
>> Hey folks,
>>
>> As we split out the repository per our unanimous vote several months ago, we
>> have a choice to make (
Hey folks,
As we split out the repository per our unanimous vote several months ago, we
have a choice to make (I think, assuming we are given latitude of the release
team who is in the cc list) as to which version to call kolla-ansible.
My personal preference is to completely retag our newly s
Doug,
As predecessor PTL for Kolla, I have followed your recommendations 1-4
including this ack, although I am not sure its really necessary for me. Note,
I am not sure Michal (inc0 on irc) wants me to continue as release liaison or
do the job himself, so that step has not yet been taken. I w
This may have got lost in the noise of the last few days of ml. As a result, I
am tagging with [vote]. I currently count 7 +1’s but again – lots of mailing
list traffic so I may be off on my counting.
For all core reviewers:
In the future to help inc0 out with tallying the votes for votes core
t projects wanting to use cryptography directly.
fwiw, i don't see a claim to support FIPS-140-2 in cryptography:
https://cryptography.io/en/latest/development/test-vectors/
https://github.com/pyca/cryptography/tree/master/vectors/cryptography_vectors/asymmetric/ECDSA
Thanks,
Dims
On Sun, Nov 6
"
Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto vs
cryptography
On 2016-11-06 08:05:51 +0000 (+), Steven Dake (stdake) wrote:
Currently Kolla uses pycrypto in our requirements. I see a lot of
big tent projects moving to cryptography. Is this just my
imagina
Requirements team,
Currently Kolla uses pycrypto in our requirements. I see a lot of big tent
projects moving to cryptography. Is this just my imagination, or was there a
decision on this from the requirements team? We are happy to comply with
whatever dep management is considered appropriat
Hey folks,
I’ve been on PTO the last week and made zero progress on the repo split. I
notice lots and lots of patches merging, which makes doing the repo split more
complex.
I am on the road to CloudNativeCon Nov7th-Nov9th. After I return on the 10th,
I’ll start the process of submitting the
tion will be to write GPL driver
that will be run with popen. Question is whether this driver can sit in Kolla
repo or not, and if not, where?
On Nov 4, 2016 6:51 PM, "Steven Dake (stdake)"
mailto:std...@cisco.com>> wrote:
Michal,
Have you read nothing I’ve said? If its new cod
Michal,
Have you read nothing I’ve said? If its new code, write it as ASL2.0. The
fact that it plugs in or uses GPLv3 code is totally irrelevant since it is
isolated by a network layer (specifically popen).
Regards
-steve
From: Michał Jastrzębski
Reply-To: "OpenStack Development Mailing Li
Clint,
I disagree that modules (which are really plugins) must be licensed under
GPLv3. You may license any module code as you like (i.e. ASL2.0) and include
it in a GPLv3 project via Ansible modules because the modules act as plugins.
The ASL2.0 license does taint, however, it does not matte
Cool.
I didn’t even know ansible had a BSD licensed example module. As we have a
module expertise in our community already, I suspect we will start from zero
code rather than introduce a BSD license addendum to the Kolla repo.
Regards
-steve
From: Jeremy Stanley
Reply-To: "OpenStack Develop
: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, November 4, 2016 at 3:50 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3
On 2016-11-04 22:22:47 +0000 (+),
Swapnil,
If you feel someone is lazy with not filing bugs for backports or feature
request, with a monster feature request or something that requires a backport,
simply -1 the review and add a polite comment “Please add a bug ID or
blueprint”.
Regards,
-steve
From: Swapnil Kulkarni
Reply-To
Paul,
I’ll take your request as a request for a vote of the core reviewers.
My vote is +1 in favor of removing the requirement for TrivialFix.
As per our standard policy, the voting window is open for 7 days beginning
November 3rd, and finishing (in 7 days) on November 11th.
Regards
-steve
F
Andreas,
Agree. Asked and answered. If Michal has some differing viewpoint, that’s his
prerogative as the PTL of Kolla, however, I would have serious concerns with
that model, and would request a vote of the core reviewers to solidify our
processes to match the OpenStack way.
Regards
-steve
Define “touching GPLv3 code”. If you mean using someone else’s work which
creates a derived work, that is a big no-no. This would cause your CL
If it’s a fresh implementation, then USE ASL2.0. This creates a transitive
dependency that taints the module on instantiation, however, since we use
Jeremy,
Kolla doesn’t want to be a special snowflake WRT patches. TrivialFix was
introduced to help core reviewers identify what bugs need backports vs which
changes do not or are feature changes (which we also don’t backport). We don’t
always get backport tracking correctly, but I think we a
The general rule I follow (and would propose we stick to) is is as follows:
If it requires a backport – it requires a bug id. (This is to facilitate the
tracking of backports to make sure we do the job correctly)
If it doesn’t require a backport but is a feature submission, it should include
a
Wrong answer. The correct answer is all software in the Kolla repository
should be ASL2.0 licensed. See legal list for a more thorough explanation
based upon the historical discussions I’ve been through with the TC and BOD on
this question. If it is GPLv3 licensed code, it should be implement
Forgot kolla tag in subject.
From: Steven Dake mailto:std...@cisco.com>>
Date: Friday, October 21, 2016 at 7:50 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: "Jastrzebski, Michal"
mailto:michal.jastrzeb...@intel.com>>
Subject
Folks,
Inline is the draft logo of the Kolla mascot and logo. We will be getting
various types of swag at the first PTG related to our mascot. The deadline for
feedback is November 11th, 2016. See the email inside from Heidi for more
information on our project mascots.
Super exciting!
Rega
Doug,
Kolla rc3 is available in the queue by the hard deadline (more or less). I
have a quick Q - would I need to submit another 3.0.0 patch with the same git
commit id, or does the release team do that automatically?
Regards
-steve
On 10/7/16, 12:16 PM, "Doug Hellmann" wrote:
>This wee
Folks,
We are in dire need of any help core reviewers can provide fixing the following
bug:
https://etherpad.openstack.org/p/kolla-bug-1631503
For everyone that submits a patch, please take responsibility to back port it
to stable/newton. This is a one click operation. Make sure not to back p
tions)"
Date: Friday, October 14, 2016 at 2:33 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements
supported by CentOS
Le 12 oct. 2016 6:01 AM, "Steven Dake (stdake)"
mailto:std...@ci
RC2 has been tagged. The stable/newton branch has been created. Master is
open for business! Core reviewers please remove any procedural -2’s you have
placed on reviews.
In RC3 of Kolla, we are fixing only critical bugs. All bugs in rc3 need to be
backported to stable/newton in order to tag
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Wednesday, October 12, 2016 at 12:51 AM
To: openstack-dev
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
Excerpts from Steven Dake (stdake)'s message of 2016-10-12 06:42:43
Tom,
No flame, just observation about the reality of these changes.
I think we missed this communication on the mailing list or in the FAQs or
somewhere else. I think most engineering-focused organizations are looking at
the PTGs only and not really considering the summit for budget planning.
Thomas,
Kolla does not use systemd fies (bifrost may be different here – I am not
certain). Kolla also does not use default configuration files that are shipped
with distros. We find this model to be disruptive to reliable development. I
get distros want to ship them and that’s fine by us.
Haikel,
We attempted removing EPEL from our repo lists. We got build errors on
cinder-volume. We have iscsi integration because vendors require it to work
with their third party plugins. The package iscsi-target-utils is not in the
newton repos for RDO.
The package that fails can be seen he
Hey folks,
Cross project initiative patches like this one:
https://review.openstack.org/#/c/383226/1
Should always be approved if they pass code review and the gate is green.
There is no need for a bug id or trivial fix or blueprint. Please do make sure
to verify they are correct and don’t al
harder time coming up with optimal
solutions because I lack the context the release team has.
Regards
-steve
From: "Steven Dake (stdake)"
Date: Friday, October 7, 2016 at 1:39 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-de
Doug,
We have already tagged rc1 long ago, but ack on rc2 (we are targeting 12th at
present) and ack on 20th for retag of final rc. We expect our rc2 to be final.
If there are critical bugs that make the release doa in some way (such as
upgrades, reconfigure etc), we will obviously have to ta
Hey folks,
Several people have asked for archives of the OSIC work we did. Those files
can be found here:
https://drive.google.com/drive/folders/0B8q6xDPETSkHc05fR21qeElpc2M?usp=sharing
Regards,
-steve
__
OpenStack Develop
e: Tuesday, October 4, 2016 at 4:46 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] TC candidacy
On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake)
mailto:std...@cisco.com>> wrote:
Emilen,
You say "the previous *PTL* of an Op
Emilen,
You say "the previous *PTL* of an OpenStack installation automation project" as
if there were only one previous PTL :) There are many previous PTLs of
OpenStack automation projects. I feel the question was directed at me, so I'll
answer.
From:
Also impacts Kolla (as in our gates are blocked). At present we are using the
proposed workaround until the pycparser 2.14 wheel and package are synced up.
Regards
-steve
From: Matt Riedemann
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Sunday, October 2, 2
My Peers,
I am self-nominating for serving you as your technical committee
representative.
I won't bore you with my professional accomplishments. If you want to
see such information to judge if I'm qualified for serving you on the
technical committee team, that information is available in my
fou
re...@betacloud-solutions.de>> wrote:
> On 29 Sep 2016, at 06:26, Steven Dake (stdake)
> mailto:std...@cisco.com>> wrote:
>
> If you have a different parsing of the deprecation policy, feel free to
> chime in.
Heka is only used as an internal component of Kolla and is not p
First off, apologies for missing most of the team meeting today. I have read
through the logs and saw a discussion about deprecating heka. We need to
ensure that we follow the deprecation policy. My understanding of the
deprecation policy is as follows (in a nutshell):
1. We must mail
e been stable. Dane and I have resolved the problems
with the load balancer at least for the LBaaS v1. For LBaaS v2, we need to
build a new image with Kubernetes 1.3 and we just got one built today.
Ton,
[nactive hide details for "Steven Dake (stdake)" ---09/27/2016 10:18:07
PM]"S
Dane,
I’ve heard Yolanda has done good work on making disk image builder build fedora
atomic properly consistently. This may work better than the current image
building tools available with atomic if you need to roll your own. Might try
pinging her on irc for advice if you get jammed up here.
ack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to
deploy OpenStack on k8s
On 23/09/16 17:47 +, Steven Dake (stdake) wrote:
Flavio,
Forgive the top post and lack of responding inline – I am dealing with
Sam is correct here. This is the why behind the how ☺
Regards
-steve
From: Sam Yaple
Reply-To: "s...@yaple.net" , "OpenStack Development Mailing
List (not for usage questions)"
Date: Monday, September 26, 2016 at 7:43 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Sub
4:23 AM, Davanum Srinivas
mailto:dava...@gmail.com>> wrote:
> Steven,
>
> Fair point.
>
> Thanks,
> Dims
>
> On Thu, Sep 22, 2016 at 11:04 PM, Steven Dake (stdake)
> mailto:std...@cisco.com>>
> wrote:
> > Dims,
> >
> > This isn’t any of my pa
Stack Development Mailing List (not for usage questions)"
Date: Friday, September 23, 2016 at 11:43 AM
To: "openstack-dev@lists.openstack.org"
Subject: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to
deploy OpenStack on k8s
On 09/23/2016 01:04 PM, Steven Dake (s
ct: Re: [openstack-dev] [kolla][fuel][tripleo] Reference architecture to
deploy OpenStack on k8s
On 22/09/16 20:55 +, Steven Dake (stdake) wrote:
Flavio,
Apologies for delay in response – my backlog is large.
Forgive me if I parsed your message incorrectly.
It's probably me failing to
Bogdan,
I recognize English isn’t your first language, so forgive me if I have
mis-parsed your message. I think the question you are asking is “Can we have
cooperation to standardize on how best to do OpenStack on Kubernetes”. We
tried an analog of that with Mirantis around Mesos, and that re
Dims,
This isn’t any of my particular business except it could affect emerging
technology projects (which I find important to OpenStack’s future) negatively –
so I thought I’d chime in.
A lack of activity in a specs repo doesn’t mean much to me. For example, as
Kolla was an emerging project w
Lu,
The kolla documentation specifically states Newton has a pin on ansible <
2.0.0.0
From: "lu.yao...@zte.com.cn"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, September 22, 2016 at 5:41 AM
To: "openstack-dev@lists.openstack.org"
Subject: [openstac
Flavio,
Apologies for delay in response – my backlog is large.
Forgive me if I parsed your message incorrectly. It came across to me as “How
do I blaze a trail for OpenStack on Kubernetes?”. That was asked of me
personally 3 years ago which led to the formation of the Kolla project inside
Re
>> decision making process.
>>
>>
>>
>> Regards
>>
>> -steve
>>
>>
>>
>>
>>
>> From: Mathias Ewald
>> Reply-To: "OpenStack Development Mailing List (not
OpenStack summit planning team,
We have been planning summit for approximately 2-3 months here:
https://etherpad.openstack.org/p/kolla-O-summit-planning
We further codified this into a vote via civs:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_8368e1e74f8a0049
As you can see from the prel
Folks,
We want to be inviting to new contributors even if they are green. New
contributors reflect on OpenStack’s growth in a positive way. The fact that a
new-to-openstack contributor would make such and error doesn’t warrant such a
negative response even if it a hassle for the various PTLs
em. Let see how priorities will
look like after couple days:)
Also, please vote!
On 21 September 2016 at 12:54, Swapnil Kulkarni wrote:
> On Wed, Sep 21, 2016 at 11:16 PM, Steven Dake (stdake)
wrote:
>> One note in this poll. Repo-split has already reached a co
other policies (i.e. project maturity
tags) in OpenStack because of this decision, that information would be helpful
as well.
Thanks!
-steve
On 9/19/16, 6:51 AM, "Doug Hellmann" wrote:
Excerpts from Thierry Carrez's message of 2016-09-18 16:08:04 +0200:
> Steven D
One note in this poll. Repo-split has already reached a consensus decision via
ml vote, and the activity around that will happen prior to summit, so it is
probably worth ignoring entirely.
Regards
-steve
On 9/21/16, 10:14 AM, "Michał Jastrzębski" wrote:
Hello,
Now, when we have
On 9/20/16, 11:18 AM, "Haïkel" wrote:
2016-09-19 19:40 GMT+02:00 Jeffrey Zhang :
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> B
: Tuesday, September 20, 2016 at 7:25 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro support
Option 2
2016-09-20 16:07 GMT+02:00 Steven Dake (stdake)
mailto:std...@cisco.com>>:
Con
Sam,
Can this meeting instead be held in the normal openstack-meeting-1 -> 4
channels? Having one-off meetings in #openstack-networking-cisco is totally
fine. Having standing team meetings there is atypical of OpenStack projects.
The main value of using the opentack-meeting-1-4 channels is t
ot;
Date: Tuesday, September 20, 2016 at 7:25 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro support
Option 2
2016-09-20 16:07 GMT+02:00 Steven Dake (stdake)
mailto:std...@cisco.co
Consider this a reversal of my vote for Debian deprecation.
Swapnil, thanks for bringing this fact to our attention. It was missing from
the original vote. I don’t know why I didn’t bring up Benedikt’s contributions
(which were substantial) just as Paul’s were substantial for Oracle Linux. I
Fwiw Swapnil, I think having a solid fedora implementation would be fantastic
to help manage the transition to centos8 whenever that happens. At this point
nobody has stepped up to do the work. We can always revisit any policy or vote
in the future if the environment changes (i.e. you are free
I disagree. Oracle Linux is well implemented and very well maintained by Paul
Bourke and many other fine folks from Oracle. CentOS is derived from RHEL
(changing trademarks and marketing fluff, not code).
Regards
-steve
From: Dave Walker
Reply-To: "OpenStack Development Mailing List (not for
+1 for option #2 with same commentary as prior relating to fedora.
Regards
-steve
On 9/19/16, 10:44 AM, "Jeffrey Zhang" wrote:
Kolla core reviewer team,
Kolla supports multiple Linux distros now, including
* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* O
+1 for option 2, unless some good Fedora folk appear in Kolla to maintain it in
the future. In that case, we can always undo a deprecation within a cycle.
Note the deprecation policy states that we do not remove functionality for 1
cycle after having released it for stable deliverables. Even t
Thierry,
Cool wfm.
Thanks
-steve
On 9/18/16, 7:08 AM, "Thierry Carrez" wrote:
Steven Dake (stdake) wrote:
> Release team,
>
> At one point Doug had indicated all projects would automatically branch
> on tagging of rc1. I notice in git no Koll
Hui,
Change is what you will see as I am not running for PTL for Ocata.
Reference:
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103499.html
Regards
-steve
On 9/14/16, 4:32 PM, "Hui Kang" wrote:
+1 for Jeffrey Zhang
- Jeffrey is full time on Kolla
- St
Release team,
At one point Doug had indicated all projects would automatically branch on
tagging of rc1. I notice in git no Kolla stable/newton branch exists. Fwiw
this is actually a good thing, because 33 patches have merged since rc1
relating to things that need to go into Newton, dramatical
Christian,
While the vote was not unanimous, a strong majority of core reviewers were in
favor of our nomination with no veto in the voting period. I know the two core
reviewers that did not vote are travelling so perhaps they missed the vote.
Welcome to the core review team! I attempted to m
101 - 200 of 748 matches
Mail list logo
