Hi Team,
Due to there is no topic to be discussed, I suggest to cancel the meeting.
B.R.,
Zhijiang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
On 6 Jan 2017, at 05:04, Rabi Mishra
> wrote:
On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi
> wrote:
Greetings Heat folks!
My question is simple:
When do you plan to support Glance v2?
Dear Team
Base on suggestions
We open a simple doodle to collect opinions.
http://doodle.com/poll/fns89s3ee4za3saw
Please help to pick the better question in your mind.
Let's voting till the end of this Friday (for everyone!)
2017-01-05 1:06 GMT+08:00 Rico Lin :
> Dear
On Thu, Jan 5, 2017 at 10:28 PM, Zane Bitter wrote:
> On 05/01/17 11:41, Crag Wolfe wrote:
>
>> Hi,
>>
>> I have a patch[1] to support the de-duplication of resource properties
>> data between events and resources. In the ideal rolling-upgrade world,
>> we would be writing
On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi wrote:
> Greetings Heat folks!
>
> My question is simple:
> When do you plan to support Glance v2?
> https://review.openstack.org/#/c/240450/
>
> The spec looks staled while Glance v1 was deprecated in Newton (and v2
> was
I think you’re giving a great example of my point that we’re not yet at the
stage where we can say, “Any tool should be able to deploy kolla containers”.
Right?
From: Pete Birley
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
I'll reply to Britts comments, and then duck out, unless explicitly asked
back, as I don't want to (totally) railroad this conversation:
The Kolla containers entry-point is a great example of how the field have
moved on. While it was initially required, in the Kkubernetes world the
Kolla ABI is
Hi all,
Vitrage generate alarms acording to the templates. All the alarms raised by
vitrage has the type "vitrage". Suppose Nagios has an alarm A. Alarm A is
raised by vitrage evaluator according to the action part of a scenario, type of
alarm A is "vitrage". If Nagios reported alarm A
Hi all,
I have a question when learnning vitrage:
A, B, C, D, E are alarms, consider the following alarm propagation model:
A --> B
C --> D
B or D --> E
When alarm E is reported by the system, from the above model, we know that
I think both Pete and Steve make great points and it should be our long term
vision. However, I lean more with Michael that we should make that a separate
discussion, and it’s probably better done further down the road. Yes, Kolla
containers have come a long way, and the ABI has been stable
We agreed in the nova meeting today to hold a feature review sprint next
Wednesday 1/11.
We'll be going through the unmerged changes in
https://etherpad.openstack.org/p/nova-ocata-feature-freeze and try to
push some of those through, or get them close.
If you have a blueprint series in that
Just some heads-up for those who were interested by removing Glance
Registry from TripleO (yes Flavio, I'm looking at you !).
Because TripleO relies on Heat for the pingtest (validation that
OpenStack cloud is up and running) and because Heat doesn't support
Glance v2 API [1], we strongly rely on
Also coming from the perspective of a Kolla-Kubernetes contributor, I am
worried about the scope that Kolla is extending itself to.
Moving from a single repo to multiple repo's has made the situation much
better, but by operating under a single umbrella I feel that we may
potentially be
Greetings Heat folks!
My question is simple:
When do you plan to support Glance v2?
https://review.openstack.org/#/c/240450/
The spec looks staled while Glance v1 was deprecated in Newton (and v2
was started in Kilo!).
As an user, I need Glance v2 support so I can remove Glance Registry
from my
Heads up folks! Just sending out a friendly reminder that tomorrow will be
our first office hour session of the new year.
See everyone in #openstack-keystone tomorrow!
On Wed, Dec 21, 2016 at 5:32 PM, Rodrigo Duarte
wrote:
> Thanks for the initiative! This is something
There are some interesting points in this topic. I agree entirely with Sam
Yaple. It does not make sense to me to have kolla-ansible and
kolla-kubernetes cores involved with the introduction of a new deliverable
under the kolla umbrella. A new deliverable (read: project, really) should
not rely
Happy New Year, everyone!
Focus
-
Feature work and major refactoring should be well under way as we
approach the third milestone and various feature and release freeze
dates.
The deadline for non-client library releases is R-5 (19 Jan). We do not
grant Feature Freeze Extensions for any
On 01/05/2017 02:23 PM, Paul Belanger wrote:
> Did my click bait work? :)
>
> So, over the holiday break I had some time to hack on diskimage-builder and
> create a new (container) element. I opted to call it ubuntu-rootfs. The basic
> idea, is the most minimal debootstrap chroot for ubuntu.
Excerpts from Michał Jastrzębski's message of 2017-01-05 11:45:49 -0800:
> I think total separation of projects would require much larger
> discussion in community. Currently we agreed on having kolla-ansible
> and kolla-k8s to be deliverables under kolla umbrella from historical
> reasons. Also I
Did my click bait work? :)
So, over the holiday break I had some time to hack on diskimage-builder and
create a new (container) element. I opted to call it ubuntu-rootfs. The basic
idea, is the most minimal debootstrap chroot for ubuntu. Everything in, we can
get a 42MB tarball of
On Thu, Jan 5, 2017 at 7:42 PM, Doug Hellmann wrote:
> Excerpts from Sam Yaple's message of 2017-01-05 18:22:54 +:
> > On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann
> wrote:
> >
> > > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35
On Thu, Jan 5, 2017 at 7:45 PM, Michał Jastrzębski wrote:
> I think total separation of projects would require much larger
> discussion in community. Currently we agreed on having kolla-ansible
> and kolla-k8s to be deliverables under kolla umbrella from historical
> reasons.
I think total separation of projects would require much larger
discussion in community. Currently we agreed on having kolla-ansible
and kolla-k8s to be deliverables under kolla umbrella from historical
reasons. Also I don't agree that there is "little or no overlap" in
teams, in fact there is ton
Excerpts from Sam Yaple's message of 2017-01-05 18:22:54 +:
> On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann wrote:
>
> > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley
> > wrote:
On 05.01.2017 17:03, Steven Hardy wrote:
> On Thu, Jan 05, 2017 at 02:56:15PM +, arkady.kanev...@dell.com wrote:
>> I have concern to rely on undercloud for overcloud swift.
>> Undercloud is not HA (yet) so it may not be operational when disk failed or
>> swift overcloud node is
On 1/5/17 3:17 AM, Erno Kuvaja wrote:
> On Wed, Jan 4, 2017 at 9:22 PM, Tony Breeds wrote:
>> On Wed, Jan 04, 2017 at 01:31:42PM -0500, Ian Cordasco wrote:
>>
>>> I believe you asked in another thread (that I cannot locate) if it was
>>> acceptable to the Glance team to
Hi all,
I believe that with the migration from WADL to RST complete, the use case
for fairy-slipper has also come to a close. I plan to retire it.
Share any concerns or questions you have, and I'll use the standard process
[1] to retire the repo.
Anne
1.
On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann wrote:
> Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley
> wrote:
> >
> > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > >
-Original Message-
From: Rob C
Reply: OpenStack Development Mailing List (not for usage questions)
Date: January 5, 2017 at 12:10:43
To: OpenStack Development Mailing List (not for usage questions)
Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley wrote:
>
> > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > [...]
> > > I do feel this is slightly different than whats described. Since it is
> > not
>
On Thu, Jan 5, 2017 at 5:56 PM, Alex Schultz wrote:
> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski
> wrote:
> > Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
> > there is no reason in my mind for kolla-ansible/k8s core team to
Hi All,
As per our IRC meeting today[1] we've decided to try shortening the
Security IRC meetings to 30 minutes per week. The other option was to have
meetings every two weeks but we all agreed that would lead to missed
meetings, confusion around holidays etc.
The main reason for shortening our
Oh you misunderstood good sir;) kolla-puppet is similar to tripleo -
it's would set up whole OpenStack using kolla containers deployed by
puppet manifests. I agree, if it would only install kolla - that
should go to openstack puppet, but kolla is a deployment tool.
On 5 January 2017 at 09:56,
On Thu, Jan 5, 2017 at 2:12 PM, Ronan-Alexandre Cherrueau <
ronan-alexandre.cherru...@inria.fr> wrote:
> Hello,
>
>
> TL;DR: We make a multi-regions deployment with Kolla. It requires to
> patch the code a little bit, and you can find the diff on our
> GitHub[1]. This patch is just a first
On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski wrote:
> Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
> there is no reason in my mind for kolla-ansible/k8s core team to vote
> on accepting new deliverable. I think this should be lightweight and
> easy,
Great stuff! Thank you Ronan. I'd love to see this guide refactored
and submitted to our docs (also take a longer look how to make full
fledged support in kolla tree). Looking for volunteers:)
On 5 January 2017 at 07:59, Jeffrey Zhang wrote:
> Thanks Ronan,
>
> Great
Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
there is no reason in my mind for kolla-ansible/k8s core team to vote
on accepting new deliverable. I think this should be lightweight and
easy, we should allow experimentation (after all, kolla itself went
through few fail
Greetings OpenStack community,
Our first meeting for 2017 opened with a bang. Lots of people in attendance to
talk about the ongoing adventure of trying to improve the handling of the
concept of visibility in Glance. If we had had more time we could have
continued talking about it for a long
On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley wrote:
> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> [...]
> > I do feel this is slightly different than whats described. Since it is
> not
> > unrelated services, but rather, for lack of a better word, competing
> >
On Thu, Jan 5, 2017 at 8:58 AM, Sam Yaple wrote:
> Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt (or kolla-puppet, or kolla-chef) is silly since the projects are
> unrelated. That would be like involving glance when cinder has a new
> service
On 05/01/17 11:41, Crag Wolfe wrote:
Hi,
I have a patch[1] to support the de-duplication of resource properties
data between events and resources. In the ideal rolling-upgrade world,
we would be writing data to the old and new db locations, only reading
from the old in the first release (let's
On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
[...]
> I do feel this is slightly different than whats described. Since it is not
> unrelated services, but rather, for lack of a better word, competing
> services. To my knowledge infra doesn't have several service doing the same
> job with
On Thu, Jan 5, 2017 at 4:34 PM, Jeremy Stanley wrote:
> On 2017-01-05 15:58:45 + (+), Sam Yaple wrote:
> > Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt
> > (or kolla-puppet, or kolla-chef) is silly since the projects are
> unrelated.
>
At today's Glance meeting, we decided to go with a version of the
question Erno posed below. I've posted an etherpad where we can refine
the question in order to increase the probability of receiving useful
responses:
https://etherpad.openstack.org/p/glance-user-survey-question-feb2017
Please
On Thu, Jan 5, 2017 at 4:06 PM, Doug Hellmann wrote:
> Excerpts from Sam Yaple's message of 2017-01-05 15:58:45 +:
> > Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt
> > (or kolla-puppet, or kolla-chef) is silly since the projects are
>
Hi,
I have a patch[1] to support the de-duplication of resource properties
data between events and resources. In the ideal rolling-upgrade world,
we would be writing data to the old and new db locations, only reading
from the old in the first release (let's assume Ocata). The problem is
that in
On 12/13/2016 01:40 PM, Dmitry Tantsur wrote:
Hi folks!
Since nearly its beginning, ironic-inspector has had a controversial feature: we
allow a user to request changing IPMI credentials of the node after
introspection. The new credentials are passed back from inspector to the
ramdisk, and the
On 2017-01-05 15:58:45 + (+), Sam Yaple wrote:
> Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
> (or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
> That would be like involving glance when cinder has a new service because
> they both
Excerpts from Sam Yaple's message of 2017-01-05 15:58:45 +:
> Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
> (or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
> That would be like involving glance when cinder has a new service because
>
Thanks Ronan,
Great approach.
I am always expecting multi-region support in Kolla. I hope what you did
can be merged into Kolla.
On Thu, Jan 5, 2017 at 10:12 PM, Ronan-Alexandre Cherrueau <
ronan-alexandre.cherru...@inria.fr> wrote:
> Hello,
>
>
> TL;DR: We make a multi-regions deployment
On Thu, Jan 05, 2017 at 02:56:15PM +, arkady.kanev...@dell.com wrote:
> I have concern to rely on undercloud for overcloud swift.
> Undercloud is not HA (yet) so it may not be operational when disk failed or
> swift overcloud node is added/deleted.
I think the proposal is only for a
Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
(or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
That would be like involving glance when cinder has a new service because
they both use keystone. The kolla-core team is reasonable since those
I think this is going to require more time and information. Perhaps you could
open a launchpad bug to track this?
I just brought up a new vagrant successfully yesterday, would you mind checking
if you have the latest code and trying again? Also, if there is anything else
relating to storm or
After some research, this review fixes the tempest failures:
https://review.openstack.org/#/c/416503/1 (newer patchset has an
unrelated fix for the functional tests gate)
Multiple local tempest runs and gate rechecks all turned green with
this fix. That is the good news part.
The bad news is
Hello,
I would like to use this opportunity upcoming to decide things related to
one of features that I am implementing.
To prevent lost-update problem, the user in the next Ironic API versions
will have the ability to use the entity tag for each resource.
Thus, in order to send conditional
On Wed, Jan 4, 2017 at 8:57 AM, John Trowbridge wrote:
>
>
> On 01/03/2017 07:30 PM, Emilien Macchi wrote:
>> I've noticed some TripleO core reviewers self approving patch without
>> respecting our review policy, specially in tripleo-quickstart.
>>
>
> This is slightly
On Wed, Jan 4, 2017 at 11:22 AM, Attila Darazs wrote:
> On 01/04/2017 10:34 AM, Steven Hardy wrote:
>>
>> Hi Harry,
>>
>> On Tue, Jan 03, 2017 at 04:04:51PM -0500, Harry Rybacki wrote:
>>>
>>> Greetings All,
>>>
>>> Folks have been diligently working on the blueprint[1] to
To anyone interested in this discussion: I put it on the agenda for
today's API-WG meeting (16:00 UTC):
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> Thanks Brian for bringing this up, same we been discussing last week on QA
> channel and
I have concern to rely on undercloud for overcloud swift.
Undercloud is not HA (yet) so it may not be operational when disk failed or
swift overcloud node is added/deleted.
-Original Message-
From: Christian Schwede [mailto:cschw...@redhat.com]
Sent: Thursday, January 05, 2017 6:14 AM
A follow up question on relationships.
On Thu, Jan 5, 2017 at 9:59 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:
> Hi Yujun,
>
> Lets see.
>
> 1. There is no need for the transformer to handle this duplication. What
> will happen at the moment is that we will receive twice every
On Tue, Jan 3, 2017 at 4:04 PM, Harry Rybacki wrote:
> Greetings All,
>
> Folks have been diligently working on the blueprint[1] to prepare
> TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
> their transition into TripleO-CI. Presently, our aim is to begin
On 04/01/17 13:31 -0500, Ian Cordasco wrote:
-Original Message-
From: Tony Breeds
Reply: OpenStack Development Mailing List (not for usage questions)
, OpenStack Development Mailing
List (not for usage questions)
On Tue, Jan 3, 2017 at 3:03 PM, Joshua Harlow wrote:
> Hi Oslo folks (and others),
>
> Happy new year!
>
> After serving for about a year I think it's a good opportunity for myself to
> let another qualified individual run for Oslo PTL (seems common to only go
> for two
Hello,
TL;DR: We make a multi-regions deployment with Kolla. It requires to
patch the code a little bit, and you can find the diff on our
GitHub[1]. This patch is just a first attempt to support multi-regions
in Kolla and it raises questions. Some modifications are not done in
an idiomatic way
On 2017-01-05 01:13:20 + (+), Yujun Zhang wrote:
> It seems the file is truncated on Github preview. It stops at
> openstack/security-specs
>
> If you check the raw file[1], you will find entry of openstack/vitrage
>
> [1]:
>
Hi Yujun,
Lets see.
1. There is no need for the transformer to handle this duplication. What will
happen at the moment is that we will receive twice every neighbor, and it is
fine by us, because it is a quite small datasource, and 99.999% of the time it
won't be changed.
2. It should be 2
One thought I had. And it may not be appropriate:
Do you use or have you considered using Ironic for non X86 based systems
(arm, powerpc, etc)?
Are you in the telecom industry? Should Ironic support ATCA based systems
to make use of older hardware?
I am facing a potential project in the next few
Alexey,
I have to dig this old thread to clarify some issues I met during static
datasource implementation. Hope that you can still recall the context :-)
I'll try to simplify this question with an example. The following
configuration are snippet from static datasource
1. suppose we have three
Hi Devs,
We are bringing up new CI using latest CI Solution[1]
And we are facing some issues[2] with connection nodepool[3] to devstack
provider[4]
Due to keystone authentication error[5], looks like some missing info in the
nodepool.yaml
Please advise.
p.s. provider was done by bringing up
Hello everyone,
there was an earlier discussion on $subject last year [1] regarding a
bug when upscaling or replacing nodes in TripleO [2].
Shortly summarized: Swift rings are built on each node separately, and
if adding or replacing nodes (or disks) this will break the rings
because they are no
Hello,
In such case like You described, ports will be bound with openvswitch
mechanism driver because this agent will be found as alive on host. So
linuxbridge mechanism driver will do nothing for binding such ports.
--
Slawek Kaplonski
sla...@kaplonski.pl
W dniu 05.01.2017 04:51, zhi
The mechanism drivers populate the vif details that tell nova how it's
supposed to setup the VM port. So the linux bridge driver tells it the port
type is linux bridge[1] and the OVS tells it that the type is OVS.
So if you have both loaded and ovs is running on the compute node. The
following
Josh,
It has been great working with you as the PTL of Oslo. Thanks for your
leadership.
-amrith
> -Original Message-
> From: Joshua Harlow [mailto:harlo...@fastmail.com]
> Sent: Tuesday, January 3, 2017 3:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
HI All,
I've started an etherpad[1] to collect topic ideas for the PTG. We would
have a meeting room for 3 days(Wednesday-Friday). Feel free to add whatever
you think we should discuss/implement.
Basic information about the PTG (schedule, layout etc) is available at
On Wed, Jan 4, 2017 at 9:22 PM, Tony Breeds wrote:
> On Wed, Jan 04, 2017 at 01:31:42PM -0500, Ian Cordasco wrote:
>
>> I believe you asked in another thread (that I cannot locate) if it was
>> acceptable to the Glance team to not have an 11.0.3 tarball on
>>
75 matches
Mail list logo