Hi All,
In order to prevent race conditions due to multiple conductors, my solution
is as blew:
1. remove the db operation in bay_update to prevent race conditions.Stack
operation is atomic. Db operation is atomic. But the two operations
together are not atomic.So the data in the db may be wrong.
Hi Vilobh,
Do we need to do something similar for a Swarm bay?
Ton Ngo,
From: Vilobh Meshram
To: "OpenStack Development Mailing List (not for usage questions)"
, "OpenStack Mailing List
(not for usage questions)"
Date: 08/11/2015 08:50 PM
Subject:[
On 8/12/15, 12:12 AM, "Mike Perez" wrote:
>On 15:39 Aug 11, Gary Kotton wrote:
>>
>>
>> On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
>>
>> >Are you saying that *new functionality* was added to the stable/kilo
>> >branch of *Neutron*, and because new functionality was added to
>> >stable/kilo's Ne
Hi All,
About CA implementation.
I know we decided to use anchor as a CA to sign the certificate of each bay.
Currently anchor doesn’t use as library.
But anchor uses Cryptography[1] library to manage X.509 objects.
And cryptography v1.0 can build a certificate object easily using X.509
Certif
Please see
http://eavesdrop.openstack.org/meetings/keystone/2015/keystone.2015-08-11-18.00.html
for vote results.
Cheers,
Morgan
On Tue, Aug 11, 2015 at 9:46 PM, Adam Young wrote:
> On 07/15/2015 05:18 AM, Thierry Carrez wrote:
>
>> Adam Young wrote:
>>
>>> On 07/03/2015 08:36 AM, Samuel de Med
On 07/15/2015 05:18 AM, Thierry Carrez wrote:
Adam Young wrote:
On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote:
Hi Thierry,
Thanks for clarifying. A Spec Freeze Exception is what I was supposed
to ask for.
Rectifying:
On behalf of the team working on the Dynamic Policies subject, I
Now we can create mysql master instance and slave instance one by one.
It would be much better to allow user to create one master instance and
multiple slave instances with one request.
Any suggestion about this, the API design or the implementation?
Hi All,
As discussed in today's Magnum weekly meeting I had shown interest to work
on [1].
Problem :-
Currently objects (pod/rc/service) are read from the database. In order for
native clients to work, they must be read from the ReST bay endpoint. To
execute native clients, we must have one trut
Yes, John, It's for boot from volume case. We can't restore the instance
root disk now with backups, although we can make backup with in-use
volumes. Snapshot is same, we can take a snapshot for in-use volumes, but
we only can create a new volume from it.
You know in some cases users don't want to
Oh.. oops. Yeah if that's the case then sorry, you can just ignore me!
On Tue, Aug 11, 2015 at 8:39 PM, Tony Breeds
wrote:
> On Tue, Aug 11, 2015 at 08:24:10PM -0600, Matt Fischer wrote:
> > It was covered some here:
> > http://lists.openstack.org/pipermail/openstack-dev/2015-July/069658.html
>
On Tue, Aug 11, 2015 at 08:24:10PM -0600, Matt Fischer wrote:
> It was covered some here:
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069658.html
> and some graphs here: http://www.mattfischer.com/blog/?p=672
>
> tl;dr is that having revoked tokens affects keystone token validat
It was covered some here:
http://lists.openstack.org/pipermail/openstack-dev/2015-July/069658.html
and some graphs here: http://www.mattfischer.com/blog/?p=672
tl;dr is that having revoked tokens affects keystone token validation and
tokens are validated on almost every API call unless you're usin
On Mon, Aug 10, 2015 at 07:16:43PM -0600, Matt Fischer wrote:
> I'm not excited about making this the default until token revocations don't
> impact performance the way that they do now. I don't know how often this
> would get exercised though, but the impact of 100+ token revokes is
> noticeable
Just wanted to point out that if you dig a little in Postman's website, it
looks like all the base code is on github, and appears to be under the Apache
license. I didn't check the "jetpacks," but I suspect those might be
proprietary bits.
Tripp, Travis S wrote on Monday, August 10, 2015
On 8/10/2015 10:50 AM, Matt Riedemann wrote:
On 8/10/2015 9:40 AM, Matt Riedemann wrote:
On 8/9/2015 7:16 PM, Matt Riedemann wrote:
On 8/9/2015 7:09 PM, Robert Collins wrote:
On 8 August 2015 at 08:52, Matt Riedemann
wrote:
Well it's a Friday afternoon so you know what that means, em
Sure thing, I can handle rabbitmq and keystone tonight. The keystone one I
wrote during the mid-cycle so I will just throw it in a patch.
Sam Yaple
On Tue, Aug 11, 2015 at 10:54 AM, Steven Dake (stdake)
wrote:
> Hi,
>
> Alicja has been heading up this blueprint:
> https://blueprints.launchpad.n
I have been hit by these failures as well.
I think you did well by bumping out that revert from the queue; I think it
simply cures the sympton possibly affecting correct operations of the
firewall service.
If we are looking at removing the sympton on the API job, than I'd skip the
failing tests whi
> Here are a few --
> instance_get_all_by_filters joins manually with
> instances_fill_metadata --
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1890
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1782
>
> Almost all instance query function
I am struggling with python code profiling in general. It has its own
caveats like 100% plus overhead.
However, on a host with only nova services (DB on a different host), I see
cpu utilization spike up quickly with scale. The DB server is relatively
calm and never goes over 20%. On a system which
Just curious...have you measured this consuming a significant amount of CPU
time? Or is it more a gut feel of "this looks like it might be expensive"?
Chris
On 08/11/2015 04:51 PM, Sachin Manpathak wrote:
Here are a few --
instance_get_all_by_filters joins manually with
instances_fill_metada
Here are a few --
instance_get_all_by_filters joins manually with
instances_fill_metadata --
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1890
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1782
Almost all instance query functions manually join
Hi Everyone,
With the end of the cycle approaching we've still got a few work items this
cycle which are in an unfinished state. I want to make sure we're able to push
forward on these items and ensure we finish up most of these before
the end of the cycle. I feel like having high bandwidth face t
Hello,
Today has been an exciting day, to say the least. Earlier today I was
pinged on IRC about some firewall as a service unit test failures that
were blocking patches from being merged, such as
https://review.openstack.org/#/c/211537/.
Neutron devs started poking around a bit and discussing o
Excerpts from Sachin Manpathak's message of 2015-08-12 05:40:36 +0800:
> Hi folks,
> Nova codebase seems to follow manual joins model where all data required by
> an API is fetched from multiple tables and then joined manually by using
> (in most cases) python dictionary lookups.
>
> I was wonderi
What is the process for current stackforge projects to move into the openstack
namespace then? Is it a simple request now, or a more complicated process?
Thanks,
Kevin
From: James E. Blair [cor...@inaugust.com]
Sent: Tuesday, August 11, 2015 2:11 PM
To: Op
Hi folks,
Nova codebase seems to follow manual joins model where all data required by
an API is fetched from multiple tables and then joined manually by using
(in most cases) python dictionary lookups.
I was wondering about the basis reasoning for doing so. I usually find
openstack services to be
Hi,
Are you currently using same disks/nodes for container and object storage
?
http://docs.openstack.org/openstack-ops/content/maintenance.html
talks about replacing storage nodes. The same instructions applies to
container db as well.You need to apply the changes to container ring and
push it
On Tue, Aug 11 2015, Michael Krotscheck wrote:
> It looks like the additional features added, in particular the
> 'oslo_config_project' property, needs to be documented.
It has been documented with one of the patch, you can see it here:
http://docs.openstack.org/developer/oslo.middleware/oslo
Hello,
I hit an exception while running glance unit test. It worked well
previously (one week ago) and I guess this is because a version conflict
came up recently. Could anyone give me some suggestions regarding the
following issue?
Successfully installed Babel-2.0 Jinja2-2.8 Mako-1.0.1 MarkupSaf
On 2015-08-11 20:42:26 + (+), Bhandaru, Malini K wrote:
[...]
> Another place I see value is running periodically against past
> releases – Icehouse, Juno etc to catch any vulnerabilities in
> production systems. When we issue security notes we typically
> specify any past releases that car
On 15:39 Aug 11, Gary Kotton wrote:
>
>
> On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
>
> >Are you saying that *new functionality* was added to the stable/kilo
> >branch of *Neutron*, and because new functionality was added to
> >stable/kilo's Neutron, that stable/kilo *Nova* will no longer work?
>
Hi,
The TC has recently been considering what the big tent means for
Stackforge. In short, very little will be changing, except that we will
now start putting projects previously destined for stackforge/ in the
openstack/ git namespace.
The big tent is a recognition that there are a lot of proje
On Wed, Jul 29, 2015 at 12:40:53PM +, Jeremy Stanley wrote:
> On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote:
> > On 07/28/2015 07:13 PM, Andreas Jaeger wrote:
> [...]
> > > * If there is a proposed change already for a project, reuse that one
> > > instead of creating a new one?
> >
On Mon, Aug 10, 2015 at 9:54 PM, hao wang wrote:
> @Duncan and John, I have a idea about this issue, if volume is in-use but
> the instance which it's attached to is power-off, so can we avoid data
> corruption? If it's true, cinder could free the "available" restriction,
> let user decide if th
Rob, Timur, Travis, and Victor, thank you for your input! We are excited about
the feedback.
Added [Security] in subject per Rob’s suggestion. Copied all the security
interested parties who responded.
Another place I see value is running periodically against past releases –
Icehouse, Juno etc
On 08/10/2015 08:06 AM, Emilien Macchi wrote:
> Hello,
>
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
>
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150811
>
> Colleen will lead th
On 08/11/2015 11:39 AM, Gary Kotton wrote:
On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
Are you saying that *new functionality* was added to the stable/kilo
branch of *Neutron*, and because new functionality was added to
stable/kilo's Neutron, that stable/kilo *Nova* will no longer work?
Yes. That
Hi,
I've been playing around with DVR-HA patches [1][2], have them applied on
Mondays master branch.
The problem is that the dvr-ha router is not working with SNAT and floating ips.
My setup:
Devstack-34 - all in one (controller, compute, DVR agent, DHCP node)
Devstack-35 - compute node and DVR a
Hi Chris,
Thanks for reaching out. I would be interested in joint sessions on
Monasca and Ceilometer at the Tokyo Summit. We had a joint
Ceilometer/Monasca session at the Paris Design Summit and had identified
several areas to work on together. It has been a while since we've sync'd
up though. We
1. This is for simplicity as file name doesn't really matter. HOT
processing code needs to know where to look for template and it is easier
to have fixed file name/location rather than force users to explicitly
specify location in package manifest. But if if you have valid case where
this becomes a
hi,
this note is to raise awareness that the rpc publishing functionality in
Ceilometer will be deprecated and disabled in Liberty[1] as it offers
redundant capabilities vs notifier publishing.
back in Juno, we adopted oslo.messaging and switched from RPC to work
queues in Ceilometer -- the
Last week in the Horizon team meeting, we voted [1] to add a meeting to
address the growing blueprint backlog. To that end, I've scheduled a
regular meeting [2] to review old and new Horizon blueprints to reduce the
clutter and focus ongoing work. We have several blueprints that need to
removed/rej
On 15:06 Aug 11, Kuvaja, Erno wrote:
> > -Original Message-
> > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > Having the image cache local to the compute nodes themselves gives the
> > best performance overall, and with glance_store, means that glance-api isn't
> > needed at all, and G
It looks like the additional features added, in particular the
'oslo_config_project' property, needs to be documented.
A deeper read shows that you're right, existing functionality was not
broken. Apologies for being heavy handed in my response.
Michael
On Tue, Aug 11, 2015 at 2:53 AM Julien Da
Marton and I are taking the ask.openstack.org site offline for a
couple hours to move it to a new server running a more recent OS,
and upgrading the version of Askbot running on it so that support
for Google authentication can be restored soon. The server should be
offline no more than a couple hou
On 8/10/15 3:11 PM, Ken Thomas wrote:
> Hi all,
Hey Ken! (we miss you at our IRC meetings :) )
>
> (I've been away for a couple of weeks and I tried to send this before
> I left. I didn't see it come through so my apologies if this is the
> second time you've seen this.)
Nope, this is the first ti
On 13:42 Aug 11, Brian Rosmaita wrote:
> On 8/7/15, 1:07 PM, "Jay Pipes" wrote:
>
> >So, here's the crux of the issue. Nova and Cinder **do not want to speak
> >the Glance REST API** to either upload or download image bits from
> >storage. Streaming image bits through the Glance API endpoint is a
Hi,
Alicja has been heading up this blueprint:
https://blueprints.launchpad.net/kolla/+spec/dockerfile-template
Other projects like TripleO and downstreams depend on this change to happen as
soon as possible. It is a mountain of work – too much for one person to finish
in a sprint. I’d like t
On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
>On 08/11/2015 10:57 AM, Gary Kotton wrote:
>> On 8/11/15, 5:08 PM, "Jeremy Stanley" wrote:
>>
>>> On 2015-08-11 13:49:37 + (+), Gary Kotton wrote:
This is a stable issue - please see
https://review.openstack.org/165750.
This is req
Hi,
I’m ok with this time.
Renat Akhmerov
@ Mirantis Inc.
> On 11 Aug 2015, at 16:27, Anastasia Kuznetsova
> wrote:
>
> Hello all,
>
> Happy to announce that Mistral team is planning to provide "L-3 roadmap
> discussion" meeting on Wednesday ( Aug 12 ).
> Meeting will be in our regular i
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, August 11, 2015 3:10 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and
> glance
>
> On 08/11/2015 09:42 AM, Brian Rosmaita wrote:
> > On 8/7
On 08/11/2015 10:57 AM, Gary Kotton wrote:
On 8/11/15, 5:08 PM, "Jeremy Stanley" wrote:
On 2015-08-11 13:49:37 + (+), Gary Kotton wrote:
This is a stable issue - please see https://review.openstack.org/165750.
This is required to support the plugin developed in Liberty.
[...]
I'm st
Dear PTLs, cross-project liaisons, and interested team members,
We'll have a cross-project meeting today at 21:00 UTC, with the following
agenda:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
* Team announcements (horizontal, vertical, diagonal)
* API Guidelines th
On 8/11/15, 5:08 PM, "Jeremy Stanley" wrote:
>On 2015-08-11 13:49:37 + (+), Gary Kotton wrote:
>> This is a stable issue - please see https://review.openstack.org/165750.
>> This is required to support the plugin developed in Liberty.
>[...]
>
>I'm still missing the connection to stable
The Nova API meeting officially shifted to Tuesday this week, for people
caught off guard by the quick transition, apologies. A bunch of folks
weren't going to be in on Friday anyway, so we decided to start with the
new day right away.
The minutes for the meeting (via meet bot):
Meeting summary
-
Excerpts from Okuma, Wayne's message of 2015-08-11 02:49:28 +:
>
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Monday, August 10, 2015 4:00 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [oslo] Question on oslo_i18n._message
>
> Excerpts fro
hi all,
we have 3 API Guidelines that are ready for final review.
1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/
2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/
3. Clarify the return code when server have hard-code len
On 2015-08-11 13:49:37 + (+), Gary Kotton wrote:
> This is a stable issue - please see https://review.openstack.org/165750.
> This is required to support the plugin developed in Liberty.
[...]
I'm still missing the connection to stable. That review is targeting
master (liberty). Stable cur
On 08/11/2015 09:42 AM, Brian Rosmaita wrote:
On 8/7/15, 1:07 PM, "Jay Pipes" wrote:
So, here's the crux of the issue. Nova and Cinder **do not want to speak
the Glance REST API** to either upload or download image bits from
storage. Streaming image bits through the Glance API endpoint is a
ne
On 08/11/15 at 01:42pm, Brian Rosmaita wrote:
On 8/7/15, 1:07 PM, "Jay Pipes" wrote:
So, here's the crux of the issue. Nova and Cinder **do not want to speak
the Glance REST API** to either upload or download image bits from
storage. Streaming image bits through the Glance API endpoint is a
ne
Hi,
This is a stable issue - please see https://review.openstack.org/165750.
This is required to support the plugin developed in Liberty. It is a bug
too. This is now blocked in L and will also be 50/50 from landing in M. So
will be in the same position again. As a result of the mail sent yesterday
Folks:
To make reviewing all approved work for Liberty-3 in Neutron easier, I've
created a handy dandy gerrit dashboard [1]. What will make this even more
useful is if everyone makes sure to set their topics to something uniform
from their approved LP BP found here [2]. The gerrit dashboard includ
On 8/7/15, 1:07 PM, "Jay Pipes" wrote:
>So, here's the crux of the issue. Nova and Cinder **do not want to speak
>the Glance REST API** to either upload or download image bits from
>storage. Streaming image bits through the Glance API endpoint is a
>needless and inefficient step, and Nova and Cin
This is essentially an access control issue. Ideally the existing access
control mechanism should be sufficient to provide the functionality we
want. If it is not, then it is better to change the underlying access
control system rather than to add a patch to provide this specific bit
of extra funct
On Mon, Aug 10, 2015 at 9:13 PM, Ruby Loo wrote:
> So KISS as much as we can! :)
+1
Cheers,
Serge Kovaleff
http://www.mirantis.com
cell: +38 (063) 83-155-70
__
OpenStack Development Mailing List (not for usage questions)
U
Hello all,
Happy to announce that Mistral team is planning to provide "L-3 roadmap
discussion" meeting on Wednesday ( Aug 12 ).
Meeting will be in our regular irc channel *#openstack-mistral at 12:00 pm
GMT*.
Here you can find what we have for L-3 now:
https://launchpad.net/mistral/+milestone/lib
Igor,
For publishing there specs, as I remember there was a discussion with
openstack-infra root guys some time ago on irc, and Fuel would need to join
“the big tent” [1] and become “an official OpenStack project” [2] first.
[1]
https://www.openstack.org/summit/vancouver-2015/summit-videos/p
Hi everyone,
Yesterday we released implementing Keystone as a Federated Service Provider
as part of the openstack-ansible deployment tooling [1].
This is a starting implementation which was purposefully scoped to only use
Shibboleth and only support SAML2. The scope was limited due to the
complex
On 6 August 2015 at 10:02, David Chadwick wrote:
>
> this is a value judgement that admins take. I think we should allow this
> to be configurable, by either improving the policy engine to allow a
> public access rule (coarse grained), or adding a public/private flag to
> each configured IdP (fin
On Mon, Aug 10 2015, Michael Krotscheck wrote:
Hi Michael,
> It appears that the patch related to this discussion were rushed through
> rather quickly, and without appropriate updates to the documentation. The
> documentation of the library no longer matches the actual functionality,
> and will n
Hi
On 05.08.2015 19:36, Dolph Mathews wrote:
yes this was my understanding of the discussion that took place many
months ago. I had assumed (wrongly) that something had been done about
it, but I guess from your message that we are no further forward on this
Actually 2) above mi
On Tue, 11 Aug 2015, Hochmuth, Roland M wrote:
The minutes for the meetup are at,
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle. If anyone
would like to discuss further or would like further clarification please
let me know.
Thanks for posting that and the linked etherpads.
One t
72 matches
Mail list logo
