On Tue, May 16, 2017 at 4:28 PM, Florian Fuchs wrote:
> On Mon, May 15, 2017 at 6:27 PM, Steven Hardy wrote:
> > On Mon, May 08, 2017 at 02:45:08PM +0300, Marios Andreou wrote:
> >>Hi folks, after some discussion locally with colleagues about
> improving
> >>the upgrades experience, one
On Mon, May 15, 2017 at 7:27 PM, Steven Hardy wrote:
> On Mon, May 08, 2017 at 02:45:08PM +0300, Marios Andreou wrote:
> >Hi folks, after some discussion locally with colleagues about
> improving
> >the upgrades experience, one of the items that came up was
> pre-upgrade and
> >update
On Tue, May 9, 2017 at 11:46 AM, mathieu bultel wrote:
> On 05/08/2017 01:45 PM, Marios Andreou wrote:
>
> Hi folks, after some discussion locally with colleagues about improving
> the upgrades experience, one of the items that came up was pre-upgrade and
> update validations. I took an AI to loo
Hi Congress folks,
As mentioned in previous meetings, we need to decide this week whether to have
work sessions at the next PTG (expected to be September 11-15, 2017 in Denver,
CO).
Please reply to me 1) whether you think we should have sessions at the PTG and
2) if we have sessions whether yo
Hi everyone,
Blazar team had some meetings, a forum and a presentation at Boston
summit last week. This mail is a quick summary of the activities. If
more details are needed, please check links listed at the bottom of this
mail.
* Blazar team meetings
Blazar team had 2 meetings [1], one
Hello,
Magnum team.
I Installed Openstack newton and magnum.
I installed Magnum by source(master branch).
I have two questions.
1.
After installation,
I created kubernetes cluster and it's CREATE_COMPLETE,
and I want to create kubernetes pod.
My create script is below.
-
Hi all,
OpenStack Bug Smash for Pike is ongoing now. I will last from Wednesday to
Friday May 17 to 19 in Suzhou, China.
Around 60 engineers are working on Nova, Cinder, Neutron, Keystone, Heat,
Telemetry, Ironic, Oslo, OSC, Kolla, Trove, Dragonflow, Karbor, Manila,
Zaqar, Tricircle, Cloudkitty,
On May 16, 2017, at 3:06 PM, Jeremy Stanley wrote:
>
>> It's pretty clear now some see drawbacks in reusing #openstack-dev, and
>> so far the only benefit expressed (beyond not having to post the config
>> change to make it happen) is that "everybody is already there". By that
>> rule, we should
Team,
We manage to have a productive discussion on resiliency for 1000+ nodes.
Many thanks to Adam Spiers on helping with it.
https://etherpad.openstack.org/p/Achieving_Resiliency_at_Scales_of_1000+
There are several concrete actions especially for current gate testing.
Will bring these at the nex
Hey Raoul,
Thanks for putting this up in the ML. Replying inline:
On Tue, May 16, 2017 at 4:59 PM, Raoul Scarazzini wrote:
> Hi everybody,
> as discussed in today's TripleO meeting [1] here's a brief recap of the
> tripleo-quickstart-utils topic.
>
> ### TL;DR ###
>
> We are trying to understand
Hi Team,
This is a kind reminder for our weekly meeting this week at
#openstack-cyborg EST 11:00am (UTC 15:00) on Wed.
The agenda for today's meeting is try to finalize and freeze our current
specs and get to code development as soon as possible.
--
Zhipeng (Howard) Huang
Standard Engineer
IT
On Tue, May 16, 2017 at 05:13:16PM -0500, Monty Taylor wrote:
> Hey all!
>
> I read the API docs A LOT. (thank you to all of you who have worked
> on writing them)
>
> As I do, a gotcha I hit up against a non-zero amount is mapping the
> descriptions of the response parameters to the form of the
On Tue, May 16, 2017 at 11:13:05PM +0200, Thierry Carrez wrote:
> Sean Dague wrote:
> > On 05/16/2017 03:59 PM, Thierry Carrez wrote:
> >> Thierry Carrez wrote:
> >>> Here we have a clear topic, and TC members need to pay a certain level
> >>> of attention to whatever is said. Mixing it with other
Hey folks,
Sending out a reminder that we will have the policy meeting tomorrow [0].
The agenda [1] is already pretty full but we are going to need
cross-project involvement tomorrow considering the topics and impacts.
I'll be reviewing policy things in the morning so if anyone has questions
or w
On 16/05/17 01:06, Colleen Murphy wrote:
Additionally, I think OAuth - either extending the existing OAuth1.0
plugin or implementing OAuth2.0 - should probably be on the table.
I believe that OAuth is not a good fit for long-lived things like an
application needing to communicate with its own
On 15/05/17 20:07, Adrian Turjak wrote:
On 16/05/17 01:09, Lance Bragstad wrote:
On Sun, May 14, 2017 at 11:59 AM, Monty Taylor mailto:mord...@inaugust.com>> wrote:
On 05/11/2017 02:32 PM, Lance Bragstad wrote:
Hey all,
One of the Baremetal/VM sessions at the summit foc
Waines, Greg wrote:
Sam,
Two other more higher-level points I wanted to discuss with you about Masaraki.
First,
so I notice that you are doing both monitoring, auto-recovery and even host
maintenance
type functionality as part of the Masaraki architecture.
are you open to some configurabili
On 16/05/17 22:39, Sean Dague wrote:
> On 05/15/2017 10:00 PM, Adrian Turjak wrote:
>> I'm well aware of the policy work, and it is fantastic to see it
>> progressing! I can't wait to actually be able to play with that stuff!
>> We've been painstakingly tweaking the json policy files which is a
Waines, Greg wrote:
thanks for the pointers Sam.
I took a quick look.
I agree that the VM Heartbeat / Health-check looks like a good fit into
Masakari.
Currently your instance monitoring looks like it is strictly black-box type
monitoring thru libvirt events.
Is that correct ?
i.e. you do no
On 2017-05-16 19:56:31 + (+), Fox, Kevin M wrote:
[...]
> Lets provide the tools to make it as easy as possible to identify
> containers with issues, and allow upgrading the system to newer
> ones.
>
> Which CVE's are on the system is somewhat less important then
> being able to get to new
On 05/16/2017 02:44 PM, Sean Dague wrote:
On 05/16/2017 03:40 PM, Monty Taylor wrote:
On 05/16/2017 10:20 AM, Doug Hellmann wrote:
Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
On Tue, 16 May 2017, Monty Taylor wrote:
FWIW - I'm un-crazy about the term API Key - but I'm go
Hey all!
I read the API docs A LOT. (thank you to all of you who have worked on
writing them)
As I do, a gotcha I hit up against a non-zero amount is mapping the
descriptions of the response parameters to the form of the response
itself. Most of the time there is a top level parameter under
Chris Friesen wrote:
On 05/16/2017 10:45 AM, Joshua Harlow wrote:
So fyi,
If you really want something like this:
Just use:
http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock
And always get a write lock.
It is a slightly different way of getting those
I'm not fully recovered from summit yet, so this will not cover
everything. It will pick back up next week once I'm back in the
full flow.
# Notes from Summit
Elsewhere I'll create a more complete write up of the Foundation board
meeting that happened on the Sunday before summit, but some comme
On 2017-05-16 23:13:05 +0200 (+0200), Thierry Carrez wrote:
[...]
> Looking at recent logs from #openstack-dev, I can see it would be a bit
> painful to sort out what is actionable TC stuff from what is long
> general development discussions and random are-you-around pings.
I'm likely misunderstan
Sean Dague wrote:
> On 05/16/2017 03:59 PM, Thierry Carrez wrote:
>> Thierry Carrez wrote:
>>> Here we have a clear topic, and TC members need to pay a certain level
>>> of attention to whatever is said. Mixing it with other community
>>> discussions (which I have to prioritize lower) just makes it
Hi everybody,
as discussed in today's TripleO meeting [1] here's a brief recap of the
tripleo-quickstart-utils topic.
### TL;DR ###
We are trying to understand whether is good or not to put the contents
of [2] somewhere else for a wider exposure.
### Long version ###
tripleo-quickstart-utils pr
On 05/16/2017 03:59 PM, Thierry Carrez wrote:
> Thierry Carrez wrote:
>> Here we have a clear topic, and TC members need to pay a certain level
>> of attention to whatever is said. Mixing it with other community
>> discussions (which I have to prioritize lower) just makes it harder to
>> pay the ri
On 2017-05-16 21:53:43 +0200 (+0200), Thierry Carrez wrote:
[...]
> I wouldn't say it's premature optimization, we create channels all the
> time. #openstack-dev is a general discussion channel, which is used for
> anything that doesn't fit anywhere else. If you look at recent logs,
> you'll see th
Thierry Carrez wrote:
> Here we have a clear topic, and TC members need to pay a certain level
> of attention to whatever is said. Mixing it with other community
> discussions (which I have to prioritize lower) just makes it harder to
> pay the right level of attention to the channel. Basically I h
Security is a spectrum, not a boolean. I know some sites that have instituted
super long/complex password requirements. The end result is usually humans just
writing pw's down on stickies then since its too hard to remember, making
security worse, not better. Humans are always the weakest link i
Jeremy Stanley wrote:
> On 2017-05-16 09:38:34 -0400 (-0400), Davanum Srinivas wrote:
>> See $TITLE :)
>
> Trying not to rehash other points, I'm in favor of using
> #openstack-dev for now until we see it's not working out. Creating a
> new channel for this purpose before we've even undertaken the
On 16 May 2017 at 12:36, Jeremy Stanley wrote:
> On 2017-05-16 11:46:14 -0700 (-0700), Michał Jastrzębski wrote:
> [...]
>> So CVE tracking might not be required by us. Since we still use
>> distro packages under the hood, we can just use these.
> [...]
>
> I think the question is how I, as a semi
On 05/16/2017 03:40 PM, Monty Taylor wrote:
> On 05/16/2017 10:20 AM, Doug Hellmann wrote:
>> Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
>>> On Tue, 16 May 2017, Monty Taylor wrote:
>>>
FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll
with
th
On 05/16/2017 10:20 AM, Doug Hellmann wrote:
Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
On Tue, 16 May 2017, Monty Taylor wrote:
FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll with
that until someone has a better idea. I'm uncrazy about it for two re
On 2017-05-16 11:46:14 -0700 (-0700), Michał Jastrzębski wrote:
[...]
> So CVE tracking might not be required by us. Since we still use
> distro packages under the hood, we can just use these.
[...]
I think the question is how I, as a semi-clueful downstream user of
your images, can tell whether t
On 05/16/2017 10:45 AM, Joshua Harlow wrote:
So fyi,
If you really want something like this:
Just use:
http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock
And always get a write lock.
It is a slightly different way of getting those locks (via a context ma
On Tue, May 16, 2017 at 1:02 PM, Jeremy Stanley wrote:
> rooters these days). Something like "tc-members" can be used to
> address a question specifically to those on the TC who happen to be
> around and paying attention and also gives people looking at the
> logs a useful string to grep/search/wh
On Tue, May 16, 2017 at 10:17 AM, Sean McGinnis wrote:
> If we just use -dev, there is a high chance there will be a lot of cross-
> talk during discussions. There would also be a lot of effort to grep
> through the full day of activity to find things relevant to TC
> discussions. If we have a ded
We can put warnings all over it and if folks choose to ignore them, then its
they who took the risk and get to keep the pieces when it breaks. Some folks
are crazy enough to run devstack in production. But does that mean we should
just abandon devstack? No. of course not. I don't think we should
And bandwidth can be conserved by only uploading images that actually changed
in non trivial ways (packages were updated, not just logfile with a new
timestamp)
Thanks,
Keivn
From: Michał Jastrzębski [inc...@gmail.com]
Sent: Tuesday, May 16, 2017 11:46 AM
On 16 May 2017 at 11:49, Doug Hellmann wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700:
>> On 16 May 2017 at 11:27, Doug Hellmann wrote:
>> > Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700:
>> >> So another consideration. Do you think whol
On 05/16/2017 02:39 PM, Doug Hellmann wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-16 09:51:00 -0700:
>> On 16 May 2017 at 09:40, Clint Byrum wrote:
>>>
>>> What's at stake isn't so much "how do we get the bits to the users" but
>>> "how do we only get bits to users that they nee
Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700:
> On 16 May 2017 at 11:27, Doug Hellmann wrote:
> > Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700:
> >> So another consideration. Do you think whole rule of "not building
> >> binares" should be reco
On 16 May 2017 at 11:33, Doug Hellmann wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-16 08:20:17 -0700:
>> On 16 May 2017 at 08:12, Doug Hellmann wrote:
>> > Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700:
>> >> On 16 May 2017 at 06:20, Flavio Percoco wr
My guess is same with octavia.
https://github.com/openstack/octavia/tree/master/diskimage-create#diskimage-builder-script-for-creating-octavia-amphora-images
-Josh
Fox, Kevin M wrote:
+1. ironic and trove have the same issues as well. lowering the bar in order to
kick the tires will help Open
Excerpts from Michał Jastrzębski's message of 2017-05-16 09:51:00 -0700:
> On 16 May 2017 at 09:40, Clint Byrum wrote:
> >
> > What's at stake isn't so much "how do we get the bits to the users" but
> > "how do we only get bits to users that they need". If you build and push
> > daily, do you expe
I'm not sure I follow the problem. The containers being built don't pull from
infra's mirrors, so they can be secure containers. Once built, during
deploy/testing, they don't install anything, so shouldn't have any issues there
either.
Am I misunderstanding?
Thanks,
Kevin
On 16 May 2017 at 11:27, Doug Hellmann wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700:
>> So another consideration. Do you think whole rule of "not building
>> binares" should be reconsidered? We are kind of new use case here. We
>> aren't distro but we are packag
Excerpts from Michał Jastrzębski's message of 2017-05-16 08:20:17 -0700:
> On 16 May 2017 at 08:12, Doug Hellmann wrote:
> > Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700:
> >> On 16 May 2017 at 06:20, Flavio Percoco wrote:
> >> > On 16/05/17 14:08 +0200, Thierry Carrez
Excerpts from Jeremy Stanley's message of 2017-05-16 17:41:28 +:
> On 2017-05-16 11:17:31 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Sam Yaple's message of 2017-05-16 14:11:18 +:
> [...]
> > > If you build images properly in infra, then you will have an image that is
> > > not se
Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700:
> So another consideration. Do you think whole rule of "not building
> binares" should be reconsidered? We are kind of new use case here. We
> aren't distro but we are packagers (kind of). I don't think putting us
> on equal f
Make sure you have the latest neutron-lib in your tree: neutron-lib==1.6.0
On Tue, May 16, 2017 at 3:05 AM, Vikash Kumar
wrote:
> Hi Team,
>
> pep8 is failing in master code. translation hint helpers are removed from
> LOG messages. Is this purposefully done ? Let me know if it is not, will
> c
+1. ironic and trove have the same issues as well. lowering the bar in order to
kick the tires will help OpenStack a lot in adoption.
From: Sean Dague [s...@dague.net]
Sent: Tuesday, May 16, 2017 6:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [o
Sorry, I'm a bit late to the discussion.
Over the time I've maintained openstack clouds, I've seen many times,
integration issues pop up between distro packages and openstack packages. The
released openstack packages are usually fine. Changes in the distros break
kolla builds over time.
In th
We now have 2 separate bugs related to changes in today's Sphinx 1.6.1
release causing our doc jobs to fail in different ways.
https://bugs.launchpad.net/pbr/+bug/1691129 describes a traceback
produced when building the developer documentation through pbr.
https://bugs.launchpad.net/reno/+bug/169
Fine with me,
I'd personally rather get down to say 2 'great' drivers for RPC,
And say 1 (or 2?) for notifications.
So ya, wfm.
-Josh
Mehdi Abaakouk wrote:
+1 too, I haven't seen its contributors since a while.
On Mon, May 15, 2017 at 09:42:00PM -0400, Flavio Percoco wrote:
On 15/05/17 15:
On 2017-05-16 09:38:34 -0400 (-0400), Davanum Srinivas wrote:
> See $TITLE :)
Trying not to rehash other points, I'm in favor of using
#openstack-dev for now until we see it's not working out. Creating a
new channel for this purpose before we've even undertaken the
experiment seems like a social f
On 16 May 2017 at 10:41, Jeremy Stanley wrote:
> On 2017-05-16 11:17:31 -0400 (-0400), Doug Hellmann wrote:
>> Excerpts from Sam Yaple's message of 2017-05-16 14:11:18 +:
> [...]
>> > If you build images properly in infra, then you will have an image that is
>> > not security checked (no gpg v
On 2017-05-16 11:17:31 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Sam Yaple's message of 2017-05-16 14:11:18 +:
[...]
> > If you build images properly in infra, then you will have an image that is
> > not security checked (no gpg verification of packages) and completely
> > unverifiabl
On 14 May 2017, at 4:04, Sean Dague wrote:
> One of the things that came up in a logging Forum session is how much effort
> operators are having to put into reconstructing flows for things like server
> boot when they go wrong, as every time we jump a service barrier the
> request-id is reset
Davanum Srinivas wrote:
> On Tue, May 16, 2017 at 11:52 AM, Michał Jastrzębski wrote:
>> On 16 May 2017 at 08:32, Doug Hellmann wrote:
>>> Excerpts from Sean McGinnis's message of 2017-05-16 10:17:35 -0500:
My preference would be to have an #openstack-tc channel.
One thing I like a
On 2017-05-16 11:46 AM, Sean Dague wrote:
On 05/16/2017 11:17 AM, Sean McGinnis wrote:
On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
Folks,
See $TITLE :)
Thanks,
Dims
My preference would be to have an #openstack-tc channel.
One thing I like about the dedicated meeting t
On 16 May 2017 at 09:40, Clint Byrum wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700:
>> > Container images introduce some extra complexity, over the basic
>> > operating system style packages mentioned above. Due to the way
>> > they are constructed, they are like
So fyi,
If you really want something like this:
Just use:
http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock
And always get a write lock.
It is a slightly different way of getting those locks (via a context
manager) but the implementation underneath is a
On 5/16/2017 11:11 AM, Chris Dent wrote:
(This is a followup to
http://lists.openstack.org/pipermail/openstack-dev/2017-May/116267.html
but I don't have that around anymore to make a proper response to.)
In a devstack change:
https://review.openstack.org/#/c/457715/
nova-api and nova-meta
So another consideration. Do you think whole rule of "not building
binares" should be reconsidered? We are kind of new use case here. We
aren't distro but we are packagers (kind of). I don't think putting us
on equal footing as Red Hat, Canonical or other companies is correct
here.
K8s is somethin
Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700:
> > Container images introduce some extra complexity, over the basic
> > operating system style packages mentioned above. Due to the way
> > they are constructed, they are likely to include content we don't
> > produce ourselv
On Tue, May 16, 2017 at 11:52 AM, Michał Jastrzębski wrote:
> On 16 May 2017 at 08:32, Doug Hellmann wrote:
>> Excerpts from Sean McGinnis's message of 2017-05-16 10:17:35 -0500:
>>> On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
>>> > Folks,
>>> >
>>> > See $TITLE :)
>>> >
>>>
(This is a followup to
http://lists.openstack.org/pipermail/openstack-dev/2017-May/116267.html
but I don't have that around anymore to make a proper response to.)
In a devstack change:
https://review.openstack.org/#/c/457715/
nova-api and nova-metadata will be changed to run as WSGI
applic
On 05/15/2017 09:10 PM, Julia Kreger wrote:
All,
In our new reality, in order to maximize velocity, I propose that we
loosen the review requirements for ironic-ui to allow faster
iteration. To this end, I suggest we move ironic-ui to using a single
core reviewer for code approval, along the same
On 16 May 2017 at 08:32, Doug Hellmann wrote:
> Excerpts from Sean McGinnis's message of 2017-05-16 10:17:35 -0500:
>> On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
>> > Folks,
>> >
>> > See $TITLE :)
>> >
>> > Thanks,
>> > Dims
>> >
>>
>> My preference would be to have an #ope
On 05/16/2017 11:28 AM, Eric Fried wrote:
>> The idea is that a regular user calling into a service should not
>> be able to set the request id, but outgoing calls from that service
>> to other services as part of the same request would.
>
> Yeah, so can anyone explain to me why this is a real pro
On 16 May 2017 at 08:30, Emilien Macchi wrote:
> On Tue, May 16, 2017 at 11:12 AM, Doug Hellmann wrote:
>> Excerpts from Flavio Percoco's message of 2017-05-16 10:07:52 -0400:
>>> On 16/05/17 09:45 -0400, Doug Hellmann wrote:
>>> >Excerpts from Flavio Percoco's message of 2017-05-15 21:50:23 -040
On 05/16/2017 11:17 AM, Sean McGinnis wrote:
> On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
>> Folks,
>>
>> See $TITLE :)
>>
>> Thanks,
>> Dims
>>
>
> My preference would be to have an #openstack-tc channel.
>
> One thing I like about the dedicated meeting time was if I was n
On Tue, May 16, 2017 at 11:12 AM, Doug Hellmann wrote:
> Excerpts from Flavio Percoco's message of 2017-05-16 10:07:52 -0400:
>> On 16/05/17 09:45 -0400, Doug Hellmann wrote:
>> >Excerpts from Flavio Percoco's message of 2017-05-15 21:50:23 -0400:
>> >> On 15/05/17 11:49 -0700, Michał Jastrzębski
Excerpts from Sean McGinnis's message of 2017-05-16 10:17:35 -0500:
> On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
> > Folks,
> >
> > See $TITLE :)
> >
> > Thanks,
> > Dims
> >
>
> My preference would be to have an #openstack-tc channel.
>
> One thing I like about the dedi
> The idea is that a regular user calling into a service should not
> be able to set the request id, but outgoing calls from that service
> to other services as part of the same request would.
Yeah, so can anyone explain to me why this is a real problem? If a
regular user wanted to be a d*ck and
Michał,
My fear is that anything said on that channel will come down as "TC
told us to do / not do such-and-such a thing"
-- Dims
On Tue, May 16, 2017 at 11:00 AM, Michał Jastrzębski wrote:
> On 16 May 2017 at 07:49, Sean Dague wrote:
>> On 05/16/2017 09:38 AM, Davanum Srinivas wrote:
>>> Folk
On Tue, May 16, 2017 at 02:08:07PM +0200, Thierry Carrez wrote:
>
> I totally subscribe to the concerns around publishing binaries (under
> any form), and the expectations in terms of security maintenance that it
> would set on the publisher. At the same time, we need to have images
> available, f
On 16 May 2017 at 08:12, Doug Hellmann wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700:
>> On 16 May 2017 at 06:20, Flavio Percoco wrote:
>> > On 16/05/17 14:08 +0200, Thierry Carrez wrote:
>> >>
>> >> Flavio Percoco wrote:
>> >>>
>> >>> From a release perspective
Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
> On Tue, 16 May 2017, Monty Taylor wrote:
>
> > FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll with
> > that until someone has a better idea. I'm uncrazy about it for two reasons:
> >
> > a) the word "key" imp
Hi Steve,
Thanks for your reply.
Out of interest, where did you find OS::TripleO::ControllerServer, do we
have a mistake in our docs somewhere?
I referred below template.
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/controller-role.yaml
resources:
Contr
On Tue, May 16, 2017 at 09:38:34AM -0400, Davanum Srinivas wrote:
> Folks,
>
> See $TITLE :)
>
> Thanks,
> Dims
>
My preference would be to have an #openstack-tc channel.
One thing I like about the dedicated meeting time was if I was not able to
attend, or when I was just a casual observer, it
Excerpts from Sam Yaple's message of 2017-05-16 14:11:18 +:
> I would like to bring up a subject that hasn't really been discussed in
> this thread yet, forgive me if I missed an email mentioning this.
>
> What I personally would like to see is a publishing infrastructure to allow
> pushing bu
Excerpts from Michał Jastrzębski's message of 2017-05-16 06:52:12 -0700:
> On 16 May 2017 at 06:20, Flavio Percoco wrote:
> > On 16/05/17 14:08 +0200, Thierry Carrez wrote:
> >>
> >> Flavio Percoco wrote:
> >>>
> >>> From a release perspective, as Doug mentioned, we've avoided releasing
> >>> proj
Excerpts from Flavio Percoco's message of 2017-05-16 10:07:52 -0400:
> On 16/05/17 09:45 -0400, Doug Hellmann wrote:
> >Excerpts from Flavio Percoco's message of 2017-05-15 21:50:23 -0400:
> >> On 15/05/17 11:49 -0700, Michał Jastrzębski wrote:
> >> >On 15 May 2017 at 11:19, Davanum Srinivas wrote
If you missed the TripleO project updates presentation, feel free to
watch the recording:
https://www.openstack.org/videos/boston-2017/project-update-triple0
and the slides:
https://docs.google.com/presentation/d/1knOesCs3HTqKvIl9iUZciUtE006ff9I3zhxCtbLZz4c
If you have any question or feedback re
Excerpts from Chris Dent's message of 2017-05-16 15:28:11 +0100:
> On Sun, 14 May 2017, Sean Dague wrote:
>
> > So, the basic idea is, services will optionally take an inbound
> > X-OpenStack-Request-ID which will be strongly validated to the format
> > (req-$uuid). They will continue to always
On 05/16/2017 10:28 AM, Chris Dent wrote:
> On Sun, 14 May 2017, Sean Dague wrote:
>
>> So, the basic idea is, services will optionally take an inbound
>> X-OpenStack-Request-ID which will be strongly validated to the format
>> (req-$uuid). They will continue to always generate one as well. When
>
Excerpts from Sean Dague's message of 2017-05-16 10:49:54 -0400:
> On 05/16/2017 09:38 AM, Davanum Srinivas wrote:
> > Folks,
> >
> > See $TITLE :)
> >
> > Thanks,
> > Dims
>
> I'd rather avoid #openstack-tc and just use #openstack-dev.
> #openstack-dev is pretty low used environment (compared t
Michał Jastrzębski wrote:
> On 16 May 2017 at 06:20, Flavio Percoco wrote:
>> I'd prefer for these builds to have a daily cadence because it sets the
>> expectations w.r.t maintenance right: "These images are daily builds and not
>> certified releases. For stable builds you're better off building
Flavio Percoco wrote:
> On 16/05/17 14:08 +0200, Thierry Carrez wrote:
>> 1/ Have third-parties publish images
>> It is the current situation. The issue is that the Kolla team (and
>> likely others) would rather automate the process and use OpenStack
>> infrastructure for it.
>>
>> 2/ Have third-pa
On 16 May 2017 at 07:49, Sean Dague wrote:
> On 05/16/2017 09:38 AM, Davanum Srinivas wrote:
>> Folks,
>>
>> See $TITLE :)
>>
>> Thanks,
>> Dims
>
> I'd rather avoid #openstack-tc and just use #openstack-dev.
> #openstack-dev is pretty low used environment (compared to like
> #openstack-infra or #
On 05/16/2017 09:38 AM, Davanum Srinivas wrote:
> Folks,
>
> See $TITLE :)
>
> Thanks,
> Dims
I'd rather avoid #openstack-tc and just use #openstack-dev.
#openstack-dev is pretty low used environment (compared to like
#openstack-infra or #openstack-nova). I've personally been trying to
make it m
On 05/15/2017 03:42 PM, Clint Byrum wrote:
In order to implement fairness you'll need every lock request to happen
in a FIFO queue. This is often implemented with a mutex-protected queue
of condition variables. Since the mutex for the queue is only held while
you append to the queue, you will al
+1!
--
Masayuki Igawa
masay...@igawa.me
On Tue, May 16, 2017, at 05:22 PM, Andrea Frittoli wrote:
> Hello team,
>
> I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.
>
> Over the past two cycle Fanglei has been steadily contributing to
> Tempest and its community.> She's
+1!
--
Masayuki Igawa
masay...@igawa.me
On Tue, May 16, 2017, at 05:22 PM, Andrea Frittoli wrote:
> Hello team,
>
> I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.
>
> Over the past two cycle Fanglei has been steadily contributing to
> Tempest and its community.> She's
On 15.05.17 19:01, Zane Bitter wrote:
On 15/05/17 12:10, Steven Hardy wrote:
On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:
Hi Steve,
I am happy to assist in any way to be honest.
It was great to meet you in Boston, and thanks very much for
volunteering to help out.
BTW one i
On Sun, 14 May 2017, Sean Dague wrote:
So, the basic idea is, services will optionally take an inbound
X-OpenStack-Request-ID which will be strongly validated to the format
(req-$uuid). They will continue to always generate one as well. When the
context is built (which is typically about 3 mor
1 - 100 of 148 matches
Mail list logo