Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Dec 7, 2013, at 6:21 PM, Robert Collins robe...@robertcollins.net wrote: On 7 December 2013 21:53, Isaku Yamahata isaku.yamah...@gmail.com wrote: Case 3: Hardware failure. So an agent on the node is gone. Another agent will run on another node. If AMQP service is set up not to lose notification, notifications will be piled up and stress AMQP service. I would say single node failure isn't catastrophic. So we should have AMQP set to discard notifications if there is noone What are the semantics of AMQP discarding notifications when a consumer is no longer present? Can this be relied upon to ensure that potentially stale notifications do not remain in the queue when an agent restarts? listening: when an agent connects after an outage, it first starts listening, then does a poll for updates it missed. Are you suggesting that processing of notifications and full state synchronization are able to cooperate safely? Or hoping that it will be so in the future? m. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Docker] What are the plans or thoughts about providing volumes aka folder mounts
Yes agree it not very cloud like. Thanks for pointing out the Manila project, didn't know about it. On Fri, Dec 6, 2013 at 5:25 PM, Russell Bryant rbry...@redhat.com wrote: On 12/06/2013 10:54 AM, Daniel Kuffner wrote: Hi All, We are using in our company for a prototype the docker hypervisor on openstack. We have the need to mount a folder inside of a container. To achieve this goal I have implemented a hack which allows to specify a folder mount via nova metadata. For example a heat template could look like: my-container: Type: OS::Nova::Server Properties: flavor: m1.large image: my-image:latest metadata: Volumes: /host/path:/guest/path This approach is of course not perfect and even a security risk (which is in our case no issue since we are not going to provide a public cloud). Any other ideas or plans how to provide the volume/folder mount in the future? I think *directly* specifying a host path isn't very cloudy. We don't really have an abstraction appropriate for this yet. Manila [1] (filesystem aaS) seems to be the closest thing. Perhaps some work in Manila and some Nova+Manila integration would be the right direction here. Thoughts? [1] https://wiki.openstack.org/wiki/Manila_Overview -- Russell Bryant ___ 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][LBaaS] L7 model - an alternative
Hi I was thinking about a different way for L7 modeling. The key points are: - The Rule has no action attribute - A Policy is a collection of rules - Association keep a reference to a Vip and to a Policy - Association holds the action (what to do if the Policy return True) - Association holds (optional) the Pool ID. When the action is redirection to a pool See: https://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/edit?usp=sharing Please let me know what do you think about this model. Thanks Avishay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi All. The wiki page for LBaaS SSL support was updated. Please see and comment https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Vip_SSL_Association Thank you! Evg -Original Message- From: Samuel Bercovici Sent: Thursday, December 05, 2013 9:14 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Evgeny Fedoruk; Samuel Bercovici Subject: RE: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Correct. Evgeny will update the WIKI accordingly. We will add a flag in the SSL Certificate to allow specifying that the private key can't be persisted. And in this case, the private key could be passed when associating the cert_id with the VIP. Regards, -Sam. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: Thursday, December 05, 2013 8:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi folks OK, It looks like we get consensus on separate resource way. Best Nachi 2013/12/5 Eugene Nikanorov enikano...@mirantis.com: Hi, My vote is for separate resource (e.g. 'New Model'). Also I'd like to see certificate handling as a separate extension/db mixing(in fact, persistence driver) similar to service_type extension. Thanks, Eugene. On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran stephen.g...@theguardian.com wrote: Hi, Right, sorry, I see that wasn't clear - I blame lack of coffee :) I would prefer the Revised New Model. I much prefer the ability to restore a loadbalancer from config in the event of node failure, and the ability to do basic sharing of certificates between VIPs. I think that a longer term plan may involve putting the certificates in a smarter system if we decide we want to do things like evaluate trust models, but just storing them locally for now will do most of what I think people want to do with SSL termination. Cheers, On 05/12/13 09:57, Samuel Bercovici wrote: Hi Stephen, To make sure I understand, which model is fine Basic/Simple or New. Thanks, -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Thursday, December 05, 2013 8:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8F qVe ZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this
[openstack-dev] [qa][keystone] Keystoneclient tests to tempest
We'd like to get the keystoneclient tests out of keystone. They're serving a useful purpose of catching problems with non-backwards compatible changes in keystoneclient so we still want them run. Problem is they're running at the wrong time -- only on changes to keystone and not changes to keystoneclient. The tests need to be run: When keystoneclient changes - run the tests against the change When the tests change - run the change against the current keystoneclient and also old clients When keystone changes - run the tests against the change with current client So here's what I think we need to do to get keystone client tests out of keystone: 1) Figure out where to put the tests - is it tempest or something else? 2) Write up a test and put it there 3) Have a job that when there's a change in the tests it runs against current client lib 4) Expand the job to also run against old clients - or is there 1 job per version? - what versions? (keystone does master, essex-3, and 0.1.1) - e.g. tox -e master,essex-3,0.1.1 - suggest start with these versions and then consider what to use in future 5) Now we can start adding tests 6) Have a job that when there's a change in keystoneclient it runs these tests against the change 7) When there's a change in keystone, run these tests against the change 8) Copy the keystoneclient tests from keystone to the new location -- will require some changes 9) Remove the tests from keystone \o/ 10) Move tests back to keystone where makes sense -- use webtest like v3 tests I created an etherpad with this same info so it's easier to discuss: https://etherpad.openstack.org/p/KeystoneTestsToTempest - Brant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
On 13-12-08 12:07 AM, Lyle, David wrote: The set domain context functionality is for operators (admins) to refine the context that they are working in/viewing. Admins can limit the scope of identity visibility to one domain, rather than having to sort through the exhaustive lists of projects, users, and groups. If you are adding multiple users with the admin role, they will still have visibility across domains. They will be able to see all instances, volumes, networks, etc. Currently, the domain scoping is only implemented for the identity management panel group. The intention is to extend the scoping to services beyond keystone as well. But even once that's implemented, any user with the admin role will be able to view/modify any instance, volume, network, etc., via the CLI. The functionality you are looking for is a way to view things as a domain admin. The domain admin role does not explicitly exist in OpenStack. It needs to, but does not. If implemented, a user with domain admin capabilities would not have the admin role and see entities in their domain much like what is seen in the current project dashboard. There are several Horizon blueprints in Icehouse to add RBAC support for the integrated services and consolidate the project and admin dashboards. Once those are implemented, then creating a domain admin role and modifying the policy.json files Horizon uses would allow the behavior you desire -- assuming you are using a policy.json file for keystone that also supports a domain admin role. This will look very much like the identity management panel group does today when the domain context is set. -David Lyle -Original Message- From: Paul Belanger [mailto:paul.belan...@polybeacon.com] Sent: Saturday, December 07, 2013 7:49 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button Greetings, I recently enabled multi-domain support on my dashboard and noticed a new domain context button. I was actually surprised to see I had to manually toggle the functionality to set the domain context, hiding domain foo resources from domain bar. My question is simple, what is the purpose of this functionality? For me, if I setup admins in 2 different domains, I don't want them to actually see the resources of the other, asking them to click said button seems to defeat the purpose. Right now, I am attempting to setup a configuration file settings that will force the domain_context to be setup on login, hence hiding external domain resources by default. But like I asked, trying to better understand the use case of the current functionality. Correct, I am in-fact trying to get 'domain admins' setup using horizon. Right now I've been struggling to get the policy.v3cloudsample.json[1] to properly work in keysone, let alone horizon. Because I was struggling with that, I was next focusing on the 'domain context' functionality in horizon to see if I could limit functionality. [1] https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][keystone] Keystoneclient tests to tempest
On Sunday, December 08, 2013 11:26:07 AM, Brant Knudson wrote: We'd like to get the keystoneclient tests out of keystone. They're serving a useful purpose of catching problems with non-backwards compatible changes in keystoneclient so we still want them run. Problem is they're running at the wrong time -- only on changes to keystone and not changes to keystoneclient. The tests need to be run: When keystoneclient changes - run the tests against the change When the tests change - run the change against the current keystoneclient and also old clients When keystone changes - run the tests against the change with current client So here's what I think we need to do to get keystone client tests out of keystone: 1) Figure out where to put the tests - is it tempest or something else? 2) Write up a test and put it there 3) Have a job that when there's a change in the tests it runs against current client lib 4) Expand the job to also run against old clients - or is there 1 job per version? - what versions? (keystone does master, essex-3, and 0.1.1) - e.g. tox -e master,essex-3,0.1.1 - suggest start with these versions and then consider what to use in future 5) Now we can start adding tests 6) Have a job that when there's a change in keystoneclient it runs these tests against the change 7) When there's a change in keystone, run these tests against the change 8) Copy the keystoneclient tests from keystone to the new location -- will require some changes 9) Remove the tests from keystone \o/ 10) Move tests back to keystone where makes sense -- use webtest like v3 tests I created an etherpad with this same info so it's easier to discuss: https://etherpad.openstack.org/p/KeystoneTestsToTempest - Brant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'll ask the super obvious question, why not move the keystoneclient tests to keystoneclient? -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][keystone] Keystoneclient tests to tempest
On Sun, Dec 8, 2013 at 3:37 PM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: On Sunday, December 08, 2013 11:26:07 AM, Brant Knudson wrote: We'd like to get the keystoneclient tests out of keystone. They're serving a useful purpose of catching problems with non-backwards compatible changes in keystoneclient so we still want them run. Problem is they're running at the wrong time -- only on changes to keystone and not changes to keystoneclient. The tests need to be run: When keystoneclient changes - run the tests against the change When the tests change - run the change against the current keystoneclient and also old clients When keystone changes - run the tests against the change with current client So here's what I think we need to do to get keystone client tests out of keystone: 1) Figure out where to put the tests - is it tempest or something else? 2) Write up a test and put it there 3) Have a job that when there's a change in the tests it runs against current client lib 4) Expand the job to also run against old clients - or is there 1 job per version? - what versions? (keystone does master, essex-3, and 0.1.1) - e.g. tox -e master,essex-3,0.1.1 - suggest start with these versions and then consider what to use in future 5) Now we can start adding tests 6) Have a job that when there's a change in keystoneclient it runs these tests against the change 7) When there's a change in keystone, run these tests against the change 8) Copy the keystoneclient tests from keystone to the new location -- will require some changes 9) Remove the tests from keystone \o/ 10) Move tests back to keystone where makes sense -- use webtest like v3 tests I created an etherpad with this same info so it's easier to discuss: https://etherpad.openstack.org/p/KeystoneTestsToTempest - Brant I'll ask the super obvious question, why not move the keystoneclient tests to keystoneclient? I believe Brant is talking about the tests that use different versions of the keystone client against the keystone server. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][keystone] Keystoneclient tests to tempest
Hi! Thanks - I've been wanting to kill this for a long time. Thanks for starting the discussion... On 12/08/2013 07:26 PM, Brant Knudson wrote: We'd like to get the keystoneclient tests out of keystone. They're serving a useful purpose of catching problems with non-backwards compatible changes in keystoneclient so we still want them run. Problem is they're running at the wrong time -- only on changes to keystone and not changes to keystoneclient. The tests need to be run: When keystoneclient changes - run the tests against the change When the tests change - run the change against the current keystoneclient and also old clients When keystone changes - run the tests against the change with current client You're talking about this: https://review.openstack.org/#/c/41931/ Which is almost ready to go. So here's what I think we need to do to get keystone client tests out of keystone: 1) Figure out where to put the tests - is it tempest or something else? Tempest. They should be moved to tempest. 2) Write up a test and put it there 3) Have a job that when there's a change in the tests it runs against current client lib Don't need most of that - the generalized test clients against stable versions matrix is about to land - as long as tempest has your tests in the scenarios, you'll be fine. 4) Expand the job to also run against old clients - or is there 1 job per version? - what versions? (keystone does master, essex-3, and 0.1.1) - e.g. tox -e master,essex-3,0.1.1 essex and 0.1.1 are both older than dirt. We just removed folsom from the gate. I'd got ahead and remove these. - suggest start with these versions and then consider what to use in future OpenStack has a clear support policy - the gate infrastructure will be covering that. Done! 5) Now we can start adding tests Tempest scenarios. 6) Have a job that when there's a change in keystoneclient it runs these tests against the change 7) When there's a change in keystone, run these tests against the change Yup. Already accounted for. 8) Copy the keystoneclient tests from keystone to the new location -- will require some changes 9) Remove the tests from keystone \o/ 10) Move tests back to keystone where makes sense -- use webtest like v3 tests I created an etherpad with this same info so it's easier to discuss: https://etherpad.openstack.org/p/KeystoneTestsToTempest - Brant ___ 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] [Ceilometer] Compute meter names prefaced by instance:
On Sat, Dec 7, 2013 at 4:27 AM, Pendergrass, Eric eric.pendergr...@hp.comwrote: Hi, I’ve been out for nearly 3 weeks and noticed Compute meter names are now prefaced by instance: http://docs.openstack.org/developer/ceilometer/measurements.html Not sure when this happened but I was wondering if the change applies across all OpenStack. Will Nova use the change for its events? Also, is the purpose of the change to identify that instance types are undefined and may vary by installation? I don't know whether a prefix is being added, but in Nova we have been removing the use of the term 'instance' and consistently using 'server' instead for anything user facing. I think it'd be a good idea if we were consistent with this across the OpenStack projects. Chris Many thanks, Eric Pendergrass ___ 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] Call for testing: 2013.2.1 candidate tarballs
Hi, We are scheduled to publish Nova, Keystone, Glance, Neutron, Cinder, Horizon, Heat and Ceilometer 2013.2.1 stable Havana releases on Thursday Dec 12. The list of issues fixed so far can be seen here: https://launchpad.net/nova/+milestone/2013.2.1 https://launchpad.net/keystone/+milestone/2013.2.1 https://launchpad.net/glance/+milestone/2013.2.1 https://launchpad.net/neutron/+milestone/2013.2.1 https://launchpad.net/cinder/+milestone/2013.2.1 https://launchpad.net/horizon/+milestone/2013.2.1 https://launchpad.net/heat/+milestone/2013.2.1 https://launchpad.net/ceilometer/+milestone/2013.2.1 We'd appreciate anyone who could test the candidate 2013.2.1 tarballs: http://tarballs.openstack.org/nova/nova-stable-havana.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-havana.tar.gz http://tarballs.openstack.org/glance/glance-stable-havana.tar.gz http://tarballs.openstack.org/neutron/neutron-stable-havana.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-havana.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-havana.tar.gz [*] http://tarballs.openstack.org/heat/heat-stable-havana.tar.gz http://tarballs.openstack.org/ceilometer/ceilometer-stable-havana.tar.gz [*] Horizon will include translations update in review https://review.openstack.org/60713 Thanks Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
Hi all, We had a very good meeting last week around the git-pull blueprint. During the discussion, Monty suggested using Zuul to manage the git repository access and workflow. While he is working on sending the group a diagram and description of what he has in mind, I had a couple of other questions which I am hoping the extended group will be able to answer. 1) Zuul is currently an infrastructure project. - Is there anything that prevents us from using it in Solum? - Does it need to be moved to a normal OpenStack project? 2) Zuul provides a sort of workflow engine. This workflow engine could potentially be used to initiate and manage: API Post - git flow - lang pack flow. - Have there been any discussion after the F2F where we have discussed using some other workflow engine? - Is Zuul’s engine generic enough to be used in Solum? (Hoping Monty can help with this one) - Perhaps only use it to manage the API post - git flow stages? Thanks —Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Git-workgroup recurring weekly meeting doodle poll
Hi all, During our last meeting, it was suggested that the Wed 9am PST meeting time is not suitable for Asia and a few other interested parties were also unable to attend. I have set up a new doodle poll to gather times to reschedule the meeting. Please indicate your availability here: http://doodle.com/b4pktcignhphbhqe I would like to make this a recurring meeting so please make sure it works for future weeks as well and not only for the date noted in the poll. Thanks Krishna___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Questions around Development Process
Thanks to all who replied, it's extremely helpful. I'll add a focus on integration tests to the list of requirements Mainn - Original Message - Hey, you've already got a bunch of answers, but FWIW: a) I think it's fine to do a few big patches deleting stuff you don't want. You can always bring it back from git history. OTOH if you bring it back it will be reviewed again :). b) I think UI + API + pythonclient in parallel is ok, but: - please get tempest (which implies devstack too) API tests up as quickly as possible. Tempest provides the contract definition to detect regressions in API usage. You can't deploy a production cloud on top of devstack, but you can use Heat and Keystone and Glance and Ironic APIs sensibly, which will let meaningful tests of Tuskar API. I'm not sure where the JS / Horizon tests fit precisely, but again - lets make sure that we have functional tests in Tempest as quickly as possible: this is crucial for when we start 'Integration'. Cheers, Rob On 7 December 2013 04:37, Tzu-Mainn Chen tzuma...@redhat.com wrote: Hey all, We're starting to work on the UI for tuskar based on Jarda's wireframes, and as we're doing so, we're realizing that we're not quite sure what development methodology is appropriate. Some questions: a) Because we're essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar will simply disappear), it's difficult to do small incremental patches that support existing functionality. Is it okay to have patches that break functionality? Are there good alternatives? b) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API would provide. We would then mock those calls in the UI, replacing them with real API calls as they became available. Is this acceptable? If there are precedents for this kind of stuff, we'd be more than happy to follow them! Thanks, Tzu-Mainn Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
