[openstack-dev] [libraries] gate-tempest-dsvm-neutron-src test and major version bumps

[Tony Breeds]

Hi All,
We have the test in $subject that is used for most (if not all) libraries
via the 'lib-forward-testing' job-group it's aim to to "test their proposed
commits to ensure they don't break OpenStack on their next release." [1]

This is of course a good idea.

The problem I;'m having is trying to land a patch in stable/juno which is
running devstack-gate in stable/juno except for the library in question where
it's grabbing master[2].  I think this is a problem because master has
introduced in compatible changes (and bumped $major).  So this results in
violating global-requirements and IMO an invalid test.

So what is the correct way forward?

 1. Disable lib-forward-testing on stable branches
- This seems easy but wrong 
 2. Use the appropriate stable/x branch for stable tests, when master has made
a $major version bump?
 3. Something smarter that I can't see because I'm not familiar enough with
what we can do in job definitions.

Of course I could be way off and this isn't really a problem at all.

Yours Tony.

[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n72
[2] 
http://logs.openstack.org/54/216954/1/check/gate-tempest-dsvm-neutron-src-oslo.i18n/044dea9/logs/devstacklog.txt.gz#_2015-08-26_04_25_37_264


pgp14VRqPdIA1.pgp
Description: PGP signature
__
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] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Everett Toews]

On Sep 1, 2015, at 8:36 PM, Dolph Mathews  wrote:

> Does anyone have an example of an API outside of OpenStack that would return 
> 400 in this situation (arbitrary query string parameters)? Based on my past 
> experience, I'd expect them to be ignored, but I can't think of a reason why 
> a 400 would be a bad idea (but I suspect there's some prior art / discussion 
> out there).

Good question! I think it’s a great idea to look outside OpenStack-land to see 
what’s going on in the wider world of APIs.

One example is listing containers in the Docker API [1]. A number of other 
resources will also return a 400 if a bad parameter is used.

Everett

[1] 
https://docs.docker.com/reference/api/docker_remote_api_v1.20/#list-containers


__
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] Scheduler hints, API and Objects

[Ken'ichi Ohmichi]

Hi Andrew,

2015-09-04 23:45 GMT+09:00 Andrew Laski :
>>>
>>> Now we are discussing this on https://review.openstack.org/#/c/217727/
>>> for allowing out-of-tree scheduler-hints.
>>> When we wrote API schema for scheduler-hints, it was difficult to know
>>> what are available API parameters for scheduler-hints.
>>> Current API schema exposes them and I guess that is useful for API users
>>> also.
>>>
>>> One idea is that: How about auto-extending scheduler-hint API schema
>>> based on loaded schedulers?
>>> Now API schemas of "create/update/resize/rebuild a server" APIs are
>>> auto-extended based on loaded extensions by using stevedore
>>> library[1].
>>> I guess we can apply the same way for scheduler-hints also in long-term.
>>> Each scheduler needs to implement a method which returns available API
>>> parameter formats and nova-api tries to get them then extends
>>> scheduler-hints API schema with them.
>>> That means out-of-tree schedulers also will be available if they
>>> implement the method.
>>> # In short-term, I can see "blocking additionalProperties" validation
>>> disabled by the way.
>>
>>
>> https://review.openstack.org/#/c/220440 is a prototype for the above idea.
>
>
> I like the idea of providing strict API validation for the scheduler hints
> if it accounts for out of tree extensions like this would do.  I do have a
> slight concern about how this works in a world where the scheduler does
> eventually get an HTTP interface that Nova uses and the code isn't
> necessarily accessible, but that can be worried about later.
>
> This does mean that the scheduler hints are not controlled by microversions
> though, since we don't have a mechanism for out of tree extensions to signal
> their presence that way.  And even if they could it would still mean that
> identical microversions on different clouds wouldn't offer the same hints.
> If we're accepting of that, which isn't really any different than having
> "additionalProperties: True", then this seems reasonable to me.

In short-term, yes. That is almost the same as "additionalProperties: True".
But in long-term, no. Each scheduler-hint parameter which is described
with JSON-Schema will be useful instead of "additionalProperties:
True" because API parameters will be exposed with JSON-Schema format
on JSON-Home or something.
If we allow customization of scheduler-hints like new filters,
out-of-tree filters without microversions, API users cannot know
available scheduler-hints parameter from microversions number.
That will be helpful for API users that nova can provide available
parameters with JSON-Home or something.

Thanks
Ken Ohmichi

__
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] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[Sean M. Collins]

On Sun, Sep 06, 2015 at 04:25:43PM EDT, Kevin Benton wrote:
> So it's been pointed out that http://169.254.169.254/openstack is completed
> OpenStack invented. I don't quite understand how that's not violating the
> contract you said we have with end users about EC2 compatibility under the
> restriction of 'no new stuff'.

I think that is a violation. I don't think that allows us to make more
changes, just because we've broken the contract once, so a second
infraction is less significant. 

> If we added an IPv6 endpoint that the metadata service listens on, it would
> just be another place that non cloud-init clients don't know how to talk
> to. It's not going to break our compatibility with any clients that connect
> to the IPv4 address.

No, but if Amazon were to make a decision about how to implement IPv6 in
EC2 and how to make the Metadata API service work with IPv6 we'd be
supporting two implementations - the one we came up with and one for
supporting the way Amazon implemented it.

-- 
Sean M. Collins

__
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]how to get service_catalog

[Jamie Lennox]

- Original Message -
> From: "王华" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, 7 September, 2015 12:00:43 PM
> Subject: [openstack-dev] [keystone]how to get service_catalog
> 
> Hi all,
> 
> When I use a token to init a keystoneclient and try to get service_catalog by
> it, error occurs. I find that keystone doesn't return service_catalog when
> we use a token. Is there a way to get service_catalog by token? In magnum,
> we now make a trick. We init a keystoneclient with service_catalog which is
> contained in the token_info returned by keystonemiddleware in auth_ref
> parameter.
> 
> I want a way to get service_catalog by token. Or can we init a keystoneclient
> by the token_info return by keystonemiddleware directly?
> 
> Regards,
> Wanghua

Sort of. 

The problem you are hitting is that a token is just a string, an identifier for 
some information stored in keystone. Given a token at __init__ time the client 
doesn't try to validate this in anyway it just assumes you know what you are 
doing. You can do a variation of this though in which you use an existing token 
to fetch a new token with the same rights (the expiry etc will be the same) and 
then you will get a fresh service catalog. Using auth plugins that's the Token 
family of plugins.

However i don't _think_ that's exactly what you're looking for in magnum. What 
token are you trying to reuse? 

If it's the users token then auth_token passes down an auth plugin in the 
ENV['keystone.token_auth'] variable[1] and you can pass that to a client to 
reuse the token and service catalog. If you are loading up magnum specific auth 
then again have a look at using keystoneclient's auth plugins and reusing it 
across multiple requests.

Trying to pass around a bundle of token id and service catalog is pretty much 
exactly what an auth plugin does and you should be able to do something there. 


Jamie

[1] 
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164
> __
> 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] [Fuel][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Sebastian Kalinowski]

+1

2015-09-03 21:34 GMT+02:00 Bartlomiej Piotrowski :

> I have no idea if I'm eligible to vote, but I'll do it anyway:
>
> +1
>
> Bartłomiej
>
> On Thu, Sep 3, 2015 at 9:16 PM, Sergey Vasilenko 
> wrote:
>
>> +1
>>
>> /sv
>>
>> __
>> 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 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][Glance] keystonemiddleware & multiple keystone endpoints

[Jamie Lennox]

- Original Message -
> From: "joehuang" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Sunday, 6 September, 2015 7:28:04 PM
> Subject: Re: [openstack-dev] [Keystone][Glance] keystonemiddleware & multiple 
> keystone endpoints
> 
> Hello, Jamie and Hans,
> 
> The patch " Allow specifying a region name to auth_token "
> https://review.openstack.org/#/c/216579 has just been merged.
> 
> But unfortunately, when I modify the source code as this patch did in the
> multisite cloud with Fernet token, the issue is still there, and routed to
> incorrect endpoint.
> 
> I also check the region_name configuration in the source code, it's correct.
> 
> The issue mentioned in the bug report not addressed yet:
> https://bugs.launchpad.net/keystonemiddleware/+bug/1488347
> 
> Is there anyone who tested it successfully in your environment?

Hey Joe, 

The way that this patch is implemented requires you to have configured 
auth_token middleware with an auth plugin. For example [1]. I should have 
called this out better in the help for the config option. To make it so that 
the old admin_user etc options were region aware is kind of a big change 
because in that case the URL that is configured as identity_uri is always used 
for all keystone options.

Can you try and configure with the auth plugin options and see if the regions 
work after that? 


Jamie

[1] 
http://www.jamielennox.net/blog/2015/02/23/v3-authentication-with-auth-token-middleware/



> The log of Glance API, the request was redirected to
> http://172.17.0.95:35357, but this address is not a KeyStone endpoint.
> (http://172.17.0.98:35357 and http://172.17.0.41:35357 are correct KeyStone
> endpoints )
> //
> 2015-09-06 07:50:43.447 194 DEBUG keystoneclient.session [-] REQ: curl -g -i
> -X GET http://172.17.0.98:35357 -H "Accept: application/json" -H
> "User-Agent: python-keystoneclient" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
> 2015-09-06 07:50:43.468 194 DEBUG keystoneclient.session [-] RESP: [300]
> content-length: 593 vary: X-Auth-Token connection: keep-alive date: Sun, 06
> Sep 2015 07:50:43 GMT content-type: application/json x-distribution: Ubuntu
> RESP BODY: {"versions": {"values": [{"status": "stable", "updated":
> "2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type":
> "application/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links":
> [{"href": "http://172.17.0.98:35357/v3/;, "rel": "self"}]}, {"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://172.17.0.98:35357/v2.0/;, "rel": "self"}, {"href":
> "http://docs.openstack.org/;, "type": "text/html", "rel":
> "describedby"}]}]}}
>  _http_log_response
>  /usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
> 2015-09-06 07:50:43.469 194 DEBUG keystoneclient.auth.identity.v3 [-] Making
> authentication request to http://172.17.0.98:35357/v3/auth/tokens
> get_auth_ref
> /usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
> 2015-09-06 07:50:43.574 194 DEBUG keystoneclient.session [-] REQ: curl -g -i
> -X GET http://172.17.0.95:35357 -H "Accept: application/json" -H
> "User-Agent: python-keystoneclient" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
> 2015-09-06 07:50:46.576 194 WARNING keystoneclient.auth.identity.base [-]
> Failed to contact the endpoint at http://172.17.0.95:35357 for discovery.
> Fallback to using that endpoint as the base url.
> 2015-09-06 07:50:46.576 194 DEBUG keystoneclient.session [-] REQ: curl -g -i
> -X GET http://172.17.0.95:35357/auth/tokens -H "X-Subject-Token:
> {SHA1}640964e1f8716ecbb10ca3d8b5b08c8e7abfac1d" -H "User-Agent:
> python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token:
> {SHA1}386777062718e0992cc818780e3ec7fa0671d8e9" _http_log_request
> /usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
> 2015-09-06 07:50:49.576 194 INFO keystoneclient.session [-] Failure: Unable
> to establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in
> 0.5s.
> 2015-09-06 07:50:52.576 194 INFO keystoneclient.session [-] Failure: Unable
> to establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in
> 1.0s.
> 2015-09-06 07:50:55.576 194 INFO keystoneclient.session [-] Failure: Unable
> to establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in
> 2.0s.
> 2015-09-06 07:50:58.576 194 WARNING keystonemiddleware.auth_token [-]
> Authorization failed for token
> 
> 
> Best Regards
> Chaoyi Huang ( Joe Huang )
> 
> 
> -Original Message-
> From: Hans Feldt [mailto:hans.fe...@ericsson.com]
> Sent: Tuesday, August 25, 2015 5:06 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: 

[openstack-dev] [puppet] Tokyo Summit

[Emilien Macchi]

Hi,

I created an etherpad to gathers all informations about Tokyo Summit [1].
You can see the resources that we will dispose, and also a "Topics" section.
Feel free to bring anything you would like to discuss.

During the next weekly meetings, we will iterate the etherpad to make sure
we use our few slots in an efficient way.

[1] https://etherpad.openstack.org/p/HND-puppet

Looking forward to seeing you there,
-- 
Emilien Macchi
__
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] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

[Steve Martinelli]

So, digging into this a bit more, the failures that Barbican and Ironic saw
were very different. The barbican team managed to fix their issues by
replacing their `keystone endpoint-create` and such commands with the
`openstack endpoint create` alternates.

Looking at the failure for why Ironic failed led me down a rabbit hole I
wish I hadn't gone down. There are no plugins managed by the ironic, like
there were in the barbican case, so there were easy commands to
replace.Instead it was failing on a few swift related commands, as
evidenced in the log that Lucas copied:

http://logs.openstack.org/68/217068/14/check/gate-tempest-dsvm-ironic-agent_ssh/18d8590/logs/devstacklog.txt.gz#_2015-09-04_09_04_55_994
2015-09-04 09:04:55.527 | + swift post -m 'Temp-URL-Key: secretkey'
2015-09-04 09:04:55.994 | Authorization Failure. Authorization Failed: The
resource could not be found. (HTTP 404)

Jamie's patch sets everything to v3, so why is failing now? I tried this in
my own environment to make sure:
steve@steve-vm:~/devstack$ export OS_IDENTITY_API_VERSION=3
steve@steve-vm:~/devstack$ export OS_AUTH_URL='http://10.0.2.15:5000/v3'
steve@steve-vm:~/devstack$ swift stat
Authorization Failure. Authorization Failed: The resource could not be
found. (HTTP 404) (Request-ID: req-63bee2a6-ca9d-49f4-baad-b6a1eef916df)
steve@steve-vm:~/devstack$ swift --debug stat
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
http://10.0.2.15:5000/v3/tokens

And saw that swiftclient was creating a v2 client instance with a v3
endpoint, this is no beuno.

As I continued to dig into this, it seems like swiftclient doesn't honor
the OS_IDENTITY_API_VERSION flag that was set, instead it relies on
--auth-version or OS_AUTH_VERSION
steve@steve-vm:~/devstack$ export OS_AUTH_VERSION=3
steve@steve-vm:~/devstack$ swift --debug stat
DEBUG:keystoneclient.auth.identity.v3.base:Making authentication request to
http://10.0.2.15:5000/v3/auth/tokens
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
(1): 10.0.2.15
 it continued and was happy

So, we could easily propose Jamies patch again, but this time also set
OS_AUTH_VERSION, or we could fix swiftclient to honor the
OS_IDENTITY_API_VERSION flag. I'd prefer doing the former first to get
Jamie's patch back in, and the latter for the long term plan, but looking
at the code, there doesn't seem to be a plan on deprecating
OS_AUTH_VERSION.

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Jamie Lennox 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/09/06 04:41 AM
Subject:Re: [openstack-dev]
[DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to
Keystone v3 API



Note that this fixing this does not mean ironic has to support keystone v3
(but please fix that too). It just means that somewhere in ironic's gate it
is doing like an "openstack user create" or a role assignment directly with
the OSC tool assuming v2 rather than using the helpers that devstack
provides like get_or_create_user. Keystone v2 still exists and is running
we just changed the default API for devstack OSC commands.

I'm kind of annoyed we reverted this patch (though i was surprised to see
it merge recently as it's been around for a while), as it was known to
possibly break people which is why it was on the discussion for the qa
meetings. However given that devstack has plugins and there is third party
CI there is absolutely no way we can make sure that everyone has fixed this
and we just need to make a breaking change. Granted coinciding with freeze
is unfortunate. Luckily this doesn't affect most people because they use
the devstack helper functions and for those that don't it's an almost
trivial fix to start using them.

Jamie

- Original Message -
> From: "Steve Martinelli" 
> To: "OpenStack Development Mailing List (not for usage questions)"

> Sent: Saturday, September 5, 2015 2:38:27 AM
> Subject: Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican]
FYI: Defaulting to Keystone v3 API
>
>
>
> This change also affected Barbican too, but they quickly tossed up a
patch to
> resolve the gate failures [1]. As much as I would like DevStack and
> OpenStackClient to default to Keystone's v3 API, we should - considering
how
> close we are in the schedule, revert the initial patch (which I see
sdague
> already did). We need to determine which projects are hosting their own
> devstack plugin scripts and update those first before bringing back the
> original patch.
>
> https://review.openstack.org/#/c/220396/
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> Lucas Alvares Gomes ---2015/09/04 10:07:51 AM---Hi, This is email is just
a
> FYI: Recently the patch [1] got merged in
>
> From: Lucas Alvares Gomes 
> To: OpenStack 

[openstack-dev] [magnum] Steps to upload magnum images

[Hongbin Lu]

Hi team,

As you may know, magnum is tested with pre-built Fedora Atomic images. 
Basically, these images are standard atomic image with k8s packages 
pre-installed. The images can be downloaded from fedorapeople.org [1]. In most 
cases, you are able to test magnum by using images there. If you are not 
satisfied by existing images, you are welcome to build a new image and share it 
with the team. Here [2] is the instruction for how to build an new atomic 
image. After you successfully build an image, you may want to upload it to the 
public file server, which is what I am going to talk about.

Below are the steps to upload an image:

1.   Register an account in here https://admin.fedoraproject.org/accounts/

2.   Sign the contributor agreement (On the home page after you login: "My 
Account" -> "Contributor Agreement").

3.   Upload your public key ("My Account" -> "Public SSH Key").

4.   Apply to join the magnum group ("Join a group" -> search "magnum" -> 
"apply"). If you cannot find the "apply" link under "Status" (I didn't), you 
can wait a few minutes or skip this step and ask Steven Dake to add you to the 
group instead.

5.   Ping Steven Dake (std...@cisco.com) to approve your application.

6.   After 30-60 minutes, you should be able to SSH to the file server (ssh 
@fedorapeople.org). Our images are stored in /srv/groups/magnum.

Notes on using the file server:

* Avoid type "sudo ...".

* Activities there are logged, so don't expect any privacy.

* Not all contents are allowed. Please make sure your uploaded contents 
are acceptable before uploading it.

[1] https://fedorapeople.org/groups/magnum/
[2] 
https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-build-atomic-image.rst
__
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] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[Jim Rollenhagen]

> On Sep 6, 2015, at 09:43, Monty Taylor  wrote:
> 
>> On 09/05/2015 06:19 PM, Sean M. Collins wrote:
>>> On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:
>>> Right, it depends on your perspective of who 'owns' the API. Is it
>>> cloud-init or EC2?
>>> 
>>> At this point I would argue that cloud-init is in control because it would
>>> be a large undertaking to switch all of the AMI's on Amazon to something
>>> else. However, I know Sean disagrees with me on this point so I'll let him
>>> reply here.
>> 
>> 
>> Here's my take:
>> 
>> Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
>> in both the Neutron and Nova projects should all the details of the
>> Metadata API that is documented at:
>> 
>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
>> 
>> This means that this is a compatibility layer that OpenStack has
>> implemented so that users can use appliances, applications, and
>> operating system images in both Amazon EC2 and an OpenStack environment.
>> 
>> Yes, we can make changes to cloud-init. However, there is no guarantee
>> that all users of the Metadata API are exclusively using cloud-init as
>> their client. It is highly unlikely that people are rolling their own
>> Metadata API clients, but it's a contract we've made with users. This
>> includes transport level details like the IP address that the service
>> listens on.
>> 
>> The Metadata API is an established API that Amazon introduced years ago,
>> and we shouldn't be "improving" APIs that we don't control. If Amazon
>> were to introduce IPv6 support the Metadata API tomorrow, we would
>> naturally implement it exactly the way they implemented it in EC2. We'd
>> honor the contract that Amazon made with its users, in our Metadata API,
>> since it is a compatibility layer.
>> 
>> However, since they haven't defined transport level details of the
>> Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
>> solution. It is not our API.
>> 
>> The nice thing about config-drive is that we've created a new mechanism
>> for bootstrapping instances - by replacing the transport level details
>> of the API. Rather than being a link-local address that instances access
>> over HTTP, it's a device that guests can mount and read. The actual
>> contents of the drive may have a similar schema as the Metadata API, but
>> I think at this point we've made enough of a differentiation between the
>> EC2 Metadata API and config-drive that I believe the contents of the
>> actual drive that the instance mounts can be changed without breaking
>> user expectations - since config-drive was developed by the OpenStack
>> community. The point being that we call it "config-drive" in
>> conversation and our docs. Users understand that config-drive is a
>> different feature.
> 
> Another great part about config-drive is that it's scalable. At infra's 
> application scale, we take pains to disable anyting in our images that might 
> want to contact the metadata API because we're essentially a DDOS on it.

So, I tend to think a simple API service like this should never be hard to 
scale. Put a bunch of hosts behind a load balancer, boom, done. Even 1000 
requests/s shouldn't be hard, though it may require many hosts, and that's far 
beyond what infra would hit today. 

The one problem I have with config-drive is that it is static. I'd love for 
systems like cloud-init, glean, etc, to be able to see changes to mounted 
disks, attached networks, etc. Attaching things after the fact isn't uncommon, 
and to make the user config the thing is a terrible experience. :(

// jim 

> 
> config-drive being local to the hypervisor host makes it MUCH more stable at 
> scale.
> 
> cloud-init supports config-drive
> 
> If it were up to me, nobody would be enablig the metadata API in new 
> deployments.
> 
> I totally agree that we should not make changes in the metadata API.
> 
>> I've had this same conversation about the Security Group API that we
>> have. We've named it the same thing as the Amazon API, but then went and
>> made all the fields different, inexplicably. Thankfully, it's just the
>> names of the fields, rather than being huge conceptual changes.
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html
>> 
>> Basically, I believe that OpenStack should create APIs that are
>> community driven and owned, and that we should only emulate
>> non-community APIs where appropriate, and explicitly state that we only
>> are emulating them. Putting improvements in APIs that came from
>> somewhere else, instead of creating new OpenStack branded APIs is a lost
>> opportunity to differentiate OpenStack from other projects, as well as
>> Amazon AWS.
>> 
>> Thanks for reading, and have a great holiday.
> 
> I could not possibly agree more if our brains were physically fused.
> 
> __
> 

[openstack-dev] [keystone]how to get service_catalog

[王华]

Hi all,

When I use a token to init a keystoneclient and try to get service_catalog
by it, error occurs. I find that keystone doesn't return service_catalog
when we use a token. Is there a way to get service_catalog by token?  In
magnum, we now make a trick. We init a keystoneclient with service_catalog
which is contained in the token_info returned by keystonemiddleware in
auth_ref parameter.

I want a way to get service_catalog by token. Or can we init a
keystoneclient by the token_info return by keystonemiddleware directly?

Regards,
Wanghua
__
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] Port forwarding

[Germy Lure]

Hi Gal,

I'm sorry for my poor English. Let me try again.

What operator wants to access is several related instances, instead of only
one or one by one. The use case is periodical check and maintain. RELATED
means instance maybe in one subnet, or one network, or one host. The host's
scene is similar to access the docker on the host as you mentioned before.

Via what you mentioned of API, user must ssh an instance and then invoke
API to update the IP address and port, or even create a new PF to access
another one. It will be a nightmare to a VPC operator who owns so many
instances.

In a word, I think the "inside_addr" should be "subnet" or "host".

Hope this is clear enough.

Germy

On Sun, Sep 6, 2015 at 1:05 PM, Gal Sagie  wrote:

> Hi Germy,
>
> I am not sure i understand what you mean, can you please explain it
> further?
>
> Thanks
> Gal.
>
> On Sun, Sep 6, 2015 at 5:39 AM, Germy Lure  wrote:
>
>> Hi, Gal
>>
>> Thank you for bringing this up. But I have some suggestions for the API.
>>
>> An operator or some other component wants to reach several VMs related
>> NOT only one or one by one. Here, RELATED means that the VMs are in one
>> subnet or network or a host(similar to reaching dockers on a host).
>>
>> Via the API you mentioned, user must ssh one VM and update even delete
>> and add PF to ssh another. To a VPC(with 20 subnets?) admin, it's totally a
>> nightmare.
>>
>> Germy
>>
>>
>> On Wed, Sep 2, 2015 at 1:59 PM, Gal Sagie  wrote:
>>
>>> Hello All,
>>>
>>> I have searched and found many past efforts to implement port forwarding
>>> in Neutron.
>>> I have found two incomplete blueprints [1], [2] and an abandoned patch
>>> [3].
>>>
>>> There is even a project in Stackforge [4], [5] that claims
>>> to implement this, but the L3 parts in it seems older then current
>>> master.
>>>
>>> I have recently came across this requirement for various use cases, one
>>> of them is
>>> providing feature compliance with Docker port-mapping feature (for
>>> Kuryr), and saving floating
>>> IP's space.
>>> There has been many discussions in the past that require this feature,
>>> so i assume
>>> there is a demand to make this formal, just a small examples [6], [7],
>>> [8], [9]
>>>
>>> The idea in a nutshell is to support port forwarding (TCP/UDP ports) on
>>> the external router
>>> leg from the public network to internal ports, so user can use one
>>> Floating IP (the external
>>> gateway router interface IP) and reach different internal ports
>>> depending on the port numbers.
>>> This should happen on the network node (and can also be leveraged for
>>> security reasons).
>>>
>>> I think that the POC implementation in the Stackforge project shows that
>>> this needs to be
>>> implemented inside the L3 parts of the current reference implementation,
>>> it will be hard
>>> to maintain something like that in an external repository.
>>> (I also think that the API/DB extensions should be close to the current
>>> L3 reference
>>> implementation)
>>>
>>> I would like to renew the efforts on this feature and propose a RFE and
>>> a spec for this to the
>>> next release, any comments/ideas/thoughts are welcome.
>>> And of course if any of the people interested or any of the people that
>>> worked on this before
>>> want to join the effort, you are more then welcome to join and comment.
>>>
>>> Thanks
>>> Gal.
>>>
>>> [1]
>>> https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
>>> [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
>>> [3] https://review.openstack.org/#/c/60512/
>>> [4] https://github.com/stackforge/networking-portforwarding
>>> [5] https://review.openstack.org/#/q/port+forwarding,n,z
>>>
>>> [6]
>>> https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
>>> [7] http://www.gossamer-threads.com/lists/openstack/dev/34307
>>> [8]
>>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
>>> [9]
>>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
>>>
>>>
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

[openstack-dev] [barbican] No IRC meeting tomorrow September 7

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Barbicaneers,

We'll be skipping the weekly IRC meeting tomorrow since I expect most
folks will be out due to the US holiday.

Thanks,

Douglas Mendizábal
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV7N2vAAoJEB7Z2EQgmLX7uGIP/1mpkl9rtJchktROwhMkO/Kk
OI3oMkVyOLOQwje7lwYjF8DR55cV/wrE+kYUyJlNnkELH5+CUskBWERN+fFOjyJ7
oCbUK3ISg9QIJf+wyov3Wbzyp+vFwLFDzHucz6rfb2MJCwNQxUH9lujBCQjdGrJC
MBV0IWQ9A8KE6yNj5Sk0S8T1ZnkPTGKojKNv8rY2NQE9O1RdPIH7IxeYPfA6Z4xY
9Z/5KEb1BpbLPnlAKxF3gLb1H+FcjF+QiSdaek3t+6QOVJ1dTjA53bbxETrWlrcU
mjDGm99bixZxlON1Pce4fg/EtshAI+LPKK9epWh2yQ5M73JfXQnm6/eFVDecmGPI
kgYnUCUb8k05ag8qN3Zrgd51SyhrSsQg2IvV6I7/mfbChFuQlg/pPLmlCATSr4Kj
zPSylNocoT5kqXAAdqjYMsXmIgyCAMEo7q5xH7ZbIC3SWdDDoQVOWrEgbo6mHfIW
aemFB2nS+ybwk4UvcYJTsrLXU8xEGAYYLJaWWHjzbd5Lt1C502rQGED2T6YkwSJY
+7Udct8gTCTxWuQykBbXgGBh2RjrcAj+ArQhUJpluzgyolNmYILOpRTGo/HhwKk9
CqTlm/R+EcDEsxpp3JmhxwwpxCc9gMcU5oUWpHcWKkyqAW0XpE3iS3nXm2YNeCXw
XI2iForVuqYIZYb6XHXT
=T39J
-END PGP SIGNATURE-

__
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] [puppet] Liberty Sprint Retrospective

[Emilien Macchi]

Hi,

With the goal to continually improve our way to work together, I would like
to build a Sprint Retrospective from what happened last week.

The first step would be to gather data on this etherpad:
https://etherpad.openstack.org/p/puppet-liberty-sprint-retrospective
The second step, that we will probably do during our weekly meeting would
be to feed the "Generate insights" section and the "Decide what to do".
Then I'll make a summary of our thoughts and close the retrospective by
some documentation that will help us to make the next time even better.

Feel free to participate to this discussion, any feedback is welcome,
-- 
Emilien Macchi
__
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] Should v2 compatibility mode (v2.0 on v2.1) fixes be applicable for v2.1 too?

[GHANSHYAM MANN]

Hi All,

As we all knows, api-paste.ini default setting for /v2 was changed to
run those on v2.1 (v2.0 on v2.1) which is really great think for easy
code maintenance in future (removal of v2 code).

To keep "v2.0 on v2.1" fully compatible with "v2.0 on v2.0", some bugs
were found[1] and fixed. But I think we should fix those only for v2
compatible mode not for v2.1.

For example bug#1491325, 'device' on volume attachment Request is
optional param[2] (which does not mean 'null-able' is allowed) and
v2.1 used to detect and error on usage of 'device' as "None". But as
it was used as 'None' by many /v2 users and not to break those, we
should allow 'None' on v2 compatible mode also. But we should not
allow the same for v2.1.

IMO v2.1 strong input validation feature (which helps to make API
usage in correct manner) should not be changed, and for v2 compatible
mode we should have another solution without affecting v2.1 behavior
may be having different schema for v2 compatible mode and do the
necessary fixes there.

Trying to know other's opinion on this or something I missed during
any discussion.

[1]: https://bugs.launchpad.net/python-novaclient/+bug/1491325
  https://bugs.launchpad.net/nova/+bug/1491511

[2]: http://developer.openstack.org/api-ref-compute-v2.1.html#attachVolume

-- 
Thanks & Regards
Ghanshyam Mann

__
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] Criteria for applying vulnerability:managed tag

[Jeremy Stanley]

On 2015-09-02 17:47:20 + (+), Tristan Cacqueray wrote:
[...]
> Any supported programming language by the openstack project should/could
> also be accepted for vulnerability management.
> As long as there is a way to test patch, I think the VMT can support
> other languages like Go or Puppet.

Okay, so for me that implies an extra criterion: the repos for the
deliverable covered should have testing. Great point, it seems
pretty important really and was absent from my initial list.

> The risk is to divide downstream communities, and managing different
> lists sounds like overkill for now. One improvement would be to maintain
> that list publicly like xen do for their pre-disclosure list:
>   http://www.xenproject.org/security-policy.html
[...]
> With a public stakeholder list, we can clarify our vmt-process to be
> directly usable without vmt supervision.
[...]

Unlike many communities, our commercial popularity and corresponding
desire from many vendors to make their involvement in OpenStack as
obvious as possible leads to a bit of a "me too" situation whenever
we create public lists of organizations. I'm all for making our
stakeholder *criteria* clearly documented, but worry that turning
the list of who gets advance notification of embargoed vulnerability
fixes into a public roster will put undue pressure on vendors to be
seen as one of the "privileged few" (creating additional work for
the VMT and potentially resulting in downstream stakeholders who
don't actually intend to make use of the notification and so
needlessly increase the risk of leaks and premature disclosure).

An alternative solution we've discussed to make reaching downstream
stakeholders easier for our developers is adding them to a private
mailing list reserved only for advance notification of embargoed
vulnerability fixes. The VMT could control manual subscription of
new stakeholders and moderate posts to ensure that subsequent
discussion is pushed back to the embargoed bug reports themselves
(we should also probably create a corresponding stakeholders group
in the bug tracker so they can be subscribed to private bugs at the
same time advance notifications are sent, and start including the
bug links in those downstream notifications).
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

[Jamie Lennox]

- Original Message -

> From: "Steve Martinelli" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Sent: Monday, 7 September, 2015 9:27:55 AM
> Subject: Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican]
> FYI: Defaulting to Keystone v3 API

> So, digging into this a bit more, the failures that Barbican and Ironic saw
> were very different. The barbican team managed to fix their issues by
> replacing their `keystone endpoint-create` and such commands with the
> `openstack endpoint create` alternates.

> Looking at the failure for why Ironic failed led me down a rabbit hole I wish
> I hadn't gone down. There are no plugins managed by the ironic, like there
> were in the barbican case, so there were easy commands to replace.Instead it
> was failing on a few swift related commands, as evidenced in the log that
> Lucas copied:

> http://logs.openstack.org/68/217068/14/check/gate-tempest-dsvm-ironic-agent_ssh/18d8590/logs/devstacklog.txt.gz#_2015-09-04_09_04_55_994
> 2015-09-04 09:04:55.527 | + swift post -m 'Temp-URL-Key: secretkey'
> 2015-09-04 09:04:55.994 | Authorization Failure. Authorization Failed: The
> resource could not be found. (HTTP 404)

> Jamie's patch sets everything to v3, so why is failing now? I tried this in
> my own environment to make sure:
> steve@steve-vm:~/devstack$ export OS_IDENTITY_API_VERSION=3
> steve@steve-vm:~/devstack$ export OS_AUTH_URL='http://10.0.2.15:5000/v3'
> steve@steve-vm:~/devstack$ swift stat
> Authorization Failure. Authorization Failed: The resource could not be found.
> (HTTP 404) (Request-ID: req-63bee2a6-ca9d-49f4-baad-b6a1eef916df)
> steve@steve-vm:~/devstack$ swift --debug stat
> DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
> http://10.0.2.15:5000/v3/tokens

> And saw that swiftclient was creating a v2 client instance with a v3
> endpoint, this is no beuno.

> As I continued to dig into this, it seems like swiftclient doesn't honor the
> OS_IDENTITY_API_VERSION flag that was set, instead it relies on
> --auth-version or OS_AUTH_VERSION
> steve@steve-vm:~/devstack$ export OS_AUTH_VERSION=3
> steve@steve-vm:~/devstack$ swift --debug stat
> DEBUG:keystoneclient.auth.identity.v3.base:Making authentication request to
> http://10.0.2.15:5000/v3/auth/tokens
> INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
> (1): 10.0.2.15
>  it continued and was happy

> So, we could easily propose Jamies patch again, but this time also set
> OS_AUTH_VERSION, or we could fix swiftclient to honor the
> OS_IDENTITY_API_VERSION flag. I'd prefer doing the former first to get
> Jamie's patch back in, and the latter for the long term plan, but looking at
> the code, there doesn't seem to be a plan on deprecating OS_AUTH_VERSION.

> Thanks,
Thanks for looking into this Steve, as evidenced by how well i phrased my 
response I shouldn't answer emails late at night. 

So what i would like to consider this is a renewed call for deprecating ALL the 
project specific CLIs in favour of using openstack client. The mix and match of 
different parameters accepted by different clients is not just a problem for 
ours users, developers who actually interact with this code can't keep them all 
straight. Does anyone know what the path would be to get this actually agreed 
on by all the projects? Cross-project blueprint? TC? 

Does OSC have the required commands that we can remove use of the swift CLI? 

I can understand having this reverted whilst feature freeze is underway and i 
didn't do a sufficient job in alerting people to the possibility of a breaking 
change (partially as i wasn't expecting it to merge). However to get this back 
in I think the easiest thing to do is just set OS_AUTH_VERSION in devstack with 
a comment about "needed for swift". I think we should consider 
OS_IDENTITY_API_VERSION an OSC flag rather that something we want all the CLIs 
to copy (as API_VERSION shouldn't necessarily imply auth_version/method). 

Jamie 

> Steve Martinelli
> OpenStack Keystone Core

> Jamie Lennox ---2015/09/06 04:41:23 AM---Note that this fixing this does not
> mean ironic has to support keystone v3 (but please fix that too)

> From: Jamie Lennox 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 2015/09/06 04:41 AM
> Subject: Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican]
> FYI: Defaulting to Keystone v3 API

> Note that this fixing this does not mean ironic has to support keystone v3
> (but please fix that too). It just means that somewhere in ironic's gate it
> is doing like an "openstack user create" or a role assignment directly with
> the OSC tool assuming v2 rather than using the helpers that devstack
> provides like get_or_create_user. Keystone v2 still exists and is running we
> just changed the default API for devstack OSC 

Re: [openstack-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[Kevin Benton]

So it's been pointed out that http://169.254.169.254/openstack is completed
OpenStack invented. I don't quite understand how that's not violating the
contract you said we have with end users about EC2 compatibility under the
restriction of 'no new stuff'.

If we added an IPv6 endpoint that the metadata service listens on, it would
just be another place that non cloud-init clients don't know how to talk
to. It's not going to break our compatibility with any clients that connect
to the IPv4 address.
On Sep 5, 2015 3:22 PM, "Sean M. Collins"  wrote:

> On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:
> > Right, it depends on your perspective of who 'owns' the API. Is it
> > cloud-init or EC2?
> >
> > At this point I would argue that cloud-init is in control because it
> would
> > be a large undertaking to switch all of the AMI's on Amazon to something
> > else. However, I know Sean disagrees with me on this point so I'll let
> him
> > reply here.
>
>
> Here's my take:
>
> Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
> in both the Neutron and Nova projects should all the details of the
> Metadata API that is documented at:
>
>
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
>
> This means that this is a compatibility layer that OpenStack has
> implemented so that users can use appliances, applications, and
> operating system images in both Amazon EC2 and an OpenStack environment.
>
> Yes, we can make changes to cloud-init. However, there is no guarantee
> that all users of the Metadata API are exclusively using cloud-init as
> their client. It is highly unlikely that people are rolling their own
> Metadata API clients, but it's a contract we've made with users. This
> includes transport level details like the IP address that the service
> listens on.
>
> The Metadata API is an established API that Amazon introduced years ago,
> and we shouldn't be "improving" APIs that we don't control. If Amazon
> were to introduce IPv6 support the Metadata API tomorrow, we would
> naturally implement it exactly the way they implemented it in EC2. We'd
> honor the contract that Amazon made with its users, in our Metadata API,
> since it is a compatibility layer.
>
> However, since they haven't defined transport level details of the
> Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
> solution. It is not our API.
>
> The nice thing about config-drive is that we've created a new mechanism
> for bootstrapping instances - by replacing the transport level details
> of the API. Rather than being a link-local address that instances access
> over HTTP, it's a device that guests can mount and read. The actual
> contents of the drive may have a similar schema as the Metadata API, but
> I think at this point we've made enough of a differentiation between the
> EC2 Metadata API and config-drive that I believe the contents of the
> actual drive that the instance mounts can be changed without breaking
> user expectations - since config-drive was developed by the OpenStack
> community. The point being that we call it "config-drive" in
> conversation and our docs. Users understand that config-drive is a
> different feature.
>
> I've had this same conversation about the Security Group API that we
> have. We've named it the same thing as the Amazon API, but then went and
> made all the fields different, inexplicably. Thankfully, it's just the
> names of the fields, rather than being huge conceptual changes.
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html
>
> Basically, I believe that OpenStack should create APIs that are
> community driven and owned, and that we should only emulate
> non-community APIs where appropriate, and explicitly state that we only
> are emulating them. Putting improvements in APIs that came from
> somewhere else, instead of creating new OpenStack branded APIs is a lost
> opportunity to differentiate OpenStack from other projects, as well as
> Amazon AWS.
>
> Thanks for reading, and have a great holiday.
>
> --
> Sean M. Collins
>
> __
> 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] [puppet] Liberty Sprint Retrospective

[Matt Fischer]

I've updated the bug triage portion but tomorrow is a US holiday so you may
not see much traction there until Tuesday.

On Sun, Sep 6, 2015 at 6:59 PM, Emilien Macchi 
wrote:

> Hi,
>
> With the goal to continually improve our way to work together, I would
> like to build a Sprint Retrospective from what happened last week.
>
> The first step would be to gather data on this etherpad:
> https://etherpad.openstack.org/p/puppet-liberty-sprint-retrospective
> The second step, that we will probably do during our weekly meeting would
> be to feed the "Generate insights" section and the "Decide what to do".
> Then I'll make a summary of our thoughts and close the retrospective by
> some documentation that will help us to make the next time even better.
>
> Feel free to participate to this discussion, any feedback is welcome,
> --
> Emilien Macchi
>
> __
> 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] Fail to get ipv4 address from dhcp

[Huan Xie]

Hi all,

I'm trying to deploy OpenStack environment using DevStack with latest master 
code.
I use Xenserver + neutron, with ML2 plugins and VLAN type.

The problem I met is that the instances cannot really get IP address (I use 
DHCP), although we can see the VM with IP from horizon.
I have tcpdump from VM side and DHCP server side, I can get DHCP request packet 
from VM side but cannot see any request packet from DHCP server side.
But after I reboot the q-agt, the VM can get IP successfully.
Checking the difference before and after q-agt restart, all my seen are the 
flow rules about ARP spoofing.

This is the q-agt's br-int port, it is dom0's flow rules and the bold part are 
new added

NXST_FLOW reply (xid=0x4):
   cookie=0x824d13a352a4e216, duration=163244.088s, table=0, 
n_packets=93, n_bytes=18140, idle_age=4998, hard_age=65534, priority=0 
actions=NORMAL
cookie=0x824d13a352a4e216, duration=163215.062s, table=0, n_packets=7, 
n_bytes=294, idle_age=33540, hard_age=65534, priority=10,arp,in_port=5 
actions=resubmit(,24)
   cookie=0x824d13a352a4e216, duration=163230.050s, table=0, 
n_packets=25179, n_bytes=2839586, idle_age=5, hard_age=65534, 
priority=3,in_port=2,dl_vlan=1023 actions=mod_vlan_vid:1,NORMAL
   cookie=0x824d13a352a4e216, duration=163236.775s, table=0, 
n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,in_port=2 
actions=drop
   cookie=0x824d13a352a4e216, duration=163243.516s, table=23, 
n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
   cookie=0x824d13a352a4e216, duration=163242.953s, table=24, 
n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
cookie=0x824d13a352a4e216, duration=163215.636s, table=24, n_packets=7, 
n_bytes=294, idle_age=33540, hard_age=65534, 
priority=2,arp,in_port=5,arp_spa=10.0.0.6 actions=NORMAL

I cannot see other changes after reboot q-agt, but it seems these rules are 
only for ARP spoofing, however, the instance can get IP from DHCP.
I also google for this problem, but failed to deal this problem.
Is anyone met this problem before or has any suggestion about how to debugging 
for this?

Thanks a lot

BR//Huan
__
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] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

[Jamie Lennox]

Note that this fixing this does not mean ironic has to support keystone v3 (but 
please fix that too). It just means that somewhere in ironic's gate it is doing 
like an "openstack user create" or a role assignment directly with the OSC tool 
assuming v2 rather than using the helpers that devstack provides like 
get_or_create_user. Keystone v2 still exists and is running we just changed the 
default API for devstack OSC commands.

I'm kind of annoyed we reverted this patch (though i was surprised to see it 
merge recently as it's been around for a while), as it was known to possibly 
break people which is why it was on the discussion for the qa meetings. However 
given that devstack has plugins and there is third party CI there is absolutely 
no way we can make sure that everyone has fixed this and we just need to make a 
breaking change. Granted coinciding with freeze is unfortunate. Luckily this 
doesn't affect most people because they use the devstack helper functions and 
for those that don't it's an almost trivial fix to start using them.

Jamie

- Original Message -
> From: "Steve Martinelli" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Saturday, September 5, 2015 2:38:27 AM
> Subject: Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican] 
> FYI: Defaulting to Keystone v3 API
> 
> 
> 
> This change also affected Barbican too, but they quickly tossed up a patch to
> resolve the gate failures [1]. As much as I would like DevStack and
> OpenStackClient to default to Keystone's v3 API, we should - considering how
> close we are in the schedule, revert the initial patch (which I see sdague
> already did). We need to determine which projects are hosting their own
> devstack plugin scripts and update those first before bringing back the
> original patch.
> 
> https://review.openstack.org/#/c/220396/
> 
> Thanks,
> 
> Steve Martinelli
> OpenStack Keystone Core
> 
> Lucas Alvares Gomes ---2015/09/04 10:07:51 AM---Hi, This is email is just a
> FYI: Recently the patch [1] got merged in
> 
> From: Lucas Alvares Gomes 
> To: OpenStack Development Mailing List 
> Date: 2015/09/04 10:07 AM
> Subject: [openstack-dev] [DevStack][Keystone][Ironic][Swit] FYI: Defaulting
> to Keystone v3 API
> 
> 
> 
> 
> Hi,
> 
> This is email is just a FYI: Recently the patch [1] got merged in
> DevStack and broke the Ironic gate [2], I haven't had time to dig into
> the problem yet so I reverted the patch [3] to unblock our gate.
> 
> The work to convert to v3 seems to be close enough but not yet there
> so I just want to bring a broader attention to it with this email.
> 
> Also, the Ironic job that is currently running in the DevStack gate is
> not testing Ironic with the Swift module, there's a patch [4] changing
> that so I hope we will be able to identify the problem before we break
> things next time .
> 
> [1] https://review.openstack.org/#/c/186684/
> [2]
> http://logs.openstack.org/68/217068/14/check/gate-tempest-dsvm-ironic-agent_ssh/18d8590/logs/devstacklog.txt.gz#_2015-09-04_09_04_55_994
> [3] https://review.openstack.org/220532
> [4] https://review.openstack.org/#/c/220516/
> 
> Cheers,
> Lucas
> 
> __
> 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 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] [nova] Bug importance

[Davanum Srinivas]

Gary,

Not sure what changed...

On this page (https://bugs.launchpad.net/nova/) on the right hand side, do
you see "Bug Supervisor" set to "Nova Bug Team"?  I believe "Nova Bug Team"
is open and you can add yourself, so if you do not see yourself in that
group, can you please add it and try?

-- Dims

On Sun, Sep 6, 2015 at 4:56 AM, Gary Kotton  wrote:

> Hi,
> In the past I was able to set the importance of a bug. Now I am unable to
> do this? Has the policy changed? Can someone please clarify. If the policy
> has changed who is responsible for deciding the priority of a bug?
> 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
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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] [nova] Bug importance

[Gary Kotton]

That works.
Thanks!

From: "dava...@gmail.com" 
>
Reply-To: OpenStack List 
>
Date: Sunday, September 6, 2015 at 4:10 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [nova] Bug importance

Gary,

Not sure what changed...

On this page (https://bugs.launchpad.net/nova/) on the right hand side, do you 
see "Bug Supervisor" set to "Nova Bug Team"?  I believe "Nova Bug Team" is open 
and you can add yourself, so if you do not see yourself in that group, can you 
please add it and try?

-- Dims

On Sun, Sep 6, 2015 at 4:56 AM, Gary Kotton 
> wrote:
Hi,
In the past I was able to set the importance of a bug. Now I am unable to do 
this? Has the policy changed? Can someone please clarify. If the policy has 
changed who is responsible for deciding the priority of a bug?
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




--
Davanum Srinivas :: 
https://twitter.com/dims
__
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] Mitaka Design Summit - Proposed slot allocation

[Zhipeng Huang]

Do we have enough logistics for projects that are not in the schedule above
but also want to have ad hoc sessions at the design summit venue? For
example like in Paris we usually just grab a table and slap a card with
project name on it.

On Sat, Sep 5, 2015 at 1:55 AM, Jim Rollenhagen 
wrote:

> On Fri, Sep 04, 2015 at 01:52:41PM +0200, Dmitry Tantsur wrote:
> > On 09/04/2015 12:14 PM, Thierry Carrez wrote:
> > >Hi PTLs,
> > >
> > >Here is the proposed slot allocation for every "big tent" project team
> > >at the Mitaka Design Summit in Tokyo. This is based on the requests the
> > >liberty PTLs have made, space availability and project activity &
> > >collaboration needs.
> > >
> > >We have a lot less space (and time slots) in Tokyo compared to
> > >Vancouver, so we were unable to give every team what they wanted. In
> > >particular, there were far more workroom requests than we have
> > >available, so we had to cut down on those quite heavily. Please note
> > >that we'll have a large lunch room with roundtables inside the Design
> > >Summit space that can easily be abused (outside of lunch) as space for
> > >extra discussions.
> > >
> > >Here is the allocation:
> > >
> > >| fb: fishbowl 40-min slots
> > >| wr: workroom 40-min slots
> > >| cm: Friday contributors meetup
> > >| | day: full day, morn: only morning, aft: only afternoon
> > >
> > >Neutron: 12fb, cm:day
> > >Nova: 14fb, cm:day
> > >Cinder: 5fb, 4wr, cm:day
> > >Horizon: 2fb, 7wr, cm:day
> > >Heat: 4fb, 8wr, cm:morn
> > >Keystone: 7fb, 3wr, cm:day
> > >Ironic: 4fb, 4wr, cm:morn
> > >Oslo: 3fb, 5wr
> > >Rally: 1fb, 2wr
> > >Kolla: 3fb, 5wr, cm:aft
> > >Ceilometer: 2fb, 7wr, cm:morn
> > >TripleO: 2fb, 1wr, cm:full
> > >Sahara: 2fb, 5wr, cm:aft
> > >Murano: 2wr, cm:full
> > >Glance: 3fb, 5wr, cm:full
> > >Manila: 2fb, 4wr, cm:morn
> > >Magnum: 5fb, 5wr, cm:full
> > >Swift: 2fb, 12wr, cm:full
> > >Trove: 2fb, 4wr, cm:aft
> > >Barbican: 2fb, 6wr, cm:aft
> > >Designate: 1fb, 4wr, cm:aft
> > >OpenStackClient: 1fb, 1wr, cm:morn
> > >Mistral: 1fb, 3wr
> > >Zaqar: 1fb, 3wr
> > >Congress: 3wr
> > >Cue: 1fb, 1wr
> > >Solum: 1fb
> > >Searchlight: 1fb, 1wr
> > >MagnetoDB: won't be present
> > >
> > >Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)
> > >PuppetOpenStack: 2fb, 3wr
> > >Documentation: 2fb, 4wr, cm:morn
> > >Quality Assurance: 4fb, 4wr, cm:full
> > >OpenStackAnsible: 2fb, 1wr, cm:aft
> > >Release management: 1fb, 1wr (shared meetup with QA)
> > >Security: 2fb, 2wr
> > >ChefOpenstack: will camp in the lunch room all week
> > >App catalog: 1fb, 1wr
> > >I18n: cm:morn
> > >OpenStack UX: 2wr
> > >Packaging-deb: 2wr
> > >Refstack: 2wr
> > >RpmPackaging: 1fb, 1wr
> > >
> > >We'll start working on laying out those sessions over the available
> > >rooms and time slots. If you have constraints (I already know
> > >searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
> > >Manila with Cinder, Solum with Magnum...) please let me know, we'll do
> > >our best to limit them.
> > >
> >
> > Would be cool to avoid conflicts between Ironic and TripleO.
>
> I'd also like to save room for one Ironic/Nova session, and one
> Ironic/Neutron session.
>
> // jim
>
> __
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] Bug importance

[Gary Kotton]

Hi,
In the past I was able to set the importance of a bug. Now I am unable to do 
this? Has the policy changed? Can someone please clarify. If the policy has 
changed who is responsible for deciding the priority of a bug?
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] [Keystone][Glance] keystonemiddleware & multiple keystone endpoints

[joehuang]

Hello, Jamie and Hans,

The patch " Allow specifying a region name to auth_token " 
https://review.openstack.org/#/c/216579 has just been merged.

But unfortunately, when I modify the source code as this patch did in the 
multisite cloud with Fernet token, the issue is still there, and routed to 
incorrect endpoint.

I also check the region_name configuration in the source code, it's correct. 

The issue mentioned in the bug report not addressed yet: 
https://bugs.launchpad.net/keystonemiddleware/+bug/1488347

Is there anyone who tested it successfully in your environment?


The log of Glance API, the request was redirected to http://172.17.0.95:35357, 
but this address is not a KeyStone endpoint. (http://172.17.0.98:35357 and 
http://172.17.0.41:35357 are correct KeyStone endpoints )
//
2015-09-06 07:50:43.447 194 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.98:35357 -H "Accept: application/json" -H "User-Agent: 
python-keystoneclient" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-06 07:50:43.468 194 DEBUG keystoneclient.session [-] RESP: [300] 
content-length: 593 vary: X-Auth-Token connection: keep-alive date: Sun, 06 Sep 
2015 07:50:43 GMT content-type: application/json x-distribution: Ubuntu 
RESP BODY: {"versions": {"values": [{"status": "stable", "updated": 
"2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links": 
[{"href": "http://172.17.0.98:35357/v3/;, "rel": "self"}]}, {"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://172.17.0.98:35357/v2.0/;, "rel": 
"self"}, {"href": "http://docs.openstack.org/;, "type": "text/html", "rel": 
"describedby"}]}]}}
 _http_log_response 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
2015-09-06 07:50:43.469 194 DEBUG keystoneclient.auth.identity.v3 [-] Making 
authentication request to http://172.17.0.98:35357/v3/auth/tokens get_auth_ref 
/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
2015-09-06 07:50:43.574 194 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.95:35357 -H "Accept: application/json" -H "User-Agent: 
python-keystoneclient" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-06 07:50:46.576 194 WARNING keystoneclient.auth.identity.base [-] 
Failed to contact the endpoint at http://172.17.0.95:35357 for discovery. 
Fallback to using that endpoint as the base url.
2015-09-06 07:50:46.576 194 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.95:35357/auth/tokens -H "X-Subject-Token: 
{SHA1}640964e1f8716ecbb10ca3d8b5b08c8e7abfac1d" -H "User-Agent: 
python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}386777062718e0992cc818780e3ec7fa0671d8e9" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-06 07:50:49.576 194 INFO keystoneclient.session [-] Failure: Unable to 
establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in 0.5s.
2015-09-06 07:50:52.576 194 INFO keystoneclient.session [-] Failure: Unable to 
establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in 1.0s.
2015-09-06 07:50:55.576 194 INFO keystoneclient.session [-] Failure: Unable to 
establish connection to http://172.17.0.95:35357/auth/tokens. Retrying in 2.0s.
2015-09-06 07:50:58.576 194 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token


Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Hans Feldt [mailto:hans.fe...@ericsson.com] 
Sent: Tuesday, August 25, 2015 5:06 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][Glance] keystonemiddleware & multiple 
keystone endpoints



On 2015-08-25 09:37, Jamie Lennox wrote:
>
>
> - Original Message -
>> From: "Hans Feldt" 
>> To: openstack-dev@lists.openstack.org
>> Sent: Thursday, August 20, 2015 10:40:28 PM
>> Subject: [openstack-dev] [Keystone][Glance] keystonemiddleware & multiple
>> keystone endpoints
>>
>> How do you configure/use keystonemiddleware for a specific identity 
>> endpoint among several?
>>
>> In an OPNFV multi region prototype I have keystone endpoints per 
>> region. I would like keystonemiddleware (in context of glance-api) to 
>> use the local keystone for performing user token validation. Instead 
>> keystonemiddleware seems to use the first listed keystone endpoint in 
>> the service catalog (which could be wrong/non-optimal in most 
>> regions).
>>
>> I found this closed, related bug:
>> https://bugs.launchpad.net/python-keystoneclient/+bug/1147530
>
> Hey,
>
> There's two points to this.
>
> * If you are using an auth plugin then you're 

Re: [openstack-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[Monty Taylor]

On 09/05/2015 06:19 PM, Sean M. Collins wrote:

On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:

Right, it depends on your perspective of who 'owns' the API. Is it
cloud-init or EC2?

At this point I would argue that cloud-init is in control because it would
be a large undertaking to switch all of the AMI's on Amazon to something
else. However, I know Sean disagrees with me on this point so I'll let him
reply here.



Here's my take:

Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
in both the Neutron and Nova projects should all the details of the
Metadata API that is documented at:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

This means that this is a compatibility layer that OpenStack has
implemented so that users can use appliances, applications, and
operating system images in both Amazon EC2 and an OpenStack environment.

Yes, we can make changes to cloud-init. However, there is no guarantee
that all users of the Metadata API are exclusively using cloud-init as
their client. It is highly unlikely that people are rolling their own
Metadata API clients, but it's a contract we've made with users. This
includes transport level details like the IP address that the service
listens on.

The Metadata API is an established API that Amazon introduced years ago,
and we shouldn't be "improving" APIs that we don't control. If Amazon
were to introduce IPv6 support the Metadata API tomorrow, we would
naturally implement it exactly the way they implemented it in EC2. We'd
honor the contract that Amazon made with its users, in our Metadata API,
since it is a compatibility layer.

However, since they haven't defined transport level details of the
Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
solution. It is not our API.

The nice thing about config-drive is that we've created a new mechanism
for bootstrapping instances - by replacing the transport level details
of the API. Rather than being a link-local address that instances access
over HTTP, it's a device that guests can mount and read. The actual
contents of the drive may have a similar schema as the Metadata API, but
I think at this point we've made enough of a differentiation between the
EC2 Metadata API and config-drive that I believe the contents of the
actual drive that the instance mounts can be changed without breaking
user expectations - since config-drive was developed by the OpenStack
community. The point being that we call it "config-drive" in
conversation and our docs. Users understand that config-drive is a
different feature.


Another great part about config-drive is that it's scalable. At infra's 
application scale, we take pains to disable anyting in our images that 
might want to contact the metadata API because we're essentially a DDOS 
on it.


config-drive being local to the hypervisor host makes it MUCH more 
stable at scale.


cloud-init supports config-drive

If it were up to me, nobody would be enablig the metadata API in new 
deployments.


I totally agree that we should not make changes in the metadata API.


I've had this same conversation about the Security Group API that we
have. We've named it the same thing as the Amazon API, but then went and
made all the fields different, inexplicably. Thankfully, it's just the
names of the fields, rather than being huge conceptual changes.

http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html

Basically, I believe that OpenStack should create APIs that are
community driven and owned, and that we should only emulate
non-community APIs where appropriate, and explicitly state that we only
are emulating them. Putting improvements in APIs that came from
somewhere else, instead of creating new OpenStack branded APIs is a lost
opportunity to differentiate OpenStack from other projects, as well as
Amazon AWS.

Thanks for reading, and have a great holiday.



I could not possibly agree more if our brains were physically fused.

__
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] RFE Bugs - Add Tags to resources and Port Forwarding

[Gal Sagie]

Hello All,

i wanted to remind the community some RFE's bugs that need
review/processing

1) Add tags to Neutron resources

RFE: https://bugs.launchpad.net/neutron/+bug/1489291
Spec: https://review.openstack.org/#/c/216021/

In terms of the RFE, i think the drivers team discussed this RFE and
decided to
at least move on to design/spec step (The bug currently doesn't reflect
that yet)

Regarding the spec it self, i think we had some good comments on it and
they are
all addressed in the updated patch (link above).
Would love to get more comments on it and start working on the
implementation
and hopefully we can also discuss it in the summit. (There is one
dependency i am
waiting for some work by Kevin Benton for a common Neutron object which
the tags implementation should leverage, will of course let him extend
on it once he is ready)

2) Port forwarding

 RFE: https://bugs.launchpad.net/neutron/+bug/1491317

 I have sent an email to the mailing list:

http://lists.openstack.org/pipermail/openstack-dev/2015-September/073461.html

 This email describe all the past efforts to implement this feature, i
think its a valuable
 functionality and all the previous interest in it show that as well.
 Would love to move forward with this as well and start drafting a
spec, would like the
 drivers team to look at it and see if i should move forward to the
next step.

Thanks
Gal.
__
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] Mitaka Design Summit - Proposed slot allocation

[Emilien Macchi]

On 09/04/2015 06:14 AM, Thierry Carrez wrote:
> Hi PTLs,
> 
> Here is the proposed slot allocation for every "big tent" project team
> at the Mitaka Design Summit in Tokyo. This is based on the requests the
> liberty PTLs have made, space availability and project activity &
> collaboration needs.
> 
> We have a lot less space (and time slots) in Tokyo compared to
> Vancouver, so we were unable to give every team what they wanted. In
> particular, there were far more workroom requests than we have
> available, so we had to cut down on those quite heavily. Please note
> that we'll have a large lunch room with roundtables inside the Design
> Summit space that can easily be abused (outside of lunch) as space for
> extra discussions.
> 
> Here is the allocation:
> 
> | fb: fishbowl 40-min slots
> | wr: workroom 40-min slots
> | cm: Friday contributors meetup
> | | day: full day, morn: only morning, aft: only afternoon
> 
> Neutron: 12fb, cm:day
> Nova: 14fb, cm:day
> Cinder: 5fb, 4wr, cm:day  
> Horizon: 2fb, 7wr, cm:day 
> Heat: 4fb, 8wr, cm:morn
> Keystone: 7fb, 3wr, cm:day
> Ironic: 4fb, 4wr, cm:morn
> Oslo: 3fb, 5wr
> Rally: 1fb, 2wr
> Kolla: 3fb, 5wr, cm:aft
> Ceilometer: 2fb, 7wr, cm:morn
> TripleO: 2fb, 1wr, cm:full
> Sahara: 2fb, 5wr, cm:aft
> Murano: 2wr, cm:full
> Glance: 3fb, 5wr, cm:full 
> Manila: 2fb, 4wr, cm:morn
> Magnum: 5fb, 5wr, cm:full 
> Swift: 2fb, 12wr, cm:full 
> Trove: 2fb, 4wr, cm:aft
> Barbican: 2fb, 6wr, cm:aft
> Designate: 1fb, 4wr, cm:aft
> OpenStackClient: 1fb, 1wr, cm:morn
> Mistral: 1fb, 3wr 
> Zaqar: 1fb, 3wr
> Congress: 3wr
> Cue: 1fb, 1wr
> Solum: 1fb
> Searchlight: 1fb, 1wr
> MagnetoDB: won't be present
> 
> Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)   
> PuppetOpenStack: 2fb, 3wr

I know Infra & PuppetOpenStack have a lot of common bits together, if we
could avoid slot conflicts, it would be awesome.

Thanks,

> Documentation: 2fb, 4wr, cm:morn
> Quality Assurance: 4fb, 4wr, cm:full
> OpenStackAnsible: 2fb, 1wr, cm:aft
> Release management: 1fb, 1wr (shared meetup with QA)
> Security: 2fb, 2wr
> ChefOpenstack: will camp in the lunch room all week
> App catalog: 1fb, 1wr
> I18n: cm:morn
> OpenStack UX: 2wr
> Packaging-deb: 2wr
> Refstack: 2wr
> RpmPackaging: 1fb, 1wr
> 
> We'll start working on laying out those sessions over the available
> rooms and time slots. If you have constraints (I already know
> searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
> Manila with Cinder, Solum with Magnum...) please let me know, we'll do
> our best to limit them.
> 

-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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] [magnum]keystone version

[Morgan Fainberg]

> On Sep 5, 2015, at 22:14, Steve Martinelli  wrote:
> 
> +1, we're trying to deprecate the v2 API as soon as is sanely possible. Plus, 
> there's no reason to not use v3 since you can achieve everything you could in 
> v2, plus more goodness.
> 
> Thanks,
> 
> Steve Martinelli
> OpenStack Keystone Core
> 
> 
Steve hit the mark dead on. Please aim to use v3 keystone api (and if you can't 
because of a bug or behavior please let us know before settling on v2 so we can 
try and fix it). 

--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-dev] [sahara] FFE request for scheduler and suspend EDP job for sahara

[lu jander]

Hi, Guys

 I would like to request FFE for scheduler EDP job and suspend EDP job for
sahara. these patches has been reviewed for a long time with lots of patch
sets.

Blueprint:

(1) https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs
(2)
https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs


Spec:

(1) https://review.openstack.org/#/c/175719/
(2) https://review.openstack.org/#/c/198264/


Patch:

(1) https://review.openstack.org/#/c/182310/
(2) https://review.openstack.org/#/c/201448/
__
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] This is what disabled-by-policy should look like to the user

[Duncan Thomas]

On 5 Sep 2015 05:47, "Adam Young"  wrote:

> Then let my Hijack:
>
> Policy is still broken.  We need the pieces of Dynamic policy.
>
> I am going to call for a cross project policy discussion for the upcoming
summit.  Please, please, please all the projects attend. The operators have
made it clear they need better policy support.

Can you give us a heads up on the perceived shortcomings, please, together
with an overview of any proposed changes? Turning up to a session to hear,
unprepared, something that can be introduced in advance over email so that
people can ruminate on the details and be better prepared to discuss them
is probably more productive than expecting tired, jet-lagged people to
think on their feet.

In general, I think the practice of introducing new things at design
summits, rather than letting people prepare, is slowing us down as a
community.
__
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