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 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 > 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
[openstack-dev] [Neutron] Third-party testing
Hi Neutron team, I'm working on building Third-party testing for Neutron Ryu plugin. I intend to use Jenkins and gerrit-trigger plugin. It is required that Third-party testing provides verify vote for all changes to a plugin/driver's code, and all code submissions by the jenkins user. https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Testing_Requirements For this requirements, what kind of filter for the trigger should I set? It is easy to set a file path of the plugin/driver: project: plain:neutron branch: plain:master file:path:neutron/plugins/ryu/** However, this is not enough because it lacks dependencies. It is difficult to judge a patchset which affects the plugin/driver. In addition, gerrit trigger has a file path filter, but there is no patchset owner filter, so it is not able to set a trigger to a patchset which is submitted by the jenkins user. Can Third-party testing execute tests for all patchset including the thing which may not affect the plugin/driver? Thanks, Kaneko ___ 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
[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
Re: [openstack-dev] [heat] Stack convergence first steps
On Thu, 5 Dec 2013 22:13:18 -0600 Christopher Armstrong wrote: > On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt > wrote: > > > On Dec 5, 2013, at 6:25 PM, Christopher Armstrong < > > chris.armstr...@rackspace.com> > > wrote: > > > > On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita < > > anderson...@thoughtworks.com> wrote: > > > >> Hey stackers, > >> > >> We've been working towards making stack convergence ( > >> https://blueprints.launchpad.net/heat/+spec/stack-convergence) one step > >> closer to being ready at a time. After the first patch was submitted we > >> got positive feedback on it as well as some good suggestions as to how to > >> move it forward. > >> > >> The first step (https://blueprints.launchpad.net/heat/+spec/stack-check) > >> is to get all the statuses back from the real world resources and update > >> our stacks accordingly so that we'll be able to move on to the next step: > >> converge it to the desired state, fixing any errors that may have happened. > >> > >> We just submitted another WiP for review, and as we were doing it, a few > >> questions were raised and we'd like to get everybody's input on them. Our > >> main concern is around the use and purpose of the `status` of a > >> stack/resource. `status` currently appears to represent the status of the > >> last action taken, and it seems that we may need to repurpose it or > >> possibly create something else to represent a stack's "health" (i.e. > >> everything is up and running as expected, something smells fishy, something > >> broke, stack's is doomed). We described this thoroughly here: > >> https://etherpad.openstack.org/p/heat-convergence > >> > >> Any thoughts? > >> > >> Cheers, > >> > >> > > I think a lot of OpenStack projects use "status" fields as "status of > > the most recent operation", and I think it's totally wrong. "status" should > > be a known state of the _object_, not an action, and if we need statuses > > for operations, then those operations should be addressable REST objects. > > Of course there are cases where object status should be updated to reflect > > an operating status if it's a completely exclusive operation (BUILDING and > > DELETING make sense, for example). > > > > Actually, I think most projects are the opposite where "status" means > > "what's the state of the resource" (Nova, Trove, Cinder, etc), whereas Heat > > uses status as the state of the last operation. Probably wouldn't be too > > terrible to have a new "state" for stacks and their resources then perhaps > > deprecate and use "status" in the accepted way in the v2 API? > > Well, my point is that it's done inconsistently. Yes, it's mostly used as > an object status, but nova for example uses it as an operation status for > things like resize. Nova's status of in resize is "RESIZE" and "VERITY_RESIZE". This status means "Currently, Instance is ACTIVE and resize in progress". I think Heat can assume resource status is "ACTIVE" in this case. Thus, several status that contain operation status have to map resource(object) status. However in my impression, a status that should assume another status isn't a lot. In my opinion, status mapping table is reasonable in present time. Regards -- Mitsuru Kanabuchi ___ 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
Re: [openstack-dev] [Ceilometer] Compute meter names prefaced by "instance:"
On Sat, Dec 7, 2013 at 4:27 AM, Pendergrass, Eric wrote: > 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
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] [qa][keystone] Keystoneclient tests to tempest
On Sun, Dec 8, 2013 at 3:37 PM, Matt Riedemann wrote: > > > 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
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] [Neutron] DHCP Agent Reliability
On 9 December 2013 01:43, Maru Newby wrote: > >>> 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? If the queue is set to autodelete, it will delete when the agent disconnects. There will be no queue until the agent reconnects. I don't know if we expose that functionality via oslo.messaging, but it's certainly something AMQP can do. >> 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? I'm saying that you can avoid race conditions by a combination of 'subscribe to changes' + 'give me the full state'. -Rob -- Robert Collins 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] [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
[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] [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 : > 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 > > 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 di
[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] [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 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
Re: [openstack-dev] [Neutron] DHCP Agent Reliability
On Dec 7, 2013, at 6:21 PM, Robert Collins wrote: > On 7 December 2013 21:53, Isaku Yamahata 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
