Re: [openstack-dev] Summit Voting and ATC emails?

[Gary Kotton]

Hi,
Yes, I think that they go out in batches. It would be best to check with
Stefano if you have any issues.
Thanks
Gary

On 2/15/15, 4:11 AM, "Nick Chase"  wrote:

>Does anybody know if a) ATC emails have started to go out yet, and b)
>when proposal voting will start?
>
>Thanks
>
>---  Nick
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] PLUMgrid CI maintenance

[Fawad Khaliq]

Folks,

PLUMgrid CI is down because of unforeseen hardware breakdown issues. We are
working on getting it sorted out asap. I will respond to this thread when
it's back up.

Thanks,
Fawad Khaliq
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] [glance] conclusion needed on functional API

[Brian Rosmaita]

This is a follow-up to the discussion at the 12 February API-WG meeting
[1] concerning "functional" API in Glance [2].  We made some progress, but
need to close this off so the spec can be implemented in Kilo.

I believe this is where we left off:
1. The general consensus was that POST is the correct verb.

2. Did not agree on what to POST.  Three options are in play:
(A) POST /images/{image_id}?action=deactivate
POST /images/{image_id}?action=reactivate

(B) POST /images/{image_id}/actions
with payload describing the action, e.g.,
{ "action": "deactivate" }
{ "action": "reactivate" }

(C) POST /images/{image_id}/actions/deactivate
POST /images/{image_id}/actions/reactivate

The spec proposes to use (C), following the discussion at the Atlanta
summit.

As a quick summary of why (C) was proposed (since all the above were
actually discussed at the summit), I'd like to quote from Hemanth's ML
posting right after the summit [4]:

1. Discoverability of operations.  It'll be easier to expose permitted
actions through schemas [or] a json home document living at
/images/{image_id}/actions/.
2. More conducive for rate-limiting. It'll be easier to rate-limit actions
in different ways if the action type is available in the URL.
3. Makes more sense for functional actions that don't require a request
body (e.g., image deactivation).

If you have a strong opinion, please reply to this message, and I will
report on the conclusion at the API-WG meeting at 00:00 UTC on 2015-02-19
[5].  This will be the third API-WG meeting at which this topic was
discussed; I would really like to see us reach a conclusion at this
meeting.

Thank you!

[1] 
http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-12-16.00
.log.html
[2] https://review.openstack.org/#/c/135122
[3] 
https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api
[4] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036416.html
[5] https://wiki.openstack.org/wiki/Meetings/API-WG


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Morgan Fainberg]

On February 14, 2015 at 9:53:14 PM, Adam Young (ayo...@redhat.com) wrote:
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@gmail.com) wrote:
Hello all, 


I'm proposing the Authenticated Encryption (AE) Token specification [1] as an 
SPFE. AE tokens increases scalability of Keystone by removing token 
persistence. This provider has been discussed prior to, and at the Paris summit 
[2]. There is an implementation that is currently up for review [3], that was 
built off a POC. Based on the POC, there has been some performance analysis 
done with respect to the token formats available in Keystone (UUID, PKI, PKIZ, 
AE) [4]. 

The Keystone team spent some time discussing limitations of the current POC 
implementation at the mid-cycle. One case that still needs to be addressed (and 
is currently being worked), is federated tokens. When requesting unscoped 
federated tokens, the token contains unbound groups which would need to be 
carried in the token. This case can be handled by AE tokens but it would be 
possible for an unscoped federated AE token to exceed an acceptable AE token 
length (i.e. < 255 characters). Long story short, a federation migration could 
be used to ensure federated AE tokens never exceed a certain length. 

Feel free to leave your comments on the AE Token spec. 

Thanks! 

Lance

[1] https://review.openstack.org/#/c/130050/
[2] https://etherpad.openstack.org/p/kilo-keystone-authorization
[3] https://review.openstack.org/#/c/145317/
[4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
__ 
OpenStack Development Mailing List (not for usage questions) 
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 


I am for granting this exception as long as it’s clear that the following is 
clear/true:

* All current use-cases for tokens (including federation) will be supported by 
the new token provider.

* The federation tokens being possibly over 255 characters can be addressed in 
the future if they are not addressed here (a “federation migration” does not 
clearly state what is meant.

I think the length of the token is not a real issue.  We need to keep them 
within header lengths.  That is 8k.  Anything smaller than that will work.

I think we start with  federation usncoped tokens allowing a list of groups.  
These tokens only go back and forth from user to Keyston anyway, and should not 
got to other services.


Scoped tokens via Federation (iirc this is possible) could end up including the 
groups. I think you hit the nail on the head though, the 255 limit is 
artificial, and we’ve made a lot of efforts here to limit the token size 
already. These tokens need to handle 100% of the current token use cases, and 
limiting federated tokens to unscoped only is likely going to break that 
requirement. Future enhancements can ensure federated tokens fall below the 255 
character limit (IIRC Dolph said he had a fix for this but it’s not something 
that can hit Kilo and will be proposed in the future).

I also have a concernt with the requirement for new cryptoloy.  Specificcally, 
the requirement for symmetric crypto and Keys management can be a s ignificant 
barrier to organizations that have to meet compliance rules.  Since PKI tokens 
have already forced this issue, I suggest we switch AE tokens to using PKI 
instead of symmetric crypto for the default case.  Putting in an optimization 
that uses symmetric crypto as an enhancement should then be a future 
enhancement.  Asymmetric crypto will mitigate the issues with multiple keystone 
servers sharing keys, and will remove the need for a key sharing mechanism.  
Since this mechanism is in Keystone already, I think it is a realistic approach.


I would rather see this spec crypto all together and strictly rely on HMAC with 
any form of crypto (Asymmetric or Symmetric) being the addon. I am worried if 
we go down the path of starting with PKI (or even symmetric crypto) instead of 
just HMAC signature validation (live-validated such as what keystone does today 
with UUID tokens) we are going to back ourselves into a similar corner we’re in 
today.

I agree that adding new crypto and key management is a good deal more overhead 
than the basic implementation. As I commented on the spec, I’m not sure 
encryption is buying us a lot here. So, lets make the adjustment to avoid 
encrypting data and rely on the UUID validation mode utilizing HMAC signatures 
(keystone owns the keys) with future enhancements to add in the actual 
encryption (in any form). Requiring ASN1 signed data would also not really the 
low opportunity cost this spec is trying to be. This eliminates easy 
multiple-signer deployments but can be an addon once the core is in place.

—Morgan


__

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Adam Young]

On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad 
(lbrags...@gmail.com ) wrote:

Hello all,


I'm proposing the Authenticated Encryption (AE) Token specification 
[1] as an SPFE. AE tokens increases scalability of Keystone by 
removing token persistence. This provider has been discussed prior 
to, and at the Paris summit [2]. There is an implementation that is 
currently up for review [3], that was built off a POC. Based on the 
POC, there has been some performance analysis done with respect to 
the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].


The Keystone team spent some time discussing limitations of the 
current POC implementation at the mid-cycle. One case that still 
needs to be addressed (and is currently being worked), is federated 
tokens. When requesting unscoped federated tokens, the token contains 
unbound groups which would need to be carried in the token. This case 
can be handled by AE tokens but it would be possible for an unscoped 
federated AE token to exceed an acceptable AE token length (i.e. < 
255 characters). Long story short, a federation migration could be 
used to ensure federated AE tokens never exceed a certain length.


Feel free to leave your comments on the AE Token spec.

Thanks!

Lance

[1] https://review.openstack.org/#/c/130050/
[2] https://etherpad.openstack.org/p/kilo-keystone-authorization
[3] https://review.openstack.org/#/c/145317/
[4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I am for granting this exception as long as it’s clear that the 
following is clear/true:


* All current use-cases for tokens (including federation) will be 
supported by the new token provider.


* The federation tokens being possibly over 255 characters can be 
addressed in the future if they are not addressed here (a “federation 
migration” does not clearly state what is meant.


I think the length of the token is not a real issue.  We need to keep 
them within header lengths.  That is 8k.  Anything smaller than that 
will work.


I think we start with  federation usncoped tokens allowing a list of 
groups.  These tokens only go back and forth from user to Keyston 
anyway, and should not got to other services.


I also have a concernt with the requirement for new cryptoloy. 
Specificcally, the requirement for symmetric crypto and Keys management 
can be a s ignificant barrier to organizations that have to meet 
compliance rules.  Since PKI tokens have already forced this issue, I 
suggest we switch AE tokens to using PKI instead of symmetric crypto for 
the default case.  Putting in an optimization that uses symmetric crypto 
as an enhancement should then be a future enhancement.  Asymmetric 
crypto will mitigate the issues with multiple keystone servers sharing 
keys, and will remove the need for a key sharing mechanism.  Since this 
mechanism is in Keystone already, I think it is a realistic approach.


Symmetric crypto when coupled with the needs to have multiple Keystones 
signing tokens is going to require something like Kite, which is not 
part of the core OpenStack services.  We don't currently rely on a key 
sharing mechanism and I don't think this feature is worth forcing that 
on the deployers.


I think with those two adjustments, AE tokens should be able to progress.


I am also ok with the AE token work being re-ordered ahead of the 
provider cleanup to ensure it lands. Fixing the AE Token provider 
along with PKI and UUID providers should be minimal extra work in the 
cleanup.


This addresses a very, very big issue within Keystone as scaling 
scaling up happens. There has been demand for solving token 
persistence for ~3 cycles. The POC code makes this exception possible 
to land within Kilo, whereas without the POC this would almost 
assuredly need to be held until the L-Cycle.



TL;DR, I am for the exception if the AE Tokens support 100% of the 
current use-cases of tokens (UUID or PKI) today.



—Morgan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] documenting volume replication

[yang, xing]

Hi Ruijing,

I've already created another etherpad for replication and CG integration.  It 
is referenced at the end of the replication etherpad that Ronen created.  I can 
move the content to the replication one if that is easier.
https://etherpad.openstack.org/p/cinder-replication-cg

I can help you add your other comments to the replication etherpad.

Thanks,
Xing


From: Guo, Ruijing [mailto:ruijing@intel.com]
Sent: Saturday, February 14, 2015 8:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] documenting volume replication

Hi, Ronen,

I don't know how to edit 
https://etherpad.openstack.org/p/cinder-replication-redoc and add some comments 
in email.


1. We may add asynchronized and synchronized type for replication.

2. We may add CG for replication

3. We may add to initialize connection for replication

Thanks,
-Ruijing

From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

As some of you are aware the spec for replication is not up to date,
The current developer documentation, 
http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html, cover 
replication but some folks indicated that it need additional details.

In order to get the spec and documentation up to date I created an Etherpad to 
be a base for the update.
The Etherpad page is on 
https://etherpad.openstack.org/p/cinder-replication-redoc

I would appreciate if interested parties would take a look at the Etherpad, add 
comments, details, questions and feedback.

Ronen,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Kilo Deadlines

[Mike Perez]

On Sat, Jan 31, 2015 at 1:53 PM, Mike Perez  wrote:
> * Blueprint/Spec approval deadline - February 15th
> * Code freeze for all features - March 10th
>
> After blueprint/spec approval deadline date has passed, you may
> request exception by:
>
> 1) Email the Openstack Dev mailing list with "[cinder] Request Spec
> Freeze Exception" in the subject.
> 2) The spec is reviewed the usual way, but should be a high priority to get 
> in.
>
> These deadlines were agreed on in the Cinder IRC meeting [1].
>
> --
> Mike Perez
>
> [1] - 
> http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303

February 15th is the last day to get a feature proposed for Kilo in
Cinder. Any blueprints that are not approved after February 15th will
need to request Feature Freeze Exception on this list, with the
subject "[cinder] FFE ". Yes, I changed the format, and
we are terribly oversubscribed as it is.

At this point I've gone through specs and left comments on the ones
that I think that have a chance in Kilo.

A blueprint will be removed from K-3 [1] if it does not have code
proposed and passing Jenkins by March 1st as agreed in the Cinder
meeting [2].

We will not be doing anymore merges, except for bug fixes after March
10th, as explained earlier in this thread and agreed in the Cinder
meeting [3].

Cinder K-3 priorities have been set for people to sign up on [4].

[1] - https://launchpad.net/cinder/+milestone/kilo-3
[2] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-11-16.00.log.html#l-328
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-303
[4] - https://etherpad.openstack.org/p/cinder-k3-priorities

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Depraction of the auth_token fragments

[Morgan Fainberg]

On February 14, 2015 at 5:59:13 PM, Clint Byrum (cl...@fewbar.com) wrote:
Excerpts from Thomas Goirand's message of 2015-02-14 16:48:01 -0800:  
> Hi,  
>  
> I've seen messages in the logs telling that we should move to the  
> identity_uri.  
>  
> I don't really like the identity_uri which contains all of the  
> information in a single directive, which means that a script that would  
> edit it would need a lot more parsing work than simply a key/value pair  
> logic. This is error prone. The fragments don't have this issue.  
>  
> So, could we decide to:  
> 1/ Not remove the auth fragments  
> 2/ Remove the deprecation warnings  
>  

Automation has tended away from parsing and editting files in place for  
a long time now. Typically you'd have a source of truth with all the  
values, and a tool to turn that into a URL during file generation. This  
isn't error prone in my experience.  

I don't really know why the single URL is preferred, but I don't think  
the argument that "it makes parsing and editting the config file with  
external tools" is strong enough to roll this deprecation back.  


As far as I know this is a move to avoid needing many configuration values to 
figure out how to communicate with Keystone. With the addition of better 
discovery, the auth fragements actually make the job of knowing what to do much 
more complex (we have to reconstruct them into a URI anyway). This should be a 
move towards being able to ask Keystone what it supports and discover how to 
interact with it/auth against it from that standpoint instead of needing the 
multiple fragments.

Thomas, Can you be more specific about what use-case you’re running into that 
makes the fragments better (instead of a URI form such as the SQL connection 
string would be)? As Clint outlined, you tend to have a single source of truth 
in most tools and do not do editing of files in-place (I’d even go as far as to 
assert that editing a file in-place is always prone to errors/has a high level 
of parsing needed and shouldn’t be done).

Thanks!
—Morgan__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Summit Voting and ATC emails?

[Amrith Kumar]

I've got my ATC mail and registration code. No idea about proposal voting.

-amrith

| -Original Message-
| From: Nick Chase [mailto:nch...@mirantis.com]
| Sent: Saturday, February 14, 2015 9:11 PM
| To: openstack-dev@lists.openstack.org
| Subject: [openstack-dev] Summit Voting and ATC emails?
| 
| Does anybody know if a) ATC emails have started to go out yet, and b) when
| proposal voting will start?
| 
| Thanks
| 
| ---  Nick
| 
| __
| OpenStack Development Mailing List (not for usage questions)
| Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Summit Voting and ATC emails?

[Nick Chase]

Does anybody know if a) ATC emails have started to go out yet, and b) 
when proposal voting will start?


Thanks

---  Nick

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Depraction of the auth_token fragments

[Clint Byrum]

Excerpts from Thomas Goirand's message of 2015-02-14 16:48:01 -0800:
> Hi,
> 
> I've seen messages in the logs telling that we should move to the
> identity_uri.
> 
> I don't really like the identity_uri which contains all of the
> information in a single directive, which means that a script that would
> edit it would need a lot more parsing work than simply a key/value pair
> logic. This is error prone. The fragments don't have this issue.
> 
> So, could we decide to:
> 1/ Not remove the auth fragments
> 2/ Remove the deprecation warnings
> 

Automation has tended away from parsing and editting files in place for
a long time now. Typically you'd have a source of truth with all the
values, and a tool to turn that into a URL during file generation. This
isn't error prone in my experience.

I don't really know why the single URL is preferred, but I don't think
the argument that "it makes parsing and editting the config file with
external tools" is strong enough to roll this deprecation back.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] documenting volume replication

[Guo, Ruijing]

Hi, Ronen,

I don't know how to edit 
https://etherpad.openstack.org/p/cinder-replication-redoc and add some comments 
in email.


1. We may add asynchronized and synchronized type for replication.

2. We may add CG for replication

3. We may add to initialize connection for replication

Thanks,
-Ruijing

From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

As some of you are aware the spec for replication is not up to date,
The current developer documentation, 
http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html, cover 
replication but some folks indicated that it need additional details.

In order to get the spec and documentation up to date I created an Etherpad to 
be a base for the update.
The Etherpad page is on 
https://etherpad.openstack.org/p/cinder-replication-redoc

I would appreciate if interested parties would take a look at the Etherpad, add 
comments, details, questions and feedback.

Ronen,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Depraction of the auth_token fragments

[Thomas Goirand]

Hi,

I've seen messages in the logs telling that we should move to the
identity_uri.

I don't really like the identity_uri which contains all of the
information in a single directive, which means that a script that would
edit it would need a lot more parsing work than simply a key/value pair
logic. This is error prone. The fragments don't have this issue.

So, could we decide to:
1/ Not remove the auth fragments
2/ Remove the deprecation warnings

Thoughts anyone?

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Update on "DB" IPAM driver

[Carl Baldwin]

On Thu, Feb 12, 2015 at 6:36 AM, Salvatore Orlando  wrote:
> - I agree with Carl that the IPAM driver should not have explicit code paths
> for autoaddress subnets, such as DHCPv6 stateless ones. In that case, the
> consumer of the driver will generate the address and then to the IPAM driver
> that would just be allocation of a specific address. However, I have the
> impression the driver still needs to be aware of whether the subnet has an
> automatic address mode or not - since in this case 'any' address allocation
> won't be possible. There already comments about this in the review [1]

I had another thought on this.  You say that "any address allocation
won't be possible".  I wonder if this is really true.  The EUI-64
space is only one part in 64k of total /64 space.  IPAM could allocate
from the rest.  There could be use cases for mixed modes in the
future.

I think best practice for any IPAM should be to steer clear of
allocating address which could be EUI-64 addresses.  Even if it
ignores it completely, what are the chances that IPAM will allocate
from that sub-space *and* allocate an address that would conflict?
I'd say pretty low.  If it did happened, IPAM would reject the address
computed and the port create would fail I think.  You'd try again and
it would likely succeed.  I may be over-simplifying.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Update on "DB" IPAM driver

[Carl Baldwin]

On Feb 13, 2015 5:54 AM, "Salvatore Orlando"  wrote:

> - Considering an alternative to availability ranges. Pre-generation of IP
entries is unpractical (think IPv6), so that's not an option.
Unfortunately, I have not yet explored in detail this route.

The availability range stuff is hard.  I was talking about it with Ryan
Tidwell last week.  I actually wonder if it would be much worse to just
load all of the allocations and compute availability on demand.  It seems
drastic and probably isn't better but that is how bad storing and
maintaining availability is in the db.

I suspect it will be more difficult for subnet allocation.

Would you consider an alternative that pregenerated up to N entries and
kept a flag on allocations stating whether they are in use or can be
recycled?

Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Update on "DB" IPAM driver

[Carl Baldwin]

I must have archived this on accident.  Sorry to not respond earlier.
Comments inline...

On Feb 12, 2015 6:40 AM, "Salvatore Orlando"  wrote:
> I have updated the patch; albeit not complete yet it's kind of closer to
be an allocator decent enough to replace the built-in logic.

I hope to look at it soon.  Thanks for your work here.

> I will be unable to attend today's L3/IPAM meeting due to a conflict, so
here are some highlights from me on which your feedback is more than
welcome:

We missed you.

> - I agree with Carl that the IPAM driver should not have explicit code
paths for autoaddress subnets, such as DHCPv6 stateless ones. In that case,
the consumer of the driver will generate the address and then to the IPAM
driver that would just be allocation of a specific address. However, I have
the impression the driver still needs to be aware of whether the subnet has
an automatic address mode or not - since in this case 'any' address
allocation won't be possible. There already comments about this in the
review [1]

Good point.

> - We had a discussion last week on whether the IPAM driver and neutron
should 'share' database tables. I went back and forth a lot of time, but
now to me it seems the best thing to do is to have the IPAM driver maintain
an 'ip_requests' tables, where it stores allocation info. This table
partially duplicates data in IPAllocation, but on the plus side it makes
the IPAM driver self sufficient. The next step would be to decide whether
we want to go a step further and also assume the driver should not access
at all Neutron's DB, but I would defer that discussion to the next
iteration (for both the driver and the IPAM interface)

I like this.  It is how I was leaning too.

> - I promised a non blocking algorithm for IP allocation. The one I was
developing was based on specifying the primary key on the ip_requests table
in a way that it would prevent two concurrent requests from getting the
same address, and would just retry getting an address until the primary key
constraint was satisfied. However, recent information emerged on MySQL
galera's (*) data set [2] certification  clarified that this kind of
algorithm would still result in a deadlock error from failed data set
certification. It is worth noting that in this case a solution based on
traditional compare-and-swap is not possible because concurrent requests
would be inserting data at the same time. I am now working on an
alternative solution, and I would like to first implement a PoC for it (so
that I can prove it works).

Hmm.  Didn't see that coming.

> - The db base refactoring being performed by Pavel is under way [3]. It
is worth noting that this is a non-negligible change to some of Neutron's
basic and more critical workflows. We should expect pushback from the
community regarding the introduction of this change in the 3rd milestone.
At this stage I would suggest either:
> A) consider a strategy for running pluggable IPAM as optional

Looking at Pavel's code, it appears it is optional in its current state.
It seems to leave all of the existing code in place.  The if/then/else
statements make me want to pull my hair out but if it is just a temporary
strategy to mitigate risk them I guess I could tolerate it until Liberty.

> B) consider delaying to Liberty.
> (and that's where I get virtually jeered and pelted with rotten tomatoes)

I think we still have time maybe with risk mitigation from A.  I'm not
ready to give up yet!

Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: [Neutron][DVR]Neutron distributed SNAT

[Carl Baldwin]

On Feb 10, 2015 2:36 AM, "Wilence Yao"  wrote:
>
>
> Hi all,
>   After OpenStack Juno, floating ip is handled by dvr, but SNAT is still
handled by l3agent on network node. The distributed SNAT is in future plans
for DVR. In my opinion, SNAT can move to DVR as well as floating ip. I have
searched in blueprint, there is little  about distributed SNAT. Is there
any different between distributed floating ip and distributed SNAT?

The difference is that a shared snat address is shared among instances on
multiple compute nodes.  A floating ip is exclusive to a single instance on
one compute node.  I'm interested to hear your ideas for distributing it.

Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron[[L2-Gateway] No meeting this week due to USA holiday

[Sukhdev Kapur]

Folks,

We are canceling the meeting on Monday (2/16/2015) due to USA holiday. The
meeting will take place the following week Monday (2/23/2015).
The agenda for next week's meeting will be posted at -
https://wiki.openstack.org/wiki/Meetings/L2Gateway


Thanks
-Sukhdev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] FFE request for vmware-driver-domain-metadata

[Gary Kotton]

Hi,
This support was added to the libvirt driver in J. The support is isolated to 
the Vmware driver and enables admins to get a better understanding of what is 
happening with the running instances. Any chance of getting a sponsor for this? 
https://review.openstack.org/#/c/141028/
This also enables the admin to do queries on the VC about instances, for 
example by AZ, flavor, etc.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Missing column in Gerrit overview page showing a -1 review after/with a +2 review

[Anita Kuno]

On 02/14/2015 07:12 AM, Romil Gupta wrote:
> Awesome, I like the idea.
> 
> On Sat, Feb 14, 2015 at 3:18 PM, Christian Berendt 
> wrote:
> 
>> At the moment there are three columns in the Gerrit overiew page showing
>> the status of a review request:
>>
>> * CR (Code-Review)
>> * V (Verified)
>> * Workflow (WF).
>>
>> After a core reviewer +2 (CR) a review request there will be a green
>> hook in the CR column in the overview page, regardless of -1 reviews.
>>
>> Sometimes I do not have the time to have a look in my Gerrit mail
>> folder. Sometimes I do not have the time to manually monitor pending
>> review requests. This is why I sometimes miss a new -1 of a reviewer
>> because it is not shown in the Gerrit overview page when there is
>> already a +2 of a core reviewer. Also a +2 of a core reviewer will
>> "overwrite" an existing -1 in the Gerrit overview page. Sometimes I do
>> not have the time to remove my +2 after a new -1 (at the moment it is
>> necessary to remove a +2 after a new -1 to be able to see the new -1 on
>> the Gerrit overview page).
>>
>> I would really like to have a fourth column in the Gerrit overview page
>> showing a -1 on a review request even if there is already a +2 of a core
>> reviewer.
>>
>> What do you think about this?
>>
>> And if this idea is appreciated how can this fourth column be added to
>> the Gerrit overview page?
>>
>> Christian.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Using gerrit queries might come in handy here.

https://review.openstack.org/Documentation/user-search.html

For a start, this gets me all reviews that are open for which I am not
the author, where I voted +1 (or better) and someone else voted -1 (or
lower). I just gave it a quick test to try it out, it might need refining.

NOT owner:self status:open label:Code-Review>=+1,self label:Code-Review<=-1

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Missing column in Gerrit overview page showing a -1 review after/with a +2 review

[Romil Gupta]

Awesome, I like the idea.

On Sat, Feb 14, 2015 at 3:18 PM, Christian Berendt 
wrote:

> At the moment there are three columns in the Gerrit overiew page showing
> the status of a review request:
>
> * CR (Code-Review)
> * V (Verified)
> * Workflow (WF).
>
> After a core reviewer +2 (CR) a review request there will be a green
> hook in the CR column in the overview page, regardless of -1 reviews.
>
> Sometimes I do not have the time to have a look in my Gerrit mail
> folder. Sometimes I do not have the time to manually monitor pending
> review requests. This is why I sometimes miss a new -1 of a reviewer
> because it is not shown in the Gerrit overview page when there is
> already a +2 of a core reviewer. Also a +2 of a core reviewer will
> "overwrite" an existing -1 in the Gerrit overview page. Sometimes I do
> not have the time to remove my +2 after a new -1 (at the moment it is
> necessary to remove a +2 after a new -1 to be able to see the new -1 on
> the Gerrit overview page).
>
> I would really like to have a fourth column in the Gerrit overview page
> showing a -1 on a review request even if there is already a +2 of a core
> reviewer.
>
> What do you think about this?
>
> And if this idea is appreciated how can this fourth column be added to
> the Gerrit overview page?
>
> Christian.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
*Regards,*

*Romil *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Ask for help with devstack error: "401 Unauthorized"

[liuxinguo]

I have seen the review you provided, but I think there is no relationship to 
our problem.
All keystone commands like “keystone user-list”, “keystone role-list”, 
“keystone tenant-list” and “eystone user-role-list --user admin --tenant 
admin‍” is ok.
But all the other command returned “Unauthorized”

This is the result of  “cinder --debug list”:

DEBUG:keystoneclient.session:REQ: curl -g -i -X GET http://127.0.0.1:35357/v2.0 
-H "Accept: application/json" -H "User-Agent: python-keystoneclient"
DEBUG:keystoneclient.session:RESP: [200] date: Sat, 14 Feb 2015 11:36:33 GMT 
vary: X-Auth-Token content-length: 336 content-type: application/json server: 
Apache/2.4.7 (Ubuntu)
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
[{"href": "http://127.0.0.1:35357/v2.0/";, "rel": "self"}, {"href": 
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to 
http://127.0.0.1:35357/v2.0/tokens
DEBUG:keystoneclient.session:REQ: curl -g -i -X GET 
http://127.0.0.1:8776/v1/12308951ebca4eac84d20e00d4d55d72/volumes/detail -H 
"User-Agent: python-cinderclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}4dfb792bb390a91d23b351b05d54db226982f6ef"
DEBUG:keystoneclient.session:RESP:
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to 
http://127.0.0.1:35357/v2.0/tokens
DEBUG:keystoneclient.session:RESP:
DEBUG:keystoneclient.session:Request returned failure status: 401
ERROR: Unauthorized (HTTP 401) (Request-ID: 
req-209c999b-77b5-4677-94bb-10e6419b8c1e)

And the cinder-api.log:

2015-02-14 03:37:48.779 18036 INFO eventlet.wsgi.server [-] (18036) accepted 
('127.0.0.1', 49278)
2015-02-14 03:37:48.781 18036 DEBUG keystoneclient.auth.identity.v2 [-] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens get_auth_ref 
/opt/stack/new/python-keystoneclient/keystoneclient/auth/identity/v2.py:76
2015-02-14 03:37:48.783 18036 DEBUG urllib3.util.retry [-] Converted retries 
value: 0 -> Retry(total=0, connect=None, read=None, redirect=0) from_int 
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-14 03:37:48.792 18036 DEBUG keystoneclient.session [-] Request returned 
failure status: 400 request 
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:383
2015-02-14 03:37:48.793 18036 ERROR keystonemiddleware.auth_token [-] Bad 
response code while validating token: 400
2015-02-14 03:37:48.794 18036 WARNING keystonemiddleware.auth_token [-] 
Identity response: {"error": {"message": "Expecting to find username or userId 
in passwordCredentials - the server could not comply with the request since it 
is either malformed or otherwise incorrect. The client is assumed to be in 
error.", "code": 400, "title": "Bad Request"}}
2015-02-14 03:37:48.794 18036 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token
2015-02-14 03:37:48.796 18036 INFO eventlet.wsgi.server [-] 127.0.0.1 - - 
[14/Feb/2015 03:37:48] "GET /v1/12308951ebca4eac84d20e00d4d55d72/volumes/detail 
HTTP/1.1" 401 257 0.014834
2015-02-14 03:37:49.140 18036 DEBUG keystoneclient.auth.identity.v2 [-] Making 
authentication request to http://127.0.0.1:35357/v2.0/tokens get_auth_ref 
/opt/stack/new/python-keystoneclient/keystoneclient/auth/identity/v2.py:76
2015-02-14 03:37:49.142 18036 DEBUG urllib3.util.retry [-] Converted retries 
value: 0 -> Retry(total=0, connect=None, read=None, redirect=0) from_int 
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-14 03:37:49.150 18036 DEBUG keystoneclient.session [-] Request returned 
failure status: 400 request 
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:383
2015-02-14 03:37:49.151 18036 ERROR keystonemiddleware.auth_token [-] Bad 
response code while validating token: 400
2015-02-14 03:37:49.152 18036 WARNING keystonemiddleware.auth_token [-] 
Identity response: {"error": {"message": "Expecting to find username or userId 
in passwordCredentials - the server could not comply with the request since it 
is either malformed or otherwise incorrect. The client is assumed to be in 
error.", "code": 400, "title": "Bad Request"}}
2015-02-14 03:37:49.153 18036 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token
2015-02-14 03:37:49.154 18036 INFO eventlet.wsgi.server [-] 127.0.0.1 - - 
[14/Feb/2015 03:37:49] "GET /v1/12308951ebca4eac84d20e00d4d55d72/volumes/detail 
HTTP/1.1" 401 257 0.014599‍

How should I do next to fix this?

发件人: Peter Stachowski [mailto:pe...@tesora.com]
发送时间: 2015年2月12日 23:32
收件人: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
抄送: Zhangli (ISSP); Fanyaohong; Chenzongliang
主题: Re: [OpenStack-Infra] [all] Ask for help with devstack error

Hi,

Take a look at this commit, it broke a number 

[openstack-dev] Missing column in Gerrit overview page showing a -1 review after/with a +2 review

[Christian Berendt]

At the moment there are three columns in the Gerrit overiew page showing
the status of a review request:

* CR (Code-Review)
* V (Verified)
* Workflow (WF).

After a core reviewer +2 (CR) a review request there will be a green
hook in the CR column in the overview page, regardless of -1 reviews.

Sometimes I do not have the time to have a look in my Gerrit mail
folder. Sometimes I do not have the time to manually monitor pending
review requests. This is why I sometimes miss a new -1 of a reviewer
because it is not shown in the Gerrit overview page when there is
already a +2 of a core reviewer. Also a +2 of a core reviewer will
"overwrite" an existing -1 in the Gerrit overview page. Sometimes I do
not have the time to remove my +2 after a new -1 (at the moment it is
necessary to remove a +2 after a new -1 to be able to see the new -1 on
the Gerrit overview page).

I would really like to have a fourth column in the Gerrit overview page
showing a -1 on a review request even if there is already a +2 of a core
reviewer.

What do you think about this?

And if this idea is appreciated how can this fourth column be added to
the Gerrit overview page?

Christian.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens

[Henry Nash]

So I’m Ok with an exception for this, but still have reservations of the this 
AE technique (at least the one that is currently proposed). I assume this will 
be marked as experimental - since we have not formally agreed that this is a 
standard we want to lock into core?

Henry
> On 14 Feb 2015, at 05:09, Lin Hua Cheng  wrote:
> 
> ++ One of the feature that I am looking forward to see in Kilo, this feature 
> will solve one of the pain points from operators in maintaining the token db 
> backend.
> 
> -Lin
> 
> On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli  > wrote:
> It would be great to see this land in Kilo, I'll definitely be willing to 
> review the code. 
> 
> Steve 
> 
> Morgan Fainberg  > wrote on 02/13/2015 04:19:15 PM:
> 
> > From: Morgan Fainberg  > > 
> > To: Lance Bragstad mailto:lbrags...@gmail.com>>, 
> > "OpenStack Development 
> > Mailing List (not for usage questions)"  > > 
> > Date: 02/13/2015 04:24 PM 
> > Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated 
> > Encryption (AE) Tokens 
> > 
> > On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@gmail.com 
> > 
> > ) wrote:
> 
> > Hello all, 
> > 
> > I'm proposing the Authenticated Encryption (AE) Token specification 
> > [1] as an SPFE. AE tokens increases scalability of Keystone by 
> > removing token persistence. This provider has been discussed prior 
> > to, and at the Paris summit [2]. There is an implementation that is 
> > currently up for review [3], that was built off a POC. Based on the 
> > POC, there has been some performance analysis done with respect to 
> > the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4]. 
> > 
> > The Keystone team spent some time discussing limitations of the 
> > current POC implementation at the mid-cycle. One case that still 
> > needs to be addressed (and is currently being worked), is federated 
> > tokens. When requesting unscoped federated tokens, the token 
> > contains unbound groups which would need to be carried in the token.
> > This case can be handled by AE tokens but it would be possible for 
> > an unscoped federated AE token to exceed an acceptable AE token 
> > length (i.e. < 255 characters). Long story short, a federation 
> > migration could be used to ensure federated AE tokens never exceed a
> > certain length. 
> > 
> > Feel free to leave your comments on the AE Token spec. 
> > 
> > Thanks! 
> > 
> > Lance 
> > 
> > [1] https://review.openstack.org/#/c/130050/ 
> >  
> > [2] https://etherpad.openstack.org/p/kilo-keystone-authorization 
> >  
> > [3] https://review.openstack.org/#/c/145317/ 
> >  
> > [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ 
> >  
> > __ 
> > OpenStack Development Mailing List (not for usage questions) 
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> >  
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> >  
> > 
> > I am for granting this exception as long as it’s clear that the 
> > following is clear/true: 
> > * All current use-cases for tokens (including federation) will be 
> > supported by the new token provider. 
> > * The federation tokens being possibly over 255 characters can be 
> > addressed in the future if they are not addressed here (a 
> > “federation migration” does not clearly state what is meant. 
> > I am also ok with the AE token work being re-ordered ahead of the 
> > provider cleanup to ensure it lands. Fixing the AE Token provider 
> > along with PKI and UUID providers should be minimal extra work in the 
> > cleanup. 
> > This addresses a very, very big issue within Keystone as scaling 
> > scaling up happens. There has been demand for solving token 
> > persistence for ~3 cycles. The POC code makes this exception 
> > possible to land within Kilo, whereas without the POC this would 
> > almost assuredly need to be held until the L-Cycle. 
> > 
> > TL;DR, I am for the exception if the AE Tokens support 100% of the 
> > current use-cases of tokens (UUID or PKI) today. 
> > 
> > —Morgan
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo

[openstack-dev] [Fuel] [UI] Sorting and filtering of node list

[Julia Aranovich]

Hi All,

Currently we [Fuel UI team] are planning the features of *sorting and
filtering of node list *to introduce it in 6.1 release.

Now user can filter nodes just by it's name or MAC address and no sorters
are available. It's rather poor UI for managing 200+ nodes environment. So,
the current suggestion is to filter and sort nodes by the following
parameters:

   1. name
   2. manufacturer
   3. IP address
   4. MAC address
   5. CPU
   6. memory
   7. disks total size (we need to think about "less than"/"more than"
   representation)
   8. interfaces speed
   9. status (Ready, Pending Addition, Error, etc.)
   10. roles


It will be a form-based filter. Items [1-4] should go to a single text
input and other go to a separate controls.
And also there is an idea to translate a user filter selection to a query
and add it to a location string. Like it's done for the logs search:
*#cluster/x/logs/type:local;source:api;level:info*.

Please also note, that the changes we are thinking about should not affect
backend code.


I will be very grateful if you share your ideas about this or tell some of
the cases that would be useful to you at work with real deployments.
We would like to introduce really usefull tools based on your feedback.


Best regards,
Julia

-- 
Kind Regards,
Julia Aranovich,
Software Engineer,
Mirantis, Inc
+7 (905) 388-82-61 (cell)
Skype: juliakirnosova
www.mirantis.ru
jaranov...@mirantis.com 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev