Re: [openstack-dev] [keystone] Can`t find Project ID

[Xie, Xianshan]

Hi Steve,
   Thanks for your reply.

It`s a stupid mistake.
I have made an invalid configuration for the provider`s project-id in the 
nodepool.yaml as follows:
{ project-id: 'admin' }
But the correct setting should be:
{ Project-name: 'admin'}  or { project-id: '<%= id of project admin %>' }

To be honest, I was misled by the  sample file 
os-ext-testing-data/etc/nodepool/nodepool.yaml.erb,
in which the project-id is also configured with admin.


Xiexs

From: Steve Martinelli [mailto:steve...@ca.ibm.com]
Sent: Friday, August 21, 2015 1:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Can`t find Project ID


For the rest of the mailing list, how was it resolved? :)

Thanks,

Steve Martinelli
OpenStack Keystone Core

[Inactive hide details for "Xie, Xianshan" ---2015/08/21 01:43:35 AM---Hi all,  
  This issue has already been resolved.]"Xie, Xianshan" ---2015/08/21 01:43:35 
AM---Hi all, This issue has already been resolved.

From: "Xie, Xianshan" mailto:xi...@cn.fujitsu.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: 2015/08/21 01:43 AM
Subject: Re: [openstack-dev] [keystone] Can`t find Project ID





Hi all,
This issue has already been resolved.
Thanks.


Xiexs

From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com]
Sent: Friday, August 21, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] Can`t find Project ID

Hi, all,

I got following error message while running nodepoold:


2015-08-21 20:18:00,336 ERROR nodepool.NodePool: Exception cleaning up leaked 
nodes
Traceback (most recent call last):
File "/home/nodepool/nodepool/nodepool.py", line 2399, in periodicCleanup
self.cleanupLeakedInstances()
File "/home/nodepool/nodepool/nodepool.py", line 2410, in cleanupLeakedInstances
servers = manager.listServers()
File "/home/nodepool/nodepool/provider_manager.py", line 570, in listServers
self._servers = self.submitTask(ListServersTask())
File "/home/nodepool/nodepool/task_manager.py", line 119, in submitTask
return task.wait()
File "/home/nodepool/nodepool/task_manager.py", line 57, in run
self.done(self.main(client))
File "/home/nodepool/nodepool/provider_manager.py", line 136, in main
servers = client.nova_client.servers.list()
File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 318, in 
nova_client
self.get_session_endpoint('compute')
File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 811, in 
get_session_endpoint
"Error getting %s endpoint: %s" % (service_key, str(e)))
OpenStackCloudException: Error getting compute endpoint: Project ID not found: 
admin (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: 
req-fb986bff-3cad-48e1-9da9-915ac9ef5927)
---

And in my case, the output info with cli listed as follows:
$ openstack service list
| ID | Name | Type |
+--+--++
| 213a7ba8f0564523a3d2769f77621fde | nova | compute |

$ openstack project list
+--++
| ID | Name |
+--++
| 0a765fdfa79a438aae56202bdd5824e2 | admin |

$ keystone endpoint-list
+--+---+-+-+-+--+
| id | region | publicurl | internalurl | adminurl | service_id |
+--+---+-+-+-+--+
| d89b009e81f04a17a26fd07ffbf83efb | regionOne | 
http://controller:8774/v2/%(tenant_id)s
 | 
http://controller:8774/v2/%(tenant_id)s
 | 
http://controller:8774/v2/%(tenant_id)s
 | 213a7ba8f0564523a3d2769f77621fde |
+--+---+-+-+-+--+


Have you ever seen this error? And could you give me any advice to solve it?
Thanks in advance.


Xiexs__
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

[openstack-dev] [swift] [swift3] Are there any objections to add scoped tempest job to swift3 pipeline?

[Andrey Pavlov]

Hi,

In our EC2-API project we use tempest job with regex
tempest.thirdparty.boto.
And I didn't find any job that runs tempest against cloud with swift3
plugin.
I think that this is a good idea to add to swift3 project pipeline tempest
job.
It will check functionality of swift3 plugin in real cloud with real
requests.
Tempests` boto tests have several test with s3 requests.

So question to swift3 team - do you have any objections?

-- 
Kind regards,
Andrey Pavlov.
__
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] Can`t find Project ID

[Steve Martinelli]

For the rest of the mailing list, how was it resolved? :)

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   "Xie, Xianshan" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/08/21 01:43 AM
Subject:Re: [openstack-dev] [keystone] Can`t find Project ID



Hi all,
   This issue has already been resolved.
   Thanks.


Xiexs

From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com]
Sent: Friday, August 21, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] Can`t find Project ID

Hi, all,

I got following error message while running nodepoold:


2015-08-21  20:18:00,336  ERROR  nodepool.NodePool:  Exception  cleaning up
leaked nodes
Traceback (most recent call last):
  File "/home/nodepool/nodepool/nodepool.py", line 2399, in periodicCleanup
self.cleanupLeakedInstances()
  File "/home/nodepool/nodepool/nodepool.py", line 2410, in
cleanupLeakedInstances
servers = manager.listServers()
  File"/home/nodepool/nodepool/provider_manager.py",   line   570,   in
listServers
self._servers = self.submitTask(ListServersTask())
  File "/home/nodepool/nodepool/task_manager.py", line 119, in submitTask
return task.wait()
  File "/home/nodepool/nodepool/task_manager.py", line 57, in run
self.done(self.main(client))
  File "/home/nodepool/nodepool/provider_manager.py", line 136, in main
servers = client.nova_client.servers.list()
  File   "/usr/local/lib/python2.7/dist-packages/shade/__init__.py",   line
318, in nova_client
self.get_session_endpoint('compute')
  File   "/usr/local/lib/python2.7/dist-packages/shade/__init__.py",   line
811, in get_session_endpoint
"Error getting %s endpoint: %s" % (service_key, str(e)))
OpenStackCloudException:  Error  getting  compute  endpoint: Project ID not
found:  admin  (Disable  debug  mode to suppress these details.) (HTTP 401)
(Request-ID: req-fb986bff-3cad-48e1-9da9-915ac9ef5927)
---

And in my case, the output info with cli listed as follows:
$ openstack service list
| ID   | Name | Type   |
+--+--++
| 213a7ba8f0564523a3d2769f77621fde | nova | compute|

$ openstack project list
+--++
| ID   | Name   |
+--++
| 0a765fdfa79a438aae56202bdd5824e2 | admin  |

$ keystone endpoint-list
+--+---+-+-+-+--+
| id |   region  |publicurl
|  internalurl |   adminurl
|service_id|
+--+---+-+-+-+--+
|d89b009e81f04a17a26fd07ffbf83efb|regionOne   |
http://controller:8774/v2/%(tenant_id)s   |
http://controller:8774/v2/%(tenant_id)s   |
http://controller:8774/v2/%(tenant_id)s  | 213a7ba8f0564523a3d2769f77621fde
|
+--+---+-+-+-+--+


Have  you  ever  seen this error? And could you give me any advice to solve
it?
Thanks in advance.


Xiexs
__
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] EMC VNX Blueprints Exceptions

[yang, xing]

Hi Mike,

No problem.

Thanks,
Xing


> On Aug 21, 2015, at 1:37 AM, "Mike Perez"  wrote:
> 
>> On Thu, Aug 20, 2015 at 8:27 PM, yang, xing  wrote:
>> Hi Mike,
>> 
>> I’m wondering if you can consider approving the following blueprints.  They
>> were submitted late:(.  These are good to be used as reference
>> implementations for the new features, so I think it is good to have them.
>> 
>> https://blueprints.launchpad.net/cinder/+spec/non-disruptive-backup-in-vnx
>> Code is submitted for this one and it is in good shape now:
>> https://review.openstack.org/#/c/214626/
>> 
>> https://blueprints.launchpad.net/cinder/+spec/vnx-clone-cg (Code will be
>> submitted soon)
>> 
>> Thanks for your consideration!
> 
> Hi Xing,
> 
> I would prefer exceptions be sent to the list instead of privately, so
> I've cc'd the dev list.
> 
> I'm not going to be making exceptions on these. Yes this gives a
> reference implementation for non-disruptive backups, however, we can
> merge a reference implementation in the M release since others won't
> be able to do anything with it until the M release anyways.
> 
> --
> Mike Perez
__
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] Can`t find Project ID

[Xie, Xianshan]

Hi all,
   This issue has already been resolved.
   Thanks.


Xiexs

From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com]
Sent: Friday, August 21, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] Can`t find Project ID

Hi, all,

I got following error message while running nodepoold:


2015-08-21 20:18:00,336 ERROR nodepool.NodePool: Exception cleaning up leaked 
nodes
Traceback (most recent call last):
  File "/home/nodepool/nodepool/nodepool.py", line 2399, in periodicCleanup
self.cleanupLeakedInstances()
  File "/home/nodepool/nodepool/nodepool.py", line 2410, in 
cleanupLeakedInstances
servers = manager.listServers()
  File "/home/nodepool/nodepool/provider_manager.py", line 570, in listServers
self._servers = self.submitTask(ListServersTask())
  File "/home/nodepool/nodepool/task_manager.py", line 119, in submitTask
return task.wait()
  File "/home/nodepool/nodepool/task_manager.py", line 57, in run
self.done(self.main(client))
  File "/home/nodepool/nodepool/provider_manager.py", line 136, in main
servers = client.nova_client.servers.list()
  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 318, in 
nova_client
self.get_session_endpoint('compute')
  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 811, in 
get_session_endpoint
"Error getting %s endpoint: %s" % (service_key, str(e)))
OpenStackCloudException: Error getting compute endpoint: Project ID not found: 
admin (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: 
req-fb986bff-3cad-48e1-9da9-915ac9ef5927)
---

And in my case, the output info with cli listed as follows:
$ openstack service list
| ID   | Name | Type   |
+--+--++
| 213a7ba8f0564523a3d2769f77621fde | nova | compute|

$ openstack project list
+--++
| ID   | Name   |
+--++
| 0a765fdfa79a438aae56202bdd5824e2 | admin  |

$ keystone endpoint-list
+--+---+-+-+-+--+
|id|   region  |publicurl   
 |   internalurl   | adminurl   
 |service_id|
+--+---+-+-+-+--+
| d89b009e81f04a17a26fd07ffbf83efb | regionOne | 
http://controller:8774/v2/%(tenant_id)s
 | 
http://controller:8774/v2/%(tenant_id)s
 | 
http://controller:8774/v2/%(tenant_id)s
 | 213a7ba8f0564523a3d2769f77621fde |
+--+---+-+-+-+--+


Have you ever seen this error? And could you give me any advice to solve it?
Thanks in advance.


Xiexs
__
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] [cinder] EMC VNX Blueprints Exceptions

[Mike Perez]

On Thu, Aug 20, 2015 at 8:27 PM, yang, xing  wrote:
> Hi Mike,
>
> I’m wondering if you can consider approving the following blueprints.  They
> were submitted late:(.  These are good to be used as reference
> implementations for the new features, so I think it is good to have them.
>
> https://blueprints.launchpad.net/cinder/+spec/non-disruptive-backup-in-vnx
> Code is submitted for this one and it is in good shape now:
> https://review.openstack.org/#/c/214626/
>
> https://blueprints.launchpad.net/cinder/+spec/vnx-clone-cg (Code will be
> submitted soon)
>
> Thanks for your consideration!

Hi Xing,

I would prefer exceptions be sent to the list instead of privately, so
I've cc'd the dev list.

I'm not going to be making exceptions on these. Yes this gives a
reference implementation for non-disruptive backups, however, we can
merge a reference implementation in the M release since others won't
be able to do anything with it until the M release anyways.

--
Mike Perez

__
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] federation

[Navid Pustchi]

Hi

I am testing the feasibility of federated token to access another federated
resource.
For this purpos, I setup three devstack kilo instances as:

kilo1 (IdP) -> kilo2 (SP / IdP) -> kilo3 (SP)

1. get a federated scoped token for a project in kilo2.

2. using this federated token, get federated scoped token for a project in
kilo3.

I get 500 internal server error from kilo2.
If I remove service provider in kilo2 (registered for kilo3), i can get
federated scoped token.

So far I know for issuing v3 token, the error is within webob
python /usr/local/lib/python2.7/dist-packages/webob/dec.py while
authenticating the
token in /keystone/auth/controllers.py. the following link is the stack
trace:
http://paste.openstack.org/show/422584/

The issue is when a SP is setup to be idp as well service provider (for
kilo3) in kilo2, then i get http 500 internal server error.

The response unscoped token from kilo2 is the following link:
http://paste.openstack.org/show/412951/

I wanted to know if somebody tested similar scenarios or had similar issues.


Thanks for your response
-Navid Pustchi
__
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] [infra] API docs latest-n-greatest

[Alex Xu]

> 在 2015年8月21日，上午9:48，Anne Gentle  写道：
> 
> Hi all, 
> A couple of notes for API docs this week. One is, the spec to enable RST 
> builds to developer.openstack.org/api-guide/ 
>  merged. The plan is 
> completely documented here: 
> http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html 
> 
> 
> I'm trying to work through the best way to build those while still working 
> with Russell Sim on the WADL to Swagger converter at fairy-slipper:
> https://github.com/russell/fairy-slipper 
> 
> 
> Basically run migrate.sh and then run_server.sh to see what Swagger can look 
> like when published (very rough). I'm fixing errors found in the WADL with 
> migrate.sh as we go and hopefully we can start maintaining Swagger only 
> before October. 
> He's working on Issues #4 and #10 but all others are up for grabs: 
> https://github.com/russell/fairy-slipper/issues 
> 
> 
> Then, next release we can use our baseline Swagger to ensure the docs get 
> updated either automatically or manually. If your project already uses Pecan 
> you may be able to write Swagger with this 
> https://github.com/elmiko/pecan-swagger 
> .
> 
> Some have noted these aren't in the OpenStack git namespace but right now, 
> the publishing outcome is more important than the governance so we'll get 
> there when needed. 
> 
> I'll also put in a formal request here for the infrastructure team to let us 
> know how to request a server that can serve content on 
> developer.openstack.org  rather than Cloud 
> Sites. I'll attend the Infra team meeting next week and I've added it to the 
> agenda.
> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
>  
> 
> 
> Final note, I've written a set of API docs guidelines in the API Working 
> Group repository. Please review and offer input, since this guidance applies 
> for all OpenStack APIs. https://review.openstack.org/#/c/214817/ 
> 
> 
> In summary:
>  - Please keep the WADL updated for now and continue to fix WADL bugs.
>  - Take a look at fairy-slipper for the migration and pecan-swagger for 
> generation.
>  - Review the API docs guidelines and ask questions.
>  - With less than 2 months until release, let's git 'er done.

Thanks for the summary!

> 
> Thanks,
> Anne
> 
> -- 
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.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

__
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] Consistent functional test failures

[Steven Dake (stdake)]

Kai,

This sounds like a good solution.  The actual VM doesn’t need to be super large 
given our present tests.

Regards
-steve


From: Kai Qiang Wu mailto:wk...@cn.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 14, 2015 at 3:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Magnum] Consistent functional test failures


I have checked with infra team members. For two instances, 10GB each should be 
OK.

So I add some steps to create magnum specific flavor(8 GB disk), instead of use 
the existed devstack flavors (m1.small needs 20GB, m1.tiny can not be used)

Magnum creates one for jenkins job and delete it when tests finished.


Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle!

[Inactive hide details for Clark Boylan ---08/14/2015 08:05:15 AM---On Thu, Aug 
13, 2015, at 03:13 AM, Tom Cammann wrote: > Hi T]Clark Boylan ---08/14/2015 
08:05:15 AM---On Thu, Aug 13, 2015, at 03:13 AM, Tom Cammann wrote: > Hi Team,

From: Clark Boylan mailto:cboy...@sapwetik.org>>
To: openstack-dev@lists.openstack.org
Date: 08/14/2015 08:05 AM
Subject: Re: [openstack-dev] [Magnum] Consistent functional test failures





On Thu, Aug 13, 2015, at 03:13 AM, Tom Cammann wrote:
> Hi Team,
>
> Wanted to let you know why we are having consistent functional test
> failures in the gate.
>
> This is being caused by Nova returning "No valid host" to heat:
>
> 2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE:
> Server "kube_minion" [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a] Stack
> "testbay-y366b2atg6mm-kube_minions-cdlfyvhaximr-0-dufsjliqfoet"
> [b40f0c9f-cb54-4d75-86c3-8a9f347a27a6]
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource Traceback (most
> recent call last):
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/resource.py", line 625, in
> _action_recorder
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/resource.py", line 696, in _do_action
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
> self.action_handler_task(action, args=handler_args)
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/scheduler.py", line 320, in wrapper
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource step =
> next(subtask)
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/resource.py", line 670, in
> action_handler_task
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource while not
> check(handler_data):
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/resources/openstack/nova/server.py",
> line 759, in check_create_complete
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource return
> self.client_plugin()._check_active(server_id)
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
> "/opt/stack/new/heat/heat/engine/clients/os/nova.py", line 232, in
> _check_active
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource 'code':
> fault.get('code', _('Unknown'))
> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource
> ResourceInError: Went to status ERROR due to "Message: No valid host was
> found. There are not enough hosts available., Code: 500"
>
> And this in turn is being caused by the compute instance running out of
> disk space:
>
> 2015-08-13 08:26:15.216 DEBUG nova.filters
> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Starting with 1
> host(s) get_filtered_objects /opt/stack/new/nova/nova/filters.py:70
> 2015-08-13 08:26:15.217 DEBUG nova.filters
> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
> RetryFilter returned 1 host(s) get_filtered_objects
> /opt/stack/new/nova/nova/filters.py:84
> 2015-08-13 08:26:15.217 DEBUG nova.filters
> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
> AvailabilityZoneFilter returned 1 host(s) get_filtered_objects
> /opt/stack/new/nova/nova/filters.py:84
> 2015-08-13 08:26:15.217 DEBUG nova.filters
> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter RamFilter
> returned 1 host(s) get_filtered_objects
> /opt/stack/new/nova/nova/filters.py:84
> 

Re: [openstack-dev] [Magnum] Consistent functional test failures (seems infra not have enough resource)

[Steven Dake (stdake)]

On 8/13/15, 6:13 AM, "Jeremy Stanley"  wrote:

>On 2015-08-13 19:38:07 +0800 (+0800), Kai Qiang Wu wrote:
>> I did talked to infra, which I think it is resource issue, But
>> they thought it is nova issue,
>[...]
>
>No, I said the error was being raised by Nova, so was not an error
>coming _from_ the infrastructure we manage. If your jobs are more
>resource-intensive than a typical devstack/tempest job, you'll want
>to look at ways to scale them back.
>
>> It is 20GB disk space, so failed for that.
>
>Correct, we run jobs on resources donated by public service
>providers. Some of them only provide a 20GB root disk. There's
>generally an ephemeral disk mounted at /opt with additional space if
>you can modify your job to leverage that for whatever is running out
>of space.

How large is /opt?

>
>> I think it is related with this, the jenkins allocated VM disk
>> space is not large. I am curious why it failed so often recently.
>> Does os-infra changed something ?
>
>Nothing has been intentionally changed with our disk space on job
>workers as far as I'm aware. Different workers have varying root
>disk sizes depending on the provider where they were booted, but
>they could be as small as 20GB so your job will need to take that
>into account.

20gb isn¹t enough for Magnum¹s CI jobs.  We could link /var/lib/docker to
/opt if there is sufficient space there.

Regards,
-steve

>-- 
>Jeremy Stanley
>
>__
>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] [Horizon] Update on Angular Identity work

[Lin Hua Cheng]

Hi Thai,

>From your example, option 1 seems closer to the *current pattern* not
option 2. :) Where the user define a list of action separately from the
table presentation (HTML template) rather than embedding it in the HTML.
And if the user wants to extend it, they just add it to the list of
columns/actions on the table class.

Option 1 seems better to me due to I find it closer to the current pattern.
As long as we can reduce the duplicate code (not having to write 9 files to
create one table), I'm good with that. :)

My main concern is really to polish first the initial table implementation
before folks jump into implementing the tables in all other panels.  So we
can avoid re-work, don't want another cycle of clean-up/refactor. :)

I think we already have 2 angular tables out, should be enough data to
figure out what duplicate code can be abstracted out based from those two
implementation.

-Lin


On Thu, Aug 20, 2015 at 4:36 PM, Doug Fish  wrote:

> It appears to me that option 1 would be better prepared to be extensible
> ... That is if a plugin needed to add an action or a column, we could make
> that happen with pattern 1 (possibly after adding in a service) I'm not
> sure how plugins ever add these things with pattern 2.
>
> On Aug 20, 2015, at 1:41 PM, "Thai Q Tran"  wrote:
>
> Hi Lin,
>
> Let me draw on some examples to help clarify what I mean.
>
> *Option 1:*
>
> table.controller.js
> 
> ctrl.headers = {
>   gettext('column 1'),
>   gettext('column 2')
> };
>
> ctrl.noItemMessage = gettext('You no longer have any items in your table.
> You either lack the sufficient priveledges or your search criteria is not
> valid');
>
> ctrl.batchActionList = [
>   { name: 'create', onclick: somefunction, etc }
>   { name: 'delete', onclick: somefunction, etc }
> ];
>
> ctrl.rowActionList = [
>   { name: 'edit', onclick: somefunction, etc }
>   { name: 'delete', onclick: somefunction, etc }
> ];
>
> table.html
> ---
> 
>headers="ctrl.headers"
> batch-actions="ctrl.batchActionList"
> row-actions="ctrl.rowActionList">
>   
> 
>
> So now your controller is polluted with presentation and translation
> logic. In addition, we will have to live with long gettext messages and
> add eslint ignore rules just to pass it. The flip side is that you do
> have a simple directive that points to a common template sitting somewhere. It
> is not that much "easier" to the example below. What we're really doing is
> defining the same presentation logic, but in the HTML instead. Lastly, I'll
> bring up the customization again because many products are going to want to
> customize their tables. They maybe the minority but that doesn't mean we
> shouldn't support them.
>
> *Option 2:*
>
> table.html
> 
> 
> 
>   
> 
>   Create
>   Delete
> 
>   
>   
> Column 1
> Column 2
>   
> 
> 
>   
> 
> 
>   Edit
>   Delete
> 
>   
> 
> 
>
> Here, your table.controller.js worries ONLY about data and data
> manipulation. The presentation logic all resides in the HTML. If I want to
> add icons in the table header, I can do that easily. Remember that this is
> plain HTML, this is a lot easier for someone new to come in and learn this
> than our special horizon-table directive. It is definitely easier to USE,
> but I would argue that it is harder to learn.
>
> --
>
> If you compare the two options above, you'll see that all we've really
> done is move presentation logic from the controller into the HTML. You have
> to define that logic somewhere, why not in the HTML? This makes it easier
> to read and know what you're going to see in the browser (something HTML5
> spec is evangelizing), and you get the bonus benefit of customization.
>
> I'd like to point out that we aren't getting rid of directives, we're
> still using directives them (like , , ,
> etc..) in our tables. The pattern is, you build your panels using smaller
> components instead of having one giant component that encapsulates
> everything. Of course, there isn't a right or wrong answer, in fact there
> are two very different implementations of a table directive out there
> right now:
>
> http://ng-table.com (more inline with option 1)
> http://lorenzofox3.github.io/smart-table-website/ (more inline with
> option 2)
>
> Basically, what I'm trying to say is: let's build something simple and
> easy to understand first (small components that we work), then we can build
> something more complex on top of it so that it easier to use. I don't think
> there is a right or wrong answer, just two very different ways of thinking
> and implementation. But if we start with smaller components first, we get
> the goods of both world. The guys that want to customize will have a way to
> do it by bypassing the horizon-table directive, and the guys that just want
> a simple table can use the more complex directive.
>
> -Lin Hua Cheng  wrote: -
> To: "OpenStack De

[openstack-dev] [infra] API docs latest-n-greatest

[Anne Gentle]

Hi all,
A couple of notes for API docs this week. One is, the spec to enable RST
builds to developer.openstack.org/api-guide/ merged. The plan is
completely documented here:
http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html

I'm trying to work through the best way to build those while still working
with Russell Sim on the WADL to Swagger converter at fairy-slipper:
https://github.com/russell/fairy-slipper

Basically run migrate.sh and then run_server.sh to see what Swagger can
look like when published (very rough). I'm fixing errors found in the WADL
with migrate.sh as we go and hopefully we can start maintaining Swagger
only before October.
He's working on Issues #4 and #10 but all others are up for grabs:
https://github.com/russell/fairy-slipper/issues

Then, next release we can use our baseline Swagger to ensure the docs get
updated either automatically or manually. If your project already uses
Pecan you may be able to write Swagger with this
https://github.com/elmiko/pecan-swagger.

Some have noted these aren't in the OpenStack git namespace but right now,
the publishing outcome is more important than the governance so we'll get
there when needed.

I'll also put in a formal request here for the infrastructure team to let
us know how to request a server that can serve content on
developer.openstack.org rather than Cloud Sites. I'll attend the Infra team
meeting next week and I've added it to the agenda.
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Final note, I've written a set of API docs guidelines in the API Working
Group repository. Please review and offer input, since this guidance
applies for all OpenStack APIs. https://review.openstack.org/#/c/214817/

In summary:
 - Please keep the WADL updated for now and continue to fix WADL bugs.
 - Take a look at fairy-slipper for the migration and pecan-swagger for
generation.
 - Review the API docs guidelines and ask questions.
 - With less than 2 months until release, let's git 'er done.

Thanks,
Anne

-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.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

Re: [openstack-dev] [Magnum] Consistent functional test failures

[Steven Dake (stdake)]

On 8/13/15, 4:58 PM, "Clark Boylan"  wrote:

>On Thu, Aug 13, 2015, at 03:13 AM, Tom Cammann wrote:
>> Hi Team,
>> 
>> Wanted to let you know why we are having consistent functional test
>> failures in the gate.
>> 
>> This is being caused by Nova returning "No valid host" to heat:
>> 
>> 2015-08-13 08:26:16.303 31543 INFO heat.engine.resource [-] CREATE:
>> Server "kube_minion" [12ab45ef-0177-4118-9ba0-3fffbc3c1d1a] Stack
>> "testbay-y366b2atg6mm-kube_minions-cdlfyvhaximr-0-dufsjliqfoet"
>> [b40f0c9f-cb54-4d75-86c3-8a9f347a27a6]
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource Traceback
>>(most 
>> recent call last):
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/resource.py", line 625, in
>> _action_recorder
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/resource.py", line 696, in _do_action
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource yield
>> self.action_handler_task(action, args=handler_args)
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/scheduler.py", line 320, in wrapper
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource step =
>> next(subtask)
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/resource.py", line 670, in
>> action_handler_task
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource while not
>> check(handler_data):
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/resources/openstack/nova/server.py",
>> line 759, in check_create_complete
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource return
>> self.client_plugin()._check_active(server_id)
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource File
>> "/opt/stack/new/heat/heat/engine/clients/os/nova.py", line 232, in
>> _check_active
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource 'code':
>> fault.get('code', _('Unknown'))
>> 2015-08-13 08:26:16.303 31543 ERROR heat.engine.resource
>> ResourceInError: Went to status ERROR due to "Message: No valid host
>>was 
>> found. There are not enough hosts available., Code: 500"
>> 
>> And this in turn is being caused by the compute instance running out of
>> disk space:
>> 
>> 2015-08-13 08:26:15.216 DEBUG nova.filters
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Starting with 1
>> host(s) get_filtered_objects /opt/stack/new/nova/nova/filters.py:70
>> 2015-08-13 08:26:15.217 DEBUG nova.filters
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
>> RetryFilter returned 1 host(s) get_filtered_objects
>> /opt/stack/new/nova/nova/filters.py:84
>> 2015-08-13 08:26:15.217 DEBUG nova.filters
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
>> AvailabilityZoneFilter returned 1 host(s) get_filtered_objects
>> /opt/stack/new/nova/nova/filters.py:84
>> 2015-08-13 08:26:15.217 DEBUG nova.filters
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter RamFilter
>> returned 1 host(s) get_filtered_objects
>> /opt/stack/new/nova/nova/filters.py:84
>> 2015-08-13 08:26:15.218 DEBUG nova.scheduler.filters.disk_filter
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin]
>> (devstack-trusty-rax-dfw-4299602, devstack-trusty-rax-dfw-4299602)
>> ram:5172 disk:17408 io_ops:0 instances:1 does not have 20480 MB usable
>> disk, it only has 17408.0 MB usable disk. host_passes
>> /opt/stack/new/nova/nova/scheduler/filters/disk_filter.py:60
>> 2015-08-13 08:26:15.218 INFO nova.filters
>> [req-e5bb52cb-387e-4638-911e-8c72aa1b6400 admin admin] Filter
>>DiskFilter 
>> returned 0 hosts
>> 
>> For now a recheck seems to work about 1 in 2, so we can still land
>> patches.
>> 
>> The fix for this could be to clean up our Magnum devstack install more
>> aggressively, which might be as simple as cleaning up the images we
>>use, 
>> or get infra to provide our tests with a larger disk size. I will
>> probably test out a patch today which cleans up the images we use in
>> devstack to see if that helps.
>> 
>It is not trivial to provide your tests with more disk as we are using
>the flavors appropriate for our RAM and CPU needs and are constrained by
>quotas in the clouds we use. Do you really need 20GB nested test
>instances? The VMs these jobs run on have ~13GB images which is almost
>half the size of the instances you are trying to boot there. I would
>definitely look into trimming the disk requirements for the nested VMs
>before anything else.
>
>As for working ~50% of the time hpcloud gives us more disk than
>rackspace which is likely why you see about half fail and half pass. The
>runs that pass probably run on hpcloud VMs.

In the short term, is there a way to request HP vms?

20gb won¹t do the job unfortunately.

Regards,
-steve

>
>Clark
>
>__

[openstack-dev] [CI] Cannot get compute endpoint when running nodepool.

[Tang Chen]

Hi, all,

I got following error message while running nodepoold with "nodepoold 
-d  $DAEMON_ARGS"




2015-08-21 20:18:00,336 ERROR nodepool.NodePool: Exception cleaning up 
leaked nodes


Traceback (most recent call last):

  File "/home/nodepool/nodepool/nodepool.py", line 2399, in periodicCleanup

self.cleanupLeakedInstances()

  File "/home/nodepool/nodepool/nodepool.py", line 2410, in 
cleanupLeakedInstances


servers = manager.listServers()

  File "/home/nodepool/nodepool/provider_manager.py", line 570, in 
listServers


self._servers = self.submitTask(ListServersTask())

  File "/home/nodepool/nodepool/task_manager.py", line 119, in submitTask

return task.wait()

  File "/home/nodepool/nodepool/task_manager.py", line 57, in run

self.done(self.main(client))

  File "/home/nodepool/nodepool/provider_manager.py", line 136, in main

servers = client.nova_client.servers.list()

  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 
318, in nova_client


self.get_session_endpoint('compute')

  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 
811, in get_session_endpoint


"Error getting %s endpoint: %s" % (service_key, str(e)))

OpenStackCloudException: Error getting compute endpoint: Project ID not 
found: admin (Disable debug mode to suppress these details.) (HTTP 401) 
(Request-ID: req-fb986bff-3cad-48e1-9da9-915ac9ef5927)


---

And in my case, the output info with cli listed as follows:

$ openstack service list

| ID   | Name | Type   |

+--+--++

| 213a7ba8f0564523a3d2769f77621fde | nova | compute|

$ openstack project list

+--++

| ID   | Name   |

+--++

| 0a765fdfa79a438aae56202bdd5824e2 | admin  |

$ keystone endpoint-list

+--+---+-+-+-+--+

|id|   region |  
  publicurl| internalurl   | 
adminurl|service_id|


+--+---+-+-+-+--+

| d89b009e81f04a17a26fd07ffbf83efb | regionOne | 
http://controller:8774/v2/%(tenant_id)s 
 | 
http://controller:8774/v2/%(tenant_id)s 
 | 
http://controller:8774/v2/%(tenant_id)s 
 | 
213a7ba8f0564523a3d2769f77621fde |


+--+---+-+-+-+--+

Have you ever seen this error? And could you give me any advice to solve it?

Thanks in advance.
__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[Alex Xu]

> 在 2015年8月21日，上午10:14，Alex Xu  写道：
> 
>> 
>> 在 2015年8月21日，上午3:09，Jay Pipes > > 写道：
>> 
>> On 08/20/2015 02:08 PM, melanie witt wrote:
>>> On Aug 20, 2015, at 5:40, Alex Xu >> > wrote:
>>> 
 So user may wrote client like this:
 
 if response.status == 500 and ‘OverQuota’ in response.message:
 …..
>>> 
>>> I thought we're not supporting that type of case. My understanding is that 
>>> we should never be returning 500 and if we are, it's a bug fix to change it 
>>> to an appropriate error status code without version bumps. I find it in the 
>>> documentation [1][2] too.
>> 
>> Yup, you are correct.
> 
> Yea, from API-WG guideline, and from my understanding, I also agree to 500 
> isn’t expect error. 
> 
> Why I thinking of this, is because I want to explain how to deal with 
> different deployment of openstack.
> 
> The one of goal for micro versions is to make our API consistent between 
> different deployment and discoverable the change between the deployment.
> 
> Finally in this email I get answer for the different deployment question by 
> make 500 as contract. yea, finally no one think this is right.
> 
> So, let me change another way to answer this question, and the baseline is 
> 500 isn’t part of contract.
> 
> My answer is we did not have good API contract in the beginning(in the 
> nova-spec).  For example, the bug we return 500 for overquota, if we have api 
> ref or nova-spec said, we will return 403 for overquota, then the thing is 
> very easy, we fix it with return 403 and no micro versions. But we didn’t 
> have such doc or spec describe that, then we don’t know the API contract. But 
> I think people we feel insane if we require such detail nova-spec again.

More explain for this part…avoid my poor English didn’t explain clearly. Let’s 
say if we have describe clearly in the nova-spec or api-ref to say 403 is 
available return code, then we needn’t detect what is available status code by 
checking the expected_error decorator 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/deferred_delete.py#L52
 

  Actually that decorator is part of bug, it isn’t part of contract.

If we have contract in the beginning, then we can answer this rule easily also 
http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
 


So what I want to say, why we confuse on those, it because we didn’t have the 
initial contract...

> 
> So I changed the answer a little again in the 
> https://review.openstack.org/#/c/215195/ 
> :
> 
> 500 isn't expect error. So user never should based on 500 error, and we won't 
> guarantee anything on 500.
> There may have bug we should return 4** but we return 500. But if 4** is 
> existed logic in the beginning of the API(Maybe we forget describe that in 
> the nova-spec or api ref.), then we think the 4** already is part of API 
> contract, we should fix it to match the contract, and it needn't new 
> microversions.
> And we should back-port this fix. Operator should update their deployment to 
> fix that bug.
> 
> Does this sounds make sense?
> 
> Thanks
> Alex
> 
>> 
>> Best,
>> -jay
>> 
>> __
>> 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] [infra][third-party] Some unknown updates broke nodepool connection to provider. Read for solution.

[Asselin, Ramy]

All,

Recently, some external dependency broke nodepool's ability to launch VMs on an 
openstack provider.
If you haven't run into this yet, it's probably because you haven't restarted 
nodepool.
When you do, you might get an error similar to [1]

I couldn't find the issue, but regardless, there's a fix to nodepool that's 
been merged  [2].
However, you do need to update your nodepool.yaml configurations to use 
'project-name' instead of 'project-id'.
Here's an example [3]
I don't know the solution if you're using cloud.yaml, but it should be similar.

Ramy
irc: asselin


[1] 
http://logs.openstack.org/54/211754/4/check/gate-dsvm-nodepool-nv/958471b/logs/screen-nodepool.txt.gz#_2015-08-18_22_59_57_227
[2] https://review.openstack.org/#/c/214399/2
[3] 
https://github.com/rasselin/os-ext-testing-data/commit/00dcce696c7fb8d3b5e55e1984ebb2bff9edfcb2

__
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] Can`t find Project ID

[Xie, Xianshan]

Hi, all,

I got following error message while running nodepoold:


2015-08-21 20:18:00,336 ERROR nodepool.NodePool: Exception cleaning up leaked 
nodes
Traceback (most recent call last):
  File "/home/nodepool/nodepool/nodepool.py", line 2399, in periodicCleanup
self.cleanupLeakedInstances()
  File "/home/nodepool/nodepool/nodepool.py", line 2410, in 
cleanupLeakedInstances
servers = manager.listServers()
  File "/home/nodepool/nodepool/provider_manager.py", line 570, in listServers
self._servers = self.submitTask(ListServersTask())
  File "/home/nodepool/nodepool/task_manager.py", line 119, in submitTask
return task.wait()
  File "/home/nodepool/nodepool/task_manager.py", line 57, in run
self.done(self.main(client))
  File "/home/nodepool/nodepool/provider_manager.py", line 136, in main
servers = client.nova_client.servers.list()
  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 318, in 
nova_client
self.get_session_endpoint('compute')
  File "/usr/local/lib/python2.7/dist-packages/shade/__init__.py", line 811, in 
get_session_endpoint
"Error getting %s endpoint: %s" % (service_key, str(e)))
OpenStackCloudException: Error getting compute endpoint: Project ID not found: 
admin (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: 
req-fb986bff-3cad-48e1-9da9-915ac9ef5927)
---

And in my case, the output info with cli listed as follows:
$ openstack service list
| ID   | Name | Type   |
+--+--++
| 213a7ba8f0564523a3d2769f77621fde | nova | compute|

$ openstack project list
+--++
| ID   | Name   |
+--++
| 0a765fdfa79a438aae56202bdd5824e2 | admin  |

$ keystone endpoint-list
+--+---+-+-+-+--+
|id|   region  |publicurl   
 |   internalurl   | adminurl   
 |service_id|
+--+---+-+-+-+--+
| d89b009e81f04a17a26fd07ffbf83efb | regionOne | 
http://controller:8774/v2/%(tenant_id)s | 
http://controller:8774/v2/%(tenant_id)s | 
http://controller:8774/v2/%(tenant_id)s | 213a7ba8f0564523a3d2769f77621fde |
+--+---+-+-+-+--+


Have you ever seen this error? And could you give me any advice to solve it?
Thanks in advance.


Xiexs
__
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] [Ironic] Let's talk about API versions

[Ruby Loo]

On 18 August 2015 at 17:13, Ruby Loo  wrote:

>
>
> On 18 August 2015 at 13:08, Lucas Alvares Gomes 
> wrote:
>
>> HI
>>
>> > Hi, I'd like to make sure I understand. Is it the case that ideally,
>> if we
>
> > could go back in time, we'd like to change the client so it defaults to
>> 1.1?
>>
>> AFAIUI, yes
>>
>> > But since we can't, the next client that we ship/release will have the
>> most
>> > reasonable oldest version? If so, then since the most recent client
>> shipped
>> > is at 1.6, then I think we should put it back to 1.6 even though it is
>> 1.9
>> > on master. Regardless of whether there are no backwards incompatible
>> changes
>> > between 1.6 & 1.9 -- because we need to stick to some
>> way-of-doing-things,
>> > and if we use 1.9, I suspect it will be confusing. At least 1.6 was
>> what we
>> > had at the end of kilo.
>> >
>>
>> The reason why I think we should release with 1.9 is because:
>>
>> 1) It's already on master and people may be using it already
>>
>> 2) It's compatible with the previous version that has been released
>> already (1.6).
>>
>> So it won't break neither users that just get it from pip nor users
>> that clone the git repository.
>>
>
> The order of my preference is 1.1 (which is unrealistic as I mention
> below), 1.6 (because that's what the client had in kilo release and is the
> 'closest' version to the server's 1.1), then 1.9 for the reasons you
> mentioned above, then 1.10 just cuz it is the last version that is
> backwards compatible :-)
>
> Devananda has a patch[0] that changes the client to 1.6, but the
> reviewers' comments there point to the mailing list (here) wrt deciding
> what it should be so what do other folks think?
>
>>
>>
In case we don't resolve this via email, I added this topic (which default
version should the client use) to our next meeting's agenda.

cheers,
--ruby
__
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] feedback from the ops mid cycle summit

[melanie witt]

Hi Everyone,

I attended the ops mid cycle summit on Tuesday and Wednesday and here are brief 
notes on the feedback I heard related to nova. Please feel free to add your 
comments or correct me if I got anything wrong.


Large Deployments Session [1]:

- There's a Neutron spec [2] for adding the capability to model an L3 network 
which is composed of L2 networks that are routed together, and this project 
will require cooperation from the nova side
- Cells v2 not coming along as quickly as expected. Cells v1 issues around 
compat between versions, understood it's not supported but it's been a problem
- Hierarchical multi-tenancy isn't yet supported (quotas)


Upgrades Session Report:
- Good linking of features to documentation is important
- Inter-service changes are important to call out
- Flavor migration is an example of something done well


Other general notes:
- Event capture is a choice between two bad options
- Information divided between events and logs. Have to capture both or you lose 
the whole picture
- Hard to trace RPC calls
- Race conditions with scheduling and quotas
- The state of Nova and NUMA is not understood
- Glance v2 is not being used. From what I understand, we can't move to it 
because images created by v1 can't be read by v2, for example?


All of the etherpads from the event are linked here: 
https://etherpad.openstack.org/p/PAO-ops-meetup


Thanks,
-melanie (irc: melwitt)


[1] https://etherpad.openstack.org/p/PAO-ops-large-deployments
[2] https://review.openstack.org/#/c/196812/



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[GHANSHYAM MANN]

On Thu, Aug 20, 2015 at 3:33 AM, Matt Riedemann
 wrote:
>
>
> On 8/19/2015 12:18 PM, Chen CH Ji wrote:
>>
>> In doing [1] [2], some suggestions raised that those kind of change need
>> microversion bump which is fine
>> however, another concern raised on whether we need combine a set of
>> those kind of changes (which may only change some error code) into one
>> bump ?
>>
>> apparently there are pros and cons for doing so, combine makes API
>> version bump not that frequent for minor changes
>> but makes it hard to review and backport ... so any suggestions on how
>> to handle ? Thanks
>>
>>
>> [1]https://review.openstack.org/#/c/198753/
>> [2]https://review.openstack.org/#/c/173985/
>>
>> Best Regards!
>>
>> Kevin (Chen) Ji 纪 晨
>>
>> Engineer, zVM Development, CSTL
>> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
>> Phone: +86-10-82454158
>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
>> District, Beijing 100193, PRC
>>
>>
>> __
>> 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 don't see why https://review.openstack.org/#/c/198753/ would require a
> microversion bump.  We've always allowed handling 500s and turning them into
> more appropriate error codes, like a 400 in this case.
>
> As noted:
>
> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>
> "Changing an error response code to be more accurate." is generally
> acceptable.

humm, actually m confused now whether we should consider changing
error code as backward incompatible or not. or its more broken in 2
part? 1 introduced new error code (500-> new error code) 2. changing
to existing error code and which one is backward incompatible?

IMO (considering most users/app checking existing/published error code
range) 1 one should be considered as backward incompatible.

>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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



-- 
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] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[GHANSHYAM MANN]

On Thu, Aug 20, 2015 at 9:40 PM, Alex Xu  wrote:
> Let me wrote down what I’m analyse about this(I’m not good at this…and this
> spend another hour for me...):
>
> When OverQuota isn’t catched by API layer, we will get response as below:
>
> {"computeFault": {"message": "Unexpected API Error. Please report this at
> http://bugs.launchpad.net/nova/ and attach the Nova API log if
> possible.\n", "code": 500}}
>
> So user may wrote client like this:
>
> if response.status == 500 and ‘OverQuota’ in response.message:

Yes, that much possible even if they not checking particular error
code but they could have checking for range of known error return for
that API.
Which makes me on side of microversion doc which say not to introduced
new error code without version bump.

> …..
>
> If we fix this to 403 without microversions, then in different openstack
> deployment we will have different return code for OverQuota.
>
> From this doc
> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n129
> , provide a way to avoid
> bump microversion. The doc suggest turn it into existed return code. But
> looks like it still drop into the different openstack deployment case.
> So can we remove this footnote?

Not sure but more possibility is app checking range of returned error
code. If so then we should be ok but if they check particular error
code then you have much valid point to correct doc.

I was checking couple of patches for 500 correction which make me also
feel that we should fix all 500 thing in single microversion. Only
issue is we need to investigate well/complete before doing that. One
way can be keep adding finding somewhere and fix it at end of release
in single microversion.

>
> If this analysis is correct, then we need new microverions.
>
> For v2 API, I think we needn't fix it… If v2.1 fix with microverions, this
> fix can’t be back-port also, 500 bug is always part of old API contract.
> If we want to make nova API consistent now, v2 API can follow this rule
> also, 500 is already part of contract of it.
>
> Thanks,
> Alex
>
> 在 2015年8月20日，上午3:37，Matt Riedemann  写道：
>
>
>
> On 8/19/2015 2:16 PM, Matt Riedemann wrote:
>
>
>
> On 8/19/2015 1:33 PM, Matt Riedemann wrote:
>
>
>
> On 8/19/2015 12:18 PM, Chen CH Ji wrote:
>
> In doing [1] [2], some suggestions raised that those kind of change need
> microversion bump which is fine
> however, another concern raised on whether we need combine a set of
> those kind of changes (which may only change some error code) into one
> bump ?
>
> apparently there are pros and cons for doing so, combine makes API
> version bump not that frequent for minor changes
> but makes it hard to review and backport ... so any suggestions on how
> to handle ? Thanks
>
>
> [1]https://review.openstack.org/#/c/198753/
> [2]https://review.openstack.org/#/c/173985/
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
>
> __
>
>
> 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 don't see why https://review.openstack.org/#/c/198753/ would require a
> microversion bump.  We've always allowed handling 500s and turning them
> into more appropriate error codes, like a 400 in this case.
>
> As noted:
>
> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>
>
>
> "Changing an error response code to be more accurate." is generally
> acceptable.
>
>
> https://review.openstack.org/#/c/173985/ doesn't require a version bump
> for the same reasons, IMO.  If people are hung up on 400 vs 403 in that
> change, just make it a 400, we do it both ways in the compute API.
>
>
> I guess the problems are in the doc:
>
> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
>
>  - the list of status codes allowed for a particular request
>
>Example: an API previously could return 200, 400, 403, 404 and the
>change would make the API now also be allowed to return 409.
>
>  - changing a status code on a particular response
>
>Example: changing the return code of an API from 501 to 400.
>
> So in the one change, just return 400.  In the service_get change where you
> want to return a 400 but it's only returning a 404 today, then I guess
> according to the doc you'd need a microversion bump. But what do we do about
> fixing that bug in the v2 API?  Do we not fix it?  Do we return 404 but v2.1
> would return 400 with a microversion bump?  That's equally inconsistent and
> gross IMO.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> 

Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[Alex Xu]

> 在 2015年8月21日，上午3:09，Jay Pipes  写道：
> 
> On 08/20/2015 02:08 PM, melanie witt wrote:
>> On Aug 20, 2015, at 5:40, Alex Xu  wrote:
>> 
>>> So user may wrote client like this:
>>> 
>>> if response.status == 500 and ‘OverQuota’ in response.message:
>>> …..
>> 
>> I thought we're not supporting that type of case. My understanding is that 
>> we should never be returning 500 and if we are, it's a bug fix to change it 
>> to an appropriate error status code without version bumps. I find it in the 
>> documentation [1][2] too.
> 
> Yup, you are correct.

Yea, from API-WG guideline, and from my understanding, I also agree to 500 
isn’t expect error. 

Why I thinking of this, is because I want to explain how to deal with different 
deployment of openstack.

The one of goal for micro versions is to make our API consistent between 
different deployment and discoverable the change between the deployment.

Finally in this email I get answer for the different deployment question by 
make 500 as contract. yea, finally no one think this is right.

So, let me change another way to answer this question, and the baseline is 500 
isn’t part of contract.

My answer is we did not have good API contract in the beginning(in the 
nova-spec).  For example, the bug we return 500 for overquota, if we have api 
ref or nova-spec said, we will return 403 for overquota, then the thing is very 
easy, we fix it with return 403 and no micro versions. But we didn’t have such 
doc or spec describe that, then we don’t know the API contract. But I think 
people we feel insane if we require such detail nova-spec again.

So I changed the answer a little again in the 
https://review.openstack.org/#/c/215195/ 
:

500 isn't expect error. So user never should based on 500 error, and we won't 
guarantee anything on 500.
There may have bug we should return 4** but we return 500. But if 4** is 
existed logic in the beginning of the API(Maybe we forget describe that in the 
nova-spec or api ref.), then we think the 4** already is part of API contract, 
we should fix it to match the contract, and it needn't new microversions.
And we should back-port this fix. Operator should update their deployment to 
fix that bug.

Does this sounds make sense?

Thanks
Alex

> 
> Best,
> -jay
> 
> __
> 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] [OpenStack-docs] [docs][api] pecan-swagger generated api

[Anne Gentle]

On Thu, Aug 20, 2015 at 7:58 PM, Melnik, Aleksandr S <
aleksandr.s.mel...@hp.com> wrote:

> I work on the Cue project at HP and I’m working on auto-generating our API
> documentation. I’m also keeping up with the changes and ongoing migrations
> at openstack docs. The new RST work documentation looks awesome for the
> user guides, but I’m very interested in where the api-docs are headed and
> how I can help get the ball rolling in a strong direction.
>
> I’m working with elmiko’s pecan-swagger plugin [1] and have a version that
> works well with Cue's API. This example [2] is a swagger spec that was
> auto-generated entirely by the pecan-swagger plugin and fed into the
> Swagger UI.  I stood this up to primarily show the power and usefulness of
> Swagger.
>
> While this works well and looks cool, I’m wondering if we can we do more.
> I’m not necessarily thinking about the official openstack doc sites, but
> about having a comprehensive specs for APIs, independent of our sites for
> now.
>
> Here are the steps needed for solid swagger specs:
>
> 1. Generate swagger spec
>
> Generating Swagger spec is what others and I have been working on, and a
> lot of tooling is already available.
>
> 2. Edit/confirm swagger spec
> (where i have questions, more info below)
>
> 3. Feed spec to UI (and more!)
>
> Feeding the spec to a UI is relatively simple, since several projects
> exist that do this [3].
>
> The missing piece that I’ve been thinking about lately is a sandboxy area
> to edit/confirm generated swagger specs (#2 above) and I’m wondering if
> anyone has a vision for what this should look like? I’ve heard of some
> ideas floating around but I would like to know more specifics.
>
> I think getting some automation around generating swagger specs, and
> having a place where humans can confirm them would be a great start!  Let's
> worry about how they end up on docs sites later.
>

Thanks for this Aleksandr. We've had a spec at
http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html
we're
working on this release to do all these, and fairy-slipper is where we're
working. I just sent a note to the openstack-docs mailing list with
updates.
http://lists.openstack.org/pipermail/openstack-docs/2015-August/007347.html
We would love your Swagger knowledge to add to our efforts.

I've also got API doc guidelines in the API working group that I'd like you
to review https://review.openstack.org/#/c/214817/

As for confirming the Swagger spec (2) for new projects, I'm open to ideas.
We've had to modify the Swagger 2.0 spec to accommodate existing known
non-conforming REST APIs such as Compute and Orchestration API sending
multiple request bodies to /actions resource. I think the way forward is
WADL to Swagger conversion to detect any drift in current reference and
then ensure that the Swagger output is updated with any patchset to the
code. For non-pecan WSGI frameworks we'll need a tool to create those.

Thanks,
Anne


>
>
> [1] https://github.com/elmiko/pecan-swagger
> [2] http://15.126.235.36
> [3] https://github.com/russell/fairy-slipper/
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.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

Re: [openstack-dev] [Horizon] Update on Angular Identity work

[Doug Fish]

It appears to me that option 1 would be better prepared to be extensible ... 
That is if a plugin needed to add an action or a column, we could make that 
happen with pattern 1 (possibly after adding in a service) I'm not sure how 
plugins ever add these things with pattern 2. 

> On Aug 20, 2015, at 1:41 PM, "Thai Q Tran"  wrote:
> 
> Hi Lin,
> 
> Let me draw on some examples to help clarify what I mean.
> 
> Option 1:
> 
> table.controller.js
> 
> ctrl.headers = {
>   gettext('column 1'),
>   gettext('column 2')
> };
> 
> ctrl.noItemMessage = gettext('You no longer have any items in your table. You 
> either lack the sufficient priveledges or your search criteria is not valid');
> 
> ctrl.batchActionList = [
>   { name: 'create', onclick: somefunction, etc }
>   { name: 'delete', onclick: somefunction, etc }
> ];
> 
> ctrl.rowActionList = [
>   { name: 'edit', onclick: somefunction, etc }
>   { name: 'delete', onclick: somefunction, etc }
> ];
> 
> table.html
> ---
> 
>headers="ctrl.headers"
> batch-actions="ctrl.batchActionList"
> row-actions="ctrl.rowActionList">
>   
> 
> 
> So now your controller is polluted with presentation and translation logic. 
> In addition, we will have to live with long gettext messages and add eslint 
> ignore rules just to pass it. The flip side is that you do have a simple 
> directive that points to a common template sitting somewhere. It is not that 
> much "easier" to the example below. What we're really doing is defining the 
> same presentation logic, but in the HTML instead. Lastly, I'll bring up the 
> customization again because many products are going to want to customize 
> their tables. They maybe the minority but that doesn't mean we shouldn't 
> support them.
> 
> Option 2:
> 
> table.html
> 
> 
> 
>   
> 
>   Create
>   Delete
> 
>   
>   
> Column 1
> Column 2
>   
> 
> 
>   
> 
> 
>   Edit
>   Delete
> 
>   
> 
> 
> 
> Here, your table.controller.js worries ONLY about data and data manipulation. 
> The presentation logic all resides in the HTML. If I want to add icons in the 
> table header, I can do that easily. Remember that this is plain HTML, this is 
> a lot easier for someone new to come in and learn this than our special 
> horizon-table directive. It is definitely easier to USE, but I would argue 
> that it is harder to learn.
> 
> --
> 
> If you compare the two options above, you'll see that all we've really done 
> is move presentation logic from the controller into the HTML. You have to 
> define that logic somewhere, why not in the HTML? This makes it easier to 
> read and know what you're going to see in the browser (something HTML5 spec 
> is evangelizing), and you get the bonus benefit of customization.
> 
> I'd like to point out that we aren't getting rid of directives, we're still 
> using directives them (like , , , etc..) 
> in our tables. The pattern is, you build your panels using smaller components 
> instead of having one giant component that encapsulates everything. Of 
> course, there isn't a right or wrong answer, in fact there are two very 
> different implementations of a table directive out there right now:
> 
> http://ng-table.com (more inline with option 1)
> http://lorenzofox3.github.io/smart-table-website/ (more inline with option 2)
> 
> Basically, what I'm trying to say is: let's build something simple and easy 
> to understand first (small components that we work), then we can build 
> something more complex on top of it so that it easier to use. I don't think 
> there is a right or wrong answer, just two very different ways of thinking 
> and implementation. But if we start with smaller components first, we get the 
> goods of both world. The guys that want to customize will have a way to do it 
> by bypassing the horizon-table directive, and the guys that just want a 
> simple table can use the more complex directive.
> 
> -Lin Hua Cheng  wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> From: Lin Hua Cheng 
> Date: 08/19/2015 05:15PM
> Subject: Re: [openstack-dev] [Horizon] Update on Angular Identity work
> 
> Hi Thai,
> 
> Thanks for investigating the two options.
> 
> Option 2 might be better. Folks have to learn the new pattern of writing 
> multiple files, so I think the learning curve for a new table directive is 
> not that much of a difference.
> 
> I think option 2 is going to be easier to maintain, since we have a layer of 
> abstraction. It might even also increase adoptability since it would be 
> easier to use.  It might be harder to customize, but that would probably not 
> be done often.  The table directive would be used as is most of the time. 
> 
> My thought is design the code to be easy to use for the use case that will be 
> used most of the time rather than the customization case  which maybe harder 
> to do. Which leads me to 

Re: [openstack-dev] [TripleO] Moving instack upstream

[Derek Higgins]

Sorry for the delay in following up on this but I've been on my hols

The instack ci jobs should now work, it appears to be getting hit by a 
LOT of network glitches in particular downloading from the centos 
infrastructure but I think to avoid more delay we should merge the 
things and work on improving reliability, We have 3 things to merge in 
order to start the move


1. Switch the f21 nonha job to use instack (eventually we'll remove the 
old codepath)

https://review.openstack.org/#/c/185151/

2. Remove most of our ci jobs (we can build back up again afterwards)
https://review.openstack.org/#/c/205479/

3. pull in 3 repositories upstream
https://review.openstack.org/#/c/215186/

There will be follow up patches after these but this will get the ball 
rolling


thanks,
Derek.

On 23/07/15 07:40, Derek Higgins wrote:

See below

On 21/07/15 20:29, Derek Higgins wrote:

Hi All,
Something we discussed at the summit was to switch the focus of
tripleo's deployment method to deploy using instack using images built
with tripleo-puppet-elements. Up to now all the instack work has been
done downstream of tripleo as part of rdo. Having parts of our
deployment story outside of upstream gives us problems mainly because it
becomes very difficult to CI what we expect deployers to use while we're
developing the upstream parts.

Essentially what I'm talking about here is pulling instack-undercloud
upstream along with a few of its dependency projects (instack,
tripleo-common, tuskar-ui-extras etc..) into tripleo and using them in
our CI in place of devtest.

Getting our CI working with instack is close to working but has taken
longer then I expected because of various complications and distractions
but I hope to have something over the next few days that we can use to
replace devtest in CI, in a lot of ways this will start out by taking a
step backwards but we should finish up in a better place where we will
be developing (and running CI on) what we expect deployers to use.

Once I have something that works I think it makes sense to drop the jobs
undercloud-precise-nonha and overcloud-precise-nonha, while switching
overcloud-f21-nonha to use instack, this has a few effects that need to
be called out

1. We will no longer be running CI on (and as a result not supporting)
most of the the bash based elements
2. We will no longer be running CI on (and as a result not supporting)
ubuntu

Should anybody come along in the future interested in either of these
things (and prepared to put the time in) we can pick them back up again.
In fact the move to puppet element based images should mean we can more
easily add in extra distros in the future.

3. While we find our feet we should remove all tripleo-ci jobs from non
tripleo projects, once we're confident with it we can explore adding our
jobs back into other projects again

Nothing has changed yet, I order to check we're all on the same page
this is high level details of how I see things should proceed so shout
now if I got anything wrong or you disagree.


Ok, I have a POC that has worked end to end in our CI environment[1],
there are a *LOT* of workarounds in there so before we can merge it I
need to clean up and remove some of those workarounds and todo that a
few things need to move around, below is a list of what has to happen
(as best I can tell)

1) Pull in tripleo-heat-template spec changes to master delorean
We had two patches in the tripleo-heat-template midstream packaging that
havn't made it into the master packaging, these are
https://review.gerrithub.io/241056 Package firstboot and extraconfig
templates
https://review.gerrithub.io/241057 Package environments and newtork
directories

2) Fixes for instack-undercloud (I didn't push these directly incase it
effected people on old versions of puppet modules)
https://github.com/rdo-management/instack-undercloud/pull/5

3) Add packaging for various repositories into openstack-packaging
I've pulled the packaging for 5 repositories into
https://github.com/openstack-packages
https://github.com/openstack-packages/python-ironic-inspector-client
https://github.com/openstack-packages/python-rdomanager-oscplugin
https://github.com/openstack-packages/tuskar-ui-extras
https://github.com/openstack-packages/ironic-discoverd
https://github.com/openstack-packages/tripleo-common

I havn't imported these into gerrithub (incase following discussion we
need to delete them again) but assuming we're in agreement we should
pull them into gerrithub)

4) update rdoinfo
https://github.com/redhat-openstack/rdoinfo/pull/69
If everybody is happy with all above we should merge this, all of the
packages needed will now be on the delorean master repository

5) Move DELOREAN_REPO_URL in tripleo-ci to a new delorean repo that
includes all of the new packages

6) Take most of the workarounds out of this patch[1] and merge it

7) Reorg the tripleo ci tests (essentially remove all of the bash
element based tests).

8) Pull instack, instack-undercloud

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

[Tony Breeds]

On Thu, Aug 20, 2015 at 02:12:44PM +0300, Eduard Matei wrote:
> Hi,
> 
> ATM our workaround is to manually pip install futures==2.2.0 before running
> stack.sh

Yeah that's what I did.  You can also add that command to tools/fixup.sh
 
> Any idea when an "official" fix will be available?

We're workign on it.  Sorry I can't give you an ETA

Yours Tony.


pgpp4seNuZ2Nr.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] [packaging] asks from the ops meetup

[Matthew Thode]

On 08/20/2015 09:22 AM, Ian Cordasco wrote:
> 
> 
> On 8/19/15, 19:31, "Matthew Thode"  wrote:
> 
>> On 08/19/2015 07:22 PM, Ian Cordasco wrote:
>>> Questions in-line, but I'd appreciate a better summary
>>>
>>> On 8/19/15, 17:50, "Matthew Thode"  wrote:
>>>
 I'll start by giving this out, but I'll also summarize the asks we had
>>> >from upstream.

 https://etherpad.openstack.org/p/PAO-ops-packaging


 General services:
  - gate check on example config and doc generation
- was mentioned this has broken in the past and taken a while to fix
>>>
>>> The etherpad doesn't have much on this topic, could you (or someone else
>>> from the mid-cycle) expound on this?
>>
>> Not sure, wasn't the one that brought it up, but a specific check on
>> config/doc generation did seem like a good idea.
> 
> "A specific check on config/doc generation" is ironically vague here. What
> kind of check? That they can be generated? That the generated configs are
> properly read/parsed by the project? What is it that is being asked here?
> 

that they can be generated

>>
>>>
  - document dependencies needed for config/doc generation
- (not all of test requirements)
>>>
>>> So you want a doc-requirements.txt file? That doesn't have other
>>> libraries
>>> other than the documentation related ones?
>>>
>>
>> Yes, though I think this may cover example config generation as well.
>>
  - generated example configs generated and stored in an automated way
- (in lieu of packagers generating the configs dynamically)
>>>
>>> Don't most projects already do this?
>>
>> iirc neutron at least does not
> 
> I don't think you (as operators) should be afraid to say "These projects
> are not doing this. Here are the bugs that haven't been answered in
> several (days|weeks|months), please address them."
> 

fair enough, I'll see about gathering / making some bugs

>>>
  - A place to look for files that go in /etc
>>>
>>> Again, don't most projects have an etc/ directory inside of them?
>>
>> yes, though files have been removed in favor of dynamic generation.  The
>> more specific ask was for this to be auto generated and updated, which
>> we don't see as being done (could be wrong)
> 
> I know Glance keeps theirs up-to-date even if they don't auto-generate
> them. I'm also confident that at least Keystone auto-generates them
> periodically and commits them to the tree. I haven't checked other
> projects recently.
> 

yes, this needs proper enumeration, but I would also hope that the
projects could be more standard about how they do this

>>>
  - Publish pip-freeze at the end
>>>
>>> At the end of what?
>>
>> of a test/gerrit run
> 
> Then this already happens.

neat

> 
>>>
  - Don't strip out files in the repo when publishing to pip
>>>
>>> No services are published to PyPI. What is this about?
>>
>> Think this is more the bash autocomplete stuff
> 
> So then this isn't about Services then (despite being under the Services
> section of the summary). So the client libraries don't have their
> setup.cfg's properly configured to include bash completion files. That's a
> fair complaint. That said, bandit recently did the right thing and we
> received a bug report (via IRC) from the gentoo packaging team that we
> were doing it wrong.
> 

yes, haven't seen an update for that, will need to bug you tomorrow
about it :D

>>>
  - Publish an example init-script (systemd)
>>>
>>> This seems reasonable
>>>
- I think this might be going away with wsgi
>>>
>>> What?
>>
>> the init scripts may be going away because of wsgi, it's be in apache or
>> nginx or whatever
>>
>>>
 Docs:
  - nginx wsgi examples
>>>
>>> Is nginx even supported in any of the services? If so, are we already
>>> gating on that?
>>>
>> The docs give example configs for apache mod_wsgi, this was an ask for
>> similiar with nginx.
> 
> You fail to understand my point. Services that provide example configs for
> apache with mod_wsgi are choosing to explicitly support those
> configurations. Providing example configurations for nginx would imply a
> similar level of support from the teams documenting that. We would need to
> add gating to make sure the services behave well with nginx then as well.
> We could do this, but it isn't as simple as "adding a documentation
> example".
> 

ok

-- 
Matthew Thode (prometheanfire)



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] [congress][requirements] Requirements proposal job fails

[Robert Collins]

I think it would be nice if someone were to cook up a patch to the
functional tests (integration.sh) to make sure that we are still able
to sync to that project without errors.

-Rob

On 21 August 2015 at 08:01, Tim Hinrichs  wrote:
> Thanks for sorting that out.  +1ed the change.
>
> Tim
>
>
> On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger  wrote:
>>
>> On 08/20/2015 09:32 PM, Robert Collins wrote:
>> > It was just removed from global requirements, because it was not used.
>> > That's clearly wrong. So let's refer that and add it back.
>>
>> Ah, that explains it, let's revert the change:
>> https://review.openstack.org/#/c/215306/
>>
>> Thanks,
>> Andreas
>> --
>>   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>> HRB 21284 (AG Nürnberg)
>>  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> 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
>



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [ironic] Re: New API for node create, specifying initial provision state

[Jim Rollenhagen]

On Thu, Aug 20, 2015 at 09:57:14PM +0100, Lucas Alvares Gomes wrote:
> Hi
> 
> > On 21 Aug 2015 6:45 am, "Jim Rollenhagen" <
> >>
> >> +1, there are tons of dragons here. Now that we're to the point where
> >> our state machine is well-defined with a single entrypoint, I think
> >
> > I'm clearly confused. When was 1.6 deleted?
> >
> 
> It wasn't and won't be AFAICT. But I think Jim is talking about
> versions >= 1.11 of the API which will always use ENROLL as the  entry
> point because that's was how things were planned for the new state
> machine.
> 
> So yeah, we have more than one entry point depending on the version of
> the API you use.

Right, sorry about that.

I still think the point stands. Every new entrypoint adds
complexity that we need to manage, and I'd love for us to take a long
hard look at new ones and not just allow whatever people want. ACTIVE is
a great example of a state where we make a ton of assumptions about what
the node is doing and what metadata it has.

// 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

Re: [openstack-dev] [nova][cinder] Extending attached disks

[Taylor . Bertie]

Excellent,

Good to see this is being discussed on the Cinder side.

I'll keep looking and hopefully we hear back from Nova either in this thread or 
by other means if they're prepared to go ahead with this.

Regards,

Taylor Bertie
Enterprise Support Infrastructure Engineer

Mobile +64 27 952 3949
Phone +64 4 462 5030
Email taylor.ber...@solnet.co.nz

Solnet Solutions Limited
Level 12, Solnet House
70 The Terrace, Wellington 6011
PO Box 397, Wellington 6140

www.solnet.co.nz 


-Mike Perez  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: Mike Perez 
Date: 2015-08-21 9:45
Subject: Re: [openstack-dev] [nova][cinder] Extending attached disks

On 19:53 Aug 19, John Griffith wrote:
> On Wed, Aug 19, 2015 at 7:48 PM,  wrote:
> 
> > Hi everyone,
> >
> > Apologises for the duplicate send, looks like my mail client doesn't
> > create very clean HTML messages. Here is the message in plain-text. I'll
> > make sure to send to the list in plain-text from now on.
> >
> > In my current pre-production deployment we were looking for a method to
> > live extend attached volumes to an instance. This was one of the
> > requirements for deployment. I've worked with libvirt hypervisors before so
> > it didn't take long to find a workable solution. However I'm not sure how
> > transferable this will be across deployment models. Our deployment model is
> > using libvirt for nova and ceph for backend storage. This means obviously
> > libvirt is using rdb to connect to volumes.


 
> ​Hey Taylor,
> 
> This is something that has come up a number of times but I personally
> didn't have a good solution for it on the iSCSI side.  I'm not sure if your
> method would work with iSCSI attached devices because typically you need to
> detach/reattach for size changes to take effect, in other words I'm
> uncertain if libvirt would be able to see the changes.  That being said I
> also didn't know about this option in libvirt so it may work out.

This was discussed at the last Cinder midcycle meetup [1]. I'm not really
involved with working out the solution here, but the people involved we're
saying that there is a solution of having the shared library between Cinder and
Nova os-brick having the ability to inform libvirt of the size change.

The only caveat that we need Nova to agree on is this would only work with
Libvirt. This is planned for the M release.

[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015

-- 
Mike Perez

__
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

Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or postmas...@solnetsolutions.co.nz as
soon as possible. The content of this email does not necessarily
reflect the views of Solnet Solutions Ltd.


__
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][cinder] Extending attached disks

[Mike Perez]

On 19:53 Aug 19, John Griffith wrote:
> On Wed, Aug 19, 2015 at 7:48 PM,  wrote:
> 
> > Hi everyone,
> >
> > Apologises for the duplicate send, looks like my mail client doesn't
> > create very clean HTML messages. Here is the message in plain-text. I'll
> > make sure to send to the list in plain-text from now on.
> >
> > In my current pre-production deployment we were looking for a method to
> > live extend attached volumes to an instance. This was one of the
> > requirements for deployment. I've worked with libvirt hypervisors before so
> > it didn't take long to find a workable solution. However I'm not sure how
> > transferable this will be across deployment models. Our deployment model is
> > using libvirt for nova and ceph for backend storage. This means obviously
> > libvirt is using rdb to connect to volumes.


 
> ​Hey Taylor,
> 
> This is something that has come up a number of times but I personally
> didn't have a good solution for it on the iSCSI side.  I'm not sure if your
> method would work with iSCSI attached devices because typically you need to
> detach/reattach for size changes to take effect, in other words I'm
> uncertain if libvirt would be able to see the changes.  That being said I
> also didn't know about this option in libvirt so it may work out.

This was discussed at the last Cinder midcycle meetup [1]. I'm not really
involved with working out the solution here, but the people involved we're
saying that there is a solution of having the shared library between Cinder and
Nova os-brick having the ability to inform libvirt of the size change.

The only caveat that we need Nova to agree on is this would only work with
Libvirt. This is planned for the M release.

[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015

-- 
Mike Perez

__
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] [ironic] Re: New API for node create, specifying initial provision state

[Lucas Alvares Gomes]

Hi

> On 21 Aug 2015 6:45 am, "Jim Rollenhagen" <
>>
>> +1, there are tons of dragons here. Now that we're to the point where
>> our state machine is well-defined with a single entrypoint, I think
>
> I'm clearly confused. When was 1.6 deleted?
>

It wasn't and won't be AFAICT. But I think Jim is talking about
versions >= 1.11 of the API which will always use ENROLL as the  entry
point because that's was how things were planned for the new state
machine.

So yeah, we have more than one entry point depending on the version of
the API you use.

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

Re: [openstack-dev] [congress][requirements] Requirements proposal job fails

[Tim Hinrichs]

Thanks for sorting that out.  +1ed the change.

Tim


On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger  wrote:

> On 08/20/2015 09:32 PM, Robert Collins wrote:
> > It was just removed from global requirements, because it was not used.
> > That's clearly wrong. So let's refer that and add it back.
>
> Ah, that explains it, let's revert the change:
> https://review.openstack.org/#/c/215306/
>
> Thanks,
> Andreas
> --
>   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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] [congress][requirements] Requirements proposal job fails

[Andreas Jaeger]

On 08/20/2015 09:32 PM, Robert Collins wrote:

It was just removed from global requirements, because it was not used.
That's clearly wrong. So let's refer that and add it back.


Ah, that explains it, let's revert the change:
https://review.openstack.org/#/c/215306/

Thanks,
Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [congress][requirements] Requirements proposal job fails

[Robert Collins]

It was just removed from global requirements, because it was not used.
That's clearly wrong. So let's refer that and add it back.
On 21 Aug 2015 6:27 am, "Andreas Jaeger"  wrote:

> The requirements proposal job fails syncing to congress with this error:
> "'PuLP' is not in global-requirements.txt"
>
> congress team, please resolve this. Options include getting this into
> global-requirements or removing it from your project.
>
> Details:
>
> https://jenkins.openstack.org/job/propose-requirements-updates/
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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] [sahara] Proposing Ethan Gafford for the core reviewer team

[Sergey Lukjanov]

As there no objections, I'm glad to congratulate us with a new core review
team member ;)

Ethan, congratulations!

On Mon, Aug 17, 2015 at 10:48 AM, Flavio Percoco  wrote:

> On 16/08/15 19:51 +, Telles Nobrega wrote:
>
>>   For what is worth I got that it was just a joke.
>>
>
> That's great. However, not everyone did and this is a public mailing
> list with lots of newcomers.
>
> As I mentioned in my email, I know Trevor sent it with good intentions
> but not everyone read it that way (including me).
>
> I'm happy it was all clarified,
> Flavio
>
>   On Fri, Aug 14, 2015 at 2:30 PM Trevor McKay  wrote:
>>
>> Flavio,
>>
>> A  thanks, bad joke on my part. I work with Telles on Sahara, just
>> poking
>> him in jest.A  Apologies, didn't mean to create an issue on the list.
>>
>> Trev
>>
>> On Fri, 2015-08-14 at 17:30 +0200, Flavio Percoco wrote:
>> > On 14/08/15 09:29 -0400, Trevor McKay wrote:
>> > >Hi Telles,
>> > >
>> > > you technically don't get a vote, but thanks anyway :)
>> >
>> > Hi Trevor,
>> >
>> > Technically, everyone gets to vote and speak up. Regardless of
>> whether
>> > you're a core-reviewer or not. Most of the time, non-core
>> contributors
>> > provide amazing feedback on what their experience has been while
>> > receiving reviews from the nominated person.
>> >
>> > Regardless of the comment, we as a community always welcome
>> > contributor's opinions and encourage folks to speak up.
>> >
>> > I knew your intentions are good but I thought it'd be a good time to
>> > share the above so that it would work as a reminder for others as
>> > well.
>> >
>> > Thank you both and +1 for Ethan ;)
>> > Flavio
>> >
>> > >
>> > >Trev
>> > >
>> > >On Fri, 2015-08-14 at 12:14 +, Telles Nobrega wrote:
>> > >> +1
>> > >>
>> > >> On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov
>> > >>  wrote:
>> > >>
>> > >>A  A  A  A  A +1
>> > >>
>> > >>A  A  A  A  A Regards,
>> > >>A  A  A  A  A Alexander Ignatov
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>A  A  A  A  A > On 13 Aug 2015, at 18:29, Sergey Reshetnyak
>> > >>A  A  A  A  A >  wrote:
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A > +2
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A > 2015-08-13 18:07 GMT+03:00 Matthew Farrellee
>> > >>A  A  A  A  A > :
>> > >>A  A  A  A  A >A  A  A  A  A On 08/13/2015 10:56 AM, Sergey
>> Lukjanov
>> wrote:
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A Hi folks,
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A I'd like to propose Ethan
>> Gafford as a
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A member of the Sahara core
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A reviewer team.
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A Ethan contributing to
>> Sahara for a long time
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A and doing a great job on
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A reviewing and improving
>> Sahara. Here are the
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A statistics for reviews
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A [0][1][2] and commits
>> [3].
>> BTW Ethan is
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A already stable maint team
>> core
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A for Sahara.
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A Existing Sahara core
>> reviewers, please vote
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A +1/-1 for the addition of
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A Ethan to the core
>> reviewer
>> team.
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A Thanks.
>> > >>A  A  A  A  A >
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A [0]
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> https://review.openstack.org/#/q/reviewer:%
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> 22Ethan+Gafford+%253Cegafford%2540redhat.com
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A %253E%22,n,z
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A [1]
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> http://stackalytics.com/report/contribution/sahara-group/90
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A [2]
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> http://stackalytics.com/?user_id=egafford&metric=marks
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A [3]
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> https://review.openstack.org/#/q/owner:%
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A A
>> 22Ethan+Gafford+%253Cegafford%2540redhat.com
>> > >>A  A  A  A  A >A  A  A  A  A  A  A  A  A
>> %253E%22+status:merged,n,z
>> > >>A  A  A  A  A >
>> > >>A  

Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[Jay Pipes]

On 08/20/2015 02:08 PM, melanie witt wrote:

On Aug 20, 2015, at 5:40, Alex Xu  wrote:


So user may wrote client like this:

if response.status == 500 and ‘OverQuota’ in response.message:
 …..


I thought we're not supporting that type of case. My understanding is that we 
should never be returning 500 and if we are, it's a bug fix to change it to an 
appropriate error status code without version bumps. I find it in the 
documentation [1][2] too.


Yup, you are correct.

Best,
-jay

__
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] [ironic] Re: New API for node create, specifying initial provision state

[Robert Collins]

On 21 Aug 2015 6:45 am, "Jim Rollenhagen" <
>
> +1, there are tons of dragons here. Now that we're to the point where
> our state machine is well-defined with a single entrypoint, I think

I'm clearly confused. When was 1.6 deleted?

Rob
__
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] [Horizon] Update on Angular Identity work

[Thai Q Tran]

Hi Lin,Let me draw on some examples to help clarify what I mean.Option 1:table.controller.jsctrl.headers = {  gettext('column 1'),  gettext('column 2')};ctrl.noItemMessage = gettext('You no longer have any items in your table. You either lack the sufficient priveledges or your search criteria is not valid');ctrl.batchActionList = [  { name: 'create', onclick: somefunction, etc }  { name: 'delete', onclick: somefunction, etc }];ctrl.rowActionList = [  { name: 'edit', onclick: somefunction, etc }  { name: 'delete', onclick: somefunction, etc }];table.html---ng-controller="table.controller.js as ctrl">      headers="ctrl.headers"    batch-actions="ctrl.batchActionList"    row-actions="ctrl.rowActionList">  horizon-table>So now your controller is polluted with presentation and translation logic. In addition, we will have to live with long gettext messages and add eslint ignore rules just to pass it. The flip side is that you do have a simple directive that points to a common template sitting somewhere. It is not that much "easier" to the example below. What we're really doing is defining the same presentation logic, but in the HTML instead. Lastly, I'll bring up the customization again because many products are going to want to customize their tables. They maybe the minority but that doesn't mean we shouldn't support them.Option 2:table.html            Create      Delete            Column 1    Column 2                  Edit      Delete      Here, your table.controller.js worries ONLY about data and data manipulation. The presentation logic all resides in the HTML. If I want to add icons in the table header, I can do that easily. Remember that this is plain HTML, this is a lot easier for someone new to come in and learn this than our special horizon-table directive. It is definitely easier to USE, but I would argue that it is harder to learn.--If you compare the two options above, you'll see that all we've really done is move presentation logic from the controller into the HTML. You have to define that logic somewhere, why not in the HTML? This makes it easier to read and know what you're going to see in the browser (something HTML5 spec is evangelizing), and you get the bonus benefit of customization.I'd like to point out that we aren't getting rid of directives, we're still using directives them (like , , , etc..) in our tables. The pattern is, you build your panels using smaller components instead of having one giant component that encapsulates everything. Of course, there isn't a right or wrong answer, in fact there are two very different implementations of a table directive out there right now:http://ng-table.com (more inline with option 1)http://lorenzofox3.github.io/smart-table-website/ (more inline with option 2)Basically, what I'm trying to say is: let's build something simple and easy to understand first (small components that we work), then we can build something more complex on top of it so that it easier to use. I don't think there is a right or wrong answer, just two very different ways of thinking and implementation. But if we start with smaller components first, we get the goods of both world. The guys that want to customize will have a way to do it by bypassing the horizon-table directive, and the guys that just want a simple table can use the more complex directive.-Lin Hua Cheng  wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Lin Hua Cheng Date: 08/19/2015 05:15PMSubject: Re: [openstack-dev] [Horizon] Update on Angular Identity workHi Thai,Thanks for investigating the two options.Option 2 might be better. Folks have to learn the new pattern of writing multiple files, so I think the learning curve for a new table directive is not that much of a difference.I think option 2 is going to be easier to maintain, since we have a layer of abstraction. It might even also increase adoptability since it would be easier to use.  It might be harder to customize, but that would probably not be done often.  The table directive would be used as is most of the time. My thought is design the code to be easy to use for the use case that will be used most of the time rather than the customization case  which maybe harder to do. Which leads me to preferring option 2.Thanks,LinOn Wed, Aug 19, 2015 at 12:16 PM, Thai Q Tran  wrote:Hi Lin,I agree with you and Eric that we have a lot of HTML fragments. Some of them I think make sense as directives:The table footer is a good example of something we can convert into a directive: https://review.openstack.org/#/c/207631/The table header on the other hand is something more specific to your table: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table/table-header.htmlSo there are two approaches we

Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state

[Jim Rollenhagen]

On Wed, Aug 19, 2015 at 09:48:29AM +0100, Lucas Alvares Gomes wrote:
> Hi,
> 
> > After thinking about this some more, I'm not actually going to address Rob's
> > points above. What I want to do is go back and discuss... what do people
> > think about having an API that allows the initial provision state to be
> > specified, for a node that is created in Ironic. I'm assuming that enroll
> > state exists :)
> >
> > Earlier today on IRC, Devananda mentioned that "there's a very strong case
> > for allowing a node to be created in any of the stable states (enroll,
> > manageable, available, active)". Maybe he'll elaborate later on this. I know
> > that there's a use case where there is a desire to import nodes (with
> > instances on them) from another system into ironic, and have them be active
> > right away. (They don't want the nodes to go from
> > enroll->verifying->manageable->cleaning!!!->available!!!->active).
> >
> 
> I would like to hear the more elaborated proposal before we start
> digging much into this problem.
> 
> > 1. What would the default provision state be, if it wasn't specified?
> > A. 'available' to be backwards compatible with pre-v1.11
> > or
> > B. 'enroll' to be consistent with v1.11+
> > or
> > ?
> >
> >
> > 2. What would it mean to set the initial provision state to something other
> > than 'enroll'?
> >
> > manageable
> > 
> > In our state machinery[0], a node goes from enroll -> verifying ->
> > manageable. For manageble to be initial state, does it mean that
> > A. whatever is needed for enroll and verifying is done and succeeds (under
> > the hood)
> > or
> > B. whatever is needed for enroll is done and succeeds (but no verifying)
> > or
> > C. no enroll or verifying is done, it goes straight to manageble
> >
> > I'm fine with A.I'm not sure that B makes sense and I definitely don't think
> > C makes sense. To date, verifying means checking that the conductor can get
> > the power state on the node, to verify the supplied power credentials. I
> > don't think it is a big deal if we skip this step; it just means that the
> > next time some action is taken on the node, it might fail.
> >
> > available
> > 
> > In our state machinery, a node goes from enroll -> verifying -> manageable
> > -> cleaning -> available. For available to be initial state, does it mean
> > that
> > A. whatever is needed for enroll, verifying, cleaning is done and succeeds
> > (under the hood)
> > or
> > B. whatever is needed for enroll is done and succeeds (but no verifying or
> > cleaning)
> > or
> > ??
> >
> > active
> > 
> > In our state machinery, a node goes from enroll -> verifying -> manageable
> > -> cleaning -> available->deploying->active. For active to be initial state,
> > does it mean that
> > A. whatever is needed for enroll, verifying, cleaning, deploying is done and
> > succeeds (under the hood)
> > or
> > B. whatever is needed for enroll is done and succeeds (but no verifying or
> > cleaning)
> > or
> > C. whatever is needed for enroll and I dunno, any 'takeover' stuff by
> > conductor or whatever node states need to be updated to be in active?
> >
> 
> What I'm more concerned about allowing the enroll a node in any stable
> state is that it's going to be a big change in our API. We have PATCH
> as a mechanism of updating a resource partially because we have
> read-only attributes (driver_internal_info, *_updated_at, etc...) in
> the API that are internal and should not be updated by the user. Some
> states might depend on them i.e a node in ACTIVE state might have
> indicators in the driver_internal_info field.
> 
> Another thing it's really cross resource, a node in ACTIVE state will
> depend on a certain port which it was used to be deployed (and other
> things about registering that port in Neutron with the right DHCP
> information, so if one is PXE booting after ACTIVE the node won't get
> stuck with a boot error. (Also we need to create the right TFTP (or
> TFTP + HTTP for iPXE) environment for that node.
> 
> Anyway, I don't want to get much deeper, I think we should all be open
> to hear what will be proposed with a fresh mind.
> 

+1, there are tons of dragons here. Now that we're to the point where
our state machine is well-defined with a single entrypoint, I think
adding any entrypoints needs to be well thought out. We should be able
to make assumptions about what we can do from a given state, and if we
are going to allow folks to define other entrypoints, those assumptions
need to be satisfied.

I'm somewhat open to adding entrypoints, but I'd like to see specs
first.

// jim

> 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-dev] [congress][requirements] Requirements proposal job fails

[Andreas Jaeger]

The requirements proposal job fails syncing to congress with this error:
"'PuLP' is not in global-requirements.txt"

congress team, please resolve this. Options include getting this into 
global-requirements or removing it from your project.


Details:

https://jenkins.openstack.org/job/propose-requirements-updates/

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[melanie witt]

On Aug 20, 2015, at 5:40, Alex Xu  wrote:

> So user may wrote client like this:
> 
> if response.status == 500 and ‘OverQuota’ in response.message:
> …..

I thought we're not supporting that type of case. My understanding is that we 
should never be returning 500 and if we are, it's a bug fix to change it to an 
appropriate error status code without version bumps. I find it in the 
documentation [1][2] too.

-melanie (irc: melwitt)


[1] 
http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion
[2] 
http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [app-catalog] App Catalog IRC meeting minutes - 8/20/2015

[Christopher Aedo]

We had a quick meeting today and covered the excellent progress Kevin
Fox is making on a Horizon plugin for the App Catalog, as well as a
brief update on whether the codebase for ask.o.o would be worth
considering as a backend for the catalog.

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!


=
#openstack-meeting-3: app-catalog
=

Meeting started by docaedo at 17:00:33 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-08-20-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:45)
  * LINK: http://localconspiracy.com/2015/08/regarding-irc.html
(docaedo, 17:02:52)

* Horizon plugin status update (kfox)  (docaedo, 17:03:20)

* ask.openstack codebase for backend (docaedo)  (docaedo, 17:08:26)
  * LINK: https://github.com/ASKBOT/askbot-devel  (docaedo, 17:09:02)
  * LINK:
http://lists.openstack.org/pipermail/community/2015-August/001257.html
(docaedo, 17:10:20)

* Open discussion  (docaedo, 17:25:35)

Meeting ended at 17:29:46 UTC.

People present (lines said)
---
* docaedo (46)
* kfox (21)
* kzaitsev_mb (6)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
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] [Fuel] Changes to the blueprint specification template

[Roman Prykhodchenko]

Folks,

as you may remember, we were about to merge some changes to the blueprint spec 
template to make our specifications in Fuel more specific regarding different 
components and subsystems.
That time we decided to move the changes to 8.0, so new specs in 8.0 will have 
to follow the new template. I restored the patch with the changes and now it’s 
ready for reviews https://review.openstack.org/#/c/193070/ 



- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Targeting "Logging API for SG and FW rules" feature to L-3 milestone

[Sean M. Collins]

On Thu, Aug 20, 2015 at 06:55:12AM EDT, hoan...@vn.fujitsu.com wrote:
> Hi Kye Mestery [PTL],
> CC: Sean M. Collins [FWaaS chair],
> CC: All,
> 
> According to the last FWaaS IRC weekly meeting, the "Logging API for SG and 
> FW rules" feature will be reviewed and handled by FWaaS core team.
> #link 
> http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-12-18.30.html

I said specifically:

"so I think we'll need more time to do the review of that spec, probably by 
next week we'll be able to discuss"

Since I have not had a chance to review, and it does not appear that
there has been much review by others.


> 
> The specification and source codes will definitely reviewing/filing in next 
> week.
> #link 
> http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-19-23.59.log.html

No - I did not say "definitely" - nowhere in that IRC log was that word
used.

-- 
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] [nova][qa] libvirt + LXC CI - where's the beef?

[Matt Riedemann]

On 8/20/2015 5:33 AM, John Garbutt wrote:

On 20 August 2015 at 03:08, Matt Riedemann  wrote:

After spending a few hours on https://bugs.launchpad.net/nova/+bug/1370590
I'm annoyed by the fact we don't yet have a CI system for testing libvirt +
LXC.


Bit thank you for raising this one.


At the Juno midcycle in Portland I thought I remember some guy(s) from
Rackspace talking about getting a CI job running, whatever happened with
that?


Now you mention it, I remember that.
I haven't heard any news about that, let me poke some people.


It seems like we should be able to get this going using community infra,
right?  Just need some warm bodies to get the parts together and figure out
which Tempest tests can't be run with that setup - but we have the
hypervisor support matrix to help us out as a starter.


+1


It also seems unfair to require third party CI for libvirt + parallels
(virtuozzo) but we don't have the same requirement for LXC.


The original excuse was that it didn't bring much value, as most of
the LXC differences were in libvirt.
But given the recent bugs that have cropped up, that is totally the wrong call.

I think we need to add a log message saying:
"LXC support is untested, and will be removed during Mitka if we do
not get a CI in place".

Following the rules here:
https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan#Specific_Requirements

Does that make sense?


There should at least be a quality warning that it's untested.  I can 
push that up today.




John

PS
I must to kick off the "feature classification" push, so we can get
discuss that for real at the summit.

Really I am looking for folks to help with that, help monitor what
bits of the support matrix are actually tested.

__
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



--

Thanks,

Matt Riedemann


__
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] Kuryr - virtual sprint

[Irena Berezovsky]

Second or last week of September work for me

On Thu, Aug 20, 2015 at 3:22 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Wed, Aug 19, 2015 at 11:50 PM, Salvatore Orlando <
> salv.orla...@gmail.com> wrote:
>
>> Hi Gal,
>>
>> even if I've been a lurker so far, I'm interested in attending for
>> learning and contributing to it with my massive bug-injecting skills!
>>
>> You said "virtual sprint" and "somewhere in september" - I think
>> "somewhere" refers to dates?
>> Anyway I am pretty much open to any date from September 7th onwards.
>>
>> Salvatore
>>
>>
>> On 19 August 2015 at 19:57, Gal Sagie  wrote:
>>
>>> Hello everyone,
>>>
>>> During our last meeting an idea was brought up that we try to do a
>>> virtual sprint
>>> for Kuryr somewhere in September.
>>>
>>> Basically the plan is very similar to the mid cycle sprints or feature
>>> sprints where
>>> we iterate on couple of tasks online and finish gaps we might have in
>>> Kuryr.
>>> (I think we are talking about 2-3 days)
>>>
>>
> Great Idea. I propose September 14th, 15th and 16th.
>
>
>>
>>> The agenda for the sprint is dependent on the amount of work we finish
>>> by then,
>>> but it will probably consist of containerising some of the common
>>> plugins and connecting
>>> things end to end. (for host networking)
>>>
>>> I started this email in order to find the best dates for it, so if you
>>> plan on participating
>>> please share your preferred dates (anyone that has a Neutron plugin
>>> might want to offer a containerised version of it with Kuryr to integrate
>>> with Docker and lib network and the sprint
>>> is probably a good place to start doing it)
>>>
>>> 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
>>>
>>>
>>
>> __
>> 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

[openstack-dev] [Keystone][Glance] keystonemiddleware & multiple keystone endpoints

[Hans Feldt]

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

Thanks,
Hans

__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[Alex Xu]

Let me wrote down what I’m analyse about this(I’m not good at this…and this 
spend another hour for me...):

When OverQuota isn’t catched by API layer, we will get response as below:

{"computeFault": {"message": "Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/  and attach 
the Nova API log if possible.\n", "code": 
500}}

So user may wrote client like this:

if response.status == 500 and ‘OverQuota’ in response.message:
…..

If we fix this to 403 without microversions, then in different openstack 
deployment we will have different return code for OverQuota.

From this doc 
http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n129
 

 , provide a way to avoid
bump microversion. The doc suggest turn it into existed return code. But looks 
like it still drop into the different openstack deployment case.
So can we remove this footnote?

If this analysis is correct, then we need new microverions.

For v2 API, I think we needn't fix it… If v2.1 fix with microverions, this fix 
can’t be back-port also, 500 bug is always part of old API contract.
If we want to make nova API consistent now, v2 API can follow this rule also, 
500 is already part of contract of it.

Thanks,
Alex

> 在 2015年8月20日，上午3:37，Matt Riedemann  写道：
> 
> 
> 
> On 8/19/2015 2:16 PM, Matt Riedemann wrote:
>> 
>> 
>> On 8/19/2015 1:33 PM, Matt Riedemann wrote:
>>> 
>>> 
>>> On 8/19/2015 12:18 PM, Chen CH Ji wrote:
 In doing [1] [2], some suggestions raised that those kind of change need
 microversion bump which is fine
 however, another concern raised on whether we need combine a set of
 those kind of changes (which may only change some error code) into one
 bump ?
 
 apparently there are pros and cons for doing so, combine makes API
 version bump not that frequent for minor changes
 but makes it hard to review and backport ... so any suggestions on how
 to handle ? Thanks
 
 
 [1]https://review.openstack.org/#/c/198753/
 [2]https://review.openstack.org/#/c/173985/
 
 Best Regards!
 
 Kevin (Chen) Ji 纪 晨
 
 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 District, Beijing 100193, PRC
 
 
 __
 
 
 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 don't see why https://review.openstack.org/#/c/198753/ would require a
>>> microversion bump.  We've always allowed handling 500s and turning them
>>> into more appropriate error codes, like a 400 in this case.
>>> 
>>> As noted:
>>> 
>>> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>>> 
>>> 
>>> 
>>> "Changing an error response code to be more accurate." is generally
>>> acceptable.
>>> 
>> 
>> https://review.openstack.org/#/c/173985/ doesn't require a version bump
>> for the same reasons, IMO.  If people are hung up on 400 vs 403 in that
>> change, just make it a 400, we do it both ways in the compute API.
>> 
> 
> I guess the problems are in the doc:
> 
> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
>  
> 
> 
>  - the list of status codes allowed for a particular request
> 
>Example: an API previously could return 200, 400, 403, 404 and the
>change would make the API now also be allowed to return 409.
> 
>  - changing a status code on a particular response
> 
>Example: changing the return code of an API from 501 to 400.
> 
> So in the one change, just return 400.  In the service_get change where you 
> want to return a 400 but it's only returning a 404 today, then I guess 
> according to the doc you'd need a microversion bump. But what do we do about 
> fixing that bug in the v2 API?  Do we not fix it?  Do we return 404 but v2.1 
> would return 400 with a microversion bump?  That's equally inconsistent and 
> gross IMO.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> 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] [Manila] Contract of ShareDriver.deny_access

[Bjorn Schuberg]

Hello everyone,

this is my first thread on this mailing list, and I would like to take the
opportunity to say that it was great to see you all at the midcycle, even
if remote.

Now, to my question; I've been looking into an issue that arise when
deleting access to a share, and then momentarily after, deleting the same
share. The delete fails due to a race in `_remove_share_access_rules` in
the `ShareManager`, which attempts to delete all granted permissions on the
share before removing it, but one of the access permissions is concurrently
deleted due to the first API call, see;
https://github.com/openstack/manila/blob/master/manila/share/manager.py#L600

I think an acceptable fix to this would be to wrap the `_deny_access` call
with a `try`... `except` block, and log any attempts to remove non-existing
permissions. The problem is that there seems to be no contract on the
exception to throw in case you attempt to delete an `access` which does not
exist -- each driver behaves differently.

This got my attention after running the tempest integration tests, where
the teardown *sometimes* fails in
tempest.api.share.test_rules:ShareIpRulesForNFSTest.

Any thoughts on this? Perhaps there is a smoother approach that I'm not
seeing.


Cheers,
Björn
__
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] "binding information" for networks

[Antoni Segura Puimedon]

On Wed, Aug 19, 2015 at 10:24 PM, Assaf Muller  wrote:

>
>
> On Wed, Aug 19, 2015 at 2:34 PM, Gal Sagie  wrote:
>
>> Hello all,
>>
>> Recently i have came across two use cases that having "binding"
>> information, or metadata
>> for networks can be useful. (similar to the port binding profile for that
>> matter)
>>
>> For example:
>>
>> 1) In project Kuryr we want to have a binding information which maps the
>> Neutron network
>> to docker network (And we might want to do it prior to the docker
>> network being created,
>> that is assign a network that is ready to be attached) so this field
>> also needs to be editable
>> (just like the port binding profile)
>>
>> 2) For multi site OpenStack (multi cloud) use cases we might want to
>> share information which
>> binds logically same network that is created at each OpenStack cloud
>> site (and hence the ID's
>> are different).
>> (Something like this could be useful for project Tricircle for
>> example)
>>
>> 3) Use cases for multi controllers environments? (each controller manage
>> different networks?)
>>
>> I believe adding such optional field to the network API is really low
>> risk due to its being optional
>> and i believe other use cases can be found to leverage it.
>>
>
> I wonder if we should just add a key/pair tuples "tags" or "metadata"
> generic field instead. There's
> been similar requests floating about that could also use a place to dump
> their data in.
>

I think something similar was proposed as part of QoS but it was decided
against. I personally think
that having metadata for the entities (networks and ports) makes a lot of
sense.


>
>
>>
>> Feel free to share ideas/comments.
>>
>> If there are no strong objections to it, i will add an RFE/Spec to add
>> this ability.
>>
>> 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
>>
>>
>
> __
> 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] [Neutron] Kuryr - virtual sprint

[Antoni Segura Puimedon]

On Wed, Aug 19, 2015 at 11:50 PM, Salvatore Orlando 
wrote:

> Hi Gal,
>
> even if I've been a lurker so far, I'm interested in attending for
> learning and contributing to it with my massive bug-injecting skills!
>
> You said "virtual sprint" and "somewhere in september" - I think
> "somewhere" refers to dates?
> Anyway I am pretty much open to any date from September 7th onwards.
>
> Salvatore
>
>
> On 19 August 2015 at 19:57, Gal Sagie  wrote:
>
>> Hello everyone,
>>
>> During our last meeting an idea was brought up that we try to do a
>> virtual sprint
>> for Kuryr somewhere in September.
>>
>> Basically the plan is very similar to the mid cycle sprints or feature
>> sprints where
>> we iterate on couple of tasks online and finish gaps we might have in
>> Kuryr.
>> (I think we are talking about 2-3 days)
>>
>
Great Idea. I propose September 14th, 15th and 16th.


>
>> The agenda for the sprint is dependent on the amount of work we finish by
>> then,
>> but it will probably consist of containerising some of the common plugins
>> and connecting
>> things end to end. (for host networking)
>>
>> I started this email in order to find the best dates for it, so if you
>> plan on participating
>> please share your preferred dates (anyone that has a Neutron plugin might
>> want to offer a containerised version of it with Kuryr to integrate with
>> Docker and lib network and the sprint
>> is probably a good place to start doing it)
>>
>> 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
>>
>>
>
> __
> 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] Great updates to tests and CI jobs

[Sebastian Kalinowski]

If there will be 4-5 patches, then I do not have anything against it. I'm
just skeptic that we will have so many ;)

2015-08-20 14:05 GMT+02:00 Roman Prykhodchenko :

> I think, that if there are 4-5 patches that pass python jobs w/o any
> problems, we can switch the jobs to voting. They are really simple with a
> very little room for a failure so should we wait longer?
>
>
> 19 серп. 2015 о 19:50 Sebastian Kalinowski 
> написав(ла):
>
> Indeed, great news!
>
> I would only suggest to wait a little bit more that a few days with
> switching
> to the voting mode since it looks like there will be not so many patches
> proposed to python-fuelclient as we are heading towards Hard Code Freeze.
>
> I hope that the next step will be to enable Python 3 pipepline for our
> client so
> we could finally test all the code that uses "six" library for Python 2 &
> 3 compatibility.
>
> Best,
> Sebastian
>
> 2015-08-19 19:00 GMT+02:00 Boris Pavlovic :
>
>> Roman,
>>
>> well done! ;)
>>
>> Best regards,
>> Boris Pavlovic
>>
>> On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko 
>> wrote:
>>
>>> Hi folks!
>>>
>>> Today I’m proud to announce that since this moment python-fuelclient has
>>> it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me
>>> making Fuel Client compatible with the upstream CI.
>>> Besides sharing great news I think it’s necessary to share changes we
>>> had to do, in order to accomplish this result.
>>>
>>> First of all tests were reorganized: now functional and unit tests have
>>> their own separate folders inside the fuelclient/tests directory. That
>>> allowed us to distinguish them from both the CI and a developer’s point of
>>> view, so there will be no mess we used to have.
>>>
>>> The other change we’ve made is deleting run_tests.sh*. It is possible to
>>> run and manage all the tests via tox which is a de-facto standard in
>>> OpenStack ecosystem. That also means anyone who is familiar with any of
>>> OpenStack projects will be able to orchestrate tests without a need to
>>> learn anything. Tox is preconfigured to run py26, py27, pep8, cover,
>>> functional, and cleanup environments. py26 and py27 only run unit tests and
>>> cover also involves calculating coverage. functional fires up Nailgun and
>>> launches functional tests. cleanup stops Nailgun, deletes its DB and any
>>> files left after functional tests and what you will definitely like —
>>> cleans up all *.pyc files. By default tox executes environments in the
>>> following order: py26->py27->pep8->functional->cleanup.
>>>
>>> Minimal tox was updated to 2.1 which guarantees no external environment
>>> variable is passed to tests.
>>>
>>> The jobs on OpenStack CI are set to be non-voting for a few days to give
>>> it a better try. On the next week we will switch them to voting. At the
>>> same time we will remove unit tests from FuelCI to not waste extra time.
>>>
>>>
>>> * Technically it is kept in place to keep compatibility with FuelCI but
>>> it only invokes tox from inside. It will be removed later, when it’s time
>>> to switch off unit tests on FuelCI.
>>>
>>>
>>> - romcheg
>>>
>>>
>>> __
>>> 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
>
>
>
> __
> 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] Great updates to tests and CI jobs

[Roman Prykhodchenko]

I think, that if there are 4-5 patches that pass python jobs w/o any problems, 
we can switch the jobs to voting. They are really simple with a very little 
room for a failure so should we wait longer?


> 19 серп. 2015 о 19:50 Sebastian Kalinowski  
> написав(ла):
> 
> Indeed, great news!
> 
> I would only suggest to wait a little bit more that a few days with switching
> to the voting mode since it looks like there will be not so many patches
> proposed to python-fuelclient as we are heading towards Hard Code Freeze.
> 
> I hope that the next step will be to enable Python 3 pipepline for our client 
> so
> we could finally test all the code that uses "six" library for Python 2 & 3 
> compatibility.
> 
> Best,
> Sebastian
> 
> 2015-08-19 19:00 GMT+02:00 Boris Pavlovic  >:
> Roman,
> 
> well done! ;)
> 
> Best regards,
> Boris Pavlovic
> 
> On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko  > wrote:
> Hi folks!
> 
> Today I’m proud to announce that since this moment python-fuelclient has it’s 
> own python-jobs in OpenStack CI. Thanks to all of you who helped me making 
> Fuel Client compatible with the upstream CI.
> Besides sharing great news I think it’s necessary to share changes we had to 
> do, in order to accomplish this result.
> 
> First of all tests were reorganized: now functional and unit tests have their 
> own separate folders inside the fuelclient/tests directory. That allowed us 
> to distinguish them from both the CI and a developer’s point of view, so 
> there will be no mess we used to have.
> 
> The other change we’ve made is deleting run_tests.sh*. It is possible to run 
> and manage all the tests via tox which is a de-facto standard in OpenStack 
> ecosystem. That also means anyone who is familiar with any of OpenStack 
> projects will be able to orchestrate tests without a need to learn anything. 
> Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
> environments. py26 and py27 only run unit tests and cover also involves 
> calculating coverage. functional fires up Nailgun and launches functional 
> tests. cleanup stops Nailgun, deletes its DB and any files left after 
> functional tests and what you will definitely like — cleans up all *.pyc 
> files. By default tox executes environments in the following order: 
> py26->py27->pep8->functional->cleanup.
> 
> Minimal tox was updated to 2.1 which guarantees no external environment 
> variable is passed to tests.
> 
> The jobs on OpenStack CI are set to be non-voting for a few days to give it a 
> better try. On the next week we will switch them to voting. At the same time 
> we will remove unit tests from FuelCI to not waste extra time.
> 
> 
> * Technically it is kept in place to keep compatibility with FuelCI but it 
> only invokes tox from inside. It will be removed later, when it’s time to 
> switch off unit tests on FuelCI.
> 
> 
> - romcheg
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Great updates to tests and CI jobs

[Roman Prykhodchenko]

Mike,

there were indeed several issues with the new Jenkins script. It seems we fixed 
them.


- Roman
> 20 серп. 2015 о 02:00 Mike Scherbakov  написав(ла):
> 
> Sounds great. Thank you Roman!
> I've heard complains about tests not passing for [1]. Now it's passed, so I 
> hope that issues are resolved.
> 
> [1] https://review.openstack.org/#/c/212906/ 
> 
> On Wed, Aug 19, 2015 at 10:51 AM Sebastian Kalinowski 
> mailto:skalinow...@mirantis.com>> wrote:
> Indeed, great news!
> 
> I would only suggest to wait a little bit more that a few days with switching
> to the voting mode since it looks like there will be not so many patches
> proposed to python-fuelclient as we are heading towards Hard Code Freeze.
> 
> I hope that the next step will be to enable Python 3 pipepline for our client 
> so
> we could finally test all the code that uses "six" library for Python 2 & 3 
> compatibility.
> 
> Best,
> Sebastian
> 
> 2015-08-19 19:00 GMT+02:00 Boris Pavlovic  >:
> Roman,
> 
> well done! ;)
> 
> Best regards,
> Boris Pavlovic
> 
> On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko  > wrote:
> Hi folks!
> 
> Today I’m proud to announce that since this moment python-fuelclient has it’s 
> own python-jobs in OpenStack CI. Thanks to all of you who helped me making 
> Fuel Client compatible with the upstream CI.
> Besides sharing great news I think it’s necessary to share changes we had to 
> do, in order to accomplish this result.
> 
> First of all tests were reorganized: now functional and unit tests have their 
> own separate folders inside the fuelclient/tests directory. That allowed us 
> to distinguish them from both the CI and a developer’s point of view, so 
> there will be no mess we used to have.
> 
> The other change we’ve made is deleting run_tests.sh*. It is possible to run 
> and manage all the tests via tox which is a de-facto standard in OpenStack 
> ecosystem. That also means anyone who is familiar with any of OpenStack 
> projects will be able to orchestrate tests without a need to learn anything. 
> Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup 
> environments. py26 and py27 only run unit tests and cover also involves 
> calculating coverage. functional fires up Nailgun and launches functional 
> tests. cleanup stops Nailgun, deletes its DB and any files left after 
> functional tests and what you will definitely like — cleans up all *.pyc 
> files. By default tox executes environments in the following order: 
> py26->py27->pep8->functional->cleanup.
> 
> Minimal tox was updated to 2.1 which guarantees no external environment 
> variable is passed to tests.
> 
> The jobs on OpenStack CI are set to be non-voting for a few days to give it a 
> better try. On the next week we will switch them to voting. At the same time 
> we will remove unit tests from FuelCI to not waste extra time.
> 
> 
> * Technically it is kept in place to keep compatibility with FuelCI but it 
> only invokes tox from inside. It will be removed later, when it’s time to 
> switch off unit tests on FuelCI.
> 
> 
> - romcheg
> 
> __
> 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 
> 
> --
> Mike Scherbakov
> #mihgen
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List 

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

[Mehdi Abaakouk]

Hi,


Also to support some of the newer services that don't use paste i
think we should absolutely make it so that the CONF object is passed
to middleware rather than sourced globally. I think gnochhi and zaqar
both fit into this case.


For example, Gnocchi doesn't use paste, deployer adds middlewares like 
this:


   [api]
   middlewares = 
oslo_middleware.request_id.RequestId,oslo_middleware.cors.CORS,keystonemiddleware.auth_token.AuthProtocol


Of course because of the current issue, we browse the pipeline to pass 
the correct options to
keystonemiddleware.auth_token.AuthProtocol, to make it works. My change 
allows to remove this workaround.



The problem i see with what you are saying is that it is mixing
deployment methodologies in a way that is unintended. Paste is
designed to allow deployers to add and remove middleware independent
of configuring the service. This means that at paste time there is no
CONF object unless it's globally registered and this is why most
middlewares allow taking options from paste.ini because if you don't
have global CONF then it's the only way to actually get options into
the middleware.


My change adds a new way that doesn't use global CONF object but still 
read options

from the application configuration file.


Fixing this problem is always where i loose enthusiasm for removing
global CONF files.


With my solution, if all applications update they paste.ini 
configuration, we
can remove the global CONF from keystonemiddleware and only relies on 
options loaded

via paste or via the local oslo.cfg object.
keystonemiddleware become like most middlewares and does not depend 
anymore on the application.


(If you want that I can write a patch to deprecate usage of global CONF 
object

once my change is merged, and update paste.ini of other projects)


From a developer perspective I feel the solution is for us to
reconsider how we deploy and configure middleware. If you are using
paste those pieces of middleware should each be able to be configured
without any integration with the service underneath it. Otherwise if
your service needs a piece of middleware like auth_token middleware to
operate or relies on oslo.config options like cors then that is not
something that should be controlled by paste.

From a deployer perspective there is no great answer i just want
everything to be in oslo.config.


Yeah, that's the goal, whatever the app uses global or not, uses paste 
or not, etc...

for the deployer, the configuration of middlewares are in oslo.config.


Equally from a deployer perspective this wasn't an issue until aodh
(et al) decided to remove the global CONF object which developers from
all the projects hate but live with. I don't mean to imply we
shouldn't look at better ways to do things, but if you're main concern
is deployers the easiest thing we can do for consistency is add back
the global CONF object or remove paste from aodh. :)


I will be sad to readd the global CONF object (removing paste is not 
really an option for us I think).


Cheers,

---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
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] Targeting "Logging API for SG and FW rules" feature to L-3 milestone

[Gal Sagie]

I think that before this can be applied to SG rules which are on the VM
ports,
there needs to be another spec in FWaaS which enable defining rules on VM
ports, i am not
sure something like that currently exists. (event that there are many use
cases for such ability)

Gal.

On Thu, Aug 20, 2015 at 1:55 PM, hoan...@vn.fujitsu.com <
hoan...@vn.fujitsu.com> wrote:

> Hi Kye Mestery [PTL],
> CC: Sean M. Collins [FWaaS chair],
> CC: All,
>
> According to the last FWaaS IRC weekly meeting, the "Logging API for SG
> and FW rules" feature will be reviewed and handled by FWaaS core team.
> #link
> http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-12-18.30.html
>
> The specification and source codes will definitely reviewing/filing in
> next week.
> #link
> http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-19-23.59.log.html
>
> a. RFE #link https://review.openstack.org/#/c/203509/
>
> b. Specification: #link https://review.openstack.org/#/c/203509/
>
> c. Source codes: #link https://review.openstack.org/#/c/204481/
>   #link
> https://review.openstack.org/#/c/204484/
>
> So could you please consider the spec for L-3 approval possibility?
> Currently, The RFE bug is still "Confirmed" status and would love to
> moving on :)
>
> P/s: I have tried to ping you in #openstack-neutron channel but you seem
> so busy to be on it.
> So I decided to send email through ML.
>
> --
> Best regards,
> Cao Xuan Hoang
>
> __
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

[Mehdi Abaakouk]

It looks like the additional features added, in particular the
'oslo_config_project' property, needs to be documented.


I have added some documentation into the keystonemiddleware too: 
https://review.openstack.org/#/c/208965/


---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
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][ThirdPartyCI]CloudFounders OpenvStorage CI - request to re-add the cinder driver

[Eduard Matei]

Hi,

Trying to get more attention to this ...

Also,

The CI will (starting next week) be commenting using the name "Open
vStorage CI" instead of "CloudFounders OpenvStorage CI".

Thanks,

Eduard

On Mon, Aug 17, 2015 at 5:44 PM, Eduard Matei <
eduard.ma...@cloudfounders.com> wrote:

> Hi,
>
> We had our driver removed by commit:
> https://github.com/openstack/cinder/commit/f0ab819732d77a8a6dd1a91422ac183ac4894419
>  due to no CI.
>
> Last week we got it working again and it's been commenting for the last 3
> days continuously.
>
> A normal run looks like this:
>
> *08:40:37* Ran: 1265 tests in 2338. sec.*08:40:37*  - Passed: 
> 1156*08:40:37*  - Skipped: 109*08:40:37*  - Expected Fail: 0*08:40:37*  - 
> Unexpected Success: 0*08:40:37*  - Failed: 0*08:40:37* Sum of execute time 
> for each test: 3300.1602 sec.
>
> for this review:
>
> https://review.openstack.org/#/c/212144/
>
> and logs:
>
> http://packages.cloudfounders.com/ci_logs/44/212144/3/check/dsvm-tempest-full/f1c6f6a/
>
>
>
>
> Pls let me know if there is something wrong so we can fix it asap so we can 
> have the driver back in Liberty (if possible).
>
>
> Thanks,
>
>
> --
>
> *Eduard Biceri Matei, Senior Software Developer*
> www.cloudfounders.com
>  | eduard.ma...@cloudfounders.com
>
>


-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com



*CloudFounders, The Private Cloud Software Company*

Disclaimer:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
If you are not the named addressee or an employee or agent responsible
for delivering this message to the named addressee, you are hereby
notified that you are not authorized to read, print, retain, copy or
disseminate this message or any part of it. If you have received this
email in error we request you to notify us by reply e-mail and to
delete all electronic files of the message. If you are not the
intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the content of this
message, and shall have no liability for any loss or damage suffered
by the user, which arise as a result of e-mail transmission.
__
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] VPNaaS and DVR compatibility

[Sergey Kolekonov]

Thanks for the link, Sean.

No, it doesn't seem to resolve the issue with FWaaS.
BTW, I have the following cluster:
- OpenStack Kilo (including *aaS) from the latest stable/kilo branches
- 2 networks nodes
- 1 compute node
Ubuntu 14.04, ML2+OVS, vxlan segmentation.
All nodes are KVM VMs.

So with the patch you provided I observe firewall rules both in
SNAT/qrouter namespaces on network nodes, but still no rules on the compute
node when instances have floating IPs assigned.
So traffic just goes without any restrictions.

On Mon, Aug 17, 2015 at 9:15 PM, Sean M. Collins  wrote:

> On Mon, Aug 17, 2015 at 10:42:18AM EDT, Sergey Kolekonov wrote:
> > BTW, the similar situation is with FWaaS [1]
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1485509
>
> Can you take a look at the following patch?
>
> https://review.openstack.org/203493
>
> If it resolves the issue I may need to re-think my -1, and we may need
> to restore 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
>



-- 
Regards,
Sergey Kolekonov
__
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] [third-party-ci]Tests randomly failing because of lvm

[Eduard Matei]

Hi,

In case someone is still interested, 32768 is the fix. The number of PEs
must be multiple of 1024 (not sure why).

Eduard
__
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-deb] Devstack stable/juno fails to install

[Eduard Matei]

Hi,

ATM our workaround is to manually pip install futures==2.2.0 before running
stack.sh

Any idea when an "official" fix will be available?

Thanks,
Eduard
__
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] Targeting "Logging API for SG and FW rules" feature to L-3 milestone

[hoan...@vn.fujitsu.com]

Hi Kye Mestery [PTL],
CC: Sean M. Collins [FWaaS chair],
CC: All,

According to the last FWaaS IRC weekly meeting, the "Logging API for SG and FW 
rules" feature will be reviewed and handled by FWaaS core team.
#link 
http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-12-18.30.html

The specification and source codes will definitely reviewing/filing in next 
week.
#link 
http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-08-19-23.59.log.html

a. RFE #link https://review.openstack.org/#/c/203509/

b. Specification: #link https://review.openstack.org/#/c/203509/

c. Source codes: #link https://review.openstack.org/#/c/204481/
  #link https://review.openstack.org/#/c/204484/

So could you please consider the spec for L-3 approval possibility?
Currently, The RFE bug is still "Confirmed" status and would love to moving on 
:)

P/s: I have tried to ping you in #openstack-neutron channel but you seem so 
busy to be on it.
So I decided to send email through ML.

--
Best regards,
Cao Xuan Hoang

__
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] [glance] [nova] Image Prefetching – Precaching

[John Garbutt]

On 19 August 2015 at 19:30, Alberto Geniola  wrote:
>
> Hi everyone,
>
>
> This is my first email to the OS developer forum, so forgive me if I 
> misplaced the subject tags J.

Welcome!

For future posts, I hope this helps make it easier:
https://wiki.openstack.org/wiki/MailingListEtiquette


> Straight to the point: for a project we’re involved in, we think that a 
> pre-fetcher mechanism would be great for a variety of use cases. There was an 
> attempt with this blueprint:
>
> https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2
>
> and a more recent one:
>
> https://blueprints.launchpad.net/python-novaclient/+spec/prefetch-image
>
> although both seems to be dead now.
>
> So I really want to get a feedback from the developer’s community whether (1) 
> such a feature makes sense in general, and (2) it may be worth the 
> integration of such a component in the OpenStack code. In fact, although we 
> can solve our problem by developing an in-house component, it would be better 
> to have it integrated in OpenStack, including Nova and Horizon, so I need the 
> feedback from the OS Guru guys J.
>
>
> What do you think?

I think it does make some sense.

The disagreement in the past is about agreeing what should live inside
Nova, and what should live outside Nova.

For me, I am OK having an API to trigger an image prefetch on a
particular host (although in many cases doing a build on that host has
the same affect).

I think the rest of that mechanism should probably live outside of
Nova and Glance. So the question is what extra API are required to
create such a tool.

Thanks,
johnthetubaguy

__
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] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[John Garbutt]

On 19 August 2015 at 20:37, Matt Riedemann  wrote:
> On 8/19/2015 2:16 PM, Matt Riedemann wrote:
>> On 8/19/2015 1:33 PM, Matt Riedemann wrote:
>>> On 8/19/2015 12:18 PM, Chen CH Ji wrote:

 In doing [1] [2], some suggestions raised that those kind of change need
 microversion bump which is fine
 however, another concern raised on whether we need combine a set of
 those kind of changes (which may only change some error code) into one
 bump ?

 apparently there are pros and cons for doing so, combine makes API
 version bump not that frequent for minor changes
 but makes it hard to review and backport ... so any suggestions on how
 to handle ? Thanks


 [1]https://review.openstack.org/#/c/198753/
 [2]https://review.openstack.org/#/c/173985/

 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 District, Beijing 100193, PRC



 __


 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 don't see why https://review.openstack.org/#/c/198753/ would require a
>>> microversion bump.  We've always allowed handling 500s and turning them
>>> into more appropriate error codes, like a 400 in this case.
>>>
>>> As noted:
>>>
>>>
>>> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>>>
>>>
>>>
>>> "Changing an error response code to be more accurate." is generally
>>> acceptable.
>>>
>>
>> https://review.openstack.org/#/c/173985/ doesn't require a version bump
>> for the same reasons, IMO.  If people are hung up on 400 vs 403 in that
>> change, just make it a 400, we do it both ways in the compute API.
>>
>
> I guess the problems are in the doc:
>
> http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63
>
>   - the list of status codes allowed for a particular request
>
> Example: an API previously could return 200, 400, 403, 404 and the
> change would make the API now also be allowed to return 409.
>
>   - changing a status code on a particular response
>
> Example: changing the return code of an API from 501 to 400.
>
> So in the one change, just return 400.  In the service_get change where you
> want to return a 400 but it's only returning a 404 today, then I guess
> according to the doc you'd need a microversion bump.  But what do we do
> about fixing that bug in the v2 API?  Do we not fix it?  Do we return 404
> but v2.1 would return 400 with a microversion bump?  That's equally
> inconsistent and gross IMO.

I think the idea is we bump the microversion so the caller knows about
the new error code being possible.

Although I am tempted to say we make the change for all microversions,
to stop the nasty 500 error, which does reduce the value of the
version bump...

In the v2 API, we should probably just change the 500 to a better
return value as well, without and advertising. I think we used to
allow that.

Does that work?

John

__
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] contextlib.nested and Python3 failing

[John Garbutt]

On 20 August 2015 at 01:42, melanie witt  wrote:
> On Aug 19, 2015, at 16:51, Sylvain Bauza  wrote:
>
>> Ideas appreciated.
>
> Instead of using the nested context managers, a way I like is to decorate a 
> nested function in the test and call it, for example:
>
>
> def test_thing(self):
>
> @mock.patch(...)
> @mock.patch(...)
> @mock.patch(...)
> def do_test(..., ..., ...):
> ...
>
> do_test()

+1

I have always found that more readable that the context manager thing,
can't really explain why.

johnthetubaguy

__
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][qa] libvirt + LXC CI - where's the beef?

[John Garbutt]

On 20 August 2015 at 03:08, Matt Riedemann  wrote:
> After spending a few hours on https://bugs.launchpad.net/nova/+bug/1370590
> I'm annoyed by the fact we don't yet have a CI system for testing libvirt +
> LXC.

Bit thank you for raising this one.

> At the Juno midcycle in Portland I thought I remember some guy(s) from
> Rackspace talking about getting a CI job running, whatever happened with
> that?

Now you mention it, I remember that.
I haven't heard any news about that, let me poke some people.

> It seems like we should be able to get this going using community infra,
> right?  Just need some warm bodies to get the parts together and figure out
> which Tempest tests can't be run with that setup - but we have the
> hypervisor support matrix to help us out as a starter.

+1

> It also seems unfair to require third party CI for libvirt + parallels
> (virtuozzo) but we don't have the same requirement for LXC.

The original excuse was that it didn't bring much value, as most of
the LXC differences were in libvirt.
But given the recent bugs that have cropped up, that is totally the wrong call.

I think we need to add a log message saying:
"LXC support is untested, and will be removed during Mitka if we do
not get a CI in place".

Following the rules here:
https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan#Specific_Requirements

Does that make sense?

John

PS
I must to kick off the "feature classification" push, so we can get
discuss that for real at the summit.

Really I am looking for folks to help with that, help monitor what
bits of the support matrix are actually tested.

__
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] [murano] [dashboard] public package visibility in Package Definitions UX concern

[Kirill Zaitsev]

On our latest irc meeting I raised a concern about public package visibility. 
Here’s the commit that caused my concerns 
https://review.openstack.org/#/c/213682/

We currently have «catalog» and «package definitions» pages in our dashboard. 
The former contains packages that the user can add in his environment, and the 
latter contains packages the user can edit. This means, that admin user sees 
all the packages on package definitions page, while simple user can only see 
packages from his tenant.
Lately we’ve added a filter, similar to the one «Images» dashboard has, that 
separates packages into «project» «public» and «other» groups, to ease 
selection, but this unfortunately introduced some negative UX, cause non-admin 
users now see the filter and expect all the public packages to be there.

This can be solved in a couple of ways.
1) Remove the filter for non-admin user, thus removing any concerns about 
public-packages. User can still sort the table by pressing on the public header.
2) Renaming the filter to something like «my public» for non-admin 
3) Allowing user to see public packages from other tenants, but making all the 
edit options grey, although I’m not sure if it’s possible to do so for bulk 
operation checkboxes.
4) Leave everything as is (ostrich algorithm), as we believe, that this is 
expected behaviour

Personally I like #1 as it makes more sense to me and feels more consistent 
than other options.

Ideas/opinions would be appreciated.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc__
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