date:20131217

2013-12-17 Thread Miller, Mark M (EB SW Cloud - RD - Corvallis)

Hi, Alan!

I'm really glad you have mentioned that problem, that was not really
covered by OpenStack projects for much time. Our (Climate) team is working
on implementing Reservation-as-a-Service. As I understand, you are
interested in reserving (managing) virtual resources on a time-based
criteria. We are going to have 0.1 release asap (we hope to make code
freeze next week).

You are welcome to join our IRC channel and participate in our weekly
meetings.

P.S. btw, we have it today, 10:00 UTC (usually we hold them on Mondays, but
that's emergency case).
P.P.S. would be nice to see you on it :)

Thanks!


On Tue, Dec 17, 2013 at 12:16 PM, Nikolay Starodubtsev 
nstarodubt...@mirantis.com wrote:

 Hi all
 I've looked at the wiki page and now I can say that Cafe have an overlap
 with Climate. Feel free to contact us at #openstack-climate. Also, please
 take a look at our patches on review.openstack.org:
 https://review.openstack.org/#/q/status:open+project:stackforge/climate,n,z



 Nikolay Starodubtsev

 Software Engineer

 Mirantis Inc.


 Skype: dark_harlequine1


 2013/12/17 Tim Bell tim.b...@cern.ch

  There appears to be some overlap of this proposal with ‘climate’ which
 provides a resource reservation system.



 They meet regularly … see
 https://wiki.openstack.org/wiki/Meetings/Climate for contacts.



 Tim



 *From:* Alan Tan [mailto:y...@students.waikato.ac.nz]
 *Sent:* 16 December 2013 23:42

 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] a time-based resource management system



 Hi everyone,



 My name is Alan and I am from the Cyber Security Lab in University of
 Waikato.



 We have recently started deploying and using Openstack in our
 experimental private cloud testbed. The cloud testbed is mainly used in
 running our research and teaching purposes. However, we notice that current
 Openstack lacks the ability to control and manage user’s access to
 resources in a time-based manner.



 I.e. Current model for private clouds requires either the user to release
 their resources (VMs) voluntarily or for the administrators to manually
 remove the resources (VMs).



 This makes capacity management a laborious effort in private clouds that
 have a large user base. Hence, we have come up with the idea of an
 automatic time-based resource management system that manages user access to
 resources in a time slot booking style. We have detailed our plans and
 design in the following wiki page. We would love to hear feedbacks from the
 community and hopefully gather some interest in our project.



 https://wiki.openstack.org/wiki/Cafe



 We look forward to hearing from you. We can be contacted via email. Our
 addresses are listed on the wiki page.



 Thanks and have a good day.



 Cheers,

 Alan



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge

2013-12-17 Thread Radomir Dopieralski

On 17/12/13 09:04, Thomas Goirand wrote:
 On 12/16/2013 10:32 PM, Jaromir Coufal wrote:

[snip]

 So by default, I would say that there should exist Project + Admin tab
 together or Infrastructure. But never all three together. So when
 Matthias say 'disabled by default', I would mean completely hidden for
 user and if user wants to use Infrastructure management, he can enable
 it in different horizon instance, but it will be the only visible tab
 for him. So it will be sort of separate application, but still running
 on top of Horizon.

 I think the disabled by default approach is the wrong one. Instead, we
 should have some users with enough credentials that will have the
 feature, and others will not.

[snip]

The thing is, as Jarda writes, that Tuskar is for managing a different
cloud than the rest of the Horizon. With TripleO you have two clouds,
one, called Undercloud, consists of real hardware and is managed by the
datacenter administrators -- that is the one where Tuskar runs. The
other, called Overcloud, is deployed on the Undercloud machines, and is
the cloud that the users actually use. It's managed by normal Horizon.
Those two instances of Horizon live on separate machines, in separate
networks and have separate sets of users.

I agree that in a general case your proposition would be much better,
but in this case it doesn't really make sense to have the normal
Horizon in Undercloud, and require the admins to specially configure the
users to see Tuskar. Instead, a preconfigured installation of Horizon
with Tuskar enabled seems much better.

-- 
Radomir Dopieralski

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Glance mod_wsgi.input Question

Hello,

I am trying to get the Grizzly Glance service working with Apache2 through the 
WSGI interface. I am having problems with the _upload method of file 
glance/api/v1/images.py It appears that the req.body_file pointer is invalid 
as I get the following error: (9, 'Bad file descriptor').

I have tried adding inline test code attempting to read the image_data object 
but have been unsuccessful. The req.content_length = None. Has anyone come 
across this issue? Below are a few variable values as well as the req.environ:

scheme = file
image size = 8
image data = mod_wsgi.Input object at 0x7f5fb08931f0

-

key=HTTP_X_TENANT_NAME, value=u'AdminProject'
key=routes.route, value=routes.route.Route object at 0x7f5fb181fc90
key=webob.is_body_readable, value=True
key=mod_wsgi.listener_port, value='9292'
key=HTTP_X_PROJECT_NAME, value=u'AdminProject'
key=SERVER_SOFTWARE, value='Apache'
key=content-length, value=8
key=SCRIPT_NAME, value='/v1/v1'
key=HTTP_TRANSFER_ENCODING, value='chunked'
key=mod_wsgi.handler_script, value=''
key=SERVER_SIGNATURE, value='addressApache Server at 10.1.184.1 Port 
9292/address\n'
key=REQUEST_METHOD, value='POST'
key=PATH_INFO, value='/images'
key=SERVER_PROTOCOL, value='HTTP/1.1'
key=QUERY_STRING, value=''
key=Content_Length, value=8
key=HTTP_X_USER_ID, value=u'0dd0361fe85a43deb456dd47ed55c2e2'
key=HTTP_X_IMAGE_META_MIN_RAM, value='0'
key=HTTP_X_AUTH_TOKEN, value='de169f1045f8d306a750d28e8e33172e'
key=HTTP_USER_AGENT, value='python-glanceclient'
key=HTTP_X_DOMAIN_NAME, value=None
key=SERVER_NAME, value='10.1.184.1'
key=REMOTE_ADDR, value='10.1.184.1'
key=HTTP_X_ROLE, value=u'admin'
key=mod_wsgi.request_handler, value='wsgi-script'
key=HTTP_X_IDENTITY_STATUS, value='Confirmed'
key=wsgi.url_scheme, value='https'
key=SERVER_ADMIN, value='[no address given]'
key=CONTENT_LENGTH, value=8
key=HTTP_X_DOMAIN_ID, value=None
key=PATH_TRANSLATED, value='/etc/apache2/wsgi/glance/glance-api.py/v1/images'
key=SERVER_PORT, value='9292'
key=HTTP_X_PROJECT_DOMAIN_ID, value=None
key=wsgiorg.routing_args, value=(routes.util.URLGenerator object at 
0x7f5fb1765a90, {'action': u'create', 'controller': 
glance.common.wsgi.Resource object at 0x7f5fb181fc10})
key=HTTP_X_USER_DOMAIN_ID, value=None
key=wsgi.multiprocess, value=True
key=mod_wsgi.input_chunked, value='1'
key=SERVER_ADDR, value='10.1.184.1'
key=DOCUMENT_ROOT, value='/etc/apache2/htdocs'
key=HTTP_X_IMAGE_META_SIZE, value='8'
key=mod_wsgi.process_group, value='glance-api'
key=HTTP_X_PROJECT_DOMAIN_NAME, value=None
key=HTTP_X_SERVICE_CATALOG, value='[{endpoints_links: [], endpoints: 
[{adminURL: 
https://192.168.124.81:8774/v2/eba7179c427f4c8bb177e4b37e6b4fcf;, region: 
Region1, publicURL: 
https://10.1.184.2:8774/v2/eba7179c427f4c8bb177e4b37e6b4fcf;, internalURL: 
https://192.168.124.81:8774/v2/eba7179c427f4c8bb177e4b37e6b4fcf;, id: 
7d60c1b83ee9434cac1a799ff912bd71}], type: compute, name: nova}, 
{endpoints_links: [], endpoints: [{adminURL: 
https://192.168.124.82:9696/;, region: Region1, publicURL: 
https://10.1.184.1:9696/;, internalURL: https://192.168.124.82:9696/;, 
id: 23e53efd167c49c683a4d97900f781e6}, {adminURL: 
https://192.168.124.82:9696/;, region: domain, publicURL: 
https://10.1.184.1:9696/;, internalURL: https://192.168.124.82:9696/;, 
id: 82bbe0e5b6954ea1a599582188c0197d}], type: network, name: 
quantum}, {endpoints_links: [], endpoints: [{adminURL: 
http://192.168.124.82:21062/;, region: domain, publicURL: 
http://10.1.184.1:21061/1;, internalURL: http://192.168.124.82:21061/1;, 
id: c302d392551649c187a0f58d2cc6b3f4}], type: repository, name: 
focus}, {endpoints_links: [], endpoints: [{adminURL: 
https://192.168.124.82:9292;, region: Region1, publicURL: 
https://10.1.184.1:9292;, internalURL: https://192.168.124.82:9292;, id: 
33a17baeb73644af8f45ebe631ab9788}, {adminURL: 
https://192.168.124.82:9292;, region: domain, publicURL: 
https://10.1.184.1:9292;, internalURL: https://192.168.124.82:9292;, id: 
4b0827ac48824f60b508fdb1edb3a401}], type: image, name: glance}, 
{endpoints_links: [], endpoints: [{adminURL: 
https://192.168.124.82:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, region: 
Region1, publicURL: 
https://10.1.184.1:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, internalURL: 
https://192.168.124.82:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, id: 
f4ab866d10ef4bc297dbe1c7c747557c}, {adminURL: 
https://192.168.124.82:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, region: 
domain, publicURL: 
https://10.1.184.1:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, internalURL: 
https://192.168.124.82:8776/v1/eba7179c427f4c8bb177e4b37e6b4fcf;, id: 
e813d4f2ab8d49119146ba313645a37e}], type: volume, name: cinder}, 
{endpoints_links: [], endpoints: [{adminURL: 
https://192.168.124.81:8773/services/Admin;, region: Region1, publicURL: 
https://10.1.184.2:8773/services/Cloud;, internalURL: 
https://192.168.124.81:8773/services/Clouds;, id: 
c77f6aacaaa64c68af48cc9b073ea81f}], type: ec2, name: ec2}, 
{endpoints_links: [], endpoints:

Re: [openstack-dev] a time-based resource management system

Sorry, forgot to add a link to our Launchpad: https://launchpad.net/climate

Thanks!


On Tue, Dec 17, 2013 at 12:27 PM, Dina Belova dbel...@mirantis.com wrote:

 Hi, Alan!

 I'm really glad you have mentioned that problem, that was not really
 covered by OpenStack projects for much time. Our (Climate) team is working
 on implementing Reservation-as-a-Service. As I understand, you are
 interested in reserving (managing) virtual resources on a time-based
 criteria. We are going to have 0.1 release asap (we hope to make code
 freeze next week).

 You are welcome to join our IRC channel and participate in our weekly
 meetings.

 P.S. btw, we have it today, 10:00 UTC (usually we hold them on Mondays,
 but that's emergency case).
 P.P.S. would be nice to see you on it :)

 Thanks!


 On Tue, Dec 17, 2013 at 12:16 PM, Nikolay Starodubtsev 
 nstarodubt...@mirantis.com wrote:

 Hi all
 I've looked at the wiki page and now I can say that Cafe have an overlap
 with Climate. Feel free to contact us at #openstack-climate. Also, please
 take a look at our patches on review.openstack.org:

 https://review.openstack.org/#/q/status:open+project:stackforge/climate,n,z



 Nikolay Starodubtsev

 Software Engineer

 Mirantis Inc.


 Skype: dark_harlequine1


 2013/12/17 Tim Bell tim.b...@cern.ch

   There appears to be some overlap of this proposal with ‘climate’
 which provides a resource reservation system.



 They meet regularly … see
 https://wiki.openstack.org/wiki/Meetings/Climate for contacts.



 Tim



 *From:* Alan Tan [mailto:y...@students.waikato.ac.nz]
 *Sent:* 16 December 2013 23:42

 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] a time-based resource management system



 Hi everyone,



 My name is Alan and I am from the Cyber Security Lab in University of
 Waikato.



 We have recently started deploying and using Openstack in our
 experimental private cloud testbed. The cloud testbed is mainly used in
 running our research and teaching purposes. However, we notice that current
 Openstack lacks the ability to control and manage user’s access to
 resources in a time-based manner.



 I.e. Current model for private clouds requires either the user to
 release their resources (VMs) voluntarily or for the administrators to
 manually remove the resources (VMs).



 This makes capacity management a laborious effort in private clouds that
 have a large user base. Hence, we have come up with the idea of an
 automatic time-based resource management system that manages user access to
 resources in a time slot booking style. We have detailed our plans and
 design in the following wiki page. We would love to hear feedbacks from the
 community and hopefully gather some interest in our project.



 https://wiki.openstack.org/wiki/Cafe



 We look forward to hearing from you. We can be contacted via email. Our
 addresses are listed on the wiki page.



 Thanks and have a good day.



 Cheers,

 Alan



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --

 Best regards,

 Dina Belova

 Software Engineer

 Mirantis Inc.




-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge

2013-12-17 Thread Matthias Runge

On 12/17/2013 09:04 AM, Thomas Goirand wrote:

 
 I think the disabled by default approach is the wrong one. Instead, we
 should have some users with enough credentials that will have the
 feature, and others will not.
 
 Also, Horizon is a web interface. Most of its switches could be made
 directly in the web interface, with the values stored in a db. That'd be
 so much nicer than stored in localsettings.py which starts, as time
 passes, to become overly complicated and ugly (it should, by the way, be
 a configuration file, not a python script: you can't expect
 administrators to understand python, but you do expect them to
 understand how to write in a .ini file).
 
 Also, it seems we have a consensus, when is it expected to happen? For
 Icehouse b2 maybe?
 
 Just my 2 cents,

The issue is, that you can not do anything with it, when it's not
configured. The other thing: When you're up to try it, you need quite a
few machines (to install OpenStack on them) etc.

Thus I think, disabled by default is the best way to not to confuse
people, since you now need to know, what you're doing.

We might/should rethink this decision in the future.


The other suggestion (totally unrelated to Tuskar) you had was: to store
config data in a database instead of a (python) config file.
Currently, Horizon does not require a database, and I'd love to keep it
that way. There are currently two configs to be changed once, when
configuring the Dashboard: ALLOWED_HOSTS and OPENSTACK_HOST. The first
is to configure the host to run on, the other points to keystone. This
gets you up and running.

We're inheriting config file handling from Django, and this consists on
parsing python files.

But, if you look at
https://github.com/openstack/horizon/tree/master/openstack_dashboard/local/enabled
you'll see a more .ini-file approach, probably more like you were thinking.

Matthias


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

2013-12-17 Thread Ladislav Smola


On 12/16/2013 08:48 PM, Jay Dobies wrote:



On 12/13/2013 01:53 PM, Tzu-Mainn Chen wrote:

On 2013/13/12 11:20, Tzu-Mainn Chen wrote:

These look good!  Quick question - can you explain the purpose of Node
Tags?  Are they
an additional way to filter nodes through nova-scheduler (is that even
possible?), or
are they there solely for display in the UI?

Mainn


We start easy, so that's solely for UI needs of filtering and 
monitoring

(grouping of nodes). It is already in Ironic, so there is no reason why
not to take advantage of it.
-- Jarda


Okay, great.  Just for further clarification, are you expecting this 
UI filtering
to be present in release 0?  I don't think Ironic natively supports 
filtering

by node tag, so that would be further work that would have to be done.

Mainn


I might be getting ahead of things, but will the tags be free-form 
entered by the user, pre-entered in a separate settings and selectable 
at node register/update time, or locked into a select few that we 
specify?




We are definitely going ahead. :-) Though I would lean to free form 
tags, that users could use as they want (grouping, creating policies, 
etc.). Plus there would be a basic set we specify for the users.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OS::Metering::Alarm?

2013-12-17 Thread Sebastian Porombka

Hi Folks.

I’m currently trying to understand the openstack mechanics in detail (e.g. to 
fix various ec2 api shortcomings) and reached heat. I tried to add heat to our 
on-premise installation and failed to try the ‚AutoScalingCeilometer.yaml‘ demo 
template. Heat-api throwed a


== /var/log/upstart/heat-api.log ==

2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred serving 
API: Unknown resource Type : OS::Metering::Alarm

2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 661, in __call__

2013-12-17 09:51:30.268 3341 TRACE root request, **action_args)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 729, in dispatch

2013-12-17 09:51:30.268 3341 TRACE root return method(*args, **kwargs)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py, line 30, in 
handle_stack_method

2013-12-17 09:51:30.268 3341 TRACE root return handler(controller, req, 
**kwargs)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py, line 314, 
in validate_template

2013-12-17 09:51:30.268 3341 TRACE root data.template())

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/rpc/client.py, line 121, in 
validate_template

2013-12-17 09:51:30.268 3341 TRACE root template=template))

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/proxy.py, line 
126, in call

2013-12-17 09:51:30.268 3341 TRACE root result = rpc.call(context, 
real_topic, msg, timeout)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/__init__.py, line 
141, in call

2013-12-17 09:51:30.268 3341 TRACE root return _get_impl().call(CONF, 
context, topic, msg, timeout)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/impl_kombu.py, 
line 816, in call

2013-12-17 09:51:30.268 3341 TRACE root rpc_amqp.get_connection_pool(conf, 
Connection))

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line 574, 
in call

2013-12-17 09:51:30.268 3341 TRACE root rv = list(rv)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line 539, 
in __iter__

2013-12-17 09:51:30.268 3341 TRACE root raise result

2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed_Remote: Unknown 
resource Type : OS::Metering::Alarm

2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line 461, 
in _process_data

2013-12-17 09:51:30.268 3341 TRACE root **args)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/dispatcher.py, 
line 172, in dispatch

2013-12-17 09:51:30.268 3341 TRACE root result = getattr(proxyobj, 
method)(ctxt, **kwargs)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/engine/service.py, line 60, in wrapped

2013-12-17 09:51:30.268 3341 TRACE root return func(self, ctx, *args, 
**kwargs)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/engine/service.py, line 364, in 
validate_template

2013-12-17 09:51:30.268 3341 TRACE root ResourceClass = 
resource.get_class(res['Type'])

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/engine/resource.py, line 45, in 
get_class

2013-12-17 09:51:30.268 3341 TRACE root return 
resources.global_env().get_class(resource_type, resource_name)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 326, in 
get_class

2013-12-17 09:51:30.268 3341 TRACE root return 
self.registry.get_class(resource_type, resource_name)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 257, in 
get_class

2013-12-17 09:51:30.268 3341 TRACE root raise 
exception.StackValidationFailed(message=msg)

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed: Unknown resource 
Type : OS::Metering::Alarm

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17 09:51:30.268 3341 TRACE root

2013-12-17

Re: [openstack-dev] [oslo]: implementing olso.messaging over amqp 1.0


On 16/12/13 17:14 +, Gordon Sim wrote:
I've pasted these into an etherpad[1] for anyone interested. Please 
feel free to edit/augment etc, or even to query anything on this list. 
It's really just an initial draft to get the ball rolling.


--Gordon

[1] https://etherpad.openstack.org/p/olso.messaging_amqp_1.0



Hi Gordon,

I created this blueprint[0] and linked your documentation there. I
also marked the old proton implementation blueprint as superseded by
this one since it'll cover a broader area than that blueprint.

Thanks for your hard work in those docs.
FF

[0] 
https://blueprints.launchpad.net/oslo.messaging/+spec/amqp10-driver-implementation

--
@flaper87
Flavio Percoco


pgpC9dVaHQWAk.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OS::Metering::Alarm?

As I see on
http://docs.openstack.org/developer/heat/template_guide/openstack.html,
there is type OS::Ceilometer::Alarm, not  OS::Metering::Alarm... Maybe it's
somehow connected with your problem?


On Tue, Dec 17, 2013 at 12:59 PM, Sebastian Porombka 
porom...@uni-paderborn.de wrote:

  Hi Folks.

  I’m currently trying to understand the openstack mechanics in detail
 (e.g. to fix various ec2 api shortcomings) and reached heat. I tried to add
 heat to our on-premise installation and failed to try the
 ‚AutoScalingCeilometer.yaml‘ demo template. Heat-api throwed a

  == /var/log/upstart/heat-api.log ==

 2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred
 serving API: Unknown resource Type : OS::Metering::Alarm

 2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 661, in
 __call__

 2013-12-17 09:51:30.268 3341 TRACE root request, **action_args)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 729, in
 dispatch

 2013-12-17 09:51:30.268 3341 TRACE root return method(*args, **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py, line 30,
 in handle_stack_method

 2013-12-17 09:51:30.268 3341 TRACE root return handler(controller,
 req, **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py, line
 314, in validate_template

 2013-12-17 09:51:30.268 3341 TRACE root data.template())

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/rpc/client.py, line 121, in
 validate_template

 2013-12-17 09:51:30.268 3341 TRACE root template=template))

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/proxy.py, line
 126, in call

 2013-12-17 09:51:30.268 3341 TRACE root result = rpc.call(context,
 real_topic, msg, timeout)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/__init__.py,
 line 141, in call

 2013-12-17 09:51:30.268 3341 TRACE root return _get_impl().call(CONF,
 context, topic, msg, timeout)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/impl_kombu.py,
 line 816, in call

 2013-12-17 09:51:30.268 3341 TRACE root
 rpc_amqp.get_connection_pool(conf, Connection))

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line
 574, in call

 2013-12-17 09:51:30.268 3341 TRACE root rv = list(rv)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line
 539, in __iter__

 2013-12-17 09:51:30.268 3341 TRACE root raise result

 2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed_Remote:
 Unknown resource Type : OS::Metering::Alarm

 2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line
 461, in _process_data

 2013-12-17 09:51:30.268 3341 TRACE root **args)

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/dispatcher.py,
 line 172, in dispatch

 2013-12-17 09:51:30.268 3341 TRACE root result = getattr(proxyobj,
 method)(ctxt, **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/engine/service.py, line 60, in
 wrapped

 2013-12-17 09:51:30.268 3341 TRACE root return func(self, ctx, *args,
 **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/engine/service.py, line 364, in
 validate_template

 2013-12-17 09:51:30.268 3341 TRACE root ResourceClass =
 resource.get_class(res['Type'])

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/engine/resource.py, line 45, in
 get_class

 2013-12-17 09:51:30.268 3341 TRACE root return
 resources.global_env().get_class(resource_type, resource_name)

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 326, in
 get_class

 2013-12-17 09:51:30.268 3341 TRACE root return
 self.registry.get_class(resource_type, resource_name)

 2013-12-17 09:51:30.268 3341 TRACE root

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/engine/environment.py, line 257, in
 get_class

Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)

2013-12-17 Thread Vijay Venkatachalam

Replies Inline!

 -Original Message-
 From: Evgeny Fedoruk [mailto:evge...@radware.com]
 Sent: Thursday, December 12, 2013 5:56 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)

 Thanks for your review Vijay

 1. Pass-Info is for the backend. Used for informing the Back-End regarding
 SSL termination details.

Will SSL Termination details be passed through HTTP headers? If so, what will 
be the http header names? 
Also ssl_policy.pass_info  is a string, how does it work?

Do you see a strong use case? Otherwise this can be skipped for phase-1.

 2. Added cipher-suites groups
 3. Added default policy
 4. Added SNI support. I think our model should support it, since EC2 supports
 it.
 5. Renamed Trusted Key to Trusted Certificate. I thought CA is obvious,
 Back-End Certificate is an option too, What do you think?

Trusted Certificate seems fine. 

ssl_trusted_key (new) datamodel and its properties are still not changed. You 
might want to rename ssl_trusted_key* = ssl_trusted_certificate*
ssl_trusted_key_id  also can be renamed

 6. Renamed Certificate's public key to certificate.

There are still keys used in place of certificate

public_key : PEM-formatted string

 Regards,
 Evg

 -Original Message-
 From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
 Sent: Wednesday, December 11, 2013 2:05 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: Abhishek Gautam
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate
 as first-class citizen - SSL Termination (Revised)

 Thanks for the detailed write-up Evg.

 What is the use of SSLPolicy.PassInfo?
 Managing as individual ciphers is a pain, Can we introduce an entity called
 cipher groups? This enables to provide built-in cipher groups (HIGH, LOW,
 DES etc) as well. At the least we can provide this in the UI+CLI layer.
 Also, it will be good to have a built-in DEFAULT ssl policy, which contains
 default set of SSL protocols, ciphers etc. which is to be used when sslpolicy 
 is
 not provided.
 Is there a need for binding multiple certificates for a VIP, because SNI is 
 not
 modeled now? We could have vip_id as the key in vip_ssl_certificate_assoc.

 Also, it will be good to have the following nomenclature corrected:
 TrustedKey: This entity refers to a CA certificate, usage key can be avoided.
 My suggestion is to call it CA or cacert.
 SSLCertificate.PublicKey: The property contains a server certificate (actually
 PublicKey + more info). My suggestion is to call the property as certificate

 Thanks,
 Vijay V.

  -Original Message-
  From: Evgeny Fedoruk [mailto:evge...@radware.com]
  Sent: Sunday, December 08, 2013 10:24 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)

  Hi All.
  The wiki page for LBaaS SSL support was updated.
  Please see and comment
  https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association

  Thank you!
  Evg

  -Original Message-
  From: Samuel Bercovici
  Sent: Thursday, December 05, 2013 9:14 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Cc: Evgeny Fedoruk; Samuel Bercovici
  Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)

  Correct.

  Evgeny will update the WIKI accordingly.
  We will add a flag in the SSL Certificate to allow specifying that the
  private key can't be persisted. And in this case, the private key
  could be passed when associating the cert_id with the VIP.

  Regards,
  -Sam.

  -Original Message-
  From: Nachi Ueno [mailto:na...@ntti3.com]
  Sent: Thursday, December 05, 2013 8:21 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for
  certificate as first-class citizen - SSL Termination (Revised)

  Hi folks

  OK, It looks like we get consensus on
  separate resource way.

  Best
  Nachi

  2013/12/5 Eugene Nikanorov enikano...@mirantis.com:
   Hi,

   My vote is for separate resource (e.g. 'New Model'). Also I'd like
   to see certificate handling as a separate extension/db mixing(in
   fact, persistence
   driver) similar to service_type extension.

   Thanks,
   Eugene.

   On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran
   stephen.g...@theguardian.com
   wrote:

   Hi,

   Right, sorry, I see that wasn't clear - I blame lack of coffee :)

   I would prefer the Revised New Model.  I much prefer the ability
   to restore a loadbalancer from config in the event of node failure,
   and the ability to do basic sharing of certificates between VIPs.

   I think that a longer

Re: [openstack-dev] OS::Metering::Alarm?

2013-12-17 Thread Sebastian Porombka

Hi Dina, hi developers.

Thanks for the very very helpful hint.

The problem issuing this exception is the lack of  
/etc/heat/environment.d/default.yaml in the ubuntu cloud reposity packages.


root@head2:# cd /etc/heat/

root@head2:/etc/heat# ls -alh environment.d/

total 12K

drwxr-xr-x 2 heat heat 4.0K Dec 17 10:25 .

drwxr-xr-x 3 heat heat 4.0K Dec 17 10:25 ..

-rw-rw-r-- 1 heat heat  436 Dec 17 10:25 default.yaml

root@head2:/etc/heat# cat environment.d/default.yaml


resource_registry:

# allow older templates with Quantum in them.

OS::Quantum*: OS::Neutron*

# Choose your implementation of AWS::CloudWatch::Alarm

#AWS::CloudWatch::Alarm: 
file:///etc/heat/templates/AWS_CloudWatch_Alarm.yaml

AWS::CloudWatch::Alarm: OS::Heat::CWLiteAlarm

OS::Metering::Alarm: OS::Ceilometer::Alarm

AWS::RDS::DBInstance: file:///etc/heat/templates/AWS_RDS_DBInstance.yaml

root@head2:/etc/heat#

Big thanks.
Sebastian

--
Sebastian Porombka, M.Sc.
Zentrum für Informations- und Medientechnologien (IMT)
Universität Paderborn

E-Mail: porom...@uni-paderborn.de
Tel.: 05251/60-5999
Fax: 05251/60-48-5999
Raum: N5.314


Q: Why is this email five sentences or less?
A: http://five.sentenc.es

Please consider the environment before printing this email.

Von: Dina Belova dbel...@mirantis.commailto:dbel...@mirantis.com
Antworten an: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Datum: Dienstag, 17. Dezember 2013 10:08
An: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Betreff: Re: [openstack-dev] OS::Metering::Alarm?

As I see on 
http://docs.openstack.org/developer/heat/template_guide/openstack.html, there 
is type OS::Ceilometer::Alarm, not  OS::Metering::Alarm... Maybe it's somehow 
connected with your problem?


On Tue, Dec 17, 2013 at 12:59 PM, Sebastian Porombka 
porom...@uni-paderborn.demailto:porom...@uni-paderborn.de wrote:
Hi Folks.

I’m currently trying to understand the openstack mechanics in detail (e.g. to 
fix various ec2 api shortcomings) and reached heat. I tried to add heat to our 
on-premise installation and failed to try the ‚AutoScalingCeilometer.yaml‘ demo 
template. Heat-api throwed a


== /var/log/upstart/heat-api.log ==

2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred serving 
API: Unknown resource Type : OS::Metering::Alarm

2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 661, in __call__

2013-12-17 09:51:30.268 3341 TRACE root request, **action_args)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 729, in dispatch

2013-12-17 09:51:30.268 3341 TRACE root return method(*args, **kwargs)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py, line 30, in 
handle_stack_method

2013-12-17 09:51:30.268 3341 TRACE root return handler(controller, req, 
**kwargs)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py, line 314, 
in validate_template

2013-12-17 09:51:30.268 3341 TRACE root data.template())

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/rpc/client.py, line 121, in 
validate_template

2013-12-17 09:51:30.268 3341 TRACE root template=template))

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/proxy.py, line 
126, in call

2013-12-17 09:51:30.268 3341 TRACE root result = rpc.call(context, 
real_topic, msg, timeout)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/__init__.py, line 
141, in call

2013-12-17 09:51:30.268 3341 TRACE root return _get_impl().call(CONF, 
context, topic, msg, timeout)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/impl_kombu.py, 
line 816, in call

2013-12-17 09:51:30.268 3341 TRACE root rpc_amqp.get_connection_pool(conf, 
Connection))

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line 574, 
in call

2013-12-17 09:51:30.268 3341 TRACE root rv = list(rv)

2013-12-17 09:51:30.268 3341 TRACE root   File 
/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line 539, 
in __iter__

2013-12-17 09:51:30.268 3341 TRACE root raise result

2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed_Remote: Unknown 
resource Type : OS::Metering::Alarm

2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

2013-12-17 09:51:30.268 3341 TRACE root

[openstack-dev] Fwd: New feature proposal: send additional headers in API calls

2013-12-17 Thread Yolanda Robla

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi
I just wanted to raise a new feature proposal request we are
interested in. We are interested in sending additional API calls in
headers, in each openstack component.
A sample code i created (using keystone as target) is showed on that
link: https://review.openstack.org/#/c/61128/

It relies on a new section in config files called extra_headers, where
we can provide a set of key-value keypairs, and that will be sent in
the headers of each API response.

We want to use that to be able to send the distribution used for
Openstack deployment, but could be used for other generic purposes.
Headers could also be disabled if not necessary.

We wanted to have some opinions about this, if this feature looks
interesting to be sent upstream, if do you think there are better ways
to achieve it, etc...

So we are open for feedback.

Best

Yolanda Robla
Ubuntu Server Engineer
Ubuntu http://ubuntu.com / Canonical http://canonical.com
yolanda.ro...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSsBtBAAoJEHui+4jWFHJLmL8IAM0vuWs4pB2MGOtRmqtjDG5G
luYTXt8pZgcNMhutB2cxzvuDNNAzEXDqoo45UI0X2EZ7+RGToEssxNBQj7fK61Zc
xhu5wPOlZFPEWtsSDM/0b+Dhl1WkfqcZARDhxp+6olRkUTDPbcgdCLXBdVjGREYb
nyJH99buWjjKAl+ym9qXpzJjjORhlPnsTmhHAg5cwqtQ8//uW/zoPeVCTujfeKhU
9ETD10cl3zEB9tq36qaJxVfpHMnWv3ckfbc07K5mi6p1UZudQOAw2chwNqZSBWTw
K6Q4N1/W5EsTKM76BOCSmvrsH1Bl2rGmzkddjaV7MV0w+GCAk0vYMfiZdFkAWhs=
=L9Cq
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OS::Metering::Alarm?

2013-12-17 Thread Steven Hardy

On Tue, Dec 17, 2013 at 08:59:19AM +, Sebastian Porombka wrote:
 Hi Folks.
 
 I’m currently trying to understand the openstack mechanics in detail (e.g. to 
 fix various ec2 api shortcomings) and reached heat. I tried to add heat to 
 our on-premise installation and failed to try the 
 ‚AutoScalingCeilometer.yaml‘ demo template. Heat-api throwed a
 
 
 == /var/log/upstart/heat-api.log ==
 
 2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred serving 
 API: Unknown resource Type : OS::Metering::Alarm

Probably the reason is your default environment doesn't contain the mapping
to OS::Ceilometer::Alarm, as OS::Metering::Alarm was renamed a while ago:

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

So you can either s/Metering/Ceilometer in your template, or update your
environment to map the old to new resource name.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation


On 16/12/13 23:49 +, Mark McLoughlin wrote:

Hi Thierry,

On Fri, 2013-12-13 at 15:53 +0100, Thierry Carrez wrote:

Hi everyone,

TL;DR:
Incubation is getting harder, why not ask efforts to apply for a new
program first to get the visibility they need to grow.

Long version:

Last cycle we introduced the concept of Programs to replace the
concept of Official projects which was no longer working that well for
us. This was recognizing the work of existing teams, organized around a
common mission, as an integral part of delivering OpenStack.
Contributors to programs become ATCs, so they get to vote in Technical
Committee (TC) elections. In return, those teams place themselves under
the authority of the TC.

This created an interesting corner case. Projects applying for
incubation would actually request two concurrent things: be considered a
new Program, and give incubated status to a code repository under
that program.

Over the last months we significantly raised the bar for accepting new
projects in incubation, learning from past integration and QA mistakes.
The end result is that a number of promising projects applied for
incubation but got rejected on maturity, team size, team diversity, or
current integration level grounds.

At that point I called for some specific label, like Emerging
Technology that the TC could grant to promising projects that just need
more visibility, more collaboration, more crystallization before they
can make good candidates to be made part of our integrated releases.

However, at the last TC meeting it became apparent we could leverage
Programs to achieve the same result. Promising efforts would first get
their mission, scope and existing results blessed and recognized as
something we'd really like to see in OpenStack one day. Then when they
are ready, they could have one of their deliveries apply for incubation
if that makes sense.

The consequences would be that the effort would place itself under the
authority of the TC. Their contributors would be ATCs and would vote in
TC elections, even if their deliveries never make it to incubation. They
would get (some) space at Design Summits. So it's not free, we still
need to be pretty conservative about accepting them, but it's probably
manageable.

I'm still weighing the consequences, but I think it's globally nicer
than introducing another status. As long as the TC feels free to revoke
Programs that do not deliver the expected results (or that no longer
make sense in the new world order) I think this approach would be fine.

Comments, thoughts ?


Thanks for writing this up; a few thoughts ...


I'm not totally convinced we need such formality around the TC
expressing its support for an early-stage program/project/effort/team.

How about if we had an RFC process (hmm, but not in the IETF sense)
whereby an individual or team can submit a document expressing a
position and ask the TC to give its feedback? We would record that
feedback in the governance repo, and it would be a short piece of prose
(perhaps even recording a diversity of views amongst the TC members)
rather than a yes/no status vote.

In the case of a fledgling project, they'd write up something like a
first draft of an incubation application and we'd give our feedback,
encouragement, whatever.


This sounds reasonable. It also sounds like a good way to officially
put a TC stamp on an emerging technology before the request for
incubation. The benefits I see from this is that:

   1. The team working on that project knows there's an interest on
   the work they're doing and that the project fits into OpenStack

   2. They don't have to worry about what program the project fits
   in, yet. Instead, the team can focus on working towards
   incubation.

   3. The TC will be aware of this emerging technology. Emerging
   technologies could request 'follow-up' meetings to the TC, or the
   other way around. (Brainstorming)

I still think that emerging / incubated projects shouldn't worry about
programs. If they've been tagged as emerging or entered into
incubation is because the TC thinks they fit into OpenStack and that
should be enough until the project is ready to graduate.


Setting a very low bar for the officialness of becoming a Program seems
wrong to me - I wouldn't like to see Programs being added and then later
removed with any sort of regularity. Part of what people are looking for
is an indication of what's coming down the track and the endorsement
implicit in becoming a Program - before a long-term viable team has been
established - seems too strong for me.


Even though this doesn't grant ATC status to the people working on those
projects, I'm struggling to see that as a burning issue for anyone -
honestly, if you're working on an early-stage, keen-to-be-incubated
project then I'd be surprised if you didn't find some small way to
contribute to one of our many ATC-granting projects.


+1 I agree here. One of the requirements for entering incubation is

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation


On 2013/13/12 19:53, Tzu-Mainn Chen wrote:

We start easy, so that's solely for UI needs of filtering and monitoring
(grouping of nodes). It is already in Ironic, so there is no reason why
not to take advantage of it.
-- Jarda


Okay, great.  Just for further clarification, are you expecting this UI 
filtering
to be present in release 0?  I don't think Ironic natively supports filtering
by node tag, so that would be further work that would have to be done.


I wouldn't expect server-side filtering for v0. Maybe not even for v1 (? 
this is questionable). We can start with client side based UI filtering 
- easy to implement.


-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OS::Metering::Alarm?

Sebastian, you are welcome :)


On Tue, Dec 17, 2013 at 1:30 PM, Sebastian Porombka 
porom...@uni-paderborn.de wrote:

  Hi Dina, hi developers.

  Thanks for the very very helpful hint.

  The problem issuing this exception is the lack of
  /etc/heat/environment.d/default.yaml in the ubuntu cloud reposity packages.

  root@head2:# cd /etc/heat/

 root@head2:/etc/heat# ls -alh environment.d/

 total 12K

 drwxr-xr-x 2 heat heat 4.0K Dec 17 10:25 *.*

 drwxr-xr-x 3 heat heat 4.0K Dec 17 10:25 *..*

 -rw-rw-r-- 1 heat heat  436 Dec 17 10:25 default.yaml

 root@head2:/etc/heat# cat environment.d/default.yaml


  resource_registry:

 # allow older templates with Quantum in them.

 OS::Quantum*: OS::Neutron*

 # Choose your implementation of AWS::CloudWatch::Alarm

 #AWS::CloudWatch::Alarm:
 file:///etc/heat/templates/AWS_CloudWatch_Alarm.yaml

 AWS::CloudWatch::Alarm: OS::Heat::CWLiteAlarm

 OS::Metering::Alarm: OS::Ceilometer::Alarm

 AWS::RDS::DBInstance:
 file:///etc/heat/templates/AWS_RDS_DBInstance.yaml

 root@head2:/etc/heat#

  Big thanks.
 Sebastian

  --
 Sebastian Porombka, M.Sc.
 Zentrum für Informations- und Medientechnologien (IMT)
 Universität Paderborn

  E-Mail: porom...@uni-paderborn.de
 Tel.: 05251/60-5999
 Fax: 05251/60-48-5999
 Raum: N5.314

  
 Q: Why is this email five sentences or less?
 A: http://five.sentenc.es

  Please consider the environment before printing this email.

   Von: Dina Belova dbel...@mirantis.com
 Antworten an: OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org
 Datum: Dienstag, 17. Dezember 2013 10:08
 An: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Betreff: Re: [openstack-dev] OS::Metering::Alarm?

   As I see on
 http://docs.openstack.org/developer/heat/template_guide/openstack.html,
 there is type OS::Ceilometer::Alarm, not  OS::Metering::Alarm... Maybe
 it's somehow connected with your problem?


 On Tue, Dec 17, 2013 at 12:59 PM, Sebastian Porombka 
 porom...@uni-paderborn.de wrote:

  Hi Folks.

  I’m currently trying to understand the openstack mechanics in detail
 (e.g. to fix various ec2 api shortcomings) and reached heat. I tried to add
 heat to our on-premise installation and failed to try the
 ‚AutoScalingCeilometer.yaml‘ demo template. Heat-api throwed a

  == /var/log/upstart/heat-api.log ==

 2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred
 serving API: Unknown resource Type : OS::Metering::Alarm

 2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last):

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 661, in
 __call__

 2013-12-17 09:51:30.268 3341 TRACE root request, **action_args)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/common/wsgi.py, line 729, in
 dispatch

 2013-12-17 09:51:30.268 3341 TRACE root return method(*args, **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py, line 30,
 in handle_stack_method

 2013-12-17 09:51:30.268 3341 TRACE root return handler(controller,
 req, **kwargs)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py, line
 314, in validate_template

 2013-12-17 09:51:30.268 3341 TRACE root data.template())

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/rpc/client.py, line 121, in
 validate_template

 2013-12-17 09:51:30.268 3341 TRACE root template=template))

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/proxy.py, line
 126, in call

 2013-12-17 09:51:30.268 3341 TRACE root result = rpc.call(context,
 real_topic, msg, timeout)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/__init__.py,
 line 141, in call

 2013-12-17 09:51:30.268 3341 TRACE root return _get_impl().call(CONF,
 context, topic, msg, timeout)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/impl_kombu.py,
 line 816, in call

 2013-12-17 09:51:30.268 3341 TRACE root
 rpc_amqp.get_connection_pool(conf, Connection))

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line
 574, in call

 2013-12-17 09:51:30.268 3341 TRACE root rv = list(rv)

 2013-12-17 09:51:30.268 3341 TRACE root   File
 /usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py, line
 539, in __iter__

 2013-12-17 09:51:30.268 3341 TRACE root raise result

 2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed_Remote:
 Unknown resource Type : OS::Metering::Alarm

 2013-12-17 09:51:30.268 3341 TRACE root Traceback

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation



On 2013/16/12 20:48, Jay Dobies wrote:

I might be getting ahead of things, but will the tags be free-form
entered by the user, pre-entered in a separate settings and selectable
at node register/update time, or locked into a select few that we specify?


So what I would expect is completely free-form entering. User enters an 
arbitrary tag, system will suggest him already existing ones and if 
there is none which he wants, he just leaves entered value.


-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge

2013-12-17 Thread Ladislav Smola


Horizoners,

As an alternative merge option, we could merge directly to Horizon code 
base. After some conversation, we have realized that it is possible to 
mix codebase of incubated and integrated projects, as Trove showed us. 
Contrary to what was said in the last meeting, we do not require any 
special treatment for the infrastructure tab and we will continue the 
development of the infrastructure tab with the same rules as the rest of 
the Horizon. Especially, we want to keep culture of cross company 
reviewers, so that we make sure that TripleO/Tuskar UI is not only in 
hands of one company. It is important to mention that there will be more 
code to keep eyes on but we believe that us helping more with reviews in 
Horizon will give more time for reviews in TripleO/Tuskar UI.


This is proposed Roadmap:

1. Before meeting 16.12.2013, send email about the merge.
2. Immediate steps after the meeting (days and weeks)
- Merge of the Tuskar-UI core team to Horizon core team. Namely: 
jtomasek, lsmola, jomara, tzumainn (a point of discussion)

- Tuskar will add a third panel, named infrastructure.
- Tuskar will be disabled by default in Horizon.
- Break tuskar-ui in smaller pieces, submit them individually as patches 
directly for horizon.

3. Long-term steps after the meeting (weeks and months)
- Synchronize coding style and policies.
- Transfer blueprints and bugs to horizon launchpad with 'tuskar-' prefix.
- Continue development under in Horizon codebase. Infrastructure tab 
will have some tabs implemented with mock data, until the underlying 
libraries are finished (Tuskar is depending on several apis, like nova, 
heat, triple-o, ironic.). It will get to stable state in I3 (we need to 
develop in parralel with API's to meet the I3 deadline)

- Transfer Documentation.

The benefits of this was already pointed out by mrunge.

We have a detailed plan of features for I2 and I3, put together by the 
tripleo community, those will be captured as blueprints and presented on 
Horizon meetings.


If you have any questions, please ask!

Thanks,
Tuskar UI team

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] Who can be a asked to help review tempest tests?

2013-12-17 Thread Nadya Privalova

Hi David,

I'm working on tempest tests for Ceilometer too.
I think this thread is a good place to make a reminder about our strategy
how to avoid duplications in change requests.

1. We have something like a test plan
https://etherpad.openstack.org/p/ceilometer-test-plan
2. Ceilometer team's decided that it is easier to keep all changes in one
bp instead of creation a new one for each change. The main bp is here
https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests

Please if you are about to start contributing to Ceilometer's tempest
please add info to any of these resources.

Thanks,
Nadya

On Tue, Dec 17, 2013 at 4:11 AM, David Kranz dkr...@redhat.com wrote:

On 12/16/2013 05:50 PM, Doug Hellmann wrote:

It might be good, to start out, if we all look at them. That way we can
all learn a bit about tempest, too. If you add ceilometer-core as a
reviewer gerrit will expand the group name.

Doug

Thanks, Doug. That makes sense. The only reason I asked this was because
I didn't know it was possible to ask all of you like that!

-David

On Mon, Dec 16, 2013 at 5:33 PM, David Kranz dkr...@redhat.com wrote:

Ceilometer team, we are reviewing tempest tests and hope to see more. The
tempest review team is hoping to identify some ceilometer devs who could
help answer questions or provide a review if needed for ceilometer patches.
Since ceilometer is new we are not all familiar with many of the details.
Can any one on the ceilometer team volunteer?

-David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing
listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Thierry Carrez

Mark McLoughlin wrote:
I'm not totally convinced we need such formality around the TC
expressing its support for an early-stage program/project/effort/team.

This is a difficult balance.

You want to help a number of projects attract more contributors and
reach critical mass. For that, they want visibility, and one way to give
them that is a formal blessing. On the other hand, we want to encourage
the spontaneous creation of teams and projects and reduce formality in
the early stages as much as possible...

How about if we had an RFC process (hmm, but not in the IETF sense)
whereby an individual or team can submit a document expressing a
position and ask the TC to give its feedback? We would record that
feedback in the governance repo, and it would be a short piece of prose
(perhaps even recording a diversity of views amongst the TC members)
rather than a yes/no status vote.

In the case of a fledgling project, they'd write up something like a
first draft of an incubation application and we'd give our feedback,
encouragement, whatever.

I think that level of formality would not trigger enough visibility, so
we'd be back to square 1 with projects applying for incubation because
it's the only way to get the visibility they need to attract enough
contributors.

So I think we need some official label. It can be attached to the
project (emerging technology), or it can be attached to the team and
its mission (incoming/wannabe/emerging program).

One benefit of applying it to the team is that the effort can then more
naturally graduate to become a full-fledged program when the project
gets incubated or integrated, without applying to become a program.

Setting a very low bar for the officialness of becoming a Program seems
wrong to me - I wouldn't like to see Programs being added and then later
removed with any sort of regularity. Part of what people are looking for
is an indication of what's coming down the track and the endorsement
implicit in becoming a Program - before a long-term viable team has been
established - seems too strong for me.

That's a fair remark. Programs come with some expectation of
durability and permanence, and using the same term might set
expectations wrong. If we settle for a team-attached label, we should
probably avoid using program in its name (and call it
incoming/wannabe/emerging effort or something).

Even though this doesn't grant ATC status to the people working on those
projects, I'm struggling to see that as a burning issue for anyone -
honestly, if you're working on an early-stage, keen-to-be-incubated
project then I'd be surprised if you didn't find some small way to
contribute to one of our many ATC-granting projects.

Ideally I'd like to address the case of the programs created from an
incubated project in the same governance change. With the expectation
of durable endorsement we'd like to see attached with Programs, it may
make sense to *not* automatically create a program when a project gets
incubated, but rather when a project is finally integrated.

So two options here:

- Consider incubated as emerging, not create a program and not grant ATC
status

- Consider incubated as integrated, create a program and grant ATC status

One thing I'm noticing that's missing from these new docs:

http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements

http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements

is any caution around increasing the scope of OpenStack. I think we are
cautious about this, but we haven't mentioned it beyond e.g.

** Project must have a clear and defined scope
** Project should not inadvertently duplicate functionality present in other
OpenStack projects. If they do, they should have a clear plan and
timeframe
to prevent long-term scope duplication.
** Project should leverage existing functionality in other OpenStack
projects
as much as possible

How would something like:

** Project must have a clear and defined scope which, in turn, represents
a measured and obvious progression for OpenStack as a whole

sound?

That's a bit orthogonal to this discussion, but +1 :)

--
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: New feature proposal: send additional headers in API calls

2013-12-17 Thread Steven Hardy

On Tue, Dec 17, 2013 at 10:37:05AM +0100, Yolanda Robla wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi
 I just wanted to raise a new feature proposal request we are
 interested in. We are interested in sending additional API calls in
 headers, in each openstack component.
 A sample code i created (using keystone as target) is showed on that
 link: https://review.openstack.org/#/c/61128/
 
 It relies on a new section in config files called extra_headers, where
 we can provide a set of key-value keypairs, and that will be sent in
 the headers of each API response.
 
 We want to use that to be able to send the distribution used for
 Openstack deployment, but could be used for other generic purposes.
 Headers could also be disabled if not necessary.

Ok, I'll bite and ask the obvious question.  Why?

IMO you need a solid technical justification for this, backed up by real
use-cases, and I don't see any in the bug.

In general, I think leaking information about the platform a service is
running on is bad, particularly when it provides no value to users, so -1
on this from me.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation


On 2013/16/12 15:19, Flavio Percoco wrote:

1. Programs that are not part of OpenStack's release cycle shouldn't
be considered official nor they should have the rights that integrated
projects have.
I don't agree on this point. There might be supportive teams, which are 
helping OpenStack in general (like UX) and they are not exactly part of 
release cycles. Why should this team and effort be excluded from 
official recognition?


-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [climate] Meeting minutes

Thank everybody who were on our weekly meeting :)
Meeting minutes are here:

Minutes:
http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.txt

Log:
http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.log.html

-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: New feature proposal: send additional headers in API calls

2013-12-17 Thread Yolanda Robla

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We mostly want that to be able to send distro information into
Openstack, to be able to collect stats about it.
Here is the blueprint for it:
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-server-app-banner-updates

El 17/12/13 11:20, Steven Hardy escribió:
 On Tue, Dec 17, 2013 at 10:37:05AM +0100, Yolanda Robla wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Hi I just wanted to raise a new feature proposal request we are 
 interested in. We are interested in sending additional API calls
 in headers, in each openstack component. A sample code i created
 (using keystone as target) is showed on that link:
 https://review.openstack.org/#/c/61128/
 
 It relies on a new section in config files called extra_headers,
 where we can provide a set of key-value keypairs, and that will
 be sent in the headers of each API response.
 
 We want to use that to be able to send the distribution used for 
 Openstack deployment, but could be used for other generic
 purposes. Headers could also be disabled if not necessary.
 
 Ok, I'll bite and ask the obvious question.  Why?
 
 IMO you need a solid technical justification for this, backed up by
 real use-cases, and I don't see any in the bug.
 
 In general, I think leaking information about the platform a
 service is running on is bad, particularly when it provides no
 value to users, so -1 on this from me.
 
 Steve
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSsDiAAAoJEHui+4jWFHJLjMAIAMzzEz8i1LUN6v9/r61Oy00V
B5T7NTRZYbsjtp/GTsC93naoz0GhS8FIxa9jBwNt8fhJvLouwBx1kD/4QpfWsw02
h/FEQSR/em58pjoKcxFtwkvOGNrzm9o2oin4DBPxEFVqYC8VbM/U/fQKnH5V7K+A
/zL7qkmtNcWdPESDntKHFDZKhoQd4JoMqp797dx+oKljoan9T2hDSimZGKWzCLZ/
oylQslkjNY5OwReYGIfCSKgyZ4MK8GDN/vm6C5QS2neU6qe9WPZNkKwY8MCcqkEP
r78igaqcDN46Ms8NRgWrWmTiz6khhEXly24iJaHpufhHqdhpOkipkpYMhpAs4pU=
=rNTR
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][ceilometer] Who can be a asked to help review tempest tests?

2013-12-17 Thread Christopher Yeoh

On Tue, Dec 17, 2013 at 8:33 PM, Nadya Privalova nprival...@mirantis.comwrote:

 Hi David,

 I'm working on tempest tests for Ceilometer too.
 I think this thread is a good place to make a reminder about our strategy
 how to avoid duplications in change requests.

 1. We have something like a test plan
 https://etherpad.openstack.org/p/ceilometer-test-plan
 2. Ceilometer team's decided that it is easier to keep all changes in one
 bp instead of creation a new one for each change. The main bp is here
 https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests

 Please if you are about to start contributing to Ceilometer's tempest
 please add info to any of these resources.


I have added the blueprint link to here:
https://etherpad.openstack.org/p/TempestTestDevelopment where we keep track
of Tempest tests being developed. You might want to look at

*https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=0*https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=0

as an example of keeping track of test development when multiple people are
working on tests for a REST API.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Mark McLoughlin

On Tue, 2013-12-17 at 11:25 +0100, Thierry Carrez wrote:
 Mark McLoughlin wrote:
  I'm not totally convinced we need such formality around the TC
  expressing its support for an early-stage program/project/effort/team.
 
 This is a difficult balance.
 
 You want to help a number of projects attract more contributors and
 reach critical mass. For that, they want visibility, and one way to give
 them that is a formal blessing. On the other hand, we want to encourage
 the spontaneous creation of teams and projects and reduce formality in
 the early stages as much as possible...
 
  How about if we had an RFC process (hmm, but not in the IETF sense)
  whereby an individual or team can submit a document expressing a
  position and ask the TC to give its feedback? We would record that
  feedback in the governance repo, and it would be a short piece of prose
  (perhaps even recording a diversity of views amongst the TC members)
  rather than a yes/no status vote.
  
  In the case of a fledgling project, they'd write up something like a
  first draft of an incubation application and we'd give our feedback,
  encouragement, whatever.
 
 I think that level of formality would not trigger enough visibility, so
 we'd be back to square 1 with projects applying for incubation because
 it's the only way to get the visibility they need to attract enough
 contributors.

How about if we had an emerging projects page where the TC feedback on
each project would be listed?

That would give visibility to our feedback, without making it a yes/no
blessing. Ok, whether to list any feedback about the project on the page
is a yes/no decision, but at least it allows us to fully express why we
find the project promising, what people need to help with in order for
it to be incubated, etc.

With a formal yes/no status, I think we'd struggle with projects which
we're not quite ready to even bless with an emerging status but we
still want to encourage them - this allows us to bless a project as
emerging but be explicit about our level of support for it.

 So I think we need some official label. It can be attached to the
 project (emerging technology), or it can be attached to the team and
 its mission (incoming/wannabe/emerging program).
 
 One benefit of applying it to the team is that the effort can then more
 naturally graduate to become a full-fledged program when the project
 gets incubated or integrated, without applying to become a program.

I'm not loving the idea of blessing a team more or less independently of
the project they're producing.

I'd tend to be more wary of blessing a program rather than a fledgling
project - if a couple of developers show up and want to be blessed as
the lampshade program, then I'd feel we're placing an awful lot of
trust in them because we're making them responsible for everything
lampshade related in OpenStack. If instead we were just saying we like
this lampshade project you're working on, then we leave room for that
project to grow or wither or be obsoleted by another group working on a
competing lampshade project.

  Setting a very low bar for the officialness of becoming a Program seems
  wrong to me - I wouldn't like to see Programs being added and then later
  removed with any sort of regularity. Part of what people are looking for
  is an indication of what's coming down the track and the endorsement
  implicit in becoming a Program - before a long-term viable team has been
  established - seems too strong for me.
 
 That's a fair remark. Programs come with some expectation of
 durability and permanence, and using the same term might set
 expectations wrong. If we settle for a team-attached label, we should
 probably avoid using program in its name (and call it
 incoming/wannabe/emerging effort or something).
 
  Even though this doesn't grant ATC status to the people working on those
  projects, I'm struggling to see that as a burning issue for anyone -
  honestly, if you're working on an early-stage, keen-to-be-incubated
  project then I'd be surprised if you didn't find some small way to
  contribute to one of our many ATC-granting projects.
 
 Ideally I'd like to address the case of the programs created from an
 incubated project in the same governance change. With the expectation
 of durable endorsement we'd like to see attached with Programs, it may
 make sense to *not* automatically create a program when a project gets
 incubated, but rather when a project is finally integrated.
 
 So two options here:
 
 - Consider incubated as emerging, not create a program and not grant ATC
 status
 
 - Consider incubated as integrated, create a program and grant ATC status

Honestly, I struggle to care much about ATC status or those programs
which are associated with individual projects - the principles I care
about here are:

  (1) that we should be fairly permissive about granting ATC status and

  (2) programs allow us bless as official those efforts or teams who
  aren't primarily

[openstack-dev] [horizon] Blueprint decrypt-and-display-vm-generated-password

2013-12-17 Thread Ala Rezmerita

Hi all,

I would like to get your opinion/feedback about the implementation of the 
blueprint Decrypt and display VM generated password[1]

Our use case is primarily targeting Windows instances with cloudbase-init, but 
the functionality can be also used on Linux instances.
The general idea of this blueprint is to give the user the ability to retrieve, 
through Horizon, administrative password for his Windows session.

There is two ways for the user to set/get his password on cloudbase-init 
Windows instances:
- The user sets the desired password as admin_pass key/value as metadata of the 
new server. Example : https://gist.github.com/arezmerita/8001673. In this case 
the password is visible in instance description, in metatada section. 
- The user do not set his password. In this case the cloudbase-init will 
generate a random password, encrypt it with user provided public key, and will 
send the result to the metadata server. The only way to get the clear password 
is to use API/nova client and provide the private key. Example:  nova 
get-password  . The novaclient will retrieve encrypted password from Nova and 
will use locally the private key in order to decrypt the password. 

Now about our blueprint implementation: 
- We add an new action Retrieve password on an instance, that shows a form 
displaying the key pair name used to boot the instance and the encrypted 
password. The user can provide its private key, that will be used ONLY on the 
client side for password decryption using JSEncrypt library[2]. 
- We choose to not send the private key over the network (for decryption on 
server side), because we consider that the user should not be forced to share 
this information with the cloud operator.
Some may argue that the connection is protected, and we are already passing 
sensitive data over the network. However, openstack user password/tokens are 
openstack sensitive data, they are related to the openstack user. User's 
private key on the other hand, is something personal to the user, 
not-openstack related.

What do you think?  

Note: On the whiteboard of the blueprint[1] I provided two demos and some 
instructions of how to test this functionality with Linux instances.

Thanks,

References: 
[1] 
https://blueprints.launchpad.net/horizon/+spec/decrypt-and-display-vm-generated-password
[2] JSEncrypt library http://travistidwell.com/jsencrypt/


Ala Rezmerita
Software Engineer || Cloudwatt
M: (+33) 06 77 43 23 91
Immeuble Etik
892 rue Yves Kermen
92100 Boulogne-Billancourt – France


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] Terminology




On 2013/13/12 23:11, Jordan OMara wrote:

On 13/12/13 16:20 +1300, Robert Collins wrote:

However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova delete gets
rid of an instance, nova rebuild recreates it, etc. Instances run
[virtual|baremetal] machines managed by a hypervisor. So
nova-scheduler is not ever going to be confused with instance in the
OpenStack space IMO. But it brings up a broader question, which is -
what should we do when terms that are well defined in OpenStack - like
Node, Instance, Flavor - are not so well defined for new users? We
could use different terms, but that may confuse 'stackers, and will
mean that our UI needs it's own dedicated terminology to map back to
e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as
a principle, where there is a well defined OpenStack concept, that we
use it, even if it is not ideal, because the consistency will be
valuable.


I think this is a really important point. I think the consistency is a
powerful tool for teaching new users how they should expect
tripleo/tuskar to work and should lessen the learning curve, as long
they've used openstack before.
I don't 100% agree here. Yes it is important for user to keep 
consistency in naming - but as long as he is working within the same 
domain. Problem is that our TripleO/Tuskar UI user is very different 
from OpenStack UI user. They are operators, and they might be very often 
used to different terminology - globally used and known in their field 
(for example Flavor is very OpenStack specific term, they might better 
see HW profile, or similar).


I think that mixing these terms in overcloud and undercloud might lead 
to problems and users' confusion. They already are confused about the 
whole 'over/under cloud' stuff. They are not working with this approach 
daily as we are. They care about deploying OpenStack, not about how it 
works under the hood. Bringing another more complicated level of 
terminology (explaining what is and belongs to under/overcloud) will 
increase the confusion here.


For developers, it might be easier to deal with the same terms as 
OpenStack already have or what is used in the background to make that 
happen. But for user - it will be confusing going to 
infrastructure/hardware management part and see the very same terms.


Therefor I incline more to broadly accepted general terminology and not 
reusing OpenSTack terms (at least in the UI).


-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [savanna][qa] How will tempest tests run?

2013-12-17 Thread Sergey Lukjanov

Hi,

thank you for catching this question. Sure, we'd like to enable Savanna by
default for d-g tests. We decided to have a separated jobs now to be able
to develop stable enough basic API tests in Tempest to potentially not
break gating. So, that's why we have savanna d-g jobs in exp pipeline of
tempest - to be able to review and merge our changes. And additionally
that's a good question about should incubated projects testing enabled by
default in common d-g tests.

Currently, only one resource (node group templates) covered by API tests
and it's under review, we're really hope that will receive some feedback
for our reviews in tempest and than will continue working on covering other
resource.

Do you have any concerns with such approach?

Thanks.


On Tue, Dec 17, 2013 at 2:30 AM, David Kranz dkr...@redhat.com wrote:

 So it's great to see a submission of savanna tests for tempest. We would
 like to see these tests run before reviewing them. Is the intent that
 savanna will be enabled by default in devstack? If not, then I guess there
 will need to be separate savanna jobs. I see that right now there are
 savanna-enabled devstack jobs on the tempest experimental queue. In the
 long run, what is the intent for how these jobs should run? This is similar
 to the issue with ironic. It doesn't seem very scalable to set up separate
 complete tempest jobs for every project that is not turned on by default in
 devstack. Thoughts?

  -David

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: New feature proposal: send additional headers in API calls

2013-12-17 Thread Steven Hardy

On Tue, Dec 17, 2013 at 12:41:52PM +0100, Yolanda Robla wrote:
 We mostly want that to be able to send distro information into
 Openstack, to be able to collect stats about it.
 Here is the blueprint for it:
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-server-app-banner-updates

So, marketing data basically - it doesn't provide any direct value to users
at all, but your patch expects them to bear the overhead of additional
headers on every API request they make.  This is the wrong approach IMO.

FWIW, we (the Heat project) had a somewhat similar requirement expressed by
our users recently, which ended up being satisfied by a /version_info API
path, where users can get deployer (or distributor) specified strings
related to the service version.  I'm personally not a massive fan of this
feature, but for your use-case it makes way more sense than setting headers
on every request.

https://blueprints.launchpad.net/heat/+spec/heat-build-info

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Shixiong Shang

Hi, guys:

I am reading the code in “constants.py” file as part of Change I5b2313ff: 
Create a new attribute for subnets, to store v6 dhcp options”. One thing 
captured my eyes is the definition of “RA_MODES”, which excluded “slaac” mode. 
If my understanding of “RA_MODES” is correct, i.e. the modes leverage RA, then 
“slaac” mode should be included. Am I correct?

Thanks!

Shixiong







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] VM diagnostics - V3 proposal

2013-12-17 Thread Gary Kotton

Hi,
Following the discussion yesterday I have updated the wiki - please see
https://wiki.openstack.org/wiki/Nova_VM_Diagnostics. The proposal is
backwards compatible and will hopefully provide us with the tools to be
able to troubleshoot VM issues.
Thanks
Gary

On 12/16/13 5:50 PM, Daniel P. Berrange berra...@redhat.com wrote:

On Mon, Dec 16, 2013 at 03:37:39PM +, John Garbutt wrote:
 On 16 December 2013 15:25, Daniel P. Berrange berra...@redhat.com
wrote:
  On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:
  I'd like to propose the following for the V3 API (we will not touch
V2
  in case operators have applications that are written against this 
this
  may be the case for libvirt or xen. The VMware API support was added
  in I1):
 
   1.  We formalize the data that is returned by the API [1]
 
  Before we debate what standard data should be returned we need
  detail of exactly what info the current 3 virt drivers return.
  IMHO it would be better if we did this all in the existing wiki
  page associated with the blueprint, rather than etherpad, so it
  serves as a permanent historical record for the blueprint design.
 
 +1
 
  While we're doing this I think we should also consider whether
  the 'get_diagnostics' API is fit for purpose more generally.
  eg currently it is restricted to administrators. Some, if
  not all, of the data libvirt returns is relevant to the owner
  of the VM but they can not get at it.
 
 Ceilometer covers that ground, we should ask them about this API.

If we consider what is potentially in scope for ceilometer and
subtract that from what the libvirt get_diagnostics impl currently
returns, you pretty much end up with the empty set. This might cause
us to question if 'get_diagnostics' should exist at all from the
POV of the libvirt driver's impl. Perhaps vmware/xen return data
that is out of scope for ceilometer ?

  For a cloud administrator it might be argued that the current
  API is too inefficient to be useful in many troubleshooting
  scenarios since it requires you to invoke it once per instance
  if you're collecting info on a set of guests, eg all VMs on
  one host. It could be that cloud admins would be better
  served by an API which returned info for all VMs ona host
  at once, if they're monitoring say, I/O stats across VM
  disks to identify one that is causing I/O trouble ? IOW, I
  think we could do with better identifying the usage scenarios
  for this API if we're to improve its design / impl.
 
 I like the API that helps you dig into info for a specific host that
 other system highlight as problematic.
 You can do things that could be expensive to compute, but useful for
 troubleshooting.

If things get expensive to compute, then it may well be preferrable to
have separate APIs for distinct pieces of interesting diagnostic
data. eg If they only care about one particular thing, they don't want
to trigger expensive computations of things they don't care about seeing.

Regards,
Daniel
-- 
|: 
https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/k=oIvRg1%2
BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=dd903dfca0
b7b3ace5c560509caf1164f8f3f4dda62174e6374b07a85724183c  -o-
https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
errange/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfD
tysg45MkPhCZFxPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8
%3D%0As=3d3587124076d99d0ad02847a95a69c541cfe296f650027c99cf098aad764ab9
:|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/k=oIvRg1%2B
dGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=60b14571198
ff9afdeb5949597de9596b75ab79abca0496a96703e15aa10  -o-
 
https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/k=oIvR
g1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
Eq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=a6f1f8
5bb37036e37ed7e7dba4d88c00a289cfb0e42740528d5c7ca1bd690620 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/k=oIvRg1%
2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=ee08dd8de
4174a142a6d8c5aa18ede84b47ec0db358b96c3b729232e004641e1   -o-
https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
kPhCZFxPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0A
s=313fd521d220dc3b7cbba305533de490bf614449d0489e705e15f2536657c222 :|
|: 
https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/k=oI
vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
xPEq8%3D%0Am=k92Oxw4Ev6Raba%2FayHa0ExWlFkO%2BLbCNYQYrLDivTK8%3D%0As=da78

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Thierry Carrez

Mark McLoughlin wrote:
 How about if we had an emerging projects page where the TC feedback on
 each project would be listed?
 
 That would give visibility to our feedback, without making it a yes/no
 blessing. Ok, whether to list any feedback about the project on the page
 is a yes/no decision, but at least it allows us to fully express why we
 find the project promising, what people need to help with in order for
 it to be incubated, etc.
 
 With a formal yes/no status, I think we'd struggle with projects which
 we're not quite ready to even bless with an emerging status but we
 still want to encourage them - this allows us to bless a project as
 emerging but be explicit about our level of support for it.

I agree that being able to express our opinion on a project in shades of
grey is valuable... The main drawback of using a non-boolean status for
that is that you can't grant any benefit to it. So we'd not be able to
say emerging projects get design summit space.

They can still collaborate in unconference space or around empty tables,
but then we are back to the problem we are trying to solve: increase
visibility of promising projects pre-incubation.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Docker] Environment variables

2013-12-17 Thread Daniel Kuffner

Actually Daniel P. Barrange comment is interesting. He states that a
configuration per instance would also be beneficial for Cinder. The
configuration is essentially needed to change the bootstrap of the
image. If you look at a docker image in abstract way then that is the
same thing - a configuration to bootstrap the image differently.

From user point of view it could look like:
 nova boot --image-meta key=value

Daniel




On Mon, Dec 16, 2013 at 10:04 PM, Dan Smith d...@danplanet.com wrote:
 eg use a 'env_' prefix for glance image attributes

 We've got a couple of cases now where we want to overrides these
 same things on a per-instance basis. Kernel command line args
 is one other example. Other hardware overrides like disk/net device
 types are another possibility

 Rather than invent new extensions for each, I think we should
 have a way to pass arbitrary attributes alon with the boot
 API call, that a driver would handle in much  the same way as
 they do for glance image properties. Basically think of it as
 a way to custom any image property per instance created.

 Personally, I think having a bunch of special case magic namespaces
 (even if documented) is less desirable than a proper API to do something
 like this. Especially a namespace that someone else could potentially
 use legitimately that would conflict.

 To me, this feels a lot like what I'm worried this effort will turn
 into, which is making containers support in Nova look like a bolt-on
 thing with a bunch of specialness required to make it behave.

 Anyone remember this bolt-on gem?

 nova boot --block-device-mapping
 vda=965453c9-02b5-4d5b-8ec0-3164a89bf6f4:::0 --flavor=m1.tiny
 --image=6415797a-7c03-45fe-b490-f9af99d2bae0 BFV

 I found that one amidst hundreds of forum threads of people confused
 about what incantation of magic they were supposed to do to make it
 actually boot from volume.

 Just MHO.

 --Dan


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Mark McLoughlin

On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:
 Mark McLoughlin wrote:
  How about if we had an emerging projects page where the TC feedback on
  each project would be listed?
  
  That would give visibility to our feedback, without making it a yes/no
  blessing. Ok, whether to list any feedback about the project on the page
  is a yes/no decision, but at least it allows us to fully express why we
  find the project promising, what people need to help with in order for
  it to be incubated, etc.
  
  With a formal yes/no status, I think we'd struggle with projects which
  we're not quite ready to even bless with an emerging status but we
  still want to encourage them - this allows us to bless a project as
  emerging but be explicit about our level of support for it.
 
 I agree that being able to express our opinion on a project in shades of
 grey is valuable... The main drawback of using a non-boolean status for
 that is that you can't grant any benefit to it. So we'd not be able to
 say emerging projects get design summit space.
 
 They can still collaborate in unconference space or around empty tables,
 but then we are back to the problem we are trying to solve: increase
 visibility of promising projects pre-incubation.

Have an emerging projects track and leave it up to the track coordinator
to decide prioritize the most interesting sessions and the most advanced
projects (according to the TC's feedback)  ?

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Docker] Environment variables

2013-12-17 Thread Daniel P. Berrange

On Mon, Dec 16, 2013 at 01:04:33PM -0800, Dan Smith wrote:
  eg use a 'env_' prefix for glance image attributes
  
  We've got a couple of cases now where we want to overrides these
  same things on a per-instance basis. Kernel command line args
  is one other example. Other hardware overrides like disk/net device
  types are another possibility
  
  Rather than invent new extensions for each, I think we should
  have a way to pass arbitrary attributes alon with the boot
  API call, that a driver would handle in much  the same way as
  they do for glance image properties. Basically think of it as
  a way to custom any image property per instance created.
 
 Personally, I think having a bunch of special case magic namespaces
 (even if documented) is less desirable than a proper API to do something
 like this. Especially a namespace that someone else could potentially
 use legitimately that would conflict.
 
 To me, this feels a lot like what I'm worried this effort will turn
 into, which is making containers support in Nova look like a bolt-on
 thing with a bunch of specialness required to make it behave.

NB I'm not saying that everything related to containers should be done
with metadata properties. I just feel that this is appropriate for
setting of environment variables and some other things like kernel
command line args, since it gives a consistent approach to use for
setting those per-image vs per-instance.

 Anyone remember this bolt-on gem?
 
 nova boot --block-device-mapping
 vda=965453c9-02b5-4d5b-8ec0-3164a89bf6f4:::0 --flavor=m1.tiny
 --image=6415797a-7c03-45fe-b490-f9af99d2bae0 BFV
 
 I found that one amidst hundreds of forum threads of people confused
 about what incantation of magic they were supposed to do to make it
 actually boot from volume.

Everything about the way you use block device mapping is plain
awful - even the bits that were done as proper API extensions.
I don't think the design failures there apply in this case.

If we do env variables as metadata properties, then you may well
not end up even needing to pass them to 'nova boot' in the common
case, since it'll likely be sufficient to have them just set against
the image in glance most of the time.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: implementing olso.messaging over amqp 1.0


On 16/12/13 10:37 +, Gordon Sim wrote:

On 12/12/2013 02:14 PM, Flavio Percoco wrote:

I've a draft in my head of how the amqp 1.0 driver could be
implemented and how to map the current expectations of the messaging
layer to the new protocol.

I think a separate thread to discuss this mapping is worth it. There
are some critical areas that definitely need more discussion


I have also been looking at this, and trying to write up a simple 
design notes. Some of the questions that occurred to me while doing so 
are:


* Use one link for all sends, with 'to' field set, or use a link for 
each target?


I like this proposal. It keeps messages atomic and isolated from the
rest of the environment. The only I can think OTO is: What happens if
the node that the reply should go to dies before the reply is sent?

Is this something we should be worrying about? I mean, if the node
that was waiting for the response dies, I think we'd have bigger
problems than just a 'missed response' :D. However, this doesn't mean
we couldn't take care of that.


* How to handle calls to one of a group of servers?


Could you elaborate more what issues you see around this?



* Use a distinct response address per request, or allow an address to 
be shared by multiple requests in conjunction with correlation id on 
responses?


mmh, this is an interesting one. Using a distinct address for
responses will make the implementation less error prone. However, I
don't really think we need to have different addresses since there's
already a way to distinguish multiple requests. So, I'd prefer the
later.



* Support both intermediated and direct communication? For all patterns?


Besides fanout, I'd say yes. We need to support intermediated and
direct communication.

The aim in my view should be to have the driver support as many 
alternatives in deployment as possible without overcomplicating 
things, distorting the mapping or introducing server specific 
extensions.


I have some notes to share if anyone is interested. I can send them to 
this list or put them upon the wiki or an etherpad or something.


I think this questions are worth raising - thanks for that - and I
agree with you about not overcomplicating things. I think we could
start working something out and then we'll face different issues that
we'll need to discuss further on this list.

Cheers,
FF

--
@flaper87
Flavio Percoco


pgpBLyKwg2WLL.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Thierry Carrez

Mark McLoughlin wrote:
 On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:
 Mark McLoughlin wrote:
 How about if we had an emerging projects page where the TC feedback on
 each project would be listed?

 That would give visibility to our feedback, without making it a yes/no
 blessing. Ok, whether to list any feedback about the project on the page
 is a yes/no decision, but at least it allows us to fully express why we
 find the project promising, what people need to help with in order for
 it to be incubated, etc.

 With a formal yes/no status, I think we'd struggle with projects which
 we're not quite ready to even bless with an emerging status but we
 still want to encourage them - this allows us to bless a project as
 emerging but be explicit about our level of support for it.

 I agree that being able to express our opinion on a project in shades of
 grey is valuable... The main drawback of using a non-boolean status for
 that is that you can't grant any benefit to it. So we'd not be able to
 say emerging projects get design summit space.

 They can still collaborate in unconference space or around empty tables,
 but then we are back to the problem we are trying to solve: increase
 visibility of promising projects pre-incubation.
 
 Have an emerging projects track and leave it up to the track coordinator
 to decide prioritize the most interesting sessions and the most advanced
 projects (according to the TC's feedback)  ?

I guess that /could/ work. I don't expect we'll have space for more than
one session per project, but that may be enough for self-organization if
we nail the collaboration spaces correctly.

I'm fine with giving that page a try (we can always revisit if it's not
working any better...).

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

2013-12-17 Thread Kyle Mestery

On Dec 16, 2013, at 11:17 PM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
 Added openstack-dev
 
 On Mon, Dec 16, 2013 at 11:34:05PM +0100,
 Erik Moe emoe...@gmail.com wrote:
 
 Hi,
 
 I have added a new document to the launchpad. Document should now be more
 in line with what we discussed at the Icehouse summit.
 
 https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
 
 Doc:
 https://docs.google.com/document/d/1lDJ31-XqkjjWC-IBq-_wV1KVhi7DzPkKYlCxTIPs_9U/edit?usp=sharing
 
 You are very welcome to give feedback if this is the solution you had in
 mind.
 
 The document is view-only. So I commented below.
 
 - 2 Modeling proposal
  What's the purpose of trunk network?
  Can you please add a use case that trunk network can't be optimized away?
 
IMHO, the trunk network is one which carries VLAN tagged traffic. However,
I'm wondering if this is explicitly needed or not as well.

Thanks,
Kyle

 - 4 IP address management
  nitpick
  Can you please clarify what the L2 gateway ports in section 2
  modeling proposal, figure 1?
 
 - Table 3
  Will this be same to l2-gateway one?
  https://blueprints.launchpad.net/neutron/+spec/l2-gateway
 
 - Figure 5
  What's the purpose of br-int local VID?
  VID can be directly converted from br-eth1 VID to VM VID untagged.




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation


On 17/12/13 11:54 +0100, Jaromir Coufal wrote:

On 2013/16/12 15:19, Flavio Percoco wrote:

1. Programs that are not part of OpenStack's release cycle shouldn't
be considered official nor they should have the rights that integrated
projects have.
I don't agree on this point. There might be supportive teams, which 
are helping OpenStack in general (like UX) and they are not exactly 
part of release cycles. Why should this team and effort be excluded 
from official recognition?


They do receive recognition. Infrastructure, Documentation, Release
Management. Those are programs that don't have actual projects but are
critical for OpenStack's releases.

It's a matter of just labeling the program as official. My point there
is about Programs that just have a non integrated project under their
umbrella.

Cheers,
FF




-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgpDtBQm5Kxs5.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation


On 17/12/13 14:59 +0100, Thierry Carrez wrote:

Mark McLoughlin wrote:

On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:

Mark McLoughlin wrote:

How about if we had an emerging projects page where the TC feedback on
each project would be listed?

That would give visibility to our feedback, without making it a yes/no
blessing. Ok, whether to list any feedback about the project on the page
is a yes/no decision, but at least it allows us to fully express why we
find the project promising, what people need to help with in order for
it to be incubated, etc.

With a formal yes/no status, I think we'd struggle with projects which
we're not quite ready to even bless with an emerging status but we
still want to encourage them - this allows us to bless a project as
emerging but be explicit about our level of support for it.


I agree that being able to express our opinion on a project in shades of
grey is valuable... The main drawback of using a non-boolean status for
that is that you can't grant any benefit to it. So we'd not be able to
say emerging projects get design summit space.

They can still collaborate in unconference space or around empty tables,
but then we are back to the problem we are trying to solve: increase
visibility of promising projects pre-incubation.


Have an emerging projects track and leave it up to the track coordinator
to decide prioritize the most interesting sessions and the most advanced
projects (according to the TC's feedback)  ?


I guess that /could/ work. I don't expect we'll have space for more than
one session per project, but that may be enough for self-organization if
we nail the collaboration spaces correctly.

I'm fine with giving that page a try (we can always revisit if it's not
working any better...).



I'm not sure about the page as a medium for this but I like the idea.
This is pretty much a way to incubate programs, which is basically
what I proposed in my previous emails. Lets not consider Programs
official right away, lets give them a place where they can grow a bit
with the projects the have under their umbrella. Lets also - as Mark
suggested - use that place to add comments and help them grow.

And I'm also in favor of having a emerging projects track. +1

Cheers,
FF


--
@flaper87
Flavio Percoco


pgpdDFeX8C356.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

2013-12-17 Thread Erik Moe

Hi,

thanks for your comments.

see answers below.

Thanks,
Erik


On Tue, Dec 17, 2013 at 6:17 AM, Isaku Yamahata isaku.yamah...@gmail.comwrote:

 Added openstack-dev

 The document is view-only. So I commented below.

 - 2 Modeling proposal
   What's the purpose of trunk network?
   Can you please add a use case that trunk network can't be optimized away?


In some use cases the trunk network will trunk all VLANS from a VM, so they
can for example be 'tunneled' to another VM or externally. In the use case
where a VM wants to connect to multiple Neutron networks, the trunk network
is a logical connection between the VM trunk port and the L2-gateways. From
my point of view it looks a little strange for this use case, but I think
this is what we said during our meeting in Hong Kong (Unless I
misunderstood something...).

I added use case where two VMs are connected through a trunk network. This
can not be optimized away. The network would have to be able to trunk all
VLANs between the VMs.



 - 4 IP address management
   nitpick
   Can you please clarify what the L2 gateway ports in section 2
   modeling proposal, figure 1?


I have now tried to clarify this more.


 - Table 3
   Will this be same to l2-gateway one?
   https://blueprints.launchpad.net/neutron/+spec/l2-gateway


I will try to align to this and maybe other proposals as much as possible.
Just wanted to have some feedback before I do too many assumptions.


 - Figure 5
   What's the purpose of br-int local VID?
   VID can be directly converted from br-eth1 VID to VM VID untagged.


Unless something has changed, all vNICs handled by OVS-agent are connected
to br-int. br-int has a local VID for separating traffic. br-int is
connected to one or more other bridges representing one or more physical
networks. The br-int VID is mapped to a per bridge VID, so two separate
Neutron networks could have the same VID on two different physical networks.




 --
 Isaku Yamahata isaku.yamah...@gmail.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: implementing olso.messaging over amqp 1.0


On 17/12/13 14:22 +, Gordon Sim wrote:

On 12/17/2013 01:53 PM, Flavio Percoco wrote:

On 16/12/13 10:37 +, Gordon Sim wrote:

On 12/12/2013 02:14 PM, Flavio Percoco wrote:

I've a draft in my head of how the amqp 1.0 driver could be
implemented and how to map the current expectations of the messaging
layer to the new protocol.

I think a separate thread to discuss this mapping is worth it. There
are some critical areas that definitely need more discussion


I have also been looking at this, and trying to write up a simple
design notes. Some of the questions that occurred to me while doing so
are:

* Use one link for all sends, with 'to' field set, or use a link for
each target?


I like this proposal. It keeps messages atomic and isolated from the
rest of the environment. The only I can think OTO is: What happens if
the node that the reply should go to dies before the reply is sent?

Is this something we should be worrying about? I mean, if the node
that was waiting for the response dies, I think we'd have bigger
problems than just a 'missed response' :D. However, this doesn't mean
we couldn't take care of that.


I'm afraid I'm not following you here. To clarify the original point, 
in AMQP 1.0 all messages are sent over a sending link (this is like a 
subscription, but for senders). You can also set an address 
per-message. However my view is that using a link per target is more 
interoperable at present. The spec doesn't really require the routing 
of messages by 'to' field and consequently not all implementations 
support it.


The point you are making seems to be around reliability(?). I would 
like to see some definitive statement about expectations in that 
regard for the API users and for transport implementers, but I think 
its a separate issue from whether or not to use a single link. 
(Perhaps the term 'link' is overloaded here, causing the confusion. In 
AMQP 1.0 a link is something like a subscription, but its a symmetric 
concept so also covers sending of messages).


I'm sorry, it was indeed a bit confusing. What I'm referring to, which
I think is related to the above issue, is that the 'reply-to' field
needs to be sent either way. My question was indeed more related to
reliability and as you mentioned it needs to be clarified a bit
further.

I'm sorry for hijacking your question. :)

Cheers,
FF

--
@flaper87
Flavio Percoco


pgpg9CkfV5cS4.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge

2013-12-17 Thread Miller, Mark M (EB SW Cloud - RD - Corvallis)


On 2013/17/12 11:04, Ladislav Smola wrote:

Horizoners,

As an alternative merge option, we could merge directly to Horizon code
base. After some conversation, we have realized that it is possible to
mix codebase of incubated and integrated projects, as Trove showed us.
Contrary to what was said in the last meeting, we do not require any
special treatment for the infrastructure tab and we will continue the
development of the infrastructure tab with the same rules as the rest of
the Horizon. Especially, we want to keep culture of cross company
reviewers, so that we make sure that TripleO/Tuskar UI is not only in
hands of one company. It is important to mention that there will be more
code to keep eyes on but we believe that us helping more with reviews in
Horizon will give more time for reviews in TripleO/Tuskar UI.

This is proposed Roadmap:

1. Before meeting 16.12.2013, send email about the merge.
2. Immediate steps after the meeting (days and weeks)
- Merge of the Tuskar-UI core team to Horizon core team. Namely:
jtomasek, lsmola, jomara, tzumainn (a point of discussion)
- Tuskar will add a third panel, named infrastructure.
- Tuskar will be disabled by default in Horizon.
- Break tuskar-ui in smaller pieces, submit them individually as patches
directly for horizon.
3. Long-term steps after the meeting (weeks and months)
- Synchronize coding style and policies.
- Transfer blueprints and bugs to horizon launchpad with 'tuskar-' prefix.
- Continue development under in Horizon codebase. Infrastructure tab
will have some tabs implemented with mock data, until the underlying
libraries are finished (Tuskar is depending on several apis, like nova,
heat, triple-o, ironic.). It will get to stable state in I3 (we need to
develop in parralel with API's to meet the I3 deadline)
- Transfer Documentation.

The benefits of this was already pointed out by mrunge.

We have a detailed plan of features for I2 and I3, put together by the
tripleo community, those will be captured as blueprints and presented on
Horizon meetings.

If you have any questions, please ask!

Thanks,
Tuskar UI team


Just one small note here:

TripleO/Tuskar UI's goal is to deliver working slick installer for 
Icehouse. Which means lot of work and lot of code will need to get in as 
fast as possible. In other words we need to develop rapidly.


I think what we will need to discuss on today's meeting is the way how 
reviews in Horizon might look like after the merger. What things should 
get priority, how to assure cross-company culture, etc.


I believe there won't be big issues, we just need to clarify all that 
stuff and make sure that we can fulfill all UI goals - Horizon's and 
TripleO/Tuskar's.


Cheers
-- Jarda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] Terminology

2013-12-17 Thread Tzu-Mainn Chen

 On 2013/13/12 23:11, Jordan OMara wrote:
  On 13/12/13 16:20 +1300, Robert Collins wrote:
  However, on instance - 'instance' is a very well defined term in Nova
  and thus OpenStack: Nova boot gets you an instance, nova delete gets
  rid of an instance, nova rebuild recreates it, etc. Instances run
  [virtual|baremetal] machines managed by a hypervisor. So
  nova-scheduler is not ever going to be confused with instance in the
  OpenStack space IMO. But it brings up a broader question, which is -
  what should we do when terms that are well defined in OpenStack - like
  Node, Instance, Flavor - are not so well defined for new users? We
  could use different terms, but that may confuse 'stackers, and will
  mean that our UI needs it's own dedicated terminology to map back to
  e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as
  a principle, where there is a well defined OpenStack concept, that we
  use it, even if it is not ideal, because the consistency will be
  valuable.
 
  I think this is a really important point. I think the consistency is a
  powerful tool for teaching new users how they should expect
  tripleo/tuskar to work and should lessen the learning curve, as long
  they've used openstack before.
 I don't 100% agree here. Yes it is important for user to keep
 consistency in naming - but as long as he is working within the same
 domain. Problem is that our TripleO/Tuskar UI user is very different
 from OpenStack UI user. They are operators, and they might be very often
 used to different terminology - globally used and known in their field
 (for example Flavor is very OpenStack specific term, they might better
 see HW profile, or similar).
 
 I think that mixing these terms in overcloud and undercloud might lead
 to problems and users' confusion. They already are confused about the
 whole 'over/under cloud' stuff. They are not working with this approach
 daily as we are. They care about deploying OpenStack, not about how it
 works under the hood. Bringing another more complicated level of
 terminology (explaining what is and belongs to under/overcloud) will
 increase the confusion here.
 
 For developers, it might be easier to deal with the same terms as
 OpenStack already have or what is used in the background to make that
 happen. But for user - it will be confusing going to
 infrastructure/hardware management part and see the very same terms.
 
 Therefor I incline more to broadly accepted general terminology and not
 reusing OpenSTack terms (at least in the UI).
 
 -- Jarda

I think you're correct with respect to the end-user, and I can see the argument
for terminology changes at the view level; it is important not to confuse the
end-user.

But at the level where developers are working with OpenStack APIs, I think it's
important not to confuse the developers and reviewers, and that's most easily 
done
by sticking with established OpenStack terminology.


Mainn

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] weekly meeting

2013-12-17 Thread Eric Harney

I also like the idea of alternating each week.

Eric

On 12/17/2013 01:40 AM, Mike Perez wrote:
 I agree with Qin here that alternating might be a good option. I'm not
 opposed to being present to both meetings though.
 
 -Mike Perez
 
 
 On Mon, Dec 16, 2013 at 9:31 PM, Qin Zhao chaoc...@gmail.com wrote:
 
 Hi John,

 Yes, alternating the time for each week should be fine.  I just change my
 gmail name to English... I think you can see my name now...


  On Tue, Dec 17, 2013 at 12:05 PM, John Griffith 
 john.griff...@solidfire.com wrote:

 On Mon, Dec 16, 2013 at 8:57 PM, 赵钦 chaoc...@gmail.com wrote:
 Hi John,

 I think the current meeting schedule, UTC 16:00, basically works for
 China
 TZ (12AM), although it is not perfect. If we need to reschedule, I
 think UTC
 05:00 is better than UTC 04:00, since UTC 04:00 (China 12PM) is our
 lunch
 time.


 On Tue, Dec 17, 2013 at 11:04 AM, John Griffith
 john.griff...@solidfire.com wrote:

 Hi All,

 Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
 some interest in either changing the weekly Cinder meeting time, or
 proposing a second meeting to accomodate folks in other time-zones.

 A large number of folks are already in time-zones that are not
 friendly to our current meeting time.  I'm wondering if there is
 enough of an interest to move the meeting time from 16:00 UTC on
 Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
 willing to look at either moving the meeting for a trial period or
 holding a second meeting to make sure folks in other TZ's had a chance
 to be heard.

 Let me know your thoughts, if there are folks out there that feel
 unable to attend due to TZ conflicts and we can see what we might be
 able to do.

 Thanks,
 John

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Hi Chaochin,

 Thanks for the feedback, I think the alternate time would have to be
 moved up an hour or two anyway (between the lunch hour in your TZ and
 the fact that it just moves the problem of being at midnight to the
 folks in US Eastern TZ).  Also, I think if there is interest that a
 better solution might be to implement something like the Ceilometer
 team does and alternate the time each week.

 John

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Qin Zhao

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Xuhan Peng

I think slaac was original excluded to make --enable-ra not specified when
only slaac is given to an subnet's dhcp mode.

However, when I checked the example conf file of dnsmasq:

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example

enable-ra is explained as:

# Do router advertisements for all subnets where we're doing DHCPv6
# Unless overriden by ra-stateless, ra-names, et al, the router
# advertisements will have the M and O bits set, so that the clients
# get addresses and configuration from DHCPv6, and the A bit reset, so the
# clients don't use SLAAC addresses.
#enable-ra

are we using --enable-ra and ra-stateless, ra-names at the same time correctly?



On Tue, Dec 17, 2013 at 8:27 PM, Shixiong Shang 
sparkofwisdom.cl...@gmail.com wrote:

 Hi, guys:

 I am reading the code in “constants.py” file as part of Change I5b2313ff:
 Create a new attribute for subnets, to store v6 dhcp options”. One thing
 captured my eyes is the definition of “RA_MODES”, which excluded “slaac”
 mode. If my understanding of “RA_MODES” is correct, i.e. the modes leverage
 RA, then “slaac” mode should be included. Am I correct?

 Thanks!

 Shixiong







 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-17 Thread Dmitry Mescheryakov

Folks,

The discussion didn't result in a consensus, but it did revealed a great
number of things to be accounted. I've tried to summarize top-level points
in the etherpad [1]. It lists only items everyone (as it seems to me)
agrees on, or suggested options where there was no consensus. Let me know
if i misunderstood or missed something. The etherpad does not list
advantages/disadvantages of options, otherwise it just would be too long.
Interested people might search the thread for the arguments :-) .

I've thought it over and I agree with people saying we need to move
further. Savanna needs the agent and I am going to write a PoC for it. Sure
the PoC will be implemented in project-independent way. I still think that
Salt limitations overweight its advantages, so the PoC will be done on top
of oslo.messaging without Salt. At least we'll have an example on how it
might look.

Most probably I will have more questions in the process, for instance we
didn't finish discussion on enabling networking for the agent yet. In that
case I will start a new, more specific thread in the list.

Thanks,

Dmitry

[1] https://etherpad.openstack.org/p/UnifiedGuestAgent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Enhance UX of Launch Instance Form

2013-12-17 Thread Gabriel pettier

I've been working on this blueprint's implementation, the first bullet 
point has been implemented by the two following Gerrit reviews:

https://review.openstack.org/#/c/61754/3

and

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

The first one is simply there to allow for any modal view to declare 
itself as fullscreen, and provide style for the modal to take screen 
space relative to the buffer size.

The second one makes use of this feature for the LaunchInstance 
Workflow, and changes the step template to use responsive elements 
instead of a table.

This doesn't touch the content of the steps at all, only the 
size/responsiveness of the whole popup UI.

Feedbacks about the blueprint are of course still welcome, as well as 
feedback for the implementation.

This video shows the state of the popup after the two patchsets.

http://youtu.be/0b9aqtH0dSI

On Tue, Dec 03, 2013 at 07:44:12PM +0100, Gabriel pettier wrote:
 (Previous mail went out a bit fast)
 
 These features could be developed iteratively to improve upon the 
 existing code base:
  - First allow the modal view system to expand for better usage of screen 
real-estate combined with responsiveness of the whole popin
  - Then rework existing menus to simplify user flow:
- ephemeral/persistent switch
- images/flavors choice list instead of combobox
 
 I saw work had been started for the wizard-navigation in [1]
 
 As for implementation details we obviously need to discuss them, for exemple 
 as
 there have been a recent addition of AngularJS, should we use it for the view
 implementation?
 
 Feedback/directions?
 
 [1] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow/  
  
 On Tue, Dec 03, 2013 at 05:49:29PM +0100, Gabriel pettier wrote:
  Hi there
  
  I read the proposal and related documentation, and intend to start 
  implementing it into horizon.
  
  Regards
  
  on Wed Nov 20 15:09:05 UTC 2013 C?dric Soulas Wrote
  
  
  Thanks for all the feedback on the Enhance UX of launch instance form 
  subject and its prototype.
  
  Try the latest version of the prototype:
  http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance
  
  This update was made after several discussion on those different channels:
  
  - openstack ux google group
  - launchpad horizon (and now launchpad openstack ux)
  - mailing list and IRC
  - the new ask bots for openstack UX
  
  We tried to write back most of discussions on ask bot, and are now 
  focusing on this tool.
  
  Below a digest of those discussions, with links to ask bot (on each 
  subject, there are links to related blueprints, google doc drafts, etc)
  
  = General topics =
  
  - Modals and supporting different screen sizes [2]
Current modal doesn't work well on the top 8 screen resolutions [2]
= Responsive and full screen modal added on the prototype [1]
  
  - Wizard mode for some modals [3]
= try the wizard [1]
  
  = Specific to launch instance =
  
  - Improve boot source options [4]
* first choose to boot from ephemeral or persistent disk
* if no ephemeral flavor are available, hide the selector
* group by public, project, shared with me
* warning message added for delete on terminate option (when boot from 
   persistent)
  
  - Scaling the flavor list [5]
* sort the columns of the table. In particular: by name.
* group of flavor list (for example: performance, standard...)?
  
  - Scaling the image list [5]
* a scrollbar on the image list
* limit the number of list items and add a x more instance snapshots - 
   See more line
* a search / filter feature would be great, like discussed at the 
   scaling horizon design session
  
  - Step 1 / Step 2 workflow: when the user click on select from one boot 
  source item it goes directly to the step 2.
If it goes back from step 2 to step 1:
* the text Please select a boot source would be replaced with a Next 
   button
* the button select on the selected boot source item would be replaced 
   with a check-mark (or equivalent).
* the user would still have the possibility to select another boot source
  
  - flavor depending on image requirements and quotas available: 
 * this a very good point, lot of things to discuss about
 = should open a separate thread on this
   
  - Network: still a work in progress
* if a single choice: then make it default choice
  
  - Several wording updates (cancel, ephemeral boot source, ...)
  
  [1] 
  http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance
  [2] 
  http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/
  [3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow
  [4] 
  http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/
  [5] 
  http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/
  
  Best,
  
  Cédric
  
Oct 11

[openstack-dev] [testr] debugging failing testr runs

2013-12-17 Thread Chmouel Boudjnah

Hello,

I was wondering what was the strategy to debug a failed run with tox?

I was trying to see which tests was failing with python-keystoneclient and
py33 and this is the type of error i am getting :

http://paste.openstack.org/show/gc3xMk34ELuSF5Fk1mvP/

(bet it with tox directly or from the virtualenv).

I have to resort to nose to get the proper error :

http://pastie.org/pastes/8558525/text?key=o4hljmbmsakrekbzqvrfug

do you know how to get the same output with testr than the above paste?

Thanks,
Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-17 Thread Thomas Herve


 The discussion didn't result in a consensus, but it did revealed a great
 number of things to be accounted. I've tried to summarize top-level points
 in the etherpad [1]. It lists only items everyone (as it seems to me) agrees
 on, or suggested options where there was no consensus. Let me know if i
 misunderstood or missed something. The etherpad does not list
 advantages/disadvantages of options, otherwise it just would be too long.
 Interested people might search the thread for the arguments :-) .
 
 I've thought it over and I agree with people saying we need to move further.
 Savanna needs the agent and I am going to write a PoC for it. Sure the PoC
 will be implemented in project-independent way. I still think that Salt
 limitations overweight its advantages, so the PoC will be done on top of
 oslo.messaging without Salt. At least we'll have an example on how it might
 look.
 
 Most probably I will have more questions in the process, for instance we
 didn't finish discussion on enabling networking for the agent yet. In that
 case I will start a new, more specific thread in the list.

Hi Dimitri,

While I agree that using Salt's transport may be wrong for us, the module 
system they have is really interesting, and a pretty big ecosystem already. It 
solved things like system-specific information, and it has a simple internal 
API to create modules. Redoing something from scratch Openstack-specific sounds 
like a mistake to me. As Salt seems to be able to work in a standalone mode, I 
think it'd be interesting to investigate that.

Maybe it's worth separating the discussion between how to deliver messages to 
the servers (oslo.messaging, Marconi, etc), and what to do on the servers 
(where I think Salt is a great contender).

-- 
Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] weekly meeting

2013-12-17 Thread Jay S Bryant

John,

I am flexible. 

I am fine with trying to move the time to 04:00 or 05:00 UTC or we can 
alternate.  The one concern with alternation is that it may lead to 
confusion and less attendance, but I am certainly open to trying it.


Jay S. Bryant
   IBM Cinder Subject Matter ExpertCinder Core Member
  
Department 7YLA, Building 015-2, Office E125, Rochester, MN
Telephone: (507) 253-4270, FAX (507) 253-6410
TIE Line: 553-4270
E-Mail:  jsbry...@us.ibm.com

 All the world's a stage and most of us are desperately unrehearsed.
   -- Sean O'Casey




From:   John Griffith john.griff...@solidfire.com
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org, 
Date:   12/16/2013 09:09 PM
Subject:[openstack-dev] [cinder] weekly meeting



Hi All,

Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
some interest in either changing the weekly Cinder meeting time, or
proposing a second meeting to accomodate folks in other time-zones.

A large number of folks are already in time-zones that are not
friendly to our current meeting time.  I'm wondering if there is
enough of an interest to move the meeting time from 16:00 UTC on
Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
willing to look at either moving the meeting for a trial period or
holding a second meeting to make sure folks in other TZ's had a chance
to be heard.

Let me know your thoughts, if there are folks out there that feel
unable to attend due to TZ conflicts and we can see what we might be
able to do.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] weekly meeting

2013-12-17 Thread Walter A. Boring IV


4 or 5 UTC works better for me.   I can't attend the current meeting
time, due to taking my kids to school in the morning at 1620UTC

Walt

Hi All,

Prompted by a recent suggestion from Tom Fifield, I thought I'd gauge
some interest in either changing the weekly Cinder meeting time, or
proposing a second meeting to accomodate folks in other time-zones.

A large number of folks are already in time-zones that are not
friendly to our current meeting time.  I'm wondering if there is
enough of an interest to move the meeting time from 16:00 UTC on
Wednesdays, to 04:00 or 05:00 UTC?  Depending on the interest I'd be
willing to look at either moving the meeting for a trial period or
holding a second meeting to make sure folks in other TZ's had a chance
to be heard.

Let me know your thoughts, if there are folks out there that feel
unable to attend due to TZ conflicts and we can see what we might be
able to do.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge

2013-12-17 Thread Jay Pipes


On 12/17/2013 03:04 AM, Thomas Goirand wrote:

On 12/16/2013 10:32 PM, Jaromir Coufal wrote:


This is important note. From information architecture and user
interaction point of view, I don't think it makes sense to keep all the
three tabs visible together (Project, Admin, Infrastructure). There are
lot of reasons, but main points:

* Infrastructure itself is undercloud concept running in different
instance of Horizon.

* Users dealing with deployment and infrastructure management are not
the users of OpenStack UI / Dashboard. It is different set of users. So
it doesn't make sense to have giant application, which provides each and
every possible feature. I think we need to keep focused.

So by default, I would say that there should exist Project + Admin tab
together or Infrastructure. But never all three together. So when
Matthias say 'disabled by default', I would mean completely hidden for
user and if user wants to use Infrastructure management, he can enable
it in different horizon instance, but it will be the only visible tab
for him. So it will be sort of separate application, but still running
on top of Horizon.

-- Jarda


I think the disabled by default approach is the wrong one. Instead, we
should have some users with enough credentials that will have the
feature, and others will not.

Also, Horizon is a web interface. Most of its switches could be made
directly in the web interface, with the values stored in a db. That'd be
so much nicer than stored in localsettings.py which starts, as time
passes, to become overly complicated and ugly (it should, by the way, be
a configuration file, not a python script: you can't expect
administrators to understand python, but you do expect them to
understand how to write in a .ini file).


Welcome to Django. This isn't going to change any time soon :)

Best,
-jay


Also, it seems we have a consensus, when is it expected to happen? For
Icehouse b2 maybe?

Just my 2 cents,

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][VMware] Deploy from vCenter template

2013-12-17 Thread Arnaud Legendre

Hi Qui Xing, 

We are planning to address the vCenter template issue by levering the OVF/OVA 
capabilities. 
Kiran's implementation is tied to a specific VC and requires to add Glance 
properties that are not generic. 
For existing templates, the workflow will be: 
. generate an *.ova tarball (containing the *.ovf descriptor + *.vmdk 
stream-optimized) out of the template, 
. register the *.ova as a Glance image location (using the VMware Glance driver 
see bp [1]) or simply upload the *.ova to another Glance store, 
. The VMware driver in Nova will be able to consume the *.ova (either through 
the location or by downloading the content to the cache): see bp [2]. However, 
for Icehouse, we are not planning to actually consume the *.ovf descriptor 
(work scheduled for the J/K release). 

[1] 
https://blueprints.launchpad.net/glance/+spec/vmware-datastore-storage-backend 
[2] https://blueprints.launchpad.net/nova/+spec/vmware-driver-ova-support 

If you have questions about [1], please send me an email. For [2], please reach 
vuil. 


Thanks, 
Arnaud 

- Original Message -

From: Shawn Hartsock harts...@acm.org 
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org 
Sent: Monday, December 16, 2013 9:37:34 AM 
Subject: Re: [openstack-dev] [Nova][VMware] Deploy from vCenter template 

IIRC someone who shows up at 
https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Meetings is planning on 
working on that again for Icehouse-3 but there's some new debate on the best 
way to implement the desired effect. The goal of that change would be to avoid 
streaming the disk image out of vCenter for the purpose of then streaming the 
same image back into the same vCenter. That's really inefficient. 

So there's a Nova level change that could happen (that's the patch you saw) and 
there's a Glance level change that could happen, and there's a combination of 
both approaches that could happen. 

If you want to discuss it informally with the group that's looking into the 
problem I could probably make sure you end up talking to the right people on 
#openstack-vmware or if you pop into the weekly team meeting on IRC you could 
mention it during open discussion time. 


On Mon, Dec 16, 2013 at 3:27 AM, Qing Xin Meng  mengq...@cn.ibm.com  wrote: 





I saw a commit for Deploying from VMware vCenter template and found it's 
abandoned. 
https://review.openstack.org/#/c/34903 

Anyone knows the plan to support the deployment from VMware vCenter template? 


Thanks! 



Best Regards 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 







-- 
# Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=KCBtvBVSZCslDQrTvSEqBcTEcx%2FSKxtF0ZRIjtTFmSw%3D%0As=f45fbe293564be6a16c90b0125534e5e62f7505fea9f92708b72aa60e5e1dc5f
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Shixiong Shang

Yes, the man page is a little bit confusing. The “slaac” mode requires 
“—enable-ra” since it needs to manipulate MOAL bits in the RA. As matter of 
fact, all of the modes available for IPv6 rely on “—enable-ra”.

My understanding is, the ra-names option has nothing to do with RA. It resolves 
the problem of where to find DNS server. It should work with slaac mode or 
ra-stateless mode.

Shixiong


On Dec 17, 2013, at 10:52 AM, Xuhan Peng pengxu...@gmail.com wrote:

 I think slaac was original excluded to make --enable-ra not specified when 
 only slaac is given to an subnet's dhcp mode. 
 
 However, when I checked the example conf file of dnsmasq:
 
 http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example
 
 enable-ra is explained as:
 # Do router advertisements for all subnets where we're doing DHCPv6
 # Unless overriden by ra-stateless, ra-names, et al, the router 
 # advertisements will have the M and O bits set, so that the clients
 # get addresses and configuration from DHCPv6, and the A bit reset, so the 
 # clients don't use SLAAC addresses.
 #enable-ra
 
 are we using --enable-ra and ra-stateless, ra-names at the same time 
 correctly?
 
 
 On Tue, Dec 17, 2013 at 8:27 PM, Shixiong Shang 
 sparkofwisdom.cl...@gmail.com wrote:
 Hi, guys:
 
 I am reading the code in “constants.py” file as part of Change I5b2313ff: 
 Create a new attribute for subnets, to store v6 dhcp options”. One thing 
 captured my eyes is the definition of “RA_MODES”, which excluded “slaac” 
 mode. If my understanding of “RA_MODES” is correct, i.e. the modes leverage 
 RA, then “slaac” mode should be included. Am I correct?
 
 Thanks!
 
 Shixiong
 
 
 
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Support for Pecan in Nova

2013-12-17 Thread Ryan Petrello

So any additional feedback on this patch?  I’d love to start working on porting 
some of the other extensions to pecan, but want to make sure I’ve got approval 
on this approach first.

https://review.openstack.org/#/c/61303/7

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

On Dec 14, 2013, at 10:45 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote:

 
 
 
 On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh cbky...@gmail.com wrote:
 
 On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann doug.hellm...@dreamhost.com 
 wrote:
 That covers routes. What about the properties of the inputs and outputs?
 
 
 I think the best way for me to describe it is that as the V3 API core and all 
 the extensions
 are written, both the routes and input and output parameters are from a 
 client's perspective fixed at application
 startup time. Its not an inherent restriction of the framework (an extension 
 could for
 example dynamically load another extension at runtime if it really wanted 
 to), but we just don't do that.
 
 OK, good.
 
  
 
 Note that values of parameters returned can be changed by an extension 
 though. For example os-hide-server-addresses
 can based on a runtime policy check and the vm_state of the server, filter 
 whether the values in the 
 addresses field are filtered out or not when returning information about a 
 server. This isn't a new thing in the
 V3 API though, it already existed in the V2 API.
 
 OK, it seems like as long as the fields are still present that makes the API 
 at least consistent for a given deployment's configuration.
 
 Doug
 
  
 
 Chris
  
 
 On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello ryan.petre...@dreamhost.com 
 wrote:
 Unless there’s some other trickiness going on that I’m unaware of, the routes 
 for the WSGI app are defined at application startup time (by methods called 
 in the WSGI app’s __init__).
 
 ---
 Ryan Petrello
 Senior Developer, DreamHost
 ryan.petre...@dreamhost.com
 
 On Dec 13, 2013, at 12:56 PM, Doug Hellmann doug.hellm...@dreamhost.com 
 wrote:
 
 
 
 
  On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh cbky...@gmail.com wrote:
  On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes jaypi...@gmail.com wrote:
  On 12/11/2013 11:47 PM, Mike Perez wrote:
  On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
  On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
  doug.hellm...@dreamhost.com
  mailto:doug.hellm...@dreamhost.comwrote:
 
 
 
 
  On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello 
  ryan.petre...@dreamhost.com
  mailto:ryan.petre...@dreamhost.com
  wrote:
 
  Hello,
 
  I’ve spent the past week experimenting with using Pecan for
  Nova’s
  API
  and have opened an experimental review:
 
 
  https://review.openstack.org/#/c/61303/6
 
  …which implements the `versions` v3 endpoint using pecan (and
  paves the
  way for other extensions to use pecan).  This is a *potential*
 
  approach
  I've considered for gradually moving the V3 API, but I’m open
  to other suggestions (and feedback on this approach).  I’ve
  also got a few open questions/general observations:
 
  1.  It looks like the Nova v3 API is composed *entirely* of
  extensions (including “core” API calls), and that extensions
  and their routes are discoverable and extensible via installed
  software that registers
  itself
  via stevedore.  This seems to lead to an API that’s composed of
 
  installed
  software, which in my opinion, makes it fairly hard to map out
  the
  API (as
  opposed to how routes are manually defined in other WSGI
  frameworks).  I
  assume at this time, this design decision has already been
  solidified for
  v3?
 
 
  Yeah, I brought this up at the summit. I am still having some
  trouble understanding how we are going to express a stable core
  API for compatibility testing if the behavior of the API can be
  varied so significantly by deployment decisions. Will we just
  list each
  required
  extension, and forbid any extras for a compliant cloud?
 
 
  Maybe the issue is caused by me misunderstanding the term
  extension, which (to me) implies an optional component but is
  perhaps reflecting a technical implementation detail instead?
 
 
  Yes and no :-) As Ryan mentions, all API code is a plugin in the V3
  API. However, some must be loaded or the V3 API refuses to start
  up. In nova/api/openstack/__init__.py we have
  API_V3_CORE_EXTENSIONS which hard codes which extensions must be
  loaded and there is no config option to override this (blacklisting
  a core plugin will result in the V3 API not starting up).
 
  So for compatibility testing I think what will probably happen is
  that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that
  must be implemented and clients can rely on that always being
  present
  on a compliant cloud. But clients can also then query through
  /extensions what other functionality (which is backwards compatible
  with respect to core) may also be present on that specific cloud.
 
  This really seems similar

[openstack-dev] Healthnmon

2013-12-17 Thread David S Taylor

Could anyone tell me about the status of the Healthnmon project [1]? There
is a proposal [2] to integrate Ceilometer and Healthnmon, which is about 1
year old. I am interested in developing a monitoring solution, and
discovered that there may already be a project and community in place
around OpenStack monitoring, or not 

[1] https://github.com/stackforge/healthnmon/tree/master/healthnmon
[2] https://wiki.openstack.org/wiki/Ceilometer/CeilometerAndHealthnmon

Thanks,

--
David S Taylor
CTO, Bluesunrise
707 529-9194
da...@bluesunrise.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Ian Wells

This is a discussion document for starters -
https://docs.google.com/document/d/1rOBOOu_OwixMStm6XJOb5PKkJA6eFbL_XCE7wlTfaPY.
 It's lacking the names you asked for at the moment but have a comment
on
it (frequent commenters get edit rights) and from there we can generate and
tidy up the blueprints.  I think that BP will go forward with changes to
the attribute name and possibly the location in that patch.  In summary, I
think we need only a couple of public options and then to generate dnsmasq
configs from those.

Aside from that, the document is trying to be a comprehensive list of
changes to implement ipv6 properly.  That doesn't mean to say we have to do
every element between now and Icehouse, we'll have succeeded even if we
only get the basic cases to work.  For instance, we don't need DHCPv6
providing SLAAC will allocate addresses, it's a refinement that brings
benefits but we can do without.
-- 
Ian.


On 17 December 2013 21:41, Collins, Sean sean_colli...@cable.comcast.comwrote:

 On Tue, Dec 17, 2013 at 07:39:14PM +0100, Ian Wells wrote:
  1. The patch ties Neutron's parameters specifically to dnsmasq.  It would
  be, I think, impossible to reimplement this for isc-dhcpd, for instance.

 While I agree in theory with this point - there are currently no
 active blueprints to add another DHCP server to Neutron. The isc-dhcp
 one has been stalled for quite a long time.

 Frankly, if we can think of better names for the modes that we're
 looking to have happen for v6 provisioning, that doesn't rely directly
 on dnsmasq-isms, I'm all ears. Feel free to propose better names for the
 modes and we'll create a map between the modes and what you pass to
 dnsmasq.

 --
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Meeting Tuesday December 17th at 19:00 UTC

2013-12-17 Thread Elizabeth Krumbach Joseph

On Mon, Dec 16, 2013 at 8:33 AM, Elizabeth Krumbach Joseph
l...@princessleia.com wrote:
 The OpenStack Infrastructure (Infra) team is hosting our weekly
 meeting tomorrow, Tuesday December 17th, at 19:00 UTC in
 #openstack-meeting

Meeting minutes and log here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-17-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-17-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-12-17-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Ian Wells

On 17 December 2013 18:57, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote:

 Yes, the man page is a little bit confusing. The “slaac” mode requires
 “—enable-ra” since it needs to manipulate MOAL bits in the RA. As matter of
 fact, all of the modes available for IPv6 rely on “—enable-ra”.

 My understanding is, the ra-names option has nothing to do with RA. It
 resolves the problem of where to find DNS server. It should work with slaac
 mode or ra-stateless mode.


I'm going to reiterate what I said in my comment on that patch and its
blueprint.

1. The patch ties Neutron's parameters specifically to dnsmasq.  It would
be, I think, impossible to reimplement this for isc-dhcpd, for instance.
2. The fact that ra-names is under consideration says that we're thinking
in implementation terms, not API design terms.  dnsmasq isn't a DNS server
in Openstack, so ra-names isn't an appropriate choice in any case.  It's
only in the list because the options on offer are the options dnsmasq
allows, which is the tail wagging the dog.

What we should have is the reverse: first, what do we want from the
interface, and second, what does that imply for the implementation?  I
don't think we need all the modes just because dnsmasq offers them.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options

2013-12-17 Thread Collins, Sean

On Tue, Dec 17, 2013 at 07:39:14PM +0100, Ian Wells wrote:
 1. The patch ties Neutron's parameters specifically to dnsmasq.  It would
 be, I think, impossible to reimplement this for isc-dhcpd, for instance.

While I agree in theory with this point - there are currently no
active blueprints to add another DHCP server to Neutron. The isc-dhcp
one has been stalled for quite a long time.

Frankly, if we can think of better names for the modes that we're
looking to have happen for v6 provisioning, that doesn't rely directly
on dnsmasq-isms, I'm all ears. Feel free to propose better names for the
modes and we'll create a map between the modes and what you pass to
dnsmasq.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge

2013-12-17 Thread Lyle, David

The simplest solution is already built into the Horizon framework.  Any panel 
or dashboard can be disabled by a check to determine if a service is available 
in the service catalog.  Since there is an inherent above/under cloud 
separation here, the Tuskar service should not be available above cloud.  
Additionally, the same permission mechanism can trigger off roles, also in the 
service catalog.  I see this as a simple implementation detail.

David

 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: Tuesday, December 17, 2013 10:44 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and
 Tuskar-UI merge
 
 On 12/17/2013 03:04 AM, Thomas Goirand wrote:
  On 12/16/2013 10:32 PM, Jaromir Coufal wrote:
 
  This is important note. From information architecture and user
  interaction point of view, I don't think it makes sense to keep all the
  three tabs visible together (Project, Admin, Infrastructure). There are
  lot of reasons, but main points:
 
  * Infrastructure itself is undercloud concept running in different
  instance of Horizon.
 
  * Users dealing with deployment and infrastructure management are not
  the users of OpenStack UI / Dashboard. It is different set of users. So
  it doesn't make sense to have giant application, which provides each and
  every possible feature. I think we need to keep focused.
 
  So by default, I would say that there should exist Project + Admin tab
  together or Infrastructure. But never all three together. So when
  Matthias say 'disabled by default', I would mean completely hidden for
  user and if user wants to use Infrastructure management, he can enable
  it in different horizon instance, but it will be the only visible tab
  for him. So it will be sort of separate application, but still running
  on top of Horizon.
 
  -- Jarda
 
  I think the disabled by default approach is the wrong one. Instead, we
  should have some users with enough credentials that will have the
  feature, and others will not.
 
  Also, Horizon is a web interface. Most of its switches could be made
  directly in the web interface, with the values stored in a db. That'd be
  so much nicer than stored in localsettings.py which starts, as time
  passes, to become overly complicated and ugly (it should, by the way, be
  a configuration file, not a python script: you can't expect
  administrators to understand python, but you do expect them to
  understand how to write in a .ini file).
 
 Welcome to Django. This isn't going to change any time soon :)
 
 Best,
 -jay
 
  Also, it seems we have a consensus, when is it expected to happen? For
  Icehouse b2 maybe?
 
  Just my 2 cents,
 
  Thomas
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-17 Thread Dmitry Mescheryakov

Hello Thomas,

I do understand your feelings. The problem is there were already many
points raised both pro and contra adopting Salt as an agent. And so far no
consensus was reached on that matter. Maybe someone else is willing to step
out and write a PoC for Salt-based agent? Then we can agree on a
functionality PoC should implement and compare the implementations. The
PoCs also can reveal limitations we currently don't see.

Thanks,

Dmitry




2013/12/17 Thomas Herve thomas.he...@enovance.com


  The discussion didn't result in a consensus, but it did revealed a great
  number of things to be accounted. I've tried to summarize top-level
 points
  in the etherpad [1]. It lists only items everyone (as it seems to me)
 agrees
  on, or suggested options where there was no consensus. Let me know if i
  misunderstood or missed something. The etherpad does not list
  advantages/disadvantages of options, otherwise it just would be too long.
  Interested people might search the thread for the arguments :-) .
 
  I've thought it over and I agree with people saying we need to move
 further.
  Savanna needs the agent and I am going to write a PoC for it. Sure the
 PoC
  will be implemented in project-independent way. I still think that Salt
  limitations overweight its advantages, so the PoC will be done on top of
  oslo.messaging without Salt. At least we'll have an example on how it
 might
  look.
 
  Most probably I will have more questions in the process, for instance we
  didn't finish discussion on enabling networking for the agent yet. In
 that
  case I will start a new, more specific thread in the list.

 Hi Dimitri,

 While I agree that using Salt's transport may be wrong for us, the module
 system they have is really interesting, and a pretty big ecosystem already.
 It solved things like system-specific information, and it has a simple
 internal API to create modules. Redoing something from scratch
 Openstack-specific sounds like a mistake to me. As Salt seems to be able to
 work in a standalone mode, I think it'd be interesting to investigate that.

 Maybe it's worth separating the discussion between how to deliver messages
 to the servers (oslo.messaging, Marconi, etc), and what to do on the
 servers (where I think Salt is a great contender).

 --
 Thomas

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Jarret Raim

On 12/13/13, 7:56 AM, Russell Bryant rbry...@redhat.com wrote:


1) Are each of the items you mention big enough to have a sustainable
team that can exist as its own program?

The answer here for Barbican and Keystone is yes.

2) Would there be a benefit of *changing* the scope and mission of the
Identity program to accomodate a larger problem space?  Security
sounds too broad ... but I'm sure you see what I'm getting at.

Dolph and I have talked about this a bit. Right now, if we combined them,
it feels like we would have meetings where the first half would be about
Keystone and the second about Barbican. Same for design sessions. The
systems and the concerns they address are entirely separate. Currently the
teams are also entirely separate.

While I think we can encourage both teams to have a close relationship
(Adam Young and I had a conversion about that recently), there is no
benefit to combining the teams now other than to reduce the number of
programs. As the combination doesn¹t help either project, it seems like
Barbican having its own program is the best option.

When we're talking about authentication, authorization, identity
management, key management, key distribution ... these things really
*do* seem related enough that it would be *really* nice if a group was
looking at all of them and how they fit into the bigger OpenStack
picture.  I really don't want to see silos for each of these things.

I don¹t agree here. Key management and distribution can be used to solve
problems in the identity space. They can also be used to solve problems in
other spaces in openstack. Barbican uses keystone to provide auth / auth
to keys, much like Nova uses keystone to provide auth / auth to servers.
Additionally, Barbican will deal with other parts of the encryption space
(e.g. SSL) that have very little to do with identity.

So, would OpenStack benefit from a tighter relationship between these
projects?  I think this may be the case, personally.

I think there would be benefit to individuals working together from the
two projects where it makes sense - especially where we have knowledge
overlaps. I don¹t agree that including Barbican in the Identity program is
the right way to do that.

Could this tighter relationship happen between separate programs?  It
could, but I think a single program better expresses the intent if
that's really what is best.

Barbican¹s intent is to simplify key management to enable consuming
systems and users to offer or use encryption in their services. This is a
fundementally different mission than Keystone has.



Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Jarret Raim

On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote:


If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin),
Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the
picture is:

67% of commits come from a single person (John Wood)
96% of commits come from a single company (Rackspace)

I think that's a bit brittle: if John Wood or Rackspace were to decide
to place their bets elsewhere, the project would probably die instantly.
I would feel more comfortable if a single individual didn't author more
than 50% of the changes, and a single company didn't sponsor more than
80% of the changes.


I think these numbers somewhat miss the point. It is true that Rackspace
is the primary sponsor of Barbican and that John Wood is the developer
that has been on the project the longest. However, % of commits is not the
only measure of contributions to the project. That number doesn¹t include
the work on our chef-automation scripts or design work to figure out the
HSM interfaces or work on the testing suite or writing our documentation
or the million other tasks for the project.

Rackspace is committed to this project. If John Wood leaves, we¹ll hire
additional developers to replace him. There is no risk of the project
lacking resources because a single person decides to work on something
else. 

We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are
interested in contributing and we are getting outside contributions today.
That will only continue, but I think the risk of the project somehow
collapsing is being overstated.

There are problems that aren¹t necessarily the sexiest things to work on,
but need to be done. It may be hard to get a large number of people
interested in such a project in a short period of time. I think it would
be a mistake to reject projects that solve important problems just because
the team is a bit one sided at the time.





Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Glance WSGI File Read Bug (Grizzly)

I was able to pin down the image upload problem today:

The Store.add file input read loop using chunkreadable throws an error on the 
very last read. Apparently the mod_wsgi.Input behaves differently than its 
eventlet counterpart in that it throws an error if the requested data length is 
greater than what is avalible. When I replaced the chunkreadable for loop with 
a while loop that modified the size of the last data read request, it works. 
Does anyone know if this is a code bug or rather a WSGI configuration setting 
that I missed?

Regards,

Mark

---

I made the following chages to file 
/usr/lib/python2.7/dist-packages/glance/store/filesystem.py:

def add(self, image_id, image_file, image_size):

Stores an image file with supplied identifier to the backend
storage system and returns a tuple containing information
about the stored image.

:param image_id: The opaque image identifier
:param image_file: The image data to write, as a file-like object
:param image_size: The size of the image data to write, in bytes

:retval tuple of URL in backing store, bytes written, and checksum
:raises `glance.common.exception.Duplicate` if the image already
existed

:note By default, the backend writes the image data to a file
  `/DATADIR/ID`, where DATADIR is the value of
  the filesystem_store_datadir configuration option and ID
  is the supplied image ID.


filepath = os.path.join(self.datadir, str(image_id))

if os.path.exists(filepath):
raise exception.Duplicate(_(Image file %s already exists!)
  % filepath)

checksum = hashlib.md5()
bytes_written = 0
bytes_to_read = ChunkedFile.CHUNKSIZE
try:
with open(filepath, 'wb') as f:

while bytes_written  image_size:
if (image_size - bytes_written)  ChunkedFile.CHUNKSIZE:
bytes_to_read = image_size - bytes_written
buf = image_file.read(bytes_to_read)
bytes_written += len(buf)
checksum.update(buf)
f.write(buf)


for buf in utils.chunkreadable(image_file,
   ChunkedFile.CHUNKSIZE):
bytes_written += len(buf)
checksum.update(buf)
f.write(buf)

except IOError as e:
if e.errno != errno.EACCES:
self._delete_partial(filepath, image_id)
exceptions = {errno.EFBIG: exception.StorageFull(),
  errno.ENOSPC: exception.StorageFull(),
  errno.EACCES: exception.StorageWriteDenied()}
raise exceptions.get(e.errno, e)



From: Miller, Mark M (EB SW Cloud - RD - Corvallis)
Sent: Tuesday, December 17, 2013 12:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Glance mod_wsgi.input Question

Hello,

I am trying to get the Grizzly Glance service working with Apache2 through the 
WSGI interface. I am having problems with the _upload method of file 
glance/api/v1/images.py It appears that the req.body_file pointer is invalid 
as I get the following error: (9, 'Bad file descriptor').

I have tried adding inline test code attempting to read the image_data object 
but have been unsuccessful. The req.content_length = None. Has anyone come 
across this issue? Below are a few variable values as well as the req.environ:

scheme = file
image size = 8
image data = mod_wsgi.Input object at 0x7f5fb08931f0

-

key=HTTP_X_TENANT_NAME, value=u'AdminProject'
key=routes.route, value=routes.route.Route object at 0x7f5fb181fc90
key=webob.is_body_readable, value=True
key=mod_wsgi.listener_port, value='9292'
key=HTTP_X_PROJECT_NAME, value=u'AdminProject'
key=SERVER_SOFTWARE, value='Apache'
key=content-length, value=8
key=SCRIPT_NAME, value='/v1/v1'
key=HTTP_TRANSFER_ENCODING, value='chunked'
key=mod_wsgi.handler_script, value=''
key=SERVER_SIGNATURE, value='addressApache Server at 10.1.184.1 Port 
9292/address\n'
key=REQUEST_METHOD, value='POST'
key=PATH_INFO, value='/images'
key=SERVER_PROTOCOL, value='HTTP/1.1'
key=QUERY_STRING, value=''
key=Content_Length, value=8
key=HTTP_X_USER_ID, value=u'0dd0361fe85a43deb456dd47ed55c2e2'
key=HTTP_X_IMAGE_META_MIN_RAM, value='0'
key=HTTP_X_AUTH_TOKEN, value='de169f1045f8d306a750d28e8e33172e'
key=HTTP_USER_AGENT, value='python-glanceclient'
key=HTTP_X_DOMAIN_NAME, value=None
key=SERVER_NAME, value='10.1.184.1'
key=REMOTE_ADDR, value='10.1.184.1'
key=HTTP_X_ROLE, value=u'admin'
key=mod_wsgi.request_handler, value='wsgi-script'
key=HTTP_X_IDENTITY_STATUS, value='Confirmed'
key=wsgi.url_scheme, value='https'
key=SERVER_ADMIN, value='[no address given]'
key=CONTENT_LENGTH,

Re: [openstack-dev] [neutron] [policy] Policy-group relationship

2013-12-17 Thread Mohammad Banikazemi

Stephen Wong s3w...@midokura.com wrote on 12/15/2013 12:00:32 PM:

 From: Stephen Wong s3w...@midokura.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 12/15/2013 12:04 PM
 Subject: Re: [openstack-dev] [neutron] [policy] Policy-group relationship

 Hi Mohammad,

 Good writeup, one minor comment at the end below (look for [s3wong]).

 On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi m...@us.ibm.com
wrote:
  Continuing the discussion we had earlier today during the Neutron Group
  Policy weekly meeting [0], I would like to initiate a couple of email
  threads and follow up on a couple of important issues we need to agree
on so
  we can move forward. In this email thread, I would like to discuss the
  policy-group relationship.

  I want to summarize the discussion we had during the meeting [1] and
see if
  we have reached an agreement:

  There are two models for expressing the relationship between Groups and
  Policies that were discussed:
  1- Policies are defined for a source Group and a destination Group
  2- Groups specify the Policies they provide and the Policies they
  consume

  As expressed during the IRC meeting, both models have strong support
and we
  decided to have a resource model that can be used to express both
models.
  The solution we came up with was rather simple:

  Update the resource model (shown in the attribute tables and the
taxonomy in
  the google doc [2]) such that policy can refer to a list of source
Groups
  and a list of destination Groups.
  This boils down to having two attributes namely, src_groups and
  destination_groups (both list of uuid-str type) replacing the current
  attributes src_group and dest_group, respectively.

  This change simply allows the support for both models. For supporting
model
  1, specify a single source Group and a single destination Group. For
model
  2, specify the producers of a Policy in the source Group list and
specify
  the consumers of the Policy in the destination Group list.

 [s3wong] this is interesting. Let's say we have two groups A  B, and
 A wants to send traffic to B, so in this case, B is providing a policy
 which A will consume. In your proposal above, I would have to put A in
 destination group list and B in source group list although the traffic
 direction is the reverse. Would that cause a bit of a confusion?

Yeah, that's a good point. Producers are the destination of traffic flows.
So should we have them under destination group? Even that is a bit
confusing.
May be we need different names for the two groups.

-Mohammad

 Thanks,
 - Stephen

  If there is agreement, I will update the taxonomy and the attribute
tables
  in the doc.

  Best,

  Mohammad

  [0] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
  [1]
  http://eavesdrop.openstack.org/meetings/networking_policy/2013/
 networking_policy.2013-12-12-16.01.log.html
  [2]
  https://docs.google.com/document/d/
 1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
  (Note the new additions are at the end of the document.)

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Mike Perez

On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim jarret.r...@rackspace.comwrote:

 On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote:


 If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin),
 Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the
 picture is:
 
 67% of commits come from a single person (John Wood)
 96% of commits come from a single company (Rackspace)
 
 I think that's a bit brittle: if John Wood or Rackspace were to decide
 to place their bets elsewhere, the project would probably die instantly.
 I would feel more comfortable if a single individual didn't author more
 than 50% of the changes, and a single company didn't sponsor more than
 80% of the changes.


 I think these numbers somewhat miss the point. It is true that Rackspace
 is the primary sponsor of Barbican and that John Wood is the developer
 that has been on the project the longest. However, % of commits is not the
 only measure of contributions to the project. That number doesn¹t include
 the work on our chef-automation scripts or design work to figure out the
 HSM interfaces or work on the testing suite or writing our documentation
 or the million other tasks for the project.

 Rackspace is committed to this project. If John Wood leaves, we¹ll hire
 additional developers to replace him. There is no risk of the project
 lacking resources because a single person decides to work on something
 else.

 We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are
 interested in contributing and we are getting outside contributions today.
 That will only continue, but I think the risk of the project somehow
 collapsing is being overstated.

 There are problems that aren¹t necessarily the sexiest things to work on,
 but need to be done. It may be hard to get a large number of people
 interested in such a project in a short period of time. I think it would
 be a mistake to reject projects that solve important problems just because
 the team is a bit one sided at the time.



Besides it being considered brittle because there is one major code
contributor,
I would be worried about the project being one-sided to solving the use
cases that
work for one company, but may not work for the use cases of other companies
if they have not chimed in yet. Do you feel this is not the case? Can
anyone
from somewhere other than Rackspace speak up and say they have been
involved
with the design/discussions of Barbican?


-Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [testr] debugging failing testr runs

2013-12-17 Thread Robert Collins

You ran a listing:

./.tox/py33/bin/python -m subunit.run discover -t ./
./keystoneclient/tests --list

which outputs the discovered tests as subunit enumerations.

.tox/py33/bin/testr run

will run the tests for you

-Rob


On 18 December 2013 05:18, Chmouel Boudjnah chmo...@enovance.com wrote:
 Hello,

 I was wondering what was the strategy to debug a failed run with tox?

 I was trying to see which tests was failing with python-keystoneclient and
 py33 and this is the type of error i am getting :

 http://paste.openstack.org/show/gc3xMk34ELuSF5Fk1mvP/

 (bet it with tox directly or from the virtualenv).

 I have to resort to nose to get the proper error :

 http://pastie.org/pastes/8558525/text?key=o4hljmbmsakrekbzqvrfug

 do you know how to get the same output with testr than the above paste?

 Thanks,
 Chmouel.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [policy] Policy-group relationship

2013-12-17 Thread Tim Hinrichs

Inline.

- Original Message -
| From: Mohammad Banikazemi m...@us.ibm.com
| To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
| Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
| Sent: Tuesday, December 17, 2013 11:42:53 AM
| Subject: Re: [openstack-dev] [neutron] [policy] Policy-group relationship
| 
| 
| 
| 
| Stephen Wong s3w...@midokura.com wrote on 12/15/2013 12:00:32 PM:
| 
|  From: Stephen Wong s3w...@midokura.com
|  To: OpenStack Development Mailing List (not for usage questions)
|  openstack-dev@lists.openstack.org,
|  Date: 12/15/2013 12:04 PM
|  Subject: Re: [openstack-dev] [neutron] [policy] Policy-group
|  relationship
|  
|  Hi Mohammad,
|  
|  Good writeup, one minor comment at the end below (look for
|  [s3wong]).
|  
|  On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi
|  m...@us.ibm.com wrote:
|   Continuing the discussion we had earlier today during the Neutron
|   Group
|   Policy weekly meeting [0], I would like to initiate a couple of
|   email
|   threads and follow up on a couple of important issues we need to
|   agree on so
|   we can move forward. In this email thread, I would like to
|   discuss the
|   policy-group relationship.
|   
|   I want to summarize the discussion we had during the meeting [1]
|   and see if
|   we have reached an agreement:
|   
|   There are two models for expressing the relationship between
|   Groups and
|   Policies that were discussed:
|   1- Policies are defined for a source Group and a destination
|   Group
|   2- Groups specify the Policies they provide and the Policies
|   they
|   consume
|   
|   As expressed during the IRC meeting, both models have strong
|   support and we
|   decided to have a resource model that can be used to express both
|   models.
|   The solution we came up with was rather simple:
|   
|   Update the resource model (shown in the attribute tables and the
|   taxonomy in
|   the google doc [2]) such that policy can refer to a list of
|   source Groups
|   and a list of destination Groups.
|   This boils down to having two attributes namely, src_groups and
|   destination_groups (both list of uuid-str type) replacing the
|   current
|   attributes src_group and dest_group, respectively.
|   
|   This change simply allows the support for both models. For
|   supporting model
|   1, specify a single source Group and a single destination Group.
|   For model
|   2, specify the producers of a Policy in the source Group list and
|   specify
|   the consumers of the Policy in the destination Group list.
|  
|  [s3wong] this is interesting. Let's say we have two groups A  B,
|  and
|  A wants to send traffic to B, so in this case, B is providing a
|  policy
|  which A will consume. In your proposal above, I would have to put A
|  in
|  destination group list and B in source group list although the
|  traffic
|  direction is the reverse. Would that cause a bit of a confusion?
|  
| 
| Yeah, that's a good point. Producers are the destination of traffic
| flows.
| So should we have them under destination group? Even that is a bit
| confusing.
| May be we need different names for the two groups.
| 
| -Mohammad
| 

If we're not sure what the 2 groups represent (source and destination), perhaps 
that means we ought to have any number of groups and not assign them names.  A 
policy would then be applied to any number of groups, and it would be up to the 
policy itself to dictate source/destination semantics if that is what the 
groups represent.

For example, if we had a DENY action, it might take several arguments, one of 
which is a source and one of which is a destination.  Then by applying groups 
properly to that DENY action, we could dictate which group is playing the role 
of SOURCE and which group is playing the role of DESTINATION.

Tim

|  Thanks,
|  - Stephen
|  
|  
|   
|   If there is agreement, I will update the taxonomy and the
|   attribute tables
|   in the doc.
|   
|   Best,
|   
|   Mohammad
|   
|   
|   [0] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
|   [1]
|   http://eavesdrop.openstack.org/meetings/networking_policy/2013/
|  networking_policy.2013-12-12-16.01.log.html
|   [2]
|   https://docs.google.com/document/d/
|  1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
|   (Note the new additions are at the end of the document.)
|   
|   
|   ___
|   OpenStack-dev mailing list
|   OpenStack-dev@lists.openstack.org
|   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
|   
|  
|  ___
|  OpenStack-dev mailing list
|  OpenStack-dev@lists.openstack.org
|  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
|  
| 
| ___
| OpenStack-dev mailing list
| OpenStack-dev@lists.openstack.org
|

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Bhandaru, Malini K

To add to Jarret's arguments,  across OpenStack we have seen as subsystems grow 
more mature and complex from additional feature extensions, they spawn off into 
separate projects.
Case in point -- Neutron rose out of Nova Networking, and is marching on in 
richness and community support.  Common libraries went into Oslo. The Nova 
scheduler is currently being forklifted into a service of its own called gantt.
At the Portland summit such considerations were raised and given that Barbican 
provides a separate functionality, it does cleanly live in its own project. 
True the public/private key pair of a service, tenant etc is part of its 
identity. In that respect Keystone and Barbican would intersect, which could be 
managed by delegating the storage of the public key in Barbican, like a 
directory service.

Regards
Malini

-Original Message-
From: Jarret Raim [mailto:jarret.r...@rackspace.com] 
Sent: Tuesday, December 17, 2013 11:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Incubation Request for Barbican

On 12/13/13, 7:56 AM, Russell Bryant rbry...@redhat.com wrote:


1) Are each of the items you mention big enough to have a sustainable 
team that can exist as its own program?

The answer here for Barbican and Keystone is yes.

2) Would there be a benefit of *changing* the scope and mission of the 
Identity program to accomodate a larger problem space?  Security
sounds too broad ... but I'm sure you see what I'm getting at.

Dolph and I have talked about this a bit. Right now, if we combined them, it 
feels like we would have meetings where the first half would be about Keystone 
and the second about Barbican. Same for design sessions. The systems and the 
concerns they address are entirely separate. Currently the teams are also 
entirely separate.

While I think we can encourage both teams to have a close relationship (Adam 
Young and I had a conversion about that recently), there is no benefit to 
combining the teams now other than to reduce the number of programs. As the 
combination doesn¹t help either project, it seems like Barbican having its own 
program is the best option.

When we're talking about authentication, authorization, identity 
management, key management, key distribution ... these things really
*do* seem related enough that it would be *really* nice if a group was 
looking at all of them and how they fit into the bigger OpenStack 
picture.  I really don't want to see silos for each of these things.

I don¹t agree here. Key management and distribution can be used to solve 
problems in the identity space. They can also be used to solve problems in 
other spaces in openstack. Barbican uses keystone to provide auth / auth to 
keys, much like Nova uses keystone to provide auth / auth to servers.
Additionally, Barbican will deal with other parts of the encryption space (e.g. 
SSL) that have very little to do with identity.

So, would OpenStack benefit from a tighter relationship between these 
projects?  I think this may be the case, personally.

I think there would be benefit to individuals working together from the two 
projects where it makes sense - especially where we have knowledge overlaps. I 
don¹t agree that including Barbican in the Identity program is the right way to 
do that.

Could this tighter relationship happen between separate programs?  It 
could, but I think a single program better expresses the intent if 
that's really what is best.

Barbican¹s intent is to simplify key management to enable consuming systems and 
users to offer or use encryption in their services. This is a fundementally 
different mission than Keystone has.



Jarret

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

2013-12-17 Thread Georgy Okrokvertskhov

Hi,

Murano project volunteers to be a first project applying to Emerging
projects program. Murano was here quite long time and it was developed
taking into account all OpenStack development processes.

I think Murano is a good candidate to be a first project in this new
program as it should be quite painless to try different OpenStack
requirements on Murano in order to specify Emerging projects requirements
in the future.

What kind of process should it be for Emerging projects program
application?

Thanks
Georgy



On Tue, Dec 17, 2013 at 6:27 AM, Flavio Percoco fla...@redhat.com wrote:

 On 17/12/13 14:59 +0100, Thierry Carrez wrote:

 Mark McLoughlin wrote:

 On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:

 Mark McLoughlin wrote:

 How about if we had an emerging projects page where the TC feedback
 on
 each project would be listed?

 That would give visibility to our feedback, without making it a yes/no
 blessing. Ok, whether to list any feedback about the project on the
 page
 is a yes/no decision, but at least it allows us to fully express why we
 find the project promising, what people need to help with in order for
 it to be incubated, etc.

 With a formal yes/no status, I think we'd struggle with projects which
 we're not quite ready to even bless with an emerging status but we
 still want to encourage them - this allows us to bless a project as
 emerging but be explicit about our level of support for it.


 I agree that being able to express our opinion on a project in shades of
 grey is valuable... The main drawback of using a non-boolean status for
 that is that you can't grant any benefit to it. So we'd not be able to
 say emerging projects get design summit space.

 They can still collaborate in unconference space or around empty tables,
 but then we are back to the problem we are trying to solve: increase
 visibility of promising projects pre-incubation.


 Have an emerging projects track and leave it up to the track coordinator
 to decide prioritize the most interesting sessions and the most advanced
 projects (according to the TC's feedback)  ?


 I guess that /could/ work. I don't expect we'll have space for more than
 one session per project, but that may be enough for self-organization if
 we nail the collaboration spaces correctly.

 I'm fine with giving that page a try (we can always revisit if it's not
 working any better...).



 I'm not sure about the page as a medium for this but I like the idea.
 This is pretty much a way to incubate programs, which is basically
 what I proposed in my previous emails. Lets not consider Programs
 official right away, lets give them a place where they can grow a bit
 with the projects the have under their umbrella. Lets also - as Mark
 suggested - use that place to add comments and help them grow.

 And I'm also in favor of having a emerging projects track. +1


 Cheers,
 FF


 --
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Bhandaru, Malini K

Barbican, key manager is essential to openstack, paves the way to greater 
security.
Instead of rejecting the project because of its current existence owed so 
heavily to Rackspace and to John Wood, why not we adopt it, code review, 
contribute code etc. We can have cores from multiple companies. Swift was a 
project that was born similarly.
During development John Wood and the whole Rackspace team has been open to 
feature design discussions and providing good code review.  

Intel plans to create a plugin for Barbican, along the lines of a low cost HSM, 
essentially using the Intel TXT and the Trusted Platform Module to save a 
master secret used to encrypt all the other secrets.
Our Intel team is small and some of us had other distractions in October and 
November, but we are back and may even grow in strength.

John, Jarret, and team, thank you for all the hard work.

Malini


-Original Message-
From: Jarret Raim [mailto:jarret.r...@rackspace.com] 
Sent: Tuesday, December 17, 2013 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Incubation Request for Barbican

On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote:


If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), 
Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the 
picture is:

67% of commits come from a single person (John Wood) 96% of commits 
come from a single company (Rackspace)

I think that's a bit brittle: if John Wood or Rackspace were to decide 
to place their bets elsewhere, the project would probably die instantly.
I would feel more comfortable if a single individual didn't author more 
than 50% of the changes, and a single company didn't sponsor more than 
80% of the changes.


I think these numbers somewhat miss the point. It is true that Rackspace is the 
primary sponsor of Barbican and that John Wood is the developer that has been 
on the project the longest. However, % of commits is not the only measure of 
contributions to the project. That number doesn¹t include the work on our 
chef-automation scripts or design work to figure out the HSM interfaces or work 
on the testing suite or writing our documentation or the million other tasks 
for the project.

Rackspace is committed to this project. If John Wood leaves, we¹ll hire 
additional developers to replace him. There is no risk of the project lacking 
resources because a single person decides to work on something else. 

We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are 
interested in contributing and we are getting outside contributions today.
That will only continue, but I think the risk of the project somehow collapsing 
is being overstated.

There are problems that aren¹t necessarily the sexiest things to work on, but 
need to be done. It may be hard to get a large number of people interested in 
such a project in a short period of time. I think it would be a mistake to 
reject projects that solve important problems just because the team is a bit 
one sided at the time.





Jarret

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

2013-12-17 Thread Tim Hinrichs



- Original Message -
| From: Prasad Vellanki prasad.vella...@oneconvergence.com
| To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
| Sent: Monday, December 16, 2013 2:11:37 PM
| Subject: Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based 
on Dec.12 network policy meeting
| 
| 
| 
| Hi
| Please see inline 
| 
| 
| 
| On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong  s3w...@midokura.com 
| wrote:
| 
| 
| Hi,
| 
| During Thursday's group-policy meeting[1], there are several
| policy-rules related issues which we agreed should be posted on the
| mailing list to gather community comments / consensus. They are:
| 
| (1) Conflict resolution between policy-rules
| --- a priority field was added to the policy-rules attributes
| list[2]. Is this enough to resolve conflict across policy-rules (or
| even across policies)? Please state cases where a cross policy-rules
| conflict can occur.
| --- conflict resolution was a major discussion point during
| Thursday's meeting - and there was even suggestion on setting
| priority
| on endpoint groups; but I would like to have this email thread
| focused
| on conflict resolution across policy-rules in a single policy first.
| 

There was interest in having a single policy that could include different 
actions so that a single flow might be both redirected and QOSed 
simultaneously.  For me this rules out a total ordering on the policy 
statements.  Here's a proposal that relies on the fact that we're fixing the 
meaning of actions within the language: the language specifies a partial order 
on the *actions*.  For example, DENY takes precedence over ALLOW, so if we both 
ALLOW and DENY, then the conflict resolution dictates DENY wins. But {DENY, 
ALLOW} and QOS and REDIRECT are all unrelated, so there is no problem with a 
policy that both DENYs and QOSes and REDIRECTs.

| (2) Default policy-rule actions
| --- there seems to be consensus from the community that we need to
| establish some basic set of policy-rule actions upon which all
| plugins/drivers would have to support
| --- just to get the discussion going, I am proposing:
| 
| 
| 
| Or should this be a query the plugin for supported actions and thus
| the user knows what functionality the plugin can support. Hence
| there is no default supported list.
| 

I think the important part is that the language defines what the actions mean.  
Whether each plugin supports them all is a different issue.  If the language 
doesn't define the meaning of the actions, there's no way for anyone to use the 
language.  We might be able to write down policies, but we don't know what 
those policies actually mean because 2 plugins might assign very different 
meanings to the same action name.

| 
| 
| a.) action_type: 'security' action: 'allow' | 'drop'
| b.) action_type: 'qos' action: {'qos_class': {'critical' |
| 'low-priority' | 'high-priority' |
| 
| 'low-immediate' | 'high-immediate' |
| 
| 'expedite-forwarding'}
| (a subset of DSCP values - hopefully in language that can
| be well understood by those performing application deployments)
| c.) action_type:'redirect' action: {UUID, [UUID]...}
| (a list of Neutron objects to redirect to, and the list
| should contain at least one element)
| 
| 
| 
| 
| I am not sure making the UUIDs a list of neutron objects or endpoints
| will work well. It seems that it should more higher level such as
| list of services that form a chain. Lets say one forms a chain of
| services, firewall, IPS, LB. It would be tough to expect user to
| derive the neutron ports create a chain of them. It could be a VM
| UUID.
| 
| 

Perhaps we could use our usual group mechanism here and say that the redirect 
action operates on 3 groups: source, destination, and the group to which we 
want to redirect.

| 
| Please discuss. In the document, there is also 'rate-limit' and
| 'policing' for 'qos' type, but those can be optional instead of
| required for now
| 

It would be nice if we had some rationale for deciding which actions to include 
and which to leave out.  Maybe if we found a 
standard/spec/collection-of-use-cases and included exactly the same actions.  
Or if we go with the action-based conflict resolution scheme from (1), we might 
want to think about whether we have at least complementary actions (e.g. ALLOW 
and DENY, WAYPOINT -- route traffic through a group of middleboxes-- and FORBID 
-- prohibit traffic from passing through middleboxes).

| (3) Prasad asked for clarification on 'redirect' action, I propose to
| add the following text to document regarding 'redirect' action:
| 
| 'redirect' action is used to mirror traffic to other destinations
| - destination can be another endpoint group, a service chain, a port,
| or a network. Note that 'redirect' action type can be used with other
| forwarding related action type such as 'security'; therefore, it is
| entirely possible that one can specify {'security':'deny'} and still

[openstack-dev] [Neutron] blueprint ovs-firewall-driver: Security groups extension API addition

2013-12-17 Thread Amir Sadoughi

Hi all,

Monday at 2000 UTC I held an IRC meeting for blueprint ovs-firewall-driver to 
discuss implementation choices with the community. Only a handful of people 
attended so I wanted to open the discussion to the mailing list.

(I’ve also uploaded this to the wiki 
https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver#Security_groups_extension_API_addition_discussion.)

tl;dr: To implement a performant OVS-based security groups solution in Neutron 
today, source port matching is a required addition to the security groups 
extension API.


=== Background ===

In Open vSwitch today, there are two best practice options of implementing 
firewalls[1]:

1. reflexive learn actions (available in OVS today)
2. stateless ACLs with tcp_flags=ack (available in OVS git, to be released in 
v2.1.0 - early 2014[6])


In the same e-mail thread[2], the tradeoffs between the two choices were 
discussed:

- reflexive learning is not as performant as it cuts into how many flows a 
megaflow can wildcard, e.g. the less that can be wildcarded, the more OVS will 
have to hit userspace for flows

- Using the learn action is strictly more correct, since it's only allowing 
return traffic that's in response to traffic that was previously seen.  TCP 
flag matching allows reasonable megaflows, but just blocking on the SYN flags 
isn't as secure, since an attacker can get traffic through--they just can't 
initiate a new connection.

My preferred implementation is 'stateless ACLs with tcp_flags=ack' to emulate 
stateful behavior (at least in TCP) because reflexive learning is not as 
performant.


=== Discussion: why? ===

Following through with the 'stateless ACLs with tcp_flags=ack' approach, UDP 
clients on the instance will need explicit security group rules to match source 
IP address and source port.

Example 1. A remote UDP client connecting to an instance UDP server
A. nw_src=$remote_ip, tp_src=random, nw_dst=$instance_ip, tp_dst=9987
B. nw_src=$instance_ip, tp_src=9987, nw_dst=$remote_ip, tp_src=random

So, in the case of the instance being a UDP server and default security groups 
already allowing all egress, adding a rule to allow ingress on UDP destination 
port 9987 will behave as expected.

Example 2. An instance UDP client connecting to a remote UDP server
C. nw_src=$instance_ip, tp_src=random, nw_dst=$remote_ip, tp_dst=9987
D. nw_src=$remote_ip, tp_src=9987, nw_dst=$instance_ip, tp_dst=random

In the case of the instance being a UDP client and default security groups 
already allowing all egress, we will need a new security group rule to allow 
ingress from source port 9987 from the remote UDP server in a stateless 
firewall. This is different behavior than the iptables-based stateful firewall 
implementation because it is able to add the reverse flow in its state table 
for a specific timeout length when it initially sees flow C.

So, in security groups, we will need an additional rule that will define flow D 
(remote UDP server’s IP address, UDP source port 9987, and of course the 
instance’s IP address). However, if you look at the security groups API as it 
is today[3], you will see there is no match for source port (tp_src), only 
destination port (—port-range-min, —port-range-max).


=== Suggested change: how to fix it ===

So, to solve the lack of source port information, I propose the following 
addition to the security groups extension API to allow a match on source port: 
—source-port-range-min, —source-port-range-max. I already have WIP patches 
uploaded for neutron[4] and python-neutronclient[5] implementing these 
suggested additions. The security groups RPC API already has a field for 
source-port-range-min and source-port-range-max so this change would only 
affect the DB and frontend API.


I’m open to any and all feedback.

Thanks,

Amir Sadoughi


[1] e-mail thread on ovs-discuss mailing list. 
http://openvswitch.org/pipermail/discuss/2013-December/012425.html
[2] http://openvswitch.org/pipermail/discuss/2013-December/012433.html
[3] http://paste.openstack.org/show/55103/
[4] https://review.openstack.org/#/c/62129/
[5] https://review.openstack.org/#/c/62130/
[6] http://openvswitch.org/pipermail/discuss/2013-December/012457.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] Weekly meeting time

2013-12-17 Thread Liz Blanchard

Hi All,

In today's weekly meeting we discussed the possibility of changing the time of 
the weekly meetings to make it easier for everyone to attend. This seems to be 
a difficult task since we are worldwide! Nevertheless, let's see if Doodle can 
help us understand which times might be a better fit for the majority of the 
group.

Here is what you need to do:

1) Click on this link to open the Doodle: http://www.doodle.com/q8q6iu8gcqp6c4xa
2) Ignore the fact that this says for Dec 31st only.
3) Choose your time zone over on the right.
4) Expand the list to show all time options.
5) Enter your name and check off the times that work for you for a meeting.
6) Click save.

Thanks for your participation!

Liz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Neutron resources and hidden dependencies

2013-12-17 Thread Zane Bitter

At the design summit we had a discussion[1] about redesigning Neutron 
resources to avoid the need for hidden dependencies (that is to say, 
dependencies which cannot be inferred from the template).


Since then we've got close to fixing one of those issues[2] (thanks 
Bartosz!), but the patch is currently held up by a merge conflict 
because... we managed to add two more[3][4].


There's also another patch currently under review[5] that adds the most 
impressively complex hidden dependencies we've yet seen (though, 
fortunately, the worst of this is actually redundant and can be removed 
without effect).


I know that due to the number of Neutron resources that currently 
override add_dependencies(), this may look like a normal part of a 
resource implementation. However, this is absolutely not the case. If 
you feel the need to override add_dependencies() for any reason then 
some part of the design is wrong. If you feel the need to do it for any 
reason other than not breaking existing soon-to-be-deprecated wrong 
designs (i.e. RouterGateway), then your part of the design is the part 
that's wrong.


Core reviewers should treat any attempt to override add_dependencies() 
as a red flag IMO.


It's unfortunate that many parts of the Neutron API are not great, 
especially that some pretty core functionality is currently balkanised 
into various 'extensions' that don't have a coherent interface. 
Nevertheless, that just means that we need to work harder to come up 
with resource designs that express the appropriate relationships between 
resources *in the template*, not with hidden relationships in the code. 
This means that orchestration will actually work regardless of whether 
all of the related resources are defined in the same template, and in 
fact regardless of whether they are defined in templates at all.


I'd like to propose that we revert NetDHCPAgent and RouterL3Agent (which 
are somewhat misnamed, and serve only to connect a Net or Router to an 
existing agent, not to create an agent) and replace them with properties 
on the Net and Router classes, respectively.


The Route resource has not yet been merged, so we can discuss in the 
review the best course of action - which IMO is to:

(a) Fix the Neutron API to allow atomic updates to the route table; and
(b) Use a reference to a RouterInterface as the nexthop value, to ensure 
that routes are not created before their nexthops are available.


cheers,
Zane.

[1] https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism
[2] https://review.openstack.org/#/c/60118/
[3] https://review.openstack.org/#/c/59626/8
[4] https://review.openstack.org/#/c/61388/3
[5] https://review.openstack.org/#/c/41044/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

2013-12-17 Thread Craig Tracey

++

As someone who has required patches to Barbican (and not affiliated with
Rackspace) I can attest to the fact that my, albeit simple, changes have
been reviewed and merged in a timely and constructive manner. Even if the
project were to bring on a flood of new developers it wouldn't move this
commit diversity metric for quite some time.

There is already a need for a keystore and I think this need will only
grow. So why not support it as its own composable service?

Thanks for all the work on Barbican!
On Dec 17, 2013 6:17 PM, Bhandaru, Malini K malini.k.bhand...@intel.com
wrote:

 Barbican, key manager is essential to openstack, paves the way to greater
 security.
 Instead of rejecting the project because of its current existence owed so
 heavily to Rackspace and to John Wood, why not we adopt it, code review,
 contribute code etc. We can have cores from multiple companies. Swift was a
 project that was born similarly.
 During development John Wood and the whole Rackspace team has been open to
 feature design discussions and providing good code review.

 Intel plans to create a plugin for Barbican, along the lines of a low cost
 HSM, essentially using the Intel TXT and the Trusted Platform Module to
 save a master secret used to encrypt all the other secrets.
 Our Intel team is small and some of us had other distractions in October
 and November, but we are back and may even grow in strength.

 John, Jarret, and team, thank you for all the hard work.

 Malini


 -Original Message-
 From: Jarret Raim [mailto:jarret.r...@rackspace.com]
 Sent: Tuesday, December 17, 2013 11:44 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Incubation Request for Barbican

 On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote:


 If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin),
 Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the
 picture is:
 
 67% of commits come from a single person (John Wood) 96% of commits
 come from a single company (Rackspace)
 
 I think that's a bit brittle: if John Wood or Rackspace were to decide
 to place their bets elsewhere, the project would probably die instantly.
 I would feel more comfortable if a single individual didn't author more
 than 50% of the changes, and a single company didn't sponsor more than
 80% of the changes.


 I think these numbers somewhat miss the point. It is true that Rackspace
 is the primary sponsor of Barbican and that John Wood is the developer that
 has been on the project the longest. However, % of commits is not the only
 measure of contributions to the project. That number doesn¹t include the
 work on our chef-automation scripts or design work to figure out the HSM
 interfaces or work on the testing suite or writing our documentation or the
 million other tasks for the project.

 Rackspace is committed to this project. If John Wood leaves, we¹ll hire
 additional developers to replace him. There is no risk of the project
 lacking resources because a single person decides to work on something else.

 We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are
 interested in contributing and we are getting outside contributions today.
 That will only continue, but I think the risk of the project somehow
 collapsing is being overstated.

 There are problems that aren¹t necessarily the sexiest things to work on,
 but need to be done. It may be hard to get a large number of people
 interested in such a project in a short period of time. I think it would be
 a mistake to reject projects that solve important problems just because the
 team is a bit one sided at the time.





 Jarret

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

2013-12-17 Thread Shixiong Shang

Hi, team:

I created a new blueprint to reflect the work we accomplished in the previous 
POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two 
weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was 
to run dnsmasq as DHCPv6 server and provide both optional information and/or 
IPv6 address to VM in the tenant network. Below you can find the link to the 
new blueprints, which are all related to the mid-term goal in Sean’s original 
proposal.

https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless

Please let me know if you have any questions. Thanks!

Shixiong


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

2013-12-17 Thread Stephen Wong

Hi Subra,

On Sun, Dec 15, 2013 at 9:32 PM, Subrahmanyam Ongole osm...@gmail.com wrote:
Hi Stephan

Comments inline for redirect action. Perhaps we may want to discuss each
section in different email threads.

On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3w...@midokura.com wrote:

Hi,

During Thursday's group-policy meeting[1], there are several
policy-rules related issues which we agreed should be posted on the
mailing list to gather community comments / consensus. They are:

(3) Prasad asked for clarification on 'redirect' action, I propose to
add the following text to document regarding 'redirect' action:

'redirect' action is used to mirror traffic to other destinations
- destination can be another endpoint group, a service chain, a port,
or a network. Note that 'redirect' action type can be used with other
forwarding related action type such as 'security'; therefore, it is
entirely possible that one can specify {'security':'deny'} and still
do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
specified on the list CANNOT be the endpoint-group who provides this
policy. Also, in case of destination being another endpoint-group, the
policy of this new destination endpoint-group will still be applied

Please discuss.

a. In Neutron, I am not sure whether there is a way to get an object given a
UUID without knowing the type of the object, be it a port, network or a
specific type of Neutron service.

I am less likely to err if uuid is qualified by a type or some human
readable name.

Excellent point. I will add a type field for each redirect object.
Thanks for pointing it out.

b. Is chain definition (how you build a chain of services) within the scope
of Global policy BP? A chain may need to be more than an ordered list of
UUIDs. It needs be a graph with branches anywhere in the chain. Each path
could be considered as a separate chain as well.

Service chain as defined by the following:

https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

which is a Neutron object (service_graph is encapsulated inside
this object; see service_chain resource).

Thanks,
- Stephen

Thanks
Subra

I will gather all the feedback by Wednesday and update the
document before this coming Thursday's meeting.

Thanks,
- Stephen

[1]
http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
[2]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Windows instances with password-less authentication

2013-12-17 Thread Alessandro Pilotti

Hi guys,

We got password-less authentication properly working in Windows, implemented 
and included in Cloudbase-Init.

Here’s a blog post explaining how it works:
http://www.cloudbase.it/windows-without-passwords-in-openstack/

And the gory details:
https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/plugins/windows/winrmcertificateauth.py

It works with the existing OpenStack bits, but IMO we need to improve the 
certificate support in Nova and Horizon.

To cut it short, Windows uses a service called WinRM, which can use HTTPS as 
transport option and can be configured to use X509
certificates for authentication.
The result is that you can get a remote PowerShell by simply having the 
certificate + private key, without needing the user's password.

What’s happening here is very similar to how keypairs are used, especially 
considering that for the time being we are using self signed
certificates.

Since we need to pass the x509 certificate via metadata and since the custom 
metadata fields can get up to 255 chars,
we got to the following working solution which is IMO at the limit between 
being almost usable and a crazy hack. :-)

declare -a CERT=(`openssl x509 -inform pem -in your_cert.pem -outform der | 
base64 -w 0 |sed -r 's/(.{255})/\1\n/g'`)
 nova boot  --flavor 2 --image your_windows_image --key-name key1 vm1 \
--meta admin_cert0=${CERT[0]} \
--meta admin_cert1=${CERT[1]} \
--meta admin_cert2=${CERT[2]} \
--meta admin_cert3=${CERT[3]} \
--meta admin_cert4=${CERT[4]}”

As an alternative, to make life easier for the users, we accept the X509 PEM 
file in the user_data as well.

What we really need to improve the user experience is to manage the 
certificates in a way similar to how we manage keypairs today.

Some initial discussion ideas:

1) improve Nova keypairs to support X509 certs as well, non only simple keypairs

2) improve nova-cert to handle client side certificates. This would give the 
additional advantage
to manage certificates with a centralized CA, not only self signed certificates.

On the nova client side, we need to pass an option to nova boot similar (or in 
alternative) to what we do for the keypairs today.
Likewise, in Horizon there must be a way to choose the certificate when booting 
a VM (with a select or similar UI element, see keypair).

Note1: the certificate used for the client auth requires 2 enhanced key usage 
OIDs: clientAuth and 1.3.6.1.4.1.311.20.2.3 (UPN).
See here for how to generate one with OpenSSL: 
https://github.com/cloudbase/winrm-scripts/blob/master/create-winrm-client-cert.sh

Note2: since SSH can use X509 certificates, this topic might go beyond the 
WIndows specific case.

Ok, looking forward to hear your thoughts!


Thanks,

Alessandro
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints

2013-12-17 Thread Randy Tuttle

Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing 
the modes via the neutron client cli, but have we seen how those modes are 
provided through the dashboard?

Randy

Sent from my iPhone

On Dec 17, 2013, at 9:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com 
wrote:

 Hi, team:
 
 I created a new blueprint to reflect the work we accomplished in the previous 
 POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two 
 weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal 
 was to run dnsmasq as DHCPv6 server and provide both optional information 
 and/or IPv6 address to VM in the tenant network. Below you can find the link 
 to the new blueprints, which are all related to the mid-term goal in Sean’s 
 original proposal.
 
 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless
 
 Please let me know if you have any questions. Thanks!
 
 Shixiong
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unified Guest Agent proposal

2013-12-17 Thread Clint Byrum

Excerpts from Dmitry Mescheryakov's message of 2013-12-17 08:01:38 -0800:
 Folks,
 
 The discussion didn't result in a consensus, but it did revealed a great
 number of things to be accounted. I've tried to summarize top-level points
 in the etherpad [1]. It lists only items everyone (as it seems to me)
 agrees on, or suggested options where there was no consensus. Let me know
 if i misunderstood or missed something. The etherpad does not list
 advantages/disadvantages of options, otherwise it just would be too long.
 Interested people might search the thread for the arguments :-) .
 
 I've thought it over and I agree with people saying we need to move
 further. Savanna needs the agent and I am going to write a PoC for it. Sure
 the PoC will be implemented in project-independent way. I still think that
 Salt limitations overweight its advantages, so the PoC will be done on top
 of oslo.messaging without Salt. At least we'll have an example on how it
 might look.
 
 Most probably I will have more questions in the process, for instance we
 didn't finish discussion on enabling networking for the agent yet. In that
 case I will start a new, more specific thread in the list.

If you're not going to investigate using salt, can I suggest you base
your POC on os-collect-config? It it would not take much to add two-way
communication to it.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

2013-12-17 Thread Stephen Wong

Hi Prasad,

Thanks for the comments, please see responses inline.

On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vella...@oneconvergence.com wrote:
 Hi
 Please see inline 


 On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3w...@midokura.com wrote:

 Hi,

 During Thursday's  group-policy meeting[1], there are several
 policy-rules related issues which we agreed should be posted on the
 mailing list to gather community comments / consensus. They are:

 (1) Conflict resolution between policy-rules
 --- a priority field was added to the policy-rules attributes
 list[2]. Is this enough to resolve conflict across policy-rules (or
 even across policies)? Please state cases where a cross policy-rules
 conflict can occur.
 --- conflict resolution was a major discussion point during
 Thursday's meeting - and there was even suggestion on setting priority
 on endpoint groups; but I would like to have this email thread focused
 on conflict resolution across policy-rules in a single policy first.

 (2) Default policy-rule actions
 --- there seems to be consensus from the community that we need to
 establish some basic set of policy-rule actions upon which all
 plugins/drivers would have to support
 --- just to get the discussion going, I am proposing:


 Or should this be a query the plugin for supported actions and thus the user
 knows what functionality the plugin can support.  Hence there is no default
 supported list.

I think what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.

As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?


 a.) action_type: 'security'action: 'allow' | 'drop'
 b.) action_type: 'qos'action: {'qos_class': {'critical' |
 'low-priority' | 'high-priority' |

'low-immediate' | 'high-immediate' |

'expedite-forwarding'}
  (a subset of DSCP values - hopefully in language that can
 be well understood by those performing application deployments)
 c.) action_type:'redirect'   action: {UUID, [UUID]...}
  (a list of Neutron objects to redirect to, and the list
 should contain at least one element)


 I am not sure making the UUIDs a list of neutron objects or endpoints will
 work well. It seems that it should more higher level such as list of
 services that form a chain. Lets say one forms a chain of services,
 firewall, IPS, LB. It would be tough to expect user to derive the neutron
 ports create a chain of them. It could be a VM UUID.

Service chain is a Neutron object with UUID:

https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain for the users, and users simply pick that as one of the
redirect action object to send traffic to.



 Please discuss. In the document, there is also 'rate-limit' and
 'policing' for 'qos' type, but those can be optional instead of
 required for now

 (3) Prasad asked for clarification on 'redirect' action, I propose to
 add the following text to document regarding 'redirect' action:

 'redirect' action is used to mirror traffic to other destinations
 - destination can be another endpoint group, a service chain, a port,
 or a network. Note that 'redirect' action type can be used with other
 forwarding related action type such as 'security'; therefore, it is
 entirely possible that one can specify {'security':'deny'} and still
 do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
 specified on the list CANNOT be the endpoint-group who provides this
 policy. Also, in case of destination being another endpoint-group, the
 policy of this new destination endpoint-group will still be applied


 As I said above one needs clarity on what these UUIDs mean. Also do we need
 a call to manage the ordered list around adding, deleting.listing the
 elements in the list.
 One other issue that comes up whether the classifier holds up along the
 chain. The classifier that goes into the chain might not be the same on the
 reverse path.

The redirect list does not define a service chain, a service chain
is defined via other Neutron APIs. The redirect list itself is not
order sensitive.

Thanks,
- Stephen


 Please discuss.

 (4)  We didn't get a chance to discuss this during last Thursday's
 meeting, but there has been discussion on the document regarding
 adding IP address fields in the classifier of a policy-rule. Email may
 be a better forum to state the use cases. Please discuss

Re: [openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

2013-12-17 Thread Yi Sun




On 12/17/13, 6:36 AM, Erik Moe wrote:


Hi,

thanks for your comments.

see answers below.

Thanks,
Erik


On Tue, Dec 17, 2013 at 6:17 AM, Isaku Yamahata 
isaku.yamah...@gmail.com mailto:isaku.yamah...@gmail.com wrote:


Added openstack-dev

The document is view-only. So I commented below.

- 2 Modeling proposal
  What's the purpose of trunk network?
  Can you please add a use case that trunk network can't be
optimized away?


In some use cases the trunk network will trunk all VLANS from a VM, so 
they can for example be 'tunneled' to another VM or externally. In the 
use case where a VM wants to connect to multiple Neutron networks, the 
trunk network is a logical connection between the VM trunk port and 
the L2-gateways. From my point of view it looks a little strange for 
this use case, but I think this is what we said during our meeting in 
Hong Kong (Unless I misunderstood something...).


I added use case where two VMs are connected through a trunk network. 
This can not be optimized away. The network would have to be able to 
trunk all VLANs between the VMs.
I see the case where admin user wants to have more than one L2 gateways 
to talk to the same VM trunk port. Also, these L2 gateways may connected 
to the untagged networks that belongs different tenants. The trunk 
network should belong to a single tenant though.

Yi

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation