[openstack-dev] Debian already using Python 3.5: please gate on that
Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Specify a domain in mapping rules
Hi all,
I'm a Python/Django software developer [1]. We have to do an integration
of OpenStack and a Shibboleth IdP in my current project.
This is not a easy feature to configure... but finally we got it :-) Now we
only need specify a domain for the user different to the Federated
default domain. This domain depends on an attribute from the IdP.
Is it possible to get with stable/kilo branch? Is it a feature for the next
release? [2] These are my rules:
[
{
local: [
{
user: {
name: {0},
domain: {
name: {1}
}
}
},
{
group: {
id: 0ff59ec2f97646eb9350fe75478f9600
}
}
],
remote: [
{
type: identity
},
{
type: domain
}
]
}
]
I have tested with a lot of rules with little changes:
domain: {
name: Default
}
or
domain: {
id: default
}
or
domain: {
id: 14321243
}
etc... and this never works :-(
Could you help me?
REF's
1. https://github.com/goinnn
2.
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst
Thanks a lot!!,
--
Pablo Martín
Software engineer
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] V3 Authentication for swift store
Hi Jamie,
Glance has another way of specifying the swift credentials for the single
tenant store which may (?) be useful here.
In glance-swift.conf you can specify something like:
[ref1]
user = tenant:user1
key = key1
auth_address = auth...@example.com
which means that in the database 'ref1' is stored instead of the
credentials: the location ends up looking something like:
swift+config://ref1@swift/container/object
The swift+config schema is used to indicate the real creds should be
fetched from the config file. (This avoids having to put them in the
database which isn't desirable and complicates password changing.)
We'd have to think about corner cases (I think --copy-from should be ok).
-Stuart
Hey everyone,
TL;DR: glance_store requires a way to do v3 authentication to the swift backend.
The keystone team is making a push to properly deprecate the v2 authentication
APIs this cycle. As part of that we have a series of devstack reviews that
moves devstack over to only using v3 APIs[1] and an experimental gate job that
runs devstack with the keystone v2 api disabled.
The current blocker for this gate job is that in glance's single-tenant swift
backend mode the config options only allow v2 authentication.
Looking at glance store the username and password are stored as part of the
location parameter in the form:
swift://username:project_name:password@keystone/container
even though devstack is still using the (deprecated?)
swift_store_user = username:project_name
swift_store_key = password
swift_store_container = container
I don't know how this relates to swift_store_config_files.
There is support for v3 in swiftclient (though it's kind of ugly), to do v3
authentication i have to do:
c = swiftclient.Connection(authurl='http://keystoneurl:5000/v3',
user=username,
key=password,
auth_version='3',
os_options={'project_name': project_name,
'project_domain_id': 'default',
'user_domain_id': 'default'})
However in future we are trying to open up authentication so it's not limited
to only user/password authentication. Immediate goals for service to service
communications are to enable SSL client certificates and kerberos
authentication. This would be handled by keystoneclient sessions but they are
not supported by swift and it would require a significant rewrite of
swiftclient to do, and the swift team has indicated they do not which to invest
more time into their client.
This leads me to my question: How do we support additional authentication
parameters and in future different parameters?
We could undo the deprecation of the config file specified credentials and add
the additional options there. This would get us the short term win of moving to
v3 auth but would need to be addressed in future for newer authentication
mechanissms.
I wrote a blog a while ago regarding how sessions supports loading different
types of authentication from conf files[2], however as swiftclient doesn't
support this the best it could do is fetch a url/token combo with which glance
could make requests and it would have to handle reauthentication and retries
somewhat manually. I actually think rewriting the required parts of the client
wouldn't be too difficult, the problem then is whether this should live in
glance or in swiftclient. This would also involve credentials in the config
file rather than the location option.
I'm not overly familiar with glance_store so there may be other options or what
i've suggested may not be possible but I'd love to hear some opinions from the
glance team as this is quickly becoming a blocker for keystone.
Thanks,
Jamie
[1] https://review.openstack.org/#/c/186684/
[2] http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. Thoughts? -jay [1] https://review.openstack.org/#/c/169201/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?
Hi Rick, In Keystone, Domains are the container of users, so a user belongs to a domain and you can grant role assignments for projects. With this call that you made, you will set the project default to this user, after that you need to grant a role for this user in this project. So, you can do:* openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME* and after that, you can verify if the assignment works doing:* openstack role list --user USER_NAME --projec TENANT_ID* You can find more information about this here: http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html or find us on #openstack-keystone Cheers, Raildo Mascena On Tue, Jun 16, 2015 at 1:52 PM Rich Megginson rmegg...@redhat.com wrote: Using admin token credentials with the Keystone v2.0 API and the openstackclient, doing this: # openstack project create bar --enable # openstack user create foo --project bar --enable ... The user will be added to the project. Using admin token credentials with the Keystone v3 API and the openstackclient, using the v3 policy file with is_admin:1 added just about everywhere, doing this: # openstack project create bar --domain Default --enable # openstack user create foo --domain Default --enable --project $project_id_of_bar ... The user will NOT be added to the project. Is this intentional? Am I missing some sort of policy to allow user create to add the user to the given project? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?
On 06/18/2015 06:43 AM, Raildo Mascena wrote: Hi Rick, In Keystone, Domains are the container of users, so a user belongs to a domain and you can grant role assignments for projects. With this call that you made, you will set the project default to this user, after that you need to grant a role for this user in this project. So, you can do:* openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME* * * and after that, you can verify if the assignment works doing:* openstack role list --user USER_NAME --projec TENANT_ID* * * You can find more information about this here:**http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html or find us on #openstack-keystone Yes, I realize that. My issue was that in going from Keystone v2.0 to v3, openstack user create --project $project changed behavior - in v2.0, openstack user create --project $project adds the user as a member of the $project. I wanted to know if this was 1) intentional behavior in v2.0 2) intentionally removed in v3. I'm trying to make puppet-keystone work with v3, while at the same time making sure all of the existing puppet manifests work exactly as before. Since this has changed, I had to work around it, by making the puppet-keystone user create function also add the user to the project. https://review.openstack.org/#/c/174976/24/lib/puppet/provider/keystone_user/openstack.rb Cheers, Raildo Mascena On Tue, Jun 16, 2015 at 1:52 PM Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: Using admin token credentials with the Keystone v2.0 API and the openstackclient, doing this: # openstack project create bar --enable # openstack user create foo --project bar --enable ... The user will be added to the project. Using admin token credentials with the Keystone v3 API and the openstackclient, using the v3 policy file with is_admin:1 added just about everywhere, doing this: # openstack project create bar --domain Default --enable # openstack user create foo --domain Default --enable --project $project_id_of_bar ... The user will NOT be added to the project. Is this intentional? Am I missing some sort of policy to allow user create to add the user to the given project? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot
On 06/18/2015 07:08 AM, Deepak Shetty wrote: On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander b...@swartzlander.org mailto:b...@swartzlander.org wrote: On 06/03/2015 12:43 PM, Deepak Shetty wrote: On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov vponomar...@mirantis.com mailto:vponomar...@mirantis.com wrote: Deepak, transfer-* is not suitable in this particular case. Usage of share networks causes creation of resources, when transfer does not. Also in this topic we have creation of new share based on some snapshot. In the original mail it was said: From user point of view, he may want to copy share and use its copy in different network and it is valid case. So create share from snapshot, then transfer that share to a different tenant , doesn't that work ? Transferring shares between tenants is not something we've discussed before. The cinder project allows transferring of volumes but its easier for them to implement that feature because they don't have the concepts of share networks and share servers to tie the share to a tenant. We implemented public shares which allows a similar use case where 1 tenant can allow others to read/write to a share and should address many of the same use cases that share transferring would address. -Ben Valeriy On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty dpkshe...@gmail.com mailto:dpkshe...@gmail.com wrote: On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas duncan.tho...@gmail.com mailto:duncan.tho...@gmail.com wrote: On 28 May 2015 at 13:03, Deepak Shetty dpkshe...@gmail.com mailto:dpkshe...@gmail.com wrote: Isn't this similar to what cinder transfer-* cmds are for ? Ability to transfer cinder volume across tenants So Manila should be implementing the transfer-* cmds, after which admin/user can create a clone then initiate a transfer to a diff tenant ? Cinder doesn't seem to have any concept analogous to a share network from what I can see; the cinder transfer commands are for moving a volume between tenants, which is a different thing, I think. I agree that 'share transfer' (like volume transfer of cinder) would be more complex, but shouldn't be impossible. IIUC Its eq to creating a new share for the destination tenant (which is same as create share for that tenant) and then copy data (or allow backend to optimize if possible) then delete the source share Yes, we can implement a share transfer, but I'm arguing that we don't need to. Such a feature would be a lot of effort to implement for (arguably) little gain. Yes, cinder doesn't have any eq of share network. But my comment was from the functionality perpsective. In cinder transfer-* commands are used to transfer ownership of volumes across tenants. IIUC the ability in Manila to create a share from snapshot and have that share in a different share network is eq to creating a share from a snapshot for a different tenant, no ? Share networks are typically 1-1 with tenant network AFAIK, correct me if i am wrong Didn't knew this just wondering, this means the public share can be accessed by multiple tenants ? Doesn't that break the tenant isolation ? Yes this was the point of public shares. It doesn't break tenant isolation any more than a feature like share transfer would. It's optional and you have to turn it on explicitly on a per-share basis. Also, the most common application for public shares would be in a read-only mode, so the possibility for bad things to happen is very small. thanx, deepak -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stackforge projects are not second class citizens
On 06/16/2015 08:16 PM, Georgy Okrokvertskhov wrote: In Murano project we do see a positive impact of BigTent model. Since Murano was accepted as a part of BigTent community we had a lot of conversations with potential users. They were driven exactly by the fact that Murano is now officially recognized in OpenStack community. It might be a wrong perception, but this is a perception they have. +1, the same experience as we had with ironic-inspector (former ironic-discoverd) Most of the guys we met are enterprises for whom catalog functionality is interesting. The problem with enterprises is that their thinking periods are often more than 6-9 months. They are not individuals who can start contributing over a night. They need some time to create proper org structure changes to organize development process. The benefits of that is more stable and predictable development over time as soon as they start contributing. Thanks Gosha On Tue, Jun 16, 2015 at 4:44 AM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: You may also find my explanation about the Big Tent helpful in this interview with Niki Acosta and Jeff Dickey: http://blogs.cisco.com/cloud/ospod-29-jay-pipes Best, -jay On 06/16/2015 06:09 AM, Flavio Percoco wrote: On 16/06/15 04:39 -0400, gordon chung wrote: i won't speak to whether this confirms/refutes the usefulness of the big tent. that said, probably as a by-product of being in non-stop meetings with sales/ marketing/managers for last few days, i think there needs to be better definitions (or better publicised definitions) of what the goals of the big tent are. from my experience, they've heard of the big tent and they are, to varying degrees, critical of it. one common point is that they see it as greater fragmentation to a process that is already too slow. Not saying this is the final answer to all the questions but at least it's a good place to start from: https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/the-big-tent-a-look-at-the-new-openstack-projects-governance That said, this is great feedback and we may indeed need to do a better job to explain the big tent. That presentation, I believe, was an attempt to do so. Flavio just giving my fly-on-the-wall view from the other side. On 15/06/2015 6:20 AM, Joe Gordon wrote: One of the stated problems the 'big tent' is supposed to solve is: 'The binary nature of the integrated release results in projects outside the integrated release failing to get the recognition they deserve. Non-official projects are second- or third-class citizens which can't get development resources. Alternative solutions can't emerge in the shadow of the blessed approach. Becoming part of the integrated release, which was originally designed to be a technical decision, quickly became a life-or-death question for new projects, and a political/community minefield.' [0] Meaning projects should see an uptick in development once they drop their second-class citizenship and join OpenStack. Now that we have been living in the world of the big tent for several months now, we can see if this claim is true. Below is a list of the first few few projects to join OpenStack after the big tent, All of which have now been part of OpenStack for at least two months.[1] * Mangum - Tue Mar 24 20:17:36 2015 * Murano - Tue Mar 24 20:48:25 2015 * Congress - Tue Mar 31 20:24:04 2015 * Rally - Tue Apr 7 21:25:53 2015 When looking at stackalytics [2] for each project, we don't see any noticeably change in number of reviews, contributors, or number of commits from before and after each project joined OpenStack. So what does this mean? At least in the short term moving from Stackforge to OpenStack does not result in an increase in development resources (too early to know about the long term). One of the three reasons for the big
Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot
On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander b...@swartzlander.org wrote: On 06/03/2015 12:43 PM, Deepak Shetty wrote: On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov vponomar...@mirantis.com wrote: Deepak, transfer-* is not suitable in this particular case. Usage of share networks causes creation of resources, when transfer does not. Also in this topic we have creation of new share based on some snapshot. In the original mail it was said: From user point of view, he may want to copy share and use its copy in different network and it is valid case. So create share from snapshot, then transfer that share to a different tenant , doesn't that work ? Transferring shares between tenants is not something we've discussed before. The cinder project allows transferring of volumes but its easier for them to implement that feature because they don't have the concepts of share networks and share servers to tie the share to a tenant. We implemented public shares which allows a similar use case where 1 tenant can allow others to read/write to a share and should address many of the same use cases that share transferring would address. -Ben Valeriy On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty dpkshe...@gmail.com wrote: On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas duncan.tho...@gmail.com wrote: On 28 May 2015 at 13:03, Deepak Shetty dpkshe...@gmail.com wrote: Isn't this similar to what cinder transfer-* cmds are for ? Ability to transfer cinder volume across tenants So Manila should be implementing the transfer-* cmds, after which admin/user can create a clone then initiate a transfer to a diff tenant ? Cinder doesn't seem to have any concept analogous to a share network from what I can see; the cinder transfer commands are for moving a volume between tenants, which is a different thing, I think. I agree that 'share transfer' (like volume transfer of cinder) would be more complex, but shouldn't be impossible. IIUC Its eq to creating a new share for the destination tenant (which is same as create share for that tenant) and then copy data (or allow backend to optimize if possible) then delete the source share Yes, cinder doesn't have any eq of share network. But my comment was from the functionality perpsective. In cinder transfer-* commands are used to transfer ownership of volumes across tenants. IIUC the ability in Manila to create a share from snapshot and have that share in a different share network is eq to creating a share from a snapshot for a different tenant, no ? Share networks are typically 1-1 with tenant network AFAIK, correct me if i am wrong Didn't knew this just wondering, this means the public share can be accessed by multiple tenants ? Doesn't that break the tenant isolation ? thanx, deepak -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/18/2015 06:49 AM, Sean Dague wrote: On 06/18/2015 03:28 AM, ozamiatin wrote: Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack; localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Improvement of the blueprint specs template
I realize, that discussing this topic in the email is hard. I filed a review request with some changes to the template and invite you folks to take a look at that: https://review.openstack.org/193070 https://review.openstack.org/193070 16 черв. 2015 о 17:08 Roman Prykhodchenko m...@romcheg.me написав(ла): Hi folks! I was reviewing one of specs for Fuel 7.0 and realized the information there is messed up and it’s pretty hard to put it all together. The reason for that is basically that Fuel is a multicomponent project but the template does not consider that — there is a Proposed change section which is used to define all the changes in the entire project; then there is the API and Data impact sections that are specific to only specific components but still have to be filled in. Since most of new features consider changes to several components I propose to stick to the following structure. It eliminates the need to create several specs to describe one feature and allows to organize everything in one document without messing it up: -- Title -- Excerpt (short version of the Problem description, proposed solution and final results) -- Problem description -- Proposed changes -- Web UI -- Nailgun -- General -- REST API -- Data model -- Astute -- General -- RPC protocol -- Fuel Client -- Plugins -- Impact -- End-user -- QA -- Developer -- Infrastructure (operations) -- Upgrade -- Performance -- Implementation -- Assignee -- Work items -- Web UI -- Nailgun -- Astute -- Fuel Client -- Plugins -- Documentation -- References - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team
Congratulations Brian! Great addition to the L3 team! On Wed, Jun 17, 2015 at 11:14 PM Edgar Magana edgar.mag...@workday.com wrote: Congratulations Brian! Welcome to the team! Edgar On 6/17/15, 3:59 PM, Carl Baldwin c...@ecbaldwin.net wrote: It has been a week and feedback has been positive and supportive of Brian's nomination. Welcome to the L3 core reviewer team, Brian. Carl On Wed, Jun 10, 2015 at 1:11 PM, Carl Baldwin c...@ecbaldwin.net wrote: Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose Brian Haley as a member of the Neutron L3 core reviewer team. Brian has been a long time contributor in Neutron showing expertise particularly in IPv6, iptables, and Linux kernel matters. His knowledge and involvement will be very important especially in this area. Brian has become a trusted member of our community. His review stats [2][3][4] place him comfortably with other Neutron core reviewers. He regularly runs proposed patches himself and gives insightful feedback. He has shown a lot of interest in the success of Neutron. Existing Neutron core reviewers from the L3 area of focus, please vote +1/-1 for the addition of Brian to the core reviewer team. Specifically, I'm looking for votes from Henry, Assaf, and Mark. Thanks! Carl [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=brian-haleymetric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] Mid-cycle sprint
Hi Adam, Thanks for the offer! It'd definitely be great to join you all in Boston, but I'm guessing the logistics aren't going to work out. Most of the people I've heard from are in the Bay Area, which makes it hard to host in Boston.But I'll keep it in mind and float it by everyone. Tim On Wed, Jun 17, 2015 at 7:20 PM Adam Young ayo...@redhat.com wrote: How many people do you think you will have? We have a midcycle in Boston University, July 15-17 and you are welcome to join in. I am pretty sure we will have more than enough capacity, considering the size of the Congress team. Hotels might be a bit of an issue, as we are getting close, and they are starting to book up, but the BU admin has let us know that we can get dorm space is people so desire. On 06/16/2015 05:13 PM, Tim Hinrichs wrote: Hi all, In the last couple of IRCs we've been talking about running a mid-cycle sprint focused on enabling our message bus to span multiple processes and multiple hosts. The message bus is what allows the Congress policy engine to communicate with the Congress wrappers around external services like Nova, Neutron. This cross-process, cross-host message bus is the platform we'll use to build version 2.0 of our distributed architecture. If you're interested in participating, drop me a note. Once we know who's interested we'll work out date/time/location details. Thanks! Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][db] online schema upgrades
my initial proposal for scripted expand/contract migrations is up:
https://review.openstack.org/#/c/192937/
On 6/18/15 5:54 AM, Anna Kamyshnikova wrote:
On Wed, Jun 17, 2015 at 8:23 PM, Mike Bayer mba...@redhat.com
mailto:mba...@redhat.com wrote:
On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:
Ihar, thanks for bringing this up!
This is very interesting and I think it worth trying. I'm +1 on
that and want to participate in this work.
Awesome.
In fact a lot *not strict* migrations are removed with
juno_initial, so I hope it won't be so hard for now to apply
stricter rules for migration. But what is the plan for those
migrations that are *not strict* now?
Still, we have several live data migrations from Juno to Kilo:
- - 14be42f3d0a5_default_sec_group_table.py: populates db with default
security groups;
- - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
extraqdhcpopts with default ip_version = 4;
- - 2d2a8a565438_hierarchical_binding.py: populates db with
port_binding_levels objects, then drops old tables;
- - 35a0f3365720_add_port_security_in_ml2.py: port security field is
populated with True for ports and networks;
- - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
column from subnetpools: probably unused so we can be ok with it?..
In any case, the plan for existing migration rules is: don't touch
them. Their presence in N release just indicates that we cannot get
online db migration in N+1. That's why we should adopt strict rules
the earlier the better, so that opportunity does not slip to N+X where
X is too far.
The patches currently in review that look suspicious in this regard are:
- - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
into another;
- - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
default server values (why is it even needed?..);
- - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
we are ok with it;
- - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
though since it touches existing live data impact rule?
I made a list of migrations from juno- kilo that are non
expansive or do data migrations:
*these contain drop column:*
034883111f_remove_subnetpool_allow_overlap.py
2d2a8a565438_hierarchical_binding.py
*these contain drop table:*
28c0ffb8ebbd_remove_mlnx_plugin.py
2b801560a332_remove_hypervneutronplugin_tables.py
408cfbf6923c_remove_ryu_plugin.py
57086602ca0a_scrap_nsx_adv_svcs_models.py
*these contain data migrations:*
14be42f3d0a5_default_sec_group_table.py
16cdf118d31d_extra_dhcp_options_ipv6_support.py
2b801560a332_remove_hypervneutronplugin_tables.py
2d2a8a565438_hierarchical_binding.py
35a0f3365720_add_port_security_in_ml2.py
*Example of failure:*
neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
- drops the following columns:
op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings',
'foreignkey')
op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
op.drop_column('ml2_dvr_port_bindings', 'segment')
op.drop_column('ml2_dvr_port_bindings', 'driver')
op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
op.drop_column('ml2_port_bindings', 'driver')
op.drop_column('ml2_port_bindings', 'segment')
which then causes a failure in Juno:
OperationalError: (OperationalError) (1054, Unknown column
'ml2_port_bindings_1.driver' in 'field list')
In M release we will be able to create kilo_initial migration that
will hide all these migrations(juno - kilo), so I as there is nothing
we can do we won't touch them as Ihar said. The problem about
migrations that are on review is more serious, as we should adopt
strict rules as early as possible and all core reviewer should be
aware about that.
To Ihar's list of migrations on review I can add :
I3426b13eede8bfa29729cf3efea3419fb91175c4 - insert some data,
I9cf36e1fd3a009c175e0d475af407a30f4e5c408 (almost ready to be merged!)
- drop tables.
And there are a lot changes with altering columns. One is merged in
neutron-vpnaas.
So we should decide these things quickly.
(the list can be incomplete)
I think that we should try to use Alembic as much we could as
Mike is going to support us in that and we have time to make
some change in Alembic directly.
Yes, sure, I'm looking forward to see Mike's proposal in public.
We should undoubtedly plan this work for M release because there
will be some issues that will appear in the process.
Sure. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
On 6/18/15, 08:44, Thomas Goirand z...@debian.org wrote: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). Cheers, Thomas Goirand (zigo) Does this mean that Debian is going to ignore classifiers for all projects that list 3.4 without listing 3.5 and will start reporting bugs against them before upstream projects have time to start testing against 3.5? Why is Debian running tests against versions of python that upstream doesn't claim to support? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] setup.py executable bit
On 06/17/2015 03:24 PM, Ian Cordasco wrote: On 6/17/15, 13:53, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-17 14:47:48 -0400 (-0400), Doug Hellmann wrote: +1 both to using -x and to removing the shebang. Agreed. We don't want anyone directly invoking this file as an executable script in PBR-based packages, so I'm strongly in favor of anything we can do to actively discourage that. -- Jeremy Stanley Agreed as well. Most places advocate using python setup.py [command] [command] so using -x and removing the shebang makes perfect sense to me. ++ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin, You are right. To avoid overloading the app catalog servers, Solum operators can (should?) have local copies of the languagepacks (LPs) in their Glance/Swift installations which are part of their Solum install. Solum currently does have the ability to download LPs from Glance or Swift and use them to build application containers. Solum internally maintains metadata about each LP. One of attributes in this is to identify whether an LP is an operator LP. The LPs that an operator downloads from the app catalog would be marked as operator LPs in Solum. Also, I would assume that operators would define a process to periodically refresh these LPs from the app catalog. Currently operator LPs are available for all the tenants in Solum. Such LPs are downloaded only the first time on the hosts that build application containers, when an application that depends on that LP is built for the very first time. After that the LP is cached on the host. So the Docker daemon on that host does not need to download it again. Solum also provides configurable option to delete LPs to control hosts' disk usage. We have not yet solved how to enable a tenant to make public the LPs that they create (i.e. make their LPs available to other tenants). The solution for this would be different for different backends. I believe that Glance has a way to make images public. So we could use that for Glance. - Devdatta From: Fox, Kevin M kevin@pnnl.gov Sent: Wednesday, June 17, 2015 8:28 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks That would work, but would be a per tenant thing? So if you had lots of tenants using the same image, it would redownloaded lots of times. Are there any plans for glance integration so the cloud deployer could cache it in the image catalog? I seem to remember a version of docker that could use glance directly? Thanks, Kevin From: Adrian Otto Sent: Wednesday, June 17, 2015 5:31:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You’d want an async proceed to keep it continually updated though. Adrian On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote: so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Hi Sean, Thanks a lot for the plugin! I was a little bit confused with a commit message and dropping of drivers support. It turns really not so hard to test zeromq driver with plugin. So I have no objections any more and removing my -1. But I also agree with Doug Hellmann and other speakers that we should not make such changes so fast. Thanks, Oleksii 6/18/15 16:36, Sean Dague пишет: On 06/18/2015 06:49 AM, Sean Dague wrote: On 06/18/2015 03:28 AM, ozamiatin wrote: Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack; localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/18/2015 09:54 AM, ozamiatin wrote: Hi Sean, Thanks a lot for the plugin! I was a little bit confused with a commit message and dropping of drivers support. It turns really not so hard to test zeromq driver with plugin. Yes, that was the design goal with the whole plugin mechanism. To provide an experience that was so minimally different from vanilla devstack, that most people would never even notice. It's honestly often easier to explain to people how to enable a service via a plugin than the config variables in tree. So I have no objections any more and removing my -1. Cool, great. It would be great if you or someone else could post a review to pull this code into gerrit somewhere. You'll need the code in gerrit to use it in devstack-gate jobs, as we don't allow projects outside of gerrit to be cloned during tests. But I also agree with Doug Hellmann and other speakers that we should not make such changes so fast. The reason I didn't think the time table was unreasonable was how quick this transition could be made, and how little code is needed to make one of these plugins. And the fact that from there on out you get to be in control of landing fixes or enhancements for your backend on the timetable that works for you. It will make getting the devstack-gate jobs working reliably a lot simpler and quicker for your team. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum][Mistral] Help with a patch
Hi, Devdatta! Thank you for catching this and for the patch. I already reviewed it and it has been merged. -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
yay! thanks Sean. -- dims On Thu, Jun 18, 2015 at 9:36 AM, Sean Dague s...@dague.net wrote: On 06/18/2015 06:49 AM, Sean Dague wrote: On 06/18/2015 03:28 AM, ozamiatin wrote: Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack; localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Packaged Fuel and Feature Groups
Hi, everyone, could you please clarify a bit about how FEATURE_GROUPS [1] parameter is handled in Fuel. Currently we have it specified at ISO build stage, while from the description of it it looks like it is just a UI switch which doesn't change anything deep inside the code. Can it be changed at master node deployment stage, after master node deployment? Can we use exactly the same nailgun package to install all the different flavors just by changing configuration parameter after package installation? [1] https://ci.fuel-infra.org/job/merged-fuel-specs/Fuel_Development_Specs_build_results/specs/5.1/feature-groups.html#feature-groups -- Aleksandra Fedorova Fuel Devops Engineer bookwar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugins] Using Gerrit workflow for Fuel Plugins Guides
Hi to all, Please, be informed about the following: you can now use Gerrit workflow for creating your Plugin Guides. Previously, you had to send a pdf that was less flexible way of writing and reviewing. You can find detailed instructions and recommendations at Fuel Plugins wiki page [1]. Please, feel free to ask questions and provide feedback. Thanks! [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Following_Gerrit_workflow -- Best regards, Irina Partner Management Business Analyst skype: ira_live __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [trove]Any process of redis configuration group
Hi all, We're trying to implement redis configuration group for trove. Now I can see the blueprint in http://specs.openstack.org/openstack/trove-specs/specs/liberty/redis-configuration-groups.html But is anyone working on it now? It would be better to know about the process about it and help for the community.__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Expected Manila behavior for creation of share from snapshot
On Thu, Jun 18, 2015 at 6:16 PM, Ben Swartzlander b...@swartzlander.org wrote: On 06/18/2015 07:08 AM, Deepak Shetty wrote: On Thu, Jun 18, 2015 at 8:43 AM, Ben Swartzlander b...@swartzlander.org wrote: On 06/03/2015 12:43 PM, Deepak Shetty wrote: On Tue, Jun 2, 2015 at 4:42 PM, Valeriy Ponomaryov vponomar...@mirantis.com wrote: Deepak, transfer-* is not suitable in this particular case. Usage of share networks causes creation of resources, when transfer does not. Also in this topic we have creation of new share based on some snapshot. In the original mail it was said: From user point of view, he may want to copy share and use its copy in different network and it is valid case. So create share from snapshot, then transfer that share to a different tenant , doesn't that work ? Transferring shares between tenants is not something we've discussed before. The cinder project allows transferring of volumes but its easier for them to implement that feature because they don't have the concepts of share networks and share servers to tie the share to a tenant. We implemented public shares which allows a similar use case where 1 tenant can allow others to read/write to a share and should address many of the same use cases that share transferring would address. -Ben Valeriy On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty dpkshe...@gmail.com wrote: On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas duncan.tho...@gmail.com wrote: On 28 May 2015 at 13:03, Deepak Shetty dpkshe...@gmail.com wrote: Isn't this similar to what cinder transfer-* cmds are for ? Ability to transfer cinder volume across tenants So Manila should be implementing the transfer-* cmds, after which admin/user can create a clone then initiate a transfer to a diff tenant ? Cinder doesn't seem to have any concept analogous to a share network from what I can see; the cinder transfer commands are for moving a volume between tenants, which is a different thing, I think. I agree that 'share transfer' (like volume transfer of cinder) would be more complex, but shouldn't be impossible. IIUC Its eq to creating a new share for the destination tenant (which is same as create share for that tenant) and then copy data (or allow backend to optimize if possible) then delete the source share Yes, we can implement a share transfer, but I'm arguing that we don't need to. Such a feature would be a lot of effort to implement for (arguably) little gain. Well, I would argue that 'transfer' as a API does have value and implementation being simple/complex shouldn't matter as long as there is 'value' in the API, so I disagree a bit here. Yes, cinder doesn't have any eq of share network. But my comment was from the functionality perpsective. In cinder transfer-* commands are used to transfer ownership of volumes across tenants. IIUC the ability in Manila to create a share from snapshot and have that share in a different share network is eq to creating a share from a snapshot for a different tenant, no ? Share networks are typically 1-1 with tenant network AFAIK, correct me if i am wrong Didn't knew this just wondering, this means the public share can be accessed by multiple tenants ? Doesn't that break the tenant isolation ? Yes this was the point of public shares. It doesn't break tenant isolation any more than a feature like share transfer would. It's optional and Not really, public share (IIUC) allows 1 tenant to access/share the share at the same time, while transfer ensures exclusivity to one share at a time, so they are different thanx, deepak you have to turn it on explicitly on a per-share basis. Also, the most common application for public shares would be in a read-only mode, so the possibility for bad things to happen is very small. thanx, deepak -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [os-ansible-deployment] Core team nomination
+1 -- Hugh Saunders On 13 June 2015 at 18:18, Kevin Carter kevin.car...@rackspace.com wrote: Hello, I would like to nominate Ian Cordasco (sigmavirus24 on IRC) for the os-ansible-deployment-core team. Ian has been contributing to the OSAD project for some time now and has always had quality reviews[0], he's landing great patches[1], he's almost always in the meetings, and is simply an amazing person to work with. His open source first attitude, security mindset, and willingness to work cross project is invaluable and will only stand to better the project and the deployers whom consume it. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. Thank you. -- Kevin Carter [0] https://review.openstack.org/#/q/status:closed+owner:%22Ian+Cordasco%22+project:stackforge/os-ansible-deployment,n,z [1] https://review.openstack.org/#/q/status:merged+owner:%22Ian+Cordasco%22+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stackforge projects are not second class citizens
Joe, I must respectfully disagree. The statistics you used to indicate that Magnum did not benefit from joining the tent are not telling the whole story. Facts: 1) When we had our Midcycle just before joining OpenStack in March we had 24 contributors from 13 affiliations when we joined. You were there, remember? We now have 55 contributors from 22 affiliations. 2) There is a ramp time in the number of reviews and commits that newcomers offer. You don't just show up and drop 10 new commits a day. Most of our new contributors have just joined the effort. I can tell by their behavior that they are gearing up to participate in a more meaningful way. They are showing up at team meetings, discussing blueprints, discussing issues on the ML, and just staring to work on a few bugs. I am sure that commits are are trailing indicator of engagement, not a leading one. 3) Contributors who participated the most in the last cycle are not producing as many reviews this time around. Several of them are working on productization strategy and execution to bring related next generation cloud services to market. This focus happens downstream, not upstream. The top commit contributors this cycle are from HP and Intel, who were only minimally involved before we joined OpenStack. 4) As a project proceeds through maturation, commit velocity decreases as the complexity of new features increases. We picked the low hanging fruit for Magnum, and now we are focusing on harder work that requires more planning and collaboration, and less blasting out of try this code. Our quality expectations are higher now. Joining worked for Magnum. When you stay in Stackforge, you have a limited window of time to build community, and then it fades. You don't need to look far to find examples of that. Our community certainly does treat Stackforge projects as second class. The process of starting Magnum reaffirmed that fact for me. I even have reviews where I was explicitly told in -1 vote comments that Stackforge was a second class and that was the point of it. Unfortunately Stackforge's reputation has been fouled because of the way we have treated it. I don't think that can be fixed. Once you are labeled a tramp, you don't recover from that socially. Stackforge is our tramp now, like it or not. Big Tent is our opportunity to build an inclusive community right. Let's not go changing it before we have given it a fair chance first. Thanks, Adrian On Jun 15, 2015, at 3:25 AM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: One of the stated problems the 'big tent' is supposed to solve is: 'The binary nature of the integrated release results in projects outside the integrated release failing to get the recognition they deserve. Non-official projects are second- or third-class citizens which can't get development resources. Alternative solutions can't emerge in the shadow of the blessed approach. Becoming part of the integrated release, which was originally designed to be a technical decision, quickly became a life-or-death question for new projects, and a political/community minefield.' [0] Meaning projects should see an uptick in development once they drop their second-class citizenship and join OpenStack. Now that we have been living in the world of the big tent for several months now, we can see if this claim is true. Below is a list of the first few few projects to join OpenStack after the big tent, All of which have now been part of OpenStack for at least two months.[1] * Mangum - Tue Mar 24 20:17:36 2015 * Murano - Tue Mar 24 20:48:25 2015 * Congress - Tue Mar 31 20:24:04 2015 * Rally - Tue Apr 7 21:25:53 2015 When looking at stackalytics [2] for each project, we don't see any noticeably change in number of reviews, contributors, or number of commits from before and after each project joined OpenStack. So what does this mean? At least in the short term moving from Stackforge to OpenStack does not result in an increase in development resources (too early to know about the long term). One of the three reasons for the big tent appears to be unfounded, but the other two reasons hold. The only thing I think this information changes is what peoples expectations should be when applying to join OpenStack. [0] https://github.com/openstack/governance/blob/master/resolutions/20141202-project-structure-reform-spec.rst [1] Ignoring OpenStackClent since the repos were always in OpenStack it just didn't have a formal home in the governance repo. [2] hhttp://stackalytics.com/?module=openstackclient-groupmetric=commitshttp://stackalytics.com/?module=magnum-groupmetric=commits __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [trove]Any process of redis configuration group
Hi chendi...@unitedstack.commailto:chendi...@unitedstack.com, (you forgot to identify yourself ;) ) A quick search in gerrit turned up the following review for ‘Configuration Groups for Redis’: https://review.openstack.org/#/c/191860 Hope that helps! Thanks, Peter From: 陈迪豪 [mailto:chendi...@unitedstack.com] Sent: June-18-15 10:14 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [trove]Any process of redis configuration group Hi all, We're trying to implement redis configuration group for trove. Now I can see the blueprint in http://specs.openstack.org/openstack/trove-specs/specs/liberty/redis-configuration-groups.html But is anyone working on it now? It would be better to know about the process about it and help for the community. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove]Any process of redis configuration group
Hi, Yes, someone is working on this (see assignee in the blueprint), the blueprint is the first step of the process. You’ll likely get more out of the community if you participated on IRC at #openstack-trove. Many contributors to the project participate in a weekly meeting which is held on Wednedays at 18:00 UTC on #openstack-meeting-alt. Thanks, -amrith From: 陈迪豪 [mailto:chendi...@unitedstack.com] Sent: Thursday, June 18, 2015 10:14 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [trove]Any process of redis configuration group Hi all, We're trying to implement redis configuration group for trove. Now I can see the blueprint in http://specs.openstack.org/openstack/trove-specs/specs/liberty/redis-configuration-groups.html But is anyone working on it now? It would be better to know about the process about it and help for the community. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?
This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3. The default_project_id attribute (***emphasis*** mine): References the user's default project against which to authorize, if the API user does not explicitly specify one when creating a token. ***Setting this attribute does not grant any actual authorization on the project,*** and is merely provided for the user's convenience. Therefore, the referenced project does not need to exist within the user's domain. New in version 3.1 If the user does not have authorization to their default project, the default project will be ignored at token creation. Source: https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#users-v3users In fact, since Grizzly, Keystone has *explicitly* assigned a role (_member_ by default) to users behind the scenes when you try to *implicitly* give them authorization using the v2 user.tenant_id attribute. Prior to the new, more explicit behaviors, default tenancy could not be consumed by RBAC policy engines, because there was nothing explicit about the relationship. On Thu, Jun 18, 2015 at 8:25 AM, Rich Megginson rmegg...@redhat.com wrote: On 06/18/2015 06:43 AM, Raildo Mascena wrote: Hi Rick, In Keystone, Domains are the container of users, so a user belongs to a domain and you can grant role assignments for projects. With this call that you made, you will set the project default to this user, after that you need to grant a role for this user in this project. So, you can do:* openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME* and after that, you can verify if the assignment works doing:* openstack role list --user USER_NAME --projec TENANT_ID* You can find more information about this here: http://docs.openstack.org/user-guide-admin/manage_projects_users_and_roles.html or find us on #openstack-keystone Yes, I realize that. My issue was that in going from Keystone v2.0 to v3, openstack user create --project $project changed behavior - in v2.0, openstack user create --project $project adds the user as a member of the $project. I wanted to know if this was 1) intentional behavior in v2.0 2) intentionally removed in v3. I'm trying to make puppet-keystone work with v3, while at the same time making sure all of the existing puppet manifests work exactly as before. Since this has changed, I had to work around it, by making the puppet-keystone user create function also add the user to the project. https://review.openstack.org/#/c/174976/24/lib/puppet/provider/keystone_user/openstack.rb Cheers, Raildo Mascena On Tue, Jun 16, 2015 at 1:52 PM Rich Megginson rmegg...@redhat.com wrote: Using admin token credentials with the Keystone v2.0 API and the openstackclient, doing this: # openstack project create bar --enable # openstack user create foo --project bar --enable ... The user will be added to the project. Using admin token credentials with the Keystone v3 API and the openstackclient, using the v3 policy file with is_admin:1 added just about everywhere, doing this: # openstack project create bar --domain Default --enable # openstack user create foo --domain Default --enable --project $project_id_of_bar ... The user will NOT be added to the project. Is this intentional? Am I missing some sort of policy to allow user create to add the user to the given project? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Liberty cycle client features releases planning
Hi sahara folks, I'd like to ask you to fill features you'd like to add to the sahara client during the Liberty cycle. Please, add links to the specs / CRs, put your name to have a contact. If you have an idea, when the patch will be ready, put the date as well. The main reason for doing it - to keep track of the needed changes and have the official Liberty feature release of client in time (it should be done before the Liberty-3). Etherpad: https://etherpad.openstack.org/p/sahara-liberty-client Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Sean Dague's message of 2015-06-18 07:09:56 -0700: On 06/18/2015 09:54 AM, ozamiatin wrote: Hi Sean, Thanks a lot for the plugin! I was a little bit confused with a commit message and dropping of drivers support. It turns really not so hard to test zeromq driver with plugin. Yes, that was the design goal with the whole plugin mechanism. To provide an experience that was so minimally different from vanilla devstack, that most people would never even notice. It's honestly often easier to explain to people how to enable a service via a plugin than the config variables in tree. +1 So I have no objections any more and removing my -1. Cool, great. It would be great if you or someone else could post a review to pull this code into gerrit somewhere. You'll need the code in gerrit to use it in devstack-gate jobs, as we don't allow projects outside of gerrit to be cloned during tests. But I also agree with Doug Hellmann and other speakers that we should not make such changes so fast. The reason I didn't think the time table was unreasonable was how quick this transition could be made, and how little code is needed to make one of these plugins. And the fact that from there on out you get to be in control of landing fixes or enhancements for your backend on the timetable that works for you. It will make getting the devstack-gate jobs working reliably a lot simpler and quicker for your team. Agreed on all points. I believe that the mistake was simply that there wasn't any need to hold hands for those who we are enabling to move faster and more independently. We do, in fact, need to transfer ownership gracefully. Thanks so much for writing the plugin for zmq, that is a huge win for zmq developers. I can't speak for oslo directly, but it seems like that plugin should land under oslo's direct stewardship and then we can move forward with this. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Packaged Fuel and Feature Groups
Also feature_groups is used for selecting usage statistics collector. If 'mirantis' is in feature_groups we are using one instance of statistics collector and another collector instance in other case. On Thu, Jun 18, 2015 at 7:04 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Hi, Yes, it is possible to change the value of feature_groups after master node installation. Currently it affects only availability of a few options in Fuel UI. 2015-06-18 17:11 GMT+03:00 Aleksandra Fedorova afedor...@mirantis.com: Hi, everyone, could you please clarify a bit about how FEATURE_GROUPS [1] parameter is handled in Fuel. Currently we have it specified at ISO build stage, while from the description of it it looks like it is just a UI switch which doesn't change anything deep inside the code. Can it be changed at master node deployment stage, after master node deployment? Can we use exactly the same nailgun package to install all the different flavors just by changing configuration parameter after package installation? [1] https://ci.fuel-infra.org/job/merged-fuel-specs/Fuel_Development_Specs_build_results/specs/5.1/feature-groups.html#feature-groups -- Aleksandra Fedorova Fuel Devops Engineer bookwar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] Removing Hadoop 1 support in Liberty
Hi folks, we were discussing the Hadoop 1 support drop on todays meeting [1] and so I'd like to ensure that more people aware about it. So, it you are using Hadoop 1 and would like us to keep it in Sahara, please, tell us about it :) Spec on review [2] already. [1] http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-06-18-14.01.html [2] https://review.openstack.org/#/c/192563/ Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Michael McCune for Security CoreSec
On 06/15/2015 09:16 AM, McPeak, Travis wrote: I¹d like to propose Michael McCune for CoreSec membership. I¹ve worked with Michael (elmiko) on numerous security tasks and bugs, and he has a great grasp on security concepts and is very active in the OpenStack security community. I think he would be a natural choice for CoreSec. +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 18 June 2015 at 09:54, Jay Pipes jaypi...@gmail.com wrote: On 06/18/2015 12:46 PM, Armando M. wrote: On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? OK, cool, glad to hear this. Yes, that would work for me. And yeah, I'll review the [2] proposal. Sweet! Cheers, Armando Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team
It has been a week and feedback has been positive and supportive of Ann's nomination. Welcome to the Neutron DB core reviewer team, Ann. -- Henry On Thu, Jun 11, 2015, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron showing expertise particularly in database matters. She has also worked with and contributed code to the oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the Neutron database healing effort that was completed in the Juno cycle. Her deep knowledge of databases and backends, and her expertise with oslo.db, sqlalchemy and alembic will be very important in this area. Ann is a trusted member of our community and her review stats [2][3][4] place her comfortably with other Neutron core reviewers. She consistently catches database issues early when patches are submitted for review, and shows dedication to helping developers understand and perfect their database-related changes. Existing Neutron core reviewers from the API and DB area of focus, please vote +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl. [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Packaged Fuel and Feature Groups
Hi, Yes, it is possible to change the value of feature_groups after master node installation. Currently it affects only availability of a few options in Fuel UI. 2015-06-18 17:11 GMT+03:00 Aleksandra Fedorova afedor...@mirantis.com: Hi, everyone, could you please clarify a bit about how FEATURE_GROUPS [1] parameter is handled in Fuel. Currently we have it specified at ISO build stage, while from the description of it it looks like it is just a UI switch which doesn't change anything deep inside the code. Can it be changed at master node deployment stage, after master node deployment? Can we use exactly the same nailgun package to install all the different flavors just by changing configuration parameter after package installation? [1] https://ci.fuel-infra.org/job/merged-fuel-specs/Fuel_Development_Specs_build_results/specs/5.1/feature-groups.html#feature-groups -- Aleksandra Fedorova Fuel Devops Engineer bookwar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team
Congratulations Ann and welcome to the team! Edgar On 6/18/15, 8:56 AM, Henry Gessau ges...@cisco.com wrote: It has been a week and feedback has been positive and supportive of Ann's nomination. Welcome to the Neutron DB core reviewer team, Ann. -- Henry On Thu, Jun 11, 2015, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron showing expertise particularly in database matters. She has also worked with and contributed code to the oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the Neutron database healing effort that was completed in the Juno cycle. Her deep knowledge of databases and backends, and her expertise with oslo.db, sqlalchemy and alembic will be very important in this area. Ann is a trusted member of our community and her review stats [2][3][4] place her comfortably with other Neutron core reviewers. She consistently catches database issues early when patches are submitted for review, and shows dedication to helping developers understand and perfect their database-related changes. Existing Neutron core reviewers from the API and DB area of focus, please vote +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl. [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? Thanks, Armando Thoughts? -jay [1] https://review.openstack.org/#/c/169201/ [2] https://review.openstack.org/#/c/192933/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 06/18/2015 12:46 PM, Armando M. wrote: On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? OK, cool, glad to hear this. Yes, that would work for me. And yeah, I'll review the [2] proposal. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec
+1 -TK On Tue, Jun 16, 2015 at 5:28 AM, Clark, Robert Graham robert.cl...@hp.com wrote: I’d like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security project for a couple of years he’s a part of the bandit subproject and has been very active in discussions over this time. He’s also found multiple vulnerabilities and has experience of the VMT process. -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Michael McCune for Security CoreSec
+1 On Mon, Jun 15, 2015 at 12:16 PM, McPeak, Travis travis.mcp...@hp.com wrote: I¹d like to propose Michael McCune for CoreSec membership. I¹ve worked with Michael (elmiko) on numerous security tasks and bugs, and he has a great grasp on security concepts and is very active in the OpenStack security community. I think he would be a natural choice for CoreSec. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec
On 06/16/2015 02:28 AM, Clark, Robert Graham wrote: I’d like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security project for a couple of years he’s a part of the bandit subproject and has been very active in discussions over this time. He’s also found multiple vulnerabilities and has experience of the VMT process. +1 -Rob** __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team
Congratulations! Yamamoto Takashi From: Kevin Benton [mailto:blak...@gmail.com] Sent: Friday, June 19, 2015 3:52 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team It has been a week and I haven't heard any negative feedback. Welcome to the control plane core reviewer team YAMAMOTO Takashi! On Mon, Jun 15, 2015 at 2:52 AM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: +1 On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not on the list either, but I want to +1 what Henry said. Yamamoto's reviews expand to the whole code base and are pretty always *very* usefu l. On 06/12/2015 11:39 PM, Henry Gessau wrote: Although I am not on your list I would like to add my +1! Yamamoto shows great attention to detail in code reviews and frequently finds real issues that were not spotted by others. On Thu, Jun 11, 2015, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his feedback on patches related to the reference implementation has been very useful. This includes everything ranging from the AMPQ API to OVS flows. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/90 Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfpgHAAoJEC5aWaUY1u57z40IAL8HpGOEQY7aW1aa39C9ig3Y bNLEabeQ0K5a4+5ynVLIm1sEl4s3GF2r0gCXak9FrkqjHx2r8VeyOx8TqrCj8gX3 +4aHI7n6rJoJtINuTd+bN7T65uaZE86erOcZN+yma5V69ObfIZhIfQKr3BMaBeZT ah5hkUKl88ckLL5zqc0HnT4wcFH/3Ved2fuhP7hw/IEGMFsqTDS8QUTdXg7/OF5t fLt0NluKoOuNMOk8dTqpqtQtiyS/E5TH+miVOzyrUeUmZOEayOO3O2b/9QRkX/hL ijv1j+clT69fhoVAWSaeR7IsXSfqMuKK/hrVtjnyDpBH4KuZnl3QbRpKJ6Yi3bw= =qnTt -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] V3 Authentication for swift store
- Original Message - From: stuart mclaren stuart.mcla...@hp.com To: openstack-dev@lists.openstack.org Sent: Thursday, 18 June, 2015 7:06:12 PM Subject: Re: [openstack-dev] [glance] V3 Authentication for swift store Hi Jamie, Glance has another way of specifying the swift credentials for the single tenant store which may (?) be useful here. In glance-swift.conf you can specify something like: [ref1] user = tenant:user1 key = key1 auth_address = auth...@example.com which means that in the database 'ref1' is stored instead of the credentials: the location ends up looking something like: swift+config://ref1@swift/container/object The swift+config schema is used to indicate the real creds should be fetched from the config file. (This avoids having to put them in the database which isn't desirable and complicates password changing.) We'd have to think about corner cases (I think --copy-from should be ok). -Stuart snip Interesting, this actually maps really closely with one of the concepts that loading auth plugins from conf already provides. You can say [keystone_authtoken] auth_section = ref1 ... [ref1] auth_plugin = password auth_url = ... username = ... ... So that you can share or separate auth. We can probably leverage something similar here. Is this the correct way to configure glance? Would i be working on a deprecated section of code to make this support plugins? I can't really tell what is recommended from the code. So the question still comes down to fix it properly or get it working. If we configure glance this way i can add user_domain_id, user_domain_name, project_domain_id, project_domain_name to the variables that are read from [ref1] and get v3 support for user/pass that way fairly easily. To move to fully loading auth_plugins we would need to either get swiftclient support for sessions or move to using the HTTP API directly. I'm inclined to just patch it in for now, work on getting swiftclient session support and then use that when ready. Would this be ok? Jamie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove]Any process of redis configuration group
Thanks @peter. Sorry for not identifying myself and I'm tobe in irc. The patch looks great. I would try to review and improve that. Thanks for all your contributions! -- Original -- From: Peter Stachowskipe...@tesora.com; Date: Thu, Jun 18, 2015 11:43 PM To: openstack-dev@lists.openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [trove]Any process of redis configuration group Hi chendi...@unitedstack.com, (you forgot to identify yourself ;) ) A quick search in gerrit turned up the following review for ‘Configuration Groups for Redis’: https://review.openstack.org/#/c/191860 Hope that helps! Thanks, Peter From: 陈迪豪 [mailto:chendi...@unitedstack.com] Sent: June-18-15 10:14 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [trove]Any process of redis configuration group Hi all, We're trying to implement redis configuration group for trove. Now I can see the blueprint in http://specs.openstack.org/openstack/trove-specs/specs/liberty/redis-configuration-groups.html But is anyone working on it now? It would be better to know about the process about it and help for the community.__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] RBAC Policy Basics
Adam, Thank you for the information RBAC Policy Basics. Thursday, June 18, 2015 1:47 AM, Adam Young wrote: However, we have found a need to have a global override. This is a way a cloud admin that can go into any API anywhere and fix things. This means that Glance, Neutron, Nova, and Keystone should be able to share a policy file. What situations does a shared policy file require? For example, there are policy files for Nova and Cinder and they have same targets such as context_is_admin, admin_or_owner and default. (1) load both policy.json files on a server process then the targets will be overridden by 2nd loaded policy.json. A cloud admin changes the 2nd policy.json only. (2) A cloud admin changes the targets in different policy.json files at one time. Did you mention about case(2)? Nova: https://github.com/openstack/nova/blob/master/etc/nova/policy.json Cinder: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json context_is_admin: role:admin, admin_or_owner: is_admin:True or project_id:%(project_id)s, default: rule:admin_or_owner, BTW, I sent the following email in this list. I think I found right person who can answer my question? :-) http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html - HTTP_X_SERVICE_ROLES handling in _checks.py Thanks in advance, Hisashi Osanai __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic
Hi Thai Q Tran, Thanks for the links about the Angular Dashboard, I agree with starting with the new angular horizon, will begin to draft a init repo of the new ironic-dashboard. And maybe can work with Krotscheck together. And as Andreas Jaeger comments here [1], he suggested to push ironic-dashboard in the openstack namespace instead of stackforge, and have a separate core team, needs Ironicers chime in here. [1] https://review.openstack.org/#/c/191131/ Regards -zhenguo From: Thai Q Tran [mailto:tqt...@us.ibm.com] Sent: Friday, June 19, 2015 6:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic Hi Zhengou, I think it make sense to start with the angular version. It's true that we don't have an angular dashboard yet, but we have a pretty good idea of what needs to go into it. I'll link a few patches that will give you an idea of where we are headed. I think this will also save you some work in the long run. For creating a new dashboard: https://review.openstack.org/#/c/190852/ For creating a new panel: https://review.openstack.org/#/c/190865/ For demo patch: https://review.openstack.org/#/c/181253/ The file and code structure I would say is pretty stable. There are still some infra stuff that needs to happen to make this easier to do. Things like translation in static HTML, auto discovery of static files, start dash for angular, etc... -niuzhenguo niuzhen...@huawei.commailto:niuzhen...@huawei.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org From: niuzhenguo niuzhen...@huawei.commailto:niuzhen...@huawei.com Date: 06/17/2015 06:38PM Subject: Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic Hi Krotscheck, Sorry for not attending the last meeting due to TZ. Yes, Horizon is moving towards an Angular application, but for now there’s no any Angular Dashboard landed. I think it’s high time that we should make a standard for other projects which want to horizon compatible on whether they should based on Angular Dashboard or the current Horizon framework. This is important for the new Magnum and Ironic UI, personally, I’d prefer to use the current framework and move to Angular Dashboard when it’s mature. And after a quick look at your JS project, I think it’s totally a standalone UI not based on Horizon Angular Dashboard (correct me if I missed something), and seems there’s no any update over a month, are you planning to push you repo to stackforge or openstack? Anyway, it’s clear that we should make an Ironic dashboard, it’s a good start. Regards -zhenguo From: Michael Krotscheck [mailto:krotsch...@gmail.com] Sent: Wednesday, June 17, 2015 11:56 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic Hey there! Yes, we are duplicating effort. I've spent quite a bit of effort over the past few months landing features inside openstack that will make it possible for a JavaScript client to be imported to horizon as a dependency. This includes CORS, configuration, caching, infra tooling, etc, with the end goal being a maximum amount of code reusability between the standalone UI and Horizon. While it may not appear that way, I _am_ actively working on this project, though I'm currently focused on javascript infrastructure tooling and oslo middleware than the ironic webclient itself. With Horizon also moving towards an angular application, I feel it makes far more sense to build components for the new Horizon than the old one. Michael On Tue, Jun 16, 2015 at 9:02 PM NiuZhenguo niuzhenguo...@hotmail.commailto:niuzhenguo...@hotmail.com wrote: hi folks, I'm planning to propose a new horizon plugin ironic-dashboard to fill the gap that ironic doesn't have horizon support. I know there's a nodes panel on infrastructure dashboard handled by tuskar-ui, but it's specifically geared towards TripleO. Ironic needs a separate dashboard to present an interface for querying and managing ironic's resources (Drivers, Nodes, and Ports). After discussion with the ironic community, I pushed an ironic-dashboard project to stackforge [1]. Also there's an existing JS UI for ironic in developing now [2], we may try to resolve the same goals, but as an integrated openstack project, there's clear needs to have horizon support. I'd like to get what's your suggestion, thanks in advance. [1] https://review.openstack.org/#/c/191131/ [2] https://github.com/krotscheck/ironic-webclient Regards -zhenguo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] V3 Authentication for swift store
- Original Message - From: Alistair Coles alistair.co...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, 18 June, 2015 4:39:52 PM Subject: Re: [openstack-dev] V3 Authentication for swift store -Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 18 June 2015 07:02 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [glance] V3 Authentication for swift store Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. snip However in future we are trying to open up authentication so it's not limited to only user/password authentication. Immediate goals for service to service communications are to enable SSL client certificates and kerberos authentication. This would be handled by keystoneclient sessions but they are not supported by swift and it would require a significant rewrite of swiftclient to do, and the swift team has indicated they do not which to invest more time into their client. If we consider specifically the swiftclient Connection class, I wonder how significant a rewrite would be to support session objects? I'm not too familiar with sessions - is a session an object with an interface to fetch a token and service endpoint url? If so maybe Connection could accept a session in lieu of auth options and call the session rather than its get_auth methods. If we can move towards sessions in swiftclient then that would be good IMHO, since we have also have requirement to support fetching a service token [1], which I guess would (now or in future) also be handled by the session? [1] https://review.openstack.org/182640 Alistair So the sessions work is built on, and is modelled after requests.Session. It consists of two parts, the session which is your transport object involving things like CA certs, verify flags etc and an auth plugin which is how we can handle new auth mechanisms. Once coupled the interface looks very similar to a requests.Session with get(), post(), request() etc methods, with the addition that requests are automatically authenticated and things like the service catalog are handled for you. I wrote a blog post a while back which explains many of the concepts[2]. The fastest way I could see including Sessions into swiftclient would be to create new Connection and HttpConnection objects. Would this be something swift is interested in? I didn't mean to offend when saying that you didn't want to put any more time into the client, there was a whole session in Paris about how the client had problems but it was just going to limp along until SDK was ready. Side note, i don't know how this decision will be affected based on Vancouver conversations about how SDK may not be suitable for service-service communications. Regarding service tokens, we have an auth plugin that is passed down from auth_token middleware that will include X-Service-Token in requests which I think swiftclient would benefit from. Jamie [2] http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-sessions/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Michael McCune for Security CoreSec
+1! -Original Message- From: McPeak, Travis Sent: Monday, June 15, 2015 9:17 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Security] Nominating Michael McCune for Security CoreSec I¹d like to propose Michael McCune for CoreSec membership. I¹ve worked with Michael (elmiko) on numerous security tasks and bugs, and he has a great grasp on security concepts and is very active in the OpenStack security community. I think he would be a natural choice for CoreSec. smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] Status of account creds in the [identity] section of tempest.conf
We had a discussion about this at the qa meeting today around the following proposal: tl;dr The test accounts feature provides the same functionality as the embedded credentials. We should deprecate the account information embedded directly in tempest.conf in favor of test-accounts, and remove those options at the beginning of the M cycle. We would also rework the non-isolated jobs to use parallel test accounts, with and without admin creds. Starting now, new features such as cleanup and tempest config will not be required to work well (or at all) if the embedded creds are used instead of test accounts. We have (at least) three use cases that are important, and we want tempest to work well with all of them, but that means something different in each case: 1. throw-away clouds (ci, gate) 2. test clouds 3. production clouds For (1), the most important thing is that failing tests not cause false negatives in other tests due to re-using a tenant. This makes tenant isolation continue to be a good choice here, and requiring admin is not an issue. In a perfect world where tempest never left behind any resources regardless of an error at any line of code, test accounts could be used. But we are probably a long way from that. For (3), we cannot use admin creds for tempest runs, and test accounts with cleanup allow parallel execution, accepting the risk of a leak causing a false negative. The only way to avoid that risk is to stamp out all leak bugs in tempest. For (2), either isolation or test accounts with cleanup can be used The tempest.conf values are not used in any of these scenarios. Is there a reason they are needed for anything? -David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
On Thu, Jun 18, 2015 at 7:17 PM, Brian Curtin br...@python.org wrote: On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? 3.4 Final is planed for September 13 small type here - 3.5 as per the link you provided :) https://www.python.org/dev/peps/pep-0478/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
On 6/15/2015 6:30 AM, Sean Dague wrote: On 06/11/2015 06:29 AM, Sean Dague wrote: On 06/09/2015 06:42 PM, Jeremy Stanley wrote: As discussed in the Liberty Design Summit Moving apps to Python 3 cross-project workshop, the way forward in the near future is to switch to the pure-python PyMySQL library as a default. https://etherpad.openstack.org/p/liberty-cross-project-python3 To that end, support has already been implemented and tested in DevStack, and when https://review.openstack.org/184493 merges in a day or two this will become its default. Any last-minute objections or concerns? Note that similar work is nearing completion is oslo.db with https://review.openstack.org/184392 and there are also a lot of similar changes in flight for other repos under the same review topic (quite a few of which have already merged). Ok, we've had 2 days fair warning, I'm pushing the merge button here. Welcome to the world of pure python mysql. As a heads up for where we stand. The switch was flipped, but a lot of neutron jobs (rally tempest) went into a pretty high failure rate after it was (all the other high volume jobs seemed fine). We reverted the change here to unwedge things - https://review.openstack.org/#/c/191010/ After a long conversation with Henry and Armando we came up with a new plan, because we want the driver switch, and we want to figure out why it causes a high Neutron failure rate, but we don't want to block everything. https://review.openstack.org/#/c/191121/ - make the default Neutron jobs set some safe defaults (which are different than non Neutron job defaults), but add a flag to make it possible to expose these issues. Then add new non-voting check jobs to Neutron queue to expose these issues - https://review.openstack.org/#/c/191141/. Hopefully allowing interested parties to get to the bottom of these issues around the db layer. It's in the check queue instead of the experimental queue to get enough volume to figure out the pattern for the failures, because they aren't 100%, and they seem to move around a bit. Once https://review.openstack.org/#/c/191121/ is landed we'll revert revert - https://review.openstack.org/#/c/191113/ and get everything else back onto pymysql. -Sean It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging][zeromq] pub/sub support for the revised zeromq driver
On 6/1/15, 5:03 PM, Davanum Srinivas dava...@gmail.commailto:dava...@gmail.com wrote: fyi, the spec for zeromq driver in oslo.messaging is here: https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage .rst,unified The above spec suggests using the zmq pub/sub/xpub/xsub proxy pattern for implementing the oslo messaging fanout API. This is described in the zmq guide (http://zguide.zeromq.org/, search for Figure 13 - Pub-Sub Network with a Proxy). When applied to openstack, this pattern will result in a number of publishers connecting to a potentially large number of proxies (the proposal calls for 1 proxy per node in the cloud), and each proxy connected to a relatively small number of local services (typically agents). All connections in this pattern are based on TCP (for inter-node) and could be based on IPC (Unix domain socket) for intra-node. ZMQ provides the option of having either side initiate the connection, in our case, it is logical and simple to have the agents connect to their local proxy (just use any well known unix domain socket name). However the connectivity on the other end (publisher to proxy) is not as simple without some form of name service/service discovery (in the present version of ZMQ driver, this is handled by matchmaker/redis). GROUP MANAGEMENT The ZMQ guide mentions rightly so that this pattern is great for decoupling publishers and subscribers as they can independently connect to the proxy without having to know each other. So publishers would basically simply connect to *the* proxy and not have to deal with other publishers or any subscriber. However when the number of proxies can be very large (thousands), the difficulty resides in keeping track of nodes as they can get added or removed during regular operations. When a node is added, we would need a way to have each publisher connect to that new node. Same can be said about node deletion. If we go that route we will need a good solution on how to do that efficiently and at scale. And this is one of my main reserve for the spec currently proposed in gerrit. To handle group management, we could reuse the existing matchmaker code (based on redis) or decide to use a more streamlined solution based on a name service. I would like to hear about any feedback on the use of matchmaker at scale if there is any experience (because I do have lots of questions on how matchmaker is designed and how it fares regarding scale and HA). I'll try to start another email thread regarding scale numbers (number of connections, current usage of fanout in the code, emulated vs. true multicast) Alec __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] DB2 CI enablement on Keystone
On 6/15/2015 5:00 AM, Feng Xi BJ Yan wrote: Hi, Keystone guys, Could we have a talk about DB2 CI enablement on this Monday, 8PM central US time? which is Tuesday 9AM beijeing time? For your questions, here are my answers: 1) Is the team going to be responsive to requests unlike last time there was a problem? *(yanfengxi) Yes, problems will be handled in time. In our current working process, issues items will be opened internally automatically if the CI fails. And our mainterner will try to handle the issues opened as soon as possible. If there are others issues, please send email to yanfen...@cn.ibm.com, **or reach irc account yanfengxi on channel #openstack-infra.* 2) Is the job stable? I have no data about the stability I couldn't vouch for it. *(yanfengxi) From the statictics of other running CIs, we have a 88%, including environment failures, and tempest failures. Which I think is acceptable.* *Because keystone CI is not enabled, we do not have the statistics for it. But from several test runnings, keystone CI can run properly.* By the way, I already updated the wiki page: https://wiki.openstack.org/w/index.php?title=IBM/IBM_DB2_CI to include a irc nick name. Best Regard:) Bruce Yan Yan， Fengxi （闫凤喜） Openstack Platform Team IBM China Systems Technology Lab, Beijing E-Mail: yanfen...@cn.ibm.com Tel: 86-10-82451418 Notes: Feng Xi FX Yan/China/IBM Address: 3BW239, Ring Building. No.28 Building, ZhongGuanCun Software Park,No.8 DongBeiWang West Road, ShangDi, Haidian District, Beijing, P.R.China Inactive hide details for Brant L Knudson---2015/06/10 02:51:14---I brought this up at the keystone meeting and the community dBrant L Knudson---2015/06/10 02:51:14---I brought this up at the keystone meeting and the community didn't want DB2 CI reporting was answere From: Brant L Knudson/Rochester/IBM@IBMUS To: Feng Xi BJ Yan/China/IBM@IBMCN@IBMAU Cc: Dan Moravec/Rochester/IBM@IBMUS, Zhu ZZ Zhu/China/IBM@IBMCN Date: 2015/06/10 02:51 Subject: Re: Could you help to talk about DB2 CI enablement on keystone meeting I brought this up at the keystone meeting and the community didn't want DB2 CI reporting was answered until a couple of questions were answered: They asked a couple of questions that I wasn't able to answer: 1) Is the team going to be responsive to requests unlike last time there was a problem? 2) Is the job stable? I have no data about the stability I couldn't vouch for it. They also wanted an irc nick fors someone that can answer questions and respond to problems, on the wiki page: https://wiki.openstack.org/w/index.php?title=IBM/IBM_DB2_CI Rather than go back and forth on this week to week, they suggested that we have a meeting on freenode irc in #openstack-keystone when it's convenient enough for all of us. They were willing to meet any day at 8 PM central US time, which I think is 9 AM Beijing time. So just pick a date when you can meet and send a note to the openstack-dev mailing list when it is. Also, you can include in the note any backup material that you have, such as answers to the above questions. Brant Knudson, OpenStack Development - Keystone core member Phone: 507-253-8621 T/L:553-8621 Inactive hide details for Brant L Knudson---06/03/2015 09:17:07 AM---Looks OK to me. I'll add it to the agenda for next week. Brant L Knudson---06/03/2015 09:17:07 AM---Looks OK to me. I'll add it to the agenda for next week. Brant Knudson, OpenStack Development - Key From: Brant L Knudson/Rochester/IBM To: Feng Xi BJ Yan/China/IBM@IBMCN@IBMAU Cc: Dan Moravec/Rochester/IBM@IBMUS, Zhu ZZ Zhu/China/IBM@IBMCN Date: 06/03/2015 09:17 AM Subject: Re: Could you help to talk about DB2 CI enablement on keystone meeting Looks OK to me. I'll add it to the agenda for next week. Brant Knudson, OpenStack Development - Keystone core member Phone: 507-253-8621 T/L:553-8621 Inactive hide details for Feng Xi BJ Yan---06/02/2015 11:58:22 PM---OK, please take a look at this patch https://review.openstaFeng Xi BJ Yan---06/02/2015 11:58:22 PM---OK, please take a look at this patch https://review.openstack.org/#/c/187751/ Best Regard:) From: Feng Xi BJ Yan/China/IBM@IBMCN To: Brant L Knudson/Rochester/IBM@IBMUS@IBMAU Cc: Dan Moravec/Rochester/IBM@IBMUS, Zhu ZZ Zhu/China/IBM@IBMCN Date: 06/02/2015 11:58 PM Subject: Re: Could you help to talk about DB2 CI enablement on keystone meeting OK, please take a look at this patch https://review.openstack.org/#/c/187751/ Best Regard:) Bruce Yan Yan， Fengxi （闫凤喜） Openstack Platform Team IBM China Systems Technology Lab, Beijing E-Mail: yanfen...@cn.ibm.com Tel: 86-10-82451418 Notes: Feng Xi FX Yan/China/IBM Address: 3BW239, Ring Building. No.28 Building, ZhongGuanCun Software Park,No.8 DongBeiWang West Road, ShangDi, Haidian
Re: [openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat
Zane, I will fix this (and the other GBP packages) as soon as I possibly can. I agree it would be better to move the GBP heat support into the heat repo, either main tree or /contrib, but others on the GBP team would most likely handle that. Seem reasonable for liberty. Thanks, -Bob On 6/17/15 8:56 AM, Zane Bitter wrote: Every day I get an email about broken dependencies for the group-based policy Heat plugin in Fedora (openstack-heat-gbp), because the version of Heat it depends on is capped. Two points: 1) Would whoever maintains that package (Bob?) please fix it :) 2) Why was this plugin not submitted to /contrib in the Heat repo so that it could be continuously tested maintained against the Heat code base, thus avoiding any compatibility problems with future versions? This is the entire reason we have /contrib. In fact, if you think the resources are in close to their final form (i.e. the API is not super experimental still), I think we may even be willing to accept them into the main tree at this point. cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec
+1! From: Clark, Robert Graham Sent: Tuesday, June 16, 2015 2:29 AM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec I'd like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security project for a couple of years he's a part of the bandit subproject and has been very active in discussions over this time. He's also found multiple vulnerabilities and has experience of the VMT process. -Rob smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? 3.4 Final is planed for September 13 https://www.python.org/dev/peps/pep-0478/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/18/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 6/18/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ A brief summary on today’s discussion: 1. Update on repository creation Repository has been created on OpenStack. https://review.openstack.org/#/c/192820/ and https://review.openstack.org/#/c/188637/ Neutron team has adopted this project. 2. Finalize the SFC API Continue collecting review comments and finalize it by next Wednesday, and we will start implementing the APIs 3. Project management and core members Cathy will manage the project and is currently running the IRC meetings and technical discussions. Core members: Kyle Mestery, Armando, Cathy Zhang, Louis Fourie, Swami, Vikram, Nicolas, Mohankumar, Ramanjaneya, Brian, s3wong, Yuji 4. Finalize the SFC project scope and functional module breakdown Following is a summary of functional module breakdown and ownership sign-up (adding more people who have signed up as the contributors). We will be happy to see more people involved to get this in the direction that suits everybody and reaching us out publicly is best. * Integration with Neutron/devstack, CLI, Horizon, Heat--Mohankumar and Ramanjaneya * Neutron Service chain API Extension- Cathy，LouisF * Flow Classifier API LouisF，Vikram, Yuji, nbouthors * Service chain Plugin: API handling and Data Base- LouisF, Cathy,Swami, s3wong * Service Chain Driver managerCathy, Brian * OVS Driver LouisF, Brian, s3wong * Flow Classifier on the data Path--- nbouthors_, Yuji * OVS with NSH encapsulation for verification of the OpenStack Service Chain API Plugin functionality---LouisF, Swami, 5. Deep dive into technical questions *Relationship with use case spec https://review.openstack.org/#/c/169201/ Our API spec provides the Neutron level design and code to support the use case documented in the above link * Why do we need to add “encapsulation” context to the service chain API Our API needs to cover both service VMs that do not support new chain header and service VMs that support the new chain header. So the vSwitch needs to be told which encapsulation format to use for communicating with the service function VMs. That is why we need this context parameter in the API which will be passed down to the vSwitch. 6. Tentative time line for development of each module We will get the feedback from each piece owner about their timeline of completion in next IRC meeting __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging
Hi folks, I had to leave the app-catalog IRC meeting early today, but I read back through the logs. I wanted to bring up a point about Apps vs. Components, and determination of what is an app and tagging. I don't think it's any more black and white with Solum language packs than it is with Glance images. As an example, a solum user can create a language pack called Ubuntu, LAMP, Wordpress, DockerRegistry, or anything else.. In fact, any Docker image in the public Docker Registry could become a Solum language pack . A language pack can be a base run-time where the user then layers app code on-top, or it can be a run-time with application code already installed that the user just layers on changes to the app code. Applications and application components can be pre-installed on solum language packs. Solum layers on the controlled workflow to integrate a user's CI/CD options of choice, where Solum's controlled workflow instills the CI/CD gates (e.g. Tests must pass before we push your app live to production) and ensures proper Heat template selection to match appropriate reference architecture for the type of app being deployed. Think of Solum as integrating Heat, Auto-scale, Git, Mistral, and up-leveing application deploying to the cloud such that an end-user just needs to specify a language pack, a git repo, and optionally a test command and application run command. If a base language pack has everything needed to get started, it can be used standalone with an empty git repo or Solum could setup a git repo automatically with the base app code (e.g. Wordpress). So, I want to challenge the notion that it's a clear line for solum language packs to not be tagged apps and that glance images are the only artifacts in the gray area. Thanks, -Keith __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Low Hanging Fruit etherpad
Hi All, I have started an etherpad for tracking low hanging fruit work in Nova: https://etherpad.openstack.org/p/nova-low-hanging-fruit I have linked it on the Nova Mentoring wiki [1] and populated it with a bit of information about the remaining work that needs to be done to convert the rest of the code base to objects. Please feel free to expand the etherpad with other work and information that would help contributors to Nova. [1] https://wiki.openstack.org/wiki/Nova/Mentoring#What_should_I_work_on.3F Thanks, -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
On 6/18/15 1:28 PM, Matt Riedemann wrote: It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. too many connections is an error raised by MySQL when more connections are attempting to connect than the max_connections setting. It defaults to 100 but it is often set at 1024 in distributions.An Openstack application that uses oslo.db will go through oslo.db's create_engine() routine which defaults the max number of connections per python process to 15, and when the process is idle, this drops to 5. Which means, there have to be over 60 python processes all hitting the DB at the max to get that error, if max_connections is at 1024.Or the connection pool is totally broken (e.g. with eventlet monkeypatching perhaps), which would be a critical issue for me to fix. So I'd love to see how the too many connections error actually happens. Please share whatever you have on that. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
On 06/18/2015 03:47 PM, Mike Bayer wrote: On 6/18/15 1:28 PM, Matt Riedemann wrote: It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. too many connections is an error raised by MySQL when more connections are attempting to connect than the max_connections setting. It defaults to 100 but it is often set at 1024 in distributions.An Openstack application that uses oslo.db will go through oslo.db's create_engine() routine which defaults the max number of connections per python process to 15, and when the process is idle, this drops to 5. Which means, there have to be over 60 python processes all hitting the DB at the max to get that error, if max_connections is at 1024.Or the connection pool is totally broken (e.g. with eventlet monkeypatching perhaps), which would be a critical issue for me to fix. So I'd love to see how the too many connections error actually happens. Please share whatever you have on that. I believe the distro defaults in Ubuntu are the mysql defaults, which is 151 - https://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html If we're allowing 15 connections per python process, and the APIs are running in a worker mode, which means 8 workers per API server, yes, that's going to add up really quick. Perhaps under these scenarios we need to raise this to 1024 in devstack? -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging
This makes sense to me too, and I feel like Kevin captures the flow I imagine for an app. Considering the point of the app catalog is to showcase what you can do with an OpenStack environment, if a Solum LP can be grabbed from the catalog and results in them just needing to add some information for they have something up an running, that would fit the definition of app for me in this context. -Christopher On Thu, Jun 18, 2015 at 1:01 PM, Fox, Kevin M kevin@pnnl.gov wrote: Good thing to discuss. So, if you can launch a Solum Language Pack without the user needing to do extra steps like creating a git repo and populating it, committing, etc, then yeah, I think that fits the app tag definition we came up with. Something a user could go into the catalog, hit launch, optionally fill out form, and get something running easily. The nice thing about the app tag is that we can selectively put it on things that it makes sense to, rather then just relying on the type of artefact it is. Like this use case. Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Thursday, June 18, 2015 12:44 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging Hi folks, I had to leave the app-catalog IRC meeting early today, but I read back through the logs. I wanted to bring up a point about Apps vs. Components, and determination of what is an app and tagging. I don't think it's any more black and white with Solum language packs than it is with Glance images. As an example, a solum user can create a language pack called Ubuntu, LAMP, Wordpress, DockerRegistry, or anything else.. In fact, any Docker image in the public Docker Registry could become a Solum language pack . A language pack can be a base run-time where the user then layers app code on-top, or it can be a run-time with application code already installed that the user just layers on changes to the app code. Applications and application components can be pre-installed on solum language packs. Solum layers on the controlled workflow to integrate a user's CI/CD options of choice, where Solum's controlled workflow instills the CI/CD gates (e.g. Tests must pass before we push your app live to production) and ensures proper Heat template selection to match appropriate reference architecture for the type of app being deployed.Think of Solum as integrating Heat, Auto-scale, Git, Mistral, and up-leveing application deploying to the cloud such that an end-user just needs to specify a language pack, a git repo, and optionally a test command and application run command. If a base language pack has everything needed to get started, it can be used standalone with an empty git repo or Solum could setup a git repo automatically with the base app code (e.g. Wordpress). So, I want to challenge the notion that it's a clear line for solum language packs to not be tagged apps and that glance images are the only artifacts in the gray area. Thanks, -Keith __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team
Thanks! It is a great honor and huge responsibility that I'll try to fit in. On Jun 18, 2015 8:42 PM, Paul Michali p...@michali.net wrote: Congratulations Ann! On Thu, Jun 18, 2015 at 12:22 PM Edgar Magana edgar.mag...@workday.com wrote: Congratulations Ann and welcome to the team! Edgar On 6/18/15, 8:56 AM, Henry Gessau ges...@cisco.com wrote: It has been a week and feedback has been positive and supportive of Ann's nomination. Welcome to the Neutron DB core reviewer team, Ann. -- Henry On Thu, Jun 11, 2015, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron showing expertise particularly in database matters. She has also worked with and contributed code to the oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the Neutron database healing effort that was completed in the Juno cycle. Her deep knowledge of databases and backends, and her expertise with oslo.db, sqlalchemy and alembic will be very important in this area. Ann is a trusted member of our community and her review stats [2][3][4] place her comfortably with other Neutron core reviewers. She consistently catches database issues early when patches are submitted for review, and shows dedication to helping developers understand and perfect their database-related changes. Existing Neutron core reviewers from the API and DB area of focus, please vote +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl. [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
On 6/18/15 3:53 PM, Sean Dague wrote: On 06/18/2015 03:47 PM, Mike Bayer wrote: On 6/18/15 1:28 PM, Matt Riedemann wrote: It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. too many connections is an error raised by MySQL when more connections are attempting to connect than the max_connections setting. It defaults to 100 but it is often set at 1024 in distributions.An Openstack application that uses oslo.db will go through oslo.db's create_engine() routine which defaults the max number of connections per python process to 15, and when the process is idle, this drops to 5. Which means, there have to be over 60 python processes all hitting the DB at the max to get that error, if max_connections is at 1024.Or the connection pool is totally broken (e.g. with eventlet monkeypatching perhaps), which would be a critical issue for me to fix. So I'd love to see how the too many connections error actually happens. Please share whatever you have on that. I believe the distro defaults in Ubuntu are the mysql defaults, which is 151 - https://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html We've been watching a too many connections issue internally and I had assumed our connections were at 100 or 150, but when I poked around i saw that RHEL is setting this at 1024 for mariadb-galera at least.So it's worth knowing what the number is if we see this actually happen somewhere. Quickest way to see it is to just query for it against MySQL itself with show variables like 'max_connections';. If we're allowing 15 connections per python process, and the APIs are running in a worker mode, which means 8 workers per API server, yes, that's going to add up really quick. Perhaps under these scenarios we need to raise this to 1024 in devstack? yes, that would be appropriate. -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team
Congratulations Ann! On Thu, Jun 18, 2015 at 12:22 PM Edgar Magana edgar.mag...@workday.com wrote: Congratulations Ann and welcome to the team! Edgar On 6/18/15, 8:56 AM, Henry Gessau ges...@cisco.com wrote: It has been a week and feedback has been positive and supportive of Ann's nomination. Welcome to the Neutron DB core reviewer team, Ann. -- Henry On Thu, Jun 11, 2015, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron showing expertise particularly in database matters. She has also worked with and contributed code to the oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the Neutron database healing effort that was completed in the Juno cycle. Her deep knowledge of databases and backends, and her expertise with oslo.db, sqlalchemy and alembic will be very important in this area. Ann is a trusted member of our community and her review stats [2][3][4] place her comfortably with other Neutron core reviewers. She consistently catches database issues early when patches are submitted for review, and shows dedication to helping developers understand and perfect their database-related changes. Existing Neutron core reviewers from the API and DB area of focus, please vote +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl. [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] (re)centralizing library release management
Excerpts from Doug Hellmann's message of 2015-06-09 16:08:16 -0400: Excerpts from Doug Hellmann's message of 2015-06-09 13:25:26 -0400: Until now we have encouraged project teams to prepare their own library releases as new versions of projects were needed. We've started running into a couple of problems with that, with releases not coming often enough, or at a bad time in the release cycle, or with version numbering not being applied consistently, or without proper announcements. To address these issues, the release management team is proposing to create a small team of library release managers to handle the process around all library releases (clients, non-application projects, middleware, Oslo libraries, etc.). This will give us a chance to collaborate and review the version numbers for new releases, as well as stay on top of stale libraries with fixes or features that sit unreleased for a period of time. It will also be the first step to creating an automated review process for release tags. The process still needs to be worked out, but I envision it working something like this: The release liaison/PTL for the project team submits a request for a new release, including the repo name, the SHA, the series (liberty, kilo, etc.), and the proposed version number. The release team checks the proposed version number against the unreleased changes up to that SHA, and then either updates it to reflect semver or uses it as it is provided. The release team would then handle the tag push and the resulting announcements. There would be a few conditions under which a new release might not be immediately approved, but really only when the gate is wedged and during freeze periods. The point of the change isn't to block releases, just ensure consistency and good timing. We have some tools to let us look for unreleased changes, and eventually we can set up a recurring job to build that report so we can propose releases to project teams with a large release backlog. That will likely come later, though. We can also pre-announce proposed releases if folks find that useful. We will need a small number of volunteers to join this team, and start building the required expertise in understanding the overall state of the project, and in semantic versioning. We do not necessarily want a liaison from every project -- think of this as the proto-team for the group that eventually has core reviewer rights on the release automation repository. The change to update the ACLs is https://review.openstack.org/189856 I would appreciate a review to ensure I've not missed any library-like things, and so that all projects understand which repositories this affects. Doug The ACLs change has landed, and the new library-release team is set up including the Release Managers group, along with dims and lifeless, who volunteered to join the new team. https://review.openstack.org/#/admin/groups/967,members Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec
On 2015-06-16 05:08:35 - (-), Robert Graham Clark wrote: I’d like to nominate Travis for a CoreSec position as part of the Security project. [...] Sounds great. His input has been invaluable, and I welcome more of it! -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Stackalytics] Complementary projects
Greetings, I am wondering the reason for the complementary projects listing[1] in Stackalytics? Specifically, why does stackalytics-processor import docker and cloudfoundry projects into the stats? [1] http://stackalytics.com/?project_type=complementarymetric=commits __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Doug [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Installing dependent modules in functional testing
Now that we have the basic beaker-rspec framework set up in the modules and working in infra's CI, we need to start making our testing aware of Zuul dependencies. The infra team is facing similar challenges so it would be nice to work together on this. Discussions with jeblair and nibalizer have resulted in an etherpad[1] with some possible solutions, where Idea 1 seems to be the most mutually beneficial. The idea is to have JJB prepare the node prior to testing, and to share an install script for when developers are running tests locally. This would install all of our modules and all their dependencies, not just the specific ones needed by one particular module, because this makes it easier to share a common thing between modules and frees us from worrying about implicit dependencies (modules needed to set up infrastructure that aren't listed explicitly in metadata.json) and transitive dependencies (dependencies of co-gated modules). I've written a possible implementation using r10k with a Puppetfile[2][3]. R10k is generally promoted as the preferred way to manage puppet environments so it makes sense to use it in our tests. It also gives us the benefit of having a commonly defined Puppetfile that lays out versions of modules that are guaranteed to work together. This POC script is also using zuul-cloner to clone dependencies from Zuul if running in a CI environment. This part could be extracted out into the node prep stage later, which would be more in line with Idea 1 in the etherpad, but it's hard to test that functionality at this early stage. I'd like to create a new repo to hold this install script and Puppetfile. This repo could also eventually become a home for integration testing material, like a kind of devstack. I suggest we call it openstack/puppet-openstack-testing or openstack/puppet-openstack-integration. I would like to avoid calling it anything that could imply that it should be used as a composition module. Opening this up for thoughts on this implementation proposal and the repo name. Colleen [1] https://etherpad.openstack.org/p/puppet-git-dependencies [2] https://review.openstack.org/#/c/190839 [3] https://github.com/cmurphy/puppet-openstack-dependencies __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
On 06/18/2015 04:28 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-06-18 12:53:16 -0700: On 06/18/2015 03:47 PM, Mike Bayer wrote: On 6/18/15 1:28 PM, Matt Riedemann wrote: It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. too many connections is an error raised by MySQL when more connections are attempting to connect than the max_connections setting. It defaults to 100 but it is often set at 1024 in distributions.An Openstack application that uses oslo.db will go through oslo.db's create_engine() routine which defaults the max number of connections per python process to 15, and when the process is idle, this drops to 5. Which means, there have to be over 60 python processes all hitting the DB at the max to get that error, if max_connections is at 1024.Or the connection pool is totally broken (e.g. with eventlet monkeypatching perhaps), which would be a critical issue for me to fix. So I'd love to see how the too many connections error actually happens. Please share whatever you have on that. I believe the distro defaults in Ubuntu are the mysql defaults, which is 151 - https://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html If we're allowing 15 connections per python process, and the APIs are running in a worker mode, which means 8 workers per API server, yes, that's going to add up really quick. Perhaps under these scenarios we need to raise this to 1024 in devstack? Indeed, mysqld needs tuning for better concurrency. I submitted this which should help avoid the low connection count and also will unserialize read/writes on a single table which should lead to tests doing multiple operations asynchronously finishing a bit quicker. https://review.openstack.org/193295 Note that we MIGHT want to raise the innodb_buffer_pool_size. The default since 5.5 has been 128MB (It used to be _8MB_). However, I imagine memory can get tight on devstack nodes and laptops, so it's also perfectly valid to keep it at 128MB and just let operations go to disk more often. Yeh, we are trying to stay useful on 4G VMs, we did turn off some default services for that reason. So lets not up memory unless we have to. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] DevStack switching from MySQL-python to PyMySQL
Excerpts from Sean Dague's message of 2015-06-18 12:53:16 -0700: On 06/18/2015 03:47 PM, Mike Bayer wrote: On 6/18/15 1:28 PM, Matt Riedemann wrote: It's not only neutron, I saw some pymysql failures in nova the other day for 'too many connections' or some such related error. too many connections is an error raised by MySQL when more connections are attempting to connect than the max_connections setting. It defaults to 100 but it is often set at 1024 in distributions.An Openstack application that uses oslo.db will go through oslo.db's create_engine() routine which defaults the max number of connections per python process to 15, and when the process is idle, this drops to 5. Which means, there have to be over 60 python processes all hitting the DB at the max to get that error, if max_connections is at 1024.Or the connection pool is totally broken (e.g. with eventlet monkeypatching perhaps), which would be a critical issue for me to fix. So I'd love to see how the too many connections error actually happens. Please share whatever you have on that. I believe the distro defaults in Ubuntu are the mysql defaults, which is 151 - https://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html If we're allowing 15 connections per python process, and the APIs are running in a worker mode, which means 8 workers per API server, yes, that's going to add up really quick. Perhaps under these scenarios we need to raise this to 1024 in devstack? Indeed, mysqld needs tuning for better concurrency. I submitted this which should help avoid the low connection count and also will unserialize read/writes on a single table which should lead to tests doing multiple operations asynchronously finishing a bit quicker. https://review.openstack.org/193295 Note that we MIGHT want to raise the innodb_buffer_pool_size. The default since 5.5 has been 128MB (It used to be _8MB_). However, I imagine memory can get tight on devstack nodes and laptops, so it's also perfectly valid to keep it at 128MB and just let operations go to disk more often. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
On 2015-06-18 15:48:28 -0400 (-0400), Doug Hellmann wrote: Based on that, I am confident in sticking with our plan of gating using 3.4 for now and keeping an eye on the 3.5 packages being built by Debian and Canonical. Unless we shift platforms and go back to special-casing Py3K jobs, I expect to see us testing the N release cycle on Python 3.5 in Ubuntu 16.04 LTS but probably not prior unless someone steps up to make it happen differently. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team
It has been a week and I haven't heard any negative feedback. Welcome to the control plane core reviewer team YAMAMOTO Takashi! On Mon, Jun 15, 2015 at 2:52 AM, Oleg Bondarev obonda...@mirantis.com wrote: +1 On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not on the list either, but I want to +1 what Henry said. Yamamoto's reviews expand to the whole code base and are pretty always *very* usefu l. On 06/12/2015 11:39 PM, Henry Gessau wrote: Although I am not on your list I would like to add my +1! Yamamoto shows great attention to detail in code reviews and frequently finds real issues that were not spotted by others. On Thu, Jun 11, 2015, Kevin Benton blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his feedback on patches related to the reference implementation has been very useful. This includes everything ranging from the AMPQ API to OVS flows. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#core-review-hierarchy http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/90 Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfpgHAAoJEC5aWaUY1u57z40IAL8HpGOEQY7aW1aa39C9ig3Y bNLEabeQ0K5a4+5ynVLIm1sEl4s3GF2r0gCXak9FrkqjHx2r8VeyOx8TqrCj8gX3 +4aHI7n6rJoJtINuTd+bN7T65uaZE86erOcZN+yma5V69ObfIZhIfQKr3BMaBeZT ah5hkUKl88ckLL5zqc0HnT4wcFH/3Ved2fuhP7hw/IEGMFsqTDS8QUTdXg7/OF5t fLt0NluKoOuNMOk8dTqpqtQtiyS/E5TH+miVOzyrUeUmZOEayOO3O2b/9QRkX/hL ijv1j+clT69fhoVAWSaeR7IsXSfqMuKK/hrVtjnyDpBH4KuZnl3QbRpKJ6Yi3bw= =qnTt -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-operators][chef] Release of knife-openstack is out (1.2.0)
I have released the 1.2.0 version of the knife-openstack[1] gem. If you find any uses or have questions don’t hesitate to email me directly or put an issue[2] in. [1]: https://rubygems.org/gems/knife-openstack https://rubygems.org/gems/knife-openstack [2]: https://github.com/chef/knife-openstack/issues https://github.com/chef/knife-openstack/issues -JJ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team
Congrats Yamamoto! On Thu, Jun 18, 2015 at 6:23 PM Kevin Benton blak...@gmail.com wrote: It has been a week and I haven't heard any negative feedback. Welcome to the control plane core reviewer team YAMAMOTO Takashi! On Mon, Jun 15, 2015 at 2:52 AM, Oleg Bondarev obonda...@mirantis.com wrote: +1 On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not on the list either, but I want to +1 what Henry said. Yamamoto's reviews expand to the whole code base and are pretty always *very* usefu l. On 06/12/2015 11:39 PM, Henry Gessau wrote: Although I am not on your list I would like to add my +1! Yamamoto shows great attention to detail in code reviews and frequently finds real issues that were not spotted by others. On Thu, Jun 11, 2015, Kevin Benton blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his feedback on patches related to the reference implementation has been very useful. This includes everything ranging from the AMPQ API to OVS flows. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#core-review-hierarchy http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/90 Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfpgHAAoJEC5aWaUY1u57z40IAL8HpGOEQY7aW1aa39C9ig3Y bNLEabeQ0K5a4+5ynVLIm1sEl4s3GF2r0gCXak9FrkqjHx2r8VeyOx8TqrCj8gX3 +4aHI7n6rJoJtINuTd+bN7T65uaZE86erOcZN+yma5V69ObfIZhIfQKr3BMaBeZT ah5hkUKl88ckLL5zqc0HnT4wcFH/3Ved2fuhP7hw/IEGMFsqTDS8QUTdXg7/OF5t fLt0NluKoOuNMOk8dTqpqtQtiyS/E5TH+miVOzyrUeUmZOEayOO3O2b/9QRkX/hL ijv1j+clT69fhoVAWSaeR7IsXSfqMuKK/hrVtjnyDpBH4KuZnl3QbRpKJ6Yi3bw= =qnTt -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] apache wsgi application support
Adam pointed to this url as a proposal for the namespaces:
https://wiki.openstack.org/wiki/URLs
How about this gets turned into a cross project spec or part of a larger one
with the stuff in this ML thread? Then we can get the projects aware and
buying into this little slice of sanity.
--Rocky
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Wednesday, June 17, 2015 11:22
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] apache wsgi application support
On 06/16/2015 05:25 PM, Chris Dent wrote:
On Tue, 16 Jun 2015, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of the wrong direction.
Yes, that's certainly what I've done the few times I've done it.
devstack is deeply encouraging of cargo culting for reasons that are
not entirely clear.
Yeh, hence why I decided to put the brakes on a little here and get this
on the list.
The first is the fact that a big reason for putting {SERVICES} under
apache wsgi is we aren't running on a ton of weird unregistered ports.
We're running on 80 and 443 (when appropriate). In order to do this we
really need to namespace the API urls. Which means that service catalog
needs to be updated appropriately.
So:
a) I'm very glad to hear of this. I've been bristling about the weird
ports thing for the last year.
b) You make it sound like there's been a plan in place to not use
those ports for quite some time and we'd get to that when we all
had some spare time. Where do I go to keep abreast of such plans?
Unfortunately, this is one of those in the ether kinds of plans. It's
been talked about for so long, but it never really got written down.
Hopefully this can be driven into the service catalog standardization
spec (or tag along somewhere close).
Or if nothing else, we're documenting it now on the mailing list as
permanent storage.
I also think this -
https://github.com/openstack-dev/devstack/blob/master/lib/nova#L266-L268
is completely wrong.
The Apache configs should instead specify access rules such that the
installed console entry point of nova-api can be used in place as the
WSGIScript.
I'm not able to parse this paragraph in any actionable way. The lines
you reference are one of several ways of telling mod wsgi where the
virtualenv is, which has to happen in some fashion if you are using
a virtualenv.
This doesn't appear to have anything to do with locating the module
that contains the WSGI app, so I'm missing the connection. Can you
explain please?
(Basically I'm keen on getting gnocchi and ceilometer wsgi servers
in devstack aligned with whatever the end game is, so knowing the plan
makes it a bit easier.)
Gah, the problem of linking to 'master' with line numbers. The three
lines I cared about were:
# copy proxy vhost and wsgi helper files
sudo cp $NOVA_DIR/nova/wsgi/nova-api.py $NOVA_WSGI_DIR/nova-api
sudo cp $NOVA_DIR/nova/wsgi/nova-ec2-api.py $NOVA_WSGI_DIR/nova-ec2-api
I don't think that we should be copying py files around to other
directories outside of normal pip install process. We should just have
mod_wsgi reference a thing that is installed in /usr/{local}/bin or
/usr/share via the python install process.
This should also make lines like -
https://github.com/openstack-dev/devstack/blob/master/lib/nova#L272 and
L274 uneeded. (The WSGI Script will be in a known place). It will also
make upgrades much more friendly.
It sounds like maybe you are saying that the api console script and
the module containing the wsgi 'application' variable ought to be the
same thing. I don't reckon that's a great idea as the api console
scripts will want to import a bunch of stuff that the wsgi application
will not.
Or I may be completely misreading you. It's been a long day, etc.
They don't need to be actually the same thing. They could be different
scripts, but they should be scripts that install via the normal pip
install process to a place, and we reference them by known name.
I think that we need to get these things sorted before any further
progression here. Volunteers welcomed to help get us there.
Find me, happy to help. The sooner we can kill wacky port weirdness
the better.
Agreed.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec
On 06/16/2015 02:28 AM, Clark, Robert Graham wrote: I'd like to nominate Travis for a CoreSec position as part of the Security project. - CoreSec team members support the VMT with extended consultation on externally reported vulnerabilities. Travis has been an active member of the Security project for a couple of years he's a part of the bandit subproject and has been very active in discussions over this time. He's also found multiple vulnerabilities and has experience of the VMT process. -Rob +1 ! signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
Excerpts from Brian Curtin's message of 2015-06-18 13:17:52 -0500: On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? 3.4 Final is planed for September 13 https://www.python.org/dev/peps/pep-0478/ Based on that, I am confident in sticking with our plan of gating using 3.4 for now and keeping an eye on the 3.5 packages being built by Debian and Canonical. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging
Good thing to discuss. So, if you can launch a Solum Language Pack without the user needing to do extra steps like creating a git repo and populating it, committing, etc, then yeah, I think that fits the app tag definition we came up with. Something a user could go into the catalog, hit launch, optionally fill out form, and get something running easily. The nice thing about the app tag is that we can selectively put it on things that it makes sense to, rather then just relying on the type of artefact it is. Like this use case. Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Thursday, June 18, 2015 12:44 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [app-catalog] [solum] Base Image tagging vs. App tagging Hi folks, I had to leave the app-catalog IRC meeting early today, but I read back through the logs. I wanted to bring up a point about Apps vs. Components, and determination of what is an app and tagging. I don't think it's any more black and white with Solum language packs than it is with Glance images. As an example, a solum user can create a language pack called Ubuntu, LAMP, Wordpress, DockerRegistry, or anything else.. In fact, any Docker image in the public Docker Registry could become a Solum language pack . A language pack can be a base run-time where the user then layers app code on-top, or it can be a run-time with application code already installed that the user just layers on changes to the app code. Applications and application components can be pre-installed on solum language packs. Solum layers on the controlled workflow to integrate a user's CI/CD options of choice, where Solum's controlled workflow instills the CI/CD gates (e.g. Tests must pass before we push your app live to production) and ensures proper Heat template selection to match appropriate reference architecture for the type of app being deployed. Think of Solum as integrating Heat, Auto-scale, Git, Mistral, and up-leveing application deploying to the cloud such that an end-user just needs to specify a language pack, a git repo, and optionally a test command and application run command. If a base language pack has everything needed to get started, it can be used standalone with an empty git repo or Solum could setup a git repo automatically with the base app code (e.g. Wordpress). So, I want to challenge the notion that it's a clear line for solum language packs to not be tagged apps and that glance images are the only artifacts in the gray area. Thanks, -Keith __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [api][Solum] Request for feedback on new API resource
Hi, API WG team,
In Solum, recently we have been working on some changes to our REST API.
Basically, we have introduced a new resource ('app'). The spec for this has
been accepted by Solum cores.
https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst
Right now we have a patch for review implementing this spec:
https://review.openstack.org/#/c/185147/
If it is not too much to request, I was wondering if someone from your team can
take a look
at the spec and the review, to see if we are not violating any of your
guidelines.
Thank you for your help.
- Devdatta
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities
Gal: I had seen the brute force blueprint and noticed how close the use case was. Can you tell me the current status of the work? Do you feel confident it can get into Liberty? Ideally, we think this fits better with QoS. Also I don’t think of it as providing FWaaS as we see that all VMs would be protected by this when enabled, but maybe that is just terminology. We think these protections are critical so we are more concerned with having the ability to protect against these cases than the specific API or service it falls under. Yes we would be interested in working together to get this pushed through. John From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Wednesday, June 17, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some UI work You can view the specs and implementations here: 1) https://review.openstack.org/#/c/184243/ 2) https://review.openstack.org/#/c/154535/ 3) https://review.openstack.org/#/c/151247/ 4) https://review.openstack.org/#/c/161207/ The spec didn't got approved as there is a strong opinion to keep the security group API compatible with Amazon. I think this and your request fits much more into the FWaaS and if this is something you would like to work together on and push i can help and align the above code to use FWaaS. Feel free to contact me if you have any question Thanks Gal. On Wed, Jun 17, 2015 at 6:58 PM, John Joyce (joycej) joy...@cisco.commailto:joy...@cisco.com wrote: Hello everyone: I would like to test the waters on some new functionality we think is needed to protect OpenStack deployments from some overload situations due to an excessive user or DDOS scenario. We wrote this up in the style of an RFE. Please let us know your thoughts and we can proceed with a formal RFE with more detail if there are no concerns raised. *What is being requested* This request is to extend the QOS APIs to include the ability to provide connection rate limiting *Why is it being requested* There are many scenarios where a VM may be intentionally malicious or become harmful to the network due to its rate of initializing TCP connections. The reverse direction of a VM being attacked with an excessive amount of TCP connection requests either intentionally or due to overload is also problematic. *Implementation Choices There might be a number of ways to implement this, but one of the easiest would appear to be to extend the APIs being developed under: https://review.openstack.org/#/c/187513/. An additional rule type “connections per-second” could be added. The dataplane implementation itself may be realized with netfilter and conntrack. *Alternatives It would be possible to extend the security groups in a similar fashion, but due to the addition of rate limiting, QoS seems a more nature fit. *Who needs it* Cloud operators have experienced this issue in real deployments in a number of cases. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards , The G. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
On 06/16/2015 08:51 PM, Alec Hothan (ahothan) wrote: I saw Sean Dague mention in another email that RabbitMQ is used by 95% of OpenStack users - and therefore does it make sense to invest in ZMQ (legit question). I believe it's used by 95% of users because there is as yet no compelling alternative. The approach taken with the qpid driver was to retain as much of the design of the rabbit driver, both in terms of the architecture of the driver code itself, and in the underlying broker model it relied on. The library used however was based on a different threading model from that used for rabbit and deliberately abstracted away from that broker model which had a negative effect on the ability to reason about the resulting code. More fundamentally, the qpid driver didn't offer a different design to the rabbit driver. It just used a different broker. The broker wasn't actually the problem with the rabbit driver though. There was no real benefit against which pain encountered during hardening of a less mature solution could be offset. Unfortunately the failure of that effort has left its scars on many in the community and continues to colour opinion. I agree that the maturity of different solutions needs to be made very clear to user, that there must be effective testing under CI, that stale, unmaintained code has to be continually removed. There are valuable lessons in that failure which we should not ignore. But I don't believe that failure is a reason to stifle the emergence of alternative approaches (as described above, the qpid driver was not a different approach anyway). I think store-and-forward is the wrong tool for RPC and end-to-end acknowledgement would be better. I think it is better to focus on the availability of the communication channel than on consistent replication of every single request- and response- message. So I think investing in different approaches does make sense. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Installing dependent modules in functional testing
On 06/18/2015 05:24 PM, Colleen Murphy wrote: Now that we have the basic beaker-rspec framework set up in the modules and working in infra's CI, we need to start making our testing aware of Zuul dependencies. The infra team is facing similar challenges so it would be nice to work together on this. Discussions with jeblair and nibalizer have resulted in an etherpad[1] with some possible solutions, where Idea 1 seems to be the most mutually beneficial. The idea is to have JJB prepare the node prior to testing, and to share an install script for when developers are running tests locally. This would install all of our modules and all their dependencies, not just the specific ones needed by one particular module, because this makes it easier to share a common thing between modules and frees us from worrying about implicit dependencies (modules needed to set up infrastructure that aren't listed explicitly in metadata.json) and transitive dependencies (dependencies of co-gated modules). For the reasons mentioned in the etherpad, big +1 on idea #1. It will also help a lot in bringing consistent our tests since we will finally make sure to use the same module versions. I've written a possible implementation using r10k with a Puppetfile[2][3]. R10k is generally promoted as the preferred way to manage puppet environments so it makes sense to use it in our tests. It also gives us the benefit of having a commonly defined Puppetfile that lays out versions of modules that are guaranteed to work together. This POC script is also using zuul-cloner to clone dependencies from Zuul if running in a CI environment. This part could be extracted out into the node prep stage later, which would be more in line with Idea 1 in the etherpad, but it's hard to test that functionality at this early stage. I'd like to create a new repo to hold this install script and Puppetfile. This repo could also eventually become a home for integration testing material, like a kind of devstack. I suggest we call it openstack/puppet-openstack-testing or openstack/puppet-openstack-integration. I would like to avoid calling it anything that could imply that it should be used as a composition module. +1 for puppet-openstack-integration Opening this up for thoughts on this implementation proposal and the repo name. Colleen Thanks a lot for this work, I see a lot of interest in what you're doing to have real cross-project functional testing and also think about how to test upgrades (a grenade-like) in the future. [1] https://etherpad.openstack.org/p/puppet-git-dependencies [2] https://review.openstack.org/#/c/190839 [3] https://github.com/cmurphy/puppet-openstack-dependencies __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [Ceilometer] Ceilometer Python API Documentation
hi Hassaan, there's a similar link here: http://docs.openstack.org/developer/python-ceilometerclient i don't know if we have official docs but you can see some usage examples here: https://www.rdoproject.org/CeilometerQuickStart#Exploring_with_the_CLI On 18/06/2015 1:24 AM, Hassaan Ali wrote: Hi, I am looking for Openstack Ceilometer Python API Documentation that includes example codes and guidelines for using it. So far I have been able to find the following link but it is not that much helpful: http://docs.openstack.org/developer/python-heatclient/ Your help will be highly appreciated. Thanks. -- Regards, * * * Hassaan * __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance] V3 Authentication for swift store
Hey everyone,
TL;DR: glance_store requires a way to do v3 authentication to the swift backend.
The keystone team is making a push to properly deprecate the v2 authentication
APIs this cycle. As part of that we have a series of devstack reviews that
moves devstack over to only using v3 APIs[1] and an experimental gate job that
runs devstack with the keystone v2 api disabled.
The current blocker for this gate job is that in glance's single-tenant swift
backend mode the config options only allow v2 authentication.
Looking at glance store the username and password are stored as part of the
location parameter in the form:
swift://username:project_name:password@keystone/container
even though devstack is still using the (deprecated?)
swift_store_user = username:project_name
swift_store_key = password
swift_store_container = container
I don't know how this relates to swift_store_config_files.
There is support for v3 in swiftclient (though it's kind of ugly), to do v3
authentication i have to do:
c = swiftclient.Connection(authurl='http://keystoneurl:5000/v3',
user=username,
key=password,
auth_version='3',
os_options={'project_name': project_name,
'project_domain_id': 'default',
'user_domain_id': 'default'})
However in future we are trying to open up authentication so it's not limited
to only user/password authentication. Immediate goals for service to service
communications are to enable SSL client certificates and kerberos
authentication. This would be handled by keystoneclient sessions but they are
not supported by swift and it would require a significant rewrite of
swiftclient to do, and the swift team has indicated they do not which to invest
more time into their client.
This leads me to my question: How do we support additional authentication
parameters and in future different parameters?
We could undo the deprecation of the config file specified credentials and add
the additional options there. This would get us the short term win of moving to
v3 auth but would need to be addressed in future for newer authentication
mechanissms.
I wrote a blog a while ago regarding how sessions supports loading different
types of authentication from conf files[2], however as swiftclient doesn't
support this the best it could do is fetch a url/token combo with which glance
could make requests and it would have to handle reauthentication and retries
somewhat manually. I actually think rewriting the required parts of the client
wouldn't be too difficult, the problem then is whether this should live in
glance or in swiftclient. This would also involve credentials in the config
file rather than the location option.
I'm not overly familiar with glance_store so there may be other options or what
i've suggested may not be possible but I'd love to hear some opinions from the
glance team as this is quickly becoming a blocker for keystone.
Thanks,
Jamie
[1] https://review.openstack.org/#/c/186684/
[2] http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? Thanks, Cathy From: Nicolas BOUTHORS [mailto:nicolas.bouth...@qosmos.com] Sent: Wednesday, June 17, 2015 12:03 AM To: Armando Migliaccio; Henry Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; Cathy Zhang; Moshe Levi; Joe D'Andrea; Ryan Tidwell; Vikram Choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: RE: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining In IETF SFC draft-penno-sfc-appid-00 proposed a notion of ApplicationId, a generic attribute that can be included in NSH metadata. This reflects also on ODL SFC wich has introduced the Application Id as a parameter that can be used by the Classifier to steer traffic into a chain. I suggest we include this parameter in the Flow Filter resource, so that application aware service chaining can be done. ApplicationId is typically encoded in a 32 bit field. Application Identification Data Format The following table displays the Selector ID default length for the different Classification Engine IDs. Classification Selector ID default Engine ID Name length (in bytes) IANA-L3 1 PANA-L3 1 IANA-L4 2 PANA-L4 2 USER-Defined 3 PANA-L2 5 PANA-L7 3 ETHERTYPE2 LLC 1 PANA-L7-PEN 3 (*) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class. Eng. ID |zero-valued upper-bits ... Selector ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nicolas -Original Message- From: Jenkins (Code Review) [mailto:rev...@openstack.org] Sent: mercredi 17 juin 2015 08:46 To: Armando Migliaccio; Louis Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; cathy; Moshe Levi; Joe D'Andrea; Ryan Tidwell; vikram.choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining Jenkins has posted comments on this change. Change subject: Neutron API for Service Chaining .. Patch Set 8: Verified+1 Build succeeded (check pipeline). - gate-neutron-specs-docs http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62//doc/build/html/http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62/doc/build/html/ : SUCCESS in 3m 51s - gate-neutron-specs-python27 http://logs.openstack.org/46/177946/8/check/gate-neutron-specs-python27/271ef19/ : SUCCESS in 2m 31s -- To view, visit https://review.openstack.org/177946 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic0df6070fefd9ead6589fa2da6c49824d7ae3941 Gerrit-PatchSet: 8 Gerrit-Project: openstack/neutron-specs Gerrit-Branch: master Gerrit-Owner: Louis Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Gerrit-Reviewer: Adolfo Duarte adolfo.dua...@hp.commailto:adolfo.dua...@hp.com Gerrit-Reviewer: Armando Migliaccio arma...@gmail.commailto:arma...@gmail.com Gerrit-Reviewer: Berezovsky Irena irenab@gmail.commailto:irenab@gmail.com Gerrit-Reviewer: Bob Melander bob.melan...@gmail.commailto:bob.melan...@gmail.com Gerrit-Reviewer: Gal Sagie
Re: [openstack-dev] [neutron][db] online schema upgrades
On Wed, Jun 17, 2015 at 8:23 PM, Mike Bayer mba...@redhat.com wrote:
On 6/17/15 12:40 PM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 11:27 AM, Anna Kamyshnikova wrote:
Ihar, thanks for bringing this up!
This is very interesting and I think it worth trying. I'm +1 on
that and want to participate in this work.
Awesome.
In fact a lot *not strict* migrations are removed with
juno_initial, so I hope it won't be so hard for now to apply
stricter rules for migration. But what is the plan for those
migrations that are *not strict* now?
Still, we have several live data migrations from Juno to Kilo:
- - 14be42f3d0a5_default_sec_group_table.py: populates db with default
security groups;
- - 16cdf118d31d_extra_dhcp_options_ipv6_support.py: populates
extraqdhcpopts with default ip_version = 4;
- - 2d2a8a565438_hierarchical_binding.py: populates db with
port_binding_levels objects, then drops old tables;
- - 35a0f3365720_add_port_security_in_ml2.py: port security field is
populated with True for ports and networks;
- - 034883111f_remove_subnetpool_allow_overlap.py: drops allow_overlap
column from subnetpools: probably unused so we can be ok with it?..
In any case, the plan for existing migration rules is: don't touch
them. Their presence in N release just indicates that we cannot get
online db migration in N+1. That's why we should adopt strict rules
the earlier the better, so that opportunity does not slip to N+X where
X is too far.
The patches currently in review that look suspicious in this regard are:
- - I4ff7db0f5fa12b0fd1c6b10318e9177fde0210d7: moves data from one table
into another;
- - Iecb3e168a805fc5f3d59d894c3f0d9298505e872: fills new columns with
default server values (why is it even needed?..);
- - Icde55742aa78ed995bac0896c01c80c9d28aa0cf: alter_column(). Not sure
we are ok with it;
- - I66b3ee8c2f9fa6f04b9e89dc49d1a3d277d63191: probably not an issue
though since it touches existing live data impact rule?
I made a list of migrations from juno- kilo that are non expansive or do
data migrations:
*these contain drop column:*
034883111f_remove_subnetpool_allow_overlap.py
2d2a8a565438_hierarchical_binding.py
*these contain drop table:*
28c0ffb8ebbd_remove_mlnx_plugin.py
2b801560a332_remove_hypervneutronplugin_tables.py
408cfbf6923c_remove_ryu_plugin.py
57086602ca0a_scrap_nsx_adv_svcs_models.py
*these contain data migrations:*
14be42f3d0a5_default_sec_group_table.py
16cdf118d31d_extra_dhcp_options_ipv6_support.py
2b801560a332_remove_hypervneutronplugin_tables.py
2d2a8a565438_hierarchical_binding.py
35a0f3365720_add_port_security_in_ml2.py
*Example of failure:*
neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
- drops the following columns:
op.drop_constraint(fk_name_dvr[0], 'ml2_dvr_port_bindings',
'foreignkey')
op.drop_column('ml2_dvr_port_bindings', 'cap_port_filter')
op.drop_column('ml2_dvr_port_bindings', 'segment')
op.drop_column('ml2_dvr_port_bindings', 'driver')
op.drop_constraint(fk_name[0], 'ml2_port_bindings', 'foreignkey')
op.drop_column('ml2_port_bindings', 'driver')
op.drop_column('ml2_port_bindings', 'segment')
which then causes a failure in Juno:
OperationalError: (OperationalError) (1054, Unknown column
'ml2_port_bindings_1.driver' in 'field list')
In M release we will be able to create kilo_initial migration that will
hide all these migrations(juno - kilo), so I as there is nothing we can do
we won't touch them as Ihar said. The problem about migrations that are on
review is more serious, as we should adopt strict rules as early as
possible and all core reviewer should be aware about that.
To Ihar's list of migrations on review I can add :
I3426b13eede8bfa29729cf3efea3419fb91175c4 - insert some data,
I9cf36e1fd3a009c175e0d475af407a30f4e5c408 (almost ready to be merged!) -
drop tables.
And there are a lot changes with altering columns. One is merged in
neutron-vpnaas.
So we should decide these things quickly.
(the list can be incomplete)
I think that we should try to use Alembic as much we could as Mike
is going to support us in that and we have time to make some change
in Alembic directly.
Yes, sure, I'm looking forward to see Mike's proposal in public.
We should undoubtedly plan this work for M release because there
will be some issues that will appear in the process.
Sure.
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVgaL4AAoJEC5aWaUY1u57oZgH/34pgV7AqOiq4XnWOOmQ9HA9
jL+8E9jv8pUSW3X4v0Rm5mDuWJyWscrgy61Om+sWsmqBFAmm/gmLWm+NNADbYM5e
6hsoaO5WmuvRc03MwIwsa0NEgfPc8EhT5JiZmYRjOBc85ZCs6+UOKUHBAI2EVTg8
t8YKdTdzxlrZQEOng1lbsUQYkHnNUZTbsREnpangfaHXBk3xmilH/ebGsz3CRUCe
OBrpp6q8N7mgZgK/UQKb04eS5bCna7eVmv6q7PvIO0SlYhhDbrL3+dv/SZpqQWZ/
Hek2Oig0IYyPygVrGc4BpT9MIaKisGoxXMn1rRB2g8us8jM58VyzqgXwEH2H4Aw=
=TqHb
-END
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Thanks, Oleksii 6/17/15 20:29, Clint Byrum пишет: Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: On 06/16/2015 12:49 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. The recent spec we added to define a policy for oslo.messaging drivers is intended as a way to encourage that 5% who feels a different messaging layer is critical to participate upstream by adding devstack-gate jobs and committing developers to keep them stable. This change basically slams the door in their face and says good luck, we don't actually care about accomodating you. This will drive them more into the shadows, and push their forks even further away from the core of the project. If that's your intention, then we need to have a longer conversation where you explain to me why you feel that's a good thing. I believe it is not the responsibility of the devstack team to support every possible backend one could imagine and carry that technical debt in tree, confusing new users in the process that any of these things might actually work. I believe that if you feel that your spec assumed that was going to be the case, you made a large incorrect externalities assumption. I agree with you, and support your desire to move things into plugins. However, your timing is problematic and the lack of coordination with the ongoing effort to deprecate untested messaging drivers gracefully is really frustrating. We've been asking (on this list) zmq interested parties to add devstack-gate jobs and identify themselves as contacts to support these drivers. Meanwhile this change and the wording around it suggest that they're not welcome in devstack. Also, I take issue with the value assigned to dropping it. If that 95% is calculated as orgs_running_on_rabbit/orgs then it's telling a really lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. I'd like to propose that we leave all of this in tree to match what is in oslo.messaging. I think devstack should follow oslo.messaging and deprecate the ones that oslo.messaging deprecates. Otherwise I feel like we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to climb the last 10 meters to the top of the cliffs of insanity and battle RabbitMQ left handed. I know, inconceivable right? We have an external plugin mechanism for devstack. That's a viable option here. People will have to own and do that work, instead of expecting the small devstack team to do that for them. I believe I left enough of a hook in place that it's possible. So lets do some communication, and ask for the qpid and zmq people to step up, and help them move their code into an external plugin, and add documentation to help their users find it. The burden should shift, but it still rests with devstack until it _does_ shift. That would also let them control the code relevant to their plugin, because there is no way that devstack was going to gate against other backends here, so we'd end up breaking them pretty often, and it taking a while to fix them in tree. I love that idea. That is not what the change does though. It deletes with nary a word about what users of this code should do until new external plugins appear. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Roadmap additions
Keith Bray wrote: As an FYI, I took a shot at updating the OpenStack wiki view of the Roadmap for Solum per IRC and developer collaboration, where good progress has been made over the last cycle delivering on features that make Solum usable in a production OpenStack system environment. This is, of course, one view of a feature set for the next milestone. As always, community input, collaboration, and contribution is welcome. https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap Thanks Keith, that's very helpful. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] When do we import aodh?
On Wed, Jun 17 2015, gordon chung wrote: don't we need an initial migration still? to create all the base tables? You don't need a migration for that, SQLAlchemy handles that on its own. We'll add an initial migration once we start using Alembic. any thought to using ceilometer repo as a base rather than duplicating code? ie https://github.com/jd/aodh/blob/master/aodh/storage/sqlalchemy/utils.py or does that cause weird cyclic madness? I don't think this is a good idea, but I think that this code should be moved to a common place (e.g. Oslo) as we have some version of it in Gnocchi too. Cheers, -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] V3 Authentication for swift store
-Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 18 June 2015 07:02 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [glance] V3 Authentication for swift store Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. snip However in future we are trying to open up authentication so it's not limited to only user/password authentication. Immediate goals for service to service communications are to enable SSL client certificates and kerberos authentication. This would be handled by keystoneclient sessions but they are not supported by swift and it would require a significant rewrite of swiftclient to do, and the swift team has indicated they do not which to invest more time into their client. If we consider specifically the swiftclient Connection class, I wonder how significant a rewrite would be to support session objects? I'm not too familiar with sessions - is a session an object with an interface to fetch a token and service endpoint url? If so maybe Connection could accept a session in lieu of auth options and call the session rather than its get_auth methods. If we can move towards sessions in swiftclient then that would be good IMHO, since we have also have requirement to support fetching a service token [1], which I guess would (now or in future) also be handled by the session? [1] https://review.openstack.org/182640 Alistair snip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [Ceilometer] Ceilometer Python API Documentation
Debug Ceilometer code, It is the best documentation itself! On Thu, Jun 18, 2015 at 11:16 AM, gordon chung g...@live.ca wrote: hi Hassaan, there's a similar link here: http://docs.openstack.org/developer/python-ceilometerclient i don't know if we have official docs but you can see some usage examples here: https://www.rdoproject.org/CeilometerQuickStart#Exploring_with_the_CLI On 18/06/2015 1:24 AM, Hassaan Ali wrote: Hi, I am looking for Openstack Ceilometer Python API Documentation that includes example codes and guidelines for using it. So far I have been able to find the following link but it is not that much helpful: http://docs.openstack.org/developer/python-heatclient/ Your help will be highly appreciated. Thanks. -- Regards, * Hassaan * __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 17/06/15 15:08 -0400, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: On 06/17/2015 01:29 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: On 06/16/2015 12:49 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. The recent spec we added to define a policy for oslo.messaging drivers is intended as a way to encourage that 5% who feels a different messaging layer is critical to participate upstream by adding devstack-gate jobs and committing developers to keep them stable. This change basically slams the door in their face and says good luck, we don't actually care about accomodating you. This will drive them more into the shadows, and push their forks even further away from the core of the project. If that's your intention, then we need to have a longer conversation where you explain to me why you feel that's a good thing. I believe it is not the responsibility of the devstack team to support every possible backend one could imagine and carry that technical debt in tree, confusing new users in the process that any of these things might actually work. I believe that if you feel that your spec assumed that was going to be the case, you made a large incorrect externalities assumption. I agree with you, and support your desire to move things into plugins. However, your timing is problematic and the lack of coordination with the ongoing effort to deprecate untested messaging drivers gracefully is really frustrating. We've been asking (on this list) zmq interested parties to add devstack-gate jobs and identify themselves as contacts to support these drivers. Meanwhile this change and the wording around it suggest that they're not welcome in devstack. So there has clearly been some disconnect here. This patch was originally going to come later in the cycle, but some back and forth on proton fixes with Flavio made me realize we really needed to get this direction out in front of more people (which is why it wasn't just a patch, it was also an email heads up). So there wasn't surprise when it was merged. We built the external plugin mechanism in devstack to make it very easy to extend out of tree, and make it easy to let people consume your out of tree stuff. It's the only way that devstack works in the big tent world, because there just is too much stuff for the team to support. Every change like this makes it harder for newcomers to participate. Frankly, it makes it harder for everyone because it means there are more moving parts, but in this specific case many of the people involved in these messaging drivers are relatively new, so I point that out. The already difficult task of setting up sufficient functional tests has now turned into figure out devstack, too. The long-term Oslo team members can't do all of this work, any more than the devstack team can, but things were at least working in what we thought was a stable way so we could try to provide guidance. This is definitely an unfortunate side-effect of this change and it'll increase the burden we, oslo.messaging maintainers, will have to carry. Oslo messaging have moved away from using devstack for the functional tests, it doesn't even use plugins. However, this won't be enough to provide proper testing, as we're also requesting o.m drivers maintainers to have and integrated gate running (which will obviously require having a devstack plugin for o.m). In the long run, I think the split would benefit oslo.messaging as it'll give us more control on what's going on in devstack land for each driver. I'm personally tired of having patches like this[0] blocked because devstack is missing some packages. [0] https://review.openstack.org/#/c/192417/ I know none of us is arguing against the goal but the method. I just wanted to point something in favor of the change and also say that I agree we should have a proper deprecation path (keep reading). Also, I take issue with the value assigned to dropping it. If that 95% is calculated as orgs_running_on_rabbit/orgs then it's telling a really lop-sided story. I'd
Re: [openstack-dev] [Ceilometer][Gnocchi] question on integration with time-series databases
On 18 Jun 2015 at 04:44:18, gordon chung (g...@live.ca) wrote: On 17/06/2015 12:57 PM, Chris Dent wrote: On Tue, 16 Jun 2015, Simon Pasquier wrote: I'm still struggling to see how these optimizations would be implemented since the current Gnocchi design has separate backends for indexing and storage which means that datapoints (id + timestamp + value) and metric metadata (tenant_id, instance_id, server group, ...) are stored into different places. I'd be interested to hear from the Gnocchi team how this is going to be tackled. For instance, does it imply modifications or extensions to the existing Gnocchi API? I think there's three things to keep in mind: a) The plan is to figure it out and make it work well, production ready even. That will require some iteration. At the moment the overlap between InfluxDB python driver maturity and someone-to-do-the- work is not great. When it is I'm sure the full variety of optimizations will be explored, with actual working code and test cases. just curious but what bugs are we waiting on for the influxdb driver? i'm hoping Paul Dix has prioritised them? b) Gnocchi has separate _interfaces_ for indexing and storage. This is not the same as having separate _backends_[1]. If it turns out that the right way to get InfluxDB working is for it to be the same backend to the two separate interfaces then that will be okay. i'll straddle the middle line here and say i think we need to wait for a viable driver before we can start making the appropriate adjustments. having said that, i think once we have the gaps resolved, i think we should make all effort to conform to the rules of the db (whether it is influxdb, kairosdb, opentsdb). we faced a similar issue with the previous data storage design where we generically applied a design for one driver across all drivers and that led to terribly inefficient design everywhere. I'd like to emphasise that using the same backend for both data-point time-series and the identification of the resources linked to those time-series is not only the right way, it is the mandatory way. The most salient reason being that we shall not mandate other applications consuming time-series produced through Gnocchi to use anything else than the time-series backend native API. Operators who want to use InfluxDB, OpenTSDB or something else, as their time-series backend, do it for a reason. The choice of an API that best suits their needs is key to that decision. It is also a question of effectiveness. There are plenty of applications out there like Grafana that plug into those time-series out-of-the-box. I don’t think we want to force those applications to use the Gnocchi API instead. - Patrick c) The future is unknown and the present is not made of stone. There could be modifications and extensions to the existing stuff. We don't know. Yet. [1] Yes the existing implementations use SQL for the indexer and various subclasses of the carbonara abstraction as two backends for the two interfaces. That's an accident of history not a design requirement. -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
