Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
[TEST] DevCloud4 - rework / Cleanup
TL;DR: Devcloud 4 cleaned up a bit, chef attributes no longer hidden, further user customisation allowed, Testers wanted. ** advanced zone on 4.4.* isn't supported due to a change on some API param for setting tags on interfaces ** Hi All, https://github.com/imduffy15/devcloud4/tree/dev/binary-installation-basic I've pushed some clean up work for binary-installation versions DevCloud4. I've moved a few things about so chef attributes are no longer completely black boxed and are more exposed to the user so they are aware they can change system vm locations, rpm locations, etc. Along with this I've moved to using berkshelf for pulling in the chef cookbooks. Sadly this adds a dependency on ChefDK but it works better for cookbook updates. I've also upped the amount of RAM given to XenServer and the System VMs. (6gb for XenServer and 256 for ssvm cpvm rvm)... I would suggest running on a system with 16gb of ram. I may lower this down in the future but I felt their was some performance issues in allocating only 100mb of ram to the system vms. URLs to resources should now be more stable. I'm no longer hosting a marvin binary, its pulled in from pypi. All default URLs for RPMs and SystemVM images are pointing to shapeblues repo :). The chef cookbook powering it all is a modification from the one created by the folks over at CloudOps. If anybody is interested in testing I'd love to hear some feedback: ** Note should work on osx, linux and windows (in theory, windows remains untested)** ** you need chefdk installed on your machine along with vagrant-berkshelf ** ** you need virtualbox interfaces vboxnet0 vboxnet1 vboxnet2 with ips 192.168.22.1, 192.168.23.1 and 192.168.24.1 respectively along with disabling the DHCP Server ** git clone https://github.com/imduffy15/devcloud4.git git checkout -b dev origin/dev cd binary-installation-basic or binary-installation-advanced vagrant up Thanks, Ian
[QUESTION] How come we don't include Users@ in vote threads?
Hi All, Just out of interest, is there some reason we don't include the users mailing list within vote threads for feedback around product stability? From what I've seen a lot of them have test labs. It would be nice to get their feedback before releasing rather than after... Thanks, Ian
Re: [QUESTION] How come we don't include Users@ in vote threads?
+1 -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Sunday, 16 November, 2014 16:20:55 Subject: [QUESTION] How come we don't include Users@ in vote threads? Hi All, Just out of interest, is there some reason we don't include the users mailing list within vote threads for feedback around product stability? From what I've seen a lot of them have test labs. It would be nice to get their feedback before releasing rather than after... Thanks, Ian
Re: [QUESTION] How come we don't include Users@ in vote threads?
I'm not sure about adding users@ into the vote since it's more dev@ related. But, I agree it would be nice to notify users@ that we have an RC it would potentially involved more people in the test phases. On Sun, Nov 16, 2014 at 12:56 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: On 16-Nov-2014, at 9:50 pm, Ian Duffy i...@ianduffy.ie wrote: Just out of interest, is there some reason we don't include the users mailing list within vote threads for feedback around product stability? From what I've seen a lot of them have test labs. It would be nice to get their feedback before releasing rather than after… I think we should start doing that. By including users@ in the last rounds of recent CloudMonkey voting release I got some good feedback. I think the general problem here is that for each voting candidate adding users@ML would be only useful if we also build a deb/rpm repo for them to test the voting candidate so everyone won’t have to build their own CloudStack. My suggestion is to do that, and I think we can have the testing repo on packages.shapeblue.com for that. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [QUESTION] How come we don't include Users@ in vote threads?
I think the general problem here is that for each voting candidate adding users@ML would be only useful if we also build a deb/rpm repo for them to test the voting candidate so everyone won’t have to build their own CloudStack. My suggestion is to do that, and I think we can have the testing repo on packages.shapeblue.com for that. Love the way you think Rohit! :-) Massive +1 to this, we want to make it ease for them. I'm not sure about adding users@ into the vote since it's more dev@ related But we're building a product for the users right? Surely they should be included in the development life cycle at some point? On 16 November 2014 18:10, Pierre-Luc Dion pdion...@apache.org wrote: I'm not sure about adding users@ into the vote since it's more dev@ related. But, I agree it would be nice to notify users@ that we have an RC it would potentially involved more people in the test phases. On Sun, Nov 16, 2014 at 12:56 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: On 16-Nov-2014, at 9:50 pm, Ian Duffy i...@ianduffy.ie wrote: Just out of interest, is there some reason we don't include the users mailing list within vote threads for feedback around product stability? From what I've seen a lot of them have test labs. It would be nice to get their feedback before releasing rather than after… I think we should start doing that. By including users@ in the last rounds of recent CloudMonkey voting release I got some good feedback. I think the general problem here is that for each voting candidate adding users@ML would be only useful if we also build a deb/rpm repo for them to test the voting candidate so everyone won’t have to build their own CloudStack. My suggestion is to do that, and I think we can have the testing repo on packages.shapeblue.com for that. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [TEST] DevCloud4 - rework / Cleanup
Hi Ian, I'm trying it as it seams quite strait forward. although, the instruction to install cloudstack [1]: I should run that in the management VM right, not locally ? does IPs are hardcoded somewhere? Thanks, that's awesome to have a local cloudstack running without effort. I'm testing this on OSX and so far the installation process is easy and well documented (still few things missing :-P )! [1] https://github.com/imduffy15/devcloud4/tree/master/advanced#start-cloudstack *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Sun, Nov 16, 2014 at 11:18 AM, Ian Duffy i...@ianduffy.ie wrote: TL;DR: Devcloud 4 cleaned up a bit, chef attributes no longer hidden, further user customisation allowed, Testers wanted. ** advanced zone on 4.4.* isn't supported due to a change on some API param for setting tags on interfaces ** Hi All, https://github.com/imduffy15/devcloud4/tree/dev/binary-installation-basic I've pushed some clean up work for binary-installation versions DevCloud4. I've moved a few things about so chef attributes are no longer completely black boxed and are more exposed to the user so they are aware they can change system vm locations, rpm locations, etc. Along with this I've moved to using berkshelf for pulling in the chef cookbooks. Sadly this adds a dependency on ChefDK but it works better for cookbook updates. I've also upped the amount of RAM given to XenServer and the System VMs. (6gb for XenServer and 256 for ssvm cpvm rvm)... I would suggest running on a system with 16gb of ram. I may lower this down in the future but I felt their was some performance issues in allocating only 100mb of ram to the system vms. URLs to resources should now be more stable. I'm no longer hosting a marvin binary, its pulled in from pypi. All default URLs for RPMs and SystemVM images are pointing to shapeblues repo :). The chef cookbook powering it all is a modification from the one created by the folks over at CloudOps. If anybody is interested in testing I'd love to hear some feedback: ** Note should work on osx, linux and windows (in theory, windows remains untested)** ** you need chefdk installed on your machine along with vagrant-berkshelf ** ** you need virtualbox interfaces vboxnet0 vboxnet1 vboxnet2 with ips 192.168.22.1, 192.168.23.1 and 192.168.24.1 respectively along with disabling the DHCP Server ** git clone https://github.com/imduffy15/devcloud4.git git checkout -b dev origin/dev cd binary-installation-basic or binary-installation-advanced vagrant up Thanks, Ian
Re: [TEST] DevCloud4 - rework / Cleanup
Hi Pierre, So advanced and basic are running from code on the host machine. Only a NFS, MySQL and hypervisor box is supplied. Testing is for binary-installation-advanced and binary-installation-basic. On 16 November 2014 19:44, Pierre-Luc Dion pd...@cloudops.com wrote: Hi Ian, I'm trying it as it seams quite strait forward. although, the instruction to install cloudstack [1]: I should run that in the management VM right, not locally ? does IPs are hardcoded somewhere? Thanks, that's awesome to have a local cloudstack running without effort. I'm testing this on OSX and so far the installation process is easy and well documented (still few things missing :-P )! [1] https://github.com/imduffy15/devcloud4/tree/master/advanced#start-cloudstack *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Sun, Nov 16, 2014 at 11:18 AM, Ian Duffy i...@ianduffy.ie wrote: TL;DR: Devcloud 4 cleaned up a bit, chef attributes no longer hidden, further user customisation allowed, Testers wanted. ** advanced zone on 4.4.* isn't supported due to a change on some API param for setting tags on interfaces ** Hi All, https://github.com/imduffy15/devcloud4/tree/dev/binary-installation-basic I've pushed some clean up work for binary-installation versions DevCloud4. I've moved a few things about so chef attributes are no longer completely black boxed and are more exposed to the user so they are aware they can change system vm locations, rpm locations, etc. Along with this I've moved to using berkshelf for pulling in the chef cookbooks. Sadly this adds a dependency on ChefDK but it works better for cookbook updates. I've also upped the amount of RAM given to XenServer and the System VMs. (6gb for XenServer and 256 for ssvm cpvm rvm)... I would suggest running on a system with 16gb of ram. I may lower this down in the future but I felt their was some performance issues in allocating only 100mb of ram to the system vms. URLs to resources should now be more stable. I'm no longer hosting a marvin binary, its pulled in from pypi. All default URLs for RPMs and SystemVM images are pointing to shapeblues repo :). The chef cookbook powering it all is a modification from the one created by the folks over at CloudOps. If anybody is interested in testing I'd love to hear some feedback: ** Note should work on osx, linux and windows (in theory, windows remains untested)** ** you need chefdk installed on your machine along with vagrant-berkshelf ** ** you need virtualbox interfaces vboxnet0 vboxnet1 vboxnet2 with ips 192.168.22.1, 192.168.23.1 and 192.168.24.1 respectively along with disabling the DHCP Server ** git clone https://github.com/imduffy15/devcloud4.git git checkout -b dev origin/dev cd binary-installation-basic or binary-installation-advanced vagrant up Thanks, Ian
Re: [QUESTION] How come we don't include Users@ in vote threads?
Den søndag 16. november 2014 skrev Pierre-Luc Dion pdion...@apache.org følgende: I'm not sure about adding users@ into the vote since it's more dev@ related. But, I agree it would be nice to notify users@ that we have an RC it would potentially involved more people in the test phases. I must disagree. Creating cloudstack is indeed a dev thing, but if you look at the last releases and the trouble they had we should look at and embrace any way to improve testing. Using simulator and spinning up basic zones can only reveal a minority of issues. Afaik non-pmc's aren't binding and any votes would merely be an indication, or do i misunderstand? But i do agree that providing packages are crucial, that would help us discover packaging problems as well Erik
Re: [QUESTION] How come we don't include Users@ in vote threads?
I agree that more tests are welcome, we have to try then :) Afaik non-pmc's aren't binding and any votes would merely be an indication, or do i misunderstand? All votes are important [1] and count as indicator, who ever vote mean something, It also show that the community members did some tests or review of some kind. And whoever doing a -1 with valid justification will be listen. It would be much more interesting to see an RC with 15 non binding votes than the 3 minimum binding. [1] http://www.apache.org/foundation/voting.html On Sun, Nov 16, 2014 at 4:30 PM, Erik Weber terbol...@gmail.com wrote: Den søndag 16. november 2014 skrev Pierre-Luc Dion pdion...@apache.org følgende: I'm not sure about adding users@ into the vote since it's more dev@ related. But, I agree it would be nice to notify users@ that we have an RC it would potentially involved more people in the test phases. I must disagree. Creating cloudstack is indeed a dev thing, but if you look at the last releases and the trouble they had we should look at and embrace any way to improve testing. Using simulator and spinning up basic zones can only reveal a minority of issues. Afaik non-pmc's aren't binding and any votes would merely be an indication, or do i misunderstand? But i do agree that providing packages are crucial, that would help us discover packaging problems as well Erik
Re: did anyone try 4.4.2?
I'm trying to build 4.4.2 from 4.4 branch. I'm having the db deployment error that schema-441to442.sql does not exist. Could it be the cause of the problem you are seeing too ? On Fri, Nov 14, 2014 at 8:57 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I run into a strange exception during the spring load phase. Did anybody run 442 yet? -- Daan
Review Request 28114: RabbitMQ integration, make SSL protocol configurable rather than hard coded
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28114/ --- Review request for cloudstack and Kishan Kavala. Bugs: CLOUDSTACK-7923 https://issues.apache.org/jira/browse/CLOUDSTACK-7923 Repository: cloudstack-git Description --- In the current RabbitMQ integration implementation we are using default SSL Context which uses SSLv3 by default. Make it configurable so that let the users decide which protocol to be used. Diffs - plugins/event-bus/rabbitmq/src/org/apache/cloudstack/mom/rabbitmq/RabbitMQEventBus.java 2d389f2 Diff: https://reviews.apache.org/r/28114/diff/ Testing --- Tested against RabbitMQ server 3.3.5 Thanks, Damodar Reddy Talakanti
Re: [QUESTION] How come we don't include Users@ in vote threads?
On Sun, Nov 16, 2014 at 11:44 PM, Pierre-Luc Dion pdion...@apache.org wrote: I agree that more tests are welcome, we have to try then :) On the other side, how many devs can say that they really like to do thorough release testing? My guess is that it's a rather small number. By adding users, and if testing actually gains any momentum, you can hopefully have faith in that the release has been tested and free up some developer time to do more development :-) There's one thing that should be thought of though. Users might not pay attention to dev@ and might not know when to expect an RC. So I think a 72 hours time limit for users to test is gonna be to little, $dayjobs and personal lifes might not allow all to just throw whatever they're doing to start testing. I'm not sure what the best way to remedy it is, if it's to extend the time window or introduce another term/phase. -- Erik
Re: [QUESTION] How come we don't include Users@ in vote threads?
My suggestions and comments; - Build a rpm/deb repository before you start voting (we can use packages.shapeblue.com/cloudstack/testing) - Tag each Voting Candidate (using a -vc or -rc suffix followed by the round number, for example 4.4.2-rc-01) and we build rpm/deb repo using tags. - This repo can be used by both developers and users - Let everyone participate, any contribution should we welcomed, so email all - dev@ and users@ and user-cn@. AFAIK, there is no *rule* stopping us from doing it so I recommend the release manager should do it. Of course this has to be at their discretion and judgement. - 72 hours (during weekdays, not weekends) limit should be good enough for everyone, by increasing this limit we risk delaying the release. If a weekend lies in a voting window, historically we've added additional weekend days as well, so the voting window can go upto 120 hours. Typically I’ve seen 4 voting rounds for any release, that means delaying release by at least 3 weeks. The other argument is, it may not be enough for developers as well. So, if you don’t find it enough - you should start a new thread as I think it's a different topic than this email. On 17-Nov-2014, at 12:32 pm, Erik Weber terbol...@gmail.com wrote: On Sun, Nov 16, 2014 at 11:44 PM, Pierre-Luc Dion pdion...@apache.org wrote: I agree that more tests are welcome, we have to try then :) On the other side, how many devs can say that they really like to do thorough release testing? My guess is that it's a rather small number. By adding users, and if testing actually gains any momentum, you can hopefully have faith in that the release has been tested and free up some developer time to do more development :-) There's one thing that should be thought of though. Users might not pay attention to dev@ and might not know when to expect an RC. So I think a 72 hours time limit for users to test is gonna be to little, $dayjobs and personal lifes might not allow all to just throw whatever they're doing to start testing. I'm not sure what the best way to remedy it is, if it's to extend the time window or introduce another term/phase. -- Erik Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
