[openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.
Hello. My name is Rucia for Samsung SDS. I had in truouble in volume deleting. I am developing for supporting big data storage such as hadoop in lvm. it use as a full disk io for deleting of cinder lvm volume because of dd the high disk I/O affects the other hadoop instance on same host. If using dd for deleting the volume, it takes too much time for deleting of cinder lvm volume because of dd. Cinder volume is 200GB for supporting hadoop master data. When i delete cinder volume in using 'dd if=/dev/zero of $cinder-volume count=100 bs=1M' it takes about 30 minutes. So When I delete the volume, i added disk id scheduler, ionice. Thanks. https://blueprints.launchpad.net/cinder/+spec/when-deleting-volume-dd-performance ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] PTL electinos: voting
70% means we reached the quorum. That's cool ! OK, let's wait until the end of the poll then... Le 26 déc. 2013 06:00, Sergey Lukjanov slukja...@mirantis.com a écrit : Hey Sylvain, That's why I've already added several more days (Dec 25 - Jan 4). Are you expecting that someone will not be available for this period? Currently, we have 70% participation (poll have been started 18h ago). On Thu, Dec 26, 2013 at 2:27 AM, Sylvain Bauza sylvain.ba...@gmail.comwrote: Hi. I know that's pretty late for asking but could we consider having a quorum for voting ? As the election is running during vacations for most of the team, my concern is to make sure there are enough voters. Thanks, Sylvain Le 25 déc. 2013 11:08, Sergey Lukjanov slukja...@mirantis.com a écrit : Hi, voting for the PTL has been started and will continue till the 17:59 UTC January 4, 2014. You'll receive an email from Sergey Lukjanov (CIVS poll supervisor) slukja...@mirantis.com and subject Poll: Climate PTL Election. Thanks, have a good holidays. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Nova][API] Still need to update v2 API in Icehouse release
Hi, In Icehouse development, do we have some guidelines for nova api change? If I want to make some changes for nova api, do I need to update both v2 and v3 or just v3? There are some patches related to this, hope can get some comments from you. https://review.openstack.org/#/c/52733/ https://review.openstack.org/#/c/52867/ https://review.openstack.org/#/c/63853/ Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Complex query BP implementation
On Tue, Dec 24 2013, Jay Pipes wrote: I think you may have switched the above? Do you mean POST for sanity (short URLs) and GET for compatibility/standards? I don't think so, but maybe my sentence wasn't clear, sorry. I meant that in theory, the right verb to use would be GET as you pointed out. However, since using GET with a body is not a common practice, also supporting the POST verb as a replacement is a good idea for compatibility. Can you elaborate why this is not something Ceilometer would be interested in supporting? Would you prefer this kind of thing live in some other component? I don't think there's any gain in storing data that are tight to a consumer application. Storing and retrieving this kind of data, and then executing this as a higher cost than just executing a query. Storing this kind of data to be executed later looks to me like we would start building some sort of light PaaS platform. I really don't think that's needed at this stage. -- Julien Danjou // Free Software hacker / independent consultant // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Attach a external volume in openstack dashboard
Hello All, I have to attach new exrenal volumes(CloudByte's Elastistore volume) in OpenStack, can you guys please tell me, where I have to make changes in OpenStack??? Thanks Regards, Mardan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
Hi, thanks for the pointers! That's a good (re-)start indeed. Actually,we've been working for a while on different blueprints related to the idea to centrally store the quota information in keystone. Apparently, the interest in this was weak, and all related blue prints (store quota, domain quota and quota delegation) got closed and marked as obsolete, see eg: https://blueprints.launchpad.net/keystone/+spec/quota-delegation so a different approach is needed here. Comments are welcome! Kind regards, Ulrich 26.12.2013 08:51, Crystal wrote: Hi, Ulrich Currently nova has per-project-user quota support, which was implemented in Havana. We also got some similar thoughts about quota management, here is some related blueprints: https://blueprints.launchpad.net/nova/+spec/per-user-quotas https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management and there are also some discussions to store quota data in keystone you may be interested, https://lists.launchpad.net/openstack/msg11558.html we did not get much progress about multiple level user quota management for now, so i would be glad if you could move this on. Regard, Yingjun ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What should I do for resolving Tempest Failure in jenkins?
Hi all, I requested to review code about no hpet option. https://blueprints.launchpad.net/nova/+spec/add-no-hpet-option-into-guest-clock I expected that the code is verified. However, the code was failed for verifying tempest test. https://review.openstack.org/#/c/63769/ Actually, this is because of not my source codes but other codes. I add review comments recheck bug 1254890. However, re failed. In this case, I don't know I should I do. Could you tell me what should I do for passing tempest test? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Complex query BP implementation
On 12/26/2013 04:24 AM, Julien Danjou wrote: On Tue, Dec 24 2013, Jay Pipes wrote: I think you may have switched the above? Do you mean POST for sanity (short URLs) and GET for compatibility/standards? I don't think so, but maybe my sentence wasn't clear, sorry. I meant that in theory, the right verb to use would be GET as you pointed out. However, since using GET with a body is not a common practice, also supporting the POST verb as a replacement is a good idea for compatibility. Ah, OK, got it. Can you elaborate why this is not something Ceilometer would be interested in supporting? Would you prefer this kind of thing live in some other component? I don't think there's any gain in storing data that are tight to a consumer application. Storing and retrieving this kind of data, and then executing this as a higher cost than just executing a query. Storing this kind of data to be executed later looks to me like we would start building some sort of light PaaS platform. I really don't think that's needed at this stage. K, understood. If we stick with just GET, then I could implement the saved query using bit.ly ;) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Devstack Ceph
On Tue, Dec 24, 2013 at 4:49 AM, Sebastien Han sebastien@enovance.com wrote: Hello everyone, I’ve been working on a new feature for Devstack that includes a native support for Ceph. The patch includes the following: * Ceph installation (using the ceph.com repo) * Glance integration * Cinder integration (+ nova virsh secret) * Cinder backup integration * Partial Nova integration since master is currently broken. Lines are already there, the plan is to un-comment those lines later. * Everything works with Cephx (Ceph authentification system). Does anyone will be interested to see this going into Devstack mainstream? I'm likely in the minority here, but personally I don't like the idea of adding every driver/backend combination option directly in devstack. The issue I think you're trying to solve here is exactly what the driver_cert scripts and result submission are intended to address. If there's interest in creating an additional gating job that uses RBD as the backend that's in my mind a different discussion and definitely worth having. Cheers. Sébastien Han Cloud Engineer Always give 100%. Unless you're giving blood.” Phone: +33 (0)1 49 70 99 72 Mail: sebastien@enovance.com Address : 10, rue de la Victoire - 75009 Paris Web : www.enovance.com - Twitter : @enovance ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
Hi Ulrich, I already discussed with Tim during last Swiss meetup at CERN about how Climate could maybe help you on your use cases. There are still many things to discuss and a demo to run out so we could see if it match your needs. Basically, Climate is a new Stackforge project planning to implement resource reservations in OpenStack, including but not exhaustively Nova instances or nova-compute nodes. Resources can be allocated to either full tenants or to a specific user and can be provisioned now or in a certain period of time. About quotas, that's something not yet planned but kind of nice feature to have. Sorry but as I'm being in vacations, I don't have way to give you more inputs on this (typing from my very limited phone...) but should you be interested in, just give a shot and search on ML, you'll find previous pointers. -Sylvain Le 26 déc. 2013 08:04, Ulrich Schwickerath ulrich.schwicker...@cern.ch a écrit : Dear all, I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need. I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake. Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a Quota delegation: - The main resource manager determines the fractions of the resources for each customer - He allocates a quota to each customer by giving it to a computing coordinater which is nominated by the customer - the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment and so on. I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here: - There are people with different roles in this game: +- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager. Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources +- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person above him +- a normal user: persons with this role can only consume resources - several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a group concept here would be appropriate, in a way that roles are assigned to groups and people are assigned to the groups instead of assigning roles directly to individuals. - When I say Quota what I'm talking about is actually just a number, eventually assigned with some unit. It could be a static limit on a specific resource like number of VMs or the amount of memory or disk space, or it could be something different like computing performance or even something like a currency at the longer term - What is the right place to store such groups or roles ? What do people think ? We are currently only interested in limit settings for Nova. The described ideas could be implemented as part of Nova, or as an entirely independent external tool (which might be incorporated later). IMO the latter approach has some advantages but I'd like to hear peoples opinion about this. We'll have some man power available to work on the design and the implementation of this so I'd expect to see some rapid progress if everbody agrees that this is a useful thing to do. Thanks a lot for your comments/opinions! Kind regards, Ulrich ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Common SSH
Hi all, I'm surprised there is no common ssh library in oslo so I filed this blueprint[0]. I would be happy to address any comments/suggestions. [0] https://blueprints.launchpad.net/oslo/+spec/common-ssh-client -- Regards, Sergey Skripnick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should I do for resolving Tempest Failure in jenkins?
Hi, in my experience, if it not caused by your code, recheck more times. 在 2013年12月26日，21:29，한승진 yongi...@gmail.com 写道： Hi all, I requested to review code about no hpet option. https://blueprints.launchpad.net/nova/+spec/add-no-hpet-option-into-guest-clock I expected that the code is verified. However, the code was failed for verifying tempest test. https://review.openstack.org/#/c/63769/ Actually, this is because of not my source codes but other codes. I add review comments recheck bug 1254890. However, re failed. In this case, I don't know I should I do. Could you tell me what should I do for passing tempest test? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should I do for resolving Tempest Failure in jenkins?
Unfortunately this approach leads to forcing in code that may increase the bug in question, which will affect all developers. I suggest you evaluate the Jenkins logs carefully, and link to the timestamp in the logs were the failure occurred, in a comment on your patch. This enables reviewers to evaluate for themselves whether your patch is a likely contributor towards the bug. Be active in the irc channels for your project and for -qa. Ask in the channel if someone else can review your patch to see if it may be contributing to the bug. Consider speaking with the people who have contributed comments to the bug report as well as the person who is assigned to the bug, if there is one. Perhaps your Jenkins logs might help the folks working on the bug to identify the issue and offer a patch. You are also welcome and encouraged to work on solving the bug. It may be your patch is unrelated to the bug but your patch also might be a contributing factor. Ask some other developers for their opinion on your patch. Request that they comment on your patch to help other reviewers as well. Thanks, Anita. On 12/26/2013 01:24 PM, 柳东 wrote: Hi, in my experience, if it not caused by your code, recheck more times. 在 2013年12月26日，21:29，한승진 yongi...@gmail.com 写道： Hi all, I requested to review code about no hpet option. https://blueprints.launchpad.net/nova/+spec/add-no-hpet-option-into-guest-clock I expected that the code is verified. However, the code was failed for verifying tempest test. https://review.openstack.org/#/c/63769/ Actually, this is because of not my source codes but other codes. I add review comments recheck bug 1254890. However, re failed. In this case, I don't know I should I do. Could you tell me what should I do for passing tempest test? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What should I do for resolving Tempest Failure in jenkins?
On Thu, Dec 26, 2013 at 10:50 AM, Anita Kuno ante...@anteaya.info wrote: Unfortunately this approach leads to forcing in code that may increase the bug in question, which will affect all developers. I suggest you evaluate the Jenkins logs carefully, and link to the timestamp in the logs were the failure occurred, in a comment on your patch. This enables reviewers to evaluate for themselves whether your patch is a likely contributor towards the bug. Be active in the irc channels for your project and for -qa. Ask in the channel if someone else can review your patch to see if it may be contributing to the bug. Consider speaking with the people who have contributed comments to the bug report as well as the person who is assigned to the bug, if there is one. Perhaps your Jenkins logs might help the folks working on the bug to identify the issue and offer a patch. You are also welcome and encouraged to work on solving the bug. It may be your patch is unrelated to the bug but your patch also might be a contributing factor. Ask some other developers for their opinion on your patch. Request that they comment on your patch to help other reviewers as well. Thanks, Anita. On 12/26/2013 01:24 PM, 柳东 wrote: Hi, in my experience, if it not caused by your code, recheck more times. 在 2013年12月26日，21:29，한승진 yongi...@gmail.com 写道： Hi all, I requested to review code about no hpet option. https://blueprints.launchpad.net/nova/+spec/add-no-hpet-option-into-guest-clock I expected that the code is verified. However, the code was failed for verifying tempest test. https://review.openstack.org/#/c/63769/ Actually, this is because of not my source codes but other codes. I add review comments recheck bug 1254890. However, re failed. In this case, I don't know I should I do. Could you tell me what should I do for passing tempest test? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Worth noting that every Jenkins comment in Gerrit that posts a -1 or -2 links to https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures which contains information on what to do with test failures. If that document is lacking in some way please give details and we can update it (or feel free to update it yourself). Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Devstack Ceph
The motivation for Ceph support in my case was for my company to work on nova/glance RBD support and horizon integration with Ceph storage. The nova support for RBD backing store is not currently mature, and subject to a great deal of debate. Also boot from volume support used by Cinder/Ceph in the openstack dashboard has a terrible workflow and needs serious attention. Having an environment to easily stand up a stack for development with Ceph already configured has been a large help. Most of our development team (and other openstack developers with which I've spoken) don't have time or want to be bothered with learning the complicated setup routine involved with Ceph. They would however happily develop support against the API if it was already there and waiting for them. The plugin architecture of devstack felt like a nice place to add features and optional functionality that wouldn't impact users who didn't want or care about the extra features. I do understand your standpoint on the issue, and that you wouldn't want devstack to become a collection of broken un-maintained plugins for everything under the sun. But this was not intended for driver certification, rather to drive current active core feature development in openstack. Hope this at least gives everyone a better idea of my intent with the Blueprint. David Pippenger Sr. Devops Engineer Metacloud Inc. David Pippenger Sr. Devops Engineer Metacloud Inc. 1-213-253-8513 On Thu, Dec 26, 2013 at 9:16 AM, John Griffith john.griff...@solidfire.comwrote: On Tue, Dec 24, 2013 at 4:49 AM, Sebastien Han sebastien@enovance.com wrote: Hello everyone, I’ve been working on a new feature for Devstack that includes a native support for Ceph. The patch includes the following: * Ceph installation (using the ceph.com repo) * Glance integration * Cinder integration (+ nova virsh secret) * Cinder backup integration * Partial Nova integration since master is currently broken. Lines are already there, the plan is to un-comment those lines later. * Everything works with Cephx (Ceph authentification system). Does anyone will be interested to see this going into Devstack mainstream? I'm likely in the minority here, but personally I don't like the idea of adding every driver/backend combination option directly in devstack. The issue I think you're trying to solve here is exactly what the driver_cert scripts and result submission are intended to address. If there's interest in creating an additional gating job that uses RBD as the backend that's in my mind a different discussion and definitely worth having. Cheers. Sébastien Han Cloud Engineer Always give 100%. Unless you're giving blood.” Phone: +33 (0)1 49 70 99 72 Mail: sebastien@enovance.com Address : 10, rue de la Victoire - 75009 Paris Web : www.enovance.com - Twitter : @enovance ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
That quota staff has been following me from summit where we discussed that with Tim. Also, Ulrich, Sylvain is right - speaking about one piece of cake for one customer, our Climate (Reservation-as-a-Service) might help that. That piece might be some amount of hosts with specific (customer specific) characteristics, or just some already created and reserved virtual capacity measured in certain amount of VMs, volumes, etc. I'll be here in mailing list (and, probably, on our IRC channel #openstack-climate) during all holidays, so you are welcome! Now I'm working on better documentation for Climate just to give link and that's it, but now I may only explain that by mails and so on :) [Climate Launchpad] https://launchpad.net/climate [Hosts Reservation BP] https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api [Climate wiki (not compete one)] https://wiki.openstack.org/wiki/Resource-reservation-service On Thu, Dec 26, 2013 at 9:44 PM, Sylvain Bauza sylvain.ba...@gmail.comwrote: Hi Ulrich, I already discussed with Tim during last Swiss meetup at CERN about how Climate could maybe help you on your use cases. There are still many things to discuss and a demo to run out so we could see if it match your needs. Basically, Climate is a new Stackforge project planning to implement resource reservations in OpenStack, including but not exhaustively Nova instances or nova-compute nodes. Resources can be allocated to either full tenants or to a specific user and can be provisioned now or in a certain period of time. About quotas, that's something not yet planned but kind of nice feature to have. Sorry but as I'm being in vacations, I don't have way to give you more inputs on this (typing from my very limited phone...) but should you be interested in, just give a shot and search on ML, you'll find previous pointers. -Sylvain Le 26 déc. 2013 08:04, Ulrich Schwickerath ulrich.schwicker...@cern.ch a écrit : Dear all, I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need. I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake. Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a Quota delegation: - The main resource manager determines the fractions of the resources for each customer - He allocates a quota to each customer by giving it to a computing coordinater which is nominated by the customer - the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment and so on. I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here: - There are people with different roles in this game: +- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager. Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources +- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person above him +- a normal user: persons with this role can only consume resources - several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a group concept here would be appropriate, in a way that roles are assigned to groups and people are assigned to the groups instead of assigning roles directly to individuals. - When I say Quota what I'm talking about is actually just a number, eventually assigned with some unit. It could be a static limit on a specific resource like number of VMs or the amount of memory or disk space, or it could be something different like computing performance or even something like a currency at the longer term - What is the right place to
[openstack-dev] [Tempest][Solum] Writing functional tests in tempest style
Hi, In Solum project we decided to write functional\integration tests from the very beginning. Initially we used pecan testing framework, but after discussion we moved to standard HTTP client approach used in other projects. In order to simplify further integration with Tempest when Solum will apply for incubation, we started to think how to write functional test cases to minimize efforts for tempest integration in the future. After some learning of tempest code we figured out that direct usage of existing tempest code will be overcomplicated at this stage. We decided to use tempest approach and part of tempest framework independently from tempest itself. Here is a patch with the example how we use tempest approach by extracting core tempest parts and using them independently. https://review.openstack.org/#/c/64165/https://review.openstack.org/#/c/64165/ It will be great to have some feedback from tempest team. If this approach is valid it can be used by other projects who want to write tempest like tests without having whole huge tempest infrastructure. I think some part of tempest can be extracted and converted to some common testing framework, probably as a oslo library part. Thanks, Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] Delivering datastore logs to customers
From: Vipul Sabhaya vip...@gmail.commailto:vip...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, December 24, 2013 3:42 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove] Delivering datastore logs to customers On Mon, Dec 23, 2013 at 8:59 AM, Daniel Morris daniel.mor...@rackspace.commailto:daniel.mor...@rackspace.com wrote: Vipul, I know we discussed this briefly in the Wednesday meeting but I still have a few questions. I am not bought in to the idea that we do not need to maintain the records of saved logs. I agree that we do not need to enable users to download and manipulate the logs themselves via Trove ( that can be left to Swift), but at a minimum, I believe that the system will still need to maintain a mapping of where the logs are stored in swift. This is a simple addition to the list of available logs per datastore (an additional field of its swift location – a location exists, you know the log has been saved). If we do not do this, how then does the user know where to find the logs they have saved or if they even exist in Swift without searching manually? It may be that this is covered, but I don't see this represented in the BP. Is the assumption that it is some known path? I would expect to see the Swift location retuned on a GET of the available logs types for a specific instance (there is currently only a top-level GET for logs available per datastore type). The Swift location can be returned in the response to the POST/‘save’ operation. We may consider returning a top-level immutable resource (like ‘flavors’) that when queried, could return the Base path for logs in Swift. As long as we have a way to programmatically obtain and build the base path to the logs on a per instance basis, that should be fine. Logs are not meaningful to Trove, since you can’t act on them or perform other meaningful Trove operations on them. Thus I don’t believe they qualify as a resource in Trove. Multiple ‘save’ operations should not result in a replace of the previous logs, it should just add to what may already be there in Swift. I am also assuming in this case, and per the BP, that If the user does not have the ability to select the storage location in Swift of if this is controlled exclusively by the deployer. And that you would only allow one occurrence of the log, per datastore / instance and that the behavior of writing a log more than once to the same location is that it will overwrite / append, but it is not detailed in the BP. The location should be decided by Trove, not the user. We’ll likely need to group them in Swift by InstanceID buckets. I don’t believe we should do appends/overwrites - new Logs saved would just add to what may already exist. If the user chooses they don’t need the logs, they can perform the delete directly in Swift. Thanks, Daniel From: Vipul Sabhaya vip...@gmail.commailto:vip...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, December 20, 2013 2:14 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove] Delivering datastore logs to customers Yep agreed, this is a great idea. We really only need two API calls to get this going: - List available logs to ‘save’ - Save a log (to swift) Some additional points to consider: - We don’t need to create a record of every Log ‘saved’ in Trove. These entries, treated as a Trove resource aren’t useful, since you don’t actually manipulate that resource. - Deletes of Logs shouldn’t be part of the Trove API, if the user wants to delete them, just use Swift. - A deployer should be able to choose which logs can be ‘saved’ by their users On Wed, Dec 18, 2013 at 2:02 PM, Michael Basnight mbasni...@gmail.commailto:mbasni...@gmail.com wrote: I think this is a good idea and I support it. In todays meeting [1] there were some questions, and I encourage them to get brought up here. My only question is in regard to the tail of a file we discussed in irc. After talking about it w/ other trovesters, I think it doesnt make sense to tail the log for most datstores. I cant imagine finding anything useful in say, a java, applications last 100 lines (especially if a stack trace was present). But I dont want to derail, so lets try to focus on the deliver to swift first option. [1] http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-12-18-18.13.log.txt On Wed, Dec 18, 2013 at 5:24 AM, Denis Makogon dmako...@mirantis.commailto:dmako...@mirantis.com wrote: Greetings, OpenStack DBaaS
Re: [openstack-dev] [Tempest][Solum] Writing functional tests in tempest style
On 12/26/2013 03:34 PM, Georgy Okrokvertskhov wrote: Hi, In Solum project we decided to write functional\integration tests from the very beginning. ++! :) Initially we used pecan testing framework, but after discussion we moved to standard HTTP client approach used in other projects. In order to simplify further integration with Tempest when Solum will apply for incubation, we started to think how to write functional test cases to minimize efforts for tempest integration in the future. After some learning of tempest code we figured out that direct usage of existing tempest code will be overcomplicated at this stage. Yes, because unfortunately at this time, Tempest does not have a Python lib that can be import'd and used easily by other projects. We really should have such a thing, to make adding functional integration tests to non-integrated projects like Solum easier. We decided to use tempest approach and part of tempest framework independently from tempest itself. Here is a patch with the example how we use tempest approach by extracting core tempest parts and using them independently. https://review.openstack.org/#/c/64165/ https://review.openstack.org/#/c/64165/ It will be great to have some feedback from tempest team. If this approach is valid it can be used by other projects who want to write tempest like tests without having whole huge tempest infrastructure. I think the approach you've taken in the above review is the appropriate one at this time. It will make eventual inclusion into tempest when/if Solum is integrated quite easy. I think some part of tempest can be extracted and converted to some common testing framework, probably as a oslo library part. ++ Best, -jay Thanks, Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra][Devstack] Why aren't test-requirements.txt installed during test runs?
Hello all, When looking at a Solum patch in review [1], I wondered why Georgy needed to move fixtures, testresources, and httplib2 into requirements.txt [2] instead of test-requirements.txt, when those aforementioned dependencies are not for Solum itself, but rather the newly-introduced functional tests. When I asked Georgy on IRC, he mentioned that the gate doesn't install the dependencies in test-requirements.txt. I'm wondering why that is the case? Why bother having a test-requirements.txt at all, if we need to list test-specific dependencies in requirements.txt? Thanks in advance for answers! Best, -jay [1] https://review.openstack.org/#/c/64165 [2] https://review.openstack.org/#/c/64165/9/requirements.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Devstack] Why aren't test-requirements.txt installed during test runs?
On Thu, Dec 26, 2013 at 3:49 PM, Jay Pipes jaypi...@gmail.com wrote: Hello all, When looking at a Solum patch in review [1], I wondered why Georgy needed to move fixtures, testresources, and httplib2 into requirements.txt [2] instead of test-requirements.txt, when those aforementioned dependencies are not for Solum itself, but rather the newly-introduced functional tests. When I asked Georgy on IRC, he mentioned that the gate doesn't install the dependencies in test-requirements.txt. I'm wondering why that is the case? Why bother having a test-requirements.txt at all, if we need to list test-specific dependencies in requirements.txt? Thanks in advance for answers! Best, -jay [1] https://review.openstack.org/#/c/64165 [2] https://review.openstack.org/#/c/64165/9/requirements.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The gate is made up of two major types of tests. The first are self contained unittest like tests that rely on tox for their invocation and the second are the devstack-gate tests that use the devstack-gate project to configure and run tests. In both cases projects are installed from source (with pip install $PATH_TO_PROJECT iirc) which installs only the requirements.txt. These are the requirements needed to run the project but not to test it. In the tox run tests you will typically add the test-requirements.txt file to the testenv's dep list in order to get those dependencies installed for testing. In devstack-gate land no test-requirements are installed as these are functional/integration tests and should be tested as normally installed. So it depends on which test was having trouble. If it was something run by tox then tox.ini probably needs an update. This sounds like a problem with the devstack-gate tests which are trickier because it just does normal installs of projects before testing them and the test framework is expected to pull in the test dependencies as its normal dependencies. In this case I would probably update the job in question to install the test-requirements as part of the pre_test_hook in devstack-gate. The reason for the difference in lists is requirements.txt is the minimum to run the project. test-requirements.txt is the minimum needed to run the unittests, doc builds, lint checks, and so on. Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA][Neutron] About paramiko's SSHException: Error reading SSH protocol banner
I put together all the patches which we prepared for making parallel testing work, and ran a few times 'check experimental' on the gate to see whether it worked or not. With parallel testing, the only really troubling issue are the scenario tests which require to access a VM from a floating IP, and the new patches we've squashed together in [1] should address this issue. However, the result is that timeouts are still observed but with a different message [2]. I'm not really familiar with it, and I've never observed it in local testing. I wonder if it just happens to be the usual problem about the target host not being reachable, or if it is something specific to paramiko. Any hint would be appreciated, since from the logs is appears everything is wired properly. Salvatore [1] https://review.openstack.org/#/c/57420/ [2] http://logs.openstack.org/20/57420/40/experimental/check-tempest-dsvm-neutron-isolated-parallel/a74bdc8/console.html#_2013-12-26_22_51_31_817 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Devstack] Why aren't test-requirements.txt installed during test runs?
On 12/26/2013 07:06 PM, Clark Boylan wrote: On Thu, Dec 26, 2013 at 3:49 PM, Jay Pipes jaypi...@gmail.com wrote: Hello all, When looking at a Solum patch in review [1], I wondered why Georgy needed to move fixtures, testresources, and httplib2 into requirements.txt [2] instead of test-requirements.txt, when those aforementioned dependencies are not for Solum itself, but rather the newly-introduced functional tests. When I asked Georgy on IRC, he mentioned that the gate doesn't install the dependencies in test-requirements.txt. I'm wondering why that is the case? Why bother having a test-requirements.txt at all, if we need to list test-specific dependencies in requirements.txt? Thanks in advance for answers! Best, -jay [1] https://review.openstack.org/#/c/64165 [2] https://review.openstack.org/#/c/64165/9/requirements.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The gate is made up of two major types of tests. The first are self contained unittest like tests that rely on tox for their invocation and the second are the devstack-gate tests that use the devstack-gate project to configure and run tests. In both cases projects are installed from source (with pip install $PATH_TO_PROJECT iirc) which installs only the requirements.txt. These are the requirements needed to run the project but not to test it. In the tox run tests you will typically add the test-requirements.txt file to the testenv's dep list in order to get those dependencies installed for testing. In devstack-gate land no test-requirements are installed as these are functional/integration tests and should be tested as normally installed. OK, understood, thx for the detailed explanation. So it depends on which test was having trouble. If it was something run by tox then tox.ini probably needs an update. This sounds like a problem with the devstack-gate tests which are trickier because it just does normal installs of projects before testing them and the test framework is expected to pull in the test dependencies as its normal dependencies. In this case I would probably update the job in question to install the test-requirements as part of the pre_test_hook in devstack-gate. Ah, good thinking. That's indeed a good solution. Thank you, Clark! -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Devstack] Why aren't test-requirements.txt installed during test runs?
On Fri, Dec 27, 2013 at 7:30 AM, Jay Pipes jaypi...@gmail.com wrote: On 12/26/2013 07:06 PM, Clark Boylan wrote: On Thu, Dec 26, 2013 at 3:49 PM, Jay Pipes jaypi...@gmail.com wrote: Hello all, When looking at a Solum patch in review [1], I wondered why Georgy needed to move fixtures, testresources, and httplib2 into requirements.txt [2] instead of test-requirements.txt, when those aforementioned dependencies are not for Solum itself, but rather the newly-introduced functional tests. When I asked Georgy on IRC, he mentioned that the gate doesn't install the dependencies in test-requirements.txt. I'm wondering why that is the case? Why bother having a test-requirements.txt at all, if we need to list test-specific dependencies in requirements.txt? Thanks in advance for answers! Best, -jay [1] https://review.openstack.org/#/c/64165 [2] https://review.openstack.org/#/c/64165/9/requirements.txt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The gate is made up of two major types of tests. The first are self contained unittest like tests that rely on tox for their invocation and the second are the devstack-gate tests that use the devstack-gate project to configure and run tests. In both cases projects are installed from source (with pip install $PATH_TO_PROJECT iirc) which installs only the requirements.txt. These are the requirements needed to run the project but not to test it. In the tox run tests you will typically add the test-requirements.txt file to the testenv's dep list in order to get those dependencies installed for testing. In devstack-gate land no test-requirements are installed as these are functional/integration tests and should be tested as normally installed. OK, understood, thx for the detailed explanation. So it depends on which test was having trouble. If it was something run by tox then tox.ini probably needs an update. This sounds like a problem with the devstack-gate tests which are trickier because it just does normal installs of projects before testing them and the test framework is expected to pull in the test dependencies as its normal dependencies. In this case I would probably update the job in question to install the test-requirements as part of the pre_test_hook in devstack-gate. Ah, good thinking. That's indeed a good solution. Thank you, Clark! https://review.openstack.org/64226 Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [third-party-testing] Tests against vendor controller
Hi, We are developing a neutron plugin that works with our network controller. Do we need to have 2 sets of tests for the plugin i) tests that can be run against the network controller in our third party test setup (to vote on changes to the plugin) ii) tests that can be run in the OpenStack test setup Thanks, -hemanth ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Neutron] About paramiko's SSHException: Error reading SSH protocol banner
This might be completely off, in isolated creds, a private network is created for each tenant, while the test already creates its own private tenant network, thereby changing the behavior from how it was intended to, and how it is in simple mode. Could this be related? I have this patch addressing this - https://review.openstack.org/#/c/63886/ You could try and see if it makes any difference Yair - Original Message - From: Salvatore Orlando sorla...@nicira.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Friday, December 27, 2013 2:53:59 AM Subject: [openstack-dev] [QA][Neutron] About paramiko's SSHException: Error reading SSH protocol banner I put together all the patches which we prepared for making parallel testing work, and ran a few times 'check experimental' on the gate to see whether it worked or not. With parallel testing, the only really troubling issue are the scenario tests which require to access a VM from a floating IP, and the new patches we've squashed together in [1] should address this issue. However, the result is that timeouts are still observed but with a different message [2]. I'm not really familiar with it, and I've never observed it in local testing. I wonder if it just happens to be the usual problem about the target host not being reachable, or if it is something specific to paramiko. Any hint would be appreciated, since from the logs is appears everything is wired properly. Salvatore [1] https://review.openstack.org/#/c/57420/ [2] http://logs.openstack.org/20/57420/40/experimental/check-tempest-dsvm-neutron-isolated-parallel/a74bdc8/console.html#_2013-12-26_22_51_31_817 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
Anita, Did you get my email with my confirmation? Thanks, Edgar On Thu, Dec 19, 2013 at 4:02 PM, Edgar Magana emag...@plumgrid.com wrote: Anita, Fawad and Myself will be also attending. BTW. Fawad will require an invitation letter for visa. He will email you directly with that request. Thanks, Edgar On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno ante...@anteaya.info wrote: Okay time for a recap. What: Neutron Tempest code sprint Where: Montreal, QC, Canada When: January 15, 16, 17 2014 Location: I am about to sign the contract for Salle du Parc at 3625 Parc avenue, a room in a residence of McGill University. Time: 9am - 5am I am expecting to see the following people in Montreal in January: Mark McClain Salvatore Orlando Sean Dague Matt Trenish Jay Pipes Sukhdev Kapur Miguel Lavelle Oleg Bondarev Rossella Sblendido Emilien Macchi Sylvain Afchain Nicolas Planel Kyle Mestery Dane Leblanc Sumit Naiksatam Henry Gessau Don Kehn Carl Baldwin Justin Hammond Anita Kuno If you are on the above list and can't attend, please email me so I have an up-to-date list. If you are planning on attending and I don't have your name listed, please email me without delay so that I can add you and you get done what you need to get done to attend. I have the contract for the room and will be signing it and sending it in with the room deposit tomorrow. Monty has about 6 more hours to get back to me on this, then I just have to go ahead and do it. Caterer is booked and I will be doing menu selection over the holidays. I can post the intended, _the intended_ menu once I have decided. Soup, salad, sandwich - not glamourous but hopefully filling. If the menu on the day isn't the same as what I post, please forgive me. Unforeseen circumstances may crop up and I will do my best to get you fed. One person has identified they have a specific food request, if there are any more out there, please email me now. This covers breakfast, lunch and tea/coffee all day. Henry Gessau will be social convener for dinners. If you have some restaurant suggestions, please contact Henry. Organization of dinners will take place once we congregate in our meeting room. T-shirts: we decided that the code quality of Neutron was a higher priority than t-shirts. One person required a letter of invitation for visa purposes and received it. I hope the visa has been granted. Individuals arrangements for hotels seem to be going well from what I have been hearing. A few people will be staying at Le Nouvel Hotel, thanks for finding that one, Rosella. Weather: well you got me on this one. This winter is colder than we have had in some time and more snow too. So it will be beautiful but bring or buy warm clothes. A few suggestions: * layer your clothes (t-shirt, turtleneck, sweatshirt) * boots with removable liners (this is my boot of choice: http://amzn.to/19ddJve) remove the liners at the end of each day to dry them * warm coat * toque (wool unless you are allergic) I'm seeing them for $35, don't pay that much, you should be able to get something warm for $15 or less * warm socks (cotton socks and wool over top)- keep your feet dry * mitts (mitts keep my fingers warmer than gloves) * scarf If the weather is making you panic, talk to me and I will see about bringing some of my extra accessories with me. The style might not be you but you will be warm. Remember, don't lick the flagpole. It doesn't matter what your friends tell you. That's all I can think of, if I missed something, email me. Oh, and best to consider me offline from Jan.2 until the code sprint. Make sure you have all the information you need prior to that time. See you in Montreal, Anita. On 11/19/2013 11:31 AM, Rossella Sblendido wrote: Hi all, sorry if this is a bit OT now. I contacted some hotels to see if we could get a special price if we book many rooms. According to my research the difference in price is not much. Also, as Anita was saying, booking for everybody is more complicated. So I decided to booked a room for myself. I share the name of the hotel, in case you want to stay in the same place http://www.lenouvelhotel.com/ http://www.booking.com/hotel/ca/le-nouvel-spa.html?aid=318615label=postbooking_confemailpbsource=conf_email_hotel_nameet=UmFuZG9tSVYkc2RlIyh9YQkLIKuQhwqabGHP/3dl6rJzqy0AqLilEWRB9q2h3N7LbLpnopp78jpk3Zrw8QEON8/7uGk2Z4XEVgx0jMidsc7G6J6/mpIjb0/tpL+TyUzh/SougdT7JVfQN96wrY/Uz9Cu068o86et5KaL1N1ikBA2yvj25PBlFEF+/iBPj8Nq . It's close to the meeting room and the price is one of the best I have found. cheers, Rossella On Sat, Nov 16, 2013 at 7:39 PM, Anita Kuno ante...@anteaya.info wrote: On 11/16/2013 01:14 PM, Anita Kuno wrote: On 11/16/2013 12:37 PM, Sean Dague wrote: On 11/15/2013 10:36 AM, Russell Bryant wrote: On 11/13/2013 11:10 AM, Anita Kuno wrote: Neutron Tempest code sprint In the second week of
Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
Mark, We do not disagree with you. The main reason was indeed to onboard new developers in Neutron. I will help Fawad on his introduction before and after the sprint, therefore you should start seeing some code reviews and code commitments from him ASAP. Thanks, Edgar On Fri, Dec 20, 2013 at 1:42 PM, Mark McClain mark.mccl...@dreamhost.comwrote: Edgar- I’m a bit concerned about Fawad joining the sprint. He’s a new contributor who has never landed a patch in Neutron or Tempest. Closing the testing gaps with experienced devs is the goal of the Montreal sprint and I do not think we’ll have manpower to onboard new contributors (3 days is a really short time). While I’m happy to welcome more workers there, I do not want to waste his time or PLUMgrid’s resources. mark On Dec 19, 2013, at 7:02 PM, Edgar Magana emag...@plumgrid.com wrote: Anita, Fawad and Myself will be also attending. BTW. Fawad will require an invitation letter for visa. He will email you directly with that request. Thanks, Edgar On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno ante...@anteaya.info wrote: Okay time for a recap. What: Neutron Tempest code sprint Where: Montreal, QC, Canada When: January 15, 16, 17 2014 Location: I am about to sign the contract for Salle du Parc at 3625 Parc avenue, a room in a residence of McGill University. Time: 9am - 5am I am expecting to see the following people in Montreal in January: Mark McClain Salvatore Orlando Sean Dague Matt Trenish Jay Pipes Sukhdev Kapur Miguel Lavelle Oleg Bondarev Rossella Sblendido Emilien Macchi Sylvain Afchain Nicolas Planel Kyle Mestery Dane Leblanc Sumit Naiksatam Henry Gessau Don Kehn Carl Baldwin Justin Hammond Anita Kuno If you are on the above list and can't attend, please email me so I have an up-to-date list. If you are planning on attending and I don't have your name listed, please email me without delay so that I can add you and you get done what you need to get done to attend. I have the contract for the room and will be signing it and sending it in with the room deposit tomorrow. Monty has about 6 more hours to get back to me on this, then I just have to go ahead and do it. Caterer is booked and I will be doing menu selection over the holidays. I can post the intended, _the intended_ menu once I have decided. Soup, salad, sandwich - not glamourous but hopefully filling. If the menu on the day isn't the same as what I post, please forgive me. Unforeseen circumstances may crop up and I will do my best to get you fed. One person has identified they have a specific food request, if there are any more out there, please email me now. This covers breakfast, lunch and tea/coffee all day. Henry Gessau will be social convener for dinners. If you have some restaurant suggestions, please contact Henry. Organization of dinners will take place once we congregate in our meeting room. T-shirts: we decided that the code quality of Neutron was a higher priority than t-shirts. One person required a letter of invitation for visa purposes and received it. I hope the visa has been granted. Individuals arrangements for hotels seem to be going well from what I have been hearing. A few people will be staying at Le Nouvel Hotel, thanks for finding that one, Rosella. Weather: well you got me on this one. This winter is colder than we have had in some time and more snow too. So it will be beautiful but bring or buy warm clothes. A few suggestions: * layer your clothes (t-shirt, turtleneck, sweatshirt) * boots with removable liners (this is my boot of choice: http://amzn.to/19ddJve) remove the liners at the end of each day to dry them * warm coat * toque (wool unless you are allergic) I'm seeing them for $35, don't pay that much, you should be able to get something warm for $15 or less * warm socks (cotton socks and wool over top)- keep your feet dry * mitts (mitts keep my fingers warmer than gloves) * scarf If the weather is making you panic, talk to me and I will see about bringing some of my extra accessories with me. The style might not be you but you will be warm. Remember, don't lick the flagpole. It doesn't matter what your friends tell you. That's all I can think of, if I missed something, email me. Oh, and best to consider me offline from Jan.2 until the code sprint. Make sure you have all the information you need prior to that time. See you in Montreal, Anita. On 11/19/2013 11:31 AM, Rossella Sblendido wrote: Hi all, sorry if this is a bit OT now. I contacted some hotels to see if we could get a special price if we book many rooms. According to my research the difference in price is not much. Also, as Anita was saying, booking for everybody is more complicated. So I decided to booked a room for myself. I share the name of the hotel, in case you want to stay in the same place http://www.lenouvelhotel.com/
[openstack-dev] [Mistral] Evolving Mistral DSL: Data Flow
Hi all,
We’ve created another etherpad https://etherpad.openstack.org/p/mistral-poc
where we proposed additional Mistral features that are going to be reflected in
DSL. One of the most important things is Data Flow, it’s main idea, how it
matches to the initial workflow model and how it affects DSL. For convenience
I’ll provide the snippet from this etherpad about Data Flow in this email.
Data Flow
When we start a workflow we optionally set initial state of workflow execution
context (basically, just object model representable in JSON format).
Expose workflow execution context object accessible as $. in YAQL notation in
DSL.
A task optionally has a YAQL expression to select needed data from workflow
execution context. Selected data is considered task input and it gets
translated to parameters of corresponding REST action (http request body in
case of POST), AMQP action (as a JSON object) etc.
A task produces a result, the result gets merged into the context and the
context copy gets passed to the next task.
Context object is immutable and each task gets a copy of it to avoid needs to
use locking techniques. It gets passed to the next task with the task itself
via a message queue.
DSL snippet
Workflow:
tasks:
task1:
input: $.people.[$.age 30].address # Input selector expression
in YAQL notation that is used to select data needed for task1 from workflow
execution context
action: MyRest:action1
Services:
MyRest:
type: REST_API
parameters:
baseUrl: http://localhost:8988/my_service
actions:
action1:
parameters:
url: /action1
method: POST
Let's say the initial workflow execution context is as follows:
{
people: [
{
first_name: John,
last_name: Doe,
age: 32,
address: {
street: 25 Broadway Avenue,
city: Woodstock
}
},
{
first_name: Jane,
last_name: Doe,
age: 28,
address: {
street: 101 Jackson Street,
city: Gamilton
}
}
]}
Then input selector $.people.[$.age 30].address.city will evaluate to:
{
street: 25 Broadway Avenue,
city: Woodstock
}
And corresponding HTTP request will be:
http POST http://localhost:8988/my_service/action1
{
street: 25 Broadway Avenue,
city: Woodstock
}
In case of HTTP GET it will look like:
http GET
http://localhost:8988/my_service/action1?street=25+Broadway+Avenuecity=Woodstock
“
If you have any concerns or new ideas on how to improve what we’re proposing
please feel free to share with us.
Thanks.
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Neutron] About paramiko's SSHException: Error reading SSH protocol banner
At Fri, 27 Dec 2013 01:53:59 +0100, Salvatore Orlando wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; ISO-8859-1 (7bit)] I put together all the patches which we prepared for making parallel testing work, and ran a few times 'check experimental' on the gate to see whether it worked or not. With parallel testing, the only really troubling issue are the scenario tests which require to access a VM from a floating IP, and the new patches we've squashed together in [1] should address this issue. However, the result is that timeouts are still observed but with a different message [2]. I'm not really familiar with it, and I've never observed it in local testing. I wonder if it just happens to be the usual problem about the target host not being reachable, or if it is something specific to paramiko. Any hint would be appreciated, since from the logs is appears everything is wired properly. It seems that a TCP connection has been established but paramiko failed get data from the server in time. Does increasing paramiko timeout help? [1] https://review.openstack.org/#/c/57420/ [2] http://logs.openstack.org/20/57420/40/experimental/check-tempest-dsvm-neutron-isolated-parallel/a74bdc8/console.html#_2013-12-26_22_51_31_817 [1.2 text/html; ISO-8859-1 (quoted-printable)] [2 text/plain; us-ascii (7bit)] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] kwargs explanation should be used when we raise webob.exc.WSGIHTTPException
Hi, stackers, In review patch: https://review.openstack.org/64099, I found that if we use kwargs detail instead of explanation when we raise that WSGIHTTPException, the http response body will generate 'message' using default explanation, instead of what we expected which is detail=msg. So I register bug: https://bugs.launchpad.net/nova/+bug/1264328 and Kiyohiro Adach register https://bugs.launchpad.net/cinder/+bug/1264424 to identify this problem However, in https://review.openstack.org/#/c/64230/, Huang Zhiteng mentioned that: ``` John mentioned this a few times, some customers may reply on this 'not-so-correct' API behavior for their automation. I'm not sure how changes like this will affect them. ``` So I want to know what is the right action we should take, IMHO, we should fix all of those statements in master branch, which means: - raise webob.exc.HTTPXXX(_(message)) - raise webob.exc.HTTPXXX(detail=_(message)) should be replaced with raise webob.exc.HTTPXXX(explanation=_(message)) What your opinion? Thanks -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Evolving Mistral DSL: Conditional transitions
Hi,
This is an additional email to continue discussion about new Mistral DSL
capabilities. This time about conditional transitions and task dependencies.
Here’s the link to the corresponding etherpad:
https://etherpad.openstack.org/p/mistral-poc.
For convenience, I’m providing the snippet about conditional transitions right
in this message.
Conditional Transitions
Option #1 ('requires' with condition)
In this case we add additional optional condition in dependencies declaration.
task1 # task1 doesn't have dependencies
action: MyRest:action1
task2:
requires: task1 # task2 is allowed to run if task1 has
finished with success
action: MyRest:action2
task3:
requires: # task3 is allowed to run if task1
and task2 have finished and corresponding conditions are true
task1: $.value1 = 34
task2: $.value2 = 245
action: MyRest:action3
task4:
requires: [task2, task3] # task4 is allowed to run if task2 and
task3 has finished with success
action: MyRest:action4
Option #2 (direct transition)
In this case after task completion we decided what to do next depending on task
result.
task1:
action: MyRest:action1
SUCCESS:
- task2 # If task1 has finished with success then start task2
- task3: $.value1 == 123 # If after completion of task1 variable
value1 in the context equals to 123 then start task3
ERROR:
- task10 # If task1 has finished with error then start task10
Option #3 (hybrid of 'requires' and direct transitions)
In this case we can specify both requires and direct transitions. In the
example below task3 starts only when task1 and task2 have finished. Therefore
task2 is an implicit dependency of task3 since task1 initiated execution of
task2. It means that a task can start only if the entire sub-workflow initiated
by requires clause has finished.
task1:
action: MyRest:action1
SUCCESS
- task2
task2:
action: MyRest:action2
task3:
action: MyRest:action3
requires:
task1: $.value1 = 34
SUCCESS:
task4: '$.value1 == 123'
Note that we’re now considering 3 options to proceed with and our current
preference is option #3 (mix of ‘requires’ and direct transitions) since it
would give a lot of flexibility for designing real life workflows. In some
cases it would be more convenient to describe a business process using task
dependencies and in other cases use direct conditional transitions if
“straightforward” flow definition is preferred.
Regardless of the option described here a user would start new workflow
execution with specifying a particular task in a graph.
As always, we would like to get your feedback on this.
Thanks!
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Nova][API] Still need to update v2 API in Icehouse release
On Thu, Dec 26, 2013 at 1:03 AM, Jay Lau jay.lau@gmail.com wrote: Hi, In Icehouse development, do we have some guidelines for nova api change? If I want to make some changes for nova api, do I need to update both v2 and v3 or just v3? For every new extension to the v2 API we require the equivalent change to the v3 api, so that there is nothing in v2 that V3 doesn't support. But requiring the opposite doesn't make any sense to me, and seems like a waste of human resources. https://etherpad.openstack.org/p/icehouse-summit-nova-v3-api says we want to freeze the v2 api at icehouse-2, a plan which I full support. There are some patches related to this, hope can get some comments from you. https://review.openstack.org/#/c/52733/ https://review.openstack.org/#/c/52867/ https://review.openstack.org/#/c/63853/ Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
