On Sat, Jan 31, 2015 at 03:55:23AM +0100, Vladik Romanovsky wrote:
>
>
> - Original Message -
> > From: "Daniel P. Berrange"
> > To: [email protected],
> > [email protected]
> > Sent: Friday, 30 January, 2015 11:47:16 AM
> > Subject: [openstack-dev]
On Mon, Feb 02, 2015 at 08:24:20AM +1300, Robert Collins wrote:
> On 31 January 2015 at 05:47, Daniel P. Berrange 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 monitors liv
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 wo
Hi,
I've a Havana installation of OpenStack with Neutron.
I've tried the migration from Havana to IceHouse by following this guide:
http://docs.openstack.org/openstack-ops/content/upgrades_havana-icehouse-rhel.html
Keystone, Glance and Nova have migrated correctly (the services are
running and
Thanks
On Mon, Feb 2, 2015 at 4:09 AM, Daniel P. Berrange
wrote:
> 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 sta
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 2/2/2015 11:46 AM, 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 deleted
On 6/5/2014 10:02 AM, Jesse Pretorius wrote:
On 5 June 2014 16:46, Assaf Muller mailto:[email protected]>> wrote:
Keystone started emitting notifications [1] for users and tenants
being created / updated /
deleted during the Havana cycle. This was in response to bug [2],
the f
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
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:
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.
https://www.openstack.org/summit/vancou
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
[...]
sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table
'neutr
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
a
> On 02 Feb 2015, at 20:46, Jesse Keating 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 02 Feb 2015, at 20:54, Kris G. Lindgren 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 the command “… stam
On 2/2/15 12:36 PM, Alvise Dorigo wrote:
On 02 Feb 2015, at 20:46, Jesse Keating 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 up
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg
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 mark it as orphaned
On February 2, 2015 at 1:31:14 PM, Joe Gordon ([email protected]) wrote:
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg
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
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 deleted
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_users_since_x()
So code in nova(any other project) should look like:
keystone_janitor = janitor.Janitor(
get_last_cleanup_timestampt=nova.get_time
+ openstack-operators
On 2/2/15, 12:24 PM, "Jesse Cook"
mailto:[email protected]>> wrote:
Configuration options will change (https://review.openstack.org/#/c/146972/4):
- Removed config option: "swift_enable_snet". The default value of
"swift_enable_snet" was False [1]. The comments in
On 31 January 2015 at 06:18, Eric Windisch 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 be a h
23 matches
Mail list logo
