[openstack-dev] [Neutron][LBaaS] Random 503 returned by Haproxy
Hi,
Recently I am working on LBaaS service. When I set up a pool and it serves,
the haproxy process randomly returns 503:
503 Service Unavailabe
No server is available to handle this request
This could be easily reproduced and I am pretty sure when this happened,
member servers are up.
Meanwhile, I ran another haproxy process, started with CentOS init script.
And the problem never showed. I replaced /etc/haproxy/haproxy.cfg with
.../lbaas/{poo_id}/conf file (change stat socket path and group) and it
still OK.
So, I checked init script and LBaaS-agent code, found there is a -D
argument in the init script when creating Haproxy process. I killed haproxy
process for the pool, and restart it with one more -D argument in pool's
namespace, and the problem finally gone.
I don't know much about Haproxy, how could this -D argument make such
difference (since there deamon options in the configuration file) ?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How-to and best practices for developing new OpenStack service
Thanks for the links, cookiecutter template is useful for obtaining initial project structure. Short tutorial for developers not familiar with OpenStack infrastructure still would be useful. My task is to help Python developers that haven't worked with OpenStack before start an OpenStack service development in the shortest possible period. If none will come up, I'll be thinking about writing one :) On Wed, May 7, 2014 at 4:08 PM, Ruslan Kamaldinov rkamaldi...@mirantis.comwrote: Hi Ruslan! I can recommend two resources: 1. cookiecutter [1] - template for a new OpenStack project 2. http://ci.openstack.org/stackforge.html - this page helps to setup a project in OpenStack infrastructure, including code-review, Jenkins automation, etc. [1] http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/README.rst Regards, Ruslan On Wed, May 7, 2014 at 4:08 PM, Ruslan Kiianchuk ruslan.kiianc...@gmail.com wrote: Hello, community. There are numerous open projects evolving that are designed to work with OpenStack and follow OpenStack development principles (technologies stack, architecture, etc.). There are even more efforts within many companies working with cloud technologies. However it is hard to quick-start with all the practices developed at OpenStack community and start developing an OpenStack service the right way. So are there any resources, tutorials, guides on how to start an OpenStack service from scratch? Something that would describe correct usage of Oslo project, common architecture and give recommendations for developers. Thank you. -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely, Ruslan Kiianchuk. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Call for alternate session leader for Signed Images
On 07/05/14 22:45 -0700, Mark Washenberger wrote: Hi folks, Unfortunately, the leader for one of our proposed sessions is now unable to attend the summit. The topic in question is Signed Images [1] and was allocated a half-session slot. This is a call out to see if there are any other folks who would like to lead this discussion. If not, no big deal. We will have other things to discuss during that time. This seems a quite requested feature and an interesting topic. I'll like to lead this session. I'll sync w/ the former leader of this session and prepare one based on his ideas. Flavio -- @flaper87 Flavio Percoco pgpSS6u4GnOtj.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How-to and best practices for developing new OpenStack service
On Thu, May 8, 2014 at 11:16 AM, Ruslan Kiianchuk ruslan.kiianc...@gmail.com wrote: Short tutorial for developers not familiar with OpenStack infrastructure still would be useful. My task is to help Python developers that haven't worked with OpenStack before start an OpenStack service development in the shortest possible period. If none will come up, I'll be thinking about writing one :) Yes, intro tutorial could be useful. But before you start, please take a look at existing resources: 1. https://wiki.openstack.org/wiki/HowToContribute 2. https://wiki.openstack.org/wiki/GerritWorkflow 3. https://wiki.openstack.org/wiki/GitCommitMessages AFAIK Stefano and Tom are working on something similar. Added them to cc list. Thanks, Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
Just a couple of quick comments since it is super late here and I don't want to reply to the entire email just yet... Firstly, I think most of us at Rackspace like the way your proposal handles L7 (hopefully my team actually agrees and I am not speaking out of turn, but I definitely like it), so I wouldn't really consider that as a difference because I think we'd like to incorporate your method into our proposal anyway. Similarly, upon further review I think I would agree that our SSL cert handling is also a bit wonky, and could be much improved by another draft. In fact, I'd like to assume that what we're really discussing is making a third revision of the proposal, rather than whether to use one or the other verbatim. Secondly, technical descriptions are great, but I'd like to talk about the term load balancer in a more approachable manner. I forget which thread I used this example in before, but to get an idea of what we mean by the term, I like to use it in some sentences. My web servers are behind a load balancer, so they can better serve traffic to my customers. I used to only have one MySQL server, but now I have three, so I put a load balancer in front of them to ensure they get an equal amount of traffic. This isn't highly technical talk -- and it is definitely very generic -- but this is how REAL PEOPLE see the technology we're developing here. That is part of why the definitions we're using are so vague. I refuse to get tied down by an object graph full of pools and VIPs and listeners! There are two very similar points I'd like to make here, and I feel that both are very important: 1. We shouldn't be looking at the current model and deciding which object is the root object, or what object to rename as a loadbalancer... That's totally backwards! *We don't define which object is named the loadbalancer by looking for the root object -- we define which object is the root by looking for the object named loadbalancer.* I had hoped that was clear from the JSON examples in our API proposal, but I think maybe there was too much focus on the object model chart, where this isn't nearly as clearly communicated. 2. As I believe I have also said before, if I'm using X as a Service then I expect to get back an object of type X. I would be very frustrated/confused if, as a user, LBaaS returned me an object of type VIP when I POST a Create for my new load balancer. On this last point, I feel like I've said this enough times that I'm beating a dead horse... Anyway, I should get at least a little bit of sleep tonight, so I'll see you all in IRC in a few hours! --Adam PS: I really hope that colloquialism translates appropriately. I've got nothing against horses. :) On May 7, 2014 7:44 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Howdy y'all! Per the e-mail I sent out earlier today, I wanted to share some thoughts on the API proposals from Rackspace and Blue Box that we're currently working on evaluating, presumably to decide which will be the version will be the starting point from which we make revisions going forward. I'll try to be relatively brief. First, some thanks! The Rackspace team really pulled out the stops this last week producing an abundance of documentation that very thoroughly covers a bunch of the use cases available at that time in excruciating detail. They've produced a glossary and suggested object diagram, and their proposal is actually looking pretty dang good in my opinion. I'm especially interested in hearing your opinion on the stuff I'm laying out below-- especially if I'm misunderstanding or mis-representing your viewpoint on any issue, eh! Why the review process we're using probably won't be conclusive So, at the last week's meeting we decided that the RAX team and I would work on producing a spreadsheet listing the use cases in question and go over how each of these would be accomplished using our API. Having gone through this exercise, I see the following problems with this approach to evaluation: * While we have thorough documentation, it's probably more than the average participant here is going to go through with a fine-toothed comb to find the subtle differences. Furthermore, there's already a huge amount of documentation produced, and we've only gone over about 1/5th of the use cases! * Since the BBG version API proposal is actually a revision of the Rackspace proposal in many ways, at its core, our models are actually so similar that the subtle differences don't come out with general / generic use cases in many ways. And the only use cases we've evaluated so far are pretty general. :/ * In fact, the only significant ways in which the proposals differ are: * BBG proposal uses VIP as single-call interface, and it's the root of the object tree from the user's perspective. * Rackspace proposal uses loadbalancer as single-call interface, and it's the root of the object tree from the
Re: [openstack-dev] [Barbican][Neutron] Cred management for ssl-vpn
corrected subject
On Thu, May 8, 2014 at 2:44 AM, Nachi Ueno na...@ntti3.com wrote:
Hi Barbican folks
I'm trying to rewrite existing ssl-vpn bp with integration with barbican.
so I'm really appliciate if I can get your input.
In original proposal, we have vpn credential resource who has followings
- id
- ca (PEM encoded)
- server_certificate (PEM encoded)
- server_key (PEM encoded)
- dh (PEM encoded)
- crl (PEM encoded)
We have also ssl-vpn-connection resource who has
credential_id
https://wiki.openstack.org/wiki/Neutron/VPNaaS/SSLVPN
IMO, we can remove vpn credential resources completely if we use Barbican.
What's I'm thinking is having payload something like this.
{payload: {
ca : xxx,
'server_key': 'xxx
}}
Is this good idea in Barbican context?
Best
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com
+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
On Mon, May 05, 2014 at 01:40:43PM -0400, Solly Ross wrote: One thing that I was discussing with @jaypipes and @dansmith over on IRC was the possibility of breaking flavors down into separate components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor. This way, you still get the control of the size of your building blocks (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid exponential flavor explosion by separating out the axes. Splitting up flavours in that way doesn't really fly, especially for CPU RAM, because the properties you want to configure for NUMA policies cross both CPU RAM so cannot be sensibly separated. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][QA] Partial fix for unittest memory consumption
Memory usage due to plugin+mock leakage is addressed by the following patch: https://review.openstack.org/#/c/92793/ I'm seeing residual (post-test) memory usage decrease from ~4.5gb to ~1.3gb with 12 concurrent test runners. Of the 1.3gb, sqlalchemy is taking the lion share at ~500mb, so that will be my next target. Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There's already a standard for a nice way to bundle those two elements together, it's described in PKCS#12 and you've likely come across it in the form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-c ontainer) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.com mailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. From: John Wood [mailto:john.wood@ http://RACKSPACE.COM RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates We intend to discuss this feature in Atlanta to enable coding in earnest for Juno. The Container resource is intended to capture/store the final certificate details. Thanks, John _ From: Samuel Bercovici [ mailto:samu...@radware.com samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hi Vijay, I have looked at the Barbican APIs - https://github.com/cloudkeep/barbican/wiki/Application-Programming-Inte rface https://github.com/cloudkeep/barbican/wiki/Application-Programming-Inter face I was no able to see a native API that will accept an SSL certificate (private key, public key, CSR, etc.) and will store it. We can either store the whole certificate as a single file as a secret or use a container and store all the certificate parts as secrets. I think that having LBaaS reference Certificates as IDs using some service is the right way to go so this might be achived by either: 1. Adding to Barbican and API to store / generate certificates 2. Create a new module that might start by being hosted in neutron or keystone that will allow to manage certificates and will use Barbican behind the scenes to store them. 3. Decide on a container structure to use in Babican but implement the way to access and arrange it as a neutron library Was any decision made on how to proceed? Regards, -Sam. From: Vijay B [ mailto:os.v...@gmail.com mailto:os.v...@gmail.com] Sent: Wednesday, April 30, 2014 3:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for LBaaS and VPN Hi, It looks like there are areas of common effort in multiple efforts that are proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron. Two relevant efforts are listed below: https://review.openstack.org/#/c/74031/
Re: [openstack-dev] [Glance] Call for alternate session leader for Signed Images
This is an interesting topic indeed: we though about the very same idea in Murano (checking the origin of app definitions is a good thing for an application catalog). If there are similar ideas in other projects, then this definitely should belong to Glance catalog. -- Regards, Alexander Tivelkov On Thu, May 8, 2014 at 11:36 AM, Flavio Percoco fla...@redhat.com wrote: On 07/05/14 22:45 -0700, Mark Washenberger wrote: Hi folks, Unfortunately, the leader for one of our proposed sessions is now unable to attend the summit. The topic in question is Signed Images [1] and was allocated a half-session slot. This is a call out to see if there are any other folks who would like to lead this discussion. If not, no big deal. We will have other things to discuss during that time. This seems a quite requested feature and an interesting topic. I'll like to lead this session. I'll sync w/ the former leader of this session and prepare one based on his ideas. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). Option 1 or 2 might be the ultimate goal. Regards, -Sam. From: Clark, Robert Graham [mailto:robert.cl...@hp.com] Sent: Thursday, May 08, 2014 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There's already a standard for a nice way to bundle those two elements together, it's described in PKCS#12 and you've likely come across it in the form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. From: John Wood [mailto:john.w...@rackspace.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates We intend to discuss this feature in Atlanta to enable coding in earnest for Juno. The Container resource is intended to capture/store the final certificate details. Thanks, John From: Samuel Bercovici [samu...@radware.commailto:samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hi Vijay, I have looked at the Barbican APIs -https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface I was no able to see a native API that will accept an SSL certificate (private key, public key, CSR, etc.) and will store it. We can either store the whole certificate as a single file as a secret or use a container and store all the certificate parts as secrets. I think that having LBaaS reference Certificates as IDs using some
Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
On Mon, May 05, 2014 at 07:40:08PM +, Dimitri Mazmanov wrote: This is good! Is there a blueprint describing this idea? Or any plans describing it in a blueprint? Would happily share the work. Should we mix it with flavors in horizon though? I¹m thinking of having a separate ³Resources² page, wherein the user can ³define² resources. I¹m not a UX expert though. But let me come back to the project-scoped flavor creation issues. Why do you think it¹s such a bad idea to let tenants create flavors for their project specific needs? I¹ll refer again to the Steve Hardy¹s proposal: - Normal user : Can create a private flavor in a tenant where they have the Member role (invisible to any other users) - Tenant Admin user : Can create public flavors in the tenants where they have the admin role (visible to all users in the tenant) - Domain admin user : Can create public flavors in the domains where they have the admin role (visible to all users in all tenants in that domain) NB, flavours have an important role as a means of access control against limited compute resources. eg if you have a limited number of hosts which have provide a large page sizes, you don't want any normal user to be able to define their own flavour which lets them consume large pages. This is why there is a distinction between properties set on images vs properties set on flavours. Image properties, which a normal user can set, are restricted to aspects of the VM which don't involve consumption of compute host resources. Flavour properties, which only a user with 'flavourmanage' permission can change, control aspects of the VM config which consume finite compute resources. If we were to allow a normal user to define flavours, we would need to come up with a way to deal with this access control requirement. One possible option, would be to not allow a normal user to create completely new flavours. Instead allow them to take an existing flavour to which they have access, and reduce (but not increase) its allocated resources. eg if the user wanted to create a flavour with 1.5 GB of RAM, they would have to have access to a pre-existing flavour which had more than 1.5 GB of RAM. eg they'd take a 2 GB flavour and override the RAM setting to be just 1.5 GB. This opens up a question of billing for hosting providers - perhaps they would allow the user this customization, but still bill them for the original flavour specs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
On Thu, May 08, 2014 at 11:22:38AM +0100, Daniel P. Berrange wrote: On Mon, May 05, 2014 at 07:40:08PM +, Dimitri Mazmanov wrote: This is good! Is there a blueprint describing this idea? Or any plans describing it in a blueprint? Would happily share the work. Should we mix it with flavors in horizon though? I¹m thinking of having a separate ³Resources² page, wherein the user can ³define² resources. I¹m not a UX expert though. But let me come back to the project-scoped flavor creation issues. Why do you think it¹s such a bad idea to let tenants create flavors for their project specific needs? I¹ll refer again to the Steve Hardy¹s proposal: - Normal user : Can create a private flavor in a tenant where they have the Member role (invisible to any other users) - Tenant Admin user : Can create public flavors in the tenants where they have the admin role (visible to all users in the tenant) - Domain admin user : Can create public flavors in the domains where they have the admin role (visible to all users in all tenants in that domain) NB, flavours have an important role as a means of access control against limited compute resources. eg if you have a limited number of hosts which have provide a large page sizes, you don't want any normal user to be able to define their own flavour which lets them consume large pages. This is why there is a distinction between properties set on images vs properties set on flavours. Image properties, which a normal user can set, are restricted to aspects of the VM which don't involve consumption of compute host resources. Flavour properties, which only a user with 'flavourmanage' permission can change, control aspects of the VM config which consume finite compute resources. If we were to allow a normal user to define flavours, we would need to come up with a way to deal with this access control requirement. One possible option, would be to not allow a normal user to create completely new flavours. Instead allow them to take an existing flavour to which they have access, and reduce (but not increase) its allocated resources. eg if the user wanted to create a flavour with 1.5 GB of RAM, they would have to have access to a pre-existing flavour which had more than 1.5 GB of RAM. eg they'd take a 2 GB flavour and override the RAM setting to be just 1.5 GB. This opens up a question of billing for hosting providers - perhaps they would allow the user this customization, but still bill them for the original flavour specs. Of course if you take this idea to its logical conclusion, you would arguably not need to give users the ability to create flavours. If you only permit them to reduce the resources associated with a flavour they use, then you could just allow them to request a reduced set of resources at time they boot the instance. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Decreasing resource usage in tripleo CI
On 07/05/14 00:07, Clint Byrum wrote: +1 to the plans. We've recently freed up a few more boxes for the HP region, and we'll be rolling those out as we migrate from saucy to trusty for the rest of the cloud. But we should do all of the things below anyway. Thanks, didn't hear any objections, patch submitted https://review.openstack.org/#/c/92808/1 Excerpts from Derek Higgins's message of 2014-05-06 15:34:41 -0700: Hi, I mentioned this at the tripleo meeting today and to get opinions out there I'd like to bring it up here, In tripleo we are currently very tight on resources to run our CI jobs and I'd like to scale back temporarily until we have either more capacity or reorganize things a bit, to more efficiently use what we have. Basically I'd like to see us do 3 things 1. Get rid of check-tripleo-seed-precise job This is currently a subset of both check-tripleo-undercloud-precise and check-tripleo-overcloud-precise so is basically using up resources with no extra gain, if we put plans in place to deploy the undercloud/overcloud on a persistent seed we can add it back again. 2. Move the check-tripleo-ironic-undercloud-precise into the experimental-tripleo queue, this test is non voting and currently doesn't work, when its fixed we can put it back into the check-tripleo queue and delete the check-tripleo-ironic-seed-precise job, as it should be a subset of the ironic undercloud job (similar to the seed job mentioned in point 1) 3. Get back onto 8G nodepool instances, we moved to 16G instances a while back to work around a problem, I've a patch up that should allow us to get back to 8G nodes https://review.openstack.org/#/c/91545/ Any objections or alternate ideas? thanks, Derek. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel-dev] [Fuel][RabbitMQ] nova-compute stuck for a while (AMQP)
On 05/06/2014 10:42 PM, Roman Sokolkov wrote: Hello, fuelers. I'm using Fuel 4.1A + Havana in HA mode. I permanently observe (on other deployments also) issue with stuck nova-compute service. But i think problem is more fundamental and relates to HA RabbitMQ and OpenStack AMQP driver implementation. Symptoms: * Random nova-compute from time to time marked as XXX for a while. * I see that service itself works properly. In logs i see that it sends status updates to conductor. But actually nothing is sent. * netstat shows that all connections to/from rabbit ESTABLISHED * rabbitmqctl shows that compute.node-x queue synced to all slaves. * nothing has been broken before, i mean rabbitmq cluster, etc. Axe style solution: * /etc/init.d/openstack-nova-compute restart So here i've found a lot of interesting stuff (and solutions): https://bugs.launchpad.net/oslo.messaging/+bug/856764 My questions are: * Are there any thoughts particular for Fuel to solve/workaround this issue? * Any fast solution for this in 4.1? Like adjust TCP keep-alive timeouts? I submitted an issue for Fuel https://bugs.launchpad.net/fuel/+bug/1317488 and assigned it to Fuel hardening team. Feel free to update it as appropriate. -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com mailto:rsokol...@mirantis.com -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
My understanding is that option 1. Is already moving at pace it might just need a little finessing to ensure that it meets everyone's requirements. -Rob From: Samuel Bercovici [mailto:samu...@radware.com] Sent: 08 May 2014 11:20 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). Option 1 or 2 might be the ultimate goal. Regards, -Sam. From: Clark, Robert Graham [mailto:robert.cl...@hp.com] Sent: Thursday, May 08, 2014 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There's already a standard for a nice way to bundle those two elements together, it's described in PKCS#12 and you've likely come across it in the form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-c ontainer) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.com mailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. From: John Wood [mailto:john.wood@ http://RACKSPACE.COM RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates We intend to discuss this feature in Atlanta to enable coding in earnest for Juno. The Container resource is intended to capture/store the final certificate details. Thanks, John _ From: Samuel Bercovici [ mailto:samu...@radware.com samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com os.v...@gmail.com Subject: Re: [openstack-dev]
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
Hi Xuhan,
I agree that such subnet shouldn’t be allowed to be added in a neutron router.
However, I have some reservations in creating a subnet with an external LLA
gateway address. First of all, it seems that the sole purpose of providing the
gateway IP is to install an RA rule to permit RAs from that gateway. Secondly,
what if the gateway IP needs to be changed? Would that incur updates in the
neutron subnets that refer to it? I think that we need a better strategy for RA
spoofing. Currently, rogue RAs are dropped at the receiving end. Would it be
better to stop them at the source and to allow RAs being SENT from the
legitimate sources only?
thanks,
Robert
On 4/25/14, 5:46 AM, Xuhan Peng
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:
Sean and Robert,
Sorry for replying this late, but after giving this a second thought, I think
it makes sense to not allow a subnet with a LLA gateway IP address to be
attached to a neutron router for the following reasons:
1. A subnet with LLA address gateway specified is only used to receive RA from
provider router. I could not think of any other use case that a user want to
specify LLA address gateway for an Neutron subnet.
2. Attach a subnet with LLA (or even any address outside subnet's cidr) will
cause the port have two LLA (or another address outside subnet's cidr) on the
subnet gateway port (qr-). This will confuse dnsmasq about binding with
which address.
3. For allowing RA sending from dnsmasq on gateway port, we can use ip command
to get the LLA. Currently I use calculation method to get the source address,
but I will improve it to use ip command to make sure the source IP is right.
Thoughts? If we all agree, I will open a bug to disallow subnet with gateway
outside CIDR be attached to a router.
Xuhan
On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli)
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi Sean,
Unless I have missed something, this is my thinking:
-- I understand that the goal is to allow RAs from designated sources
only.
-- initially, xuhanp posted a diff for
https://review.openstack.org/#/c/72252. And my comment was that subnet
that was created with gateway ip not on the same subnet can't be added
into the neutron router.
-- as a result, https://review.openstack.org/#/c/76125/ was posted to
address that issue. With that diff, LLA would be allowed. But a
consequence of that is a gateway port would end up having two LLAs: one
that is automatically generated, the other from the subnet gateway IP.
-- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if
openstack native RA is enabled, then the automatically generated LLA will
be used; and if it's not enabled, it will use the external gateway's LLA.
And the diff seems to indicate this LLA comes from the subnet's gateway
IP.
-- Therefore, the change of https://review.openstack.org/#/c/76125/
seems to be able to add the gateway IP as an external gateway.
-- Thus, my question is: should such a subnet be allowed to add in a
router? And if it should, what would the semantics be? If not, proper
error should be provided to the user. I'm also trying to figure out the
reason that such a subnet needs to be created in neutron (other than
creating L2 ports for VMs).
-- Another thought is that if the RA is coming from the provider net, then
the provider net should have installed mechanisms to prevent rogue RAs
from entering the network. There are a few RFCs that address the rogue RA
issue.
see inline as well.
I hope that I didn't confuse you guys.
Thanks,
Robert
On 3/25/14 2:18 PM, Collins, Sean
sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com
wrote:
During the review[0] of the patch that only allows RAs from known
addresses, Robert Li brought up a bug in Neutron, where a
IPv6 Subnet could be created, with a link local address for the gateway,
that would fail to create the Neutron router because the IP address that
the router's port would be assigned, was a link local
address that was not on the subnet.
This may or may have been run before force_gateway_on_subnet flag was
introduced. Robert - if you can give us what version of Neutron you were
running that would be helpful.
[Robert] I'm using the latest
Here's the full text of what Robert posted in the review, which shows
the bug, which was later filed[1].
This is what I've tried, creating a subnet with a LLA gateway address:
neutron subnet-create --ip-version 6 --name myipv6sub --gateway
fe80::2001:1 mynet :::/64
Created a new subnet:
+--+
+
| Field | Value |
+--+
+
| allocation_pools | {start: :::1, end:
::::::fffe} | | cidr | :::/64 | |
dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1
| | host_routes | | | id |
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
Hi Stephen, A couple of inline comments: - BBG proposal just has attributes for both and IPv4 address and an IPv6 address in its VIP object. (Meaning it's slightly different than a VIP as people are likely to assume what that term means.) This is a correct approach. VIP has single neutron port, which however may have ip address on several subnets at once, so ipv4+ipv6 is easily solved within 1 VIP. I think that's a preferred way. - *Maybe we should wait until the survey results are out?* No sense solving for use cases that nobody cares about, eh. *Maybe we should just look at the differences?* The core object models we've proposed are almost identical. Change the term Listener to Load Balancer in my model, and you've essentially got the same thing as the Rackspace model. I guess you meant VIP, not Listener. I think what is more important is tree-like configuration structure. However having Loadbalancer as the root object vs VIP has difference in meaning. Loadbalancer implies several L2 ports for the frontend (e.g. multiple VIPs with own ip addresses) while VIP implies only one L2 port. For example, I understand the Rackspace model is using a join object between load balancer and vip so these can have a n:m relationship-- and this is almost entirely to solve use case #14 in the document. This is clearly an overkill to share VIPs between loadbalancer instances. *We need to decide what load balancer means and go that.* This has been something that's come up a lot, and the more we ignore it, it seems to me, the more it just adds to the confusion to the discussion. Rackspace is defining a load balancer as: An entity that contains multiple VIPs, but only one tcp/udp port and protocol ( http://en.wikipedia.org/wiki/Load_balancing_%28computing%29) . It may have a default pool (named just pool in API object). It also may have a content switching object attached that defines L7 rules. I may have missed something, did you mean one tcp/upd port and protocol per VIP? Or otherwise how is that possible? *What does the root mean when we're looking at an object graph, not a tree? Or maybe the people most likely to use the single-call interface should have the strongest voices in deciding where it should actually be placed?* I think probably the biggest source of contention over the API proposals thus far are what object should be considered the root of the tree. 'root object' has the sole purpose of transforming arbitrary graph of objects into a tree. We can't move forward without properly defining it. This whole concept seems to strike me as odd-- because when you have a graph, even if it's somewhat tree-like (ie. there are leaf nodes), does the term root even apply? Can someone please tell me what criteria they're using when they say that one object should be a root and another should not? Criterias are: - user can think of an object as representation of 'logical service instance' (logical loadbalancer) - workflow starts with object creation - it makes sense to apply attributes like Flavor (service requirements) to it. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
Hi Adam, My comments inline: 1. We shouldn't be looking at the current model and deciding which object is the root object, or what object to rename as a loadbalancer... That's totally backwards! *We don't define which object is named the loadbalancer by looking for the root object -- we define which object is the root by looking for the object named loadbalancer.* I had hoped that was clear from the JSON examples in our API proposal, but I think maybe there was too much focus on the object model chart, where this isn't nearly as clearly communicated. 2. As I believe I have also said before, if I'm using X as a Service then I expect to get back an object of type X. I would be very frustrated/confused if, as a user, LBaaS returned me an object of type VIP when I POST a Create for my new load balancer. On this last point, I feel like I've said this enough times that I'm beating a dead horse... I think we definitely should be looking at existing API/BBG proposal for the root object. The question about whether we need additional 'Loadbalancer' resource or not is not a question about terminology, so (2) is not a valid argument. What really matters in answering the question about 'loadbalancer' resource is do we need multiple L2 ports per single loadbalancer. If we do - that could be a justification to add it. Right now the common perception is that this is not needed and hence, 'loadbalancer' is not required in the API or obj model. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC
Excellent documentation. Thanks once again! I see the VIP creation is documented as a POST to the following URL http://client.url.com/v2.0/neutron/lbaas/vips I think the VIP should be outside the purview of LBaaS and remain in general neutron. Today an IP gets reserved as part of creation of a neutron port. Are you proposing to give an indirection for IP reservation? For ex. the above API will ultimately create a neutron port in the background? Thanks, Vijay V. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, May 8, 2014 1:40 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting Thursday, 05/08 14-00 UTC All of our relevant material is in this Google Drive folder == https://drive.google.com/#folders/0B_x8_4x6DRLad1NZMjgyVFhqakU Cheers, --Jorge On 5/7/14 1:19 PM, Kyle Mestery mest...@noironetworks.com wrote: Lets go over the Rackspace portion of the API comparison tomorrow then, and we can cover Stephen's on the ML when it's complete. On Wed, May 7, 2014 at 4:55 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Howdy, y'all! I just wanted to give you a quick update: It looks like the Rackspace team is mostly done with their half of the API comparison, however, it is extremely unlikely I'll be able to finish my half of this in time for the team meeting this Thursday. I apologize for this. Stephen On Tue, May 6, 2014 at 1:27 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, This will be the last meeting before the summit, so I suggest we will focus on the agenda for two design track slots we have. Per my experience design tracks are not very good for in-depth discussion, so it only make sense to present a road map and some other items that might need core team attention like interaction with Barbican and such. Another item for the meeting will be comparison of API proposals which as an action item from the last meeting. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Forbidden: It is not allowed to create an interface on external network
Hi,all! I encountered the following error when creating an instance of this time: *Forbidden: It is not allowed to create an interface on external network(HTTP 403)* In normal use this afternoon, I just re-create the external network admin, and demo-related networks. I really can not find the root cause of the problem, how to solve this problem? Thanks！ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Web of Trust Juno Summit Key Signing Participants List
I've had a few questions since the end of the sign-up period as to whether people who missed adding themselves to the list can still participate. While you can't get your key added to the list (the checksums have already been calculated and published) you can still feel free to print a copy and bring it with you to the room where this activity is taking place. That will allow you to verify the identification on the projector of people who are on the list, so that you can confidently sign their keys. To get your own key signed, you'll need to find opportunities during the conference to show your ID to people and give them a copy of your key fingerprint (we'll be scrambling to get through 65 people's IDs in the ~20 minutes we have available as it is). Tips on ad-hoc key signing can be found at: https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust#Key_Signing_Process Breaks, meals, parties, slow periods during sessions and presentations... these are all potential opportunities to show someone your ID and give them a copy of your key fingerprint. I usually carry ~100 business cards with my info and key fingerprint when attending any conference or user group meeting precisely for this reason, and am always happy to exchange ID and fingerprints with anyone who asks as long as I'm not too busy. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QA] Partial fix for unittest memory consumption
Thanks Maru, I've added this patch to my list of patches to review. I've also targeted the bug of J-1 because I love being a pedant bookkeeper. Salvatore On 8 May 2014 11:41, Maru Newby ma...@redhat.com wrote: Memory usage due to plugin+mock leakage is addressed by the following patch: https://review.openstack.org/#/c/92793/ I'm seeing residual (post-test) memory usage decrease from ~4.5gb to ~1.3gb with 12 concurrent test runners. Of the 1.3gb, sqlalchemy is taking the lion share at ~500mb, so that will be my next target. Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
On 05/08/2014 03:19 AM, Samuel Bercovici wrote: Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. It's really just private keys you need to be concerned about, not certificates themselves (which are really just a signed public key plus other public data like the subject, issuer, and validity). I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). I'd be concerned about implementing a separate service when this clearly falls into Barbican's target use-cases. We should be moving towards centralizing security related functionality like this instead of having multiple implementations of similar functionality. Option 1 or 2 might be the ultimate goal. I think 1 should be the ultimate goal. Barbican is designed for securely storing keys, which is exactly what you are trying to do. Thanks, -NGK Regards, -Sam. *From:*Clark, Robert Graham [mailto:robert.cl...@hp.com] *Sent:* Thursday, May 08, 2014 12:43 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There’s already a standard for a nice way to bundle those two elements together, it’s described in PKCS#12 and you’ve likely come across it in the form of ‘.pfx’ files. I’d suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container) -Rob *From:*Carlos Garza [mailto:carlos.ga...@rackspace.com] *Sent:* 08 May 2014 04:30 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.com mailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. *From:* John Wood [mailto:john.w...@rackspace.com http://RACKSPACE.COM] *Sent:* Thursday, May 01, 2014 11:28 PM *To:* OpenStack Development Mailing List (not for usage questions); os.v...@gmail.com mailto:os.v...@gmail.com *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one:
Re: [openstack-dev] [qa] Checking for return codes in tempest client calls
On 05/07/2014 10:48 AM, Ken'ichi Ohmichi wrote: Hi Sean, 2014-05-07 23:28 GMT+09:00 Sean Dague s...@dague.net: On 05/07/2014 10:23 AM, Ken'ichi Ohmichi wrote: Hi David, 2014-05-07 22:53 GMT+09:00 David Kranz dkr...@redhat.com: I just looked at a patch https://review.openstack.org/#/c/90310/3 which was given a -1 due to not checking that every call to list_hosts returns 200. I realized that we don't have a shared understanding or policy about this. We need to make sure that each api is tested to return the right response, but many tests need to call multiple apis in support of the one they are actually testing. It seems silly to have the caller check the response of every api call. Currently there are many, if not the majority of, cases where api calls are made without checking the response code. I see a few possibilities: 1. Move all response code checking to the tempest clients. They are already checking for failure codes and are now doing validation of json response and headers as well. Callers would only do an explicit check if there were multiple success codes possible. 2. Have a clear policy of when callers should check response codes and apply it. I think the first approach has a lot of advantages. Thoughts? Thanks for proposing this, I also prefer the first approach. We will be able to remove a lot of status code checks if going on this direction. It is necessary for bp/nova-api-test-inheritance tasks also. Current https://review.openstack.org/#/c/92536/ removes status code checks because some Nova v2/v3 APIs return different codes and the codes are already checked in client side. but it is necessary to create a lot of patch for covering all API tests. So for now, I feel it is OK to skip status code checks in API tests only if client side checks are already implemented. After implementing all client validations, we can remove them of API tests. Do we still have instances where we want to make a call that we know will fail and not through the exception? I agree there is a certain clarity in putting this down in the rest client. I just haven't figured out if it's going to break some behavior that we currently expect. If a server returns unexpected status code, Tempest fails with client validations like the following sample: Traceback (most recent call last): File /opt/stack/tempest/tempest/api/compute/servers/test_servers.py, line 36, in test_create_server_with_admin_password resp, server = self.create_test_server(adminPass='testpassword') File /opt/stack/tempest/tempest/api/compute/base.py, line 211, in create_test_server name, image_id, flavor, **kwargs) File /opt/stack/tempest/tempest/services/compute/json/servers_client.py, line 95, in create_server self.validate_response(schema.create_server, resp, body) File /opt/stack/tempest/tempest/common/rest_client.py, line 596, in validate_response raise exceptions.InvalidHttpSuccessCode(msg) InvalidHttpSuccessCode: The success code is different than the expected one Details: The status code(202) is different than the expected one([200]) Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Note that there are currently two different methods on RestClient that do this sort of thing. Your stacktrace shows validate_response which expects to be passed a schema. The other is expected_success which takes the expected response code and is only used by the image clients. Both of these will need to stay around since not all APIs have defined schemas but the expected_success method should probably be changed to accept a list of valid success responses rather than just one as it does at present. I hope we can get agreement to move response checking to the client. There was no opposition when we started doing this in nova to check schema. Does any one see a reason to not do this? It would both simplify the code and make sure responses are checked in all cases. Sean, do you have a concrete example of what you are concerned about here? Moving the check from the value returned by a client call to inside the client code should not have any visible effect unless the value was actually wrong but not checked by the caller. But this would be a bug that was just found if a test started failing. -David -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration
Hi Steve, I have added something to the design summit etherpad at [1] based on this ML discussion so far. I removed some items from my initial post since they seem to be resolved. I copied more concrete points from this thread into other items. Please have a look and edit as needed. [1] https://etherpad.openstack.org/p/juno-summit-heat-sw-orch Regards, Thomas Steve Baker sba...@redhat.com wrote on 28/04/2014 23:31:56: From: Steve Baker sba...@redhat.com To: openstack-dev@lists.openstack.org Date: 28/04/2014 23:32 Subject: Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration On 29/04/14 01:41, Thomas Spatzier wrote: Excerpts from Steve Baker's message on 28/04/2014 01:25:29: I'm with Clint on this one. Heat-engine cannot know the true state of a server just by monitoring what has been polled and signaled. Since it can't know it would be dangerous for it to guess. Instead it should just offer all known configuration data to the server and allow the server to make the decision whether to execute a config again. I still think one more derived input value would be useful to help the server to make that decision. This could either be a datestamp for when the derived config was created, or a hash of all of the derived config data. So as I said in another note, I agree that the this seems best handled in the in-instance tool and the Heat engine, or the resource should probably not have any new magic. If there is some additional state property that the resource maintains, and the in-instance tool handles it, that should be fine. I think what is important, is that users who want to use existing automation scripts do not have to implement much logic for interpreting that additional flag, but that we handle it in the generic hook invocation logic. Can you elaborate more on what you have in mind with the additional derived input value? Heat needs to give the hook or the config script enough information to know whether that *particular* combination of config script + input values has been executed on that server. It could do this by providing the timestamp or the hash of the derived config, then this piece of information can be compared with some local state on the server to decide whether to run the config again. Actually the hash could be calculated on the server too, so the hash could be calculated in 55-heat-config then consumed by the hook or config script. For this design session I have my own list of items to discuss: #4.1 Maturing the puppet hook so it can invoke more existing puppet scripts #4.2 Make progress on the chef hook, and defining the mapping from chef concepts to heat config/inputs/outputs #4.3 Finding volunteers to write hooks for Salt, Ansible #5.1 Now that heatclient can include binary files, discuss enhancing get_file to zip the directory contents if it is pointed at a directory #5.2 Now that heatclient can include binary files, discuss making stack create/update API calls multipart/form-data so that proper mime data can be captured for attached files #6.1 Discuss options for where else metadata could be polled from (ie, swift) #6.2 Discuss whether #6.1 can lead to software-config that can work on an OpenStack which doesn't allow admin users or keystone domains (ie, rackspace) #4.1 thru #4.3 are important and seem straight forward and more about finding people to do it. If there are design issues to be figured out, maybe we can do it offline via the ML. #5.1 and #5.2 are really interesting and map to use cases we have also seen internally. Is there a size limit for the binaries? Would this also cover, e.g. sending small binaries like a wordpress install tgz instead of doing a yum based install? Or would the latter be something to address via #6 below? #6 looks very interesting as well. We also thought about using swift not only for metadata but also for sharing installables to instances in cases where direct download from the internet, for example, is not possible. We'll just have to try it to find out were the limits are, but in general I would assume the following: * user_data limited to about 16k total, so anything bigger than that needs to go in the deployment input_values * practically speaking, a binary could go in a deployment input value or a swift object resource (which doesn't exist yet) to be passed to the deployment input value by url * The default heat.conf max_template_size=524288, so to avoid this limit binaries should be put into swift outside the scope of heat, and passed into the template as a parameter URL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
The way I was thinking this would work would be to allow flavor bundles if you will, which would allow 2 or more axes in one flavor (essentially preserving the existing functionality). Thus, if you needed NUMA, you could use those. - Original Message - From: Daniel P. Berrange berra...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 5:08:32 AM Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2) On Mon, May 05, 2014 at 01:40:43PM -0400, Solly Ross wrote: One thing that I was discussing with @jaypipes and @dansmith over on IRC was the possibility of breaking flavors down into separate components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor. This way, you still get the control of the size of your building blocks (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid exponential flavor explosion by separating out the axes. Splitting up flavours in that way doesn't really fly, especially for CPU RAM, because the properties you want to configure for NUMA policies cross both CPU RAM so cannot be sensibly separated. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
P.S. I feel like this is something that should be discussed at the design summit. Perhaps there's an existing session this could be discussed in (the unsession, perhaps?) - Original Message - From: Solly Ross sr...@redhat.com To: Daniel P. Berrange berra...@redhat.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 10:51:47 AM Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2) The way I was thinking this would work would be to allow flavor bundles if you will, which would allow 2 or more axes in one flavor (essentially preserving the existing functionality). Thus, if you needed NUMA, you could use those. - Original Message - From: Daniel P. Berrange berra...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 5:08:32 AM Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2) On Mon, May 05, 2014 at 01:40:43PM -0400, Solly Ross wrote: One thing that I was discussing with @jaypipes and @dansmith over on IRC was the possibility of breaking flavors down into separate components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor. This way, you still get the control of the size of your building blocks (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid exponential flavor explosion by separating out the axes. Splitting up flavours in that way doesn't really fly, especially for CPU RAM, because the properties you want to configure for NUMA policies cross both CPU RAM so cannot be sensibly separated. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ |:| |: http://libvirt.org -o- http://virt-manager.org |:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ |:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc |:| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Design session etherpads
Hi all! I've linked the etherpads from the wiki and the sched.org entries, but I'm guessing not everyone noticed that, so I'd like to draw attention to our session's etherpads ahead of the summit. Ironic Python Agent -- an effort, led by rackspace, to give Ironic a much more featureful deploy/ramdisk agent. https://etherpad.openstack.org/p/juno-summit-ironic-python-agent (I've pinged the RS folks to fill in some detail here) Hardware Multitenancy Risk Mitigation -- because abstinence is not the answer, let's discuss safer multitenancy. https://etherpad.openstack.org/p/juno-summit-ironic-multitenancy Discussion about Ironic service performance and scalability -- because there are some things we know we can improve, and some things we need to investigate further. https://etherpad.openstack.org/p/juno-summit-ironic-performance Planning for Juno -- because there's a *lot* we want to do with a limited set of (human) resources, we need to decide what to postpone. https://etherpad.openstack.org/p/juno-summit-ironic-arch Regards, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
+1 would be interested. -Original Message- From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] Sent: May-06-14 12:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit? For those attending, to discuss the QoS API current status? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] ML2 extensions info propagation
Hi Mathieu, Yes, the enhancement of the get_device_details method sounds like an interesting and useful option. The option of using drivers in the agent for supporting extensions is to make the agent more modular and allow for selectively supporting extensions as needed by a given agent. If we take the approach you are suggesting and eliminate or reduce the use of extension specific RPCs how can we achieve the modularity goal above? Is there a way to make these options useful together? More broadly, what would be the impact of your proposal on the modularity of the agent (if any)? Please note that as per discussion during the ML2 meeting yesterday we are going to have a single etherpad for each of ML2 sessions. The etherpad for the Modular Layer 2 Agent session can be found at [2] from your original email below. We may reorganize the information that is already there but please do add your comments there. Thanks, Mohammad From: Mathieu Rohon mathieu.ro...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 05/07/2014 10:25 AM Subject:[openstack-dev] [Neutron] ML2 extensions info propagation Hi ML2er and others, I'm considering discussions around ML2 for the summit. Unfortunatly I won't attend the summit, so I'll try to participate through the mailing list and etherpads. I'm especially interested in extension support by Mechanism Driver[1] and Modular agent[2]. During the Juno cycle I'll work on the capacity to propagate IPVPN informations (route-target) down to the agent, so that the agent can manage MPLS encapsulation. I think that the easiest way to do that is to enhance get_device_details() RPC message to add network extension informations of the concerned port in the dict sent. Moreover I think this approach could be generalized, and get_device_details() in the agent should return serialized information of a port with every extension informations (security_group, port_binding...). When the core datamodel or the extension datamodel would be modified, this would result in a port_update() with the updated serialization of the datamodel. This way, we could get rid of security-group and l2pop RPC. Modular agent wouldn't need to deal with one driver by extension which need to register its RPC callbacks. Those informations should also be stored in ML2 driver context. When a port is created by ML2 plugin, it calls super() for creating core datamodel, which will return a dict without extension informations, because extension informations in the Rest call has not been processed yet. But once the plugin call its core extension, it should call MD registered extensions as proposed by nader here [4] and then call make_port_dict(with extension), or an equivalent serialization function, to create the driver context. this seralization function would be used by get_device_details() RPC callbacks too. Regards, Mathieu [1]https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support [2]https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent [3]http://summit.openstack.org/cfp/details/240 [4]https://review.openstack.org/#/c/89211/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] powervc-driver project in Stackforge
Hi, Just a heads up that we have upstreamed the powervc-driver project to Stackforge. PowerVC is the strategic product for IBM Power virtualization management. And powervc-driver project contains a set of OpenStack drivers (nova, cinder and neutron) and utilities for the manage-to Power via PowerVC. With this project, community OpenStack users can build a mixed cloud environment with both x86 and Power servers. More documentation will be provided in the launchpad and the initial CI support for the powervc-driver project will be launched within next 1-2 weeks. Comments/feedback are welcome. PowerVC driver repository stackforge: https://github.com/stackforge/powervc-driver PowerVC driver project on launchpad: https://launchpad.net/powervc-driver -- Regards, Xiandong Meng mengxiand...@gmail.com mengxiand...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Proposal: add local hacking for oslo-incubator
On 05/06/2014 01:13 PM, Joe Gordon wrote:
On Mon, May 5, 2014 at 10:56 AM, Ben Nemec openst...@nemebean.com
mailto:openst...@nemebean.com wrote:
On 05/05/2014 10:02 AM, ChangBo Guo wrote:
Hi Stackers,
I find some common code style would be avoided while I'm
reviewing code
,so think these check would
be nice to move into local hacking. The local hacking can ease
reviewer
burden.
The idea from keystone blueprint [1].
Hacking is a great start at automating checks for common style
issues.
There are still lots of things that it is not checking for that it
probably should. The local hacking ease reviewer burden . This
is the
list of from [1][2] that would be nice to move into an automated
check:
- use import style 'from openstack.common.* import' not use 'import
openstack.common.*'
This is the only one that I think belongs in Oslo. The others are
all generally applicable, but the other projects aren't going to
want to enforce the import style since it's only to make Oslo syncs
work right.
I agree this belongs in oslo-incubator only as well. But I am still
confused as to why this is needed. It sounds like this is a workaround
for a bug in the sync script.
I feel like there was a reason we couldn't make both import styles work
properly, but my memory is fuzzy. Maybe ChangBo can comment.
- assertIsNone should be used when using None with assertEqual
- _() should not be used in debug log statements
-do not use 'assertTrue(isinstance(a, b)) sentence'
-do not use 'assertEqual(type(A), B) sentence'
The _() one in particular I think we'll want as we make the logging
changes. Some additional checks to make sure the the correct _
function is used with the correct logging function would be good too
(for example, LOG.warning(_LE('foo')) should fail pep8).
But again, that belongs in hacking proper, not an Oslo module.
Yup, this belongs in hacking although this gets a little tricky to do
right, as we don't want false positives
http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst#n42
We have to make sure that '_' is what we think it is and that 'LOG' is
the logger, just checking for 'LOG' isn't very robust.
Patches welcome! http://git.openstack.org/cgit/openstack-dev/hacking
The assert ones do seem to fit the best practices as I understand
them, but I suspect there's going to be quite a bit of work to get
projects compliant.
Although some projects already have the assert ones, I don't see a lot
of value in them.
I would probably give priority to the assertTrue(isinstance...) one
because I believe assertTrue yields a less useful error message when it
fails. The others are mostly style issues I don't feel that strongly
about, although I could see some value in them just to avoid having
someone come along and leave a -1, use assertIsNone comment (I try not
to -1 for that alone, but I won't promise that I never have, and I'm
pretty sure other people do).
[1]
https://blueprints.launchpad.__net/keystone/+spec/more-code-__style-automation
https://blueprints.launchpad.net/keystone/+spec/more-code-style-automation
[2]
https://github.com/openstack/__nova/blob/master/nova/hacking/__checks.py
https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
I just registered a blueprint for this in [3] and submit first
patch in [4].
[3]
https://blueprints.launchpad.__net/oslo/+spec/oslo-local-__hacking
https://blueprints.launchpad.net/oslo/+spec/oslo-local-hacking
[4] https://review.openstack.org/#__/c/87832/
https://review.openstack.org/#/c/87832/
https://github.com/openstack/__nova/blob/master/nova/hacking/__checks.py
https://github.com/openstack/nova/blob/master/nova/hacking/checks.py
Should we add local hacking for oslo-incubator ? If yes, what's the
other check will be added ?
Your comment is appreciated :-)
--
ChangBo Guo(gcb)
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Re: [openstack-dev] powervc-driver project in Stackforge
On 05/08/2014 11:14 AM, Xiandong Meng wrote: Hi, Just a heads up that we have upstreamed the powervc-driver project to Stackforge. PowerVC is the strategic product for IBM Power virtualization management. And powervc-driver project contains a set of OpenStack drivers (nova, cinder and neutron) and utilities for the manage-to Power via PowerVC. With this project, community OpenStack users can build a mixed cloud environment with both x86 and Power servers. More documentation will be provided in the launchpad and the initial CI support for the powervc-driver project will be launched within next 1-2 weeks. Comments/feedback are welcome. PowerVC driver repository stackforge: https://github.com/stackforge/powervc-driver PowerVC driver project on launchpad: https://launchpad.net/powervc-driver This repository does not include even a README at this point. Starting with a README would be really nice. Also it looks like it's not actually Open Source - https://github.com/stackforge/powervc-driver/blob/master/nova-powervc/powervc/utils.py#L1-L9 (that's just an example, it's littered throughout the code). Which I assume is actually a violation of being on stackforge. So that needs to be fixed ASAP or we should delete it. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Special session on heat-translator project at Atlanta summit
Hi all, we have put up an etherpad [1] with a draft agenda for the session on Heat Translator next week. It is an outline of things that we want to talk about to give an overview and some background on the project, as well as a collection of things that came to our minds. It is important to say that the project is really young and still taking shape. Compared to other design design sessions where the issues being discussed are much more concrete, expect this session to be of a broader scope. It is really meant to show what we have so far, what our vision is, but then also to shape the project so it best benefits the OpenStack Orchestration program. Therefore, we are really interested in everyone's input for that session so that we can make best use of everyone's time there. That said, feel free to add your input to the etherpad. We will then consolidate it in time for the session next Thursday. [1] https://etherpad.openstack.org/p/juno-design-summit-heat-translator Regards, Thomas From: Thomas Spatzier/Germany/IBM@IBMDE To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 06/05/2014 10:47 Subject: Re: [openstack-dev] [Heat] Special session on heat- translator project at Atlanta summit Hi Dimitri, I think we will cover the relation to the overall Heat vision during that session. That would actually be very good use of time during that session, because we want to shape the project in a way that it adds benefit to the overall orchestration project. From our perspective, TOSCA is one driving factor, but it's not a pure TOSCA discussion. For example, during last year's summit in Portland we came up with this vision architecture chart in [1], and heat-translator could be a starting point for this pluggable formats layer. Maybe we will also incubate some features in heat-translator and later move them more tightly into Heat ... all points to be sorted out and to develop over time. My 2 cents. Thomas Dimitri Mazmanov dimitri.mazma...@ericsson.com wrote on 06/05/2014 10:16:44: From: Dimitri Mazmanov dimitri.mazma...@ericsson.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 06/05/2014 10:18 Subject: Re: [openstack-dev] [Heat] Special session on heat- translator project at Atlanta summit Great effort! One question, will this session relate to the overall Heat vision [1] (Model Interpreters, API Relay, etc)? - Dimitri [1] https://wiki.openstack.org/wiki/Heat/Vision On 05/05/14 19:21, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: Hi all, I mentioned in some earlier mail that we have started to implement a TOSCA YAML to HOT translator on stackforge as project heat-translator. We have been lucky to get a session allocated in the context of the Open source @ OpenStack program for the Atlanta summit, so I wanted to share this with the Heat community to hopefully attract some interested people. Here is the session link: http://openstacksummitmay2014atlanta.sched.org/event/ c94698b4ea2287eccff8fb743a358d8c#.U2e-zl6cuVg While there is some focus on TOSCA, the goal of discussions would also be to find a reasonable design for sitting such a translation layer on-top of Heat, but also identify the relations and benefits for other projects, e.g. how Murano use cases that include workflows for templates (which is part of TOSCA) could be addressed long term. So we hope to see a lot of interested folks there! Regards, Thomas PS: Here is a more detailed description of the session that we submitted: 1) Project Name: heat-translator 2) Describe your project, including links to relevent sites, repositories, bug trackers and documentation: We have recently started a stackforge project [1] with the goal to enable the deployment of templates defined in standard format such as OASIS TOSCA on top of OpenStack Heat. The Heat community has been implementing a native template format 'HOT' (Heat Orchestration Templates) during the Havana and Icehouse cycles, but it is recognized that support for other standard formats that are sufficiently aligned with HOT are also desirable to be supported. Therefore, the goal of the heat-translator project is to enable such support by translating such formats into Heat's native format and thereby enable a deployment on Heat. Current focus is on OASIS TOSCA. In fact, the OASIS TOSCA TC is currently working on a TOSCA Simple Profile in YAML [2] which has been greatly inspired by discussions with the Heat team, to help getting TOSCA adoption in the community. The TOSCA TC and the Heat team have also be in close discussion to keep HOT and TOSCA YAML aligned. Thus, the first goal of heat-translator will be to enable deployment of TOSCA YAML templates thru Heat. Development had been started in a separate public github repository
Re: [openstack-dev] powervc-driver project in Stackforge
Copyright is fine and appropriate: (C) Copyright IBM Corp. 2013 All Rights Reserved However the OCO declaration is not compatible with Open Source. And it also should do the copyright like is done in other projects, a comment header not in a variable. -Sean On 05/08/2014 11:55 AM, Xiandong Meng wrote: We will fix it by adding in the Apache License file and the readme file to the repo. BTW, i feel it is ok to retain copyright in the source code. On Thu, May 8, 2014 at 10:32 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 05/08/2014 11:14 AM, Xiandong Meng wrote: Hi, Just a heads up that we have upstreamed the powervc-driver project to Stackforge. PowerVC is the strategic product for IBM Power virtualization management. And powervc-driver project contains a set of OpenStack drivers (nova, cinder and neutron) and utilities for the manage-to Power via PowerVC. With this project, community OpenStack users can build a mixed cloud environment with both x86 and Power servers. More documentation will be provided in the launchpad and the initial CI support for the powervc-driver project will be launched within next 1-2 weeks. Comments/feedback are welcome. PowerVC driver repository stackforge: https://github.com/stackforge/powervc-driver PowerVC driver project on launchpad: https://launchpad.net/powervc-driver This repository does not include even a README at this point. Starting with a README would be really nice. Also it looks like it's not actually Open Source - https://github.com/stackforge/powervc-driver/blob/master/nova-powervc/powervc/utils.py#L1-L9 (that's just an example, it's littered throughout the code). Which I assume is actually a violation of being on stackforge. So that needs to be fixed ASAP or we should delete it. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote: There are networking talks in the general session in the afternoon on Thursday including the talk on Network Policies from 1:30 to 2:10pm. Anything after that is ok with me. How does 2:30PM on Thursday sound to everyone? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
+1 On Thu, May 8, 2014 at 9:22 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote: There are networking talks in the general session in the afternoon on Thursday including the talk on Network Policies from 1:30 to 2:10pm. Anything after that is ok with me. How does 2:30PM on Thursday sound to everyone? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] [Doc] [ceilometer] [cinder] [glance] [heat] [horizon] [keystone] [neutron] [nova] [swift] [trove] Atlanta Summit – Discuss docs process and tool improvements
On Wed, May 7, 2014 at 1:43 PM, Roger Luethi r...@patchworkscience.orgwrote: On Wed, 07 May 2014 09:16:48 -0700, Anne Gentle wrote: Why not? The responses to my recent survey about doc contributions indicate that the top barriers to docs’ contributions are: - Tools: DocBook and WADL are difficult DocBook may be a pain to set up, but editing DocBook documents is hardly more difficult than Markdown, RST or any other solution will be by the time you have added all the features you want to have. Yep, I realize DocBook fulfills many if not all of the requirements, plus it's what's used within much of RedHat and we have a translation toolchain built for it. These are compelling except for the survey results indicating it's a barrier. I'd like to stick to discussion of the requirements. I just named two possible requirements, should those be included as well? Thanks for the input Roger, you're exactly who we're trying to reach out to for docs, and your input is super valuable. Anne Formatting docs is hard because the style guides demand that numerous rules be considered. Ditching DocBook won't change that. - Subject-matter expertise: People do not have test environments and they feel that they don't know enough to contribute. Also, 70% of the respondents to the survey work on or consume OpenStack fewer than 10 hours a week. The people who are qualified to contribute to the docs are usually not non-technical people, but they can't spend hours setting up an environment just to work on docs. IMHO good documentation (or scripts, or VM downloads) that make it easy to create a complete, working environment for testing and building documentation would go a long way towards making contributions easier. Roger ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Team meeting this week
Hi, so we should have a meeting today week at 21:00 UTC. The agenda is at https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting Cheers, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
On May 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). Option 1 or 2 might be the ultimate goal. Regards, -Sam. From: Clark, Robert Graham [mailto:robert.cl...@hp.comhttp://hp.com] Sent: Thursday, May 08, 2014 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There’s already a standard for a nice way to bundle those two elements together, it’s described in PKCS#12 and you’ve likely come across it in the form of ‘.pfx’ files. I’d suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. From: John Wood [mailto:john.w...@rackspace.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions);os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates We intend to discuss this feature in Atlanta to enable coding in earnest for Juno. The Container resource is intended to capture/store the final certificate details. Thanks, John From: Samuel Bercovici [samu...@radware.commailto:samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev]
Re: [openstack-dev] [Fuel-dev] [Fuel][RabbitMQ] nova-compute stuck for a while (AMQP)
Bogdan, thank you. On Thu, May 8, 2014 at 6:22 AM, Bogdan Dobrelya bdobre...@mirantis.comwrote: On 05/06/2014 10:42 PM, Roman Sokolkov wrote: Hello, fuelers. I'm using Fuel 4.1A + Havana in HA mode. I permanently observe (on other deployments also) issue with stuck nova-compute service. But i think problem is more fundamental and relates to HA RabbitMQ and OpenStack AMQP driver implementation. Symptoms: * Random nova-compute from time to time marked as XXX for a while. * I see that service itself works properly. In logs i see that it sends status updates to conductor. But actually nothing is sent. * netstat shows that all connections to/from rabbit ESTABLISHED * rabbitmqctl shows that compute.node-x queue synced to all slaves. * nothing has been broken before, i mean rabbitmq cluster, etc. Axe style solution: * /etc/init.d/openstack-nova-compute restart So here i've found a lot of interesting stuff (and solutions): https://bugs.launchpad.net/oslo.messaging/+bug/856764 My questions are: * Are there any thoughts particular for Fuel to solve/workaround this issue? * Any fast solution for this in 4.1? Like adjust TCP keep-alive timeouts? I submitted an issue for Fuel https://bugs.launchpad.net/fuel/+bug/1317488 and assigned it to Fuel hardening team. Feel free to update it as appropriate. -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com mailto:rsokol...@mirantis.com -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
On May 8, 2014, at 8:01 AM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi Adam, My comments inline: 1. We shouldn't be looking at the current model and deciding which object is the root object, or what object to rename as a loadbalancer... That's totally backwards! *We don't define which object is named the loadbalancer by looking for the root object -- we define which object is the root by looking for the object named loadbalancer.* I had hoped that was clear from the JSON examples in our API proposal, but I think maybe there was too much focus on the object model chart, where this isn't nearly as clearly communicated. 2. As I believe I have also said before, if I'm using X as a Service then I expect to get back an object of type X. I would be very frustrated/confused if, as a user, LBaaS returned me an object of type VIP when I POST a Create for my new load balancer. On this last point, I feel like I've said this enough times that I'm beating a dead horse... I think we definitely should be looking at existing API/BBG proposal for the root object. The question about whether we need additional 'Loadbalancer' resource or not is not a question about terminology, so (2) is not a valid argument. It's pretty awkward to have a REST api that doesn't have a resource representation of the object its supposed to be creating and handing out. It's really awkward to identify a loadbalancer by vip id. Thats like trying going to a car dealership API and only being able to look up a car by its parking spot ID. Do you believe Neutron/Lbaas is actually LoadBalancerVip as a Service which would entirely explain the disconnect we are having with you. What really matters in answering the question about 'loadbalancer' resource is do we need multiple L2 ports per single loadbalancer. If we do - that could be a justification to add it. Right now the common perception is that this is not needed and hence, 'loadbalancer' is not required in the API or obj model. Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain further. Thanks Carlos. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Release 0.5
I'd like to announce release of Murano 0.5 - Application Catalog for OpenStack. This release includes 28 implemented blueprints and 76 bug fixes. Release notes and tarballs can be found here: https://launchpad.net/murano/0.x/0.5 https://wiki.openstack.org/wiki/Murano/ReleaseNotes_v0.5 Here is the demo: https://drive.google.com/a/mirantis.com/file/d/0B3F5XCmYtnRdcnRUaXg0Q3BUcUU/edit More demos to come on the next week :) -- Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
Have any of you javascript gurus respun this for the new gerrit version?
Or can this now be done on the backend somehow?
On Tue, Mar 04, at 4:00 pm, Carl Baldwin wrote:
Nachi,
Great! I'd been meaning to do something like this. I took yours and
tweaked it a bit to highlight failed Jenkins builds in red and grey
other Jenkins messages. Human reviews are left in blue.
javascript:(function(){
list = document.querySelectorAll('td.GJEA35ODGC');
for(i in list) {
title = list[i];
if(! title.innerHTML) { continue; }
text = title.nextSibling;
if (text.innerHTML.search('Build failed') 0) {
title.style.color='red'
} else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') = 0)
{
title.style.color='#66'
} else {
title.style.color='blue'
}
}
})()
Carl
On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
I wrote an bookmarklet for neutron gerrit review.
This bookmarklet make the comment title for 3rd party ci as gray.
javascript:(function(){list =
document.querySelectorAll('td.GJEA35ODGC'); for(i in
list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML
list[i].innerHTML.search('CI|Ryu|Testing|Mine')
0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
enjoy :)
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] gpd: a git-push-based dev workflow for OpenStack projects
Matt, Thanks for sharing this. Pretty cool! -Craig On Wed, May 7, 2014 at 11:13 AM, Lowery, Mathew mlow...@ebay.com wrote: I just wanted to share a project that I've been working on. It's a development workflow for OpenStack projects. I like to code in PyCharm and push my changes to a DevStack VM. I don't use Vagrant and I don't like manually scp'ing code. So I created git-push-devstack or gpd: https://github.com/mlowery/git-push-devstack After configuring your laptop (or wherever you code) and your DevStack VM, pushing your code from your laptop to your DevStack VM and restarting affected processes is as easy as: $ git commit $ git push test Code and doc are at the GitHub link. Feedback is welcome. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can manage their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place... German From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Thursday, May 08, 2014 9:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). Option 1 or 2 might be the ultimate goal. Regards, -Sam. From: Clark, Robert Graham [mailto:robert.cl...@hp.comhttp://hp.com] Sent: Thursday, May 08, 2014 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There's already a standard for a nice way to bundle those two elements together, it's described in PKCS#12 and you've likely come across it in the form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure. This such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate. Why the need for that complexity? The X509s are public by nature and don't need to be stored in Barbican so there isn't really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea. -Sam. From: John Wood [mailto:john.w...@rackspace.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions);os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN Hello Samuel, Just noting that the link below shows current-state Barbican. We are in the process of
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
Hi Sean, Perfect (I assume it is local time, i.e. 2:30pm EDT). And I also assume this will be at the Neutron pod? - Stephen On Thu, May 8, 2014 at 9:22 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote: There are networking talks in the general session in the afternoon on Thursday including the talk on Network Policies from 1:30 to 2:10pm. Anything after that is ok with me. How does 2:30PM on Thursday sound to everyone? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] [MONaaS] Monitoring as a Service
Hello everyone! I have participated to today's Ceilometer meeting. You can read it here (2014-05-08): http://eavesdrop.openstack.org/meetings/ceilometer/2014/ As proposed by eglynn, MONaaS will become a recurring topic in Ceilometer's meetings. It was proposed to start adding MONaaS as a recurring topic starting the week after the summit, that would be May 22. Until then, I suggest you try contributing to the Etherpad. The first problem that we have to solve is to define the project's scope. In order to correctly answer to this question, we need a detailed list of possible use cases. Don't hesitate to work on this on the Etherpad before May 22. A sub-team could be formed to work on the blueprint, this team would have regular MONaaS-specific meeting. I will be proposing this on May 22. To avoid all confusion with Metal as a Service, I have renamed pages to MONaaS. New wiki page: https://wiki.openstack.org/wiki/MONaaS New Etherpad: https://etherpad.openstack.org/p/MONaaS Best regards, Alexandre Viau ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness
James, On May 5, 2014, at 5:49 PM, James Polley j...@jamezpolley.commailto:j...@jamezpolley.com wrote: To revive this thread... I'd really like to see us trying out alternate meeting times for a while. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Looking at the iCal feed it looks like it's actually taken by Solum. No, we (Solum Team) meet at 1600 UTC and 2200 UTC alternating Tuesdays in #openstack-meeting-alt. We are not meeting next week by IRC because of the Summit. We are all attending and will meet in person. If the iCal feed is not right, do you know how I can correct it? Adrian But in any case: On Thu, Mar 20, 2014 at 11:17 AM, Robert Collins robe...@robertcollins.netmailto:robe...@robertcollins.net wrote: I think we need a timezone to cover the current impossible regions: - Australia - China / Japan - India 1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. Personally that's worse for me than 1700UTC. I'd prefer to move it significantly later than 1900UTC, especially if we want a time that's civilized (or at least, achievable) in India. 0700UTC seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm New Delhi. It's not friendly to the US (midnight SF, 3am NYC). but it should work well for Europe - 8am London, and it gets later in the day as you go east. What would we need to do to try this time out next week? On Thu, Mar 20, 2014 at 8:03 PM, j...@ioctl.orgmailto:j...@ioctl.org wrote: On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote: From: James Slagle [mailto:james.sla...@gmail.commailto:james.sla...@gmail.com] Sent: 18 March 2014 19:58 Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness Our current meeting time is Tuesdays at 19:00 UTC. I think this works ok for most folks in and around North America. It was proposed during today's meeting to see if there is interest is an alternating meeting time every other week so that we can be a bit more friendly to those folks that currently can't attend. If that interests you, speak up :). Speaking up! :D Also interested. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Relatively speaking, that's actually sociable. -- Update your address books: j...@ioctl.orgmailto:j...@ioctl.org http://ioctl.org/jan/ perl -e 's?ck?t??print:perl==pants if $_=Just Another Perl Hacker\n' ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
Hi Carlos, Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain further. No, I mean that loadbalancer instance is needed if we need several *different* L2 endpoints for several front ends. That's basically 'virtual appliance' functionality that we've discussed on today's meeting. Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Database migrations meeting at summit
Several developers are working on different aspects of Neutron DB migration. I thought it would be good to have a meeting at the summit where we can discuss the issues and come closer to converging on a solution. I was thinking maybe a time on Tuesday or Thursday afternoon would work. I have created an etherpad [1] where I have tried to accumulate the emails, bugs, bps and code proposals. If you are interested in meeting please add your name to the etherpad. Also please add any missing notes/references to the etherpad. [1] https://etherpad.openstack.org/p/neutron-db-migrations ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Carlos, +1 My impression of barbican is that they indeed see themselves as sending updates to the LBs/VPN/X - but I am not too excited about that. Any marginally sophisticated user wants to control when we burst out new certificates so they can tie that to their maintenance window (in case client certs need to be updated). German From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Thursday, May 08, 2014 11:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 8, 2014, at 1:41 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can manage their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place... Ok but in our implementation we may decide to duplicate the X509s in our database so that we can search and do searches on them with out going over a separate API service. So we don't mind storing them in both locations. We just worry about case were people update their (x509,priv_key) via barbican but existing loadbalancers in neutron would then be unaware of the new updated cert. This would seem to imply that barbican would need to trigger an update on neutron/lbaas. :( German From: Carlos Garza [mailto:carlos.ga...@rackspace.comhttp://rackspace.com] Sent: Thursday, May 08, 2014 9:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Please note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge. This calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases. So it here are the options as far as I have seen so far. 1. Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement 2. Using Heat as a centralized service 3. Implementing such service in Neutron 4. LBaaS private implementation BTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. I think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2). Option 1 or 2 might be the ultimate goal. Regards, -Sam. From: Clark, Robert Graham [mailto:robert.cl...@hp.comhttp://hp.com] Sent: Thursday, May 08, 2014 12:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN The certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys. There's already a standard for a nice way to bundle those two elements together, it's described in PKCS#12 and you've likely come across it in the form of '.pfx' files. I'd suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container) -Rob From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: 08 May 2014 04:30 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi John, If the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate? The Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in
[openstack-dev] Informal meeting before SR-IOV summit presentation
Hi, It would be nice to have an informal discussion / unconference session before the actual summit session on SR-IOV. During the previous IRC meeting, we were really close to identifying the different use cases. There was a dangling discussion on introducing another level of indirection between the vnic_types exposed via the nova boot API and how it would be represented internally. It would be ideal to have these 2 discussions converged before the summit session. If you are interested in attending please reply and also add a date and time that would work for you. Thanks, Sandhya ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Informal meeting before SR-IOV summit presentation
It would be nice to have an informal discussion / unconference session before the actual summit session on SR-IOV. During the previous IRC meeting, we were really close to identifying the different use cases. There was a dangling discussion on introducing another level of indirection between the vnic_types exposed via the nova boot API and how it would be represented internally. It would be ideal to have these 2 discussions converged before the summit session. What would be the purpose of doing that before the session? IMHO, a large part of being able to solve this problem is getting everyone up to speed on what this means, what the caveats are, and what we're trying to solve. If we do some of that outside the scope of the larger audience, I expect we'll get less interaction (or end up covering it again) in the session. That said, if there's something I'm missing that needs to be resolved ahead of time, then that's fine, but I expect the best plan is to just keep the discussion to the session. Afterwards, additional things can be discussed in a one-off manner, but getting everyone on the same page is largely the point of having a session in the first place IMHO. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Informal meeting before SR-IOV summit presentation
- Original Message - It would be nice to have an informal discussion / unconference session before the actual summit session on SR-IOV. During the previous IRC meeting, we were really close to identifying the different use cases. There was a dangling discussion on introducing another level of indirection between the vnic_types exposed via the nova boot API and how it would be represented internally. It would be ideal to have these 2 discussions converged before the summit session. What would be the purpose of doing that before the session? IMHO, a large part of being able to solve this problem is getting everyone up to speed on what this means, what the caveats are, and what we're trying to solve. If we do some of that outside the scope of the larger audience, I expect we'll get less interaction (or end up covering it again) in the session. That said, if there's something I'm missing that needs to be resolved ahead of time, then that's fine, but I expect the best plan is to just keep the discussion to the session. Afterwards, additional things can be discussed in a one-off manner, but getting everyone on the same page is largely the point of having a session in the first place IMHO. Right, in spite of my previous response...looking at the etherpad there is nothing there to frame the discussion at the moment: https://etherpad.openstack.org/p/juno-nova-sriov-support I think populating this should be a priority rather than organizing another session/meeting? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Mid-Cycle Meeting Location
Hi everyone: I've settled on a date, location, and agenda for the Neutron mid-cycle Meeting. The logistical information is at the etherpad referenced below [1]. The tl;dr for those curious: Date: July 9-11 Location: Cisco office in Bloomington, MN Agenda: nova-network parity sprint and completion of tasks I've setup a hotel block of 15 rooms at this point, please add yourself to the list of attendees so I can track the room block reservation. The hotel is within walking distance of the Cisco office. There are lots of other hotels all very close as well. Thanks, looking forward to seeing everyone next week as well as at the Mid-Cycle Meeting! Kyle [1] https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QA] Partial fix for unittest memory consumption
On Thu, May 8, 2014 at 7:30 AM, Salvatore Orlando sorla...@nicira.comwrote: Thanks Maru, I've added this patch to my list of patches to review. I've also targeted the bug of J-1 because I love being a pedant bookkeeper. Salvatore On 8 May 2014 11:41, Maru Newby ma...@redhat.com wrote: Memory usage due to plugin+mock leakage is addressed by the following patch: https://review.openstack.org/#/c/92793/ I'm seeing residual (post-test) memory usage decrease from ~4.5gb to ~1.3gb with 12 concurrent test runners. Of the 1.3gb, sqlalchemy is taking the lion share at ~500mb, so that will be my next target. Awesome! Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Summit etherpads
Hi everyone: I've noticed that not all Neutron sessions [1] have etherpad's linked to them yet. If you're running a session, please make sure you get your etherpad setup this week yet. You'll only have 40 minutes for your session (or less if you're in a combined session), so organizing your thoughts before hand is critical to a successful session. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Neutron ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com To: openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: All, TL;DR: novaclient should be able to use the common transport/auth layers of keystoneclient. If it does there are going to be functions like client.authenticate() that won't operate the same way when a session object is passed. For most users who just use the CRUD operations there will be no difference. I'm hoping that at least some of the nova community has heard of the push for using keystoneclient's Session object across all the clients. For those unaware keystoneclient.session.Session is a common transport and authentication layer to remove the need for each python-*client having there own authentication configuration and disparate transport options. It offers: - a single place for updates to transport (eg fixing TLS or other transport issues in one place) - a way for all clients to immediately support the full range of keystone's authentication including v3 auth, SAML, kerberos etc - a common place to handle version discovery such that we support multiple version endpoints from the same service catalog endpoint. For information of how to interact with a session you can see: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ This mentions the code is uncommitted however has since been committed with a few small details around parameter names being changed. The theory remains the same. To integrate this into novaclient means that if a session= object is passed then the standard HTTPClient code will be ignored in favour of using what was passed. This means that there are changes in the API of the client. In keystoneclient we have take the opinion that by passing a session object then you opt-in to the newer API and therefore accept that some functions are no longer available. For example client.authenticate() is no longer allowed because authentication is not the client's responsibility. It will have no impact on the standard novaclient CRUD operations and so be un-noticed by the vast majority of users. The review showing these changes is here: https://review.openstack.org/#/c/85920 To enable this there are a series of test changes to mock client requests at the HTTP layer rather than in the client. This means that we can test that all client operations against the new and old client construction methods and ensure the same requests are being sent. The foundation of this to turn tests into fixtures can be found by following: https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing IMO making these tests into fixtures is a good idea anyway, however I am only pursuing it so that we can transition to using a common Session. Regarding dependencies, novaclient will need a test-requirements.txt on keystoneclient so that it can construct Session objects to test with but it should not need a requirements.txt as the session object is constructed by the user of the client (eg openstackclient, horizon etc). Can we make novaclient use keystoneclient's session by default? And just add this to requirements. ++ Once it's supported, I would think that someone wanting to use novaclient _without_ keystoneclient should be seen as the exception case and not the normal case. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url=' http://keystone/v3', username='user', password='pass', ...) session = keystoneclient.session.Session(auth=auth, cacerts='path/to') glance = glanceclient.v1.Client(session) keystone = keystoneclient.v3.Client(session) nova = novaclient.v1.Client(session) This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said that the novaclient CLI is a consumer of the novaclient library and so there is going to be a dependence there eventually. We can rip out the existing
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
Is there a bp to coordinate work on aligning all clients to the Session object? Having a consistent implementation would make users and developers life so much easier – not to mention QA :) andrea From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 08 May 2014 21:55 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com mailto:jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: All, TL;DR: novaclient should be able to use the common transport/auth layers of keystoneclient. If it does there are going to be functions like client.authenticate() that won't operate the same way when a session object is passed. For most users who just use the CRUD operations there will be no difference. I'm hoping that at least some of the nova community has heard of the push for using keystoneclient's Session object across all the clients. For those unaware keystoneclient.session.Session is a common transport and authentication layer to remove the need for each python-*client having there own authentication configuration and disparate transport options. It offers: - a single place for updates to transport (eg fixing TLS or other transport issues in one place) - a way for all clients to immediately support the full range of keystone's authentication including v3 auth, SAML, kerberos etc - a common place to handle version discovery such that we support multiple version endpoints from the same service catalog endpoint. For information of how to interact with a session you can see: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ This mentions the code is uncommitted however has since been committed with a few small details around parameter names being changed. The theory remains the same. To integrate this into novaclient means that if a session= object is passed then the standard HTTPClient code will be ignored in favour of using what was passed. This means that there are changes in the API of the client. In keystoneclient we have take the opinion that by passing a session object then you opt-in to the newer API and therefore accept that some functions are no longer available. For example client.authenticate() is no longer allowed because authentication is not the client's responsibility. It will have no impact on the standard novaclient CRUD operations and so be un-noticed by the vast majority of users. The review showing these changes is here: https://review.openstack.org/#/c/85920 To enable this there are a series of test changes to mock client requests at the HTTP layer rather than in the client. This means that we can test that all client operations against the new and old client construction methods and ensure the same requests are being sent. The foundation of this to turn tests into fixtures can be found by following: https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing IMO making these tests into fixtures is a good idea anyway, however I am only pursuing it so that we can transition to using a common Session. Regarding dependencies, novaclient will need a test-requirements.txt on keystoneclient so that it can construct Session objects to test with but it should not need a requirements.txt as the session object is constructed by the user of the client (eg openstackclient, horizon etc). Can we make novaclient use keystoneclient's session by default? And just add this to requirements. ++ Once it's supported, I would think that someone wanting to use novaclient _without_ keystoneclient should be seen as the exception case and not the normal case. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url='http://keystone/v3', username='user', password='pass', ...) session =
[openstack-dev] [TripleO] headsup: passing additional parameters to heat.
This is a small PSA - with the addition of heat environment file support in devtest_overcloud users can now pass any parameter they want in (if its not already being set by devtest_overcloud.sh). So: - there is no need to add corner case parameters to devtest_overcloud.sh unless they require derivation logic to determine their value - if we need to set an option to work in test VMs where the production value is different, we should guard it somehow - e.g. by seeing if we're using VMs, or if the option is already present in the environment file honour that value. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On May 6, 2014, at 15:22, Jamie Lennox jamielen...@redhat.com wrote: If there are concerns with this process please respond here and/or on the review. This sounds like it would be a fix for a bug affecting clients that I was looking at recently: https://bugs.launchpad.net/python-novaclient/+bug/1154809 If so, maybe we can add a note in the bug linking to this work. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Forbidden: It is not allowed to create an interface on external network
Hi, This is a development list, and your question sounds more usage-related. You'll probably have better luck asking on the users list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Thanks. -Ben On 05/08/2014 09:04 AM, Taurus H wrote: Hi,all! I encountered the following error when creating an instance of this time: *Forbidden: It is not allowed to create an interface on external network(HTTP 403)* In normal use this afternoon, I just re-create the external network admin, and demo-related networks. I really can not find the root cause of the problem, how to solve this problem? Thanks！ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TXT/TCP
Hi Robert, I work with Tom Norton and Tim Reddin in the new OpenStack Services group. I used to be a member of the Neutron team, and before that the Cinder team. In fact, my office is very close to Stephen Mulcahy. I am working on an Intel PoC, and they want to validate something called TXT/TCP. I'm told you have done some work on this. Would it be possible to have a quick chat about it and what it means? We may need tO enable it on some compute hosts in the public cloud. What time would be good for you? I'm GMT+1 at the moment. I will also be at OpenStack, if you had some time to spare there. - Der -- Dermot Tynan Cloud Consulting Principal OpenStack Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA] Open topics for summit in Atlanta
I started an etherpad for people to put down QA topics we could discuss during the summit at lunch or over a beer https://etherpad.openstack.org/p/juno-summit-open-topics Feel free to add anything that needs some good face to face brainstorming :) andrea -- Andrea Frittoli QA Tech Lead HP Cloud ☁ PC Phone: +445601090317 smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
Henry,
I haven't gotten further than noticing that mine no longer works.
It'd be great to put this in to gerrit somehow. It was useful.
Carl
On Thu, May 8, 2014 at 12:29 PM, Henry Gessau ges...@cisco.com wrote:
Have any of you javascript gurus respun this for the new gerrit version?
Or can this now be done on the backend somehow?
On Tue, Mar 04, at 4:00 pm, Carl Baldwin wrote:
Nachi,
Great! I'd been meaning to do something like this. I took yours and
tweaked it a bit to highlight failed Jenkins builds in red and grey
other Jenkins messages. Human reviews are left in blue.
javascript:(function(){
list = document.querySelectorAll('td.GJEA35ODGC');
for(i in list) {
title = list[i];
if(! title.innerHTML) { continue; }
text = title.nextSibling;
if (text.innerHTML.search('Build failed') 0) {
title.style.color='red'
} else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') =
0) {
title.style.color='#66'
} else {
title.style.color='blue'
}
}
})()
Carl
On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno na...@ntti3.com wrote:
Hi folks
I wrote an bookmarklet for neutron gerrit review.
This bookmarklet make the comment title for 3rd party ci as gray.
javascript:(function(){list =
document.querySelectorAll('td.GJEA35ODGC'); for(i in
list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML
list[i].innerHTML.search('CI|Ryu|Testing|Mine')
0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
enjoy :)
Nachi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Informal meeting before SR-IOV summit presentation
On Thu, May 08, 2014 at 08:40:01PM +, Robert Li (baoli) wrote: On 5/8/14, 4:33 PM, Steve Gordon sgor...@redhat.com wrote: snip FWIW, it is nice to keep the author of a particular indent level in the message /snip Dan Smith d...@danplanet.com wrote: What would be the purpose of doing that before the session? IMHO, a large part of being able to solve this problem is getting everyone up to speed on what this means, what the caveats are, and what we're trying to solve. If we do some of that outside the scope of the larger audience, I expect we'll get less interaction (or end up covering it again) in the session. That said, if there's something I'm missing that needs to be resolved ahead of time, then that's fine, but I expect the best plan is to just keep the discussion to the session. Afterwards, additional things can be discussed in a one-off manner, but getting everyone on the same page is largely the point of having a session in the first place IMHO. Right, in spite of my previous response...looking at the etherpad there is nothing there to frame the discussion at the moment: https://etherpad.openstack.org/p/juno-nova-sriov-support I think populating this should be a priority rather than organizing another session/meeting? Steve This is the one that Irena created: https://etherpad.openstack.org/p/pci_passthrough_cross_project Since the juno etherpad now contains the contents of the other, it seems that someone has cut and pasted. Nice. I think we can frame the discussion topics a little more clearly prior to the session though, so maybe a brief gathering for that purpose would be useful? One goal might be (as I think Dan alludes to) to provide some background and details so the participants of the session can engage in constructive dialogue. Dan provides a good outline: - Introduction - get up to speed What is the most effective way to outline for this particular audience so that they can participate? - What the caveats are. Are these our use cases? In a matter of speaking they are. One of them is also a question that needs answering. - What are we trying to solve? B. C. D. and E.? IMO, if there things we don't agree on at the moment, it is perfectly fine and probably preferable to present the problem and the alternate views (albeit objectively and evenly) in the session. Walking in with unresolved questions and walking out with the same questions is kind of a fail. Walking out with new unresolved questions is, IMO, fine... and probably likely ;) - We probably need to get to the what we are going to do for Juno question for this to be a good win. This could be satisfy use case X and Y and might be distressingly underwhelming or overambitious... this is something else that we might want to talk about as having some idea of what we want to accomplish vis-a-vis use cases and why, a prioritization, etc. is something that could be brought up in a session and discussed. In any case, it goes without saying that coming away from the session with something actionable and acceptable to the community is the ultimate objective. A really strong understanding of what is needed for acceptable nova blueprints for SRIOV (and why we haven't gotten there yet maybe) would be super! If getting together to further prepare for the session is something of interest, I am free on Monday starting late morning. The rest of my schedule is resolving, but I have firm commitments on mid-afternoon Tuesday and Wednesday and will not be available then. Cheers, Brent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Changing glances default policy on setting image public to admin only
Hi, The current default settings that glance ships with allows any tenant to upload an image and mark it as public for other tenants to use. I'd like to change the default (https://review.openstack.org/#/c/92739/) so that only a admin user can make an image public by default. Allowing any tenant to make an image public by default might allow a malicious tenant to trick other tenants into using their disk image which could do harm to unsuspecting tenants. Since this is a default setting impact I wanted to ping the mailing list to see if anyone had any concerns in changing the default. In addition, to this change in glance the tempest tests will also need to be updated as well because currently there are tests that have nonadmin tenants upload images. Best, Aaron ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Hierarchical administrative boundary [keystone]
Hi All, Below is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancyhttp://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9 session of Atlanta design summit. https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary Please take a look. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TXT/TCP
Hello Der! Shane and I work with Gang Wei who leads the Intel open source effort on TXT (tboot and OAT). Would like you to include us in your emails and be happy to help in any way we can. We are working with HP to jointly float a trusted bare metal blueprint for TripleO and would welcome more participants. BTW, Shane and I shall also be at the summit. Day-1 I shall mostly be at the security track talks. Regards Malini -Original Message- From: Tynan, Dermot [mailto:ty...@hp.com] Sent: Thursday, May 08, 2014 3:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] TXT/TCP Hi Robert, I work with Tom Norton and Tim Reddin in the new OpenStack Services group. I used to be a member of the Neutron team, and before that the Cinder team. In fact, my office is very close to Stephen Mulcahy. I am working on an Intel PoC, and they want to validate something called TXT/TCP. I'm told you have done some work on this. Would it be possible to have a quick chat about it and what it means? We may need tO enable it on some compute hosts in the public cloud. What time would be good for you? I'm GMT+1 at the moment. I will also be at OpenStack, if you had some time to spare there. - Der -- Dermot Tynan Cloud Consulting Principal OpenStack Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
Sounds good. Thanks. Mohammad On May 8, 2014, at 3:02 PM, Stephen Wong s3w...@midokura.com wrote: Hi Sean, Perfect (I assume it is local time, i.e. 2:30pm EDT). And I also assume this will be at the Neutron pod? - Stephen On Thu, May 8, 2014 at 9:22 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote: There are networking talks in the general session in the afternoon on Thursday including the talk on Network Policies from 1:30 to 2:10pm. Anything after that is ok with me. How does 2:30PM on Thursday sound to everyone? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing listopenstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Mid-Cycle Meeting Location
Kyle Mestery mest...@noironetworks.com wrote on 05/08/2014 04:45:43 PM: From: Kyle Mestery mest...@noironetworks.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/08/2014 04:46 PM Subject: [openstack-dev] [neutron] Mid-Cycle Meeting Location Hi everyone: I've settled on a date, location, and agenda for the Neutron mid-cycle Meeting. The logistical information is at the etherpad referenced below [1]. The tl;dr for those curious: Date: July 9-11 Location: Cisco office in Bloomington, MN Agenda: nova-network parity sprint and completion of tasks I've setup a hotel block of 15 rooms at this point, please add yourself to the list of attendees so I can track the room block reservation. The hotel is within walking distance of the Cisco office. There are lots of other hotels all very close as well. Thanks, looking forward to seeing everyone next week as well as at the Mid-Cycle Meeting! Kyle [1] https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting Please bear with me as I ask a question on nova-network parity work items that may have been addressed earlier. Is the auto-associating floating IPs part of the work items? I see a blueprint on this topic [2] but do not see it listed in [3] or [4]. Thanks, Mohammad [2] https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip [3] https://etherpad.openstack.org/p/neutron-nova-parity [4] https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchical administrative boundary [keystone]
On 05/08/2014 07:55 PM, Tiwari, Arvind wrote: Hi All, Below is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancy http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9 session of Atlanta design summit. https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary Please take a look. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Looks very good. One question: Why hierarchical domains and not Projects. I'm not disagreeing, mind you, just that I think the Nova team is going for hierarchical Projects. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fuel
On 05/06/2014 09:01 PM, Roman Sokolkov wrote: Tizy, Selinux is disabled on all nodes under Fuel. https://github.com/stackforge/fuel-library/blob/stable/4.0/deployment/puppet/cobbler/templates/kickstart/centos.ks.erb#L32 You could check it by getenforce command. It should report Disabled. So you could simply pass all steps related to Selinux. Thank you. Yeah, you don't need to deal with SELinux if SELinux is disabled. On Tue, May 6, 2014 at 12:51 AM, Tizy Ninan tizy.e...@gmail.com mailto:tizy.e...@gmail.com wrote: Hi We are trying to integrate the openstack setup with the Microsoft Active Directory(LDAP server). As per openstack documentation, http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html in order to integrate with an LDAP server, an SELinux Boolean variable 'authlogin_nsswitch_use_ldap' needs to be set. We tried setting the variable using the following command. $ setsebool --P authlogin_nsswitch_use_ldap 1 It returned a message stating SElinux is disabled. We changed the status of SElinux to permissive mode and tried setting the boolean variable, but it returned a message stating 'record not found in the database'. We also tried retrieving all the boolean variables by using the following command $getsebool --a It listed out all the boolean variables, but there was no variable named 'authlogin_nsswitch_use_ldap' in the list. In order to add the variable we needed semanage. When executing the 'semanage' command it returned 'command not found'. To install semanage we tried installing policycoreutils-python. It showed no package policycoreutils-python available. We are using Mirantis Fuel v4.0. We have an openstack Havana deployment on CentOS 6.4 and nova-network network service. Can you please help us on why the SELinux boolean variable (authlogin_nsswitch_use_ldap) is not available. Is it because the CentOS image provided by the Fuel master node does not provide the SELinux settings? Is there any alternative ways to set this boolean variable? Kindly help us to resolve this issue. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com mailto:rsokol...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] Merge Nova v2/v3 API tests in Tempest
Hi, In Tempest, there is a lot of copypaste test code for Nova v2/v3 API tests. In addition, we need to add many checks for API test coverage. As the result, now we should apply the same changes to v2 and v3 tests. To avoid these redundant changes, we started bp/nova-api-test-inheritance[1] tasks. This blueprint requires a lot of patches, so I am glad if someone jumps into this. https://etherpad.openstack.org/p/nova-api-test-inheritance contains the way to implement and manages these tasks. If interested in these tasks, please write your names on the etherpad as assignee. (https://review.openstack.org/#/c/92542/ is a good sample.) Thanks Ken'ichi Ohmichi --- [1]: https://blueprints.launchpad.net/tempest/+spec/nova-api-test-inheritance detail: http://git.openstack.org/cgit/openstack/qa-specs/tree/specs/nova-api-test-inheritance.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] API proposal review thoughts
On May 8, 2014, at 2:45 PM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi Carlos, Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain further. No, I mean that loadbalancer instance is needed if we need several *different* L2 endpoints for several front ends. That's basically 'virtual appliance' functionality that we've discussed on today's meeting. From looking at the irc log it looks like nothing conclusive came out of the meeting. I don't understand a lot of the conclusions you arrive at. For example your rejecting the notion of a loadbalancer concrete object unless its needed to include multi l2 network support. Will you make an honest effort to describe your objections here in the ML cause if we can't resolve it here its going to spill over into the summit. I certainly don't want this to dominate the summit. Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
