Re: [openstack-dev] In loving memory of Chris Yeoh
On 8 Apr 2015 4:49 pm, Michael Still mi...@stillhq.com wrote: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris Oh crap. Thank you for letting us know in such a caring way. Vale, Chris. -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Congress] hosts table of nova datasource driver
Hi, congress folks I'm new to congress and I'd like to use hosts table of nova datasource driver in my usecase. I, however, found out the hosts table is commented out in current master. Is there any reason to comment out it? or will it be removed from an official datasource in the future? best regard, masa -- 室井 雅仁(Masahito MUROI) Software Innovation Center, NTT Tel: +81-422-59-4539 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
Kyle and Neutron Team, Having the mid-cyle just one month after the Liberty summit does not really fit into the definition of mid-cycle. It feels like we are just getting up to speed on Liberty BPs when we need to get ready for three days of sprint coding. Would you consider to move this at least one month after? I really want to go but it feels to soon to request permission to my management team. Thanks, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 6:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add it to the etherpad now. I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. Bummer! But, as I said, we'll try our best to include remote people into the coding sprint, so hopefully you can participate from afar. :) -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] need help regarding openstack
Could you provide more detail log in sahara? Your situation usually is because the VMs cannot be ssh, so they are waiting for the VMs get ready. One thing you can do is to make sure you can ssh into the VM using private ip/floating ip. From: Deepika Agrawal [mailto:deepika...@gmail.com] Sent: Wednesday, April 8, 2015 12:11 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] need help regarding openstack hi guys! I installed Openstack and in that i installed Hadoop i.e., sahara for distributed storage. But the problem I am facing is that when i am going to run node cluster, system will go in the waiting state because I have only 4GB RAM in my laptop. and my college also dint provide me sufficient space. This is for my Btech project. Can Someone tell me what I can be done with open stack so that I'll show this to my mentors as my Btech project. I need help. Please help me. -- Deepika Agrawal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
On 04/08/2015 05:20 AM, Day, Phil wrote: Thanks for letting us know Michael, and thanks for doing it in such a moving way.Sad news indeed Phil From: Michael Still [mailto:mi...@stillhq.com] Sent: 08 April 2015 05:49 To: OpenStack Development Mailing List Subject: [openstack-dev] In loving memory of Chris Yeoh It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.auhttp://linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thank you, Michael for telling us. I'm sad to hear of his passing mostly for selfish reasons, I was looking forward to sharing a hug with him again. I know how grateful he was for the love that surrounded him when he needed it most. Thanks Michael, Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] Sahara + Cinder use cases?
Hello, Did you have any success in finding Sahara and Cinder use cases? Using Cinder one loses the data locality property around which hadoop and hdfs are built, so I am curious of what benefits there are in such a configuration. Thanks, Daniele -Original Message- From: Jacob Liberman [mailto:jlibe...@redhat.com] Sent: Tuesday 24 March 2015 19:34 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [sahara] Sahara + Cinder use cases? Hi, I am working on a Sahara doc bug: https://bugs.launchpad.net/sahara/+bug/1371360 [DOC] Features overview suggests Cinders to increase reliability I am doing some research for this update. What are the use cases for Sahara + Cinder? 1. Cinder-backed Sahara for persistent data 2. Booting Sahara instances from Cinder volumes Can option #1 be used in conjunction with existing plugin images? Are there any docs on using Cinder volumes in place of ephemeral? (similar to the docs describing how to use Swift-backed EDP) The Cinder integration test mounts a few volumes to instances but does not use them. Thanks, Jacob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-dev] resource quotas limit per stacks within a project
+ operators Hard to believe nobody is facing this problems, even on small shops you end up with multiple stacks part of the same tenant/ project. Thanks, Dani On Wed, Apr 1, 2015 at 8:10 PM, Daniel Comnea comnea.d...@gmail.com wrote: Any ideas/ thoughts please? In VMware world is basically the same feature provided by the resource pool. Thanks, Dani On Tue, Mar 31, 2015 at 10:37 PM, Daniel Comnea comnea.d...@gmail.com wrote: Hi all, I'm trying to understand what options i have for the below use case... Having multiple stacks (various number of instances) deployed within 1 Openstack project (tenant), how can i guarantee that there will be no race after the project resources. E.g - say i have few stacks like stack 1 = production stack 2 = development stack 3 = integration i don't want to be in a situation where stack 3 (because of a need to run some heavy tests) will use all of the resources for a short while while production will suffer from it. Any ideas? Thanks, Dani P.S - i'm aware of the heavy work being put into improving the quotas or the CPU pinning however that is at the project level __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [RelMgt] PTL Candidacy
Hello list, I'm announcing my candidacy for OpenStack Release Cycle Management PTL for the Liberty cycle. Release Management is a function that existed since the inception of OpenStack and I always filled that role, so this candidacy may sound like business as usual. I like to think there are a lot of important changes we need to implement during the Liberty cycle though, which makes it extra-interesting. First, we need to scale and evolve the various Release Cycle Management subteams to accommodate the big-tent initiative. How to scale those central activities to a higher number of OpenStack projects ? That effort is already started for the stable maintenance subteam, which implemented a number of structural changes to support more projects while preserving the ideals outlined in the Stable branch policy. For the release subteam, that means evolving from doing only direct release management to providing advice, reusable tools and documented processes. It is a pretty significant change that will require a bit of work and recruitment in the team, and I'd like to lead that change if you give me your trust. Second, we need to have a discussion on long-term evolution of the release model to better serve our users. The 6-month cycle with 3 intermediary milestones was always a compromise between our stable support and documentation capacity and our goal of releasing early, releasing often. As our base projects slowly mature and we welcome more OpenStack projects, we want to reconsider that trade-off and at least bring some flexibility to it. I think my experience there can be useful while we navigate that treacherous pass. You'll note that I'm not mentioning the Vulnerability Management Subteam anymore, since that one got reassigned to the new Security team that just got approved. Thank you for your consideration ! -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
On 04/08/2015 03:58 AM, Dmitry Tantsur wrote: On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Tempest shouldn't be the *only* test for a project API. The projects themselves need to take some ownership for their API getting full coverage with in tree testing, including whatever microversion strategy they are employing. My original thoughts about this would be that Tempest tests without versions (so the low end), plus there could be specific Tempest tests added for new microversions. Regression of 'latest' should be a low probability event, caught by the project in tree. So I think that Tempest on every run for that is excessive. Instead I'd say that should go into periodic changes instead. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting
Hi Muguel: Either works for me. Carol From: Vikram Choudhary [mailto:vikram.choudh...@huawei.com] Sent: Wednesday, April 08, 2015 1:49 AM To: Miguel Ángel Ajo Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel, Voting for timeslot: b. Thanks Vikram From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com] Sent: 07 April 2015 21:49 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting Hi Miguel, Both time slots work for me. Thanks for rekindling this effort. Thanks, Sandhya From: Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 1:45 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote: On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: On 7 April 2015 at 00:33, Armando M. arma...@gmail.commailto:arma...@gmail.com wrote: On 6 April 2015 at 08:56, Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: I'd like to co-organized a QoS weekly meeting with Sean M. Collins, In the last few years, the interest for QoS support has increased, Sean has been leading this effort [1] and we believe we should get into a consensus about how to model an extension to let vendor plugins implement QoS capabilities on network ports and tenant networks, and how to extend agents, and the reference implementation others [2] As you surely know, so far every attempt to achieve a consensus has failed in a pretty miserable way. This mostly because QoS can be interpreted in a lot of different ways, both from the conceptual and practical perspective. Yes, I'm fully aware of it, it was also a new feature, so it was out of scope for Kilo. It is important in my opinion to clearly define the goals first. For instance a simple extensions for bandwidth limiting could be a reasonable target for the Liberty release. I quite agree here, but IMHO, as you said it's a quite open field (limiting, guaranteeing, marking, traffic shaping..), we should do our best in trying to define a model allowing us to build that up in the future without huge changes, on the API side I guess micro versioning is going to help in the API evolution. Also, at some point, we should/could need to involve the nova folks, for example, to define port flavors that can be associated to nova instance flavors, providing them 1) different types of network port speeds/guarantees/priorities, 2) being able to schedule instance/ports in coordination to be able to met specified guarantees. yes, complexity can sky rocket fast, Moving things such as ECN into future works is the right thing to do in my opinion. Attempting to define a flexible framework that can deal with advanced QoS policies specification is a laudable effort, but I am a bit skeptical about its feasibility. ++, I think focusing on perhaps bandwidth limiting may make a lot of sense Yes, I believe we should look into the future , but at the same pick our very first feature (or a very simple set of them) for L, stick to it, and try to make a design that can be extended. As per discussion we've had during the last few months [3], I believe we should start simple, but prepare a model allowing future extendibility, to allow for example specific traffic rules (per port, per IP, etc..), congestion notification support [4], ... Simple in my mind is even more extreme then what you're proposing here... I'd start with bare APIs for specifying bandwidth limiting, and then phase them out once this framework is in place. Also note that this kind of design bears some overlap with the flavor framework which is probably going to be another goal for Liberty. Indeed, and the flavor framework is something I'm hoping we can land by Liberty-1 (yes, I just said Liberty-1). Yes it's something I looked at, I must admit I wasn't able to see it work together (It doesn't mean it doesn't play well, but most probably I was silly enough not to see it :) ), I didn't want to distract attention from the Kilo cycle focus making questions, so it should be a good thing to talk about during the first meetings. Who are the flavor fathers/mothers? ;) Morever, consider using common tools such as the specs repo to share and discuss design documents. Also a good idea. Yes, that was the plan now, we didn't use it before to avoid creating unnecessary noise during this cycle. It's the first time I'm trying to organize an openstack/neutron meeting, so, I don't know
Re: [openstack-dev] In loving memory of Chris Yeoh
+1 I can't believe we lost him When we met in Hongkong summit his smile give me very deep impression... he is very helpful to me from the first day I contribute to community and I learnt a lot from him May his soul rest in peace Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: Qiao, Liyong liyong.q...@intel.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 04/08/2015 11:30 AM Subject:Re: [openstack-dev] In loving memory of Chris Yeoh +1 from me. Chris is also my leader in IBM some time before, He is a helpful and talkative man. I learn lots from him, he work so hard that I see he send out email shortly before even he is ill in bed. we never forget the contribution for the nova community, nova v3 api, nova v2.1 api nova 2.1 micro version api. I hot he will leave in peace and won’t be worry about the review duty in heaven. I will never forget his word when ending the scrum, “let talk it tomorrow, CU” BR, Eli(Li Yong)Qiao From: Alex Xu [mailto:sou...@gmail.com] Sent: Wednesday, April 08, 2015 5:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] In loving memory of Chris Yeoh Feel very sad. Just few weeks ago, I still saw him active on the community. Really hard believe this happen such suddenly. He was my leader in IBM and mentored me on the openstack community also, offered lots of help without reservation, really learn a lot from him. We have phone call meeting every morning before, he always sounds happy and enthusiastic even after he got health problem. May his soul rest in peace. 2015-04-08 12:49 GMT+08:00 Michael Still mi...@stillhq.com: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] autoscaling and load balancers
Hi, Response inline. Hi, The OS::Heat::AutoScalingGroup resource is somewhat limited at this time, because when a scaling even occurs it does not notify dependent resources, such as a load balancer, that the pool of instances has changed. That's technically not true. If you use a neutron load balancer, and a PoolMember resource in each scaling unit, it will do exactly that. The AWS::AutoScaling::AutoScalingGroup resource, on the other side, has a LoadBalancerNames property that takes a list of AWS::ElasticLoadBalancing::LoadBalancer resources that get updated anytime the size of the ASG changes. I'm trying to implement this notification mechanism for HOT templates, but there are a few aspects that I hope to do better. 1. A HOT template can have get_attr function calls that invoke attributes of the ASG. None of these update when the ASG resizes at this time, a scaling even does a partial update that only affects the ASG resource. I would like to address this. 2. The AWS solution relies on the well known LoadBalancer resource, but often load balancers are just regular instances that get loaded with a load balancer such as haproxy in a custom way. I'd like custom load balancers to also update when the ASG resizes. The ResourceGroup is an interesting resource. It is much simpler than the ASG. In particular, the only way to scale the ResourceGroup is by issuing a stack-update with a new size. This indirectly solves #1 and #2 above, because when a full update is issued any references to the ResourceGroup get updated as well. In my opinion, the best way to address #1 and #2 above so that they work for the ASG as they work for the RG, is to change what happens when there is a scaling event. When the ScalingPolicy resource gets a signal, it reaches directly to the ASG by calling asg.adjust() (or in the near future by sending a signal to it, when a currently proposed patch merges) with the new size. This bypasses the update mechanism, so only a partial update occurs, just the ASG resource itself is updated. I would like this to be a full stack update, so that all references get updated with the new ASG size. This will address #1 and #2. I'm in full support of this. We already do a localized stack update on the nested stack, I don't see any reason why we would do a full one. It would make the template works without making the user do any extra declaration. But there is an alternative to this. I guess we could copy the update mechanism used on the AWS side, which is also partial, but at least covers the load balancers, given in the LoadBalancerNames property. We can have a load_balancer_names equivalent property for the OS::Heat::ASG resource, and we can then trigger the updates of the load balancer(s) exactly like the AWS side does it. For this option, I would like to extend the load balancer update mechanism to work on custom load balancers, as it currently works with the well known load balancer resources. I have implemented this approach and is currently up for review: https://review.openstack.org/#/c/170634/ . I honestly prefer the full update, seems cleaner to me. As mentioned in the review, I don't think it's the proper approach. Especially considering that the load_balancer_names property would actually contain arbitrary resources. Anyway, sorry for the long email. If you can provide guidance on which of the approaches are preferred, or if you have other ideas, I would appreciate it. Thanks a lot for the careful explanation and for tackling this issue. -- Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
On 04/08/2015 12:53 PM, Sean Dague wrote: On 04/08/2015 03:58 AM, Dmitry Tantsur wrote: On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Tempest shouldn't be the *only* test for a project API. The projects themselves need to take some ownership for their API getting full coverage with in tree testing, including whatever microversion strategy they are employing. Agreed, but in-tree testing is also not feasible with too many version. Even now we have 7 (1.0-1.6), if it continues, we'll have not less than 12 after L, 18 after M, etc. And we have to test every one of them for regressions at least occasionally, provided that we don't start to aggressively deprecated microversions. If we do start, then we'll start breaking people even more often, than we should. E.g. if someone writes a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will break, though maybe it can actually work with new API. My original thoughts about this would be that Tempest tests without versions (so the low end), plus there could be specific Tempest tests added for new microversions. Regression of 'latest' should be a low probability event, caught by the project in tree. So I think that Tempest on every run for that is excessive. Instead I'd say that should go into periodic changes instead. -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron-lbaas][tempest] tempest v2 API tests failing with logging_noop driver
It is failing at CI https://125.22.100.252/Change_168046_PatchSet_6_2015-04-04_23_02_18/tempest_api_test.html Seems tests are failing at Radware CI's also. https://os-ci-logs.radware.com/170983_1_2015-04-06_21-19-54/lbaas_v2_tempest_tests.log Will do necessary changes to skip. Thanks Santosh On Sun, Apr 5, 2015 at 4:04 PM, santosh sharma chitr.praya...@gmail.com wrote: I am using latest git version (after https://review.openstack.org/#/c/165716/ merge): There are 18 tests failing( (logging noop driver) with latest changes Attaching tempest log files. Thanks Santosh -- Santosh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [RelMgt] PTL Candidacy
confirmed On 04/08/2015 06:18 AM, Thierry Carrez wrote: Hello list, I'm announcing my candidacy for OpenStack Release Cycle Management PTL for the Liberty cycle. Release Management is a function that existed since the inception of OpenStack and I always filled that role, so this candidacy may sound like business as usual. I like to think there are a lot of important changes we need to implement during the Liberty cycle though, which makes it extra-interesting. First, we need to scale and evolve the various Release Cycle Management subteams to accommodate the big-tent initiative. How to scale those central activities to a higher number of OpenStack projects ? That effort is already started for the stable maintenance subteam, which implemented a number of structural changes to support more projects while preserving the ideals outlined in the Stable branch policy. For the release subteam, that means evolving from doing only direct release management to providing advice, reusable tools and documented processes. It is a pretty significant change that will require a bit of work and recruitment in the team, and I'd like to lead that change if you give me your trust. Second, we need to have a discussion on long-term evolution of the release model to better serve our users. The 6-month cycle with 3 intermediary milestones was always a compromise between our stable support and documentation capacity and our goal of releasing early, releasing often. As our base projects slowly mature and we welcome more OpenStack projects, we want to reconsider that trade-off and at least bring some flexibility to it. I think my experience there can be useful while we navigate that treacherous pass. You'll note that I'm not mentioning the Vulnerability Management Subteam anymore, since that one got reassigned to the new Security team that just got approved. Thank you for your consideration ! signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/07/2015 11:49 PM, Michael Still wrote: Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. I met Chris at PyCon Australia, as we held an OpenStack mini-summit the day before. A year later when I was considering joining IBM, the fact that he would be on my team was a very strong positive factor in my decision. He was always a joy to work with, even these past few months when he was fighting the ultimate battle. He was, and still is, a true inspiration. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVJRxpAAoJEKMgtcocwZqL7r4P/it99miUFxhJz6gNGHjea9sF d56Y0V3e205omJm4cpCQsYAXJ1BXNnMSIbjACQl/n7NnKjnyTo6GiytAZMb+ew8M k9RzqC2AKjwMHTMC9Z7OdKZTvTMC2FFEK3RLg504CQQtL4ZaKlRnVg2DYuE6sWJS vWhh0YA+syDdzgvV6fwBaE6ot/reSQBV/1oSkvmybYiHfVOxib5ZBWZfXWQC0uZX W6xZydcvSEvy8f5AuLtbZy2rWWp5Iav3AkD1kEGmbKv3/gaMZeQBCkmwXe+G8Prx gmZnrbf3uKV0RaiINT3CYCfDP6o8svtRfBXObpPXsRTwNP+lZk9mfwBRlm4OLudn XeC5A4PG0b3yB1rdRgyjl66LVhQIwpnme+YDJ31vDOJvIkMAsEK6J9mpI2AN32PG xcof9C8SmgU+RrN/n2AfVW6BlKY9VvQqcbu/JmuMRUOaeqwQwMKMikGaRrGZlrhe o5uAaUhEqealxXVD+eZ1kW1p/5Lvq+QezZCSjIR6EIZ8E9v/WRuZvOnf7k5dIMfv Lkl2TbSYu1rh4Uvb7yGb2Xva+dReVIf2wzZrsibExD94oUiKaf85hgxSooM7EoGi jBn+fTiWAO1nE+UahFTKQnuuIs9c+2NcgK1sUkEVRaAPxs7XXeRE7wJsSIID3U0G Z9fQX7Mca/OQF15P2pLc =z/zF -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
Feel very sad. Just few weeks ago, I still saw him active on the community. Really hard believe this happen such suddenly. He was my leader in IBM and mentored me on the openstack community also, offered lots of help without reservation, really learn a lot from him. We have phone call meeting every morning before, he always sounds happy and enthusiastic even after he got health problem. May his soul rest in peace. 2015-04-08 12:49 GMT+08:00 Michael Still mi...@stillhq.com: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Thanks Ken Ohmichi --- [1]: https://review.openstack.org/#/c/166386/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
2015-04-08 13:49 GMT+09:00 Michael Still mi...@stillhq.com: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ It is difficult to believe that. He always helped the other developers and many people were around him. His contribution was not only Nova but also Tempest. He improved quality of whole OpenStack projects through Tempest work, that was really great. May his soul rest in peace. Ken Ohmichi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Mellanox request for permission for Nova CI
Sean, Matt, Is there anything missing for us to start 'non-voting' Nova CI ? Thanks. Lenny Verkhovsky SW Engineer, Mellanox Technologies www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 -Original Message- From: Michael Still [mailto:mi...@stillhq.com] Sent: Wednesday, April 01, 2015 11:57 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI This looks good to me, but it would be interesting to see what Sean or Matt thought. Michael On Thu, Apr 2, 2015 at 3:25 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Apr 1, 2015 at 8:28 AM, Lenny Verkhovsky len...@mellanox.com wrote: Hi all, We had some issues with presentation of the logs, now it looks ok. You can see Nova CI logs here http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20 150401_1102/ Tempest output is http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20 150401_1102/testr_results.html.gz We are currently running tempest api tests on Mellanox HW using SRiOV configuration, We are working to add tempest scenario tests with port direct configuration for SRiOV We are also planning to extend tests with our in-house tests developments. Thanks, that looks a lot better. I would like to get a second opinion from another nova-core but this looks like enough to start commenting on nova patches. Lenny Verkhovsky SW Engineer, Mellanox Technologies www.mellanox.com Office:+972 74 712 9244 Mobile: +972 54 554 0233 Fax:+972 72 257 9400 From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Thursday, March 26, 2015 3:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI On Thu, Mar 19, 2015 at 5:52 AM, Nurit Vilosny nur...@mellanox.com wrote: Hi Joe, Sorry for the late response. Here are some latest logs for the Nova CI: http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20 150318_1650/ http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20 150318_1506/ http://144.76.193.39/ci-artifacts/37/165437/1/check-nova/Check-MLNX-N ova-ML2-Sriov-driver/e90a677/ http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20 150318_1851/ I couldn't find the equivalent of: http://logs.openstack.org/68/135768/9/check/check-tempest-dsvm-full/f 6c95de/logs/testr_results.html.gz Also what tests are running and how do they actually check if sriov works? I can provide more if needed. Thanks, Nurit. From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, March 11, 2015 7:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Mellanox request for permission for Nova CI On Wed, Mar 11, 2015 at 12:49 AM, Nurit Vilosny nur...@mellanox.com wrote: Hi , I would like to ask for a CI permission to start commenting on Nova branch. Mellanox is engaged in pci pass-through features for quite some time now. We have an operating Neutron CI for ~2 years, and since the pci pass-through features are part of Nova as well, we would like to start monitoring Nova’s patches. Our CI had been silently running locally over the past couple of weeks, and I would like to step ahead, and start commenting in a non-voting mode. During this period we will be closely monitor our systems and be ready to solve any problem that might occur. Do you have a link to the output of your testing system, so we can check what its testing etc. Thanks, Nurit Vilosny SW Cloud Solutions Manager Mellanox Technologies 13 Zarchin St. Raanana, Israel Office: 972-74-712-9410 Cell: 972-54-4713000 Fax: 972-74-712-9111 _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
[openstack-dev] [neutron-lbaas][tempest] tempest v2 API negative tests to be skipped
Please find details at
https://bugs.launchpad.net/neutron/+bug/1441512
Tempest v2 api negative tests for invalid or empty tenantid fails as tenant
id is not validated at plugin layer.
1. In Case of looging noop driver (no validation is done by driver ) ,
In test , create returns success whereas it excepts BadRequest.
0}
neutron_lbaas.tests.tempest.v2.api.test_members.MemberTestJSON.test_create_member_empty_tenant_id
[0.590837s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File neutron_lbaas/tests/tempest/v2/api/test_members.py, line 244,
in test_create_member_empty_tenant_id
self.pool_id, **member_opts)
File
/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py,
line 422, in assertRaises
self.assertThat(our_callable, matcher)
File
/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py,
line 435, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: bound method
type._create_member of class
'neutron_lbaas.tests.tempest.v2.api.test_members.MemberTestJSON' returned
{u'protocol_port': 80, u'weight': 1, u'admin_state_up': True, u'subnet_id':
u'e20c013e-33d0-4752-883d-b78bd45ef0ea', u'tenant_id': u'', u'address':
u'127.0.0.1', u'id': u'3f8d811f-ab69-44f8-ae18-8fc20a94b228'}
2.In case of if Backend Driver (Say NetScaler) ,driver is raising
BadRequest .
==
return self._callable_object(*self._args, **self._kwargs)
File neutron_lbaas/tests/tempest/v2/api/base.py, line 252, in
_create_member
member = cls.members_client.create_member(pool_id, **member_kwargs)
File neutron_lbaas/tests/tempest/v2/clients/members_client.py, line
51, in create_member
resp, body = self.post(url, post_body)
File
/opt/stack/neutron-lbaas/.tox/tempest/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py,
line 252, in post
return self.request('POST', url, extra_headers, headers, body)
File
/opt/stack/neutron-lbaas/.tox/tempest/src/tempest/tempest/common/service_client.py,
line 83, in request
raise exceptions.ServerFault(ex)
tempest.exceptions.ServerFault: Got server fault
Details: Got server fault
Details: An error happened in the driver
===
Above behavior is observed as ,at plugin layer all Exceptions from Driver
is raised as same Driver Exception.
plugin.y
def _call_driver_operation(self, context, driver_method, db_entity,
old_db_entity=None):
manager_method = %s.%s %
(driver_method.__self__.__class__.__name__,
driver_method.__name__)
LOG.info(_LI(Calling driver operation %s) % manager_method)
try:
if old_db_entity:
driver_method(context, old_db_entity, db_entity)
else:
driver_method(context, db_entity)
# catching and reraising agent issues
except (lbaas_agentschedulerv2.NoEligibleLbaasAgent,
lbaas_agentschedulerv2.NoActiveLbaasAgent) as no_agent:
raise no_agent
except Exception:
LOG.exception(_LE(There was an error in the driver))
self._handle_driver_error(context, db_entity)
raise loadbalancerv2.DriverError() #-- bad request
is raised as Driver Error
Negative Testcases:-
test_create_listener_invalid_tenant_id()
test_create_listener_invalid_empty_tenant_id()
test_create_member_invalid_tenant_id()
test_create_member_empty_tenant_id()
--
Santosh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
+1 from me. Chris is also my leader in IBM some time before, He is a helpful and talkative man. I learn lots from him, he work so hard that I see he send out email shortly before even he is ill in bed. we never forget the contribution for the nova community, nova v3 api, nova v2.1 api nova 2.1 micro version api. I hot he will leave in peace and won’t be worry about the review duty in heaven. I will never forget his word when ending the scrum, “let talk it tomorrow, CU” BR, Eli(Li Yong)Qiao From: Alex Xu [mailto:sou...@gmail.com] Sent: Wednesday, April 08, 2015 5:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] In loving memory of Chris Yeoh Feel very sad. Just few weeks ago, I still saw him active on the community. Really hard believe this happen such suddenly. He was my leader in IBM and mentored me on the openstack community also, offered lots of help without reservation, really learn a lot from him. We have phone call meeting every morning before, he always sounds happy and enthusiastic even after he got health problem. May his soul rest in peace. 2015-04-08 12:49 GMT+08:00 Michael Still mi...@stillhq.commailto:mi...@stillhq.com: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.auhttp://linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Thanks Angus for feedback. Best, Dani On Mon, Apr 6, 2015 at 11:30 PM, Angus Salkeld asalk...@mirantis.com wrote: On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea comnea.d...@gmail.com wrote: Hi all, Does anyone know if the above use case has made it into the convergence project and in which release was/ is going to be merged? Hi Phase one of convergence should be merged in early L (we have some of the patches merged now). Phase two is to separate the checking of actual state into a new RPC service within Heat. Then you *could* run that checker periodically (or receive RPC notifications) to learn of changes to the stack's state during the lifetime of the stack. That *might* get done in L - we will just have to see how things go. -Angus Thanks, Dani On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea comnea.d...@gmail.com wrote: Thanks all for reply. I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed this is not possible as of today. Someone else - sorry i forgot his nicname on IRC suggested to write a Ceilometer query to count the number of instances but what @ZhiQiang said is true and this is what we have seen via the instance sample *@Clint - *that is the case indeed *@ZhiQiang* - what do you mean by *count of resource should be queried from specific service's API*? Is it related to Ceilometer's event types configuration? *@Mike - *my use case is very simple: i have a group of instances and in case the # of instances reach the minimum number i set, i would like a new instance to be spun up - think like a cluster where i want to maintain a minimum number of members With regards to the proposal you made - https://review.openstack.org/#/c/127884/ that works but only in a specific use case hence is not generic because the assumption is that my instances are hooked behind a LBaaS which is not always the case. Looking forward to see the 'convergence' in action. Cheers, Dani On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer mspre...@us.ibm.com wrote: Daniel Comnea comnea.d...@gmail.com wrote on 10/27/2014 07:16:32 AM: Yes i did but if you look at this example https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml the flow is simple: CPU alarm in Ceilometer triggers the type: OS::Heat::ScalingPolicy which then triggers the type: OS::Heat::AutoScalingGroup Actually the ScalingPolicy does not trigger the ASG. BTW, ScalingPolicy is mis-named; it is not a full policy, it is only an action (the condition part is missing --- as you noted, that is in the Ceilometer alarm). The so-called ScalingPolicy does the action itself when triggered. But it respects your configured min and max size. What are you concerned about making your scaling group smaller than your configured minimum? Just checking here that there is not a misunderstanding. As Clint noted, there is a large-scale effort underway to make Heat maintain what it creates despite deletion of the underlying resources. There is also a small-scale effort underway to make ASGs recover from members stopping proper functioning for whatever reason. See https://review.openstack.org/#/c/127884/ for a proposed interface and initial implementation. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Propose Winson Chan m4dcoder for core team
Congratulations Winson! You’re now a core member of Mistral. Welcome ) Cheers Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 19:28, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Hello all, As a QA Engineer of Mistral, I also appreciate Winson's contribution to the project, his ideas and I will be glad to see him as a core engineer of Mistral project. On Tue, Apr 7, 2015 at 12:56 PM, Lingxian Kong anlin.k...@gmail.com mailto:anlin.k...@gmail.com wrote: Although I have jumpped into Mistral just for a short time, but really appreciate Winson's vision about my patches, and his work is of great value to Mistral. I'm not in the core team of Mistral, but really hope to see Winson as a core member to bring more to Mistral. On Tue, Apr 7, 2015 at 5:08 PM, Nikolay Makhotkin nmakhot...@mirantis.com mailto:nmakhot...@mirantis.com wrote: It would be good to see Winson as the core contributor in Mistral. +1 for Winson! On Tue, Apr 7, 2015 at 11:53 AM, Renat Akhmerov rakhme...@mirantis.com mailto:rakhme...@mirantis.com wrote: +1 with my both hands. Winson has been working on Mistral for about a year, was actively participating in the very first workflow engine version (what we called PoC) and keeps bringing his experience and excellent engineering skills to the project. Thanks Winson for your passionate work! Renat Akhmerov @ Mirantis Inc. On 07 Apr 2015, at 03:04, Dmitri Zimine dzim...@stackstorm.com mailto:dzim...@stackstorm.com wrote: Hi folks, I’d like to propose Winson Chan (m4dcoder) to become Mistral core team member. Winson brings unique mix of field experience implementing Mistral workflows in user environments, and solid development skills. He has been contributing to Mistral since Mar 2014. Winson did a 23 commits - a number of them are non-trivial, like moving RPC to oslo-messaging, or introducing environments, or making full validation. He has submitted 14 blueprints and detailed design proposals, contributing to design and directions. He found, reported, and fixed bugs. He is becoming more active on the review board (would encourage to do more). I am +1 for m4dcoder as a core team member. DZ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] [scheduler] select_destinations() behavior
Dear all, just a question about the behavior of select_destinations() in Icehouse: this method has to select and consume resources or just select them without consuming? I'm asking you because if I invoke such method for testing the resource availability and only when the result is OK I call run_instance(), the scheduler's filters see a wrong host state (e.g. wrong vcpus_used). This is because both methods use _schedule() which consumes resources (chosen_host.obj.consume_from_instance(instance_properties)). Is this feature intentional? Thanks in advance. cheers, Lisa __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
:( I am shocked to my core. He was so humble and helpful always. It would be very hard to believe that he is no more. God rest his soul in peace. On Wed, Apr 8, 2015 at 1:49 PM, Michael Still mi...@stillhq.com wrote: It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven't had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the 'Hackfest' programming contests for a number of years at Australia's open source conference -- linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa's memories of her dad need to last her a long time, so we've decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks Regards Ghanshyam Mann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] In loving memory of Chris Yeoh
Thanks for letting us know Michael, and thanks for doing it in such a moving way.Sad news indeed Phil From: Michael Still [mailto:mi...@stillhq.com] Sent: 08 April 2015 05:49 To: OpenStack Development Mailing List Subject: [openstack-dev] In loving memory of Chris Yeoh It is my sad duty to inform the community that Chris Yeoh passed away this morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will remember Chris as the clever and caring person that I will remember him as. I haven’t had a chance to confirm with the family if they want flowers or a donation to a charity. As soon as I know those details I will reply to this email. Chris worked on open source for a very long time, with OpenStack being just the most recent in a long chain of contributions. He worked tirelessly on his contributions to Nova, including mentoring other developers. He was dedicated to the cause, with a strong vision of what OpenStack could become. He even named his cat after the project. Chris might be the only person to have ever sent an email to his coworkers explaining what his code review strategy would be after brain surgery. It takes phenomenal strength to carry on in the face of that kind of adversity, but somehow he did. Frankly, I think I would have just sat on the beach. Chris was also a contributor to the Linux Standards Base (LSB), where he helped improve the consistency and interoperability between Linux distributions. He ran the ‘Hackfest’ programming contests for a number of years at Australia’s open source conference -- linux.conf.auhttp://linux.conf.au. He supported local Linux user groups in South Australia and Canberra, including involvement at installfests and speaking at local meetups. He competed in a programming challenge called Loki Hack, and beat out the world to win the event[1]. Alyssa’s memories of her dad need to last her a long time, so we’ve decided to try and collect some fond memories of Chris to help her along the way. If you feel comfortable doing so, please contribute a memory or two at https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing. Michael [1] http://www.lokigames.com/hack/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Consistent variable documentation for diskimage-builder elements
Hello, Id like to propse a standard for consistently documenting our diskimage- builder elements. I have pushed a review which transforms the apt-sources element to this format[1][2]. Essentially, id like to move in the direction of making all our element README.rst's contain a sub section called Environment Vairables with a Definition List[3] where each entry is the environment variable. Under that environment variable we will have a field list[4] with Required, Default, Description, and optionally Example. The goal here is that rather than users being presented with a wall of text that they need to dig through to remember the name of a variable, there is a quick way for them to get the information they need. It also should help us to remember to document the vital bits of information for each vairable we use. Thoughts? Cheers, Greg 1 - https://review.openstack.org/#/c/171320/ 2 - http://docs-draft.openstack.org/20/171320/1/check/gate-diskimage- builder-docs/d3bdf04//doc/build/html/elements/apt-sources/README.html 3 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition- lists 4 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists Looks very promising. Are you planning to add some kind of lint[1] to RST and force formatting or based on common sense for all developers involved? One minor thing: would be nice to have permalinks to Variables. In general, it's more readable and understandable compared to previous version. +1 from me :) [1] https://pypi.python.org/pypi/restructuredtext_lint/0.4.0 -- Dariusz Smigiel Intel Technology Poland __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
Excerpts from Angus Salkeld's message of 2015-04-06 19:55:37 -0700: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) These messages could be (based on Heat's use case): - Specific user oriented log messages (distinct from our normal operator logs) These currently go in the Heat events API, yes? - Deprecation messages (if they are using old resource properties/template features) I think this could fit with the bits above. - Progress and resource state changes (an application doesn't want to poll an api for a state change) These also go in the current Heat events. - Automated actions (autoscaling events, time based actions) As do these? - Potentially integrated server logs (from in guest agents) I wanted to raise this to [all] as it would be great to have a general solution that all projects can make use of. What do we have now: - The user can not get any kind of log message from services. The closest thing ATM is the notifications in Ceilometer, but I have the feeling that these have a different aim. - nova console log - Heat has a DB event table for users (we have long wanted to get rid of this) So if we forget the DB part of it, the API is also lacking things like pagination and search that one would want in an event/logging API. What do other clouds provide: - https://devcenter.heroku.com/articles/logging - https://cloud.google.com/logging/docs/ - https://aws.amazon.com/blogs/aws/cloudwatch-log-service/ - http://aws.amazon.com/cloudtrail/ (other examples...) What are some options we could investigate: 1. remote syslog The user provides a rsyslog server IP/port and we send their messages to that. [pros] simple, and the user could also send their server's log messages to the same rsyslog - great visibility into what is going on. There are great tools like loggly/logstash/papertrailapp that source logs from remote syslog It leaves the user in control of what tools they get to use. [cons] Would we become a spam agent (just sending traffic to an IP/Port) - I guess that's how remote syslog works. I am not sure if this is an issue or not? This might be a lesser solution for the use case of an application doesn't want to poll an api for a state change I am not sure how we would integrate this with horizon. I think this one puts too much burden on the user to setup a good receiver. 2. Zaqar We send the messages to a queue in Zaqar. [pros] multi tenant OpenStack project for messaging! [cons] I don't think Zaqar is installed in most installations (tho' please correct me here if this is wrong). I know Mirantis does not currently support Zaqar, so that would be a problem for me. There is not the level of external tooling like in option 1 (logstash and friends) I agree with your con, and would also add that after the long discussions we had in the past we had some concerns about scaling. 3. Other options: Please chip in with suggestions/links! There's this: https://wiki.openstack.org/wiki/Cue I think that could be a bit like 1, but provide the user with an easy target for the messages. I also want to point out that what I'd actually rather see is that all of the services provide functionality like this. Users would be served by having an event stream from Nova telling them when their instances are active, deleted, stopped, started, error, etc. Also, I really liked Sandy's suggestion to use the notifications on the backend, and then funnel them into something that the user can consume. The project they have, yagi, for putting them into atom feeds is pretty interesting. If we could give people a simple API that says subscribe to Nova/Cinder/Heat/etc. notifications for instance X, and put them in an atom feed, that seems like something that would make sense as an under-the-cloud service that would be relatively low cost and would ultimately reduce load on API servers. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack in the classroom
Yes, offering courses on OpenStack in Coursera kind of platform will be a good idea. Currently there are some cloud computing courses being offered in Coursera along with a capstone project: https://www.coursera.org/specialization/cloudcomputing/19/courses Thanks, Ganesh From: Amrith Kumar amr...@tesora.commailto:amr...@tesora.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, 8 April 2015 9:01 pm To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack in the classroom Shaifali, These are two related but slightly different things. The first is, as you suggest, to offer courses that teach OpenStack and cloud computing. The other which I believe has broader applicability is to teach computing with OpenStack as the exemplar system. Your suggestion of offering courses through a MOOC is a good one in either case, and certainly worth pursuing. Thanks, -amrith From: Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com] Sent: Wednesday, April 08, 2015 11:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] OpenStack in the classroom Hello Amrit I liked the idea of taking OpenStack to the classroom. Thank You for taking the initiative and sharing your knowledge of cloud computing and OpenStack with students. I have a suggestion, why don't you offer a MOOChttp://www.google.co.in/url?sa=trct=jq=esrc=ssource=webcd=2cad=rjauact=8ved=0CCgQFjABurl=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMassive_open_online_courseei=dUIlVZ38D9iLuwTRo4HYDgusg=AFQjCNHB6aQWZ7LqZEhPhyoiZmfYso7Gbwsig2=O23q6eODL8CpmHFQo7KUyQbvm=bv.90237346,d.c2E, preparing video lectures and sharing it with world(not just educational institutions in Massachusetts and near Toronto). We can ask to various MOOC offering portals(like udacity.comhttp://udacity.com, coursera.orghttp://coursera.org etc) to add the course into their list of courses or may be let this course offered by OpenStack Foundation only. This will be really helpful for those who have never studied about cloud computing in their regular study courses curriculum and are new to OpenStack. Such students/listners will get well prepared and *sequential lectures* to read and learn about cloud computing and OpenStack rather than searching on web and reading about each new terms that they encounter while hacking in OpenStack or similar fields. The main reason why am I asking to prepare MOOC is that your effort will reach to whole world and also your knowledge sharing will stay alive forever in the form of video lectures :) Also even though I don't have much knowledge in cloud computing and OpenStack but if you need someone to work with you, I would love to be that. So please let me know if you need an assistant for such stuff. Thanks!!! Shaifali Agrawal about.me/shaifaliagrawal On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar amr...@tesora.commailto:amr...@tesora.com wrote: CS and EE schools today use open source software as the basis for a lot of coursework and as the practical example for several concepts. Most often the exemplar system is Linux. Yet if students are even taught about the cloud, they often learn about that other cloud company from Seattle. I think OpenStack is the ideal exemplar system for a whole lot of CS/EE courses. No matter what area of computer science you are interested in, there’s an OpenStack project (or in some cases several) that you can study. I think the fact that you can have the entire cloud on your laptop, source code and all, is incredibly powerful in the classroom. Not only can you see how the system works, but you can also tweak it or fix it if you find something to be wrong. Some students also learn about software development methodologies by contributing to a fictional open source project. Why do that when they can instead be contributing code to a real open source project? I think there’s a huge opportunity for us to take OpenStack in the Classroom (a longer post about my experience doing this last week is at http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and Kamesh Pemmaraju for helping me with this at short notice. Let us make (and I’m looking to the Foundation to support this as a formal initiative) it a priority to have every university offer courses on computer science and cloud computing with OpenStack as the exemplar system. Personally, I’m going to work with educational institutions in Massachusetts and near Toronto (where Tesora has offices, and where I tend to spend most of my time) to try and make available a course on cloud computing with OpenStack as the exemplar system. I’m going to make the materials, and offer to teach the course, and I will contribute the materials to the
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown rybr...@redhat.com wrote: On 04/08/2015 09:12 AM, Flavio Percoco wrote: On 08/04/15 08:59 -0400, Doug Hellmann wrote: Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Just wanted to +1 the above. I've also considered pbr a packaging/install tool. Furthermore, I believe having it as a runtime requirement makes packagers life more complicated because that means pbr will obviously need to be added as a runtime requirement for that package. RDO actually patches out calls to pbr to avoid the runtime requirement, FWIW. How does RDO handle --version arguments? -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] Utilizing the KMIP plugin
Hey John. I do have the barbican-api.conf file located in the /etc/barbican folder. But that does not seem to be the one that barbican reads from. It seems to be reading from the barbican-api.conf file locate in my home directory. Either way, both have the exact same configurations. I also checked the setup.cfg file and it does have the line for kmip_plugin . Regards, CHRIS SOLIS From: John Wood john.w...@rackspace.com To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: 04/07/2015 10:39 AM Subject:Re: [openstack-dev] [barbican] Utilizing the KMIP plugin Hello Christopher, Just checking, but is that barbican-api.conf file located in your local system’s /etc/barbican folder? If not that is the preferred place for local development. Modifying the copy that is in your local git repository will have no effect. Also, please double check that your local git repository’s setup.cfg has a line like this in there (at/around #35): kmip_plugin = barbican.plugin.kmip_secret_store:KMIPSecretStore Thanks, John From: Christopher N Solis cnso...@us.ibm.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Monday, April 6, 2015 at 10:25 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin Hello! Sorry to Kaitlin Farr for not responding directly to your e-mail. My openstack settings were misconfigured and I was not receiving e-mail from the dev mailing list. Thanks for looking into the issue. I double checked the permissions at the bottom of the kmip_plugin part in the barbican-api.conf file and they are set to 400. I would also like to note that I do not think the code ever actually entered the __init__ function of KMIPSecretStore. I put a breakpoint in the __init__ function but the debugger never gets open. The error occurs and returns without ever seeming to enter the init function. Here are the parts of the barbican-api.conf file that concern the kmip_plugin: . [secretstore] namespace = barbican.secretstore.plugin enabled_secretstore_plugins = kmip_plugin . [kmip_plugin] username = '**' password = '**' host = port = keyfile = '/etc/barbican/rootCA.key' certfile = '/etc/barbican/rootCA.pem' ca_certs = '/etc/barbican/rootCA.pem' ... Thank You!! Regards, Christopher Solis __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Neutron scaling datapoints?
My team is working on experiments looking at how far the Neutron server will scale, with increasing numbers of compute hosts and VMs. Does anyone have any datapoints on this that they can share? Or any clever hints? I'm already aware of the following ones: https://javacruft.wordpress.com/2014/06/18/168k-instances/ Icehouse 118 compute hosts 80 Neutron server processes (10 per core on each of 8 cores, on the controller node) 27,000 VMs - but only after disabling all security/iptables http://www.opencontrail.org/openstack-neutron-at-scale/ 1000 hosts 5000 VMs 3 Neutron servers (via a load balancer) But doesn't describe if any specific configuration is needed for this. (Other than using OpenContrail! :-)) Many thanks! Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Trove] PTL Candidacy
I'd like to announce my candidacy for the PTL role of the Database (Trove) program for Liberty. I have been the PTL for Trove for Juno, and Kilo. During this time frame we made some really good progress on multiple fronts. In Kilo specifically, we completed the oslo-messaging integration work that we had started in Juno. We added support for GTID based mysql master-slave replication. We added support for new datastores including CouchDB, Vertica and DB2, and an initial implementation of clustering for Vertica as well. We furthered the testability of Trove, by moving all testing off of our deprecated 3rd party CI infrastructure and fully into OpenStack CI. We are continuing to make good progress updating and cleaning up our developer docs, install guide, and user documentation. For Liberty, I'd like us to keep working on clustering, with the end goal of being able to provision fully HA database clusters for the various datastores in Trove. This means a continued focus on clustering for datastores including a semi-synchronous mysql clustering solution. I'd also like to ensure that we make progress towards our goal of integrating trove with a monitoring solution to enable scenarios like auto-failover, which will be crucial to HA and a fully managed database service. Additionally, I'd like to keep our momentum going with regards to improving Trove testability documentation, and reviews. Some of the other work-items that I hope we can get to in Liberty include: - Separating out the Guest Agent from the other Trove services. - User access of datastore logs. - Scheduled Tasks for instances - especially backups. - Tackling control plane, guest agent, and datastore updates No PTL candidate email is complete without some commit / review stats, so here they are: * My Patches: https://review.openstack.org/#/q/owner:slicknik,n,z * My Reviews: https://review.openstack.org/#/q/-owner:slicknik+reviewer:slicknik,n,z Thanks for taking the time to make it this far, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Neutron and ACLs
Hello everyone, I (and my sponsor) are interested in adding ACLs to neutron and after trying IRC, emailing some githubbers directly and asking in a couple other places I've been told that this might be the place to have the discussion. Here's what I've been told so far: 1) There was a proposal for Quantum ACLs that was never approved. 2) There might be a push to put ACLs in Keystone and have other services depend on this central resource for ACL information. 3) Swift has ACLs built into it (notably, not using Keystone) 4) I don't see ACLs in any service other than Swift. So my question is: How can I meaningfully engage with the right people to understand what the current thoughts are for ACLs for all of open stack as well as Neutron? If you google my name and open source you'll see that I've been in the game a while and have worked in a few different communities. As such, I found one piece of advice I was given while researching Neutron code up your proposal and submit it to be a bit naive. It's clear there have been some conversations about this in the past and I would really not want to spend a couple months starting from zero, coming up with a solution that *I* like and is objectively good but have it rejected because the community already has inertia going in a different direction. So what I think I need to understand is something like: o What are the current thoughts on ACLs globally and with regard to Neutron o What people should I engage with (both for neutron and other services like keystone) Thanks in advance to all who reply. rw2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] need help regarding openstack
Thnku for ur reply. On Wed, Apr 8, 2015 at 11:57 AM, Chen, Weiting weiting.c...@intel.com wrote: Could you provide more detail log in sahara? Your situation usually is because the VMs cannot be ssh, so they are waiting for the VMs get ready. One thing you can do is to make sure you can ssh into the VM using private ip/floating ip. *From:* Deepika Agrawal [mailto:deepika...@gmail.com] *Sent:* Wednesday, April 8, 2015 12:11 PM *To:* openstack-dev@lists.openstack.org *Subject:* [openstack-dev] need help regarding openstack hi guys! I installed Openstack and in that i installed Hadoop i.e., sahara for distributed storage. But the problem I am facing is that when i am going to run node cluster, system will go in the waiting state because I have only 4GB RAM in my laptop. and my college also dint provide me sufficient space. This is for my Btech project. Can Someone tell me what I can be done with open stack so that I'll show this to my mentors as my Btech project. I need help. Please help me. -- Deepika Agrawal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Deepika Agrawal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] need help regarding openstack
give me any code for open stack. i am unable to do it. On Wed, Apr 8, 2015 at 8:57 PM, Deepika Agrawal deepika...@gmail.com wrote: Thnku for ur reply. On Wed, Apr 8, 2015 at 11:57 AM, Chen, Weiting weiting.c...@intel.com wrote: Could you provide more detail log in sahara? Your situation usually is because the VMs cannot be ssh, so they are waiting for the VMs get ready. One thing you can do is to make sure you can ssh into the VM using private ip/floating ip. *From:* Deepika Agrawal [mailto:deepika...@gmail.com] *Sent:* Wednesday, April 8, 2015 12:11 PM *To:* openstack-dev@lists.openstack.org *Subject:* [openstack-dev] need help regarding openstack hi guys! I installed Openstack and in that i installed Hadoop i.e., sahara for distributed storage. But the problem I am facing is that when i am going to run node cluster, system will go in the waiting state because I have only 4GB RAM in my laptop. and my college also dint provide me sufficient space. This is for my Btech project. Can Someone tell me what I can be done with open stack so that I'll show this to my mentors as my Btech project. I need help. Please help me. -- Deepika Agrawal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Deepika Agrawal -- Deepika Agrawal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack in the classroom
Shaifali, These are two related but slightly different things. The first is, as you suggest, to offer courses that teach OpenStack and cloud computing. The other which I believe has broader applicability is to teach computing with OpenStack as the exemplar system. Your suggestion of offering courses through a MOOC is a good one in either case, and certainly worth pursuing. Thanks, -amrith From: Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com] Sent: Wednesday, April 08, 2015 11:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] OpenStack in the classroom Hello Amrit I liked the idea of taking OpenStack to the classroom. Thank You for taking the initiative and sharing your knowledge of cloud computing and OpenStack with students. I have a suggestion, why don't you offer a MOOChttp://www.google.co.in/url?sa=trct=jq=esrc=ssource=webcd=2cad=rjauact=8ved=0CCgQFjABurl=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMassive_open_online_courseei=dUIlVZ38D9iLuwTRo4HYDgusg=AFQjCNHB6aQWZ7LqZEhPhyoiZmfYso7Gbwsig2=O23q6eODL8CpmHFQo7KUyQbvm=bv.90237346,d.c2E, preparing video lectures and sharing it with world(not just educational institutions in Massachusetts and near Toronto). We can ask to various MOOC offering portals(like udacity.comhttp://udacity.com, coursera.orghttp://coursera.org etc) to add the course into their list of courses or may be let this course offered by OpenStack Foundation only. This will be really helpful for those who have never studied about cloud computing in their regular study courses curriculum and are new to OpenStack. Such students/listners will get well prepared and *sequential lectures* to read and learn about cloud computing and OpenStack rather than searching on web and reading about each new terms that they encounter while hacking in OpenStack or similar fields. The main reason why am I asking to prepare MOOC is that your effort will reach to whole world and also your knowledge sharing will stay alive forever in the form of video lectures :) Also even though I don't have much knowledge in cloud computing and OpenStack but if you need someone to work with you, I would love to be that. So please let me know if you need an assistant for such stuff. Thanks!!! Shaifali Agrawal about.me/shaifaliagrawal On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar amr...@tesora.commailto:amr...@tesora.com wrote: CS and EE schools today use open source software as the basis for a lot of coursework and as the practical example for several concepts. Most often the exemplar system is Linux. Yet if students are even taught about the cloud, they often learn about that other cloud company from Seattle. I think OpenStack is the ideal exemplar system for a whole lot of CS/EE courses. No matter what area of computer science you are interested in, there’s an OpenStack project (or in some cases several) that you can study. I think the fact that you can have the entire cloud on your laptop, source code and all, is incredibly powerful in the classroom. Not only can you see how the system works, but you can also tweak it or fix it if you find something to be wrong. Some students also learn about software development methodologies by contributing to a fictional open source project. Why do that when they can instead be contributing code to a real open source project? I think there’s a huge opportunity for us to take OpenStack in the Classroom (a longer post about my experience doing this last week is at http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and Kamesh Pemmaraju for helping me with this at short notice. Let us make (and I’m looking to the Foundation to support this as a formal initiative) it a priority to have every university offer courses on computer science and cloud computing with OpenStack as the exemplar system. Personally, I’m going to work with educational institutions in Massachusetts and near Toronto (where Tesora has offices, and where I tend to spend most of my time) to try and make available a course on cloud computing with OpenStack as the exemplar system. I’m going to make the materials, and offer to teach the course, and I will contribute the materials to the Foundation. So this is an open offer to any university in MA and near Toronto; if you want someone to develop and deliver a course on cloud computing, please let me know! I think we can all come together and take OpenStack to the Classrooms so that every graduating student interested in cloud computing has a working knowledge of OpenStack. Thanks, -amrith Amrith Kumar, Founder CTO [tesora-small] Mobile: 978-563-9590 Direct: 978-707-8010 x1002 Twitter: @amrithkumarhttp://www.twitter.com/amrithkumar Skype: amrith.skype Check out our bloghttp://www.tesora.com/blog Twitterhttps://twitter.com/tesoracorp Facebookhttps://www.facebook.com/tesoracorp LinkedInhttp://www.linkedin.com/company/parelastic 125
Re: [openstack-dev] [Ironic] How to deal with microversions in 3rdparty tools
On 04/07/2015 11:35 PM, Michael Davies wrote: On Tue, Apr 7, 2015 at 10:32 PM, Dmitry Tantsur dtant...@redhat.com mailto:dtant...@redhat.com wrote: I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? I agree with Jim R's suggestion - it's really up to the consumer as to what they want to do. Having said that... I think that any consumer wants to use the latest version of the API that it can support. And so since we're not planning on making any breaking API changes[1], I think any consumer wants to: a) have a concept of the latest API version that it has been coded for b) then, in negotiation with the server, choose a version that suffices: b1) negotiated_version = min(your code's max version, max Ironic server version) and b2) negotiated_version your code's supported version b3) negotiated_version Ironic API's minimum version Is that statement about not planning on making any breaking API changes an intention or a guarantee? The reason I ask is that doc/source/devref/api_microversions.rst contains an explicit mention of making breaking changes: So breaking changes can be added to the API without breaking users who don't specifically ask for it. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
Kyle, Thank you for your answers and also for organizing this coding sprint. I would like to rephrase my question as follows. If you are elected as Neutron PTL for the Liberty Cycle, would you consider to have either of the following options for the M cycle?: 1. Move the next coding sprint at least one month after the “M” summit 2. Having both a sprint coding and a formal mid-cycle meet-up I know how hard is to organize these sessions and I by no means wanted to change people plans for attending the one in June 2015. However, raising my concerns and suggestions early in the process seems to be a good approach. Kind Regards, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, April 8, 2015 at 6:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote: Kyle and Neutron Team, Having the mid-cyle just one month after the Liberty summit does not really fit into the definition of “mid-cycle”. It feels like we are just getting up to speed on Liberty BPs when we need to get ready for three days of sprint coding. Would you consider to move this at least one month after? I really want to go but it feels to soon to request permission to my management team. Thanks for your concerns Edgar. I guess you're right, and I will stop calling this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding Sprint. It's actually worked out really well to have it close to the first milestone, we have a lot of things we can do very early in the cycle, getting together and pushing towards the first milestone with some of them will work well. Like I indicated to Russell, we'll do our best to facilitate remote attendees over IRC and maybe Hangouts while we're there. Thanks! Kyle Thanks, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 6:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add it to the etherpad now. I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. Bummer! But, as I said, we'll try our best to include remote people into the coding sprint, so hopefully you can participate from afar. :) -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
On Wed, Apr 8, 2015 at 10:14 AM, Edgar Magana edgar.mag...@workday.com wrote: Kyle, Thank you for your answers and also for organizing this coding sprint. I would like to rephrase my question as follows. If you are elected as Neutron PTL for the Liberty Cycle, would you consider to have either of the following options for the M cycle?: 1. Move the next coding sprint at least one month after the “M” summit 2. Having both a sprint coding and a formal mid-cycle meet-up I know how hard is to organize these sessions and I by no means wanted to change people plans for attending the one in June 2015. However, raising my concerns and suggestions early in the process seems to be a good approach. The Liberty coding spring is actually more than a month after the Liberty Summit, so the M coding spring would be the same. I don't think having a coding spring and a mid-cycle makes sense. In fact, I am against mid-cycles where the focus is not on code. Personally, we need to continue evolving the projects in OpenStack so decisions do not need to be made in person. Mid-cycles perpetuate the notion you have to go there and be present so you can be a part of the decision making process. Coding sprints are focused on actually writing code together. Thus, I won't support mid-cycles where decisions are expected to be made, but will continue to support coding sprints. Hope that makes sense. Thanks, Kyle Kind Regards, Edgar From: Kyle Mestery mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, April 8, 2015 at 6:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana edgar.mag...@workday.com wrote: Kyle and Neutron Team, Having the mid-cyle just one month after the Liberty summit does not really fit into the definition of “mid-cycle”. It feels like we are just getting up to speed on Liberty BPs when we need to get ready for three days of sprint coding. Would you consider to move this at least one month after? I really want to go but it feels to soon to request permission to my management team. Thanks for your concerns Edgar. I guess you're right, and I will stop calling this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding Sprint. It's actually worked out really well to have it close to the first milestone, we have a lot of things we can do very early in the cycle, getting together and pushing towards the first milestone with some of them will work well. Like I indicated to Russell, we'll do our best to facilitate remote attendees over IRC and maybe Hangouts while we're there. Thanks! Kyle Thanks, Edgar From: Kyle Mestery mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 6:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add it to the etherpad now. I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. Bummer! But, as I said, we'll try our best to include remote people into the coding sprint, so
Re: [openstack-dev] Neutron and ACLs
What do you mean by ACLs? Is it anything similar to the following? https://review.openstack.org/#/c/132661/ On Wed, Apr 8, 2015 at 9:02 AM, Rich Wellner r...@objenv.com wrote: Hello everyone, I (and my sponsor) are interested in adding ACLs to neutron and after trying IRC, emailing some githubbers directly and asking in a couple other places I've been told that this might be the place to have the discussion. Here's what I've been told so far: 1) There was a proposal for Quantum ACLs that was never approved. 2) There might be a push to put ACLs in Keystone and have other services depend on this central resource for ACL information. 3) Swift has ACLs built into it (notably, not using Keystone) 4) I don't see ACLs in any service other than Swift. So my question is: How can I meaningfully engage with the right people to understand what the current thoughts are for ACLs for all of open stack as well as Neutron? If you google my name and open source you'll see that I've been in the game a while and have worked in a few different communities. As such, I found one piece of advice I was given while researching Neutron code up your proposal and submit it to be a bit naive. It's clear there have been some conversations about this in the past and I would really not want to spend a couple months starting from zero, coming up with a solution that *I* like and is objectively good but have it rejected because the community already has inertia going in a different direction. So what I think I need to understand is something like: o What are the current thoughts on ACLs globally and with regard to Neutron o What people should I engage with (both for neutron and other services like keystone) Thanks in advance to all who reply. rw2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
From a security point, it certainly scares the hell out of me On 7 April 2015 at 08:45, Chris Friesen chris.frie...@windriver.com wrote: On 04/06/2015 10:08 PM, Angus Salkeld wrote: On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen chris.frie...@windriver.com mailto:chris.frie...@windriver.com wrote: On 04/06/2015 08:55 PM, Angus Salkeld wrote: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) snip What are some options we could investigate: 1. remote syslog 2. Zaqar 3. Other options: Please chip in with suggestions/links! What about a per-user notification topic using the existing notification backend? Wouldn't that require the Operator to provide the end user with access to the message bus? Seems scary to me. AMQP supports access controls, so is it really all that scary? Maybe set up a virtual host per user if we want to be paranoid? (Just throwing it out there as an option since we're already using it...) Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] official clients and tempest
Since tempest no longer uses the official clients as a literal code dependency, except for the cli tests which are being removed, the clients have been dropping from requirements.txt. But when debugging issues uncovered by tempest, or when debugging tempest itself, it is useful to use the cli to check various things. I think it would be a good service to users of tempest to include the client libraries when tempest is installed on a machine. Is there a reason to not do this? -David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Rally] PTL candidacy
On Wed, Apr 8, 2015 at 8:02 AM, Boris Pavlovic bpavlo...@mirantis.com wrote: Hi, As far as https://review.openstack.org/#/c/169357/ Rally is part of OpenStack, I would like to announce my candidacy for Rally / Benchmark as a Services. Tristan has informed me that we've confirmed with Thierry that recently-added projects Rally and Security won't run elections this time around and will keep their current PTLs. -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow
Carl, I did want to discuss the refactoring for IPAM but we can do it over the ML. Looks like Salvatore didn't have a chance to play with it over the weekend, so I will be looking at it today (hopefully). John On 4/8/15, 11:26 AM, Carl Baldwin c...@ecbaldwin.net wrote: I will not be available to chair or attend the L3 sub team meeting tomorrow. Are others okay with canceling the meeting? Let me know if you have something to discuss. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
On 04/08/2015 11:25 AM, Dolph Mathews wrote: On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown rybr...@redhat.com wrote: On 04/08/2015 09:12 AM, Flavio Percoco wrote: On 08/04/15 08:59 -0400, Doug Hellmann wrote: Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Just wanted to +1 the above. I've also considered pbr a packaging/install tool. Furthermore, I believe having it as a runtime requirement makes packagers life more complicated because that means pbr will obviously need to be added as a runtime requirement for that package. RDO actually patches out calls to pbr to avoid the runtime requirement, FWIW. How does RDO handle --version arguments? The version is hard-coded as part of the patch process. Not useful in non-package based environments where the version isn't static, unfortunately. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack in the classroom
Amrit, Yeah, I thought you are planning to teach cloud computing and OpenStack, but computing with OpenStack is also no doubt worth spreading to world as you said. Thanks!!! Shaifali Agrawal about.me/shaifaliagrawal [image: Shaifali Agrawal on about.me] http://about.me/shaifaliagrawal On Wed, Apr 8, 2015 at 9:48 PM, Ganesh Narayanan (ganeshna) ganes...@cisco.com wrote: Yes, offering courses on OpenStack in Coursera kind of platform will be a good idea. Currently there are some cloud computing courses being offered in Coursera along with a capstone project: https://www.coursera.org/specialization/cloudcomputing/19/courses Thanks, Ganesh From: Amrith Kumar amr...@tesora.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, 8 April 2015 9:01 pm To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OpenStack in the classroom Shaifali, These are two related but slightly different things. The first is, as you suggest, to offer courses that teach OpenStack and cloud computing. The other which I believe has broader applicability is to teach computing with OpenStack as the exemplar system. Your suggestion of offering courses through a MOOC is a good one in either case, and certainly worth pursuing. Thanks, -amrith *From:* Shaifali Agrawal [mailto:agrawalshaifal...@gmail.com agrawalshaifal...@gmail.com] *Sent:* Wednesday, April 08, 2015 11:05 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] OpenStack in the classroom Hello Amrit I liked the idea of taking OpenStack to the classroom. Thank You for taking the initiative and sharing your knowledge of cloud computing and OpenStack with students. I have a suggestion, why don't you offer a MOOC http://www.google.co.in/url?sa=trct=jq=esrc=ssource=webcd=2cad=rjauact=8ved=0CCgQFjABurl=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMassive_open_online_courseei=dUIlVZ38D9iLuwTRo4HYDgusg=AFQjCNHB6aQWZ7LqZEhPhyoiZmfYso7Gbwsig2=O23q6eODL8CpmHFQo7KUyQbvm=bv.90237346,d.c2E, preparing video lectures and sharing it with world(not just educational institutions in Massachusetts and near Toronto). We can ask to various MOOC offering portals(like udacity.com, coursera.org etc) to add the course into their list of courses or may be let this course offered by OpenStack Foundation only. This will be really helpful for those who have never studied about cloud computing in their regular study courses curriculum and are new to OpenStack. Such students/listners will get well prepared and *sequential lectures* to read and learn about cloud computing and OpenStack rather than searching on web and reading about each new terms that they encounter while hacking in OpenStack or similar fields. The main reason why am I asking to prepare MOOC is that your effort will reach to whole world and also your knowledge sharing will stay alive forever in the form of video lectures :) Also even though I don't have much knowledge in cloud computing and OpenStack but if you need someone to work with you, I would love to be that. So please let me know if you need an assistant for such stuff. Thanks!!! *Shaifali Agrawal* about.me/shaifaliagrawal [image: Shaifali Agrawal on about.me] On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar amr...@tesora.com wrote: CS and EE schools today use open source software as the basis for a lot of coursework and as the practical example for several concepts. Most often the exemplar system is Linux. Yet if students are even taught about the cloud, they often learn about that other cloud company from Seattle. I think OpenStack is the ideal exemplar system for a whole lot of CS/EE courses. No matter what area of computer science you are interested in, there’s an OpenStack project (or in some cases several) that you can study. I think the fact that you can have the entire cloud on your laptop, source code and all, is incredibly powerful in the classroom. Not only can you see how the system works, but you can also tweak it or fix it if you find something to be wrong. Some students also learn about software development methodologies by contributing to a fictional open source project. Why do that when they can instead be contributing code to a real open source project? I think there’s a huge opportunity for us to take OpenStack in the Classroom (a longer post about my experience doing this last week is at http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and Kamesh Pemmaraju for helping me with this at short notice. Let us make (and I’m looking to the Foundation to support this as a formal initiative) it a priority to have every university offer courses on computer science and cloud computing with OpenStack as the exemplar system.
Re: [openstack-dev] [all] how to send messages (and events) to our users
On Wed, 8 Apr 2015, Sandy Walsh wrote: Yes. It would be so good to pull apart the state-machine that is Nova and just emit completed actions via notifications. Then, have something like TaskFlow externalize the orchestration. Do away with RPC-over-AMQP. YES! I've got notes going back to my first few weeks in OpenStack land that essentially say What's with this RPC? Let's have (observable) events! It was basically the first thing I noticed that stood out as a significant limitation. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow
John, I will be around and looking for your posts to the ML. Carl On Wed, Apr 8, 2015 at 11:15 AM, John Belamaric jbelama...@infoblox.com wrote: Carl, I did want to discuss the refactoring for IPAM but we can do it over the ML. Looks like Salvatore didn't have a chance to play with it over the weekend, so I will be looking at it today (hopefully). John On 4/8/15, 11:26 AM, Carl Baldwin c...@ecbaldwin.net wrote: I will not be available to chair or attend the L3 sub team meeting tomorrow. Are others okay with canceling the meeting? Let me know if you have something to discuss. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
Yeah, I don't think anyone would give access to the production rabbitmq directly. We use Yagi [1] to pipe it to AtomHopper [2] for downstream consumption/sanitizing. -S [1] https://github.com/rackerlabs/yagi [2] http://atomhopper.org/ From: Duncan Thomas duncan.tho...@gmail.com Sent: Wednesday, April 8, 2015 2:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] how to send messages (and events) to our users From a security point, it certainly scares the hell out of me On 7 April 2015 at 08:45, Chris Friesen chris.frie...@windriver.commailto:chris.frie...@windriver.com wrote: On 04/06/2015 10:08 PM, Angus Salkeld wrote: On Tue, Apr 7, 2015 at 1:53 PM, Chris Friesen chris.frie...@windriver.commailto:chris.frie...@windriver.com mailto:chris.frie...@windriver.commailto:chris.frie...@windriver.com wrote: On 04/06/2015 08:55 PM, Angus Salkeld wrote: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) snip What are some options we could investigate: 1. remote syslog 2. Zaqar 3. Other options: Please chip in with suggestions/links! What about a per-user notification topic using the existing notification backend? Wouldn't that require the Operator to provide the end user with access to the message bus? Seems scary to me. AMQP supports access controls, so is it really all that scary? Maybe set up a virtual host per user if we want to be paranoid? (Just throwing it out there as an option since we're already using it...) Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] suggestion for lock/protect stack blueprint
Hey, I would like to suggest a blueprint to allow locking/protecting a stack. Similar to: nova server lock or glance-image --is-protected flag. Once a stack is locked, the only operation allowed on the stack is unlock - heat engine should reject any stack operations and ignore signals that modify the stack (such as scaling). The lock operation should have a lock_resources flag (default = True): When True: perform heat lock and enable lock/protect for each stack resource that supports it (nova server, glance image,...). when False: perform heat lock - which would lock the stack and all nested stacks (actions on resources will not be effected). Use-cases: 1. we received several requests from application vendors, to allow maintenance mode for the application. When in maintenance no topology changes are permitted. For example a maintenance mode is required for a clustered DB app that needs a manual reboot of one of its servers - when the server reboots all the other servers are redistributing the data among themselves which causes high CPU levels which in turn might cause an undesired scale out (which will cause another CPU spike and so on...). 2. some cloud-admins have a configuration stack that initializes the cloud (Creating networks, flavors, images, ...) and these resources should always exist while the cloud exists. Locking these configuration stacks, will prevent someone from accidently deleting/modifying the stack or its resources. This feature might even raise in significance, once convergence phase 2 is in place, and many other automatic actions are performed by heat. The ability to manually perform admin actions on the stack with no interruptions is important. Any thoughts/comments/suggestions are welcome. Thanks Noa Koffman. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] suggestion for lock/protect stack blueprint
Hi Noa, would you kindly propose this blueprint as a spec in heat-specs project on review.openstack.org? It is way easier to discuss specs in a Gerrit review format than in ML. If you need a help with submitting a spec for a review, come to our IRC channel (#heat at freenode.net), we'll gladly help you with that. Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) noa.koff...@alcatel-lucent.com wrote: Hey, I would like to suggest a blueprint to allow locking/protecting a stack. Similar to: nova server lock or glance-image --is-protected flag. Once a stack is locked, the only operation allowed on the stack is unlock - heat engine should reject any stack operations and ignore signals that modify the stack (such as scaling). The lock operation should have a lock_resources flag (default = True): When True: perform heat lock and enable lock/protect for each stack resource that supports it (nova server, glance image,...). when False: perform heat lock - which would lock the stack and all nested stacks (actions on resources will not be effected). Use-cases: 1. we received several requests from application vendors, to allow maintenance mode for the application. When in maintenance no topology changes are permitted. For example a maintenance mode is required for a clustered DB app that needs a manual reboot of one of its servers - when the server reboots all the other servers are redistributing the data among themselves which causes high CPU levels which in turn might cause an undesired scale out (which will cause another CPU spike and so on...). 2. some cloud-admins have a configuration stack that initializes the cloud (Creating networks, flavors, images, ...) and these resources should always exist while the cloud exists. Locking these configuration stacks, will prevent someone from accidently deleting/modifying the stack or its resources. This feature might even raise in significance, once convergence phase 2 is in place, and many other automatic actions are performed by heat. The ability to manually perform admin actions on the stack with no interruptions is important. Any thoughts/comments/suggestions are welcome. Thanks Noa Koffman. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
From: Ryan Brown rybr...@redhat.com Sent: Wednesday, April 8, 2015 9:42 AM The trend in the monitoring space seems to be: 1. Alarms are issued from Metrics as Events. (events can issue alarms too, but conventional alarming is metric based) 2. Multiple events are analyzed to produce Metrics (stream processing) 3. Go to Step 1 Indeed. I sort of envisioned heat sending out events that are then consumed both as metrics and by the user (where appropriate). In StackTach I can see that being implemented as /-- resource events other tools Heat -- Winchester --- notifications stream-- user \-- metrics stream -- alerts --/ Yep, you can get a lot of great info from a notification. And a lot of metrics can be produced from them. We use them for debugging, usage/billing and performance monitoring/tuning. Contextual data ftw! :) Events start as structured data. More so, we're looking at establishing AVRO-based schema definitions on top of these events (slow progress). Yeah, I'd really like to have a schema for Heat events so we can have a single event stream and repackage events for different consumption goals (metrics, notifications, programmatic interaction, etc). Yep, that's the right approach. There are some people at Rax looking at getting this nailed down soon. Having to build filters is a relatively error-prone approach compared to the methods described above. I wasn't saying *we* should do the unstructured message + regex filters strategy, I was just pointing out the CW solution for folks who hadn't used it. Gotcha ... agreed. [snip] The Fujitsu team have already added logging support to Monasca (with an elasticsearch backend) and HP is currently adding StackTach.v3 support for notification-event conversion as well as our Winchester event stream processing engine. Also, this is based on Kafka vs. RabbitMQ, which has better scaling characteristics for this kind of data. Oooh, I'll have a look into that, Kafka as an event bus sounds like a good fit. I have the same concern Angus voiced earlier about Zaqar though. What's the deployment of StackTach.v3 across OpenStack installations? Is it mostly deployed for Helion/Rackspace, or are smaller deployers using it as well? We're in the short strokes of rolling STv3 into production at Rax now. No issues with the libraries, it's all hiccups with downstream system integration. HP have some good requirements they want added around hosted monitoring. People are still installing and playing around with STv2. It's battle proven and solves the immediate OpenStack concerns. But it's more rigid than STv3. If you want to get going today, I'd recommend STv2, but all new efforts and partner work is going into STv3. This could be extended to richer JSON events that include the stack, resources affected in the update, stats like num-deleted-resources or num-replaced-resources, autoscaling actions, and info about stack errors. Some of these sound more like a metrics than notifications. We should be careful not to misuse the two. I think they're events, and have facets that are quantifiable as metrics (num-replaced-resources on an update action) and that should be user-visible (update is complete, or autoscaling actions taken). Yep, tricky to discern sometimes. Perhaps a better way to decide if it's an event or a metric is to consider the frequency they're generated or how much context they contain? Is there a way for users as-is to view those raw notifications, not just the indexed k/v pairs? In StackTach.v3 we ship the raw notifications to HDFS for archiving, but expose the reduced event via the API. The message-id links the two. Lots more here: http://www.stacktach.com Thanks! I'll have to read up. By all means, reach out if you have questions. The more people we have that see the value in events, the better. Looking at the rise of packages like storm, spark, reimann.io, etc. it's clear it's a big change in the distributed computing monitoring space. -S __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] suggestion for lock/protect stack blueprint
On Wed, Apr 08, 2015 at 12:43:06PM +, KOFFMAN, Noa (Noa) wrote: Hey, I would like to suggest a blueprint to allow locking/protecting a stack. Similar to: nova server lock or glance-image --is-protected flag. Once a stack is locked, the only operation allowed on the stack is unlock - heat engine should reject any stack operations and ignore signals that modify the stack (such as scaling). The lock operation should have a lock_resources flag (default = True): When True: perform heat lock and enable lock/protect for each stack resource that supports it (nova server, glance image,...). when False: perform heat lock - which would lock the stack and all nested stacks (actions on resources will not be effected). This sounds like a reasonable requirement to me, particularly if there are existing lock operations supported by other openstack services. We might consider making this a stack action, e.g like suspend/resume - actions are intended for stack-wide operations which affect the stack state but not it's definition, so it seems like potentially a good fit. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [designate] PTL Candidacy
confirmed On 04/08/2015 09:32 AM, Kiall Mac Innes wrote: I would like to announce my candidacy for Designate / DNS Services Program PTL position for the Liberty cycle. Keeping this short! I've been working on the Designate project since day 1, and believe we've made great progress over the last few cycles. For Liberty, I expect our focus will be on tighter integration with other OpenStack projects, scalability and reliability improvements, and community growth. Thanks, Kiall __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
On 04/08/2015 07:38 AM, Dmitry Tantsur wrote: On 04/08/2015 12:53 PM, Sean Dague wrote: On 04/08/2015 03:58 AM, Dmitry Tantsur wrote: On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Tempest shouldn't be the *only* test for a project API. The projects themselves need to take some ownership for their API getting full coverage with in tree testing, including whatever microversion strategy they are employing. Agreed, but in-tree testing is also not feasible with too many version. Even now we have 7 (1.0-1.6), if it continues, we'll have not less than 12 after L, 18 after M, etc. And we have to test every one of them for regressions at least occasionally, provided that we don't start to aggressively deprecated microversions. If we do start, then we'll start breaking people even more often, than we should. E.g. if someone writes a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will break, though maybe it can actually work with new API. I do not understand how in tree testing is not feasible. In tree you have insights into all the branching that occurs within code so can very clearly understand what paths aren't possible. It should be a lot more straight forward than external black box testing where that can't be assume. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
On 04/07/2015 02:34 PM, Sandy Walsh wrote:
Tooling in general seems to be moving towards richer event data as well.
The logging tools (Loggly/Logstash/PaperTrail/zillions of others) are
intended to take your unstructured logs and turn them into events, so
why not have Heat output structured events that we can present to the
user with Ceilometer rather than sending log lines (through syslog or
otherwise) and using tooling to reassemble them into events later.
The trend in the monitoring space seems to be:
1. Alarms are issued from Metrics as Events.
(events can issue alarms too, but conventional alarming is metric based)
2. Multiple events are analyzed to produce Metrics (stream processing)
3. Go to Step 1
Indeed. I sort of envisioned heat sending out events that are then
consumed both as metrics and by the user (where appropriate). In
StackTach I can see that being implemented as
/-- resource events other tools
Heat -- Winchester --- notifications stream-- user
\-- metrics stream -- alerts --/
TL;DR: I think what we really want is a place to send and react to
*events*. Logs are a way to do that, of course, but the Ceilometer way
sounds pretty attractive.
The difference is structured vs. unstructured data. Elasticsearch-based
solutions tend to ignore structure by looking at keywords. Some solutions,
like TopLog, infer a structure by gleaning regexs from logs.
Events start as structured data. More so, we're looking at establishing
AVRO-based schema definitions on top of these events (slow progress).
Yeah, I'd really like to have a schema for Heat events so we can have a
single event stream and repackage events for different consumption goals
(metrics, notifications, programmatic interaction, etc).
If anything we should consider changing the logging library to use structured
messages. Specifically:
log(The %(foo)s did %(thing)s % {'foo':'x', 'thing':'action'})
it would be
log({'message':The %(foo)s did %(thing)s, 'foo':'x', 'thing':'action'})
Which can still be formatted for conventional logs, but also sent as a
notification or as a higher-level structure to things like ES, TopLog, etc.
The driver can decide.
* CloudWatch has you send unstructured log messages, then build filters
to parse them into quantifiable events, then set alarms on those metrics.
Having to build filters is a relatively error-prone approach compared to the
methods described above.
I wasn't saying *we* should do the unstructured message + regex filters
strategy, I was just pointing out the CW solution for folks who hadn't
used it.
[snip]
The Fujitsu team have already added logging support to Monasca (with an
elasticsearch backend) and HP is currently adding StackTach.v3 support for
notification-event conversion as well as our Winchester event stream
processing engine. Also, this is based on Kafka vs. RabbitMQ, which has better
scaling characteristics for this kind of data.
Oooh, I'll have a look into that, Kafka as an event bus sounds like a
good fit. I have the same concern Angus voiced earlier about Zaqar
though. What's the deployment of StackTach.v3 across OpenStack
installations? Is it mostly deployed for Helion/Rackspace, or are
smaller deployers using it as well?
This could be extended to richer JSON events that include the stack,
resources affected in the update, stats like num-deleted-resources or
num-replaced-resources, autoscaling actions, and info about stack errors.
Some of these sound more like a metrics than notifications. We should be
careful not to misuse the two.
I think they're events, and have facets that are quantifiable as metrics
(num-replaced-resources on an update action) and that should be
user-visible (update is complete, or autoscaling actions taken).
Is there a way for users as-is to view those raw notifications, not just
the indexed k/v pairs?
In StackTach.v3 we ship the raw notifications to HDFS for archiving, but
expose the reduced event via the API. The message-id links the two.
Lots more here: http://www.stacktach.com
Thanks! I'll have to read up.
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Doug -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [designate] PTL Candidacy
I would like to announce my candidacy for Designate / DNS Services Program PTL position for the Liberty cycle. Keeping this short! I've been working on the Designate project since day 1, and believe we've made great progress over the last few cycles. For Liberty, I expect our focus will be on tighter integration with other OpenStack projects, scalability and reliability improvements, and community growth. Thanks, Kiall __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Kilo stable branches for other libraries
Hi everyone, As you may know, in an effort to simplify stable branch maintenance and increase their resilience to random changes, the following policy was adopted: http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html TL;DR is that in the future, stable branches will be cut from libraries current versions and then expressed in global-requirements using a = operator combination, to allow for non-breaking security/critical fixes updates but not backward-incompatible changes. While Oslo libs (under the leadership of Doug) have all adopted that procedure early, for kilo we are left with all the other OpenStack libraries that (1) haven't cut such stable branches yet and (2) may not have done what they consider their final kilo release yet. At this point in the cycle any change to requirements is highly disrupting (as it needs to be synced to consuming projects and potentially force a release candidate respin). The question is, how should we proceed there ? This is new procedure, so I'm a bit unclear on the best way forward and would like to pick our collective brain. Should we just push requirements cap for all OpenStack libs and create stable branches from the last tagged release everywhere ? What about other libraries ? Should we push a cap there too ? Should we just ignore the whole thing for the Kilo release for all non-Oslo stuff ? For the record, here is a (hopefully correct) list of the OpenStack libs directly consumed by integrated projects: (NB: I skipped all Oslo libs since they have been taken care of already) python-barbicanclient=3.0.1 (now at 3.0.3, release 9 days ago) python-ceilometerclient=1.0.13 (released 6 weeks ago) python-cinderclient=1.1.0 (now at 1.1.1, released 6 months ago) python-designateclient=1.0.0 (now at 1.1.1, released 4 months ago) python-heatclient=0.3.0 (now at 0.4.0, released 7 days ago) python-glanceclient=0.15.0 (now at 0.17.0, released 3 weeks ago) python-keystoneclient=1.1.0 (now at 1.3.0, released 14 days ago) python-neutronclient=2.3.11,3 (released 8 weeks ago) python-novaclient=2.22.0 (now at 2.23.0, released 3 weeks ago) python-saharaclient=0.8.0 (released 4 weeks ago) python-swiftclient=2.2.0 (now at 2.4.0, released 2 weeks ago) python-troveclient=1.0.7 (now at 1.0.9, released 3 weeks ago) glance_store=0.3.0 (now at 0.4.0, released 3 weeks ago) keystonemiddleware=1.5.0 (released 4 weeks ago) pycadf=0.8.0 (released 7 weeks ago) django_openstack_auth=1.1.7,!=1.1.8 (now at 1.1.9, released 2 months ago) All other non-Oslo libs in the OpenStack world do not seem to be directly consumed by projects that have stable branches, and are therefore likely to not maintain stable branches. Please report any glaring omission there. I'm especially worried with python-cinderclient, python-designateclient and django_openstack_auth which are more than 2 months old and may well contemplate another kilo release that could be disrupting at this point. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] not running for PTL for liberty cycle
Excerpts from Doug Hellmann's message of 2015-04-03 08:50:56 -0400: Team, I have decided not to run for PTL for Oslo for the next cycle. Serving as PTL for the last three releases has been a rewarding experience, and I think we’ve made some great strides together as a team. Now it’s time for me to step down and let someone else take the lead position. I am still committed to the mission, and I will be contributing to Oslo, but I do also want to work on some other projects that I won’t have time for if I stay in the PTL role. We have several good candidates for PTL on the team, and I expect us to have no trouble finding someone willing to step up and run. Thanks, Doug Thank you all for your support over the past 3 cycles, and kind words this week. I look forward to continuing to work with all of you! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
Yeah, I'd really like to have a schema for Heat events so we can have a
single event stream and repackage events for different consumption goals
(metrics, notifications, programmatic interaction, etc).
Keystone and parts of Ceilometer use the CADF schema to build notification
messages[1]. you can see example usage in ceilometermiddleware[2] but as an
example, it basically builds a notification similar to:
{
'typeURI': 'http: //schemas.dmtf.org/cloud/audit/1.0/event',
'eventTime': '2015-01-30T16: 38: 43.233621',
'target': { # target of event
'typeURI': 'service/storage/object',
'id': 'account',
},
'observer': {
'id': 'target'
},
'eventType': 'activity',
'measurements': [ # measurements if appplicable
{
'metric': {
'metricId': 'openstack: uuid',
'name': 'storage.objects.outgoing.bytes',
'unit': 'B'
},
'result': 28
}
],
'initiator': { # who is triggering event
'typeURI': 'service/security/account/user',
'project_id': None,
'id': 'openstack: 288f6260-bf37-4737-a178-5038c84ba244'
},
'action': 'read',
'outcome': 'success',
'id': 'openstack: 69972bb6-14dd-46e4-bdaf-3148014363dc'
}
a few of the fields are generated if not given. i just mention this because
i've found it immensely easier as a consumer to work off a consistent format.
[1] http://docs.openstack.org/developer/pycadf/
[2]
https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L198-L227
cheers,
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
On 07/04/15 12:55 +1000, Angus Salkeld wrote: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) These messages could be (based on Heat's use case): - Specific user oriented log messages (distinct from our normal operator logs) - Deprecation messages (if they are using old resource properties/template features) - Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions) - Potentially integrated server logs (from in guest agents) I wanted to raise this to [all] as it would be great to have a general solution that all projects can make use of. What do we have now: - The user can not get any kind of log message from services. The closest thing ATM is the notifications in Ceilometer, but I have the feeling that these have a different aim. - nova console log - Heat has a DB event table for users (we have long wanted to get rid of this) What do other clouds provide: - https://devcenter.heroku.com/articles/logging - https://cloud.google.com/logging/docs/ - https://aws.amazon.com/blogs/aws/cloudwatch-log-service/ - http://aws.amazon.com/cloudtrail/ (other examples...) What are some options we could investigate: 1. remote syslog The user provides a rsyslog server IP/port and we send their messages to that. [pros] simple, and the user could also send their server's log messages to the same rsyslog - great visibility into what is going on. There are great tools like loggly/logstash/papertrailapp that source logs from remote syslog It leaves the user in control of what tools they get to use. [cons] Would we become a spam agent (just sending traffic to an IP/Port) - I guess that's how remote syslog works. I am not sure if this is an issue or not? This might be a lesser solution for the use case of an application doesn't want to poll an api for a state change I am not sure how we would integrate this with horizon. 2. Zaqar We send the messages to a queue in Zaqar. [pros] multi tenant OpenStack project for messaging! [cons] I don't think Zaqar is installed in most installations (tho' please correct me here if this is wrong). I know Mirantis does not currently support Zaqar, so that would be a problem for me. This is, unfortunately, true. However, adoption needs to start somewhere and I believe this would be a good thing to use Zaqar for. Kilo was a heads-down cycle for the Zaqar team but I believe we could help out with making this happen in heat during Liberty. At the Kilo summit, we discussed what was needed for Heat to consume Zaqar and we've completed some of those features. I'm saying this to highlight that Zaqar is now closer to Heat's needs. There is not the level of external tooling like in option 1 (logstash and friends) True again :( There's an almost-complete puppet manifest but other than that, tools are yet to be built. With my Zaqar hat on, I hope we can make this happen and any help on tools/adoption is more than appreciated. Flavio -- @flaper87 Flavio Percoco pgpTGmVFmKyfa.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana edgar.mag...@workday.com wrote: Kyle and Neutron Team, Having the mid-cyle just one month after the Liberty summit does not really fit into the definition of “mid-cycle”. It feels like we are just getting up to speed on Liberty BPs when we need to get ready for three days of sprint coding. Would you consider to move this at least one month after? I really want to go but it feels to soon to request permission to my management team. Thanks for your concerns Edgar. I guess you're right, and I will stop calling this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding Sprint. It's actually worked out really well to have it close to the first milestone, we have a lot of things we can do very early in the cycle, getting together and pushing towards the first milestone with some of them will work well. Like I indicated to Russell, we'll do our best to facilitate remote attendees over IRC and maybe Hangouts while we're there. Thanks! Kyle Thanks, Edgar From: Kyle Mestery mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 6:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional information on the etherpad [1]. We'll set the specific agenda in the coming weeks, but the idea is to focus on things like the pending neutron-lib work [2] while there, similar to what we did with the advanced services split in Utah last year. My experience running the past two mid-cycles has been that having these earlier in the cycle has been helpful for landing a lot of work near the first milestone of a release. I expect this to be the same for Liberty with the sprint in Fort Collins. Please note attendance is not required at all. We will do our best to facilitate virtual collaboration for those who cannot travel to the event. I wanted to get this out there for folks who have to book travel in advance. I don't know anything about these events. Naively: would OVN development (some of which is in Neutron, much of which is not) be an appropriate use of time at the event? Yes, I think putting OVN hacking on the agenda makes a lot of sense! I'll add it to the etherpad now. I suspect so. FWIW, I'm not sure I'll be going, though. The dates aren't good for me. Bummer! But, as I said, we'll try our best to include remote people into the coding sprint, so hopefully you can participate from afar. :) -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
On 08/04/15 08:59 -0400, Doug Hellmann wrote: Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Just wanted to +1 the above. I've also considered pbr a packaging/install tool. Furthermore, I believe having it as a runtime requirement makes packagers life more complicated because that means pbr will obviously need to be added as a runtime requirement for that package. Flavio Doug -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpxE4YrjG7Mt.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [elections] Last hours for PTL candidate announcements
A quick reminder that we are in the last hours for PTL candidate announcements. If you want to stand for PTL, don't delay, follow the instructions on the wikipage and make sure we know your intentions: https://wiki.openstack.org/wiki/PTL_Elections_April_2015 Thank you, Tristan signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Kilo stable branches for other libraries
Thierry, You left out python-ironicclient, which isn't a surprise as it isn't actually listed in Nova's requirements.txt file. I don't have a link handy to cite the previous discussions, but Nova felt that it was not appropriate to list a driver's dependency in their project's requirements file. As such, it is installed from pip in devstack/lib/ironic right now. I've tagged a 0.5.0 version two days ago, and plan a quick fix (0.5.1) today. I think it's reasonable for this library to be capped just like the other python-*clients, but I'm not sure how to express that, due to Nova not allowing this dependency in their requirements.txt file. -Devananda On Wed, Apr 8, 2015 at 7:18 AM Matthias Runge mru...@redhat.com wrote: On 08/04/15 15:55, Thierry Carrez wrote: I'm especially worried with python-cinderclient, python-designateclient and django_openstack_auth which are more than 2 months old and may well contemplate another kilo release that could be disrupting at this point. In general: a great idea, and I've been expecting this for a longer time now. That would save some work. django_openstack_auth: it's quite stable now, although it would make sense to cut a newer release for kilo. We will merge that into horizon eventually, since it's a helper and we never saw anyone to use it outside of horizon. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Kilo stable branches for other libraries
On 04/08/2015 10:42 AM, Dean Troyer wrote: On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: The question is, how should we proceed there ? This is new procedure, so I'm a bit unclear on the best way forward and would like to pick our collective brain. Should we just push requirements cap for all OpenStack libs and create stable branches from the last tagged release everywhere ? What about other libraries ? Should we push a cap there too ? Should we just ignore the whole thing for the Kilo release for all non-Oslo stuff ? Provided that represents the code being used for testing at this point, and I believe it does, this seems like a sensible default action. Next cycle we can make a bit more noise about when this default action will occur, probably pick one of the other existing dates late in the cycle such as RC or string freeze or whatever. (Maybe that already happened and I can't remember?) Yes, due to the way we're testing client libraries, that's the right approach. In future we should fully cap GR as the first Milestone 3 task. And everything after that should be managed as an exception to get bumps. All other non-Oslo libs in the OpenStack world do not seem to be directly consumed by projects that have stable branches, and are therefore likely to not maintain stable branches. Please report any glaring omission there. OSC is not used by any of the integrated release projects but due to its dependencies on the other client libs and use in DevStack I would like to follow the same process for it here. The current 1.0.3 release is the one that should be used for stable. Agreed. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] PTL Candidacy
confirmed On 04/08/2015 10:49 AM, Sergey Lukjanov wrote: Hey folks, I'd like to announce my intention to continue being PTL of the Data Processing program (Sahara). I’m working on Sahara (ex. Savanna) project from scratch, from the initial proof of concept implementation and till now. I have been the acting/elected PTL since Sahara was an idea. Additionally, I’m contributing to other OpenStack projects, especially Infrastructure for the last three releases where I’m core/root teams member now. My high-level focus as PTL is to coordinate work of subteams, code review, release management and general architecture/design tracking. During the Kilo cycle we successfully adopted specs and czars systems. Tons of operability and supportability improvements were done as well as number of interesting features. For Liberty cycle my focus is to keep going in the same direction and to ensure that everything we're working on is related to the end users needs. So, in a few words it's about continuing moving forward in implementing scalable and flexible Data Processing aaS for OpenStack ecosystem by investing in quality, usability and new features. A few words about myself: I’m Principle Software Engineer in Mirantis. I was working a lot with Big Data projects and technologies (Hadoop, HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions before (and partially in parallel) working on Sahara in OpenStack ecosystem. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Kilo stable branches for other libraries
On 08/04/15 15:55, Thierry Carrez wrote: I'm especially worried with python-cinderclient, python-designateclient and django_openstack_auth which are more than 2 months old and may well contemplate another kilo release that could be disrupting at this point. In general: a great idea, and I've been expecting this for a longer time now. That would save some work. django_openstack_auth: it's quite stable now, although it would make sense to cut a newer release for kilo. We will merge that into horizon eventually, since it's a helper and we never saw anyone to use it outside of horizon. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Kilo stable branches for other libraries
On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez thie...@openstack.org wrote: The question is, how should we proceed there ? This is new procedure, so I'm a bit unclear on the best way forward and would like to pick our collective brain. Should we just push requirements cap for all OpenStack libs and create stable branches from the last tagged release everywhere ? What about other libraries ? Should we push a cap there too ? Should we just ignore the whole thing for the Kilo release for all non-Oslo stuff ? Provided that represents the code being used for testing at this point, and I believe it does, this seems like a sensible default action. Next cycle we can make a bit more noise about when this default action will occur, probably pick one of the other existing dates late in the cycle such as RC or string freeze or whatever. (Maybe that already happened and I can't remember?) All other non-Oslo libs in the OpenStack world do not seem to be directly consumed by projects that have stable branches, and are therefore likely to not maintain stable branches. Please report any glaring omission there. OSC is not used by any of the integrated release projects but due to its dependencies on the other client libs and use in DevStack I would like to follow the same process for it here. The current 1.0.3 release is the one that should be used for stable. dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] PTL Candidacy
Hey folks, I'd like to announce my intention to continue being PTL of the Data Processing program (Sahara). I’m working on Sahara (ex. Savanna) project from scratch, from the initial proof of concept implementation and till now. I have been the acting/elected PTL since Sahara was an idea. Additionally, I’m contributing to other OpenStack projects, especially Infrastructure for the last three releases where I’m core/root teams member now. My high-level focus as PTL is to coordinate work of subteams, code review, release management and general architecture/design tracking. During the Kilo cycle we successfully adopted specs and czars systems. Tons of operability and supportability improvements were done as well as number of interesting features. For Liberty cycle my focus is to keep going in the same direction and to ensure that everything we're working on is related to the end users needs. So, in a few words it's about continuing moving forward in implementing scalable and flexible Data Processing aaS for OpenStack ecosystem by investing in quality, usability and new features. A few words about myself: I’m Principle Software Engineer in Mirantis. I was working a lot with Big Data projects and technologies (Hadoop, HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions before (and partially in parallel) working on Sahara in OpenStack ecosystem. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Rally] PTL candidacy
Hi, As far as https://review.openstack.org/#/c/169357/ Rally is part of OpenStack, I would like to announce my candidacy for Rally / Benchmark as a Services. I started this project in 2013 and for almost two years together we made nice project and build even nicer project's community. I would like to hold the position of PTL and improve Rally quality and cover all use cases: https://docs.google.com/a/mirantis.com/spreadsheets/d/16DXpfbqvlzMFaqaXAcJsBzzpowb_XpymaK2aFY2gA2g/edit#gid=0 Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Unable to authenticate with keystone V3 for Barbican curl command
Thanks a lot John for your response.
The issue was were working with keystone server which is SSL enabled and we
need to configure Barbican to provide clients side certificate.
Thanks and Regards,
Asha Seshagiri
On Tue, Apr 7, 2015 at 6:26 PM, John Wood john.w...@rackspace.com wrote:
Hello Asha,
Please following the steps in the pending CR [1]. That configures v3
usage with Keystone, and if you use the Docker Keystone instance mentioned,
it syncs the passwords with it as well. Note the need to execute the setup
script noted to configure Keystone properly as well.
Thanks,
John
[1]
https://review.openstack.org/#/c/169114/2/doc/source/setup/keystone.rst
From: Asha Seshagiri asha.seshag...@gmail.com
Date: Tuesday, April 7, 2015 at 2:49 PM
To: John Wood john.w...@rackspace.com
Cc: openstack-dev openstack-dev@lists.openstack.org, Reller, Nathan
S. nathan.rel...@jhuapl.edu, Douglas Mendizabal
douglas.mendiza...@rackspace.com, a...@redhat.com a...@redhat.com,
Paul Kehrer paul.keh...@rackspace.com, Adam Harwell
adam.harw...@rackspace.com, Alexis Lee alex...@hp.com
Subject: Re: Barbican : Unable to authenticate with keystone V3 for
Barbican curl command
Thanks a lot John for your help and response.
I had followed the same set of instructions as given in the link 1
initially changing the version to v3 , it did not work and hence followed
with link 2 and is not working though.
The link 1 provided below points to keystone v2 changes with barbican
and not v3
[1] http://docs.openstack.org/developer/barbican/setup/keystone.html .
But in this link 2 for Integration keystone V3 with barbican we have to
modify both the configuriation files
*barbican-api-paste.ini and barbican-admin-paste.ini* files . There are
some changes in the filter and pipline names names tied with v3
pipeline = keystone_v3_authtoken context apiapp
.
[filter:keystone_v3_authtoken]
[2]
https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
Could you please confirm that we need to follow the link 1 changing the
version from v2 to v3 with only modification in *barbican-api-paste.ini
file and not **barbican-admin-paste.ini so that I can start looking into
the issue with the changes mentioned in link1 alone.*
Thanks and Regards,
Asha Seshagiri
On Tue, Apr 7, 2015 at 2:08 PM, John Wood john.w...@rackspace.com wrote:
Hello Asha,
We are in the process of migrating our documentation to Sphinx, so I’d
suggest following this link for Keystone configuration options [1].
I’d also note that a CR is pending with a bit more details to setup via
a Docker Keystone here [2].
Thanks,
John
[1] http://docs.openstack.org/developer/barbican/setup/keystone.html
[2] https://review.openstack.org/#/c/169114/
From: Asha Seshagiri asha.seshag...@gmail.com
Date: Tuesday, April 7, 2015 at 1:34 PM
To: openstack-dev openstack-dev@lists.openstack.org
Cc: John Wood john.w...@rackspace.com, Reller, Nathan S.
nathan.rel...@jhuapl.edu, Douglas Mendizabal
douglas.mendiza...@rackspace.com, a...@redhat.com a...@redhat.com,
Paul Kehrer paul.keh...@rackspace.com, Adam Harwell
adam.harw...@rackspace.com, Alexis Lee alex...@hp.com
Subject: Barbican : Unable to authenticate with keystone V3 for Barbican
curl command
Hi All ,
Could anyone please help me on this integration issue.
I am unable to authenticate with keystone V3 for Barbican curl command
.I have followed the procedure given in the following link :
https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API
I was unable to authenticate with the keystone V3 even though the right
token was provided in the curl command
Please find the command to get the token and the curl command to post the
secret .
[root@keystone-versiontest ~]# openstack --insecure token issue *(Command
to get token from keystone v3)*
++--+
| Field | Value|
++--+
| expires| 2015-04-07T18:26:13.835641Z |
|* id | f28b93f27cce4bc09f9ac50d84bde736 |*
| project_id | 9d37f9ecc481422aa8ab53674cb82410 |
| user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
++--+
[root@keystone-versiontest ~]# curl -X POST -H
'content-type:application/json' -H 'X-Project-Id:12345' \
-H X-Auth-Token:*f28b93f27cce4bc09f9ac50d84bde736* -d '{payload:
my-secret-here, payload_content_type: text/plain}'
http://localhost:9311/v1/secrets
*Authentication required*[root@keystone-versiontest ~]#
The contents of the admin.opensrc file is as given below :
[root@keystone-versiontest ~]# cat admin.openrc
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL=https://169.54.204.69:35357/v3
export OS_REGION_NAME=RegionOne
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_ID=default
Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups
On Tue, Apr 07, 2015 at 07:12:42PM -0400, Zane Bitter wrote:
On 07/04/15 05:13, Steven Hardy wrote:
On Thu, Apr 02, 2015 at 06:31:39PM -0400, Zane Bitter wrote:
A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance
mismatch with Heat concepts and how Heat runs its workflow. As many talented
TripleO-ers who have gone before can probably testify, that's surprisingly
difficult to do, but we did come up with an idea that I think might work and
which I'd like to get wider feedback on. For clarity, I'm speaking here in
the context of the new overcloud-without-mergepy templates.
The idea is that we create a SoftwareConfig that, when run, can update some
software on the server. (The exact mechanism for the update is not important
for this discussion; suffice to say that in principle it could be as simple
as [yum|apt-get] update.) The SoftwareConfig would have at least one
input, though it need not do anything with the value.
Then each server has that config deployed to it with a SoftwareDeployment at
the time it is created. However, it is set to execute only on the UPDATE
action. The value of (one of) the input(s) is obtained from a parameter.
As a result, we can trigger the software update by simply changing the value
of the input parameter, and the regular Heat dependency graph will be
respected. The actual input value could be by convention a uuid, a
timestamp, a random string, or just about anything so long as it changes.
Here's a trivial example of what this deployment might look like:
update_config:
type: OS::Heat::SoftwareConfig
properties:
config: {get_file: do_sw_update.sh}
inputs:
- name: update_after_time
description: Timestamp of the most recent update request
update_deployment:
type: OS::Heat::SoftwareDeployment
properties:
actions:
- UPDATE
config: {get_resource: update_config}
server: {get_resource: my_server}
input_values:
update_after_time: {get_param: update_timestamp}
(A possible future enhancement is that if you keep a mapping between
previous input values and the system state after the corresponding update,
you could even automatically handle rollbacks in the event the user decided
to cancel the update.)
And now we should be able to trigger an update to all of our servers, in the
regular Heat dependency order, by simply (thanks to the fact that parameters
now keep their previous values on stack updates unless they're explicitly
changed) running a command like:
heat stack-update my_overcloud -f $TMPL -P update_timestamp=$(date)
(A future goal of Heat is to make specifying the template again optional
too... I don't think that change landed yet, but in this case we can always
obtain the template from Tuskar, so it's not so bad.)
Astute readers may have noticed that this does not actually solve our
problem. In reality groups of similar servers are deployed within
ResourceGroups and there are no dependencies between the members. So, for
example, all of the controller nodes would be updated in parallel, with the
likely result that the overcloud could be unavailable for some time even if
it is deployed with HA.
The good news is that a solution to this problem is already implemented in
Heat: rolling updates. For example, the controller node availability problem
can be solved by setting a rolling update batch size of 1. The bad news is
that rolling updates are implemented only for AutoscalingGroups, not
ResourceGroups.
Accordingly, I propose that we switch the implementation of
overcloud-without-mergepy from ResourceGroups to AutoscalingGroups. This
would be a breaking change for overcloud updates (although no worse than the
change from merge.py over to overcloud-without-mergepy), but that also means
that there'll never be a better time than now to make it.
I wonder if this is an opportunity to look at how we converge
AutoScalingGroup and ResourceGroup in Heat?
As long as it's not one of those insoluble opportunities.
No, of course - all I'm suggesting is now might not be a bad time to
enumerate the areas of divergence, and figure out a medium term plan
towards, uh, convergence ;)
It seems like the main barrier to transparent (non destructive)
substitution of
AutoScalingGroup for ResourceGroup is the resource naming (e.g it's a short
UUID vs an index derived name) - could we add a property to
AutoScalingGroup which allowed optionally to use index based naming, such
that switching from ResourceGroup to ASG in a stack-update wouldn't replace
all the group members?
I would say the main barrier is that you can't ever change a resource's type
without replacing it, and even the hacky workaround we have (abandon/adopt)
is not robust enough to actually use. Resource naming doesn't even make the
Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2
Thanks for the information, Vivek I’m not aware of any samples using neutronclient lbaas v2 I’m not familiar with Horizon project but will be glad to contribute in case of free cycles. Is there anything describing this work? Any tasks bank? Thanks, Evg From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Tuesday, April 07, 2015 7:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi Evgeny, We have just started working on Horizon lbaasv2 support. I have to sync up with my team on the time-line but it is not targeted for Kilo release. Since it is a major effort, we will need more hands. Let me know if anyone is interested to contribute. On a related note, Do we have a sample code which uses neutronclient lbaas v2 methods? That will greatly speedup our horizon integration. Thanks, Vivek From: Phillip Toohill phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 7:50 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hey Evgeny, I believe Vivek is working on Horizon lbaasv2 support. We werent given a timeline or anything but sounds like its being actively worked on. I would reach out to him to get better timelines if concerned. Phillip V. Toohill III Software Developer [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png] phone: 210-312-4366 mobile: 210-440-8374 From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com Sent: Tuesday, April 7, 2015 5:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi guys, LBaaS v2 has no horizon support as for now and I want to know if this work is planned to be done and , if yes, in what time frame. Is there a plan to develop it for Kilo or for L release? Thanks, Evg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
On 04/08/2015 09:12 AM, Flavio Percoco wrote: On 08/04/15 08:59 -0400, Doug Hellmann wrote: Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Just wanted to +1 the above. I've also considered pbr a packaging/install tool. Furthermore, I believe having it as a runtime requirement makes packagers life more complicated because that means pbr will obviously need to be added as a runtime requirement for that package. RDO actually patches out calls to pbr to avoid the runtime requirement, FWIW. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
On 04/08/2015 05:24 AM, Sean Dague wrote: On 04/08/2015 07:38 AM, Dmitry Tantsur wrote: On 04/08/2015 12:53 PM, Sean Dague wrote: On 04/08/2015 03:58 AM, Dmitry Tantsur wrote: On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Tempest shouldn't be the *only* test for a project API. The projects themselves need to take some ownership for their API getting full coverage with in tree testing, including whatever microversion strategy they are employing. Agreed, but in-tree testing is also not feasible with too many version. Even now we have 7 (1.0-1.6), if it continues, we'll have not less than 12 after L, 18 after M, etc. And we have to test every one of them for regressions at least occasionally, provided that we don't start to aggressively deprecated microversions. If we do start, then we'll start breaking people even more often, than we should. E.g. if someone writes a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will break, though maybe it can actually work with new API. I do not understand how in tree testing is not feasible. In tree you have insights into all the branching that occurs within code so can very clearly understand what paths aren't possible. It should be a lot more straight forward than external black box testing where that can't be assume. Exactly. The whole *point* of microversions was to allow the APIs to evolve in a backwards-compatible, structured and advertised way. The evolution of the APIs response and request payloads should be tested fully for each microversion added to the codebase -- in tree. -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack in the classroom
Hello Amrit I liked the idea of taking OpenStack to the classroom. Thank You for taking the initiative and sharing your knowledge of cloud computing and OpenStack with students. I have a suggestion, why don't you offer a MOOC http://www.google.co.in/url?sa=trct=jq=esrc=ssource=webcd=2cad=rjauact=8ved=0CCgQFjABurl=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMassive_open_online_courseei=dUIlVZ38D9iLuwTRo4HYDgusg=AFQjCNHB6aQWZ7LqZEhPhyoiZmfYso7Gbwsig2=O23q6eODL8CpmHFQo7KUyQbvm=bv.90237346,d.c2E, preparing video lectures and sharing it with world(not just educational institutions in Massachusetts and near Toronto). We can ask to various MOOC offering portals(like udacity.com, coursera.org etc) to add the course into their list of courses or may be let this course offered by OpenStack Foundation only. This will be really helpful for those who have never studied about cloud computing in their regular study courses curriculum and are new to OpenStack. Such students/listners will get well prepared and *sequential lectures* to read and learn about cloud computing and OpenStack rather than searching on web and reading about each new terms that they encounter while hacking in OpenStack or similar fields. The main reason why am I asking to prepare MOOC is that your effort will reach to whole world and also your knowledge sharing will stay alive forever in the form of video lectures :) Also even though I don't have much knowledge in cloud computing and OpenStack but if you need someone to work with you, I would love to be that. So please let me know if you need an assistant for such stuff. Thanks!!! Shaifali Agrawal about.me/shaifaliagrawal [image: Shaifali Agrawal on about.me] http://about.me/shaifaliagrawal On Tue, Apr 7, 2015 at 9:28 PM, Amrith Kumar amr...@tesora.com wrote: CS and EE schools today use open source software as the basis for a lot of coursework and as the practical example for several concepts. Most often the exemplar system is Linux. Yet if students are even taught about the cloud, they often learn about that other cloud company from Seattle. I think OpenStack is the ideal exemplar system for a whole lot of CS/EE courses. No matter what area of computer science you are interested in, there’s an OpenStack project (or in some cases several) that you can study. I think the fact that you can have the entire cloud on your laptop, source code and all, is incredibly powerful in the classroom. Not only can you see how the system works, but you can also tweak it or fix it if you find something to be wrong. Some students also learn about software development methodologies by contributing to a fictional open source project. Why do that when they can instead be contributing code to a real open source project? I think there’s a huge opportunity for us to take OpenStack in the Classroom (a longer post about my experience doing this last week is at http://www.tesora.com/openstack-in-the-classroom/). My thanks to dims and Kamesh Pemmaraju for helping me with this at short notice. Let us make (and I’m looking to the Foundation to support this as a formal initiative) it a priority to have every university offer courses on computer science and cloud computing with OpenStack as the exemplar system. Personally, I’m going to work with educational institutions in Massachusetts and near Toronto (where Tesora has offices, and where I tend to spend most of my time) to try and make available a course on cloud computing with OpenStack as the exemplar system. I’m going to make the materials, and offer to teach the course, and I will contribute the materials to the Foundation. So this is an open offer to any university in MA and near Toronto; if you want someone to develop and deliver a course on cloud computing, please let me know! I think we can all come together and take OpenStack to the Classrooms so that every graduating student interested in cloud computing has a working knowledge of OpenStack. Thanks, -amrith Amrith Kumar, Founder CTO [image: tesora-small] Mobile: 978-563-9590 Direct: 978-707-8010 x1002 Twitter: @amrithkumar http://www.twitter.com/amrithkumar Skype: amrith.skype *Check out our blog http://www.tesora.com/blog* *Twitter https://twitter.com/tesoracorp* *Facebook https://www.facebook.com/tesoracorp* *LinkedIn http://www.linkedin.com/company/parelastic* 125 CambridgePark Drive, Suite 400, https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MAhl=ensll=42.036922,-71.683501sspn=3.422779,6.696167oq=125+cahnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140t=mz=17 *Cambridge, MA 02140 https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MAhl=ensll=42.036922,-71.683501sspn=3.422779,6.696167oq=125+cahnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140t=mz=17* 4 Robert Speck Parkway, Suite 1500,
[openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow
I will not be available to chair or attend the L3 sub team meeting tomorrow. Are others okay with canceling the meeting? Let me know if you have something to discuss. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Keystone, python3 and python-ldap
Heya, Looking at keystone test requirements and the https://wiki.openstack.org/wiki/Python3 is there a plan for python-ldap ldappool ? I see some mentions on the mailing list, but not a concrete solution. It seems to me that both python-ldap ldappool could be replaced by ldap3 (previously known as python3-ldap, retro-fitted with python2.6+ support) https://ldap3.readthedocs.org/en/latest/welcome.html https://pypi.python.org/pypi/ldap3 It is licensed under LGPLv3, is that ok? Note that currently python-ldap license is quite iffy, and one of the optional deps is BSD-4-Clause which also not nice for everyone. Is it ok for me to work on transitioning to ldap3? -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] PTL Candidacy
Hi, I am johnthetubaguy on IRC. I would like to run for the OpenStack Compute (Nova) PTL position. I currently work as a Principal Engineer at Rackspace, focusing on software development for the Rackspace public cloud. Background == I started working with Nova in late 2010, working on a private cloud style packaging of XenServer and OpenStack at Citrix. Later in 2010, my efforts moved towards helping maintain the upstream XenServer support. In early 2013 I moved to Rackspace to work on their public cloud. Over the last few releases, I have been helping with some of the release management, running some nova meetings, blueprint/specs management and in various other Nova relating activities. I would like to build on this experience and help continue Nova’s evolution. Code Contributions == Its no secret that many contributors are finding it harder and harder to get their code merged into Nova. We need to ensure we maintain (ideally increase) code quality and consistency, but we also need to scale out our processes. Its a hard problem, but I am sure we can do better. I support the idea of moving to a kind of “tick-tock” release for Nova. Adopting this would mean Liberty has more room for new ‘features’, and the M release will have a similar focus on stability to Kilo. During Kilo, the focus on fixing bugs and working on fixing up some of the technical debt we have accrued. That of course, meant there were many features we were unable to merge, because we were focusing more on other things. There are some really promising ideas, and we need to start trying out some of these solutions very soon. I think a key part of why its hard to expand nova-core is because it currently means too much to be dropped from nova-core. We need that group to be more fluid. Process === Not all process is good, but some can be helpful to communication between such a large community. We are now better at agreeing priorities for a release, and following through on that. We are better at reviving, agreeing and documenting plans for features in specs. We are now making better use of dev ref to capture longer term work streams, and their aims. More importantly, we relaxed a lot of the nova-spec process for blueprints that don’t need that level of overhead. When we focus our review effort, such as with the trivial patch list, we have seen great results. I think we need to expand the groups of reviews that need immediate attention to include reviews that a sub group feels is now “ready”. As trust builds between the central team and the sub group, we can look at how much that can evolve to a more formal federated system, as the sub group gains trust. But I hope better ideas will come along that we can consider and look at adopting. The key thing, lets continue this evolution, so we can scale out the community, keep the quality high, but while keeping everyone productive. Users and Operators === The API v2.1 effort is a great start on the road towards better interoperability. This is a key step towards ensuring the compute API looks and feels the same regardless of what Nova deployment you are pointing at. I feel we need to be more upfront about what is known to work, and what is unknown. We started down this path for Hypervisor drivers, I feel we need to revive this effort, and look at other combinations: https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status We can look at defining how well tested particular combinations are, using a similar methodology to devcore. But the important thing is having open information on what is known to work. We are getting clear feedback from our users about some areas of the code that need attention. We need to continue to be responsive to those requests, and look at ways to improve that process. Conclusion == This email has got too long and writing is not my strong point. But for those who don’t know me, I hope it gives you a good idea about where I stand on some of the key issues facing the Nova community. Thanks for reading. johnthetubaguy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2
Hi, We briefly talked about it a few Neutron meetings back (LBaaS is now on demand) and created an etherpad to track things: https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases Susanne and I met with HP’s UX designer to work on the design for some flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the lead. Please check that etherpad for more information and feel free to update as things happen… Thanks, German From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Tuesday, April 07, 2015 9:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi Evgeny, We have just started working on Horizon lbaasv2 support. I have to sync up with my team on the time-line but it is not targeted for Kilo release. Since it is a major effort, we will need more hands. Let me know if anyone is interested to contribute. On a related note, Do we have a sample code which uses neutronclient lbaas v2 methods? That will greatly speedup our horizon integration. Thanks, Vivek From: Phillip Toohill phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 7:50 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hey Evgeny, I believe Vivek is working on Horizon lbaasv2 support. We werent given a timeline or anything but sounds like its being actively worked on. I would reach out to him to get better timelines if concerned. Phillip V. Toohill III Software Developer [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png] phone: 210-312-4366 mobile: 210-440-8374 From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com Sent: Tuesday, April 7, 2015 5:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi guys, LBaaS v2 has no horizon support as for now and I want to know if this work is planned to be done and , if yes, in what time frame. Is there a plan to develop it for Kilo or for L release? Thanks, Evg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] official clients and tempest
On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote: Since tempest no longer uses the official clients as a literal code dependency, except for the cli tests which are being removed, the clients have been dropping from requirements.txt. But when debugging issues uncovered by tempest, or when debugging tempest itself, it is useful to use the cli to check various things. I think it would be a good service to users of tempest to include the client libraries when tempest is installed on a machine. Is there a reason to not do this? i Umm, so that is not what requirements.txt is for, we should only put what is required to run the tempest in the requirements file. It's a package dependencies list, not a list of everything you find useful for developing tempest code. I get what you're going for but doing that as part of the tempest install is not the right place for it. We can put it as a recommendation in the developer documentation or have scripts somewhere which sets setups up a dev env or something. -Matt Treinish pgpJHRB3WudHt.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FWaaS iptables implementation
Hi Miyashita, The second rule is 'accept' on state being 'established' or 'related'. In case of ICMP, if a request has gone out from inside network, then the reply to that will match this rule. A new ICMP message initiated from outside will not match this rule. I hope I understood your question correctly. Let me know if this addresses your concern. Thanks, -Rajesh Mohan On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro miy...@jp.fujitsu.com wrote: Hi, I want to ask about FWaaS iptables rule implementation. firewall rule are deployed as iptables rules in network node , and ACCEPT target is set at second rule(*). Chain neutron-l3-agent-iv431d7bfbc (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED (*) 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 0 0 neutron-l3-agent-liD31d7bfbc all -- * * 0.0.0.0/00.0.0.0/0 Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP or other protocol such as UDP/TCP)? This causes some wrong scenario for example... [outside openstack cloud] --- Firewall(FWaaS) -- [inside openstack cloud] 1) admin create Firewall and create Filrewall rule accepting ICMP request from outside openstack cloud, and 2) ICMP request packets incoming from outside to inside, and 3) someday, admin detects that ICMP rule is security vulnerability and create Firewall rule blocking ICMP request from outside. but ICMP request packets still incoming due to ACCEPT rule(*), because ICMP connection still hit rule at second(*). Thanks. kazuhiro MIYASHITA __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] official clients and tempest
On 04/08/2015 02:36 PM, Matthew Treinish wrote: On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote: Since tempest no longer uses the official clients as a literal code dependency, except for the cli tests which are being removed, the clients have been dropping from requirements.txt. But when debugging issues uncovered by tempest, or when debugging tempest itself, it is useful to use the cli to check various things. I think it would be a good service to users of tempest to include the client libraries when tempest is installed on a machine. Is there a reason to not do this? i Umm, so that is not what requirements.txt is for, we should only put what is required to run the tempest in the requirements file. It's a package dependencies list, not a list of everything you find useful for developing tempest code. I was more thinking of users of tempest than developers of tempest, though it is useful to both. But we can certainly say that this is an issue for those who provide tempest to users. -David I get what you're going for but doing that as part of the tempest install is not the right place for it. We can put it as a recommendation in the developer documentation or have scripts somewhere which sets setups up a dev env or something. -Matt Treinish __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp
On Wed, Apr 8, 2015 at 7:59 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200: On 7 April 2015 at 05:11, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic bo...@pavlovic.me wrote: Jay, Not far, IMHO. 100ms difference in startup time isn't something we should spend much time optimizing. There's bigger fish to fry. I agree that priority of this task shouldn't be critical or even high, and that there are other places that can be improved in OpenStack. In other hand this one is as well big source of UX issues that we have in OpenStack.. For example: 1) You would like to run some command X times where X is pretty big (admins likes to do this via bash loops). If you can execute all of them for 1 and not 10 minutes you will get happier end user. +1 I'm fully in support of this effort. Shaving 100ms off the startup time of a frequently used library means that you'll save that 100ms over and over, adding up to a huge win. Another data point on how slow our libraries/CLIs can be: $ time openstack -h snip real0m2.491s user0m2.378s sys 0m0.111s pbr should be snappy - taking 100ms to get the version is wrong. I have always considered pbr a packaging/installation time tool, and not something that would be used at runtime. Why are we using pbr to get the version of an installed package, instead of asking pkg_resources? Doug -Rob I have no idea if one is better than the other, but I figured It was easy enough to post the change for keystoneclient: https://review.openstack.org/#/c/171720/ . - Brant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] official clients and tempest
On 04/08/2015 02:58 PM, David Kranz wrote: On 04/08/2015 02:36 PM, Matthew Treinish wrote: On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote: Since tempest no longer uses the official clients as a literal code dependency, except for the cli tests which are being removed, the clients have been dropping from requirements.txt. But when debugging issues uncovered by tempest, or when debugging tempest itself, it is useful to use the cli to check various things. I think it would be a good service to users of tempest to include the client libraries when tempest is installed on a machine. Is there a reason to not do this? i Umm, so that is not what requirements.txt is for, we should only put what is required to run the tempest in the requirements file. It's a package dependencies list, not a list of everything you find useful for developing tempest code. I was more thinking of users of tempest than developers of tempest, though it is useful to both. But we can certainly say that this is an issue for those who provide tempest to users. I'm in agreement with Matt here. Tempest requirements should be what Tempest actually requires. Installing the CLI is pretty easy, it's package installed in any Linux distro. apt-get, yum, or even pip install and you are off and running. I don't think having Tempest side effect dragging in the CLI tools is useful. Those should instead be something people install themselves. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] PTL Candidacy
confirmed On Wed, Apr 8, 2015 at 11:25 AM, John Garbutt j...@johngarbutt.com wrote: Hi, I am johnthetubaguy on IRC. I would like to run for the OpenStack Compute (Nova) PTL position. I currently work as a Principal Engineer at Rackspace, focusing on software development for the Rackspace public cloud. Background == I started working with Nova in late 2010, working on a private cloud style packaging of XenServer and OpenStack at Citrix. Later in 2010, my efforts moved towards helping maintain the upstream XenServer support. In early 2013 I moved to Rackspace to work on their public cloud. Over the last few releases, I have been helping with some of the release management, running some nova meetings, blueprint/specs management and in various other Nova relating activities. I would like to build on this experience and help continue Nova's evolution. Code Contributions == Its no secret that many contributors are finding it harder and harder to get their code merged into Nova. We need to ensure we maintain (ideally increase) code quality and consistency, but we also need to scale out our processes. Its a hard problem, but I am sure we can do better. I support the idea of moving to a kind of tick-tock release for Nova. Adopting this would mean Liberty has more room for new 'features', and the M release will have a similar focus on stability to Kilo. During Kilo, the focus on fixing bugs and working on fixing up some of the technical debt we have accrued. That of course, meant there were many features we were unable to merge, because we were focusing more on other things. There are some really promising ideas, and we need to start trying out some of these solutions very soon. I think a key part of why its hard to expand nova-core is because it currently means too much to be dropped from nova-core. We need that group to be more fluid. Process === Not all process is good, but some can be helpful to communication between such a large community. We are now better at agreeing priorities for a release, and following through on that. We are better at reviving, agreeing and documenting plans for features in specs. We are now making better use of dev ref to capture longer term work streams, and their aims. More importantly, we relaxed a lot of the nova-spec process for blueprints that don't need that level of overhead. When we focus our review effort, such as with the trivial patch list, we have seen great results. I think we need to expand the groups of reviews that need immediate attention to include reviews that a sub group feels is now ready. As trust builds between the central team and the sub group, we can look at how much that can evolve to a more formal federated system, as the sub group gains trust. But I hope better ideas will come along that we can consider and look at adopting. The key thing, lets continue this evolution, so we can scale out the community, keep the quality high, but while keeping everyone productive. Users and Operators === The API v2.1 effort is a great start on the road towards better interoperability. This is a key step towards ensuring the compute API looks and feels the same regardless of what Nova deployment you are pointing at. I feel we need to be more upfront about what is known to work, and what is unknown. We started down this path for Hypervisor drivers, I feel we need to revive this effort, and look at other combinations: https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status We can look at defining how well tested particular combinations are, using a similar methodology to devcore. But the important thing is having open information on what is known to work. We are getting clear feedback from our users about some areas of the code that need attention. We need to continue to be responsive to those requests, and look at ways to improve that process. Conclusion == This email has got too long and writing is not my strong point. But for those who don't know me, I hope it gives you a good idea about where I stand on some of the key issues facing the Nova community. Thanks for reading. johnthetubaguy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Launchpad] Fwd: How to correctly change the bug milestone...
The mail being forwarded was originally intended for MIrantis internal mailing list, but then I've realized that it fits as well to the general Openstack mailing list. -- Forwarded message -- From: Timur Sufiev tsuf...@mirantis.com Date: Wed, Apr 8, 2015 at 6:22 PM Subject: How to correctly change the bug milestone... To: mos-dev mos-...@mirantis.com ... or why we shouldn't use Launchpad at all Hello all! Recently thanks to our new LP reports tool I've discovered that we lost 3 bugs in MOS Horizon. Well, they weren't actually deleted, instead they were set to Won't fix in the Milestone/Series they were originally filed to. I've decided to find out what it takes to correctly change the bug milestone to not lose it. Here is the absolute minimum of steps tested on ~10 bugs I've just moved from 6.1 milestone to 7.0. 1. Nominate the bug for series 7.0 (and make sure it's also nominated for 6.1) 2. Change status in 6.1 to Won't fix 3. Refresh the page (it's important!) 4. Observe the new link in the rightmost column of the top row in a list of affected series - 'Mirantis Openstack 6.1' and change it to 'Mirantis Openstack 7.0'. 5. Repeat for whatever number of bugs you have for the milestone that's almost soft code-freezed. That's it! Now, you will see all the bugs (in my case, with 'horizon' tag, query https://bugs.launchpad.net/mos/+bugs?field.tag=horizon) in the standard Launchpad view, which wouldn't be the case if they were still tracked as of 'Mirantis Openstack 6.1' series which got Won't Fix status. Of course, you could also use LP Reports tool, but it's still slower than native LP UI due to a larger number of calls it makes. And frankly speaking, I'm eager to see Storyboard project ready to finally move away from this sordid piece of software called 'Launchpad'. -- Timur Sufiev -- Timur Sufiev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint
Kyle, I do understand it. My suggestions were related to timing and not related to the objectives of this meet-up, I do agree totally with you that we should get together to make a big push on the code and BPs and not to discuss and make more decisions. For the next coding sprint I will plan it better with my sponsor company, in the meantime let me apologize with you and the Neutron team because I will not be able to attend it in person but I will be in IRC and if available hangouts. Cheers, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, April 8, 2015 at 8:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Wed, Apr 8, 2015 at 10:14 AM, Edgar Magana edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote: Kyle, Thank you for your answers and also for organizing this coding sprint. I would like to rephrase my question as follows. If you are elected as Neutron PTL for the Liberty Cycle, would you consider to have either of the following options for the M cycle?: 1. Move the next coding sprint at least one month after the “M” summit 2. Having both a sprint coding and a formal mid-cycle meet-up I know how hard is to organize these sessions and I by no means wanted to change people plans for attending the one in June 2015. However, raising my concerns and suggestions early in the process seems to be a good approach. The Liberty coding spring is actually more than a month after the Liberty Summit, so the M coding spring would be the same. I don't think having a coding spring and a mid-cycle makes sense. In fact, I am against mid-cycles where the focus is not on code. Personally, we need to continue evolving the projects in OpenStack so decisions do not need to be made in person. Mid-cycles perpetuate the notion you have to go there and be present so you can be a part of the decision making process. Coding sprints are focused on actually writing code together. Thus, I won't support mid-cycles where decisions are expected to be made, but will continue to support coding sprints. Hope that makes sense. Thanks, Kyle Kind Regards, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, April 8, 2015 at 6:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Wed, Apr 8, 2015 at 1:22 AM, Edgar Magana edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote: Kyle and Neutron Team, Having the mid-cyle just one month after the Liberty summit does not really fit into the definition of “mid-cycle”. It feels like we are just getting up to speed on Liberty BPs when we need to get ready for three days of sprint coding. Would you consider to move this at least one month after? I really want to go but it feels to soon to request permission to my management team. Thanks for your concerns Edgar. I guess you're right, and I will stop calling this a mid-cycle, and instead just refer to it as a the Neutron Liberty Coding Sprint. It's actually worked out really well to have it close to the first milestone, we have a lot of things we can do very early in the cycle, getting together and pushing towards the first milestone with some of them will work well. Like I indicated to Russell, we'll do our best to facilitate remote attendees over IRC and maybe Hangouts while we're there. Thanks! Kyle Thanks, Edgar From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 7, 2015 at 6:39 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] Liberty mid-cycle coding sprint On Tue, Apr 7, 2015 at 8:15 AM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 04/07/2015 12:33 AM, Ben Pfaff wrote: On Mon, Apr 06, 2015 at 03:00:17PM -0500, Kyle Mestery wrote: I know we're not even at the Liberty Design Summit in Vancouver yet, but I wanted to take this time to announce the Neutron mid-cycle coding sprint for Liberty. HP has been gracious enough to offer to host at it's Fort Collins, CO offices. The dates are set for June 24-26, this is Wednesday-Friday. I've got additional
Re: [openstack-dev] [all] how to send messages (and events) to our users
From: Clint Byrum cl...@fewbar.com Sent: Wednesday, April 8, 2015 1:15 PM There's this: https://wiki.openstack.org/wiki/Cue Hmm, that looks interesting. Will read. I also want to point out that what I'd actually rather see is that all of the services provide functionality like this. Users would be served by having an event stream from Nova telling them when their instances are active, deleted, stopped, started, error, etc. Also, I really liked Sandy's suggestion to use the notifications on the backend, and then funnel them into something that the user can consume. The project they have, yagi, for putting them into atom feeds is pretty interesting. If we could give people a simple API that says subscribe to Nova/Cinder/Heat/etc. notifications for instance X, and put them in an atom feed, that seems like something that would make sense as an under-the-cloud service that would be relatively low cost and would ultimately reduce load on API servers. THIS! Yes. It would be so good to pull apart the state-machine that is Nova and just emit completed actions via notifications. Then, have something like TaskFlow externalize the orchestration. Do away with RPC-over-AMQP. And, anyone that is interested in the transitions can eavesdrop on the notifications. In our transition from StackTach.v2 to StackTach.v3 in production we simply cloned the notification feeds so the two systems can run in parallel*. No changes to OpenStack, no disruption of service. Later, we'll just kill off the v2 queues. -S * we did this in Yagi, since olso-messaging doesn't support multiple queues from one routing key. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and ACLs
On 4/8/15 11:17 AM, Kevin Benton wrote: What do you mean by ACLs? Is it anything similar to the following? https://review.openstack.org/#/c/132661/ Yes, our goals are very closely aligned with yours. And the rst doc as well as the messages on that thread file in a lot of gaps for me. Thanks. What's your plan going forward? rw2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] PTL Candidacy
confirmed On Wed, Apr 8, 2015 at 9:33 AM, Nikhil Manchanda nik...@manchanda.me wrote: I'd like to announce my candidacy for the PTL role of the Database (Trove) program for Liberty. I have been the PTL for Trove for Juno, and Kilo. During this time frame we made some really good progress on multiple fronts. In Kilo specifically, we completed the oslo-messaging integration work that we had started in Juno. We added support for GTID based mysql master-slave replication. We added support for new datastores including CouchDB, Vertica and DB2, and an initial implementation of clustering for Vertica as well. We furthered the testability of Trove, by moving all testing off of our deprecated 3rd party CI infrastructure and fully into OpenStack CI. We are continuing to make good progress updating and cleaning up our developer docs, install guide, and user documentation. For Liberty, I'd like us to keep working on clustering, with the end goal of being able to provision fully HA database clusters for the various datastores in Trove. This means a continued focus on clustering for datastores including a semi-synchronous mysql clustering solution. I'd also like to ensure that we make progress towards our goal of integrating trove with a monitoring solution to enable scenarios like auto-failover, which will be crucial to HA and a fully managed database service. Additionally, I'd like to keep our momentum going with regards to improving Trove testability documentation, and reviews. Some of the other work-items that I hope we can get to in Liberty include: - Separating out the Guest Agent from the other Trove services. - User access of datastore logs. - Scheduled Tasks for instances - especially backups. - Tackling control plane, guest agent, and datastore updates No PTL candidate email is complete without some commit / review stats, so here they are: * My Patches: https://review.openstack.org/#/q/owner:slicknik,n,z * My Reviews: https://review.openstack.org/#/q/-owner:slicknik+reviewer:slicknik,n,z Thanks for taking the time to make it this far, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and ACLs
My plan is to repropose that for Liberty. I will re upload it to the spec repo in the next couple of weeks. When I do that it would be great to get your feedback. Perhaps we can divide up the work or you can expand the model to things other than subnets. On Apr 8, 2015 9:43 AM, Rich Wellner r...@objenv.com wrote: On 4/8/15 11:17 AM, Kevin Benton wrote: What do you mean by ACLs? Is it anything similar to the following? https://review.openstack.org/#/c/132661/ Yes, our goals are very closely aligned with yours. And the rst doc as well as the messages on that thread file in a lot of gaps for me. Thanks. What's your plan going forward? rw2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][nova][ironic] How to run microversions tests on the gate
FWIW the Ironic microversion test patch mentioned on gerrit is only targeted at Tempest because thats where the API tests currenty live and from which our infra is setup to run. The eventual goal is to move all of tempest.api.baremetal.* to the Ironic tree, there's no reason why those proposed new tests wouldn't either. Those tests were designed to allow running against all available microversions or some configured subset, and to ensure tests for previous microversions run against newer. I think its perfectly feasible to test many microversions in tree or out, provided test coverage is kept sufficiently up to date as the APIs evolve. Adam On Wed, Apr 8, 2015 at 7:45 AM, Jay Pipes jaypi...@gmail.com wrote: On 04/08/2015 05:24 AM, Sean Dague wrote: On 04/08/2015 07:38 AM, Dmitry Tantsur wrote: On 04/08/2015 12:53 PM, Sean Dague wrote: On 04/08/2015 03:58 AM, Dmitry Tantsur wrote: On 04/08/2015 06:23 AM, Ken'ichi Ohmichi wrote: Hi, Now Nova and Ironic have implemented API microversions in Kilo. Nova's microversions are v2.1 - v2.3. Ironic's microversions are v1.1 - v1.6. Now Tempest is testing the lowest microversion on the gate, and Ironic's microversions test patch[1] is on the gerrit. Before merging the patch, I'd like to propose consistent test way for microversions of Nova and Ironic. My suggestion is the test target microversions are: * the lowest microversion * the biggest microversion, but don't use the keyword latest on a header and these microversions tests are operated on different gate jobs. The lowest microversion is already tested on check-tempest-dsvm-full or something, so this proposes just to add the biggest microversion job like check-tempest-dsvm-full-big-microversion. [background] In long-term, these microversions continue increasing and it is difficult to run Tempest for all microversions on the gate because of test workload. So I feel we need to select microversions which are tested on the gate for efficient testing. [the lowest microversion] On microversion mechanism, if a client *doesn't* specify favorite microversion in its request header, a Nova/Ironic server considers the request as the lowest microversion. So the lowest microversion is default behavior and important. I think we need to test it at least. [the biggest microversion] On microversion mechanism, if a client specify the keyword latest in its request header instead of microversion, a Nova/Ironic server works on the biggest microversion behavior. During the development, there is time lag between each project dev and Tempest dev. After adding a new API on a project, corresponding tests are added to Tempest in most cases. So if specifying the keyword latest, Tempest would not handle the request/response and fail, because Tempest can not catch the latest API changes until corresponding Tempest patch is merged. So it is necessary to have the target microversion config option in Tempest and pass specific biggest microversion to Tempest with openstack-infra/project-config. Any thoughts? Hi! I've already stated this point in #openstack-ironic and I'd like to reiterate: if we test only the lowest and the highest microversions essentially means (or at least might mean) that the other are broken. At least in Ironic only some unit tests actually touch code paths for versions 1.2-1.5. As we really can't test too many versions, I suggest we stop producing a microversion for every API feature feature change in L. No idea what to do with 1.2-1.5 now except for politely asking people not to use them :D Tempest shouldn't be the *only* test for a project API. The projects themselves need to take some ownership for their API getting full coverage with in tree testing, including whatever microversion strategy they are employing. Agreed, but in-tree testing is also not feasible with too many version. Even now we have 7 (1.0-1.6), if it continues, we'll have not less than 12 after L, 18 after M, etc. And we have to test every one of them for regressions at least occasionally, provided that we don't start to aggressively deprecated microversions. If we do start, then we'll start breaking people even more often, than we should. E.g. if someone writes a tool targeted at 1.1, and we deprecated 1.1 in M cycle, the tool will break, though maybe it can actually work with new API. I do not understand how in tree testing is not feasible. In tree you have insights into all the branching that occurs within code so can very clearly understand what paths aren't possible. It should be a lot more straight forward than external black box testing where that can't be assume. Exactly. The whole *point* of microversions was to allow the APIs to evolve in a backwards-compatible, structured and advertised way. The evolution of the APIs response and request payloads should be tested fully for each microversion added to the codebase -- in tree. -jay
Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Are you looking at scaling the numbers of tenants, Neutron routers, and tenant networks as you scale hosts and guests? I think this is a plausible way to grow. The compartmentalizations that comes with growing those things may make a difference in results. Thanks, Mike From: Neil Jerram neil.jer...@metaswitch.com To: openstack-dev@lists.openstack.org Date: 04/08/2015 12:29 PM Subject:[openstack-dev] [neutron] Neutron scaling datapoints? My team is working on experiments looking at how far the Neutron server will scale, with increasing numbers of compute hosts and VMs. Does anyone have any datapoints on this that they can share? Or any clever hints? I'm already aware of the following ones: https://javacruft.wordpress.com/2014/06/18/168k-instances/ Icehouse 118 compute hosts 80 Neutron server processes (10 per core on each of 8 cores, on the controller node) 27,000 VMs - but only after disabling all security/iptables http://www.opencontrail.org/openstack-neutron-at-scale/ 1000 hosts 5000 VMs 3 Neutron servers (via a load balancer) But doesn't describe if any specific configuration is needed for this. (Other than using OpenContrail! :-)) Many thanks! Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and ACLs
Yeah, sounds like a plan. FWIW, our target implementation will be Arista switches. rw2 On 4/8/15 11:52 AM, Kevin Benton wrote: My plan is to repropose that for Liberty. I will re upload it to the spec repo in the next couple of weeks. When I do that it would be great to get your feedback. Perhaps we can divide up the work or you can expand the model to things other than subnets. On Apr 8, 2015 9:43 AM, Rich Wellner r...@objenv.com mailto:r...@objenv.com wrote: On 4/8/15 11:17 AM, Kevin Benton wrote: What do you mean by ACLs? Is it anything similar to the following? https://review.openstack.org/#/c/132661/ Yes, our goals are very closely aligned with yours. And the rst doc as well as the messages on that thread file in a lot of gaps for me. Thanks. What's your plan going forward? rw2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] how to send messages (and events) to our users
On 08/04/15 16:38 +, Sandy Walsh wrote: From: Clint Byrum cl...@fewbar.com Sent: Wednesday, April 8, 2015 1:15 PM There's this: https://wiki.openstack.org/wiki/Cue Hmm, that looks interesting. Will read. I also want to point out that what I'd actually rather see is that all of the services provide functionality like this. Users would be served by having an event stream from Nova telling them when their instances are active, deleted, stopped, started, error, etc. Also, I really liked Sandy's suggestion to use the notifications on the backend, and then funnel them into something that the user can consume. The project they have, yagi, for putting them into atom feeds is pretty interesting. If we could give people a simple API that says subscribe to Nova/Cinder/Heat/etc. notifications for instance X, and put them in an atom feed, that seems like something that would make sense as an under-the-cloud service that would be relatively low cost and would ultimately reduce load on API servers. THIS! Yes. It would be so good to pull apart the state-machine that is Nova and just emit completed actions via notifications. Then, have something like TaskFlow externalize the orchestration. Do away with RPC-over-AMQP. Sorry for being nitpicky but, saying RPC-over-AMQP is way too generic. What AMQP version? On top of what technology? Considering all the issues OPs have with our current broker story, I think considering implementing this on top of pure AMQP (which is how that phrase reads) would not be good. If you meant RPC-over-messaging then I think you should just keep using oslo.nmessaging, which abstracts the problem of picking one broker. Unfortunately, this means users will need to consume this messages from the messaging source using oslo.messaging as well. I say unfortunately because I believe the API - or even the protocol - as it is exposed through this library - or simply the broker - is not something users should deal with. There are services that try to make this interaction simpler - yes, Zaqar. Flavio And, anyone that is interested in the transitions can eavesdrop on the notifications. In our transition from StackTach.v2 to StackTach.v3 in production we simply cloned the notification feeds so the two systems can run in parallel*. No changes to OpenStack, no disruption of service. Later, we'll just kill off the v2 queues. -S * we did this in Yagi, since olso-messaging doesn't support multiple queues from one routing key. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpYZZIXGaONk.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
