This is what I thought of as well. In the rbd driver, if a request to
delete a volume comes in, where the volume object on the backend has other
objects that depend on it, it simply renames it:
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L657
There is also code to
Agreed, we can temporarily pin the version of django_openstack_auth to the
lower version.
发自我的 iPhone
> 在 Jun 22, 2014，11:09，Morgan Fainberg 写道：
>
> I don't think we can revert the change without David's fix. The blocked up
> gate isn't because of PKIZ in this case (it isn't tested from the
I don't think we can revert the change without David's fix. The blocked up
gate isn't because of PKIZ in this case (it isn't tested from the horizon
part) the blocked up gate is because of the broken django_openstack_auth
module.
Could we just tag a new release based upon the commit of the old rel
I'm afraid we have to revert the PKIZ change since devstack is not support
django_openstack_auth now and all patches blocked including David's fix.
发自我的 iPhone
> 在 Jun 22, 2014，5:39，Morgan Fainberg 写道：
>
> Great. This looks like your fix will not require reverting the PKIZ change.
___
Hi Thomas,
This is interesting.
I have some of the basic question about deployment model of using this BaGPipe
BGP in virtual cloud network.
1. We want MPLS to start right from compute node as part Tennant traffic ?
2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
Tena
On Sat, Jun 21, 2014 at 2:27 PM, Morgan Fainberg
wrote:
> The issue with the login page simply refreshing was due to a change in
> Keystone that updated the type of Token issued by default from PKI to PKIZ
> (compressed PKI/ASN1). The update to the django auth module was intended to
> correct tha
Great. This looks like your fix will not require reverting the PKIZ change.
Thanks!
--Morgan
On Saturday, June 21, 2014, Lyle, David wrote:
> I released django_openstack_auth 1.1.6 on Friday to fix the login issue
> with PKIZ. Part of that release contained a pep8 cleanup that broke
> Horizon,
I released django_openstack_auth 1.1.6 on Friday to fix the login issue
with PKIZ. Part of that release contained a pep8 cleanup that broke
Horizon, ultimately because we were doing something stupid in Horizon. We
added a fix to Horizon to correct the issue on trunk
https://github.com/openstack/h
Hello!
We have blueprints here:
https://blueprints.launchpad.net/horizon/+spec/periodic-security-checks
and here:
https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/
And we already have some code. Is it necessary to approve the blueprint
before contributing the code? In any ca
The issue with the login page simply refreshing was due to a change in
Keystone that updated the type of Token issued by default from PKI to PKIZ
(compressed PKI/ASN1). The update to the django auth module was intended to
correct that specific issue with Keystone and Horizon (Juno).
The bug fix (n
Since Friday I have been getting this misbehavior: enter username and
password, hit login, and it shows you the login page again.
Sean Dague --- [openstack-dev] horizon failing on icehouse 100%,
currently
blocking all patches ---
|--+---
On Sat, Jun 21, 2014 at 10:53 AM, Sean Dague wrote:
> Horizon in icehouse is now 100% failing
>
> [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: /
> [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last):
> [Sat Jun 21 16:17:35 2014] [error] File
> "/usr/local/lib/pyth
Horizon in icehouse is now 100% failing
[Sat Jun 21 16:17:35 2014] [error] Internal Server Error: /
[Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last):
[Sat Jun 21 16:17:35 2014] [error] File
"/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 112, in g
> As we knew, Nova db has the table “compute_nodes” for modelling the
> hypervisors and its using the “hypervisor_hostname” field to represent the
> hypervisor name.
>
> This value is having significant value in os-hypervisor extension api which
> is using this field to uniquely identify the hyper
Excerpts from Sean Dague's message of 2014-06-21 05:08:01 -0700:
> On 06/20/2014 09:26 PM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2014-06-20 11:07:39 -0700:
> >>
> >> H803 - First line of a commit message must *not* end in a period. This
> >> was mostly a response to an unreas
On Sat, Jun 21, 2014 at 6:08 AM, Sean Dague wrote:
> https://twitter.com/markmc_/status/480073387600269312
Don't think it needs to be said, but I'm TOTALLY on board with all of the
items Sean pointed out.
___
OpenStack-dev mailing list
OpenStack-dev
On 06/20/2014 09:26 PM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2014-06-20 11:07:39 -0700:
>> After seeing a bunch of code changes to enforce new hacking rules, I'd
>> like to propose dropping some of the rules we have. The overall patch
>> series is here -
>> https://review.open
I am considering to contribute to Neutron but was struggling to find good
documents, thanks for sharing links.
Thanks,
Shiva
On Fri, Jun 20, 2014 at 3:24 AM, Anita Kuno wrote:
> On 06/19/2014 05:47 PM, Mohammad Banikazemi wrote:
> >
> > Have you looked at https://wiki.openstack.org/wiki/Neutr
Hi,
I was intrigued when a cinder volume-type is destroyed completely its queue
still exists until the messaging service is restarted. In my case its
rabbitmq, not sure if it is valid behavior. Kindly let me know.
--
Thanks,
IK
___
OpenStack-dev mailin
19 matches
Mail list logo
