On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
I think the simple answer is yes. We (keystone) should emit
notifications. And yes other projects should listen.
The only thing really in discussion should be:
1: soft delete or hard delete? Does the service
That¹s what I was thinking as well. I looked at the install guide and it
says to set the stamp using your existing config, then run the db upgrade
using the new config - then do a db migration after db upgrade. I thought
I had read some where that you had to migrate first then upgrade. We were
On 02/02/2015 12:46 PM, Matt Riedemann wrote:
This came up in the operators mailing list back in June [1] but given
the subject probably didn't get much attention.
Basically there is a really old bug [2] from Grizzly that is still a
problem and affects multiple projects. A tenant can be
On 02 Feb 2015, at 20:46, Jesse Keating j...@bluebox.net wrote:
On 2/2/15 5:56 AM, Alvise Dorigo wrote:
For neutron I got a problem at the very last step:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/ml2_conf.ini upgrade icehouse
[...]
On February 2, 2015 at 1:31:14 PM, Joe Gordon (joe.gord...@gmail.com) wrote:
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
I think the simple answer is yes. We (keystone) should emit notifications.
And yes other projects should listen.
The only thing really
On 02 Feb 2015, at 20:54, Kris G. Lindgren klindg...@godaddy.com wrote:
That¹s what I was thinking as well. I looked at the install guide and it
says to set the stamp using your existing config, then run the db upgrade
using the new config
uhm, this is probably what I did wrong !
I ran
On 2/2/15 12:36 PM, Alvise Dorigo wrote:
On 02 Feb 2015, at 20:46, Jesse Keating j...@bluebox.net wrote:
On 2/2/15 5:56 AM, Alvise Dorigo wrote:
For neutron I got a problem at the very last step:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file
This will simplify life of everybody!=)
According to what said Joe I have small suggestion.
Keystone can have next method in API:
get_all_deleted_userstenants_since_x()
So code in nova(any other project) should look like:
keystone_janitor = janitor.Janitor(
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
Thanks for bringing this up, Daniel. I don't think it makes sense to have
a timeout on live migration, but operators should be able to cancel it,
just like any other unbounded long-running process. For example, there's
no
On Sun, Feb 01, 2015 at 03:03:45PM -0700, David Medberry wrote:
I'll second much of what Rob said:
API that indicated how many live-migrations (l-m) were going would be good.
API that told you what progress (and start time) a given l-m had made would
be great.
API to cancel a given l-m would
On Sat, Jan 31, 2015 at 03:55:23AM +0100, Vladik Romanovsky wrote:
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: openstack-...@lists.openstack.org,
openstack-operators@lists.openstack.org
Sent: Friday, 30 January, 2015 11:47:16 AM
Subject:
On Mon, Feb 02, 2015 at 08:24:20AM +1300, Robert Collins wrote:
On 31 January 2015 at 05:47, Daniel P. Berrange berra...@redhat.com wrote:
In working on a recent Nova migration bug
https://bugs.launchpad.net/nova/+bug/1414065
I had cause to refactor the way the nova libvirt driver
On 31 January 2015 at 06:18, Eric Windisch e...@windisch.us wrote:
That's a failing of the Nova team that must be addressed. As maintainers
it is our job to produce software that meets the needs of our users. We
have 35% of users reporting they use this EC2 code, so fixing any problems
should
On Mon, Feb 02, 2015 at 11:46:53AM -0600, Matt Riedemann wrote:
This came up in the operators mailing list back in June [1] but given the
subject probably didn't get much attention.
Basically there is a really old bug [2] from Grizzly that is still a problem
and affects multiple projects. A
I think the simple answer is yes. We (keystone) should emit notifications.
And yes other projects should listen.
The only thing really in discussion should be:
1: soft delete or hard delete? Does the service mark it as orphaned, or just
delete (leave this to nova, cinder, etc to discuss)
2:
This came up in the operators mailing list back in June [1] but given
the subject probably didn't get much attention.
Basically there is a really old bug [2] from Grizzly that is still a
problem and affects multiple projects. A tenant can be deleted in
Keystone even though other resources in
On 6/5/2014 10:02 AM, Jesse Pretorius wrote:
On 5 June 2014 16:46, Assaf Muller amul...@redhat.com
mailto:amul...@redhat.com wrote:
Keystone started emitting notifications [1] for users and tenants
being created / updated /
deleted during the Havana cycle. This was in response to
February 9th is the deadline to submit a talk for the May 2015 Vancouver
Summit
Would you like to speak at the May 2015 OpenStack Summit in Vancouver?
Then hurry up and submit a talk! February 9 is the final day that
speaking submissions will be accepted.
18 matches
Mail list logo
