Re: [DISCUSS][PROPOSAL] git workflow

[Rohit Yadav]

Hi,

Rajani Karuturi wrote:

In my first email, I mentioned a youtube url[1] which is a google tech talk by  
Laura Wingerd [2] of Perforce Software
I recommend watching it as well. (its a 55 min video).

[1] https://www.youtube.com/watch?v=AJ-CpGsCpM0
[2] http://www.perforce.com/blog/author/lwingerd

~Rajani


Thanks for sharing this again Rajani, I saw the video it was insightful.

Here are the slides: (link on youtube was broken)

http://web.archive.org/web/20061019021704/http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf


Let me share the key points from the shared talk:

- The speaker uses analogy of ease of driving cars on complex layout of
roads to developing software using a SCM.

- She recommends a mainline model which could speed up development and
release process. (refer the slides) We have branches -- mainline
(master), release (release branches) and development (feature work,
refactoring etc).

- Tofu scale: released/stable branches are firmer, unstable/master ones
are soft.

- She defines a baseline protocol: the soft branches are those which are
not tested and development work is going on, the firm ones are those
which are set to release or are already released or are live. The
protocol is to let the commit/changes flow from soft to firm branches
wrt to a baseline (master) only when they firm-er or tested and
continually changes flow from firm ones to soft ones (i.e. you rebase or
cherry-pick often from firm branches to soft ones). Change flows between
branch and baseline

- Always accept stable changes over destabilizing change

- She suggests to view the branches wrt baseline as a map, where changes
follow the baseline protocol and fix on an old trickle downs to
chronological release branches, then to baseline (master) and to rest of
the feature branches continually.

- She spoke about module, file tree etc. which I think is not relevant
for git users. We've git submodules and subtrees but IMO it's out of the
scope unless we want to split our repo.

- Merge down, copy up: She shares an interesting approach to deliver
feature work/project to firmer baseline branch which requires you to
first get all the changes from baselines (master & above, in git terms
that would be merge/rebase or cherry-picking from master to feature
branch) and then copy the files from the feature branch to baseline (not
merge). Then test and have the code/files in baseline (master).



My thoughts and suggestions:

- We adapt and adopt the baseline protocol (discuss?) wrt ACS

- We don't commit on master directly, break master. In future, have
master to be stable enough for anyone to branch off and work.

- Anyone fixing anything on master or other release/QA branches creates
a feature/topic branch and work on it, and merge/cherry-pick changes
back to upper branches only when that branch is well tested.

- Feature branches branch off master or other feature branches, not
release branches. Bug fix branches branch off from the oldest release
branch (on which we need to fix it) and the test fix lands to that
branch and subsequent release branches and then to master and other
feature branches.

- Suggestion for a better release protocol: All releases have tags. We
value tags more than release branch names. A vote is requested on a
release branch's commit with a version plus -RC, -beta and other
suitable name tag. Once vote is passed, the tag is the version number
this is the actual release. Git allows multiple tags can be on a commit
so we're good. Developers have freedmo to land but only bug fixes (once
fully tested) on release branches from a bugfix branch branched off from
the release branch or (by cherry-picking from) older release branches.
Then the bugfix lands to master and other feature branches continually.
This would also require that tags are immutable (you don't change/delete
them once created and pushed). IMHO this will speed up development process.

- One thing I'm still struggling with is working with branches/releases
which has fair amount of refactoring and rearchitecture work, which is
where changes would need to be manually ported and fixed. I don't have
any idea how to deal with it automatically, with git or any other tool.



On 09-Jul-2014, at 3:52 am, Sebastien 
Goasguenmailto:run...@gmail.com>>  wrote:

This is also a good read, against cherry-picking (back to Rajani's original 
point):

http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

(even wondering if Rohit did not send this to the list already…)


I do not remember sharing this, but I've read posts like this before and
I think it's just the author's opinion and not universal truth.

In my experience, if you rebase your source branch and cherry pick on
target there is no issue or conflicts (as suggested by this articles).
If merge/rebase is required I prefer no-ff and ignore-whitespace flags.

Merging IMHO is a quick and easy solution but it clutters the history,
while cherry-picking is great too

Re: Review Request 23314: Plugin specific code for the Brocade Network Plugin

[Hugo Trippaers]

> On July 8, 2014, 9:29 a.m., Hugo Trippaers wrote:
> > Thanks for make this a separate review, much easier to read.
> > 
> > The licenses are not added to all files and in some files they appear not 
> > to be complete. A good trick to solve this is to include the 
> > license-maven-plugin in the build section. See 
> > plugins/network-elements/nicira-nvp/pom.xml for an example.
> > 
> > Also the plugin doesn't contain any tests. We need unit tests or functional 
> > tests (and preferably both) to validate that this plugin works and keeps on 
> > working in future versions of CloudStack. It would be great if you could 
> > supply unit tests to validate this inner workings of this module and marvin 
> > based integration tests that we can run to see if this work with the 
> > intended hardware.
> > 
> > The last general point is that we would also need documentation on this 
> > plugin so administrators will know how to use this.
> 
> Ritu  Sabharwal wrote:
> Thanks for reviewing the code.
> 
> I have fixed the license in all the files.
> 
> I am working on writing the unit tests for the plugin.
> 
> I am working on providing the documentation on using the plugin.
> 
> I have tested the plugin with the simulator and see the configurations on 
> Brocade switches happening. Currently, I am setting up a real hardware setup 
> with Vmware hypervisor and Brocade switches so test the connectivity between 
> spawned VMs.
> 
> Can I continue writing the unit tests and marvin integration tests and 
> documentation after the July 19 date so that this plugin makes to 4.5 feature 
> freeze date.
> 
> I have updated the diffs with the changes for the license and other 
> comments.
> 
> Ritu  Sabharwal wrote:
> I am planning to include the following in the documentation:
>  - Brocade switch setup
>  - Connections to the Hypervisor hosts
>  - the flow to use the plugin from UI

Thanks for fixing the open issues.

I think it's ok to work on the documentation while a release is being tested 
(eventhough it is far better to have it ready for the testers). However 
unittests and functional testcases need to be there before we can merge the 
plugin. Without it we can not properly test the plugin to see if it is fit to 
be part of the release. 

I'd rather have a completely done plugin in the 4.6 release than something that 
is not complete in 4.5. So currently the blockers for a merge into master are 
the two property files and we need unit and integration tests.


- Hugo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23314/#review47435
---


On July 8, 2014, 6:49 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23314/
> ---
> 
> (Updated July 8, 2014, 6:49 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Plugin specific code.
> 
> 
> Diffs
> -
> 
>   plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema.xsd 
> PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSchema.xsd 
> PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.xsd 
> PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/module.properties
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/spring-vcs-context.xml
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkAnswer.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkCommand.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNetworkAnswer.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNetworkCommand.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNetworkAnswer.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNetworkCommand.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DisassociateMacFromNetworkAnswer.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DisassociateMacFromNetworkCommand.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/StartupBrocadeVcsCommand.java
>  PRE-CREATION 
>   
> plugins/ne

Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin

[Hugo Trippaers]

> On July 8, 2014, 10:07 a.m., Hugo Trippaers wrote:
> > plugins/network-elements/nuage-vsp/src/com/cloud/network/resource/NuageVspResource.java,
> >  line 196
> > 
> >
> > I'm not really agreeing with this method of loading the client. The 
> > client should be loaded using the classloader.
> > 
> > Is the library available from maven central or is distribution 
> > restricted? If the latter case we need to move this plugin and the 
> > dependency on the library to the noredist build.
> 
> Suresh Ramamurthy wrote:
> Yes, NuageVsp plugin client library is distribution restricted. I had 
> some design question regarding dropping the library and loading it 
> dynamically. Please find below our requirement'
> 
> 1) We wanted to drop our NuageVsp plugin client after installing 
> CloudStack. 
> 2) We wanted to create an NuageVsp plugin Client RPM and then install the 
> RPM that copies in a location. The location could be some other location that 
> NuageVsp Plugin client chooses.
>In this case I thought of copying it under 
> /usr/share/cloudstack-management/webapps/client/WEB-INF/lib but it could be 
> different location
> 3) Then restart CloudStack.
> 4) When NuageVsp Device is added, then the class files will be 
> dynamically loaded and things will work seamlessly
> 
> Advantages of above approach:
> 
> 1) Cloudstack build does not have any dependency on our jar files. This 
> is because, we do not have any reference of NuageVsp Plugin client code 
>and the client classes are loaded dynamically
> 2) There is no maven central dependency
> 3) Version Upgrade of NuageVsp Plugin client does not depend on 
> Cloudstack version. We will just uninstall our RPM and re-install the new 
> version of NuageVsp Plugin client code and restart CloudStack
> 
> Hugo, above was our suggestion. Is it okay to follow the above approach 
> of loading the Plugin Client files? 
> 
> If the above approach is not acceptable then we are open to follow the 
> noredist build approach. If we are following the noredist build approach then 
> I just want to clarify the procedure to be
> followed to use NuageVsp Plugin
> 
> 1) User needs to download NuageVsp Plugin client jar file
> 2) Copy the jar under deps folder
> 3) Run install-non-oss.sh
> 4) Build RPM using -p NOREDIST option
> 
> Could you please let me know details of the forum where we can have 
> design discussions?
> 
> I know, I am asking too many question :)
> 
> Thanks reviewing and supporting us.
>

That makes sense, thanks for the clarification. I think we can work that way, 
actually our plugin system is designed to work in such a way that the entire 
plugin could technically be separated into an rpm package. 

Probably the best way to go forward is to agree on a file location. Probably 
something like /usr/share/nuage/lib for unix alike systems is a better place to 
store the library. The actual location would need to be configured as a global 
setting in CloudStack and passed to the resource during initialization. 

However to use this type of loading i would like to make sure that a user will 
receive a clear error message explaining that the correct library is not 
installed when it tries to use it. 

For functional testing this introduces number of problems as only people with 
access to those libraries can do any kind of testing on the library or are you 
delivering a stub together with the functional tests so we can integrate it in 
the functional test stream.

In short, i'm ok with this type of loading, provided:
  * we have a way of testing the plugin or execute functional tests against 
something that has access to the libraries.
  * the cloudstack plugin documentation makes it clear that the plugin requires 
an additional library.
  * the user receives an error message when he tries to configure the nauge 
plugin in cloudstack without the library.

I'll take the question whether or not we need to put this plugin in the 
noredist build to the dev-list as i would like some more input on that.


- Hugo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23282/#review47436
---


On July 7, 2014, 6 p.m., Suresh Ramamurthy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23282/
> ---
> 
> (Updated July 7, 2014, 6 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6845
> https://issues.apache.org/jira/browse/CLOUDSTACK-6845
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>

Re: Review Request 21901: L10N:001-Fixed the legacy hard-coding issues

[Vetrivel Chinnasamy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21901/
---

(Updated July 9, 2014, 2:38 p.m.)


Review request for cloudstack and Brian Federle.


Repository: cloudstack-git


Description
---

Externalized the hard coded strings in JavaScript files and added them to 
messages.properties files. Also appended the link dictionary.jsp with the 
externalized strings.


Diffs
-

  client/WEB-INF/classes/resources/messages.properties eff2c3e 
  systemvm/js/cloud.logger.js 751627e 
  ui/dictionary.jsp 9cc030a 
  ui/modules/vnmcAsa1000v/vnmcAsa1000v.js 621c52a 
  ui/scripts/accounts.js a789084 
  ui/scripts/configuration.js 1a88224 
  ui/scripts/events.js 2731cb6 
  ui/scripts/network.js f934f21 
  ui/scripts/sharedFunctions.js 2cfc89f 
  ui/scripts/storage.js 2660aa5 
  ui/scripts/system.js 67e01f1 
  ui/scripts/templates.js 67cc2fb 
  ui/scripts/ui-custom/physicalResources.js 06fcca7 
  ui/scripts/ui-custom/regions.js 986e009 
  ui/scripts/ui/dialog.js 34cec7b 
  ui/scripts/ui/widgets/listView.js be40d33 
  ui/scripts/vpc.js 020b9d7 

Diff: https://reviews.apache.org/r/21901/diff/


Testing
---

Tested in local environment by replacing the fixed file.


File Attachments


Patch - 2 Commits
  
https://reviews.apache.org/media/uploaded/files/2014/05/27/4d2b3c2f-246b-49a6-a528-8c95eecbfba8__001002-L10N-Hardcoding_Fix.patch


Thanks,

Vetrivel Chinnasamy

RE: [ANNOUNCE] New PMC Member: Mark Hinkle

[Giles Sirett]

Mark

You can join me on the list of people who are trusted *NOT* to commit code :-)


Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: Mark Hinkle [mailto:mark.hin...@citrix.com]
Sent: 07 July 2014 14:54
To: market...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [ANNOUNCE] New PMC Member: Mark Hinkle

Thanks for the asking me to join and everyone's kind words though if you start 
accepting my spaghetti code patches. I will vote for my own dismissal ;)

Regards, Mark


On Jul 3, 2014, at 1:50 PM, John Burwell 
mailto:jburw...@basho.com>> wrote:

The Project Management Committee (PMC) for Apache CloudStack has asked Mark 
Hinkle to join the PMC and we are pleased to announce that he has accepted.

Join me in congratulating Mark!


-The CloudStack PMC

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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 is a registered trademark.

Re: Review Request 22927: Bugfix CLOUDSTACK-6261: remove the forceful timeout setting when login to NetScaler.

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22927/#review47503
---


Commit e07d0ddabfedad137856c3c9ae7de3a96fe25feb in cloudstack's branch 
refs/heads/master from Sujaya Maiyya
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e07d0dd ]

fixed CLOUDSTACK-6261: remove the forceful timeout setting when login to 
NetScaler.


- ASF Subversion and Git Services


On July 8, 2014, 9:28 a.m., Sujaya Maiyya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22927/
> ---
> 
> (Updated July 8, 2014, 9:28 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6261
> https://issues.apache.org/jira/browse/CLOUDSTACK-6261
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The NetScaler Resource forces a idle timeout of 100,000 seconds during login. 
> It is best to leave it to the system default which is 30 mins. The timeout 
> has been removed from NetscalerResource in order to support login for 
> Netscaler 10.5 devices.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  ff51ef9 
> 
> Diff: https://reviews.apache.org/r/22927/diff/
> 
> 
> Testing
> ---
> 
> Timeout was removed and login to the Netscaler devices with the default 
> timeout of 30 minutes was successful. It was tested for Netscaler builds 10.1 
> and 10.5.
> 
> 
> Thanks,
> 
> Sujaya Maiyya
> 
>

Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin

[Suresh Ramamurthy]

> On July 8, 2014, 10:07 a.m., Hugo Trippaers wrote:
> > plugins/network-elements/nuage-vsp/src/com/cloud/network/resource/NuageVspResource.java,
> >  line 196
> > 
> >
> > I'm not really agreeing with this method of loading the client. The 
> > client should be loaded using the classloader.
> > 
> > Is the library available from maven central or is distribution 
> > restricted? If the latter case we need to move this plugin and the 
> > dependency on the library to the noredist build.
> 
> Suresh Ramamurthy wrote:
> Yes, NuageVsp plugin client library is distribution restricted. I had 
> some design question regarding dropping the library and loading it 
> dynamically. Please find below our requirement'
> 
> 1) We wanted to drop our NuageVsp plugin client after installing 
> CloudStack. 
> 2) We wanted to create an NuageVsp plugin Client RPM and then install the 
> RPM that copies in a location. The location could be some other location that 
> NuageVsp Plugin client chooses.
>In this case I thought of copying it under 
> /usr/share/cloudstack-management/webapps/client/WEB-INF/lib but it could be 
> different location
> 3) Then restart CloudStack.
> 4) When NuageVsp Device is added, then the class files will be 
> dynamically loaded and things will work seamlessly
> 
> Advantages of above approach:
> 
> 1) Cloudstack build does not have any dependency on our jar files. This 
> is because, we do not have any reference of NuageVsp Plugin client code 
>and the client classes are loaded dynamically
> 2) There is no maven central dependency
> 3) Version Upgrade of NuageVsp Plugin client does not depend on 
> Cloudstack version. We will just uninstall our RPM and re-install the new 
> version of NuageVsp Plugin client code and restart CloudStack
> 
> Hugo, above was our suggestion. Is it okay to follow the above approach 
> of loading the Plugin Client files? 
> 
> If the above approach is not acceptable then we are open to follow the 
> noredist build approach. If we are following the noredist build approach then 
> I just want to clarify the procedure to be
> followed to use NuageVsp Plugin
> 
> 1) User needs to download NuageVsp Plugin client jar file
> 2) Copy the jar under deps folder
> 3) Run install-non-oss.sh
> 4) Build RPM using -p NOREDIST option
> 
> Could you please let me know details of the forum where we can have 
> design discussions?
> 
> I know, I am asking too many question :)
> 
> Thanks reviewing and supporting us.
>
> 
> Hugo Trippaers wrote:
> That makes sense, thanks for the clarification. I think we can work that 
> way, actually our plugin system is designed to work in such a way that the 
> entire plugin could technically be separated into an rpm package. 
> 
> Probably the best way to go forward is to agree on a file location. 
> Probably something like /usr/share/nuage/lib for unix alike systems is a 
> better place to store the library. The actual location would need to be 
> configured as a global setting in CloudStack and passed to the resource 
> during initialization. 
> 
> However to use this type of loading i would like to make sure that a user 
> will receive a clear error message explaining that the correct library is not 
> installed when it tries to use it. 
> 
> For functional testing this introduces number of problems as only people 
> with access to those libraries can do any kind of testing on the library or 
> are you delivering a stub together with the functional tests so we can 
> integrate it in the functional test stream.
> 
> In short, i'm ok with this type of loading, provided:
>   * we have a way of testing the plugin or execute functional tests 
> against something that has access to the libraries.
>   * the cloudstack plugin documentation makes it clear that the plugin 
> requires an additional library.
>   * the user receives an error message when he tries to configure the 
> nauge plugin in cloudstack without the library.
> 
> I'll take the question whether or not we need to put this plugin in the 
> noredist build to the dev-list as i would like some more input on that.

Hi Hugo,

Thanks for quick response.

Please find my response below for you comments

  * we have a way of testing the plugin or execute functional tests against 
something that has access to the libraries.

 We are doing functional testing here at Nuage Networks. Will community 
also perform functional test. Could you 
 please clarify me regarding what kind of functional testing does the 
community perform. Could you please point me
 to any document? As our plugin will need additional library and an SDN 
setup, how will community test it. Let me 
 know so that I can work on that ASAP

  * the clou

Re: [CASE STUDY] GreenQloud Accelerates the Market Adoption of a Cleaner Cloud and Offers a Full Cloud Infrastructure Stack Built on Apache CloudStack

[ilya musayev]

Karen

Thanks for posting this. Folk please re-tweet!

Regards
ilya
On 7/8/14, 5:21 PM, Karen Vuong wrote:

Hi all,



A new case study has been published, titled, GreenQloud Accelerates the
Market Adoption of a Cleaner Cloud and Offers a Full Cloud Infrastructure
Stack Built on Apache CloudStack.



Click-to-tweet - http://ctt.ec/cd29Q: [CASE STUDY] Built on #CloudStack,
#GreenQloud accelerates the market adoption of a cleaner cloud -
clds.co/1oh8HPv #opensource #cloud



Thanks,



Karen

Re: [CASE STUDY] GreenQloud Accelerates the Market Adoption of a Cleaner Cloud and Offers a Full Cloud Infrastructure Stack Built on Apache CloudStack

[ilya musayev]

Karen

Thanks for posting this. Folks please re-tweet!

Regards
ilya
On 7/8/14, 5:21 PM, Karen Vuong wrote:

Hi all,



A new case study has been published, titled, GreenQloud Accelerates the
Market Adoption of a Cleaner Cloud and Offers a Full Cloud Infrastructure
Stack Built on Apache CloudStack.



Click-to-tweet - http://ctt.ec/cd29Q: [CASE STUDY] Built on #CloudStack,
#GreenQloud accelerates the market adoption of a cleaner cloud -
clds.co/1oh8HPv #opensource #cloud



Thanks,



Karen

Re: [Help] Help for setting up Vmware Cluster in CloudStack...

[ilya musayev]

Ritu,

That tutorial is a bit old.

Let me try to answer them, i do have an alternative solution, perhaps we 
can get on the phone and do a webex session or something similar - this 
week is bad for me, i'm traveling, but next week, Thursday and beyond - 
my schedule is flexible. I assume you are on PST timezone somewhere in 
bay area.


Please see response inline to your inquiries.



On 7/8/14, 6:29 PM, Ritu Sabharwal wrote:


Hi Ilya,

I am trying to add VMWare DC for the first time in CloudStack 
management server and need help in doing so. I am trying to test the 
Brocade Network Plugin functionality. The Jira id is : 
https://issues.apache.org/jira/browse/CLOUDSTACK-6823


I am following the Tutorial: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step


My Network setup:

1.2 ESXi hosts 4.1.0 hosts.

2.vCenter 5.0

Network layout:

vSwitch0: For Management Network

vSwitch0: for Guest Network

vSwitch0 is assigned 1 Physical Nic. This Nic is connected to Brocade 
VDX switch.


My test includes:

  * Create an isolated network; verify that the port-profile is
created on the Brocade switch.
  * Attach a VM to the network; verify that the VMs MAC address is
associated with the port profile of the network on the Brocade switch.
  * Add VMs to the same guest network but on different hosts and
verify connectivity.
  * Check the availability of the switch by using the CloudStack API:

http://:8096/client/api?command=listHosts&type=L2Networking.
This should list the switch with its availability status.
  * Delete VMs for an isolated network; verify that the VMs MAC
address is disassociated with the port profile of the network on
the Brocade switch.
  * Delete the isolated network; verify that the port-profile is
deleted from the Brocade switch.

I have few questions:

1.Where do I download the system vm template for vmware. I am using 
master CS codebase, I don't have the script 
/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt


The path is incorrect, this use to apply to CloudStack 4.0 or 4.1, but 
anything post 4.2 has cloudstack in its path.

Here is the snippet of my install script:

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m /mnt/nfs/secondary -u 
http://my-webserver/systemvm64template-latest-master-vmware.ova -h vmware -F


Note that /mnt/nfs/secondary - is nfs mount - either local or remote
That mount must be accessible by hypervisors. Cloudstack needs to access 
hypervisors and vcenter on port 443.


2.Since I am testing L2 connectivity b/w VMs using Brocade switches by 
configuring the VLANs( by creating port-profiles) for the network on 
the switches, do I need to assign a IP range for Public network and 
storage network?


Depends on your setup. Storage network is used when you have a separate 
segregated NFS or alike storage network. In that case, that storage 
network must be trunked  to you hypervisors.
If you are deploying for POC and you dont have a specific storage 
network, dont add storage network traffic label.
Public network - also depends on your setup, if you are doing Advanced 
Zone with VPC (amazon like cloud), you will need a larger IP pool as you 
want to assign public IPs to your guest VMs. However, if you are 
deploying Advanced Shared  Zone without VPC, where you are using your 
physical network and routers/firewalls, then all you need is 2 public 
ips per zone - which arent really public in the internet sense.


3.In the tutorial, there are 2 portgroups for VMs on Managemnt Network 
and Development Network? What are these 2 types of VMs?



Cloudstack deploys System VMs in following fashion.
Per zone, you have:

Advanced Shared Zone (non VPC)
- Storage VM - doing storage things
   uses 1 public ip and 1 management ip (private communication link)

- Console Proxy VM - proxies VNC console session from hypervisor to end user
   uses 1 public ip and 1 management ip (private communication link)

- RouterVM - 1 per VLAN
   uses 1 management ip (private communication link)

Advanced Shared Zone (VPC - dont use this type of env so i'm not certain 
- but from what i'm told)

- Storage VM - doing storage things
   uses 1 public ip and 1 management ip (private communication link)

- Console Proxy VM - proxies VNC console session from hypervisor to end user
   uses 1 public ip and 1 management ip (private communication link)

- RouterVM - 1 per VLAN per Account
   uses 1 management ip (private communication link)


4.For primary storage, do I give the datastore attached to the 
hypervisor hosts?


It depends yet again :) If you have VMFS datastores, then yes you have 
to specify existing VMFS store already defined in vCenter.

If you are doing NFS, then cloudstack will create it on your behalf.

Regards
ilya


Any help is appreciated.

Thanks & Regards,

Ritu S.

Live migration failed on 4.4 branch with KVM hypervisor

[Yoshikazu Nojima]

Hi,

I made a new blocker ticket for 4.4 branch.
"Live migration failed on 4.4 branch with KVM hypervisor".
https://issues.apache.org/jira/browse/CLOUDSTACK-7086

Since this is a regression, I filed as a blocker.

Regards,
Noji

Re: Review Request 23314: Plugin specific code for the Brocade Network Plugin

[Ritu Sabharwal]

> On July 8, 2014, 9:29 a.m., Hugo Trippaers wrote:
> > Thanks for make this a separate review, much easier to read.
> > 
> > The licenses are not added to all files and in some files they appear not 
> > to be complete. A good trick to solve this is to include the 
> > license-maven-plugin in the build section. See 
> > plugins/network-elements/nicira-nvp/pom.xml for an example.
> > 
> > Also the plugin doesn't contain any tests. We need unit tests or functional 
> > tests (and preferably both) to validate that this plugin works and keeps on 
> > working in future versions of CloudStack. It would be great if you could 
> > supply unit tests to validate this inner workings of this module and marvin 
> > based integration tests that we can run to see if this work with the 
> > intended hardware.
> > 
> > The last general point is that we would also need documentation on this 
> > plugin so administrators will know how to use this.
> 
> Ritu  Sabharwal wrote:
> Thanks for reviewing the code.
> 
> I have fixed the license in all the files.
> 
> I am working on writing the unit tests for the plugin.
> 
> I am working on providing the documentation on using the plugin.
> 
> I have tested the plugin with the simulator and see the configurations on 
> Brocade switches happening. Currently, I am setting up a real hardware setup 
> with Vmware hypervisor and Brocade switches so test the connectivity between 
> spawned VMs.
> 
> Can I continue writing the unit tests and marvin integration tests and 
> documentation after the July 19 date so that this plugin makes to 4.5 feature 
> freeze date.
> 
> I have updated the diffs with the changes for the license and other 
> comments.
> 
> Ritu  Sabharwal wrote:
> I am planning to include the following in the documentation:
>  - Brocade switch setup
>  - Connections to the Hypervisor hosts
>  - the flow to use the plugin from UI
> 
> Hugo Trippaers wrote:
> Thanks for fixing the open issues.
> 
> I think it's ok to work on the documentation while a release is being 
> tested (eventhough it is far better to have it ready for the testers). 
> However unittests and functional testcases need to be there before we can 
> merge the plugin. Without it we can not properly test the plugin to see if it 
> is fit to be part of the release. 
> 
> I'd rather have a completely done plugin in the 4.6 release than 
> something that is not complete in 4.5. So currently the blockers for a merge 
> into master are the two property files and we need unit and integration tests.

Hi Hugo,

Thanks for reviewing the plugin.

Few points:

1. The configuration using properties file was part of the Design document 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Brocade+Network+Plugin+to+Orchestrate+Brocade+VDX+Switches
 and was not raised as a concern earlier and the implementation is based on 
that.  

Changing the implementation right now would involve some work. Can this be done 
as an enhancement as part of bug fix during testing?

2. For functional testcases, we are doing functional testing but how will 
functional testcases be run by the community without the Brocade hardware? 

We are working on writing the unit and functional testcases.


- Ritu


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23314/#review47435
---


On July 8, 2014, 6:49 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23314/
> ---
> 
> (Updated July 8, 2014, 6:49 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Plugin specific code.
> 
> 
> Diffs
> -
> 
>   plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema.xsd 
> PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSchema.xsd 
> PRE-CREATION 
>   plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.xsd 
> PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/module.properties
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/spring-vcs-context.xml
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkAnswer.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkCommand.java
>  PRE-CREATION 
>   
> plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/Cre

RE: [Help] Help for setting up Vmware Cluster in CloudStack...

[Ritu Sabharwal]

Hi Ilya,

Thanks for your replies.

This is really helpful. We can surely get into some video conferencing and get 
this setup ready. I am in San Jose, CA.

Thanks & Regards,
Ritu S.

From: ilya musayev [mailto:ilya.mailing.li...@gmail.com]
Sent: Wednesday, July 09, 2014 12:58 PM
To: Ritu Sabharwal; Hugo Trippaers
Cc: dev@cloudstack.apache.org
Subject: Re: [Help] Help for setting up Vmware Cluster in CloudStack...

Ritu,

That tutorial is a bit old.

Let me try to answer them, i do have an alternative solution, perhaps we can 
get on the phone and do a webex session or something similar - this week is bad 
for me, i'm traveling, but next week, Thursday and beyond - my schedule is 
flexible. I assume you are on PST timezone somewhere in bay area.

Please see response inline to your inquiries.



On 7/8/14, 6:29 PM, Ritu Sabharwal wrote:

Hi Ilya,

I am trying to add VMWare DC for the first time in CloudStack management server 
and need help in doing so. I am trying to test the Brocade Network Plugin 
functionality. The Jira id is : 
https://issues.apache.org/jira/browse/CLOUDSTACK-6823

I am following the Tutorial: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step

My Network setup:


1.   2 ESXi hosts 4.1.0 hosts.

2.   vCenter 5.0

Network layout:

vSwitch0: For Management Network
vSwitch0: for Guest Network

vSwitch0 is assigned 1 Physical Nic. This Nic is connected to Brocade VDX 
switch.


My test includes:

 *   Create an isolated network; verify that the port-profile is created on the 
Brocade switch.
 *   Attach a VM to the network; verify that the VMs MAC address is associated 
with the port profile of the network on the Brocade switch.
 *   Add VMs to the same guest network but on different hosts and verify 
connectivity.
 *   Check the availability of the switch by using the CloudStack API: 
http://:8096/client/api?command=listHosts&type=L2Networking.
 This should list the switch with its availability status.
 *   Delete VMs for an isolated network; verify that the VMs MAC address is 
disassociated with the port profile of the network on the Brocade switch.
 *   Delete the isolated network; verify that the port-profile is deleted from 
the Brocade switch.

I have few questions:

1.   Where do I download the system vm template for vmware. I am using 
master CS codebase, I don't have the script 
/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt
The path is incorrect, this use to apply to CloudStack 4.0 or 4.1, but anything 
post 4.2 has cloudstack in its path.
Here is the snippet of my install script:

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m /mnt/nfs/secondary -u 
http://my-webserver/systemvm64template-latest-master-vmware.ova -h vmware -F

Note that /mnt/nfs/secondary - is nfs mount - either local or remote
That mount must be accessible by hypervisors. Cloudstack needs to access 
hypervisors and vcenter on port 443.


2.   Since I am testing L2 connectivity b/w VMs using Brocade switches by 
configuring the VLANs( by creating port-profiles) for the network on the 
switches, do I need to assign a IP range for Public network and storage network?
Depends on your setup. Storage network is used when you have a separate 
segregated NFS or alike storage network. In that case, that storage network 
must be trunked  to you hypervisors.
If you are deploying for POC and you dont have a specific storage network, dont 
add storage network traffic label.
Public network - also depends on your setup, if you are doing Advanced Zone 
with VPC (amazon like cloud), you will need a larger IP pool as you want to 
assign public IPs to your guest VMs. However, if you are deploying Advanced 
Shared  Zone without VPC, where you are using your physical network and 
routers/firewalls, then all you need is 2 public ips per zone - which arent 
really public in the internet sense.


3.   In the tutorial, there are 2 portgroups for VMs on Managemnt Network 
and Development Network? What are these 2 types of VMs?
Cloudstack deploys System VMs in following fashion.
Per zone, you have:

Advanced Shared Zone (non VPC)
- Storage VM - doing storage things
   uses 1 public ip and 1 management ip (private communication link)

- Console Proxy VM - proxies VNC console session from hypervisor to end user
   uses 1 public ip and 1 management ip (private communication link)

- RouterVM - 1 per VLAN
   uses 1 management ip (private communication link)

Advanced Shared Zone (VPC - dont use this type of env so i'm not certain - but 
from what i'm told)
- Storage VM - doing storage things
   uses 1 public ip and 1 management ip (private communication link)

- Console Proxy VM - proxies VNC console session from hypervisor to end user
   uses 1 public ip and 1 management ip (private communication link)

- RouterVM - 1 per VLAN per Account
   uses 1 management ip (private communication link)

For primary s

Re: Live migration failed on 4.4 branch with KVM hypervisor

[Yoshikazu Nojima]

It seems I faced this issue, which is not related to CloudStack.
https://pthree.org/2012/06/15/libvirt-tyan-motherboards-and-uuid/

I will close the ticket.

Regards,
Noji

2014-07-09 14:12 GMT-06:00 Yoshikazu Nojima :
> Hi,
>
> I made a new blocker ticket for 4.4 branch.
> "Live migration failed on 4.4 branch with KVM hypervisor".
> https://issues.apache.org/jira/browse/CLOUDSTACK-7086
>
> Since this is a regression, I filed as a blocker.
>
> Regards,
> Noji

Re: [Help] Help for setting up Vmware Cluster in CloudStack...

[ilya musayev]

I'm in Sunnyvale. I've been trying to do a meetup and perhaps demo the 
whole vmware/cloudstack setup, but i never really got to do this.


Hopefully, we can put something together for July or early August 
timeframe for the meetup.


Also, Router VMs have 1 Management and 1 Guest IP - just realized i 
missed it.


If i can give you a suggestion in the meantime, try to get your setup 
working with stable 4.3. Once you figure the process out - which is 
really not that difficult in my opinion (should take 10-30 minutes at 
most - granted you have everything pre-set), then try it with master 
codebase, and only then master codebase and your patch.


You did not mention if you are using VLAN tagging btw. Not that it 
matters greatly, but consider using newer vSphere, you can download 
trials from VMware site, you can even do a nested setup and run many 
vSphere CloudStack environments for dev/qa - which is what i've been 
doing lately. You have 60 day trial, post that, you can reset the 
environment to be compliant with vmware licensing model - needless to 
say, this can be semi or completely automated, depends how much effort 
you want to put into this. I'd double check this with vmware rep to be 
on the safe side.




On 7/9/14, 5:36 PM, Ritu Sabharwal wrote:


Hi Ilya,

Thanks for your replies.

This is really helpful. We can surely get into some video conferencing 
and get this setup ready. I am in San Jose, CA.


Thanks & Regards,

Ritu S.

*From:*ilya musayev [mailto:ilya.mailing.li...@gmail.com]
*Sent:* Wednesday, July 09, 2014 12:58 PM
*To:* Ritu Sabharwal; Hugo Trippaers
*Cc:* dev@cloudstack.apache.org
*Subject:* Re: [Help] Help for setting up Vmware Cluster in CloudStack...

Ritu,

That tutorial is a bit old.

Let me try to answer them, i do have an alternative solution, perhaps 
we can get on the phone and do a webex session or something similar - 
this week is bad for me, i'm traveling, but next week, Thursday and 
beyond - my schedule is flexible. I assume you are on PST timezone 
somewhere in bay area.


Please see response inline to your inquiries.



On 7/8/14, 6:29 PM, Ritu Sabharwal wrote:

Hi Ilya,

I am trying to add VMWare DC for the first time in CloudStack 
management server and need help in doing so. I am trying to test the 
Brocade Network Plugin functionality. The Jira id is : 
https://issues.apache.org/jira/browse/CLOUDSTACK-6823


I am following the Tutorial: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step


My Network setup:

1.2 ESXi hosts 4.1.0 hosts.

2.vCenter 5.0

Network layout:

vSwitch0: For Management Network

vSwitch0: for Guest Network

vSwitch0 is assigned 1 Physical Nic. This Nic is connected to Brocade 
VDX switch.


My test includes:

  * Create an isolated network; verify that the port-profile is
created on the Brocade switch.
  * Attach a VM to the network; verify that the VMs MAC address is
associated with the port profile of the network on the Brocade switch.
  * Add VMs to the same guest network but on different hosts and
verify connectivity.
  * Check the availability of the switch by using the CloudStack API:

http://:8096/client/api?command=listHosts&type=L2Networking.
This should list the switch with its availability status.
  * Delete VMs for an isolated network; verify that the VMs MAC
address is disassociated with the port profile of the network on
the Brocade switch.
  * Delete the isolated network; verify that the port-profile is
deleted from the Brocade switch.

I have few questions:

1.Where do I download the system vm template for vmware. I am using 
master CS codebase, I don't have the script 
/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt


The path is incorrect, this use to apply to CloudStack 4.0 or 4.1, but 
anything post 4.2 has cloudstack in its path.

Here is the snippet of my install script:

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt 
-m /mnt/nfs/secondary -u 
http://my-webserver/systemvm64template-latest-master-vmware.ova -h 
vmware -F


Note that /mnt/nfs/secondary - is nfs mount - either local or remote
That mount must be accessible by hypervisors. Cloudstack needs to 
access hypervisors and vcenter on port 443.


2.Since I am testing L2 connectivity b/w VMs using Brocade switches by 
configuring the VLANs( by creating port-profiles) for the network on 
the switches, do I need to assign a IP range for Public network and 
storage network?


Depends on your setup. Storage network is used when you have a 
separate segregated NFS or alike storage network. In that case, that 
storage network must be trunked  to you hypervisors.
If you are deploying for POC and you dont have a specific storage 
network, dont add storage network traffic label.
Public network - also depends on your setup, if you are doing Advanced 
Zone with VPC (amazon like cloud), you will need a larger IP pool as 
you want