Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent
On 03/26/2016 12:27 PM, Steven Dake (stdake) wrote: Hey fellow PTLs and core reviewers of those projects, Kolla at present deploys the compute kit, and some other services that folks have added over time including other projects like Ironic, Heat, Mistral, Murano, Magnum, Manilla, and Swift. One of my objectives from my PTL candidacy was to deploy the big tent, and I saw how we were not super successful as I planned in Mitaka at filling out the big tent. While the Kolla core team is large, and we can commit to maintaining big tent projects that are deployed, we are at capacity every milestone of every cycle implementing new features that the various big tent services should conform to. The idea of a plugin architecture for Kolla where projects could provide their own plugins has been floated, but before we try that, I'd prefer that the various teams in OpenStack with an interest in having their projects consumed by Operators involve themselves in containerizing their projects. Again, once the job is done, the Kolla community will continue to maintain these projects, and we hope you will stay involved in that process. It takes roughly four 4 hour blocks to learn the implementation architecture of Kolla and probably another 2 4 hour blocks to get a good understanding of the Kolla deployment workflow. Some projects (like Neutron for example) might fit outside this norm because containerizing them and deploying them is very complex. But we have already finished the job on what we believe are the hard projects. My ask is that PTLs take responsibility or recruit someone from their respective community to participate in the implementation of Kolla deployment for their specific project. I'll take on Keystone, but only if you promise to stop using "ask" as a noun and instead use ye olde English "Request" in its place. Only with your help can we make the vision of a deployment system that can deploy the big tent a reality. Regards -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 __ 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] [kolla] gate failures
Currently the Kolla gate is completely busted. I have spent today fixing it here: https://review.openstack.org/#/c/297945/ What this means is any patch that has been submitted in abut the past 48 hours that has gate failures needs rechecks applied to it once the above merges. The above review will also have to be backported to mitaka and liberty since the images have changed. The speculation from openstack-infra is securepath was introduced to sudo, so sudo -E results in a reset of the path. There is no other way to fix this problem - I've tried everything I could think of. I realize with the upcoming Easter holiday many folks may not be working - so feel free to ack that at your leisure. I'd ask core reviewers not to approve any changes until the gate fix patch is merged so we don't end up with broken software. Thanks -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] [Tricircle] Using the reserved keywords reserved as field name
Hi, Shinobu, RPC bottlenect will be mostly in bottom openstack, ie, current openstack, there quite lot rpc messages(and frequence) a better RPC protocol is definitely great help. In each openstack summit, there are some topics about message bus performance tunning :) currently in Tricircle only one rpc message for configuring the cross openstack L3 bridging network. There will be very few and not frequent RPC message in Tricircle even in the future, these async tasks mainly for better user experience so that the response to end user as fast as possible. Sent from HUAWEI AnyOffice 发件人：shinobu.kj 收件人：openstack-dev, 时间：2016-03-26 18:13:11 主题:Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name Hi Chaoyi, Thank you for the pointer. I'm also researching privately how we can improve RPC protocol reasonably like HTTP2. It's quite easy to foreseen that it would be bottleneck, and be able not to realize what the Tricircle is trying to do. Honestly it's already bottleneck. Cheers, Shinobu On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: > Hi, Shinobu, > > This BP is a good entrance for Tricircle source code, this BP listed the all > basic patches building Tricircle from scratches. > > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > > Best Regards > Chaoyi Huang ( Joe Huang ) > > > -Original Message- > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > Sent: Saturday, March 26, 2016 2:39 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved as > field name > > Hi Team, > > In the Tricircle database, there are three tables having a field name which > the MySQL (MariaDB) has as one of the reserved keywords. [1] > > Table Name: > aggregate_metadata > instance_type_extra_specs > quality_of_service_specs > > Field Name: > key > > I think it would not be best practice to use any reserved word by the any > system because it could cause bug once the component is bigger. > > What do you think? > > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > > Cheers, > Shinobu > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __ > 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 -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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] Gating scripts in different TLD
Hey folks, Warning - this is pure gold plating :) I'd like to see our gating tools in the test directory, rather then the tools directory. I was thinking kolla/test/gate as the TLD for all gating related scripts. The work would be something like: Modify infrastructure gating to test for the existence of the gate tools in kolla/test/gate, of there, use those, otherwise use existing gate tools Git mv the gate tools to kolla/test/gate as to not lose important commit history of these tools of which Sam Yaple is the primary author Backport the git mv to stable/mitaka and stable/liberty Modify project-config to remove the directory test and default to kolla/tests/gate Anyone in opposition, assuming the gate isn't broken along the way? I'd like to introduce more gates related to reconfigure and upgrade and this work helps isolate that work from the actual tools people use in their daily work. Regards -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] How does tempest read in the variables defined in tempest.conf?
Hi, To run a multi-region scenario you need to have both regions deployed before a tempest run is started, so you would need a extra configuration items. But I'm not convinced that would be in scope for tempest - there's no single way to deploy multiple regions. To run the same scenario tests against multiple regions (or clouds) you could have multiple tempest folders (use "tempest init" to create them) or you could have a single folder and point tempest to a different configuration file, depending on whether you wish to keep your testr db separated per region or not. In any case you'll need multiple config files. You can use a template config and change only the bits that you need using tools like crudini or jinja2 templates (if you use ansible). Andrea On Fri, 25 Mar 2016 5:18 pm Danny Choi (dannchoi), wrote: > Hi, > > There are variables defined in the tempest.conf. How does tempest read > them and use them in the tests? > > I’m trying to write scenario tests in multiple regions. > > Under tempest.conf: > > [identity] > > Region = RegionOne > > > [compute] > > image_ref = b6f85abb-c582-40e4-ad18-5a01431a6bfd > > image_ref_alt = b6f85abb-c582-40e4-ad18-5a01431a6bfd > > [network] > > public_network_id = 51efe3a5-390f-4a40-a480-8aa41d704c69 > > > I’m thinking to change these variables within the test on the fly to run > test within that particular region > > (region name, image id, public network id). > > > My question is what tempest variables uses these conf variables? > > > Is this the right approach or there is a better way to do it? > > > Thanks, > > Danny > __ > 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] [kolla] Gift from the OpenStack foundation
Hello core reviewers, If you will be at summit please attend one of our design or fishbowl sessions for gift distribution. If you have been in the past or currently are a core reviewer in the Kolla project and won't make summit, the foundation (or HP, not sure which) has a gift of nominal value for each of you. I would like the gift to remain a surprise, so I'll ship everyone's gift out prior to my departure for Summit so hopefully you will receive it at about the same time as folks on the core review team at summit receive it. Please email me privately std...@cisco.com with the tagline [core-reviewer-gift] along with your mailing address as expected by the US Postal service. If your in a country other then the United States, don't expect me to figure out how to make your address fit the postal service's requirements - please use the internet to sort that part out ;) I will mark the value of the gift on any required documentation as $3 USD because that is probably what they cost to produce :) As such, you may have to pay some minimal import duties if your outside the US. Thanks -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
[openstack-dev] [ptl][kolla][release] Deploying the big tent
Hey fellow PTLs and core reviewers of those projects, Kolla at present deploys the compute kit, and some other services that folks have added over time including other projects like Ironic, Heat, Mistral, Murano, Magnum, Manilla, and Swift. One of my objectives from my PTL candidacy was to deploy the big tent, and I saw how we were not super successful as I planned in Mitaka at filling out the big tent. While the Kolla core team is large, and we can commit to maintaining big tent projects that are deployed, we are at capacity every milestone of every cycle implementing new features that the various big tent services should conform to. The idea of a plugin architecture for Kolla where projects could provide their own plugins has been floated, but before we try that, I'd prefer that the various teams in OpenStack with an interest in having their projects consumed by Operators involve themselves in containerizing their projects. Again, once the job is done, the Kolla community will continue to maintain these projects, and we hope you will stay involved in that process. It takes roughly four 4 hour blocks to learn the implementation architecture of Kolla and probably another 2 4 hour blocks to get a good understanding of the Kolla deployment workflow. Some projects (like Neutron for example) might fit outside this norm because containerizing them and deploying them is very complex. But we have already finished the job on what we believe are the hard projects. My ask is that PTLs take responsibility or recruit someone from their respective community to participate in the implementation of Kolla deployment for their specific project. Only with your help can we make the vision of a deployment system that can deploy the big tent a reality. Regards -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] [kolla][vote] deprecation of icehosue/juno/kilo branches
A majority was reached so closing voting early and removing these branches. Regards -steve From: Steven Dake mailto:std...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 25, 2016 at 8:36 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches Hey folks, These branches are essentially unmaintained and we have completely given up on them. That's ok - they were paths of our development. I didn't really want to branch them in the first place, but the community demanded it, so I delivered that :) Now that our architecture is fairly stable in liberty and mitaka, I think it makes sense to do the following 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol 2. Ask infrastructure to remove the branches from git This is possible; I have just verified in openstack-infra. I'd like a vote from the core review team. If you would like to see the kilo branch stay, please note that, and if there is a majority on icehosue/juno but not kilo I'll make the appropriate arrangements with openstack-infra. I will leave voting open for 1 week until Saturday April 2nd. I will close voting early if there is a majority vote. Regards -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] [Tricircle] Using the reserved keywords reserved as field name
Thanks Shinobu, I quite like the gRPC idea and we could continue to discuss and work on it :) On Sat, Mar 26, 2016 at 11:38 PM, Shinobu Kinjo wrote: > Hi Zhipeng, > > I've not elaborate on gRPC in detail at all. > > What I meant about one of possibilities is that, since gRPC was > designed for fully distributed computing system, the features of this > framework would be available in any kind of distributed computing > system potentially. > Of course it may be necessary to build a new feature of infrastructure > to make use of it, which is quite challenge and would cause a big > change on some layer. But since the OpenStack wouldn't stop growing > because of demands by end-users (I guess), it's worth thinking of that > features for our future. > > Cheers, > Shinobu > > > On Sat, Mar 26, 2016 at 9:48 PM, Zhipeng Huang > wrote: > > Great:) Do you have any more thoughts on that ? > > > > It might need both Tricircle and bottom OpenStack entity to deploy gRPC > > server and client, while it is ok for Tricircle, it is not easy to > mandate > > gRPC endpoints as part of official OpenStack functionality. > > > > The whole point about Tricircle is to ensure Users could manage multiple > > cloud via normal OpenStack API. > > > > Or shall we only use gRPC endpoints internally in Tricircle ? That is to > say > > to use it between gateways and Xjobs > > > > On Sat, Mar 26, 2016 at 8:11 PM, Shinobu Kinjo > wrote: > >> > >> Yes, that's one of possibilities. > >> > >> Cheers, > >> Shinobu > >> > >> On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang > >> wrote: > >> > any possible that we use gRPC for Tricircle ? > >> > > >> > On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo > >> > wrote: > >> >> > >> >> Hi Chaoyi, > >> >> > >> >> Thank you for the pointer. > >> >> I'm also researching privately how we can improve RPC protocol > >> >> reasonably like HTTP2. > >> >> It's quite easy to foreseen that it would be bottleneck, and be able > >> >> not to realize what the Tricircle is trying to do. > >> >> Honestly it's already bottleneck. > >> >> > >> >> Cheers, > >> >> Shinobu > >> >> > >> >> On Sat, Mar 26, 2016 at 6:31 PM, joehuang > wrote: > >> >> > Hi, Shinobu, > >> >> > > >> >> > This BP is a good entrance for Tricircle source code, this BP > listed > >> >> > the > >> >> > all basic patches building Tricircle from scratches. > >> >> > > >> >> > > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > >> >> > > >> >> > Best Regards > >> >> > Chaoyi Huang ( Joe Huang ) > >> >> > > >> >> > > >> >> > -Original Message- > >> >> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > >> >> > Sent: Saturday, March 26, 2016 2:39 PM > >> >> > To: OpenStack Development Mailing List (not for usage questions) > >> >> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords > >> >> > reserved as field name > >> >> > > >> >> > Hi Team, > >> >> > > >> >> > In the Tricircle database, there are three tables having a field > name > >> >> > which the MySQL (MariaDB) has as one of the reserved keywords. [1] > >> >> > > >> >> > Table Name: > >> >> > aggregate_metadata > >> >> > instance_type_extra_specs > >> >> > quality_of_service_specs > >> >> > > >> >> > Field Name: > >> >> > key > >> >> > > >> >> > I think it would not be best practice to use any reserved word by > the > >> >> > any system because it could cause bug once the component is bigger. > >> >> > > >> >> > What do you think? > >> >> > > >> >> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > >> >> > > >> >> > Cheers, > >> >> > Shinobu > >> >> > > >> >> > -- > >> >> > Email: > >> >> > shin...@linux.com > >> >> > GitHub: > >> >> > shinobu-x > >> >> > Blog: > >> >> > Life with Distributed Computational System based on OpenSource > >> >> > > >> >> > > >> >> > > >> >> > > __ > >> >> > 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 > >> >> > >> >> > >> >> > >> >> -- > >> >> Email: > >> >> shin...@linux.com > >> >> GitHub: > >> >> shinobu-x > >> >> Blog: > >> >> Life with Distributed Computational System based on OpenSource > >> >> > >> >> > >> >> > __ > >> >> OpenStack Development Mailing List (not for usage questions) > >> >> Unsubscribe: > >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> >> http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name
Hi Zhipeng, I've not elaborate on gRPC in detail at all. What I meant about one of possibilities is that, since gRPC was designed for fully distributed computing system, the features of this framework would be available in any kind of distributed computing system potentially. Of course it may be necessary to build a new feature of infrastructure to make use of it, which is quite challenge and would cause a big change on some layer. But since the OpenStack wouldn't stop growing because of demands by end-users (I guess), it's worth thinking of that features for our future. Cheers, Shinobu On Sat, Mar 26, 2016 at 9:48 PM, Zhipeng Huang wrote: > Great:) Do you have any more thoughts on that ? > > It might need both Tricircle and bottom OpenStack entity to deploy gRPC > server and client, while it is ok for Tricircle, it is not easy to mandate > gRPC endpoints as part of official OpenStack functionality. > > The whole point about Tricircle is to ensure Users could manage multiple > cloud via normal OpenStack API. > > Or shall we only use gRPC endpoints internally in Tricircle ? That is to say > to use it between gateways and Xjobs > > On Sat, Mar 26, 2016 at 8:11 PM, Shinobu Kinjo wrote: >> >> Yes, that's one of possibilities. >> >> Cheers, >> Shinobu >> >> On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang >> wrote: >> > any possible that we use gRPC for Tricircle ? >> > >> > On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo >> > wrote: >> >> >> >> Hi Chaoyi, >> >> >> >> Thank you for the pointer. >> >> I'm also researching privately how we can improve RPC protocol >> >> reasonably like HTTP2. >> >> It's quite easy to foreseen that it would be bottleneck, and be able >> >> not to realize what the Tricircle is trying to do. >> >> Honestly it's already bottleneck. >> >> >> >> Cheers, >> >> Shinobu >> >> >> >> On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: >> >> > Hi, Shinobu, >> >> > >> >> > This BP is a good entrance for Tricircle source code, this BP listed >> >> > the >> >> > all basic patches building Tricircle from scratches. >> >> > >> >> > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless >> >> > >> >> > Best Regards >> >> > Chaoyi Huang ( Joe Huang ) >> >> > >> >> > >> >> > -Original Message- >> >> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] >> >> > Sent: Saturday, March 26, 2016 2:39 PM >> >> > To: OpenStack Development Mailing List (not for usage questions) >> >> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords >> >> > reserved as field name >> >> > >> >> > Hi Team, >> >> > >> >> > In the Tricircle database, there are three tables having a field name >> >> > which the MySQL (MariaDB) has as one of the reserved keywords. [1] >> >> > >> >> > Table Name: >> >> > aggregate_metadata >> >> > instance_type_extra_specs >> >> > quality_of_service_specs >> >> > >> >> > Field Name: >> >> > key >> >> > >> >> > I think it would not be best practice to use any reserved word by the >> >> > any system because it could cause bug once the component is bigger. >> >> > >> >> > What do you think? >> >> > >> >> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html >> >> > >> >> > Cheers, >> >> > Shinobu >> >> > >> >> > -- >> >> > Email: >> >> > shin...@linux.com >> >> > GitHub: >> >> > shinobu-x >> >> > Blog: >> >> > Life with Distributed Computational System based on OpenSource >> >> > >> >> > >> >> > >> >> > __ >> >> > 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 >> >> >> >> >> >> >> >> -- >> >> Email: >> >> shin...@linux.com >> >> GitHub: >> >> shinobu-x >> >> Blog: >> >> Life with Distributed Computational System based on OpenSource >> >> >> >> >> >> __ >> >> 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 >> > >> > >> > >> > >> > -- >> > Zhipeng (Howard) Huang >> > >> > Standard Engineer >> > IT Standard & Patent/IT Prooduct Line >> > Huawei Technologies Co,. Ltd >> > Email: huangzhip...@huawei.com >> > Office: Huawei Industrial Base, Longgang, Shenzhen >> > >> > (Previous) >> > Research Assistant >> > Mobile Ad-Hoc Network Lab, Calit2 >> > University of California, Irvine >> > Email: zhipe...@uci.edu >> > Office: Calit2 Buil
Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?
On 03/25/2016 03:52 PM, Jeremy Stanley wrote: On 2016-03-25 16:33:44 -0400 (-0400), Jay Pipes wrote: [...] What I'm proposing isn't using or needing a custom OpenStack deployment. There's nothing non-standard at all about the PCI or NFV stuff besides the hardware required to functionally test it. What you _are_ talking about though is maintaining physical servers in a data center running an OpenStack environment (and if you want it participating in gating/preventing changes from merging you need more than one environment so we don't completely shutdown development when one of them collapses). This much has been a challenge for the TripleO team, such that the jobs running for them are still not voting on their changes. What we're talking about here is using the same upstream Infra Puppet modules, installed on a long-running server in a lab that can interface with upstream Gerrit, respond to new change events in the Gerrit stream, and trigger devstack-gate[-like] builds on some bare-metal gear. It's possible I'm misunderstanding you... you're talking about maintaining a deployment of OpenStack with specific hardware to be able to run these jobs in, right? That's not as trivial an effort as it sounds, and I'm skeptical "a couple of operators" is sufficient to sustain such an endeavor. Two things: - Rhere is no current concept of "a long-lived machine running that we run devstack on from time to time" - everything in Infra is designed around using OpenStack APIs to get compute resources. So if we want to run jobs on hardware in this lab, as it stands right now, that hardware would need to be provided by Ironic+Nova. Last time we did the math (and Jim can maybe correct my numbers) in order to keep up with the demand similar to our VM environments, I believe such an env would need at least 83 Ironic nodes. And as Jeremy said, we'd need at least 2 envs for redundancy - so in looking at getting it funded, looking for approximately 200 machines is likely about right. - zuul v3 does introduce the concept of statically available resources that can be checked out of nodepool - specifically to address the question of people wanting to use long-lived servers as test resources for things. The machine count is still likely to remain static - but once we have zuul v3 out, it might reduce the need for the operators to operate 2 100-node Ironic-based OpenStack clouds. (This implies that help with zuul v3 might be seen as an accelerant to this project) Also keep in mind, if/when resources are sought out, that every underlying OS config would double the amount of resources. So if we got 2 sets of 100 nodes to start with, and started running NFV config'd devstack tests on them on ubuntu trusty, and then our friends at RedHat request that we test the same on a RH-baed distro, the cost for that would be an additional 100 nodes in each DC. Is that something that is totally out of the question for the upstream Infra team to be a guide for? We've stated in the past that we're willing to accept this level of integration as long as our requirements for redundancy/uptime are met. We mostly just don't want to see issues with the environment block development for projects relying on it because it's the only place those jobs can run, so multiple environments in different data centers would be a necessity (right now our gating jobs are able to run in any of 9 regions from 6 providers, which mitigates this risk). __ 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] [Tricircle] Using the reserved keywords reserved as field name
Great:) Do you have any more thoughts on that ? It might need both Tricircle and bottom OpenStack entity to deploy gRPC server and client, while it is ok for Tricircle, it is not easy to mandate gRPC endpoints as part of official OpenStack functionality. The whole point about Tricircle is to ensure Users could manage multiple cloud via normal OpenStack API. Or shall we only use gRPC endpoints internally in Tricircle ? That is to say to use it between gateways and Xjobs On Sat, Mar 26, 2016 at 8:11 PM, Shinobu Kinjo wrote: > Yes, that's one of possibilities. > > Cheers, > Shinobu > > On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang > wrote: > > any possible that we use gRPC for Tricircle ? > > > > On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo > wrote: > >> > >> Hi Chaoyi, > >> > >> Thank you for the pointer. > >> I'm also researching privately how we can improve RPC protocol > >> reasonably like HTTP2. > >> It's quite easy to foreseen that it would be bottleneck, and be able > >> not to realize what the Tricircle is trying to do. > >> Honestly it's already bottleneck. > >> > >> Cheers, > >> Shinobu > >> > >> On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: > >> > Hi, Shinobu, > >> > > >> > This BP is a good entrance for Tricircle source code, this BP listed > the > >> > all basic patches building Tricircle from scratches. > >> > > >> > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > >> > > >> > Best Regards > >> > Chaoyi Huang ( Joe Huang ) > >> > > >> > > >> > -Original Message- > >> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > >> > Sent: Saturday, March 26, 2016 2:39 PM > >> > To: OpenStack Development Mailing List (not for usage questions) > >> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords > >> > reserved as field name > >> > > >> > Hi Team, > >> > > >> > In the Tricircle database, there are three tables having a field name > >> > which the MySQL (MariaDB) has as one of the reserved keywords. [1] > >> > > >> > Table Name: > >> > aggregate_metadata > >> > instance_type_extra_specs > >> > quality_of_service_specs > >> > > >> > Field Name: > >> > key > >> > > >> > I think it would not be best practice to use any reserved word by the > >> > any system because it could cause bug once the component is bigger. > >> > > >> > What do you think? > >> > > >> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > >> > > >> > Cheers, > >> > Shinobu > >> > > >> > -- > >> > Email: > >> > shin...@linux.com > >> > GitHub: > >> > shinobu-x > >> > Blog: > >> > Life with Distributed Computational System based on OpenSource > >> > > >> > > >> > > __ > >> > 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 > >> > >> > >> > >> -- > >> Email: > >> shin...@linux.com > >> GitHub: > >> shinobu-x > >> Blog: > >> Life with Distributed Computational System based on OpenSource > >> > >> > __ > >> 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 > > > > > > > > > > -- > > Zhipeng (Howard) Huang > > > > Standard Engineer > > IT Standard & Patent/IT Prooduct Line > > Huawei Technologies Co,. Ltd > > Email: huangzhip...@huawei.com > > Office: Huawei Industrial Base, Longgang, Shenzhen > > > > (Previous) > > Research Assistant > > Mobile Ad-Hoc Network Lab, Calit2 > > University of California, Irvine > > Email: zhipe...@uci.edu > > Office: Calit2 Building Room 2402 > > > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > > > > __ > > 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 > > > > > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __ > 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 > -- Zhipeng (Howa
Re: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name
Yes, that's one of possibilities. Cheers, Shinobu On Sat, Mar 26, 2016 at 8:55 PM, Zhipeng Huang wrote: > any possible that we use gRPC for Tricircle ? > > On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo wrote: >> >> Hi Chaoyi, >> >> Thank you for the pointer. >> I'm also researching privately how we can improve RPC protocol >> reasonably like HTTP2. >> It's quite easy to foreseen that it would be bottleneck, and be able >> not to realize what the Tricircle is trying to do. >> Honestly it's already bottleneck. >> >> Cheers, >> Shinobu >> >> On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: >> > Hi, Shinobu, >> > >> > This BP is a good entrance for Tricircle source code, this BP listed the >> > all basic patches building Tricircle from scratches. >> > >> > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless >> > >> > Best Regards >> > Chaoyi Huang ( Joe Huang ) >> > >> > >> > -Original Message- >> > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] >> > Sent: Saturday, March 26, 2016 2:39 PM >> > To: OpenStack Development Mailing List (not for usage questions) >> > Subject: [openstack-dev] [Tricircle] Using the reserved keywords >> > reserved as field name >> > >> > Hi Team, >> > >> > In the Tricircle database, there are three tables having a field name >> > which the MySQL (MariaDB) has as one of the reserved keywords. [1] >> > >> > Table Name: >> > aggregate_metadata >> > instance_type_extra_specs >> > quality_of_service_specs >> > >> > Field Name: >> > key >> > >> > I think it would not be best practice to use any reserved word by the >> > any system because it could cause bug once the component is bigger. >> > >> > What do you think? >> > >> > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html >> > >> > Cheers, >> > Shinobu >> > >> > -- >> > Email: >> > shin...@linux.com >> > GitHub: >> > shinobu-x >> > Blog: >> > Life with Distributed Computational System based on OpenSource >> > >> > >> > __ >> > 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 >> >> >> >> -- >> Email: >> shin...@linux.com >> GitHub: >> shinobu-x >> Blog: >> Life with Distributed Computational System based on OpenSource >> >> __ >> 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 > > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > __ > 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 > -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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] [Tricircle] Using the reserved keywords reserved as field name
any possible that we use gRPC for Tricircle ? On Sat, Mar 26, 2016 at 6:11 PM, Shinobu Kinjo wrote: > Hi Chaoyi, > > Thank you for the pointer. > I'm also researching privately how we can improve RPC protocol > reasonably like HTTP2. > It's quite easy to foreseen that it would be bottleneck, and be able > not to realize what the Tricircle is trying to do. > Honestly it's already bottleneck. > > Cheers, > Shinobu > > On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: > > Hi, Shinobu, > > > > This BP is a good entrance for Tricircle source code, this BP listed the > all basic patches building Tricircle from scratches. > > > > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > > > > Best Regards > > Chaoyi Huang ( Joe Huang ) > > > > > > -Original Message- > > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > > Sent: Saturday, March 26, 2016 2:39 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [Tricircle] Using the reserved keywords > reserved as field name > > > > Hi Team, > > > > In the Tricircle database, there are three tables having a field name > which the MySQL (MariaDB) has as one of the reserved keywords. [1] > > > > Table Name: > > aggregate_metadata > > instance_type_extra_specs > > quality_of_service_specs > > > > Field Name: > > key > > > > I think it would not be best practice to use any reserved word by the > any system because it could cause bug once the component is bigger. > > > > What do you think? > > > > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > > > > Cheers, > > Shinobu > > > > -- > > Email: > > shin...@linux.com > > GitHub: > > shinobu-x > > Blog: > > Life with Distributed Computational System based on OpenSource > > > > > __ > > 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 > > > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __ > 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 > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ 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] [Tricircle] Using the reserved keywords reserved as field name
Hi Vega, Thank you for your quick action. Cheers, Shinobu On Sat, Mar 26, 2016 at 6:39 PM, Vega Cai wrote: > Added a work item in phase 4 in our todo list: > > https://etherpad.openstack.org/p/TricircleToDo > > On 26 March 2016 at 17:31, joehuang wrote: >> >> Hi, Shinobu, >> >> This BP is a good entrance for Tricircle source code, this BP listed the >> all basic patches building Tricircle from scratches. >> >> https://blueprints.launchpad.net/tricircle/+spec/implement-stateless >> >> Best Regards >> Chaoyi Huang ( Joe Huang ) >> >> >> -Original Message- >> From: Shinobu Kinjo [mailto:shinobu...@gmail.com] >> Sent: Saturday, March 26, 2016 2:39 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved >> as field name >> >> Hi Team, >> >> In the Tricircle database, there are three tables having a field name >> which the MySQL (MariaDB) has as one of the reserved keywords. [1] >> >> Table Name: >> aggregate_metadata >> instance_type_extra_specs >> quality_of_service_specs >> >> Field Name: >> key >> >> I think it would not be best practice to use any reserved word by the any >> system because it could cause bug once the component is bigger. >> >> What do you think? >> >> [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html >> >> Cheers, >> Shinobu >> >> -- >> Email: >> shin...@linux.com >> GitHub: >> shinobu-x >> Blog: >> Life with Distributed Computational System based on OpenSource >> >> __ >> 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 > -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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] [Tricircle] Using the reserved keywords reserved as field name
Hi Chaoyi, Thank you for the pointer. I'm also researching privately how we can improve RPC protocol reasonably like HTTP2. It's quite easy to foreseen that it would be bottleneck, and be able not to realize what the Tricircle is trying to do. Honestly it's already bottleneck. Cheers, Shinobu On Sat, Mar 26, 2016 at 6:31 PM, joehuang wrote: > Hi, Shinobu, > > This BP is a good entrance for Tricircle source code, this BP listed the all > basic patches building Tricircle from scratches. > > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > > Best Regards > Chaoyi Huang ( Joe Huang ) > > > -Original Message- > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > Sent: Saturday, March 26, 2016 2:39 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved as > field name > > Hi Team, > > In the Tricircle database, there are three tables having a field name which > the MySQL (MariaDB) has as one of the reserved keywords. [1] > > Table Name: > aggregate_metadata > instance_type_extra_specs > quality_of_service_specs > > Field Name: > key > > I think it would not be best practice to use any reserved word by the any > system because it could cause bug once the component is bigger. > > What do you think? > > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > > Cheers, > Shinobu > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __ > 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 -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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] [Tricircle] Using the reserved keywords reserved as field name
Added a work item in phase 4 in our todo list: https://etherpad.openstack.org/p/TricircleToDo On 26 March 2016 at 17:31, joehuang wrote: > Hi, Shinobu, > > This BP is a good entrance for Tricircle source code, this BP listed the > all basic patches building Tricircle from scratches. > > https://blueprints.launchpad.net/tricircle/+spec/implement-stateless > > Best Regards > Chaoyi Huang ( Joe Huang ) > > > -Original Message- > From: Shinobu Kinjo [mailto:shinobu...@gmail.com] > Sent: Saturday, March 26, 2016 2:39 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved > as field name > > Hi Team, > > In the Tricircle database, there are three tables having a field name > which the MySQL (MariaDB) has as one of the reserved keywords. [1] > > Table Name: > aggregate_metadata > instance_type_extra_specs > quality_of_service_specs > > Field Name: > key > > I think it would not be best practice to use any reserved word by the any > system because it could cause bug once the component is bigger. > > What do you think? > > [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html > > Cheers, > Shinobu > > -- > Email: > shin...@linux.com > GitHub: > shinobu-x > Blog: > Life with Distributed Computational System based on OpenSource > > __ > 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] [Tricircle] Using the reserved keywords reserved as field name
Hi, Shinobu, This BP is a good entrance for Tricircle source code, this BP listed the all basic patches building Tricircle from scratches. https://blueprints.launchpad.net/tricircle/+spec/implement-stateless Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: Shinobu Kinjo [mailto:shinobu...@gmail.com] Sent: Saturday, March 26, 2016 2:39 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name Hi Team, In the Tricircle database, there are three tables having a field name which the MySQL (MariaDB) has as one of the reserved keywords. [1] Table Name: aggregate_metadata instance_type_extra_specs quality_of_service_specs Field Name: key I think it would not be best practice to use any reserved word by the any system because it could cause bug once the component is bigger. What do you think? [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html Cheers, Shinobu -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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] [Tricircle] Using the reserved keywords reserved as field name
Yes, It would be better to avoid the field name duplicated with DB key words. These tables are ported from Nova and Neutron, it would be good to change the field name. Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: Shinobu Kinjo [mailto:shinobu...@gmail.com] Sent: Saturday, March 26, 2016 2:39 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Tricircle] Using the reserved keywords reserved as field name Hi Team, In the Tricircle database, there are three tables having a field name which the MySQL (MariaDB) has as one of the reserved keywords. [1] Table Name: aggregate_metadata instance_type_extra_specs quality_of_service_specs Field Name: key I think it would not be best practice to use any reserved word by the any system because it could cause bug once the component is bigger. What do you think? [1] http://dev.mysql.com/doc/refman/5.0/en/keywords.html Cheers, Shinobu -- Email: shin...@linux.com GitHub: shinobu-x Blog: Life with Distributed Computational System based on OpenSource __ 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
