[openstack-dev] [Fuel] Changes to the blueprint specification template
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/ 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
[openstack-dev] [keystone] federation
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
[openstack-dev] [infra] API docs latest-n-greatest
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/service 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
On 8/13/15, 4:58 PM, Clark Boylan cboy...@sapwetik.org 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 Development Mailing List (not for usage questions)
Unsubscribe:
[openstack-dev] [CI] Cannot get compute endpoint when running nodepool.
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/%25%28tenant_id%29s |
http://controller:8774/v2/%(tenant_id)s
http://controller:8774/v2/%25%28tenant_id%29s |
http://controller:8774/v2/%(tenant_id)s
http://controller:8774/v2/%25%28tenant_id%29s |
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] [Horizon] Update on Angular Identity work
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 the.doug.f...@gmail.com 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 tqt...@us.ibm.com 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
---
div ng-controller=table.controller.js as ctrl
horizon-table
headers=ctrl.headers
batch-actions=ctrl.batchActionList
row-actions=ctrl.rowActionList
/horizon-table
/div
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
table ng-controller=table.controller.js as ctrl
thead
tr
action-list
action callback=someFunc translateCreate/action
action callback=someFunc translateDelete/action
/action-list
/tr
tr
th translateColumn 1/th
th translateColumn 2/th
/tr
/thead
tbody
tr ng-repeat=items in ctrl.items
td/td
tdaction-list
action callback=someFunc translateEdit/action
action callback=someFunc translateDelete/action
/action-list/td
/tr
/tbody
/table
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 action-list, action, magic-search,
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
Re: [openstack-dev] [Magnum] Consistent functional test failures (seems infra not have enough resource)
On 8/13/15, 6:13 AM, Jeremy Stanley fu...@yuggoth.org 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] [infra] API docs latest-n-greatest
在 2015年8月21日，上午9:48，Anne Gentle annegen...@justwriteclick.com 写道： 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/ http://developer.openstack.org/api-guide/service merged. The plan is completely documented here: http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html 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 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 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 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 http://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 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/ 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 http://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] [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)shttp://controller:8774/v2/%25(tenant_id)s
|
http://controller:8774/v2/%(tenant_id)shttp://controller:8774/v2/%25(tenant_id)s
|
http://controller:8774/v2/%(tenant_id)shttp://controller:8774/v2/%25(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] [swift] [swift3] Are there any objections to add scoped tempest job to swift3 pipeline?
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] [Ironic] Let's talk about API versions
On 18 August 2015 at 17:13, Ruby Loo rlooya...@gmail.com wrote: On 18 August 2015 at 13:08, Lucas Alvares Gomes lucasago...@gmail.com 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] [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] [nova] feedback from the ops mid cycle summit
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?
On Thu, Aug 20, 2015 at 3:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.com 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?
On Thu, Aug 20, 2015 at 9:40 PM, Alex Xu hejie...@intel.com 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.\nclass 'nova.exception.OverQuota', 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 mrie...@linux.vnet.ibm.com 写道：
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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
在 2015年8月21日，上午3:09，Jay Pipes jaypi...@gmail.com 写道： On 08/20/2015 02:08 PM, melanie witt wrote: On Aug 20, 2015, at 5:40, Alex Xu hejie...@intel.com 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/ 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] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
在 2015年8月21日，上午10:14，Alex Xu hejie...@intel.com 写道： 在 2015年8月21日，上午3:09，Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com 写道： On 08/20/2015 02:08 PM, melanie witt wrote: On Aug 20, 2015, at 5:40, Alex Xu hejie...@intel.com mailto:hejie...@intel.com 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 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 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/ 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 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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.
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
Re: [openstack-dev] [OpenStack-docs] [docs][api] pecan-swagger generated api
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] [Magnum] Consistent functional test failures
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 wk...@cn.ibm.commailto:wk...@cn.ibm.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, August 14, 2015 at 3:46 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto: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.commailto: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 cboy...@sapwetik.orgmailto:cboy...@sapwetik.org
To: openstack-dev@lists.openstack.orgmailto: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] [Neutron] Kuryr - virtual sprint
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 gal.sa...@gmail.com 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] [glance] [nova] Image Prefetching – Precaching
On 19 August 2015 at 19:30, Alberto Geniola albertogeni...@gmail.com 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
[openstack-dev] [Neutron] Targeting Logging API for SG and FW rules feature to L-3 milestone
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] [Neutron] Targeting Logging API for SG and FW rules feature to L-3 milestone
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] [Fuel] Great updates to tests and CI jobs
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 skalinow...@mirantis.com написав(ла): 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 bpavlo...@mirantis.com mailto:bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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
Mike, there were indeed several issues with the new Jenkins script. It seems we fixed them. - Roman 20 серп. 2015 о 02:00 Mike Scherbakov mscherba...@mirantis.com написав(ла): 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/ https://review.openstack.org/#/c/212906/ On Wed, Aug 19, 2015 at 10:51 AM Sebastian Kalinowski skalinow...@mirantis.com 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 bpavlo...@mirantis.com mailto:bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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 (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs
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 m...@romcheg.me: 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 skalinow...@mirantis.com написав(ла): 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 bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me 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://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://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] [Neutron] binding information for networks
On Wed, Aug 19, 2015 at 10:24 PM, Assaf Muller amul...@redhat.com wrote: On Wed, Aug 19, 2015 at 2:34 PM, Gal Sagie gal.sa...@gmail.com 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] [cinder][ThirdPartyCI]CloudFounders OpenvStorage CI - request to re-add the cinder driver
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
[openstack-dev] [murano] [dashboard] public package visibility in Package Definitions UX concern
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
Re: [openstack-dev] [nova] contextlib.nested and Python3 failing
On 20 August 2015 at 01:42, melanie witt melwi...@gmail.com wrote: On Aug 19, 2015, at 16:51, Sylvain Bauza sba...@redhat.com 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] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 19 August 2015 at 20:37, Matt Riedemann mrie...@linux.vnet.ibm.com 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] [third-party-ci]Tests randomly failing because of lvm
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] [nova][qa] libvirt + LXC CI - where's the beef?
On 20 August 2015 at 03:08, Matt Riedemann mrie...@linux.vnet.ibm.com 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
Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install
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
Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility
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 s...@coreitpro.com 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] [oslo][keystone] oslo_config and wsgi middlewares
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] [oslo][keystone] oslo_config and wsgi middlewares
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] [openstack-deb] Devstack stable/juno fails to install
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] [Horizon] Update on Angular Identity work
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 tqt...@us.ibm.com 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
---
div ng-controller=table.controller.js as ctrl
horizon-table
headers=ctrl.headers
batch-actions=ctrl.batchActionList
row-actions=ctrl.rowActionList
/horizon-table
/div
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
table ng-controller=table.controller.js as ctrl
thead
tr
action-list
action callback=someFunc translateCreate/action
action callback=someFunc translateDelete/action
/action-list
/tr
tr
th translateColumn 1/th
th translateColumn 2/th
/tr
/thead
tbody
tr ng-repeat=items in ctrl.items
td/td
tdaction-list
action callback=someFunc translateEdit/action
action callback=someFunc translateDelete/action
/action-list/td
/tr
/tbody
/table
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 action-list, action, magic-search, 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 os.lch...@gmail.com wrote: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Lin Hua Cheng os.lch...@gmail.com
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
Re: [openstack-dev] [TripleO] Moving instack upstream
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,
[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 8/20/2015
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
Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state
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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Horizon] Update on Angular Identity work
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---divng-controller="table.controller.js as ctrl" horizon-table headers="ctrl.headers" batch-actions="ctrl.batchActionList" row-actions="ctrl.rowActionList" /horizon-table/divSo 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.htmltable ng-controller="table.controller.js as ctrl"thead tr action-list action callback="someFunc" translateCreate/action action callback="someFunc" translateDelete/action /action-list /tr tr th translateColumn 1/th th translateColumn 2/th /tr/theadtbody tr ng-repeat="items in ctrl.items" td/td tdaction-list action callback="someFunc" translateEdit/action action callback="someFunc" translateDelete/action /action-list/td /tr/tbody/tableHere, 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 action-list, action, magic-search, 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 os.lch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Lin Hua Cheng os.lch...@gmail.comDate: 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 tqt...@us.ibm.com 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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On Aug 20, 2015, at 5:40, Alex Xu hejie...@intel.com 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] [congress][requirements] Requirements proposal job fails
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] [ironic] Re: New API for node create, specifying initial provision state
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
[openstack-dev] [Manila] Contract of ShareDriver.deny_access
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
[openstack-dev] [Keystone][Glance] keystonemiddleware multiple keystone endpoints
How do you configure/use keystonemiddleware for a specific identity endpoint among several? In an OPNFV multi region prototype I have keystone endpoints per region. I would like keystonemiddleware (in context of glance-api) to use the local keystone for performing user token validation. Instead keystonemiddleware seems to use the first listed keystone endpoint in the service catalog (which could be wrong/non-optimal in most regions). I found this closed, related bug: https://bugs.launchpad.net/python-keystoneclient/+bug/1147530 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] [Neutron] Kuryr - virtual sprint
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 gal.sa...@gmail.com 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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
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/ http://bugs.launchpad.net/nova/ and attach
the Nova API log if possible.\nclass 'nova.exception.OverQuota', 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
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 mrie...@linux.vnet.ibm.com 写道：
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
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
mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
Re: [openstack-dev] [nova][qa] libvirt + LXC CI - where's the beef?
On 8/20/2015 5:33 AM, John Garbutt wrote: On 20 August 2015 at 03:08, Matt Riedemann mrie...@linux.vnet.ibm.com 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
[openstack-dev] [cinder] EMC VNX Blueprints Exceptions
On Thu, Aug 20, 2015 at 8:27 PM, yang, xing xing.y...@emc.com 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] [cinder] EMC VNX Blueprints Exceptions
Hi Mike, No problem. Thanks, Xing On Aug 21, 2015, at 1:37 AM, Mike Perez thin...@gmail.com wrote: On Thu, Aug 20, 2015 at 8:27 PM, yang, xing xing.y...@emc.com 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
For the rest of the mailing list, how was it resolved? :)
Thanks,
Steve Martinelli
OpenStack Keystone Core
From: Xie, Xianshan xi...@cn.fujitsu.com
To: OpenStack Development Mailing List (not for usage questions)
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-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
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
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 a...@suse.com 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] [congress][requirements] Requirements proposal job fails
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] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 08/20/2015 02:08 PM, melanie witt wrote: On Aug 20, 2015, at 5:40, Alex Xu hejie...@intel.com 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] [congress][requirements] Requirements proposal job fails
Thanks for sorting that out. +1ed the change.
Tim
On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger a...@suse.com 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] [nova][cinder] Extending attached disks
On 19:53 Aug 19, John Griffith wrote: On Wed, Aug 19, 2015 at 7:48 PM, taylor.ber...@solnet.co.nz 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. snip 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] [nova][cinder] Extending attached disks
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 thin...@gmail.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Mike Perez thin...@gmail.com 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, taylor.ber...@solnet.co.nz 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. snip 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] [ironic] Re: New API for node create, specifying initial provision state
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] [packaging] asks from the ops meetup
On 08/20/2015 09:22 AM, Ian Cordasco wrote: On 8/19/15, 19:31, Matthew Thode prometheanf...@gentoo.org 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 prometheanf...@gentoo.org 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
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 t...@styra.com wrote:
Thanks for sorting that out. +1ed the change.
Tim
On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger a...@suse.com 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 rbtcoll...@hp.com
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] [Neutron] Targeting Logging API for SG and FW rules feature to L-3 milestone
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
