Re: Removal of cloud-plugin-netapp

[Chiradeep Vittal]

It could enable a volume service for baremetal, but currently it is too
tied to NetApp.


On 9/18/13 11:35 AM, "Alex Huang"  wrote:

>I think it should be removed.
>
>--Alex
>
>> -Original Message-
>> From: SuichII, Christopher [mailto:chris.su...@netapp.com]
>> Sent: Wednesday, September 18, 2013 5:26 AM
>> To: 
>> Subject: Removal of cloud-plugin-netapp
>> 
>> I remember seeing/hearing some discussion about removing the cloud-
>> plugin-netapp component since it is not used or really managed any
>>more. Is
>> this still in the works? One of the dependencies (manageontap.jar) will
>> conflict with one of the dependencies of our (in development) plugin.
>>The
>> version of manageontap.jar used by CloudStack is different than what we
>> require in our plugin and would likely cause runtime issues if still
>>included in
>> the MS classpath.
>> 
>> Any thoughts?
>> 
>> Thanks,
>> Chris
>> --
>> Chris Suich
>> chris.su...@netapp.com
>> NetApp Software Engineer
>> Data Center Platforms - Cloud Solutions
>> Citrix, Cisco & Red Hat
>

Re: [Merge] Minimal Hyper-V Plugin

[Chiradeep Vittal]

Thanks for the preliminary testing.
Questions:
1. More for the community: should the C# code be in a separate repo?
According to the merge request, mono and maven can be used to build the
agent.
2. Packaging: how is the C# agent installed?
3. What does minimal mean? What works? What doesn't? Local storage? Shared
storage? Networking modes? Are the hypervisors supposed to be clustered?
4. How does one extend the "minimal" plugin?
5. Can the unit tests (at least those that test the agent API) be run in a
non-hyper-v environment?
6. Is the RDP console you had earlier mentioned included in the merge?
7. Any known issues?

On 9/11/13 8:00 AM, "Donal Lafferty"  wrote:

>Hi Rajesh,
>
>Thanks for spotting this problem with the Hyper-V Agent.  Sounds like it
>should first URL decode the field.
>
>Can you update the review with details of your testing?
>
>I would need to know the command and which incoming field is causing
>problems.  Also, can you add a serialised example of the instruction that
>fails?  There should be an example in the agent's log file.  By default,
>the log file is in the same folder as the agent executable.  I will use
>this to update the automated tests.
>
>If you want to go ahead and made the fixes from a git clone, send a Pull
>Request.  As long as there is an appropriate automated test, I'll update
>the feature branch with your changes.
>
>
>DL
>
>> -Original Message-
>> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
>> Sent: 11 September 2013 09:08
>> To: dev@cloudstack.apache.org
>> Subject: RE: [Merge] Minimal Hyper-V Plugin
>> 
>> Hi Donal,
>> I had figured out the issue why "+" is coming in the path value.
>> The root cause is while encoding the URI, we use URLEncoder.encode(path)
>> 
>> The encode method is converting/replace "space" with "+".
>> 
>> API doc:
>> When encoding a String, the following rules apply:
>> 
>> The alphanumeric characters "a" through "z", "A" through "Z" and "0"
>> through "9" remain the same.
>> The special characters ".", "-", "*", and "_" remain the same.
>> The space character " " is converted into a plus sign "+".
>> All other characters are unsafe and are first converted into one or more
>> bytes using some encoding scheme. Then each byte is represented by the
>>3-
>> character string "%xy", where xy is the two-digit hexadecimal
>>representation
>> of the byte. The recommended encoding scheme to use is UTF-8. However,
>> for compatibility reasons, if an encoding is not specified, then the
>>default
>> encoding of the platform is used.
>> 
>> Thanks
>> Rajesh Battala
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
>> Sent: Monday, September 2, 2013 3:03 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [Merge] Minimal Hyper-V Plugin
>> 
>> Hi Rajesh,
>> 
>> I'll PM the scripts.
>> 
>> WRT problem below, it looks like a CS persists paths with spaces as URL
>> encoded strings.  Is it the Hyper-V code storing the path in the wrong
>> formant?  I can fix that if it's an issue.
>> 
>> I would be very reluctant to change the the format of columns in the
>> database. There will be other code reliant on URL encoding.
>> 
>> DL
>> 
>> 
>> > -Original Message-
>> > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
>> > Sent: 02 September 2013 08:37
>> > To: dev@cloudstack.apache.org
>> > Subject: RE: [Merge] Minimal Hyper-V Plugin
>> >
>> > Hi Donal,
>> > One more issue is, currently local storage is discovered when host is
>>added.
>> > But when mgmt. server got restarted,  there is an exception happening
>> > while add/discovering already existing local storage pool.
>> >
>> >
>> > Root cause:
>> > ==
>> > I had debugged and figured out the root cause,  CS not able to find
>> > the storage pool and tries to created it but it fails to add to DB as
>> > the entry is already persisted.
>> > The reason why CS not able to get the existing localstorage is , when
>> > executing the query to get the storage pool, it's getting empty set .
>> > It's because of the storage path issue.
>> > In the db the local storage path is stored as
>> > "C:\Users\Public\Documents\Hyper-V\Virtual+Hard+Disks",  ('+' symbol
>> > in place of space) In the db query its searching without "+" and with
>> > space which is causing the query to have empty set and hence the
>> > issue.
>> >
>> > I can fix the issue by removing the "+" when we are persisting the
>> > local storage pool from hyperv
>> >
>> >
>> >
>> > Exception:
>> > =
>> > WARN  [c.c.r.ResourceManagerImpl] (AgentTaskPool-14:ctx-ddbbf089)
>> > Unable to connect due to
>> > com.cloud.exception.ConnectionException: Unable to setup the local
>> > storage pool for Host[-1-Routing]
>> > at
>> >
>> com.cloud.storage.StorageManagerImpl.createLocalStorage(StorageManage
>> > rImpl.java:598)
>> > at
>> >
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercep
>> > torDispatcher.intercept(ComponentInstantia

Re: conflicting dependencies between CloudStack and Whirr

[Chiradeep Vittal]

I don't think adding an API to CloudStack is particularly appropriate way
to integrate with whirr? Whirr should *use* the CloudStack API, not add to
it?

On 9/20/13 1:09 AM, "Sebastien Goasguen"  wrote:

>
>On Sep 20, 2013, at 12:45 AM, Hugo Trippaers  wrote:
>
>> 
>> The Nicira NVP plugin is also depending on gson. If we make any changes
>>we need to validate against their api to ensure that the interface still
>>works.
>> 
>> If we put the changes in a separate branch i'd be happy to run the
>>changes against the api.
>> 
>> Cheers,
>> 
>> Hugo
>
>So how can Meng get out of this bind, she is trying to complete her
>google summer of code project.
>
>thanks,
>
>-Sebastien
>
>> 
>> 
>> On Sep 20, 2013, at 12:08 PM, Darren Shepherd
>> wrote:
>> 
>>> After much searching I found the two lines of code I needed to get it
>>>to serialize right.  I'll keep looking and see if I find other snags.
>>>Maybe we can just move to jackson we'll see, haven't tried to
>>>deserialize yet.
>>> 
>>> Darren
>>> 
 On Sep 19, 2013, at 4:25 PM, Alex Huang  wrote:
 
 Darren,
 
 When I looked into updating to the latest gson, the problem, IIRC, is
things that weren't considered cyclical dependencies are suddenly
considered cyclical with the latest.  I don't recall where though.
 
 --Alex
 
> -Original Message-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Thursday, September 19, 2013 1:33 PM
> To: dev@cloudstack.apache.org
> Subject: Re: conflicting dependencies between CloudStack and Whirr
> 
> Alright, I looked into this and it will take a bit more work to
>switch to Jackson.
> The snag I hit was how we serialize commands for the agents.  We use
>a
> customer typeadatper in gson to produce a format like { "org.MyClass"
> : {...} }.  In jackson I don't see producing a similar format as
>being so straight
> forward.  I'm sure there's an elegant solution, but I didn't
>immediately find it.
> The problem is if you use a custom serializer in jackson and do
> writeObjectField(x.getClass().getName(), x), you'll get stuck in a
>loop
> because it will call your serializer again.  So if somebody can
>figure out how to
> do this format easily in jackson, the rest looks simple enough.
> 
> So, being that it is not an obvious switch to using jackson, what is
>the impact
> of moving to the latest gson?  What were the issue encountered when
> people tried it before?
> 
> Darren
> 
> 
> On Wed, Sep 18, 2013 at 4:42 PM, Darren Shepherd <
> darren.s.sheph...@gmail.com> wrote:
> 
>> I can do some analysis on this.  I'm always up for a terribly
>>painful
>> refactor :)
>> 
>> Darren
>> 
>> 
>>> On Wed, Sep 18, 2013 at 4:06 PM, Alex Huang 
>> wrote:
>> 
>>> I actually did a quick try to update cloudstack to use newest gson
>>> version about 3 months back.  Had to roll it back but I didn't try
>>> very hard though.  Part of the reason why I decided to rollback is
>>> due to gson is used differently by various components in CloudStack
>>> and I didn't have time to get into each component to see if I break
>>> anything.  The other is also I thought using Jackson would be much
>>> better and thought our next attempt should be with Jackson.
>>> 
>>> Not that any of these helps you.  Just know updating CloudStack to
>>> latest gson is not simple.
>>> 
>>> --Alex
>>> 
 -Original Message-
 From: Andrei Savu [mailto:savu.and...@gmail.com]
 Sent: Wednesday, September 18, 2013 10:53 AM
 To: d...@whirr.apache.org
 Cc: dev@cloudstack.apache.org
 Subject: Re: conflicting dependencies between CloudStack and Whirr
 
 It's easy to usr jclouds and whirr inside an OSGi container - just
 add
>>> the
 feature url. Bonus: you can also use jclouds shell interface (part
 of
>>> jclouds cli).
 
 Another option is to upgrade the CloudStack API to use the new
version.
> On Sep 18, 2013 5:14 AM, "Han,Meng"  wrote:
> 
> Dear all,
> 
> I am adding an API to CloudStack which utilizes Whirr to launch
> various clusters on CloudStack. Now I am facing a dependency
>>> conflicting
 issue.
> 
> Whirr 0.8.2 requires gson 2.2.2 while CloudStack API requires
> gson
>>> 1.7.1.
> If I use gson 1.7.1 for Whirr, the following error will happen:
> 
> com.google.common.util.**concurrent.ExecutionError:
 java.lang.**NoClassDefFoundError:
> com/google/gson/TypeAdapter
> 
> This TypeAdapter class can be found inside gson-2.2.2.jar.
> However if I modify CloudStack to use gson 2.2.2 CloudStack will
> not build successfully

Re: API extract exact name

[Chiradeep Vittal]

Is this the same issue as
https://issues.apache.org/jira/browse/CLOUDSTACK-3080

On 9/20/13 2:33 PM, "Ian Duffy"  wrote:

>Hi,
>
>It possible extract a specific virtualmachine from listvirtualmachines
>by giving a name name field?
>
>Basically, I want equality instead of like. I'm having an issue where
>by I have a bunch of virtual machines: 'test', 'test2', 'test3'.
>Calling listvirtualmachines with a name field supplied results in them
>all being returned not sorted by closest matching.
>
>Thanks,
>Ian

Re: SSHException('Error reading SSH protocol banner',) while sshing to a machine behind a load balancing rule

[Chiradeep Vittal]

What tool/library are you using to perform the SSH?
SSH is not a good way to test the algorithm. How are you going to test
other stickiness methods?
Best to use good old HTTP.

On 9/22/13 9:30 PM, "Ashutosh Kelkar"  wrote:

>I am currently trying to validate the stickiness policy of a load
>balancing
>rule by sshing to the public IP of the LB rule and verifying that the
>request goes to the same machine every time.
>
>Here is the config I use to create the LB rule.
>
>"lbrule": {
>
>"name": "SSH",
>"alg": "roundrobin",
># Algorithm used for load balancing
>"privateport": 22,
>"publicport": 22,
>"openfirewall": True,
>"startport": 22,
>"endport": ,
>"protocol": "TCP",
>"cidrlist": '0.0.0.0/0',
>},
>
>My ssh attempts fail with the following error : SSHException('Error
>reading
>SSH protocol banner',)
>
>Is there some more setup that is needed for SSH to work correctly? The SSH
>error points to a possible firewall configuration issue.
>
>Regards
>Ashutosh

Re: [PROPOSAL] adding [SOLVED] tag in mailing list subject

[Chiradeep Vittal]

Excellent suggestion

On 9/23/13 6:50 AM, "Jayapal Reddy Uradi" 
wrote:

>Hi,
>
>When the issues raised in dev/users mailing lists are solved by using
>suggestions/solutions as replies
>send by community members then the one who raised the issue please reply
>to the thread by adding [SOLVED] tag.
>
>
>Also please add the accumulated steps performed to solve it, this will
>helpful to other members when they gets the similar issues.
>
>Thanks,
>Jayapal
>

Re: Removal of cloud-plugin-netapp

[Chiradeep Vittal]

If you remove it, it will break the following APIs:

createPool
createVolumeOnFiler
createLunOnFiler
AssociateLun

Here's how it is used:
The steps are

1. create a volume pool using the createPool

API (algorithm can be "leastfull" or "roundrobin")
2. add volumes to the pool using the createVolumeOnFiler
 API. This requires the IP address of the NetApp filer and its
credentials
3. create LUNs in the volume pool using createLunOnFiler
  API. Depending on the algorithm for the pool, CloudStack will choose
the NetApp Volume to create the LUN.


Once a bare metal host / vm has booted up, you need to determine its ISCSI
initiator iqn and then use the
AssociateLUN 

 API set the LUN mask on the filer for that LUN. Then the ISCSI initiator
on the bare metal host / vm can login to the LUN.



On 9/23/13 10:32 AM, "Chip Childers"  wrote:

>On Mon, Sep 23, 2013 at 04:44:51PM +, SuichII, Christopher wrote:
>> I'd like to get a final word on this - is it OK to be removed? Is there
>>someone who is knowledgable with what it will take to remove it and/or
>>is comfortable removing it? I don't know how tied into the rest of the
>>codebase it is.
>
>I'm +1 to remove, but there are artifacts all over the place (UI, DB,
>code).  It might require some careful work to extract it cleanly.
>
>Any takers?
>
>-chip

Re: conflicting dependencies between CloudStack and Whirr

[Chiradeep Vittal]

I still think this is the wrong way to implement the Whirr integration.

On 9/23/13 6:45 AM, "sebgoa"  wrote:

>
>On Sep 23, 2013, at 7:12 AM, Darren Shepherd
> wrote:
>
>> The only way this will get committed is if we either move to latest
>>gson or
>> jackson.  Regardless, the outcome will be that Meng can assume this gson
>> conflict won't happen.  The problem is just how fast can we move all of
>>ACS
>> to a new json library.  Is it possible for Meng to commit to a branch
>>that
>> just blindly updates gson to the latest (in /pom.xml).
>
>Yes I will talk to Meng about this. thanks
>
>> When we get ACS on
>> a newer json library, we can merge in that branch.  Tomorrow (9/23), I
>>can
>> attempt to put together a patch to move to jackson.  I think I ironed
>>out
>> most of the technical issues so I just have to globally apply the
>>changes.
>> 
>> Darren
>> 
>> 
>> On Fri, Sep 20, 2013 at 1:09 AM, Sebastien Goasguen
>>wrote:
>> 
>>> 
>>> On Sep 20, 2013, at 12:45 AM, Hugo Trippaers  wrote:
>>> 
 
 The Nicira NVP plugin is also depending on gson. If we make any
changes
>>> we need to validate against their api to ensure that the interface
>>>still
>>> works.
 
 If we put the changes in a separate branch i'd be happy to run the
>>> changes against the api.
 
 Cheers,
 
 Hugo
>>> 
>>> So how can Meng get out of this bind, she is trying to complete her
>>>google
>>> summer of code project.
>>> 
>>> thanks,
>>> 
>>> -Sebastien
>>> 
 
 
 On Sep 20, 2013, at 12:08 PM, Darren Shepherd <
>>> darren.s.sheph...@gmail.com> wrote:
 
> After much searching I found the two lines of code I needed to get it
>>> to serialize right.  I'll keep looking and see if I find other snags.
>>> Maybe we can just move to jackson we'll see, haven't tried to
>>> deserialize yet.
> 
> Darren
> 
>> On Sep 19, 2013, at 4:25 PM, Alex Huang 
>>wrote:
>> 
>> Darren,
>> 
>> When I looked into updating to the latest gson, the problem, IIRC,
>>is
>>> things that weren't considered cyclical dependencies are suddenly
>>> considered cyclical with the latest.  I don't recall where though.
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>> Sent: Thursday, September 19, 2013 1:33 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: conflicting dependencies between CloudStack and Whirr
>>> 
>>> Alright, I looked into this and it will take a bit more work to
>>> switch to Jackson.
>>> The snag I hit was how we serialize commands for the agents.  We
>>>use a
>>> customer typeadatper in gson to produce a format like {
>>>"org.MyClass"
>>> : {...} }.  In jackson I don't see producing a similar format as
>>> being so straight
>>> forward.  I'm sure there's an elegant solution, but I didn't
>>> immediately find it.
>>> The problem is if you use a custom serializer in jackson and do
>>> writeObjectField(x.getClass().getName(), x), you'll get stuck in a
>>> loop
>>> because it will call your serializer again.  So if somebody can
>>> figure out how to
>>> do this format easily in jackson, the rest looks simple enough.
>>> 
>>> So, being that it is not an obvious switch to using jackson, what
>>>is
>>> the impact
>>> of moving to the latest gson?  What were the issue encountered when
>>> people tried it before?
>>> 
>>> Darren
>>> 
>>> 
>>> On Wed, Sep 18, 2013 at 4:42 PM, Darren Shepherd <
>>> darren.s.sheph...@gmail.com> wrote:
>>> 
 I can do some analysis on this.  I'm always up for a terribly
painful
 refactor :)
 
 Darren
 
 
> On Wed, Sep 18, 2013 at 4:06 PM, Alex Huang
>
 wrote:
 
> I actually did a quick try to update cloudstack to use newest
>gson
> version about 3 months back.  Had to roll it back but I didn't
>try
> very hard though.  Part of the reason why I decided to rollback
>is
> due to gson is used differently by various components in
>CloudStack
> and I didn't have time to get into each component to see if I
>break
> anything.  The other is also I thought using Jackson would be
>much
> better and thought our next attempt should be with Jackson.
> 
> Not that any of these helps you.  Just know updating CloudStack
>to
> latest gson is not simple.
> 
> --Alex
> 
>> -Original Message-
>> From: Andrei Savu [mailto:savu.and...@gmail.com]
>> Sent: Wednesday, September 18, 2013 10:53 AM
>> To: d...@whirr.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: conflicting dependencies between CloudStack and
>>Whirr
>> 
>> It's easy to us

Re: cloudstack-sysvmadm takes very long to run?

[Chiradeep Vittal]

Logs?

On 9/23/13 12:46 PM, "Indra Pramana"  wrote:

>Dear all,
>
>The script failed to restart the system VMs. See below.
>
>All my system VMs (except one virtual router) are in "Starting" state but
>it never got started. Any idea how to resolve this issue?
>
>===
>nohup: ignoring input
>/usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No such
>file or directory
>
>Stopping and starting 1 secondary storage vm(s)...
>Done stopping and starting secondary storage vm(s)
>
>Stopping and starting 1 console proxy vm(s)...
>ERROR: Failed to start console proxy vm with id 1903
>
>Done stopping and starting console proxy vm(s) .
>
>Stopping and starting 2 running routing vm(s)...
>ERROR: Failed to restart domainRouter with id 1931
>
>ERROR: Failed to restart domainRouter with id 1930
>
>Done restarting router(s).
>===
>
>Looking forward to your reply, thank you.
>
>Cheers.
>
>
>
>On Tue, Sep 24, 2013 at 2:54 AM, Indra Pramana  wrote:
>
>> Is it normal for the cloudstack-sysvmadm script to take very long to
>>run?
>> It has been more than 30 minutes and it's still restarting the second
>> system VM.
>>
>> ===
>> root@cs-mgmt-01:~/cloudstack3# tail -f sysvm.log
>> nohup: ignoring input
>> /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No
>>such
>> file
>>
>> Stopping and starting 1 secondary storage vm(s)...
>> Done stopping and starting secondary storage vm(s)
>>
>> Stopping and starting 1 console proxy vm(s)...
>> ===
>>
>> If it's normal, any reason why? I presume restarting a VM shouldn't take
>> that long in normal circumstances?
>>
>> Any insight is appreciated. :)
>>
>> Thank you.
>>

Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chiradeep Vittal]

+1 (binding)

On 9/20/13 8:36 PM, "Animesh Chaturvedi" 
wrote:

>
>
>
>
>I've created a 4.2.0 release, with the following artifacts up for a vote:
>
>Git Branch and Commit SH:
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs
>/heads/4.2
>Commit: 69c459342c568e2400d57ee88572b301603d8686
>
>List of changes:
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CH
>ANGES;hb=4.2
>
>Source release (checksums and signatures are available at the same
>location):
>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
>
>PGP release keys (signed using 94BE0D7C):
>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
>Testing instructions are here:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+proced
>ure
>
>Vote will be open for 72 hours (Monday 9/23 PST EOD).
>
>For sanity in tallying the vote, can PMC members please be sure to
>indicate "(binding)" with their vote?
>
>[ ] +1  approve
>[ ] +0  no opinion
>[ ] -1  disapprove (and reason why)
>
>

Re: cloudstack-sysvmadm takes very long to run?

[Chiradeep Vittal]

Looks like you are out of space.
rocessing:  { Ans: , MgmtId: 161342671900, via: 37, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.e
xception.CloudRuntimeException: org.libvirt.LibvirtException: internal
error Child process (/bin/umount
/mnt/99a4fb82-780d-35c2-afb0-7f16388eeb94) unexpected exit status 32:
error writing /etc/mtab.tmp: No space left on device


Check with 'df -Ph' on the hypervisor to see if anything is at 100%

On 9/23/13 1:13 PM, "Indra Pramana"  wrote:

>Hi Chiradeep,
>
>I have uploaded the logs in pastebin here:
>
>http://pastebin.com/jy49jF4A
>
>Looking forward to your reply, thank you.
>
>Cheers.
>
>
>
>On Tue, Sep 24, 2013 at 3:59 AM, Chiradeep Vittal <
>chiradeep.vit...@citrix.com> wrote:
>
>> Logs?
>>
>> On 9/23/13 12:46 PM, "Indra Pramana"  wrote:
>>
>> >Dear all,
>> >
>> >The script failed to restart the system VMs. See below.
>> >
>> >All my system VMs (except one virtual router) are in "Starting" state
>>but
>> >it never got started. Any idea how to resolve this issue?
>> >
>> >===
>> >nohup: ignoring input
>> >/usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No
>>such
>> >file or directory
>> >
>> >Stopping and starting 1 secondary storage vm(s)...
>> >Done stopping and starting secondary storage vm(s)
>> >
>> >Stopping and starting 1 console proxy vm(s)...
>> >ERROR: Failed to start console proxy vm with id 1903
>> >
>> >Done stopping and starting console proxy vm(s) .
>> >
>> >Stopping and starting 2 running routing vm(s)...
>> >ERROR: Failed to restart domainRouter with id 1931
>> >
>> >ERROR: Failed to restart domainRouter with id 1930
>> >
>> >Done restarting router(s).
>> >===
>> >
>> >Looking forward to your reply, thank you.
>> >
>> >Cheers.
>> >
>> >
>> >
>> >On Tue, Sep 24, 2013 at 2:54 AM, Indra Pramana  wrote:
>> >
>> >> Is it normal for the cloudstack-sysvmadm script to take very long to
>> >>run?
>> >> It has been more than 30 minutes and it's still restarting the second
>> >> system VM.
>> >>
>> >> ===
>> >> root@cs-mgmt-01:~/cloudstack3# tail -f sysvm.log
>> >> nohup: ignoring input
>> >> /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No
>> >>such
>> >> file
>> >>
>> >> Stopping and starting 1 secondary storage vm(s)...
>> >> Done stopping and starting secondary storage vm(s)
>> >>
>> >> Stopping and starting 1 console proxy vm(s)...
>> >> ===
>> >>
>> >> If it's normal, any reason why? I presume restarting a VM shouldn't
>>take
>> >> that long in normal circumstances?
>> >>
>> >> Any insight is appreciated. :)
>> >>
>> >> Thank you.
>> >>
>>
>>

Re: [ANNOUNCE] A GCE interface to CloudStack

[Chiradeep Vittal]

Wow. Nice!

On 9/24/13 6:04 AM, "sebgoa"  wrote:

>Hi,
>
>I am quite pumped to announce a Google Compute Engine (GCE) interface to
>CloudStack.
>
>Ian Duffy, Darren Brogan and myself worked on this on github over the
>last month. Our latest branch:
>
>https://github.com/NOPping/cloudstack-gce/tree/refactor
>
>Has been uploaded to pypi:
>
>https://pypi.python.org/pypi/gcloud
>
>A little virtualenv and a pip install gcloud will give you a Flask
>application, with OAuth2 provider and REST routes that map to the
>CloudStack API.
>The routes are compliant with GCE API, which allows you to use the Google
>gcutil cli to talk to your CloudStack cloud.
>
>Of course there are a few caveats that I will not mention, this is
>release 0.0.1, feedback and pr welcome.
>
>Congrats to our two 20 year olds in ireland who are taking names up in
>Dublin !
>
>Have fun,
>
>-Sebastien

Re: VmWare SDK to vijava

[Chiradeep Vittal]

Ha! Prussians == Prasanna?
Godawful autocorrect.

On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:

>Darren, you can probably work with Prussians to get it through the bvt
>suite. That would be a nice start.
>
>Cheers,
>
>Hugo
>
>Sent from my iPhone
>
>> On 25 sep. 2013, at 09:06, Darren Shepherd
>> wrote:
>> 
>> My extensive testing consisted of "it compiles!"  So somebody needs to
>>validate it, I don't have a vmware setup handy.  The wsdl generation
>>route is not feasible unless legal says it's okay.  Somebody want to
>>email legal@?
>> 
>> Darren
>> 
>>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
>>> 
>>> So at this moment we have the following tally,
>>> 
>>> Darren, Alex, Kelven opt for the wsdl route
>>> Hugo opts for the vijava route
>>> 
>>> I'm perfectly ok with ditching my work on the vijava in favour of the
>>>wsdl route. The arguments presented in the last few mails make a lot of
>>>sense. So i say the wsdl route is the way to go.
>>> 
>>> I do think however that we need to revisit the vmware code anyway.
>>>There is dead code in there, formatting issues and a general
>>>duplication of code. Parts of my plan to switch to vijava was to
>>>simplify the code as well, but i can still do that with the WSDL layer.
>>> 
>>> Darren, did you run your wsdl branch through the BVT test suite? If
>>>you did we can merge it on short notice and get on with it. If you
>>>didn't can you take care of that and give an overview of the testing
>>>done on that branch besides the BVT?
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
 On Sep 25, 2013, at 2:58 AM, Kelven Yang 
wrote:
 
 We have commercial releases on top of existing code base and there are
 lots of testing efforts behind it, dramatic switch means $ cost, the
major
 concern for me is not about how beautiful vijava is or how bad a
direct
 wsdl approach would be. it is about to get things move smoothly.
 
 It looks like that we should have VMware layer on its own to have a
plugin
 structure so that we can replace underlying binding easier, it should
 solve the balance between developer's tho motivation and carrying on
the
 legacy with minimal impacts to the rest of others.
 
 
 Kelven
 
> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> 
> Heya,
> 
> This biggest advantage i see in using vijava is that a lot of the
> functionality that we now have in the vmware-base project is already
> supplied with vijava.
> 
> There is a lot of code that facilitates calling tasks and other
>stuff in
> our MO classes. These classes are available in vijava and could be
>used
> instead of our classes. Basically when using vijava correctly you
>hardly
> have to work with the ManagedObjectReferences anymore. For me this
>would
> be a big benefit as it makes programming against vmware a lot
>easier. We
> also have a lot of duplicate code currently in the vmware class and i
> wouldn't mind getting rid of it, which i think is easier with the
>vijava
> libraries.
> 
> That said, the main driver is getting it into the main build so any
>other
> efforts towards that goal are ok with me.
> 
> I would propose that somebody else puts up a branch with our own wdsl
> wrapper and we open a discussion thread when both branches are ready
>to
> see which we want to merge in master. Anybody who wants to pick that
>up?
> 
> I'm stubbornly going to continue with converting to vijava, I put
>some
> effort into it and i want at least to see it running once ;-)  And
>the
> more i work with it the more i'm seeing to benefits of the library
>so i
> might be able to be more convincing in the end :-)
> 
> Cheers,
> 
> Hugo
> 
> 
>> On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>>wrote:
>> 
>> Prior to 5.1, VMware provides java binding in its SDK and this is
>>where
>> CloudStack VMware integration began with. Starting from 5.1, VMware
>>no
>> longer provides the java binding in binary form and recommends its
>> customers to generate directly from its WS WSDL.
>> 
>> Since we are not sure if we can distribute VMware wsdl legally or
>>not,
>> therefore, we ended up to generate and distribute the java binding
>>in
>> binary form. If we can get this cleared in lebal, as Darren
>>pointed, we
>> can solve our non-dist issue easily in matter of adding couple of
>>lines
>> in
>> maven.
>> 
>> As of vijava, yes, I think it may add some value from developer's
>>point
>> of
>> view, but on the other hand, I don't see immediate benefits to
>>having
>> another layer on top of VMware official WS API, vijava is an open
>>source
>> project for providing convenient java binding to vmware WS API,
>>maybe
>> I'm
>> wrong, but I think VMwar

Re: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

[Chiradeep Vittal]

+1 (binding)

On 9/25/13 10:13 AM, "Chip Childers"  wrote:

>Hi all!
>
>As stated in other threads, Juniper is proposing the donation of a
>Contrail plugin to Apache CloudStack.  The code itself has been posted
>to reviewboard [1].  The design has been documented by Pedro [2].
>
>[1] https://reviews.apache.org/r/14325/
>[2] 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+network+pl
>ugin
>
>I'm calling a vote here, so that we have a formal consensus on accepting
>the code into the project.  As I've suggested earlier, I'd like us to
>accept the code into a branch, and then work through any technical
>concerns / reviews / changes prior to a master branch merge.
>
>So...  voting will end in ~72 hours.  As this is a technical decision,
>committer and PMC votes are binding.
>
>-chip
>
>
>Votes please!
>
>[ ] +1 - Accept the donation
>[ ] +/-0 - No strong opinion
>[ ] -1 - Do not accept the donation

Re: [Merge] Minimal Hyper-V Plugin

[Chiradeep Vittal]

+1 to put this into a branch off of master. Can merge into master after
unit tests for the agent API.


On 9/24/13 12:37 PM, "Donal Lafferty"  wrote:

>On paternity leave, so I don't get to these emails right away...
>
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: 20 September 2013 06:40
>> To: dev@cloudstack.apache.org
>> Subject: Re: [Merge] Minimal Hyper-V Plugin
>> 
>> Thanks for the preliminary testing.
>> Questions:
>> 1. More for the community: should the C# code be in a separate repo?
>> According to the merge request, mono and maven can be used to build the
>> agent.
>
>Silence == acceptance?
>
>> 2. Packaging: how is the C# agent installed?
>
>The agent is implemented to as a self-contained Windows Service, which is
>the Microsoft Windows equivalent of a Linux daemon.
>
>To make the agent distributable, package the agent and an app.config
>consistent with your data center in an MSI.  WiX is the preferred tool
>(http://en.wikipedia.org/wiki/WiX ).  When executed, the MSI will add the
>agent to set of Windows Services.
>
>To distribute and run this MSI, use Active Directory's GPO (global policy
>object) service.  In typical deployments machines running Hyper-V will be
>domain joined.  Where machines are not domain joined, look at something
>like puppet. 
>
>> 3. What does minimal mean? What works? What doesn't? Local storage?
>> Shared storage? Networking modes? Are the hypervisors supposed to be
>> clustered?
>
>Minimal = create / start / stop / destroy a local storage VM in a
>QuickCloud network offering and CIFS secondary storage.
>
>No clustering required.
>
>> 4. How does one extend the "minimal" plugin?
>
>Each CloudStack command has a corresponding an HTTP URI served by the
>agent.  These are written in ASP.NET MVC4.  Data received by the agent is
>kept in a JSON object graph.
>
>E.g.
>
>// POST api/HypervResource/ReadyCommand
>[HttpPost]
>[ActionName(CloudStackTypes.ReadyCommand)]
>public JContainer ReadyCommand([FromBody]dynamic cmd)
>{
>using (log4net.NDC.Push(Guid.NewGuid().ToString()))
>{
>logger.Info(CloudStackTypes.ReadyCommand +
>cmd.ToString());
>object ansContent = new
>{
>result = true,
>details = (string)null
>};
>return ReturnCloudStackTypedJArray(ansContent,
>CloudStackTypes.ReadyAnswer);
>}
>
>}
>
>Therefore, to extend the plugin, add new HTTP URIs corresponding to
>missing commands, or extend the capabilities of existing commands.
>
>I can follow up with an explanation in a blog entry.
>
>> 5. Can the unit tests (at least those that test the agent API) be run
>>in a non-
>> hyper-v environment?
>
>Unit tests start the agent in a local process.  Provided Mono is
>installed on your system, the unit tests will run.  However, they will
>complain of bad output.
>
>> 6. Is the RDP console you had earlier mentioned included in the merge?
>
>Yes, but it serves no purpose at the moment.
>
>If there is an IP clearance protocol to follow for this console, I would
>prefer to remove the console from the submission.
>
>> 7. Any known issues?
>> 
>
>There seems to be a bug with local paths that include spaces.  I've asked
>Rajesh to provide a bug report, but it's unclear where to put this.  Can
>we use JIRA for code not merged, or should the bug appear in the comments.
>
> 
>> On 9/11/13 8:00 AM, "Donal Lafferty"  wrote:
>> 
>> >Hi Rajesh,
>> >
>> >Thanks for spotting this problem with the Hyper-V Agent.  Sounds like
>> >it should first URL decode the field.
>> >
>> >Can you update the review with details of your testing?
>> >
>> >I would need to know the command and which incoming field is causing
>> >problems.  Also, can you add a serialised example of the instruction
>> >that fails?  There should be an example in the agent's log file.  By
>> >default, the log file is in the same folder as the agent executable.  I
>> >will use this to update the automated tests.
>> >
>> >If you want to go ahead and made the fixes from a git clone, send a
>> >Pull Request.  As long as there is an appropriate automated test, I'll
>> >update the feature branch with your changes.
>> >
>> >
>> >DL
>> >
>> >> -Original Message-
&

Re: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

SNMP wouldn't restart a failed process nor would it generate alerts. It is
simply too generic for the requirements outlined here. The proposal does
not talk about modifying monit, just using it. That wouldn't trigger the
AGPL.
I think the idea is to have a tight monitoring loop that scales: so
executing the monitoring loop in-situ makes sense.


On 9/25/13 9:53 PM, "David Nalley"  wrote:

>On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
> wrote:
>> Hi,
>>
>> Currently in virtual router there is no way to recover and notify if
>>some service goes down unexpectedly.
>>
>> This feature is about monitoring all the services rendered by the
>>virtual router, ensure that the services are running through the life
>>time of the VR.
>>
>> On service failure:
>> 1. Generate an alert and event indicating failure
>> 2. Restart the service
>>
>> Services to be monitored:
>> DHCP, DNS, haproxy, password server etc.
>>
>> As part of monitoring there are two activities
>>
>> 1. One is monitoring the services in VR and log the events. Using monit
>>for monitoring services
>> 2. Second part is pushing alerts from router to  MS server. Thinking on
>>POST the logs to web server in MS.
>>
>> I will be updating more details and FS in this thread.
>>
>> I created enhancement bug for this.
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
>>
>> Thanks,
>> Jayapal
>
>So several things - why not make this via SNMP? Query processes, and
>many other things. This should be relatively simple, is well known,
>can be locked down (or could be monitored for many other things by
>external monitoring packages) and is the defacto standard for
>monitoring hosts.
>Second - monit is Affero GPL licensed - which is a cat-x license.
>While I expect that we would merely use this and not do any hacking on
>it - I think its inclusion might be a surprise (and forbidden in many
>environments) to our users
>
>--David

Re: ubuntu LTS for system vm? and 64bit?

[Chiradeep Vittal]

32-bit theoretically performs better on Xen.
Debian is just more stable than Ubuntu, hence the preference.

On 9/25/13 4:38 PM, "Darren Shepherd"  wrote:

>Is there any technical reason why we couldn't use ubuntu LTS (12.04
>and soon to be 14.04) for the system VM.  Additionally is there any
>technical reason we couldn't switch to 64bit.  I don't necesarily want
>to get into "fight for you favorite distro" discussion, just curious.
>
>Darren

Re: Documentation on VPC?

[Chiradeep Vittal]

CloudStack VPC is quite similar to AWS VPC, except for some of the
differences listed here:
https://cwiki.apache.org/confluence/x/vhHMAQ

On 9/25/13 3:30 PM, "Darren Shepherd"  wrote:

>I've been trying to go through the GUI and do stuff with VPC and I'm
>really quite lost. Are there any user docs on this stuff?  I thought I
>would just go through the API, but cloudmonkey is not very useful for
>VPC in that "list vpcs" spews like 50 lines for each VPC.  I can click
>around a view a lot of stuff, but I can't manage to figure out how to
>create much of anything.
>
>Darren

Re: ubuntu LTS for system vm? and 64bit?

[Chiradeep Vittal]

Yes. 4.2 has Wheezy with the 3.2 kernel. Theoretically with RPS/RFS we
could use multiple cores effectively, but it may be harder in practice.

On 9/25/13 10:53 PM, "Darren Shepherd"  wrote:

>Yeah, for sure 32bit PV is faster.  Do we require a specific minimum
>kernel version?  I though I heard something about upgrading the template
>for multicore networking or something like that.
>
>Darren
>
>> On Sep 25, 2013, at 10:38 PM, Chiradeep Vittal
>> wrote:
>> 
>> 32-bit theoretically performs better on Xen.
>> Debian is just more stable than Ubuntu, hence the preference.
>> 
>>> On 9/25/13 4:38 PM, "Darren Shepherd" 
>>>wrote:
>>> 
>>> Is there any technical reason why we couldn't use ubuntu LTS (12.04
>>> and soon to be 14.04) for the system VM.  Additionally is there any
>>> technical reason we couldn't switch to 64bit.  I don't necesarily want
>>> to get into "fight for you favorite distro" discussion, just curious.
>>> 
>>> Darren
>> 

Re: CloudStack Server Memory Requirements

[Chiradeep Vittal]

I believe Darren's proposed Spring refactor will help greatly.

On 9/26/13 7:41 AM, "Marcus Sorensen"  wrote:

>I think its an artifact from the Spring stuff six months ago. We can
>probably decrease that in the default tomcat conf now.
>On Sep 26, 2013 6:11 AM, "Geoff Higginbottom" <
>geoff.higginbot...@shapeblue.com> wrote:
>
>>  I¹ve been testing the 4.2 release of CloudStack using Virtual Box and
>> have noticed a need to allocate significantly more memory to the VM.
>> Previously I would use a CentOS VM with 1 GB of RAM for the installation
>> but then drop the memory to 512MB, leaving plenty of RAM on the host
>> machine to then stand up a XenServer VM or a KVM VM etc.
>>
>>
>>
>> I initially had problems logging into 4.2 after a clean install, and
>> discovered that only by increasing the memory to 2GB could I get the
>>system
>> to function.
>>
>>
>>
>> I am quite shocked that the memory footprint has increased 400% between
>> releases.  Obviously for a real production system, allocating more than
>>2GB
>> or RAM to CloudStack is not an issue, but it does make standing up a
>>simple
>> test environment in Virtual Box more difficult.
>>
>>
>>
>> Does anyone have ideas why this has increased and is it something that
>> should be looked at.
>>
>>
>>
>> Regards
>>
>>
>>
>> Geoff Higginbottom
>>
>> *CTO / Cloud Architect*
>>
>>
>>
>> [image: Description: Mail Logo Bottom Align]
>>
>>
>>
>> D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540
>><+442036030540>| M:
>> +447968161581
>>
>>
>>
>> geoff.higginbot...@shapeblue.com | www.shapeblue.com |
>>Twitter:@shapeblue
>>
>>
>>
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>>
>>
>> Apache CloudStack Bootcamp training courses
>>
>> 18/19 September,
>>Bangalore
>>
>> 02/03 October, 
>>London
>>
>> 13/14 November, 
>>London
>>
>> 27/28 November, 
>>Bangalore
>>
>> 08/09 January 2014,
>>London
>> **
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  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: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

In this case you would have to invent another enterprise MIB. Not too
hard, but I'd argue that it needs to be proxied through some other service
anyway and it represents a different integration point with ACS. Depends
on whether you consider the system vm part of the ACS deployment, or an
entity like a host.

On 9/26/13 10:27 AM, "Alex Huang"  wrote:

>Using SNMP for alert notification is not a bad idea though.  I don't see
>why we can't do that instead of posting to the management server.  This
>is specifically referring to the second part of the proposal.  Why
>reinvent that part of it?
>
>--Alex
>
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Wednesday, September 25, 2013 10:28 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>> 
>> SNMP wouldn't restart a failed process nor would it generate alerts. It
>>is
>> simply too generic for the requirements outlined here. The proposal does
>> not talk about modifying monit, just using it. That wouldn't trigger
>>the AGPL.
>> I think the idea is to have a tight monitoring loop that scales: so
>>executing the
>> monitoring loop in-situ makes sense.
>> 
>> 
>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>> 
>> >On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>> > wrote:
>> >> Hi,
>> >>
>> >> Currently in virtual router there is no way to recover and notify if
>> >>some service goes down unexpectedly.
>> >>
>> >> This feature is about monitoring all the services rendered by the
>> >>virtual router, ensure that the services are running through the life
>> >>time of the VR.
>> >>
>> >> On service failure:
>> >> 1. Generate an alert and event indicating failure 2. Restart the
>> >> service
>> >>
>> >> Services to be monitored:
>> >> DHCP, DNS, haproxy, password server etc.
>> >>
>> >> As part of monitoring there are two activities
>> >>
>> >> 1. One is monitoring the services in VR and log the events. Using
>> >>monit for monitoring services  2. Second part is pushing alerts from
>> >>router to  MS server. Thinking on POST the logs to web server in MS.
>> >>
>> >> I will be updating more details and FS in this thread.
>> >>
>> >> I created enhancement bug for this.
>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
>> >>
>> >> Thanks,
>> >> Jayapal
>> >
>> >So several things - why not make this via SNMP? Query processes, and
>> >many other things. This should be relatively simple, is well known, can
>> >be locked down (or could be monitored for many other things by external
>> >monitoring packages) and is the defacto standard for monitoring hosts.
>> >Second - monit is Affero GPL licensed - which is a cat-x license.
>> >While I expect that we would merely use this and not do any hacking on
>> >it - I think its inclusion might be a surprise (and forbidden in many
>> >environments) to our users
>> >
>> >--David
>

Re: ubuntu LTS for system vm? and 64bit?

[Chiradeep Vittal]

That enabled running without a system vm. But you'd still need a VR if you
wanted network services.

On 9/26/13 12:47 AM, "Sebastien Goasguen"  wrote:

>
>On Sep 26, 2013, at 3:27 AM, Wido den Hollander  wrote:
>
>> 
>> 
>> On 09/26/2013 01:38 AM, Darren Shepherd wrote:
>>> Is there any technical reason why we couldn't use ubuntu LTS (12.04
>>> and soon to be 14.04) for the system VM.  Additionally is there any
>>> technical reason we couldn't switch to 64bit.  I don't necesarily want
>>> to get into "fight for you favorite distro" discussion, just curious.
>>> 
>> 
>> This still underlines the problem with the SystemVM, it isn't flexible
>>enough.
>> 
>> I'm not saying we should change overnight, but the SystemVM should be
>>abstracted a lot more so people can throw in their own SystemVM more
>>easily.
>> 
>> I created a issue about this last year:
>>https://issues.apache.org/jira/browse/CLOUDSTACK-451
>> 
>> I'd like to see this abstracted more so you can drop in any Linux or
>>BSD distro you like as long as it talks the API and does what it's asked
>>to do.
>> 
>> For Debian based we should be able to create some .deb packages which
>>you can simple install and for Redhat some .rpms.
>> 
>> The SystemVMs aren't rocket-science, as a matter of fact, I think the
>>are a big mess internally when you see all the scripts.
>> 
>> Wido
>
>Didn't Chiradeep work on quick cloud to solve some of those issues:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
>
>
>
>> 
>>> Darren
>>> 
>

Re: Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[Chiradeep Vittal]

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


Not sure if this should be in the API since it is a HAProxy-specific 
configuration. This wouldn't apply to Netscaler or F5. 
After all the end user has no idea if he is using HAProxy of Netscaler or F5.

Likely this flag is of interest to the cloud operator only, so why not put it 
in zone-wide config instead of the network offering.
Do you really see someone creating 2 offerings: one with HttpClose and one 
without HttpClose?

- Chiradeep Vittal


On Sept. 26, 2013, 7:01 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14320/
> ---
> 
> (Updated Sept. 26, 2013, 7:01 p.m.)
> 
> 
> Review request for cloudstack and Wei Zhou.
> 
> 
> Bugs: CLOUDSTACK-4328
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> add boolean option httpModeEnabled to the service offering for use in haproxy 
> conf
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/NetworkOffering.java 6c5573e 
>   api/src/org/apache/cloudstack/api/ApiConstants.java f85784b 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
>  bdad904 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOfferingCmd.java
>  c9c4c8a 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java ee29290 
>   core/src/com/cloud/network/HAProxyConfigurator.java 2309125 
>   core/test/com/cloud/network/HAProxyConfiguratorTest.java PRE-CREATION 
>   engine/components-api/src/com/cloud/configuration/ConfigurationManager.java 
> 5e1b9b5 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
>  53f64fd 
>   engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java eefdc94 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  ecd6006 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  587ae99 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 8a0f7a6 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 7c026a4 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java c9a0480 
>   
> server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
>  1f1fb75 
>   setup/db/db/schema-420to430.sql 44a884d 
> 
> Diff: https://reviews.apache.org/r/14320/diff/
> 
> 
> Testing
> ---
> 
> created unit test.
> instantiated a network with some loadbalancer rule based on a netoffer with 
> the option to true/false and maxconnections to a non default value -> checked 
> haproxy.cfg on the router
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request 11981: Adding base support for NVP security groups to the NVP API

[Chiradeep Vittal]

> On June 20, 2013, 6:40 a.m., Prasanna Santhanam wrote:
> > Minor nitpick : our code conventions recommend the method naming to not use 
> > underscore. so it's lowerCaseAndNoUnderscores()
> > 
> > http://cloudstack.apache.org/develop/coding-conventions.html
> 
> Animesh Chaturvedi wrote:
> Hugo can you review this patch

Agree with Prasanna's comment. 


- Chiradeep


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


On June 19, 2013, 9:28 p.m., Adrian Steer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11981/
> ---
> 
> (Updated June 19, 2013, 9:28 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is initial version of API implementation of security groups within the 
> NVP API
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalSwitchPort.java
>  c571458 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraAddressPairs.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraLogicalPortRule.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
>  12fa6c0 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraSecurityProfile.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11981/diff/
> 
> 
> Testing
> ---
> 
> Compile testing
> 
> 
> Thanks,
> 
> Adrian Steer
> 
>

Re: [DISCUSS] UI: New look and feel

[Chiradeep Vittal]

Not to be a fanboi and all that and hating to divert this topic, but doing
it anyway, I do like 'flat'.

On 9/26/13 5:12 PM, "Musayev, Ilya"  wrote:

>I don't agree.
>
>For the reference,  take a look at OpenStack UI and compare it to ACS
>specifically version 4.2
>
>
>- All mistakes in this message are not mine but Android's.
>
>
> Original message 
>From: Tracy Phillips 
>Date: 09/26/2013 8:06 PM (GMT-05:00)
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] UI: New look and feel
>
>
>I am a fan of Foundation's look (or Bootstrap even)...
>
>http://foundation.zurb.com/
>
>3d elements make it look dated, kind of like it does now. The less images,
>the better imo.
>
>
>
>
>On Thu, Sep 26, 2013 at 7:11 PM, Kelcey Jamison Damage <
>kel...@backbonetechnology.com> wrote:
>
>> Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.
>>
>> - Original Message -
>> From: "Ilya Musayev" 
>> To: dev@cloudstack.apache.org
>> Sent: Thursday, September 26, 2013 4:08:50 PM
>> Subject: RE: [DISCUSS] UI: New look and feel
>>
>> Brian,
>>
>> Are we no longer using icons on the left navigation menu or is this a
>> draft?
>>
>> Thanks
>> ilya
>>
>> > -Original Message-
>> > From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
>> > Sent: Thursday, September 26, 2013 6:28 PM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] UI: New look and feel
>> >
>> > You just made my day, these look great. Most importantly it has a look
>> that
>> > will sell to IT managers, etc.
>> >
>> > I wish you the best of luck with this and hope for rapid progress :)
>> >
>> > Again, it looks awesome!
>> >
>> > - Original Message -
>> > From: "Brian Federle" 
>> > To: dev@cloudstack.apache.org
>> > Cc: "Sonny Chhen" , "Animesh Chaturvedi"
>> > , "Jessica Wang"
>> > 
>> > Sent: Thursday, September 26, 2013 3:11:07 PM
>> > Subject: [DISCUSS] UI: New look and feel
>> >
>> > Hi all,
>> >
>> > In addition to the CSS code cleanup I'm working on, I am planning a
>> 'reskin' of
>> > the current UI to give a better user experience and look and feel.
>>This
>> will
>> > utilize SASS and a grid system as I have discussed in the previous
>> thread.
>> >
>> > I created a task in JIRA and wiki functional spec, which has
>>screenshots
>> of
>> > what I've done so far and what I plan to do:
>> >
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
>> > al+appearance
>> >
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-4748
>> >
>> > You can also checkout the ui-restyle branch on git, if you are able to
>> manually
>> > compile the cloudstack.scss file via SASS (that will be automated in
>>the
>> > future). I can send over instructions on how to compile SASS manually;
>> it's
>> > pretty easy to setup.
>> >
>> > Let me know what you think so far :)  I'll of course up and post more
>> > screenshots as I get more done. This reskin is only changing the CSS
>> mainly,
>> > with minimal changes to actual usage or JS code, so it is basically a
>> drop-in
>> > replacement for the current styling. I'm hoping to get this in by 4.3,
>> so please
>> > give me feedback on anything from the current UI you don't like or
>>want
>> > changed, and I can see about improving it.
>> >
>> > Thanks!
>> > Brian
>> >
>>
>>

Re: Scalable Backup and Recovery

[Chiradeep Vittal]

Ah I see. You mean a "scalable user experience".

The actual scalability of the snapshot process itself is limited by
available disk and network bandwidth.
Also certain hypervisors have various quirks which stand in the way of an
efficient solution.

On 9/27/13 10:27 AM, "SuichII, Christopher"  wrote:

>I'd like to start a discussion around the direction of scalable backup
>and recovery in CloudStack. Currently, the only want to backup and
>recover vms is by setting up a schedule or manually snapshotting up
>individual vm disks or manually snapshotting vms. Unfortunately, I don't
>believe this is a very scalable solution. What if a user wants all of
>their vm disks to be backed up on the same schedule? What if a domain
>administrator wants all of the vms in their domain to be backed up on the
>same schedule or to manually backup every vm in their domain?
>
>Here are some use cases I see for helping to scale things up:
>-Scheduled and manual backup of 1 to all of a user's vms and vm disks
>-Scheduled and manual backup of 1 to all of a domain's vms and vm disks
>(by a domain admin)
>-Scheduled and manual backup of 1 to all vms and vm disks on primary
>storage (by a cloud admin) - this one is tougher to find a valid use case
>for
>-Backup schedules attached to service offerings
>
>I know I previously started a discussion about backing up multiple vm
>disks at once, but I think these use cases, broken down by user type
>(user, domain admin and admin), should help clear things up and show the
>utility of being able to backup multiple objects at once.
>
>Thanks!
>Chris
>-- 
>Chris Suich
>chris.su...@netapp.com
>NetApp Software Engineer
>Data Center Platforms ­ Cloud Solutions
>Citrix, Cisco & Red Hat
>

Re: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

Good idea. If x and y and z are borked, initiate shutdown?

More generically, it seems we need some form of in-VM automation that can
co-ordinate with top-level orchestration

On 9/28/13 4:14 AM, "Daan Hoogland"  wrote:

>Even when always restarting on every glitch we need to monitor the inside
>of the vr to know when to restart/respin a new vr. There is much
>functionality present on the vr an for us it is not possible to say for
>sure what is important to a customer installation so the admin should be
>able to define the minimal reqs that will stop us from spinning up a new
>vr. And there must be tools present for monitoring these reqs.
>
>makes sense?
>
>
>On Thu, Sep 26, 2013 at 10:01 PM, David Nalley  wrote:
>
>> For what it's worth we created an ACS-specific MIB (beneath the
>> org.apache MIB) so really this is just a matter of defining and
>> publishing it.
>>
>> But lets think about monit being used to restart services - with HA,
>> Redundant VR, are we sure that we want to inject yet another point of
>> control into things? Is it better to just respawn an instance since
>> they are essentially stateless? I don't know, but management server,
>> local daemons, and other SysVMs making decisions seems like we are
>> increasing complexity.
>>
>> --David
>>
>> On Thu, Sep 26, 2013 at 10:31 AM, Chiradeep Vittal
>>  wrote:
>> > In this case you would have to invent another enterprise MIB. Not too
>> > hard, but I'd argue that it needs to be proxied through some other
>> service
>> > anyway and it represents a different integration point with ACS.
>>Depends
>> > on whether you consider the system vm part of the ACS deployment, or
>>an
>> > entity like a host.
>> >
>> > On 9/26/13 10:27 AM, "Alex Huang"  wrote:
>> >
>> >>Using SNMP for alert notification is not a bad idea though.  I don't
>>see
>> >>why we can't do that instead of posting to the management server.
>>This
>> >>is specifically referring to the second part of the proposal.  Why
>> >>reinvent that part of it?
>> >>
>> >>--Alex
>> >>
>> >>> -Original Message-
>> >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> >>> Sent: Wednesday, September 25, 2013 10:28 PM
>> >>> To: dev@cloudstack.apache.org
>> >>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>> >>>
>> >>> SNMP wouldn't restart a failed process nor would it generate
>>alerts. It
>> >>>is
>> >>> simply too generic for the requirements outlined here. The proposal
>> does
>> >>> not talk about modifying monit, just using it. That wouldn't trigger
>> >>>the AGPL.
>> >>> I think the idea is to have a tight monitoring loop that scales: so
>> >>>executing the
>> >>> monitoring loop in-situ makes sense.
>> >>>
>> >>>
>> >>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>> >>>
>> >>> >On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>> >>> > wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> Currently in virtual router there is no way to recover and
>>notify if
>> >>> >>some service goes down unexpectedly.
>> >>> >>
>> >>> >> This feature is about monitoring all the services rendered by the
>> >>> >>virtual router, ensure that the services are running through the
>>life
>> >>> >>time of the VR.
>> >>> >>
>> >>> >> On service failure:
>> >>> >> 1. Generate an alert and event indicating failure 2. Restart the
>> >>> >> service
>> >>> >>
>> >>> >> Services to be monitored:
>> >>> >> DHCP, DNS, haproxy, password server etc.
>> >>> >>
>> >>> >> As part of monitoring there are two activities
>> >>> >>
>> >>> >> 1. One is monitoring the services in VR and log the events. Using
>> >>> >>monit for monitoring services  2. Second part is pushing alerts
>>from
>> >>> >>router to  MS server. Thinking on POST the logs to web server in
>>MS.
>> >>> >>
>> >>> >> I will be updating more details and FS in this thread.
>> >>> >>
>> >>> >> I created enhancement bug for this.
>> >>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Jayapal
>> >>> >
>> >>> >So several things - why not make this via SNMP? Query processes,
>>and
>> >>> >many other things. This should be relatively simple, is well known,
>> can
>> >>> >be locked down (or could be monitored for many other things by
>> external
>> >>> >monitoring packages) and is the defacto standard for monitoring
>>hosts.
>> >>> >Second - monit is Affero GPL licensed - which is a cat-x license.
>> >>> >While I expect that we would merely use this and not do any
>>hacking on
>> >>> >it - I think its inclusion might be a surprise (and forbidden in
>>many
>> >>> >environments) to our users
>> >>> >
>> >>> >--David
>> >>
>> >
>>

Re: Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[Chiradeep Vittal]

My point is that it is a tuning that is specific for HAProxy and shouldn't
be exposed in an abstraction like the CS API.
(After all, how do I choose, as an end-user Offering A with httpClose or
offering B without httpClose). If there is another desirable feature Y in
Netscaler, do you anticipate changing another dozen files for that feature?

If you look at the stickiness policy feature, it isn't tied to the service
offering despite there being some differences between stickiness
capabilities between different LB providers.



On 9/28/13 4:18 AM, "Daan Hoogland"  wrote:

>Chiradeep,
>
>the network offerings are created by the cloud operator aren't they? The
>netscaler  en f5 modules will have to implement it's own behavior on
>httpClose. in case of haproxy it means no mode http and option httpclose
>(and some other things)
>
>If you define it zone wide every tenant has the same setting whilst you
>want this to tune setting (like with maxConnections) for a tenant.
>
>regards,
>Daan
>
>
>On Thu, Sep 26, 2013 at 10:57 PM, Chiradeep Vittal
>wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/14320/
>>
>> Not sure if this should be in the API since it is a HAProxy-specific
>>configuration. This wouldn't apply to Netscaler or F5.
>> After all the end user has no idea if he is using HAProxy of Netscaler
>>or F5.
>>
>> Likely this flag is of interest to the cloud operator only, so why not
>>put it in zone-wide config instead of the network offering.
>> Do you really see someone creating 2 offerings: one with HttpClose and
>>one without HttpClose?
>>
>>
>> - Chiradeep Vittal
>>
>> On September 26th, 2013, 7:01 p.m. UTC, daan Hoogland wrote:
>>   Review request for cloudstack and Wei Zhou.
>> By daan Hoogland.
>>
>> *Updated Sept. 26, 2013, 7:01 p.m.*
>>  *Bugs: * CLOUDSTACK-4328
>>  *Repository: * cloudstack-git
>> Description
>>
>> add boolean option httpModeEnabled to the service offering for use in
>>haproxy conf
>>
>>   Testing
>>
>> created unit test.
>> instantiated a network with some loadbalancer rule based on a netoffer
>>with the option to true/false and maxconnections to a non default value
>>-> checked haproxy.cfg on the router
>>
>>   Diffs
>>
>>- api/src/com/cloud/offering/NetworkOffering.java (6c5573e)
>>- api/src/org/apache/cloudstack/api/ApiConstants.java (f85784b)
>>- 
>>api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOffe
>>ringCmd.java
>>(bdad904)
>>- 
>>api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOffe
>>ringCmd.java
>>(c9c4c8a)
>>- core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java
>>(ee29290)
>>- core/src/com/cloud/network/HAProxyConfigurator.java (2309125)
>>- core/test/com/cloud/network/HAProxyConfiguratorTest.java
>>(PRE-CREATION)
>>- 
>>engine/components-api/src/com/cloud/configuration/ConfigurationManager.ja
>>va
>>(5e1b9b5)
>>- 
>>engine/orchestration/src/org/apache/cloudstack/engine/orchestration/Netwo
>>rkOrchestrator.java
>>(53f64fd)
>>- engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java
>>(eefdc94)
>>- 
>>plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/El
>>asticLoadBalancerManagerImpl.java
>>(ecd6006)
>>- 
>>plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/
>>network/lb/InternalLoadBalancerVMManagerImpl.java
>>(587ae99)
>>- server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>>(8a0f7a6)
>>- 
>>server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.ja
>>va
>>(7c026a4)
>>- server/test/com/cloud/vpc/MockConfigurationManagerImpl.java
>>(c9a0480)
>>- 
>>server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTe
>>st.java
>>(1f1fb75)
>>- setup/db/db/schema-420to430.sql (44a884d)
>>
>> View Diff <https://reviews.apache.org/r/14320/diff/>
>>

Re: [PROPOSAL] Provide Option to Quiesce VMs While Taking Snapshots

[Chiradeep Vittal]

Is VM Quiescing sufficient to ensure consistency of the snapshot?


On 9/30/13 2:43 PM, "SuichII, Christopher"  wrote:

>CloudStack currently snapshots vm disks by taking hypervisor snapshots.
>However, when implementing the storage subsystem API interface
>takeSnapshot(), the VM associated with the requested volume is not
>quiesced since a hypervisor snapshot is not necessarily taken. When
>creating a storage level snapshot, there are ways around this and
>'quiescing' the vm without actually quiescing it (through hypervisor
>APIs). I would like to propose that there be an option to quiesce VMs
>when taking snapshots both manually and through recurring snapshot
>policies. One issue I see with this is that this option is not always
>applicable. If the default storage provider is used, a hypervisor
>snapshot will be taken and therefore the VM will always be quiesced. Some
>storage providers may not respect the user's request to quiesce. Because
>of this, I suggest that the option be shown to the user as 'Quiesce VM
>(if applicable)'. This indicates to the user that the option will be
>passed to the management server and respected if possible.
>
>I will work on formalizing a full functional spec if needed but wanted to
>get this up for discussion ASAP.
>
>I have created a JIRA ticket:
>https://issues.apache.org/jira/browse/CLOUDSTACK-4774
>
>Thanks,
>Chris
>--
>Chris Suich
>chris.su...@netapp.com
>NetApp Software Engineer
>Data Center Platforms ­ Cloud Solutions
>Citrix, Cisco & Red Hat
>

Re: [PROPOSAL] Revert to VM disk Snapshot

[Chiradeep Vittal]

+1. 

On 9/30/13 2:31 PM, "SuichII, Christopher"  wrote:

>The storage subsystem API currently has an interface for takeSnapshot()
>and an associated externally facing API for takeSnapshot. There is also a
>method on the primary data store interface for revertSnapshot(). However,
>this method is unused. We would like this storage subsystem interface
>method be hooked up to an externally facing API so that we can provide
>true VM disk backup and recovery.
>
>I will work on formalizing a full functional spec but wanted to get this
>up for discussion ASAP.
>
>I have created a JIRA ticket:
>https://issues.apache.org/jira/browse/CLOUDSTACK-4771
>
>Thanks,
>Chris
>--
>Chris Suich
>chris.su...@netapp.com
>NetApp Software Engineer
>Data Center Platforms ­ Cloud Solutions
>Citrix, Cisco & Red Hat
>

Re: [PROPOSAL] SSVM Generic Copy

[Chiradeep Vittal]

While SSVM is OK to understand the concept, it is more generically a
transfer daemon which can run in a VM or not. For example, QuickCloud[1]
takes the SSVM's daemon out and runs it on a standard Linux OS.
[1] https://cwiki.apache.org/confluence/x/clnVAQ

On 9/30/13 2:37 PM, "SuichII, Christopher"  wrote:

>The storage subsystem currently uses a number of hypervisor APIs for
>transferring files between data stores (both primary and secondary).
>However, while implementing the storage subsystem API as a storage
>provider, we have discovered that there is a need for a generic copy
>method that can copy files between (almost) any source and destination.
>For example, if we need to copy a file from our storage to S3 or Swift.
>It would make more sense for the SSVM to provide a generic method for
>copying files than for us to implement a copy method for S3, Swift, etc.
>Additionally, the SSVM already has NFS volumes mounted and has easier
>access to primary and secondary storage.
>
>I will work on formalizing a full functional spec if needed but wanted to
>get this up for discussion ASAP.
>
>I have created a JIRA ticket:
>https://issues.apache.org/jira/browse/CLOUDSTACK-4773
>
>Thanks,
>Chris
>--
>Chris Suich
>chris.su...@netapp.com
>NetApp Software Engineer
>Data Center Platforms ­ Cloud Solutions
>Citrix, Cisco & Red Hat
>

[POLL] Latency between Management Server and zones

[Chiradeep Vittal]

[Apologize for the crosspost, but I think there may be answers from the dev 
perspective]
[Also, this is poll / opinion question]

What is the maximum latency / minimum bandwidth folks have between their 
Management Server and the hypervisor?
What works? What needs to be tweaked?

TIA

[DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

[Chiradeep Vittal]

We have a couple of people trying to expose the advanced capabilities of the 
underlying physical resources to the end-user. In the case of Nicolas FOATA, he 
is trying to expose some of the advanced functions of XenServer/XCP, and in the 
case of Daan, he is trying to expose some feature of HAProxy.

Users are ideally abstracted from these details and shouldn't have to wonder 
which offering to choose [because they are not Xen/HAProxy experts].
After all one of the goals of CS is to hide these messy details and let users 
focus on their apps.

Is there a possibility of a generic way of leaking abstractions for 
sufficiently advanced users?

https://reviews.apache.org/r/13238/
https://reviews.apache.org/r/14320/
https://reviews.apache.org/r/13896/

BTW, I really prefer that these changes are discussed by putting up an FS on 
the wiki rather than submitting patch requests.
If it touches more than a few files, it is probably worth discussing with a 
[DISCUSS] tag line.
Also, it requires tests.

Re: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

Got it. Any other OSS tool out there similar to monit?

On 10/1/13 8:24 AM, "David Nalley"  wrote:

>On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal
> wrote:
>> SNMP wouldn't restart a failed process nor would it generate alerts. It
>>is
>> simply too generic for the requirements outlined here. The proposal does
>> not talk about modifying monit, just using it. That wouldn't trigger the
>> AGPL.
>
>Let me restate my objection to anything AGPL.
>People are largely comfortable with GPLv2 software - Linux is
>ubiquitous. Many legal departments routinely prohibit GPLv3 software
>(we actually saw this when CS was GPLv3 licensed.) But the Affero GPL
>license is anathema in many corporate environments, and by forcing it
>on folks in the default System VM I fear it will hurt adoption of
>CloudStack.
>
>--David

Wiki access

[Chiradeep Vittal]

Apparently, edit access has been revoked for all. Who do we contact for edit 
permissions?

TIA

Re: [DISCUSS] Breaking out Marvin from CloudStack

[Chiradeep Vittal]

Chip, that makes perfect sense to me.

On 10/2/13 1:10 PM, "Chip Childers"  wrote:

>On Wed, Oct 02, 2013 at 07:38:33PM +, Alex Huang wrote:
>> I don't really understand what purpose would this serve.  Would we ever
>>use newer marvin against older CloudStack or vice versa?  What's the
>>benefit?  
>> 
>> I can understand it for cloudmonkey because cloudmonkey is an admin cli
>>tool and reving it differently is not a bad idea.  I just don't see it
>>for marvin and, especially for the tests.
>> 
>> --Alex
>
>IMO, we should consider Marvin the "framework" to be the thing to break
>out, and the tests should be different from the framework.
>
>Now that leads to the question: to test or not to test (in the main
>repo)?
>
>I'd suggest that *tests* belong in the main repo, because they are tied
>to the software's capabilities and versions.
>
>The Marvin framework, on the other hand, since the re-work that Prasanna
>did, is mostly distinct (and uses API discovery).
>
>Anyone else agree?

Re: Wiki access

[Chiradeep Vittal]

Sorry, I'm not seeing the ability to change space permissions.

On 10/2/13 2:01 PM, "Chip Childers"  wrote:

>Not all committers were easy to find, but those that I did should be all
>set.
>
>So committers / contributors = provide your confluence ID's if you can't
>add / edit pages.  PMC folks - help add them please.
>
>
>On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>wrote:
>
>> There were major issues with Spam on the wiki, so infra changed the
>> permissions.
>>
>> I've just gone and added all PMC members to the space as space admins.
>>  That means all PMC members can help deal with this issue (or at least
>> those that I could find in the wiki user list).
>>
>> I'm going to deal with committers next.  That permission level needs to
>> exclude space admin.  I'm using alena1108 as the example for committer /
>> contributor permissions.
>>
>> So if you are not a committer, give your confluence ID in this thread
>>and
>> PMC folks can help get them added (make them look like alena's perms).
>>
>>
>>
>>
>> On Wed, Oct 2, 2013 at 4:35 PM, Chiradeep Vittal <
>> chiradeep.vit...@citrix.com> wrote:
>>
>>> Apparently, edit access has been revoked for all. Who do we contact for
>>> edit permissions?
>>>
>>> TIA
>>>
>>
>>

Re: HA is broken on master

[Chiradeep Vittal]

Perhaps as a result of this work:
https://cwiki.apache.org/confluence/x/tYvlAQ
I think Kelven is trying to separate the job state (starting, stopping)
from the actual VM state.

On 10/2/13 3:36 PM, "Darren Shepherd"  wrote:

>Alex,
>
>In scheduleRestart() when it calls _itMgr.advanceStop() it used to
>pass the VO.  Now it passes a UUID.  So the VO the HA manager holds is
>out of sync with the DB and the recorded previous state and update
>count are wrong, so HA will just stop the VM in the worker.
>
>I really think the update count approach is far too fragile.  For
>example, currently if you try to start a VM and it fails, the update
>count will change.  But the current code will record the new update
>count so the next try it will have the updated count.  I can see the
>following issue, maybe there's some work around for it.  Imagine you
>have a large failure, the stuff really hits the fan.  So you have
>1000's of HA jobs trying to run and things just keep failing.  So to
>stop the churn you shutdown the mgmt stack to figure out whats up with
>infrastructure.  There's a really good chance that you would kill the
>mgmt stack while a VM was in starting.  So now the hawork update count
>will be out of sync with the current DB.  So when you bring the mgmt
>stack back up.  It won't try to restart that VM.
>
>Maybe that situation is taken care of somehow, but I could probably
>dream up another one.  I think it is far simpler that when a user
>starts a VM, you record in the vm_instance table, in a new column,
>"Should be running", then when the HA worker processes the record, it
>will always say it should be running.  If the user does a stop, you
>clear that column.  This has the added benefit of when things are bad
>and a user starts clicking restart/start, they won't mess with the HA.
> I think, maybe things have changed, but before what I would see is
>that we'd have an issue so VMs should be started, but weren't.  So HA
>was trying, but it kept failing.  The user would login and see they're
>VM is down, so they would click start.  But that would fail (similar
>to how HA was also failing).  So the VM would stay in stopped, but
>since they touched the VM, the update count changed and HA wouldn't
>start it back up when the infra worked again.  So customers who
>proactively tried to do something would get penalized in that their
>downtime was longer because cloudstack wouldn't bring their VM back up
>like the other VMs.
>
>Darren

Re: HA is broken on master

[Chiradeep Vittal]

My bad. I thought this was merged into master, but it isn't.

On 10/2/13 4:24 PM, "David Nalley"  wrote:

>Why is the work happening in master?
>
>
>On Wed, Oct 2, 2013 at 7:09 PM, Chiradeep Vittal
> wrote:
>> Perhaps as a result of this work:
>> https://cwiki.apache.org/confluence/x/tYvlAQ
>> I think Kelven is trying to separate the job state (starting, stopping)
>> from the actual VM state.
>>
>> On 10/2/13 3:36 PM, "Darren Shepherd" 
>>wrote:
>>
>>>Alex,
>>>
>>>In scheduleRestart() when it calls _itMgr.advanceStop() it used to
>>>pass the VO.  Now it passes a UUID.  So the VO the HA manager holds is
>>>out of sync with the DB and the recorded previous state and update
>>>count are wrong, so HA will just stop the VM in the worker.
>>>
>>>I really think the update count approach is far too fragile.  For
>>>example, currently if you try to start a VM and it fails, the update
>>>count will change.  But the current code will record the new update
>>>count so the next try it will have the updated count.  I can see the
>>>following issue, maybe there's some work around for it.  Imagine you
>>>have a large failure, the stuff really hits the fan.  So you have
>>>1000's of HA jobs trying to run and things just keep failing.  So to
>>>stop the churn you shutdown the mgmt stack to figure out whats up with
>>>infrastructure.  There's a really good chance that you would kill the
>>>mgmt stack while a VM was in starting.  So now the hawork update count
>>>will be out of sync with the current DB.  So when you bring the mgmt
>>>stack back up.  It won't try to restart that VM.
>>>
>>>Maybe that situation is taken care of somehow, but I could probably
>>>dream up another one.  I think it is far simpler that when a user
>>>starts a VM, you record in the vm_instance table, in a new column,
>>>"Should be running", then when the HA worker processes the record, it
>>>will always say it should be running.  If the user does a stop, you
>>>clear that column.  This has the added benefit of when things are bad
>>>and a user starts clicking restart/start, they won't mess with the HA.
>>> I think, maybe things have changed, but before what I would see is
>>>that we'd have an issue so VMs should be started, but weren't.  So HA
>>>was trying, but it kept failing.  The user would login and see they're
>>>VM is down, so they would click start.  But that would fail (similar
>>>to how HA was also failing).  So the VM would stay in stopped, but
>>>since they touched the VM, the update count changed and HA wouldn't
>>>start it back up when the infra worked again.  So customers who
>>>proactively tried to do something would get penalized in that their
>>>downtime was longer because cloudstack wouldn't bring their VM back up
>>>like the other VMs.
>>>
>>>Darren
>>

Re: System VM

[Chiradeep Vittal]

I enabled cloudfront on this so that folks in
S.America/Africa/Europe/Asia/Oceania can have better speeds.

Just substitute d21ifhcun6b1t2.cloudfront.net for download.cloud.com



On 10/2/13 4:21 PM, "Travis Graham"  wrote:

>Here are the correct links for 4.2.0:
>
>Xenserver : 
>http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master
>-xen.vhd.bz2   
>KVM  :
>http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master
>-kvm.qcow2.bz2 
>VMware   : 
>http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova
>
>Travis
>
>On Oct 2, 2013, at 7:00 PM, Maurice Lawler  wrote:
>
>> Hello,
>> 
>> Going through the install, I noticed the system VM template hasnt
>>changed URL. Is it safe to assume to utilize this one:
>> 
>> # 
>>/usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt
>> -m /mnt/secondary -u
>>http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.b
>>z2 -h kvm -s  -F
>> 
>> 
>> Or should I be utilizing another?
>> 
>> - Maurice
>

Re: Wiki access

[Chiradeep Vittal]

Daan, it is at the 'Browse' drop down at the upper right. Heh


On 10/3/13 10:33 AM, "Daan Hoogland"  wrote:

>I'm not seeing any links for editting permissions either. id == dahn
>
>
>On Thu, Oct 3, 2013 at 7:26 PM, Ian Duffy  wrote:
>
>> Hi,
>>
>> May I get access to edit/add pages as well?
>> My username is imduffy15.
>>
>> Thanks,
>> Ian
>>
>> On 3 October 2013 16:13, Chip Childers 
>>wrote:
>> > On Thu, Oct 03, 2013 at 09:58:03AM +, Bharat Kumar wrote:
>> >> Hi All,
>> >> any one please grant me the edit or add page permission to cwiki.
>> my user name is bharat.kumar
>> >
>> > Done
>>

Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

[Chiradeep Vittal]

I was thinking along the same lines that a offering could have a generic
key/value map (where the value could be a string/json string/whatever).
CloudStack core wouldn't have any idea about the semantics of the keys or
values, but the specific hypervisor/provider might decide to interpret it.


On 10/3/13 11:15 AM, "Darren Shepherd"  wrote:

>We are always going to run into the issue where they're implementation
>specific features that can't be represented in a generic way in the
>API.  First class attributes in the API need to essentially be the
>lowest common denominator.  ACS already has this pattern of *_details
>tables.  I honestly don't know completely how they are used, but I
>would hope that pattern could be used to address these types of
>issues.  By allowing the admin to add arbitrary key/value pairs to the
>various offerings/entities we can use that to tap into provider
>specific or advanced configuration.  For the http close proposal you
>could just add haproxy.httpClose=true on the network offering and the
>haproxy impl can respect that and use it.  So implementations can
>document what additional key/value parameters they support to access
>advanced features.
>
>Review 13896 adds an otherOptions field to the service offering.
>Conceptually that is fine in my mind, but I just don't understand why
>the *_details tables can't be used instead.  Just like XenServer has
>other_config on all types, I'd like it if ACS had a similar thing
>(which I kinda, sorta think it does?).  So we should be able to
>arbitrary data onto any type.  Can somebody comment on how this idea
>may relate with the existing implementation of "details" and "tags" in
>ACS?
>
>Darren
>
>On Thu, Oct 3, 2013 at 10:21 AM, Daan Hoogland 
>wrote:
>> Murali,
>>
>> What our admins need is the ability to instantiate an abstract thing
>>called
>> a virtual redundant high available router. They need be able to tune it
>> with all sorts of features is such a way that other routers redundant or
>> not and high availible or not, may but do not have to have the same
>>tuning
>> parameters. This 'feature' of httpClose is just one of the many things
>>they
>> need to be able to tune. Others include a more fine grained control over
>> the iptables/firewall rules and monitoring of the functionality/daemons
>> running on the machines. I am not biased as to the way how to
>>do/implement
>> this control. The networkoffering seemed like the way to do it.
>>
>> Having said that I didn't think that httpClose would be considered
>>haproxy
>> specific. It seems worrying that someone could device a proxy or a
>> loadbalancer that does not support either one of the features of
>> maximizing - or pooling connections. I'm not into that market recently
>>so I
>> might be mistaking. This maybe besides the point but it discomforts me
>> somewhat.
>>
>> regards,
>> Daan
>>
>>
>> On Thu, Oct 3, 2013 at 2:22 PM, murali reddy
>>wrote:
>>
>>> On Thu, Oct 3, 2013 at 4:18 PM, Daan Hoogland >> >wrote:
>>>
>>> > Chiradeep,
>>> >
>>> > I have been thinking about your concern and there is something
>>>bothering
>>> me
>>> > about it. The issue CLOUDSTACK-4328 of which
>>> > https://reviews.apache.org/r/14320/ is an implementation. This issue
>>>has
>>> > been brought up by the engineers at Schuberg Philis. These are cloud
>>> > operators and domain admins. So these are the people that need to be
>>> > bothered by this tuning and they are certainly haproxy and xen
>>>experts to
>>> > an extend. For them not being able to use connection caching was a
>>>bug.
>>> And
>>> > the proposed solution still seems reasonable to me. It is exposing
>>>the
>>> > abstract feature only to those instantiating a vpc, isn't it? This
>>>last
>>> > question probably touches on the reason you are addressing my
>>>submission
>>> > together with the ones from Nicolas  I see only people instantiating
>>>a
>>> vpc
>>> > having to be bothered by which netoffering to use (with respect to
>>> > httpClose functionality) If this is not the case how should I isolate
>>> this
>>> > concern from other , more mondain users?
>>> >
>>> > btw I did not create an FS page as the issue was created as a jira
>>> ticket.
>>> > I am willing to do that in hind sight but want to have a path to

Re: Wiki access

[Chiradeep Vittal]

Mike, Tuna, Srinivas, Go, done.

On 10/3/13 9:12 PM, "Mike Tutkowski"  wrote:

>I seem to need edit access, as well.
>
>I'm usually logged in by default, but I believe my username is
>mike-tutkowski (else please try mtutkowski).
>
>Thanks!
>
>
>On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba  wrote:
>
>> Hi Chip,
>>
>> Please grant me to edit pages. My id is "gochiba".
>>
>>
>> On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers > >wrote:
>>
>> > Not all committers were easy to find, but those that I did should be
>>all
>> > set.
>> >
>> > So committers / contributors = provide your confluence ID's if you
>>can't
>> > add / edit pages.  PMC folks - help add them please.
>> >
>> >
>> > On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>>> > >wrote:
>> >
>> > > There were major issues with Spam on the wiki, so infra changed the
>> > > permissions.
>> > >
>> > > I've just gone and added all PMC members to the space as space
>>admins.
>> > >  That means all PMC members can help deal with this issue (or at
>>least
>> > > those that I could find in the wiki user list).
>> > >
>> > > I'm going to deal with committers next.  That permission level
>>needs to
>> > > exclude space admin.  I'm using alena1108 as the example for
>>committer
>> /
>> > > contributor permissions.
>> > >
>> > > So if you are not a committer, give your confluence ID in this
>>thread
>> and
>> > > PMC folks can help get them added (make them look like alena's
>>perms).
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Oct 2, 2013 at 4:35 PM, Chiradeep Vittal <
>> > > chiradeep.vit...@citrix.com> wrote:
>> > >
>> > >> Apparently, edit access has been revoked for all. Who do we contact
>> for
>> > >> edit permissions?
>> > >>
>> > >> TIA
>> > >>
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> 千葉 豪  Go Chiba
>> E-mail:go.ch...@gmail.com
>>
>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*?*

Re: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

Well just make sure that your script is resilient to its own crashes as
well.

On 10/4/13 1:59 AM, "Jayapal Reddy Uradi" 
wrote:

>Hi,
>
>I am planning to write script utility to monitor processes and restart on
>the event of failure. It will also logs the events.
>
>Thanks,
>Jayapal
>
>On 02-Oct-2013, at 3:25 AM, Simon Weller  wrote:
>
>> supervisord maybe?
>> 
>> - Original Message -
>> 
>> From: "Chiradeep Vittal" 
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, October 1, 2013 4:45:56 PM
>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>> 
>> Got it. Any other OSS tool out there similar to monit?
>> 
>> On 10/1/13 8:24 AM, "David Nalley"  wrote:
>> 
>>> On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal
>>>  wrote:
>>>> SNMP wouldn't restart a failed process nor would it generate alerts.
>>>>It 
>>>> is 
>>>> simply too generic for the requirements outlined here. The proposal
>>>>does 
>>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>>the 
>>>> AGPL. 
>>> 
>>> Let me restate my objection to anything AGPL.
>>> People are largely comfortable with GPLv2 software - Linux is
>>> ubiquitous. Many legal departments routinely prohibit GPLv3 software
>>> (we actually saw this when CS was GPLv3 licensed.) But the Affero GPL
>>> license is anathema in many corporate environments, and by forcing it
>>> on folks in the default System VM I fear it will hurt adoption of
>>> CloudStack. 
>>> 
>>> --David 
>> 
>> 
>

Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

[Chiradeep Vittal]

I've checked the Netscaler and HAProxy docs, this appears to be artifact
of the HAProxy implementation (inability to support keep-alive).
For a cloud operator that chooses Netscaler or F5 for load balancing, this
won't make any sense.

On 10/3/13 12:55 PM, "Daan Hoogland"  wrote:

>On Thu, Oct 3, 2013 at 9:02 PM, Chip Childers
>wrote:
>
>> a model for extensions like that makes perfect sense.
>
>
>
>This model sound fine indeed. It makes no sense for httpClose however.
>
>Here's my concern:
>So when an early adapter is implemented and the rest of the market comes
>to
>their senses, how do we migrate without running into migration/upgrade
>problems?
>httpClose is a flag controlling connection pooling. I probably choose the
>wrong name. It is something that any implementation will support or should
>have supported already. Am I going to implement it as a key/value now to
>later implemented as I have done anyway? I don't like this idea.
>
>Don't get me wrong the pattern described by you guys is fine in some
>situations. I don't think it is applicable to this feature.
>
>regards,
>Daan

Re: [MERGE] spring-modularization to master - Spring Modularization

[Chiradeep Vittal]

I'm not getting any notifications of BVT test failures. Where do I
subscribe?

On 10/8/13 10:20 AM, "Darren Shepherd"  wrote:

>From what I can gather it seems that master currently fails the BVT
>(and know when I say BVT I mean that black box that apparently exists
>somewhere doing something, but I have no clue what it really means).
>So in turn my spring modularization branch will additionally fail BVT.
> Citrix internal QA ran some tests against my branch and they mostly
>passed but some failed.  Its quite difficult to sort through this all
>because tests are failing on master.  So I don't know what to do at
>this point.  At least my branch won't completely blow up everything.
>I just know the longer it takes to merge this the more painful it will
>be
>
>Honestly this is all quite frustrating for myself being new to
>contributing to ACS.  I feel somewhat lost in the whole process of how
>to get features in.  I'll refrain from venting my frustrations.
>
>Darren

Re: Call for 4.3 and 4.2.1 Release Managers!

[Chiradeep Vittal]

+1.
We should get a call out to the community to see who is expecting to merge
for 4.3. 
Although  10/31 is the feature freeze date, proposals and branches should
be in already IMHO.

On 10/8/13 9:54 AM, "Chip Childers"  wrote:

>On Tue, Oct 08, 2013 at 04:49:24PM +, Animesh Chaturvedi wrote:
>> 
>> > Whomever wants to take the lead for 4.3 should probably (IMO), start a
>> > discussion on (1) coordination of work and
>> [Animesh>] Since we are getting closer to code freeze date and we
>>cannot find overall release management I can pick up 4.3 and call out
>>the roles and ask for volunteers for them.
>
>Sounds good.
>
>> 
>> (2) re-thinking the schedule
>> > to reset based on both historic performance and reality of the
>>calendar
>> > (we've really been working on 4.2 when we should have moved on to
>>4.3).
>> [Animesh>] Chip my preference would be to stick to the timeline of 4.3
>>which will make it a smaller release but will give us the opportunity to
>>clear up our technical debt.
>
>+1 to being smaller and tech-debt focused.
>
>-chip

Re: [MERGE] spring-modularization to master - Spring Modularization

[Chiradeep Vittal]

I'm personally +1. Simulator seems to work

On 10/8/13 3:12 PM, "Darren Shepherd"  wrote:

>So what's the verdict?  What would it take for everyone to feel warm
>and fuzzy about this merge, given the troubled past this community has
>had with Spring.  I'm not saying the code is perfect, but so far its
>not terribly bad :)
>
>Darren
>
>On Tue, Oct 8, 2013 at 11:10 AM, Chiradeep Vittal
> wrote:
>> I'm not getting any notifications of BVT test failures. Where do I
>> subscribe?
>>
>> On 10/8/13 10:20 AM, "Darren Shepherd" 
>>wrote:
>>
>> >From what I can gather it seems that master currently fails the BVT
>>>(and know when I say BVT I mean that black box that apparently exists
>>>somewhere doing something, but I have no clue what it really means).
>>>So in turn my spring modularization branch will additionally fail BVT.
>>> Citrix internal QA ran some tests against my branch and they mostly
>>>passed but some failed.  Its quite difficult to sort through this all
>>>because tests are failing on master.  So I don't know what to do at
>>>this point.  At least my branch won't completely blow up everything.
>>>I just know the longer it takes to merge this the more painful it will
>>>be
>>>
>>>Honestly this is all quite frustrating for myself being new to
>>>contributing to ACS.  I feel somewhat lost in the whole process of how
>>>to get features in.  I'll refrain from venting my frustrations.
>>>
>>>Darren
>>

Re: [DISCUSS] Transaction Hell

[Chiradeep Vittal]

+1 to option B (for a lot of the reasons enunciated by Darren).
Also, let's get this in right away so that by 1/31/2014 we are confident
about the change and fixed any bugs uncovered by the new scheme.

On 10/9/13 10:29 AM, "Darren Shepherd"  wrote:

>Pedro,
>
>From a high level I think we'd probably agree.  Generally I feel an
>IaaS platform is largely a metadata management framework that stores
>the "desired" state of the infrastructure and then pro-actively tries
>to reconcile the desired state with reality.  So failures should be
>recovered from easily as inconsistency will be discovered and
>reconciled.  Having sad that, ACS is not at all like that.  It is very
>task oriented.  Hopefully I/we/everyone can change that, its a huge
>concern of mine.  The general approach in ACS I see is do task X and
>hopefully it works.  If it doesn't work, well hopefully we didn't
>leave things in an inconsistent state.  If we find it does leave
>things in an inconsistent state, write a cleanup thread to fix bad
>things in bad states
>
>Regarding TX specifically.  This is a huge topic.  I really don't know
>where to start.  I have so many complaints with the data access in
>ACS.  There's what I'd like to see, but its so far from what it really
>is.  Instead I'll address specifically your question.
>
>I wish we were doing transaction per API, but I don't think that was
>ever a consideration.  I do think the sync portion of API commands
>should be wrapped in a single transaction.  I really think the
>original intention of the Transaction framework was to assist in
>cleaning up resources that people always forget to close.  I think
>that is mostly it.
>
>The general guidelines of how I'd like transactions to work would be
>
>1) Synchronous portions of API commands are wrapped in a single
>transaction.  Transaction propagation capability from spring tx can
>then handle nesting transaction as more complicated transaction
>management may be need in certain places.
>
>2) Async jobs that run in a background threads should do small fine
>grained transaction management.  Ideally no transactions.
>Transactions should not be used as a locking mechanism.
>
>Having said that, there are currently so many technical issues in
>getting to that.  For example, with point 1, because IPC/MessageBus
>and EventBus were added recently, that makes it difficult to do 1.
>The problem is that you can't send a message while a DB tx is open
>because the reciever may get the message before the commit.  So
>messaging frameworks have to be written in consideration of the
>transaction management.  Not saying you need to do complex XA style
>transactions, there's simpler ways to do that.  So regarding points 1
>and 2 I said.  That's what I'd like to see, but I know its a long road
>to that.
>
>Option B is really about introducing an API that will eventually serve
>as a lightweight wrapper around Spring TX.  In the short term, if I do
>option B, the implementation of the code will still be the custom ACS
>TX mgmt.  So across modules, its sorta kinda works but not really.
>But if I do the second step of replacing custom ACS TX impl with
>Spring TX, it will follow how Spring TX works.  If we have Sprint TX
>we can then leverage the transaction propagation features of it to
>more sanely handle transaction nesting.
>
>I feel I went a bit the weeds with that response, but maybe something
>in there made sense.
>
>Darren
>
>On Wed, Oct 9, 2013 at 9:31 AM, Pedro Roque Marques
> wrote:
>> Darren,
>> My assumption when I tried to make sense of the transaction code is
>>that the underlying motivation is that the code is trying to create a
>>transaction per API call and then allow multiple modules to implement
>>that API call...
>> i.e. the intent is do use a bit of what i would call a "web-server
>>logic"...
>>
>> 1. API call starts.
>> 2. Module X starts transaction...
>> 3. Module Y does some other changes in the DB...
>> 4. Either the API call completes successfully or not... commit or error
>>back to the user.
>>
>>  I suspect that this was probably the starting point... but it doesn't
>>really work as i describe above. Often when the plugin i'm working on
>>screws up (or XenServer is misconfigured) one ends up with DB objects in
>>inconsistent state.
>>
>> I suspect that the DB Transaction design needs to include what is the
>>methodology for the design of the management server.
>>
>> In an ideal world, i would say that API calls just check authorization
>>and quotas and should store the intent of the management server to reach
>>the desired state. State machines that can then deal with transient
>>failures should then attempt to move the state of the system to the
>>state intended by the user. That however doesn't seem to reflect the
>>current state of the management server.
>>
>> I may be completely wrong... Can you give an example in proposal B of
>>how a transaction would span multiple modules of code ?
>>
>>   Pedro.
>>
>> On Oct 9, 2013, at 1:44 AM, D

Re: System VM template caching

[Chiradeep Vittal]

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Releas
e_Notes/upgrade-instructions.html


On 10/9/13 10:11 AM, "kel...@backbonetechnology.com"
 wrote:

>We tested deleting the template on primary storage, and it failed to
>regenerate.
>
>What is the documented method for registering the new template, can you
>link to it?
>
>It seems many of us failed to find any documentation about updating the
>template period, not just in the 4.2 release doc under upgrades from 4.1
>
>Thanks.
>
>Sent from my HTC
>
>- Reply message -
>From: "Ahmad Emneina" 
>To: "dev@cloudstack.apache.org" 
>Subject: System VM template caching
>Date: Wed, Oct 9, 2013 9:48 AM
>
>there might be a more sound way than swapping the template on secondary
>storage and hacking the db. I figure one should be able to register the
>template, via the documented route... wait for download to succeed,
>upgrade
>the binary bits. then when the system vm's fail to launch. delete the
>cached template on primary storage. That should be enough to trigger a new
>system vm propagated to the primary storage. I find it hard to believe
>this
>passed QA...
>
>
>On Wed, Oct 9, 2013 at 9:39 AM, kel...@backbonetechnology.com <
>kel...@backbonetechnology.com> wrote:
>
>> This process you mention for registering as a user VM I can't find in
>>the
>> upgrade guide. Do you have a link?
>>
>> The work around works because CloudStack defaults to re-download the
>> system template is it is in NOT_DOWNLOADED status. How ever the database
>> never gets updated for the life of the build.
>>
>> CS is designed it seems to only ever have a single unaltered template_id
>> '3' record. And I guess the template download script just overwrites the
>> sane GUID filename.
>>
>> Seems like a solution that could be handled in a better way.
>>
>> Either way, this is what has been working for us in the community.
>>
>> Sent from my HTC
>>
>> - Reply message -
>> From: "Sebastien Goasguen" 
>> To: "dev@cloudstack.apache.org" 
>> Cc: "dev@cloudstack.apache.org" 
>> Subject: System VM template caching
>> Date: Wed, Oct 9, 2013 9:30 AM
>>
>> Are you sure about this ? I thought we needed to register them as user
>>vm
>> and that the upgrade would convert them to systemVM automatically
>>
>> -Sebastien
>>
>> On 9 Oct 2013, at 17:22, "kel...@backbonetechnology.com"<
>> kel...@backbonetechnology.com> wrote:
>>
>> > I was able to create a work around and several community builders
>>tested
>> it out for me and it works.
>> >
>> > I will not submit to docs as it's a hack, but I have updated the JIRA
>> ticket.
>> >
>> > Work around can be found at:
>> >
>> >
>> 
>>http://cloud.kelceydamage.com/cloudfire/blog/2013/10/08/conquering-the-cl
>>oudstack-4-2-dragon-kvm/
>> >
>> > Thanks,
>> >
>> > -Kelcey
>> >
>> > Sent from my HTC
>> >
>> > - Reply message -
>> > From: "Soheil Eizadi" 
>> > To: "dev@cloudstack.apache.org" 
>> > Subject: System VM template caching
>> > Date: Tue, Oct 8, 2013 9:49 PM
>> >
>> > This seems similar to a problem I had on 4.3 Master with System VM
>> creation. If it is the same problem you can check from API command
>> ListTemplateCommand(), from CloudMonkey and see if it returns a bogus
>> cached value. Then you know it is the same problem.
>> > -Soheil
>> >
>> >
>> 
>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201309.mbox/%3C67
>>17ec2e5a665a40a5af626d7d4fa90625e2e...@x2008mb1.infoblox.com%3E
>> >
>> > 
>> > From: Kelcey Jamison Damage [kel...@backbonetechnology.com]
>> > Sent: Tuesday, October 08, 2013 12:19 PM
>> > To: Cloud Dev
>> > Subject: [ACS 4.2][Upgrade Issue] System VM template caching
>> >
>> > Hi,
>> >
>> > Several of us in the community have found that with the 4.2 upgrade,
>> when we download and install the latest system VM template, CloudStack
>> refuses to use this template for new system VM creation. CloudStack
>>appears
>> to be usin a cached or master-clone variant of the old template.
>> >
>> > This is causing may KVM+ 4.2 users to have broken clouds, A bug report
>> has been filed: https://issues.apache.org/jira/browse/CLOUDSTACK-4826
>> >
>> > My question is: Does anyone know where this cached template is stored?
>> when CloudStack goes to make a new system VM, where does it look first
>>for
>> the template? We have observed through testing that this is no secondary
>> storage.
>> >
>> > Thanks in advance.
>> >
>> > Kelcey Damage | Infrastructure Systems Architect
>> > Strategy | Automation | Cloud Computing | Technology Development
>> >
>> > Backbone Technology, Inc
>> > 604-331-1152 ext. 114

Re: Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[Chiradeep Vittal]

Sure.

On 10/9/13 1:55 PM, "Daan Hoogland"  wrote:

>H Chiradeep,
>
>Would you considder this if I rename the option to keepAlive, adding a
>API description field stating that it only has effect on HAProxy (for
>now)?
>
>regards,
>Daan
>
>On Tue, Oct 1, 2013 at 10:50 AM, Daan Hoogland 
>wrote:
>> Ok Chiradeep,
>>
>> I see where you worries are. I'll study the stickiness implementation.
>>If it
>> is not a zone wide thing I'll consider it.
>>
>> I disagree that the feature is implementation specific. The tuning is.
>>And
>> the tuning the feature are not the same. The abstraction of the feature
>> httpClose, which is only implemented by haproxy (let's assume) as a set
>>of
>> options is the reason for someone to choose for this implementation of a
>> load balancer. This should be leveraged.
>>
>> Actually in the Schuberg Philis implementation it must. The solution
>>that is
>> now done at the actual site is hacked into the running VR. This will
>>then
>> lead to an emergency if the router is recreated for some reason.
>>
>> regards,
>> Daan
>>
>> On Mon, Sep 30, 2013 at 11:50 PM, Chiradeep Vittal
>>  wrote:
>>>
>>> My point is that it is a tuning that is specific for HAProxy and
>>>shouldn't
>>> be exposed in an abstraction like the CS API.
>>> (After all, how do I choose, as an end-user Offering A with httpClose
>>>or
>>> offering B without httpClose). If there is another desirable feature Y
>>>in
>>> Netscaler, do you anticipate changing another dozen files for that
>>> feature?
>>>
>>> If you look at the stickiness policy feature, it isn't tied to the
>>>service
>>> offering despite there being some differences between stickiness
>>> capabilities between different LB providers.
>>>
>>>
>>>
>>> On 9/28/13 4:18 AM, "Daan Hoogland"  wrote:
>>>
>>> >Chiradeep,
>>> >
>>> >the network offerings are created by the cloud operator aren't they?
>>>The
>>> >netscaler  en f5 modules will have to implement it's own behavior on
>>> >httpClose. in case of haproxy it means no mode http and option
>>>httpclose
>>> >(and some other things)
>>> >
>>> >If you define it zone wide every tenant has the same setting whilst
>>>you
>>> >want this to tune setting (like with maxConnections) for a tenant.
>>> >
>>> >regards,
>>> >Daan
>>> >
>>> >
>>> >On Thu, Sep 26, 2013 at 10:57 PM, Chiradeep Vittal
>>> >wrote:
>>> >
>>> >>This is an automatically generated e-mail. To reply, visit:
>>> >> https://reviews.apache.org/r/14320/
>>> >>
>>> >> Not sure if this should be in the API since it is a HAProxy-specific
>>> >>configuration. This wouldn't apply to Netscaler or F5.
>>> >> After all the end user has no idea if he is using HAProxy of
>>>Netscaler
>>> >>or F5.
>>> >>
>>> >> Likely this flag is of interest to the cloud operator only, so why
>>>not
>>> >>put it in zone-wide config instead of the network offering.
>>> >> Do you really see someone creating 2 offerings: one with HttpClose
>>>and
>>> >>one without HttpClose?
>>> >>
>>> >>
>>> >> - Chiradeep Vittal
>>> >>
>>> >> On September 26th, 2013, 7:01 p.m. UTC, daan Hoogland wrote:
>>> >>   Review request for cloudstack and Wei Zhou.
>>> >> By daan Hoogland.
>>> >>
>>> >> *Updated Sept. 26, 2013, 7:01 p.m.*
>>> >>  *Bugs: * CLOUDSTACK-4328
>>> >>  *Repository: * cloudstack-git
>>> >> Description
>>> >>
>>> >> add boolean option httpModeEnabled to the service offering for use
>>>in
>>> >>haproxy conf
>>> >>
>>> >>   Testing
>>> >>
>>> >> created unit test.
>>> >> instantiated a network with some loadbalancer rule based on a
>>>netoffer
>>> >>with the option to true/false and maxconnections to a non default
>>>value
>>> >>-> checked haproxy.cfg on the router
>>> >>
>>> >>   Diffs
>>> >>
>>> >>- api/src/com/cloud/off

Re: [PROPOSAL] Remove Setters from *JoinVO

[Chiradeep Vittal]

If there's no compile errors then it should not require any tests.

On 10/10/13 8:02 AM, "SuichII, Christopher"  wrote:

>I went ahead and removed all setters from *JoinVOs this morning and
>played around in my environment. There were no compile errors since
>nobody called those setters, everything seems to be working just fine and
>there aren't any errors in any of the logs.
>
>Does anyone have any suggestions on how to properly test this? I can't
>imagine we're using Java reflection somewhere to actually invoke the
>setter for a given field. Other than that, with no compile errors, I
>don't see this causing any issues.
>
>-Chris
>-- 
>Chris Suich
>chris.su...@netapp.com
>NetApp Software Engineer
>Data Center Platforms ­ Cloud Solutions
>Citrix, Cisco & Red Hat
>
>On Oct 10, 2013, at 1:40 AM, Koushik Das  wrote:
>
>> Views are meant to be read only. So +1 for removing setters.
>> 
>> On 04-Oct-2013, at 10:59 PM, "SuichII, Christopher"
>> wrote:
>> 
>>> *JoinVOs are used to store entries from MySQL views, which are not
>>>editable. I think removing setters from the *JoinVOs may help avoid
>>>some potential confusion as setters seem to imply that the fields are
>>>editable, which they really aren't.
>>> 
>>> I started looking around and it looks like most setters in *JoinVOs
>>>aren't actually used since the creation of *VOs is handled by java
>>>reflection. Please let me know if this is not the case or if I'm
>>>misunderstanding the way the MySQL views work.
>>> 
>>> -Chris
>>> -- 
>>> Chris Suich
>>> chris.su...@netapp.com
>>> NetApp Software Engineer
>>> Data Center Platforms ­ Cloud Solutions
>>> Citrix, Cisco & Red Hat
>>> 
>> 
>

[cloudmonkey] username / password support

[Chiradeep Vittal]

Hi folks,

I modified cloudmonkey to work off of username and password. Feedback and 
testing required.
The code is in the branch  username_password_support
http://goo.gl/5xTgo5

Thanks
--
Chiradeep

Re: wiki édit access

[Chiradeep Vittal]

Done

On 10/15/13 8:07 PM, "Srikanteswararao Talluri"
 wrote:

>I need wiki edit access for the below mentioned account.
>Username : talluri
>
>
>Thanks,
>~Talluri

Re: [cloudmonkey] username / password support

[Chiradeep Vittal]

Aha, thanks. Can you 'pip install requests' ?



On 10/15/13 8:38 PM, "Ryan Lei"  wrote:

>I was unable to run cloudmonkey after applying your update.
>My commands were:
>
>$ git checkout username_password_support
>$ git pull
>$ python setup.py build
>$ python setup.py install
>$ cloudmonkey
>
>Then I got this import error:
>Import error in cloudmonkey.requester : No module named requests
>
>Switching back to master branch runs fine, however.
>
>
>--
>-
>Yu-Heng (Ryan) Lei, Associate Researcher
>Chunghwa Telecom Laboratories / Cloud Computing Laboratory
>ryan...@cht.com.tw<https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWY
>pVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto
>%3aryanlei%40cht.com.tw>
>or
>ryanlei750...@gmail.com
>
>
>
>On Wed, Oct 16, 2013 at 11:23 AM, Chiradeep Vittal <
>chiradeep.vit...@citrix.com> wrote:
>
>> Hi folks,
>>
>> I modified cloudmonkey to work off of username and password. Feedback
>>and
>> testing required.
>> The code is in the branch  username_password_support
>> http://goo.gl/5xTgo5
>>
>> Thanks
>> --
>> Chiradeep
>>

Re: [cloudmonkey] username / password support

[Chiradeep Vittal]

Sorry, urllib2 and cookiejar looked just too painful.

On 10/15/13 9:26 PM, "Prasanna Santhanam"  wrote:

>
>I fixed this temporarily by adding the requests as a dependency. But
>may be we could do the login using urllib2 itself to avoid the
>requests dependency.
>
>+1 to username,password login. I need to add that to marvin too.
>
>On Wed, Oct 16, 2013 at 11:38:40AM +0800, Ryan Lei wrote:
>> I was unable to run cloudmonkey after applying your update.
>> My commands were:
>> 
>> $ git checkout username_password_support
>> $ git pull
>> $ python setup.py build
>> $ python setup.py install
>> $ cloudmonkey
>> 
>> Then I got this import error:
>> Import error in cloudmonkey.requester : No module named requests
>> 
>> Switching back to master branch runs fine, however.
>> 
>> 
>> 
>>-
>>--
>> Yu-Heng (Ryan) Lei, Associate Researcher
>> Chunghwa Telecom Laboratories / Cloud Computing Laboratory
>> 
>>ryan...@cht.com.tw<https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SW
>>YpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mail
>>to%3aryanlei%40cht.com.tw>
>> or
>> ryanlei750...@gmail.com
>> 
>> 
>> 
>> On Wed, Oct 16, 2013 at 11:23 AM, Chiradeep Vittal <
>> chiradeep.vit...@citrix.com> wrote:
>> 
>> > Hi folks,
>> >
>> > I modified cloudmonkey to work off of username and password. Feedback
>>and
>> > testing required.
>> > The code is in the branch  username_password_support
>> > http://goo.gl/5xTgo5
>> >
>> > Thanks
>> > --
>> > Chiradeep
>> >
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>

Re: [cloudmonkey] username / password support

[Chiradeep Vittal]

You can leave that blank. That is just the way the generic config manager
works. If you leave out apikey and secret key too it will complain.

On 10/15/13 9:58 PM, "Prasanna Santhanam"  wrote:

>I prefer requests too. May be we can later switch over all of
>cloudmonkey to use requests just like marvin. I tested out the changes
>with a user account and everything works fine. But startup of
>cloudmonkey seems to force one to put in the username, passwd in
>cloudmonkey/config.
>
>On Wed, Oct 16, 2013 at 04:51:23AM +, Chiradeep Vittal wrote:
>> Sorry, urllib2 and cookiejar looked just too painful.
>> 
>> On 10/15/13 9:26 PM, "Prasanna Santhanam"  wrote:
>> 
>> >
>> >I fixed this temporarily by adding the requests as a dependency. But
>> >may be we could do the login using urllib2 itself to avoid the
>> >requests dependency.
>> >
>> >+1 to username,password login. I need to add that to marvin too.
>> >
>> >On Wed, Oct 16, 2013 at 11:38:40AM +0800, Ryan Lei wrote:
>> >> I was unable to run cloudmonkey after applying your update.
>> >> My commands were:
>> >> 
>> >> $ git checkout username_password_support
>> >> $ git pull
>> >> $ python setup.py build
>> >> $ python setup.py install
>> >> $ cloudmonkey
>> >> 
>> >> Then I got this import error:
>> >> Import error in cloudmonkey.requester : No module named requests
>> >> 
>> >> Switching back to master branch runs fine, however.
>> >> 
>> >> 
>> >> 
>> 
>>>>---
>>>>--
>> >>--
>> >> Yu-Heng (Ryan) Lei, Associate Researcher
>> >> Chunghwa Telecom Laboratories / Cloud Computing Laboratory
>> >> 
>> 
>>>>ryan...@cht.com.tw<https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0
>>>>SW
>> 
>>>>YpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=ma
>>>>il
>> >>to%3aryanlei%40cht.com.tw>
>> >> or
>> >> ryanlei750...@gmail.com
>> >> 
>> >> 
>> >> 
>> >> On Wed, Oct 16, 2013 at 11:23 AM, Chiradeep Vittal <
>> >> chiradeep.vit...@citrix.com> wrote:
>> >> 
>> >> > Hi folks,
>> >> >
>> >> > I modified cloudmonkey to work off of username and password.
>>Feedback
>> >>and
>> >> > testing required.
>> >> > The code is in the branch  username_password_support
>> >> > http://goo.gl/5xTgo5
>> >> >
>> >> > Thanks
>> >> > --
>> >> > Chiradeep
>> >> >
>> >
>> >-- 
>> >Prasanna.,
>> >
>> >
>> >Powered by BigRock.com
>> >
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>

RE: [cloudmonkey] username / password support

[Chiradeep Vittal]

Passwords can be changed too. No difference in security, IMO.

Plus the api key option is always there.

In fact I first wrote it as an option ( --populate-api-keys USERNAME:PASSWORD), 
but decided that it didn't buy anything.

The original code didn't pass pep8 (imports not being used etc), that's 
probably a separate patch.


-Original Message-
From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit 
Yadav
Sent: Wednesday, October 16, 2013 10:50 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [cloudmonkey] username / password support

I never intended to have support for password as I thought people will end up 
using and storing plain text username/password, keys (specific for
cloudmonkey) are revokable :)
Maybe we can use usernames/password initially to create keys or maybe let users 
decided what they want. If this could be refactored as a reusable module 
Prasanna can use this for Marvin.

On Wed, Oct 16, 2013 at 10:21 AM, Chiradeep Vittal < 
chiradeep.vit...@citrix.com> wrote:

> Sorry, urllib2 and cookiejar looked just too painful.
>

Totally agree, we should throw away painful things for better ones. With 
requests as dependency in setup.py so no one has to install it manually.
You just do pip install --upgrade stuff and pip would get all the deps from 
setup.py. Thanks Prasanna for adding that, maybe specify a minimum or maximum 
version?

Initially my idea was to use least possible dependency, like have cloudmonkey 
pure python 2.6 program that just uses standard libs but eventually added 
prettytable and pygments. We should have more good stuff, remove painful libs.

Lastly, could the code be pep8'd, tested and released :)

Cheers,
bhaisaab


>
> On 10/15/13 9:26 PM, "Prasanna Santhanam"  wrote:
>
> >
> >I fixed this temporarily by adding the requests as a dependency. But 
> >may be we could do the login using urllib2 itself to avoid the 
> >requests dependency.
> >
> >+1 to username,password login. I need to add that to marvin too.
> >
> >On Wed, Oct 16, 2013 at 11:38:40AM +0800, Ryan Lei wrote:
> >> I was unable to run cloudmonkey after applying your update.
> >> My commands were:
> >>
> >> $ git checkout username_password_support $ git pull $ python 
> >> setup.py build $ python setup.py install $ cloudmonkey
> >>
> >> Then I got this import error:
> >> Import error in cloudmonkey.requester : No module named requests
> >>
> >> Switching back to master branch runs fine, however.
> >>
> >>
> >>
> >>
> >>-
> >>--
> >> Yu-Heng (Ryan) Lei, Associate Researcher  Chunghwa Telecom 
> >>Laboratories / Cloud Computing Laboratory
> >>
> >>ryan...@cht.com.tw<
> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SW
> >>YpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL
> >>=mail
> >>to%3aryanlei%40cht.com.tw>
> >> or
> >> ryanlei750...@gmail.com
> >>
> >>
> >>
> >> On Wed, Oct 16, 2013 at 11:23 AM, Chiradeep Vittal < 
> >> chiradeep.vit...@citrix.com> wrote:
> >>
> >> > Hi folks,
> >> >
> >> > I modified cloudmonkey to work off of username and password. 
> >> > Feedback
> >>and
> >> > testing required.
> >> > The code is in the branch  username_password_support
> >> > http://goo.gl/5xTgo5
> >> >
> >> > Thanks
> >> > --
> >> > Chiradeep
> >> >
> >
> >--
> >Prasanna.,
> >
> >
> >Powered by BigRock.com
> >
>
>

Re: [cloudmonkey] username / password support

[Chiradeep Vittal]

Fixed pep8 and other issues (with flake8).

Does this warrant a new release?

On 10/16/13 11:13 AM, "Chiradeep Vittal" 
wrote:

>Passwords can be changed too. No difference in security, IMO.
>
>Plus the api key option is always there.
>
>In fact I first wrote it as an option ( --populate-api-keys
>USERNAME:PASSWORD), but decided that it didn't buy anything.
>
>The original code didn't pass pep8 (imports not being used etc), that's
>probably a separate patch.
>
>
>-Original Message-
>From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of
>Rohit Yadav
>Sent: Wednesday, October 16, 2013 10:50 AM
>To: dev@cloudstack.apache.org
>Cc: us...@cloudstack.apache.org
>Subject: Re: [cloudmonkey] username / password support
>
>I never intended to have support for password as I thought people will
>end up using and storing plain text username/password, keys (specific for
>cloudmonkey) are revokable :)
>Maybe we can use usernames/password initially to create keys or maybe let
>users decided what they want. If this could be refactored as a reusable
>module Prasanna can use this for Marvin.
>
>On Wed, Oct 16, 2013 at 10:21 AM, Chiradeep Vittal <
>chiradeep.vit...@citrix.com> wrote:
>
>> Sorry, urllib2 and cookiejar looked just too painful.
>>
>
>Totally agree, we should throw away painful things for better ones. With
>requests as dependency in setup.py so no one has to install it manually.
>You just do pip install --upgrade stuff and pip would get all the deps
>from setup.py. Thanks Prasanna for adding that, maybe specify a minimum
>or maximum version?
>
>Initially my idea was to use least possible dependency, like have
>cloudmonkey pure python 2.6 program that just uses standard libs but
>eventually added prettytable and pygments. We should have more good
>stuff, remove painful libs.
>
>Lastly, could the code be pep8'd, tested and released :)
>
>Cheers,
>bhaisaab
>
>
>>
>> On 10/15/13 9:26 PM, "Prasanna Santhanam"  wrote:
>>
>> >
>> >I fixed this temporarily by adding the requests as a dependency. But
>> >may be we could do the login using urllib2 itself to avoid the
>> >requests dependency.
>> >
>> >+1 to username,password login. I need to add that to marvin too.
>> >
>> >On Wed, Oct 16, 2013 at 11:38:40AM +0800, Ryan Lei wrote:
>> >> I was unable to run cloudmonkey after applying your update.
>> >> My commands were:
>> >>
>> >> $ git checkout username_password_support $ git pull $ python
>> >> setup.py build $ python setup.py install $ cloudmonkey
>> >>
>> >> Then I got this import error:
>> >> Import error in cloudmonkey.requester : No module named requests
>> >>
>> >> Switching back to master branch runs fine, however.
>> >>
>> >>
>> >>
>> >>----
>> >>-
>> >>--
>> >> Yu-Heng (Ryan) Lei, Associate Researcher  Chunghwa Telecom
>> >>Laboratories / Cloud Computing Laboratory
>> >>
>> >>ryan...@cht.com.tw<
>> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SW
>> >>YpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL
>> >>=mail
>> >>to%3aryanlei%40cht.com.tw>
>> >> or
>> >> ryanlei750...@gmail.com
>> >>
>> >>
>> >>
>> >> On Wed, Oct 16, 2013 at 11:23 AM, Chiradeep Vittal <
>> >> chiradeep.vit...@citrix.com> wrote:
>> >>
>> >> > Hi folks,
>> >> >
>> >> > I modified cloudmonkey to work off of username and password.
>> >> > Feedback
>> >>and
>> >> > testing required.
>> >> > The code is in the branch  username_password_support
>> >> > http://goo.gl/5xTgo5
>> >> >
>> >> > Thanks
>> >> > --
>> >> > Chiradeep
>> >> >
>> >
>> >--
>> >Prasanna.,
>> >
>> >
>> >Powered by BigRock.com
>> >
>>
>>

Re: S3 API broken in 4.2

[Chiradeep Vittal]

Yeah, it was always a tech preview kind of thing. The basic operations
used to work, but since most of the available client tools
(s3cmd/boto/etc) had special workarounds for odd AWS behaviors (in the
return behavior), they would have a hard time working with the S3
implementation in CloudStack which was based entirely on the WSDL.

On 10/21/13 10:16 PM, "Darren S"  wrote:

>I didn't even know this feature existed until yesterday, so I thought I'd
>try it out, but it seems that the S3 API in CloudStack completely doesn't
>work in 4.2.  Is it supposed to?  Is this an official feature or some
>tech preview type thing?
>
>Darren

Re: [VOTE] Accept the donation of RDP client code into Apache CloudStack

[Chiradeep Vittal]

+1

On 10/21/13 11:11 AM, "Donal Lafferty"  wrote:

>As stated in a previous thread [1], Citrix is proposing the donation of
>source for an RDP client.  After donation, the client would be integrated
>with the console system VM in order to provide access to Hyper-V based
>VMs.
>
>The client's source is in the diff attached to the Review Board
>submission https://reviews.apache.org/r/14701/
>
>[1] http://markmail.org/thread/q6sfqrhosmirm3bg
>
>I would like to call a vote here, so that we have a formal consensus on
>accepting the code into the project.  I suggest that it be accepted into
>a branch, and then we work through any technical concerns / reviews /
>changes prior to a master branch merge.
>
>VOTING will be left open for 72 hours.
>
>This is a technical decision, which means committer and PMC votes are
>binding.
>
>
>DL
>

Re: LXC and SSVM/CPVM on the host

[Chiradeep Vittal]

As far as I understand, in an LXC scenario, the system vms are expected to
run on real hypervisors.
You can always use the QuickCloud way to not use system vms at all.

On 10/21/13 1:45 PM, "Francois Gaudreault" 
wrote:

>Ok I think we have to look at this further. I'll stop hijacking other
>threads.
>
>I am trying to get the SSVM/CPVM to run on a LXC host. The SSVM/CPVM
>starts, get IPs, but then CloudStack kill them for some reason. Yes, I
>use the 4.2 images :
>
>2013-10-21 16:19:21,605 DEBUG [agent.manager.AgentManagerImpl]
>(AgentManager-Handler-9:null) SeqA 73--1: Processing Seq 73--1:  { Cmd ,
>MgmtId: -1, via: 73, Ver: v1, Flags: 111,
>[{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
>2013-10-21 16:19:21,605 INFO  [agent.manager.AgentManagerImpl]
>(AgentManager-Handler-9:null) Host 73 has informed us that it is
>shutting down with reason sig.kill and detail null
>2013-10-21 16:19:21,606 INFO  [agent.manager.AgentManagerImpl]
>(AgentTaskPool-11:null) Host 73 is disconnecting with event
>ShutdownRequested
>2013-10-21 16:19:21,609 DEBUG [agent.manager.AgentManagerImpl]
>(AgentTaskPool-11:null) The next status of agent 73is Disconnected,
>current status is Up
>2013-10-21 16:19:21,609 DEBUG [agent.manager.AgentManagerImpl]
>(AgentTaskPool-11:null) Deregistering link for 73 with state Disconnected
>2013-10-21 16:19:21,609 DEBUG [agent.manager.AgentManagerImpl]
>(AgentTaskPool-11:null) Remove Agent : 73
>2013-10-21 16:19:21,609 DEBUG [agent.manager.ConnectedAgentAttache]
>(AgentTaskPool-11:null) Processing Disconnect.
>
>I transferred the host to KVM, and now the same SSVM/CPVM images are
>running fine for the last 30min ( so I assume it works fine...).
>Something seems to be wrong with the LXC side :S
>
>Anyone wants to invest some time to troubleshoot? I'll open a ticket also.
>
>-- 
>Francois Gaudreault
>Architecte de Solution Cloud | Cloud Solutions Architect
>fgaudrea...@cloudops.com
>514-629-6775
>- - -
>CloudOps
>420 rue Guy
>Montréal QC  H3J 1S6
>www.cloudops.com
>@CloudOps_
>

Re: How does HA work?

[Chiradeep Vittal]

https://cwiki.apache.org/confluence/x/dwn8AQ

On 10/23/13 10:51 AM, "Kelcey Jamison Damage"
 wrote:

>I can tell you it uses 'Storage-Heartbeat" method for HA, unless that's
>changed. That means the heartbeat ring is via the primary storage.
>
>
>- Original Message -
>
>From: "Nux!" 
>To: dev@cloudstack.apache.org
>Cc: us...@cloudstack.apache.org
>Sent: Wednesday, October 23, 2013 10:48:40 AM
>Subject: How does HA work?
>
>Hello, 
>
>Since I'm not a programmer reading the code doesn't make too much sense
>to me. 
>Can anyone explain to me how HA works (for VMs expecially)?
>Who monitors these HA VMs? Can I run multiple monitors, for HA? Any
>recommendations, best practices, gotchas?
>
>Thanks, 
>Lucian 
>
>-- 
>Sent from the Delta quadrant using Borg technology!
>
>Nux! 
>www.nux.ro 
>

Re: [ASF4.2.1] default to 64-bit system VM template

[Chiradeep Vittal]

32-bit vms also "generally" perform better on XenServer (depending on the
workload).
The issue with 32-bit Linux is that it has usually only has 800M for so
for available for the kernel [1].
This limits the number of connections that can be tracked by the conntrack
module to around
800/300 =~ 2.5 million. Of course this leave little space for other kernel
tasks.

If you've got a busy web site behind CloudStack's HAProxy then this may
not be enough.

[1] 
http://unix.stackexchange.com/questions/4929/what-are-high-memory-and-low-m
emory-on-linux

On 10/23/13 10:21 AM, "Marty Sweet"  wrote:

>What would be the main reasoning behind this change? Surely the
>minimalistic specifications that SystemVMs are assigned suit 32-bit better
>in terms of Memory?
>
>"The main disadvantage of 64-bit architectures is that, relative to 32-bit
>architectures, the same data occupies more space in memory (due to longer
>pointers and possibly other types, and alignment padding). This increases
>the memory requirements of a given process and can have implications for
>efficient processor cache utilization."
>
>
>On Wed, Oct 23, 2013 at 1:48 PM, Abhinandan Prateek <
>abhinandan.prat...@citrix.com> wrote:
>
>> On 23/10/13 3:48 pm, "David Nalley"  wrote:
>>
>> >On Wed, Oct 23, 2013 at 1:32 AM, Abhinandan Prateek
>> > wrote:
>> >>
>> >>   We are planning to  make 64-bit system vm templates as default
>> >>offering in 4.2.1.
>> >> This is an initial email to have thoughts from the community on this.
>> >>
>> >> -abhi
>> >
>> >-1
>> >Who is this we?
>> >I agree with Wido We adhere to semver, and accordingly 4.2.1 should be
>> >a bugfix release.
>>
>> We were some of the fellow committers, even I was of the same thinking
>>but
>> thought it will be good to have a general opinion.
>>
>> -abhi
>>
>>

Re: Metadata URL location

[Chiradeep Vittal]

For the VPC virtual router case this would this have to be done on all
guest interfaces? 
Could we alias localhost on the VR to 169.254.169.254?
For shared networks, basic zone and networks where the VR is not the
default gateway, we would have to send another (169.254.0.0/16) route in
the DHCP response to point to the VR.

Additionally in basic zone the anti-spoof filters in dom0 would have to be
adjusted to let 169.254.169.254 addresses

On 10/24/13 8:51 AM, "Darren Shepherd"  wrote:

>So additionally you need to do
>
>ip addr add dev eth0 169.254.169.254/0
>
>On Thu, Oct 24, 2013 at 8:29 AM, Kris G. Lindgren 
>wrote:
>> You would also need to supernet 169.254.169.254 on the virtual router
>> (assigning it as 169.254.169.254 netmask 0.0.0.0 on eth0) that way it
>>will
>> still arp to servers that are calling it that have real ip addresses.
>>
>> Additionally we had some other iptables rules in there that would change
>> the the ip address of the incoming request to metadata based upon the
>>mac
>> address that was hitting it.  This was to prevent spoofing of another
>>vm's
>> IP and getting someone else's metadata (at least in our metadata
>> implementation we keyed off of the VM IP calling into metadata).  This
>> also allowed a user to set whatever ipaddress they wanted, but as long
>>as
>> the mac address was the same and they still had a zeroconfig route on
>>the
>> VM, they still got only their metadata.
>> 
>>
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy, LLC.
>>
>>
>> This email message and any attachment(s) hereto are intended for use
>>only
>> by its intended recipient(s) and may contain confidential information.
>>If
>> you have received this email in error, please immediately notify the
>> sender and permanently delete the original and any copy of this message
>> and its attachments.
>>
>>
>>
>>
>>
>>
>>
>> On 10/24/13 9:12 AM, "Darren Shepherd" 
>>wrote:
>>
>>>My guess, I don't really know, would be because its hard.  The VR uses
>>>link local for the control network so 169.254/16 is bound to the wrong
>>>nic.  To fix this you just need some ip routing magic in linux (credit
>>>goes to Kris Lindgren who showed me how to do this).  Add the below to
>>>a file, substitute eth0 for the guest network nic, run "ip -b "
>>>The below effectively creates a routing table dedicated to the IP
>>>169.254.169.254 that sets it default route to go out the guest network
>>>nic.
>>>
>>>rule add from 169.254.169.254 table 70
>>>rule add to 169.254.169.254 dev eth0 table 70
>>>route flush table 70
>>>route add default dev eth0 src 169.254.169.254 table 70
>>>route flush cache
>>>
>>>Darren
>>>
>>>On Thu, Oct 24, 2013 at 6:10 AM, Shanker Balan
>>> wrote:
 Hi Guys,

 CloudStack metadata services are on the default gateway while on EC2,
 its at 169.254.169.254. Am curious to know why CloudStack does not
 use a link local address for meta data services.

 A search of the Wiki
(https://cwiki.apache.org/confluence/dosearchsite.action?where=CLOUDSTA
CK
&tooltip=Type+ALL%3A+in+your+query+to+search+all+of+Confluence&spaceSea
rc
h=true&queryString=metadata) didn¹t seem to list any doc related to the
design of this service.

 TIA.

 --
 @shankerbalan

 M: +91 98860 60539 | O: +91 (80) 67935867
 shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue
 ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade
Centre, Bangalore - 560 055

 CloudStack Bootcamp Training on 27/28 November, Bangalore
 http://www.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 is a registered trademark.
>>

Re: LXC and SSVM/CPVM on the host

[Chiradeep Vittal]

So here's what should work
Create zone
Add a KVM cluster -> add a KVM host -> wait for systemvms to start
Add a LXC cluster -> add a LXC host

On 10/24/13 9:55 AM, "Francois Gaudreault" 
wrote:

>If it's designed to do that, then something is wrong with how CS deals
>with it.
>
>When I was trying to get the KVM images to work, they were starting,
>getting IPs, but then something was killing the VM. I though for
>sometime that libvirt was the issue, so I tried Ubuntu 13.10, 12.04 and
>CentOS with the same results. I then switched the hypervisor type in CS
>from LXC to KVM (rebuilt the zone), keep the same settings on my host,
>and the System VMs are running fine since then.
>
>Anyone have time to help me troubleshoot? I mean, this is not a blocker,
>but I can't get standalone LXC cluster to work...
>
>Francois
>
>On 10/24/2013, 11:53 AM, Phong Nguyen wrote:
>> > So we need a KVM cluster to run the VMs? (Added the author of the
>> feature)
>>
>> As it was originally discussed and implemented, the decision was to
>> use KVM as the system VM for LXC clusters instead of creating an LXC
>> system VM. A zone with only LXC clusters will deploy a KVM system VM
>> on a host running an LXC agent. Behind the scenes, this is possible
>> because both KVM and LXC agents use libvirt for provisioning (and that
>> the setup of an LXC agent is almost identical to KVM and perfectly
>> capable of running KVM VMs).
>>
>> -Phong
>>
>>
>> On Thu, Oct 24, 2013 at 8:57 AM, Francois Gaudreault
>> mailto:fgaudrea...@cloudops.com>> wrote:
>>
>> If this is the case, then you should remove the ability to create
>> LXC zones or clarify the documentation about that.
>>
>> According to the wiki page:
>>
>> Each of the different hypervisors currently have their own System
>> VMs. These system VM images are used to run a console proxy,
>> secondary storage, and router VMs.
>>
>> We discussed the possibility of creating System VMs for LXC. There
>> was concern with the complexity and potential issues involving
>> iptables for the router inside an LXC container. As an
>> intermediate solution we are going to use KVM System VMs inside
>> the LXC Cluster.
>>
>> So we need a KVM cluster to run the VMs? (Added the author of the
>> feature)
>>
>> Francois
>>
>> On 10/22/2013, 1:24 AM, Chiradeep Vittal wrote:
>>
>> As far as I understand, in an LXC scenario, the system vms are
>> expected to
>> run on real hypervisors.
>> You can always use the QuickCloud way to not use system vms at
>> all.
>>
>> On 10/21/13 1:45 PM, "Francois Gaudreault"
>> mailto:fgaudrea...@cloudops.com>>
>> wrote:
>>
>> Ok I think we have to look at this further. I'll stop
>> hijacking other
>> threads.
>>
>> I am trying to get the SSVM/CPVM to run on a LXC host. The
>> SSVM/CPVM
>> starts, get IPs, but then CloudStack kill them for some
>> reason. Yes, I
>> use the 4.2 images :
>>
>> 2013-10-21 16:19:21,605 DEBUG
>>[agent.manager.AgentManagerImpl]
>> (AgentManager-Handler-9:null) SeqA 73--1: Processing Seq
>> 73--1:  { Cmd ,
>> MgmtId: -1, via: 73, Ver: v1, Flags: 111,
>> 
>>[{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}]
>> }
>> 2013-10-21 16:19:21,605 INFO
>>[agent.manager.AgentManagerImpl]
>> (AgentManager-Handler-9:null) Host 73 has informed us that
>> it is
>> shutting down with reason sig.kill and detail null
>> 2013-10-21 16:19:21,606 INFO
>>[agent.manager.AgentManagerImpl]
>> (AgentTaskPool-11:null) Host 73 is disconnecting with event
>> ShutdownRequested
>> 2013-10-21 16:19:21,609 DEBUG
>>[agent.manager.AgentManagerImpl]
>> (AgentTaskPool-11:null) The next status of agent 73is
>> Disconnected,
>> current status is Up
>> 2013-10-21 16:19:21,609 DEBUG
>>[agent.manager.AgentManagerImpl]
>> (AgentTaskPool-11:null) Deregistering link for 73 with
>> state Disconnected
>> 2013-10-21 16:19:21,609 DEBUG
>>[

Re: Metadata URL location

[Chiradeep Vittal]

Hmm. Windows may not work then? Needs testing

On 10/24/13 5:04 PM, "Darren Shepherd"  wrote:

>Chiradeep,
>
>Linux distros set 169.254/16 route on the primary interface.  It's just
>there now.  I'm not sure if that's because of ec2 or if it's always been
>that way, but all modern distros will assign it if you have a standard
>base install.
>
>In the VPC case I think we would have to use network namespaces to bind
>the same IP to multiple NICs.  You could bind the IP to loopback, but
>then it won't ARP.  So since linux distros already have the route, they
>won't send to the gateway.
>
>Yes systemvm will need to be allowed to talk over 169.254, so that's
>needs to change.
>
>Again, I said the reason I thought this wasn't done is because it's hard.
> But still doable.  I'd like to see us do this change.  At least in the
>KVM case, it would be real nice to be able to pickup the standard ubuntu
>(or fedora) cloud qcow and have it run in CloudStack.
>
>Darren
>
>> On Oct 24, 2013, at 3:57 PM, Chiradeep Vittal
>> wrote:
>> 
>> For the VPC virtual router case this would this have to be done on all
>> guest interfaces?
>> Could we alias localhost on the VR to 169.254.169.254?
>> For shared networks, basic zone and networks where the VR is not the
>> default gateway, we would have to send another (169.254.0.0/16) route in
>> the DHCP response to point to the VR.
>> 
>> Additionally in basic zone the anti-spoof filters in dom0 would have to
>>be
>> adjusted to let 169.254.169.254 addresses
>> 
>>> On 10/24/13 8:51 AM, "Darren Shepherd" 
>>>wrote:
>>> 
>>> So additionally you need to do
>>> 
>>> ip addr add dev eth0 169.254.169.254/0
>>> 
>>> On Thu, Oct 24, 2013 at 8:29 AM, Kris G. Lindgren
>>>
>>> wrote:
>>>> You would also need to supernet 169.254.169.254 on the virtual router
>>>> (assigning it as 169.254.169.254 netmask 0.0.0.0 on eth0) that way it
>>>> will
>>>> still arp to servers that are calling it that have real ip addresses.
>>>> 
>>>> Additionally we had some other iptables rules in there that would
>>>>change
>>>> the the ip address of the incoming request to metadata based upon the
>>>> mac
>>>> address that was hitting it.  This was to prevent spoofing of another
>>>> vm's
>>>> IP and getting someone else's metadata (at least in our metadata
>>>> implementation we keyed off of the VM IP calling into metadata).  This
>>>> also allowed a user to set whatever ipaddress they wanted, but as long
>>>> as
>>>> the mac address was the same and they still had a zeroconfig route on
>>>> the
>>>> VM, they still got only their metadata.
>>>> 
>>>> 
>>>> Kris Lindgren
>>>> Senior Linux Systems Engineer
>>>> GoDaddy, LLC.
>>>> 
>>>> 
>>>> This email message and any attachment(s) hereto are intended for use
>>>> only
>>>> by its intended recipient(s) and may contain confidential information.
>>>> If
>>>> you have received this email in error, please immediately notify the
>>>> sender and permanently delete the original and any copy of this
>>>>message
>>>> and its attachments.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 10/24/13 9:12 AM, "Darren Shepherd" 
>>>> wrote:
>>>> 
>>>>> My guess, I don't really know, would be because its hard.  The VR
>>>>>uses
>>>>> link local for the control network so 169.254/16 is bound to the
>>>>>wrong
>>>>> nic.  To fix this you just need some ip routing magic in linux
>>>>>(credit
>>>>> goes to Kris Lindgren who showed me how to do this).  Add the below
>>>>>to
>>>>> a file, substitute eth0 for the guest network nic, run "ip -b "
>>>>> The below effectively creates a routing table dedicated to the IP
>>>>> 169.254.169.254 that sets it default route to go out the guest
>>>>>network
>>>>> nic.
>>>>> 
>>>>> rule add from 169.254.169.254 table 70
>>>>> rule add to 169.254.169.254 dev eth0 table 70
>>>>> route flush table 70
>>>

Re: Review Request 14914: Make commands.properties optional for non-ACS code

[Chiradeep Vittal]

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

Ship it!


- Chiradeep Vittal


On Oct. 24, 2013, 10:06 p.m., Darren Shepherd wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14914/
> ---
> 
> (Updated Oct. 24, 2013, 10:06 p.m.)
> 
> 
> Review request for cloudstack and Chris Suich.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently any new API extension to CloudStack must edit
> commands.properties to add the appropriate ACLs.  This generally works
> fine for ACS as we control the contents of that file and distribute
> all the code ourself.  The hang up comes when somebody develops code
> outside of ACS and want to add their code to an existing ACS
> installation.  The Spring work that has been done has made this much
> easier, but you are still required to manually edit
> commands.properties.  This change introduces the following logic.
> 
> First check commands.properties for ACL info.  If ACL info exists, use
> that to authorize the command.  If no ACL information exists (ie
> null), then look at the @APICommand annotation.  The defaults of
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/APICommand.java 4d024c1 
>   
> plugins/acl/static-role-based/src/org/apache/cloudstack/acl/StaticRoleBasedAPIAccessChecker.java
>  affcf91 
> 
> Diff: https://reviews.apache.org/r/14914/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Darren Shepherd
> 
>

Re: [Merge] hyperv branch to master

[Chiradeep Vittal]

+1

On 10/28/13 4:41 AM, "Devdeep Singh"  wrote:

>Hi,
>
>I would like to merge the support for Hyperv to the master branch.
>Development for this has been done by Donal, Rajesh, Anshul and I on
>branch [1]. The feature was proposed for merge earlier [3] but unit tests
>for hyperv agent code were requested [4].
>
>Checklist:
>The development for the feature was earlier done in branch [2] but later
>moved to [1].
>Jira ticket for the feature is here [5].
>The FS can be found at [6] and [7].
>Unit tests for the feature are available at [8]
>
>This link [7] also provides details of third party libraries used by the
>plugin including their licenses. No source for these libraries is used,
>and the binaries are downloaded from their distributors at build time. No
>proprietary tools are required for the build.  For instance, C# compiled
>with Mono has been tested. Mono setup details can be found here [9].
>
>[1] 
>https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.git;a
>=shortlog;h=refs/heads/hyperv
>[2] https://github.com/lafferty/cloudstack/tree/hyperv_plugin
>[3] 
>http://markmail.org/message/cm7kdwh6l2ea772e?q=list:org%2Eapache%2Eincubat
>or%2Ecloudstack-%2A+Minimal+Hyperv+plugin
>[4] 
>http://markmail.org/message/vxknappvyovhmeyp?q=list:org%2Eapache%2Eincubat
>or%2Ecloudstack-%2A+Minimal+Hyperv+plugin&page=3
>[5] https://issues.apache.org/jira/browse/CLOUDSTACK-999
>[6] 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hyper-V+2012+%283.0
>%29+Support
>[7] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Progress
>[8] 
>https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.git;a
>=blob;f=plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Te
>sts/HypervResourceController1Test.cs;h=ec91e9ff21742bde78873ed7cee49f2423e
>425b9;hb=refs/heads/hyperv
>[9] 
>http://dlafferty.blogspot.co.uk/2013/08/building-your-microsoft-solution-w
>ith.html
>
>Regards,
>Devdeep
>
>

Re: [Merge] hyperv branch to master

[Chiradeep Vittal]

That could be a decision to put off for later.
The release process deals with single repos for now.
The signing will come up during the build right? How do other OSS C#
projects deal with it?
Perhaps they release binaries in addition to source?

On 10/29/13 9:35 AM, "David Nalley"  wrote:

>On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh 
>wrote:
>> Hi,
>>
>> I would like to merge the support for Hyperv to the master branch.
>>Development for this has been done by Donal, Rajesh, Anshul and I on
>>branch [1]. The feature was proposed for merge earlier [3] but unit
>>tests for hyperv agent code were requested [4].
>>
>
>I know this has been discussed several times, but what was the
>decision about making the agent code live in its own repo?
>It's C#, might need to be signed to actually run easily on Windows, etc.
>
>--David

Re: [ANNOUNCE] OCCI Interface

[Chiradeep Vittal]

Awesome

On 11/5/13 5:06 AM, "sebgoa"  wrote:

>Hi,
>
>I am pleased to announce an OGF OCCI interface to CloudStack.
>
>Isaac Chiang contributed back to our ruby client and forked rOCCI-server
>to make this happen. Many thanks to him.
>
>I wrote about it here:
>http://buildacloud.org/blog/296-occi-interface-to-cloudstack.html
>
>OCCI is one of the two cloud standards (with CIMI from DMTF).
>It is very important for CloudStack has it finally brings an official
>industry standard API to our software.
>
>If you want to help with CIMI, ping me.
>
>Cheers,
>
>-Sebastien

[PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

Network Functions Virtualisation (NFV) is an effort to utilize server
virtualization in conjunction with industry standard servers, network
hardware switches and storage hardware to achieve significant time and
costs reductions in the Telecommunication industry. ETSI [1] has a group
(NFV ISG [2]) that is trying to develop guidelines and frameworks around
NFV (note: not standards). They have published a White Paper [3] which
makes very interesting reading.


Among other things, the group identifies

"The NFVI (Network Functions Virtualisation Infrastructure), which
provides the virtual
resources required to support the execution of the Virtualised Network
Functions. It includes
Commercial-Off-The-Shelf (COTS) hardware, accelerator components where
necessary, and
a software layer which virtualises and abstracts the underlying hardware."

This software layer is assumed to be a form of IAAS software. Currently
the group members use OpenStack as an example, but it should be our (the
CloudStack community) goal to popularize and encourage the adoption of
CloudStack as well.

The white paper [3] also goes on to say:
"
We are interested to 
ensure that the Open Source community actively
engages in NFV to help create
virtualised network capabilitiesŠ









...we intend to actively collaborate with existing reference
open-source initiatives in the areas relevant to NFV, as well as to
encourage and support new ones
aligned with the NFV goals, especially when addressing new issues
identified by the NFV community."

One way to improve visibility and collaborate actively with this community
is to have a liaison with the ISG.
The liaison can contribute to the activities of the various working groups
(e.g., Management and Orchestration MANO WG) and convey the activities
and requirements of the NFV ISG back to the CloudStack community.

If the community is OK with the Liaison idea, then we could solicit
volunteers on this list to act as the Liaison(s)

Comments?





[1] http://en.wikipedia.org/wiki/ETSI
[2] http://www.etsi.org/technologies-clusters/technologies/nfv
[3] http://portal.etsi.org/NFV/NFV_White_Paper2.pdf

Re: [PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

While I appreciate the confidence, there are weekly calls to attend.
The particularly interesting one (MANO WG) happens on Wednesdays at 6am
PST. 
I've tried but there's very little chance that I can attend these
meetings. 
Anybody in a more agreeable timezone?

On 11/6/13 3:34 PM, "John Kinsella"  wrote:

>+1
>
>On Nov 5, 2013, at 11:58 AM, Sebastien Goasguen  wrote:
>
>> I volunteer you.
>> 
>> We need to do this.
>> 
>> -Sebastien
>> 
>> On 5 Nov 2013, at 20:28, Chiradeep Vittal 
>>wrote:
>> 
>>> Network Functions Virtualisation (NFV) is an effort to utilize server
>>> virtualization in conjunction with industry standard servers, network
>>> hardware switches and storage hardware to achieve significant time and
>>> costs reductions in the Telecommunication industry. ETSI [1] has a
>>>group
>>> (NFV ISG [2]) that is trying to develop guidelines and frameworks
>>>around
>>> NFV (note: not standards). They have published a White Paper [3] which
>>> makes very interesting reading.
>>> 
>>> 
>>> Among other things, the group identifies
>>> 
>>> "The NFVI (Network Functions Virtualisation Infrastructure), which
>>> provides the virtual
>>> resources required to support the execution of the Virtualised Network
>>> Functions. It includes
>>> Commercial-Off-The-Shelf (COTS) hardware, accelerator components where
>>> necessary, and
>>> a software layer which virtualises and abstracts the underlying
>>>hardware."
>>> 
>>> This software layer is assumed to be a form of IAAS software. Currently
>>> the group members use OpenStack as an example, but it should be our
>>>(the
>>> CloudStack community) goal to popularize and encourage the adoption of
>>> CloudStack as well.
>>> 
>>> The white paper [3] also goes on to say:
>>> "
>>>   We are interested to ensure that the Open
>>>Source community actively
>>> engages in NFV to help create
>>> virtualised network capabilitiesŠ
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ...we intend to actively collaborate with existing reference
>>> open-source initiatives in the areas relevant to NFV, as well as to
>>> encourage and support new ones
>>> aligned with the NFV goals, especially when addressing new issues
>>> identified by the NFV community."
>>> 
>>> One way to improve visibility and collaborate actively with this
>>>community
>>> is to have a liaison with the ISG.
>>> The liaison can contribute to the activities of the various working
>>>groups
>>> (e.g., Management and Orchestration MANO WG) and convey the activities
>>> and requirements of the NFV ISG back to the CloudStack community.
>>> 
>>> If the community is OK with the Liaison idea, then we could solicit
>>> volunteers on this list to act as the Liaison(s)
>>> 
>>> Comments?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> [1] http://en.wikipedia.org/wiki/ETSI
>>> [2] http://www.etsi.org/technologies-clusters/technologies/nfv
>>> [3] http://portal.etsi.org/NFV/NFV_White_Paper2.pdf
>

Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

[Chiradeep Vittal]

It may be an admin burden, but it has to be optional. There are other ways
to achieve global sync (e.g., LDAP/AD/Oauth).
A lot of service providers who run cloudstack have their own user database
/ portal. In their implementations the CloudStack database is not the
master source of user records, but a slave.

On 11/5/13 12:41 PM, "Chip Childers"  wrote:

>Alex,
>
>I've moved your page to the "Designs not committed to a release"
>parent (instead of the 4.3 designs page), to align with both the Jira
>record *and* the fact that feature freeze is about to happen for 4.3.
>
>As for the proposal itself, I have a couple of suggestions:
>
>1) I'd like to see the implementation be part of the ACS runtime.
>Having a separate python app for this sync feature seems like an admin
>burden.
>
>2) As far as the design document itself, I think that we need to see
>more details on the proposed approach to sync, failure condition
>handling, etc...
>
>-chip
>
>
>On Mon, Nov 4, 2013 at 3:16 PM, Alex Ough  wrote:
>> All,
>>
>> Among the 2 approaches, I uploaded the implemented codes of the first
>> approach, master-slave architecture, here.
>> https://github.com/alexoughsg/albatross
>>
>> And here is the design doc in the wiki.
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-Use
>>r+Sync+Up+Among+Multiple+Regions
>>
>> Please review them and let me know what you think if you're interested!
>> Thanks
>> Alex Ough
>>
>>
>>
>> On Thu, Oct 31, 2013 at 6:51 PM, Alex Ough 
>>wrote:
>>
>>> Great! Thanks a lot, Daan.
>>>
>>>
>>> On Thu, Oct 31, 2013 at 4:58 PM, Daan Hoogland
>>>wrote:
>>>
 you are added to jira, Alex

 On Thu, Oct 31, 2013 at 8:31 PM, Alex Ough 
wrote:
 > Thanks Chip, and can you also give a permission in Jira so that I
can
 > assign myself in its jira?
 >
 > Alex Ough
 >
 >
 > On Thu, Oct 31, 2013 at 2:00 PM, Chip Childers
>>> >wrote:
 >
 >> Permission added.
 >>
 >> On Wed, Oct 30, 2013 at 12:19:23PM -0500, Alex Ough wrote:
 >> > And I'd like to write the design document in the wiki page, but I
 don't
 >> > seem to have a permission to create pages.
 >> > So can anyone give me the permission?
 >> >
 >> > My account in the wiki is alex.o...@sungard.com
 >> >
 >> > Thanks in advance.
 >> > Alex Ough
 >> >
 >> >
 >> > On Tue, Oct 29, 2013 at 3:38 PM, Alex Ough

 >> wrote:
 >> >
 >> > > I created a jira for this feature.
 >> > >
 >> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4992
 >> > >
 >> > > But it doesn't allow for me to assign it to myself, so any
 permission
 >> do I
 >> > > need for this?
 >> > > If so, can anyone give me this permission?
 >> > >
 >> > > If there is anything missing, let me know.
 >> > > Thanks
 >> > > Alex Ough
 >> > >
 >> > >
 >> > > On Fri, Oct 18, 2013 at 9:30 AM, Kishan Kavala <
 >> kishan.kav...@citrix.com>wrote:
 >> > >
 >> > >> > -Original Message-
 >> > >> > From: Alex Ough [mailto:alex.o...@sungard.com]
 >> > >> > Sent: Thursday, 17 October 2013 11:25 PM
 >> > >> > To: dev@cloudstack.apache.org; u...@cloudstack.apache.org
 >> > >> > Subject: Fwd: [DISCUSS] Domain/Account/User Sync Up Among
 Multiple
 >> > >> > Regions
 >> > >> >
 >> > >> > All,
 >> > >> >
 >> > >> > Currently, under the environment of cloudstack with multiple
 >> regions,
 >> > >> each
 >> > >> > region has its own management server running with a separate
 >> database.
 >> > >> So if
 >> > >> > we want to support multiple regions and provide one point of
 entry
 >> for a
 >> > >> > customer, we need to duplicate domain/account/user
information
 of
 >> that
 >> > >> > customer to all of the databases of regions the customer
 accesses,
 >> > >> which will
 >> > >> > cause data discrepancies when users update those data
 independently
 >> in
 >> > >> each
 >> > >> > management server.
 >> > >> >
 >> > >> > So I'd like to provide a way to sync up the data using the
 messaging
 >> > >> system
 >> > >> > introduced in 4.1.0. Using the events from each management
 server,
 >> > >> updates
 >> > >> > from each region can be propagated to the rest regions and
they
 can
 >> be
 >> > >> > executed accordingly.
 >> > >> >
 >> > >> > I hope you guys have a chance to think about this and give
some
 >> > >> feedbacks if
 >> > >> > interested.
 >> > >> > Thanks in advance.
 >> > >> > Alex Ough
 >> > >>
 >> > >> [KK] Alex, it was discussed sometime back. Related thread [1].
 Sync up
 >> > >> using messaging system is the right way to go.
 >> > >>
 >> > >>
 >> > >> [1]
 >> > >>
 >>
 
http://www.mail-archive.com/cloudstack-dev@incubator.apache.org/msg2019
>

Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

[Chiradeep Vittal]

I'd also like to highlight that it isn't a trivial problem.
Let's say there's 3 regions: this means there are 3 copies of the user
database that are geographically separated by network links that fail
quite often (orders of magnitude more than intra-DC networks).

Here we run into the consequences of the CAP theorem [1].
We can either have a CP or AP system: either approach makes some tradeoffs:
1. If we run a AP system, then the challenge is to resolve conflicting
updates
2. If we run a CP system, then the challenge is to detect partitions
reliably and disallow updates during partitions.

[1] http://en.wikipedia.org/wiki/CAP_theorem

On 11/7/13 11:58 AM, "Chip Childers"  wrote:

>On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
> wrote:
>> It may be an admin burden, but it has to be optional. There are other
>>ways
>> to achieve global sync (e.g., LDAP/AD/Oauth).
>> A lot of service providers who run cloudstack have their own user
>>database
>> / portal. In their implementations the CloudStack database is not the
>> master source of user records, but a slave.
>
>+1 to it being optional.

Re: [PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

OK, here's the draft of the Liaison request (template borrowed from
OpenDaylight)

--


To:
ETSI Industry Study Group (ISG) on Network Functions Virtualization
Prodip Sen, Chairman NFV ISG prodip@verizon.com
Andrew Malis, NFV Liaison Officer 

I am a member of the Apache CloudStack Project Management Committee (PMC)
and have been asked to serve as liaison from the Apache CloudStack
community to the ETSI Industry Standard Group on Network Functions
Virtualization.

Apache CloudStack is open source software designed to deploy and manage
large networks of virtual machines, as a highly available, highly scalable
Infrastructure as a Service (IaaS) cloud computing platform.  The platform
has pioneered the use of VNF to provide network services to IAAS tenants.
We are excited to see that NFV is going to realize its potential and look
forward to collaborating to realize this promise expeditiously.

The community would like to suggest these areas of collaboration:

1)  ETSI NFV ISG Documents: It would be very helpful to receive pointers
to the various documents being produced by the ETSI NFV ISG, even before
their formal publication, so that your needs can be incorporated into the
Apache CloudStack development effort.

2)  Sharing ideas and experience: We have many shared goals and a large
community of experienced cloud implementors. We have several opportunities
where someone from ETSI NFV ISG could present to the Apache CloudStack
community, including meetups and online fora , and our CloudStack
Collaboration Summit. We would also be quite pleased to present on Apache
CloudStack to ETSI NFV ISG in any forum you find appropriate. If
appropriate we can participate in working groups such as the MANO WG.

3)  Open Source:  We would love to get members of the  ETSI NFV ISG
participate in our community, especially in design ideas, code
contributions and the like. We hope that we can assist in producing
reference implementations and help iterate faster on crucial issues such
as interoperability.

Of course we welcome other ideas for collaboration with the NFV ISG.


---
-



On 11/11/13 1:02 AM, "Sebastien Goasguen"  wrote:

>How about Chiradeep makes the contact and proposal for CloudStack to
>join/be represented ?
>
>Then we can decide who is the representative. Daan could do it and Nguyen
>could be the substitute ?
>
>
>On Nov 9, 2013, at 8:38 AM, Daan Hoogland  wrote:
>
>> I don't mind being involved if needed.
>> 
>> On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers 
>>wrote:
>>> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
>>>> 2013/11/7 Chiradeep Vittal 
>>>> 
>>>>> While I appreciate the confidence, there are weekly calls to attend.
>>>>> The particularly interesting one (MANO WG) happens on Wednesdays at
>>>>>6am
>>>>> PST.
>>>>> I've tried but there's very little chance that I can attend these
>>>>> meetings.
>>>>> Anybody in a more agreeable timezone?
>>>>> 
>>>> 
>>>> Not sure if I have permitted to join, I'm in agreeable timezone (9pm
>>>>at
>>>> local time). It's great and I'm willing to join to liaison team.
>>> 
>>> I'd say you are...  you're a committer on the project.  Perhaps you and
>>> Chiradeep can discuss how to get involved?
>

Re: [PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

I'll do it since I actually know some of the folks

On 11/12/13 8:43 AM, "Daan Hoogland"  wrote:

>Ok,
>
>when nothing there is nothing else to add I will send out this
>tonight. Unless you want to make the contact yourself, Chiradeep.
>
>I'll put you and Nguyen in cc
>
>Daan
>
>On Tue, Nov 12, 2013 at 5:20 PM, Nguyen Anh Tu  wrote:
>> 2013/11/12 Chip Childers 
>>
>>> Tuna - we can find a way to get you engaged as well!
>>
>>
>> No prob, Chip. I'm glad for any contribution I can do...
>>
>> --
>>
>> N.g.U.y.e.N.A.n.H.t.U

Re: [PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

VNF = virtualized network function (e.g., LB virtual appliance)
NFV = network functions virtualization (the whole kit and caboodle)

On 11/12/13 6:53 AM, "sebgoa"  wrote:

>
>On Nov 12, 2013, at 7:21 AM, Chiradeep Vittal
> wrote:
>
>> OK, here's the draft of the Liaison request (template borrowed from
>> OpenDaylight)
>> 
>> --
>> 
>> 
>> To:
>> ETSI Industry Study Group (ISG) on Network Functions Virtualization
>> Prodip Sen, Chairman NFV ISG prodip@verizon.com
>> Andrew Malis, NFV Liaison Officer 
>> 
>> I am a member of the Apache CloudStack Project Management Committee
>>(PMC)
>> and have been asked to serve as liaison from the Apache CloudStack
>> community to the ETSI Industry Standard Group on Network Functions
>> Virtualization.
>> 
>> Apache CloudStack is open source software designed to deploy and manage
>> large networks of virtual machines, as a highly available, highly
>>scalable
>> Infrastructure as a Service (IaaS) cloud computing platform.  The
>>platform
>> has pioneered the use of VNF to provide network services to IAAS
>>tenants.
>
>NFV ? not VNF ?
>
>> We are excited to see that NFV is going to realize its potential and
>>look
>> forward to collaborating to realize this promise expeditiously.
>> 
>> The community would like to suggest these areas of collaboration:
>> 
>> 1)  ETSI NFV ISG Documents: It would be very helpful to receive pointers
>> to the various documents being produced by the ETSI NFV ISG, even before
>> their formal publication, so that your needs can be incorporated into
>>the
>> Apache CloudStack development effort.
>> 
>> 2)  Sharing ideas and experience: We have many shared goals and a large
>> community of experienced cloud implementors. We have several
>>opportunities
>> where someone from ETSI NFV ISG could present to the Apache CloudStack
>> community, including meetups and online fora , and our CloudStack
>> Collaboration Summit. We would also be quite pleased to present on
>>Apache
>> CloudStack to ETSI NFV ISG in any forum you find appropriate. If
>> appropriate we can participate in working groups such as the MANO WG.
>> 
>> 3)  Open Source:  We would love to get members of the  ETSI NFV ISG
>> participate in our community, especially in design ideas, code
>> contributions and the like. We hope that we can assist in producing
>> reference implementations and help iterate faster on crucial issues such
>> as interoperability.
>> 
>> Of course we welcome other ideas for collaboration with the NFV ISG.
>> 
>> 
>> 
>>-
>>--
>> -
>> 
>> 
>> 
>> On 11/11/13 1:02 AM, "Sebastien Goasguen"  wrote:
>> 
>>> How about Chiradeep makes the contact and proposal for CloudStack to
>>> join/be represented ?
>>> 
>>> Then we can decide who is the representative. Daan could do it and
>>>Nguyen
>>> could be the substitute ?
>>> 
>>> 
>>> On Nov 9, 2013, at 8:38 AM, Daan Hoogland 
>>>wrote:
>>> 
>>>> I don't mind being involved if needed.
>>>> 
>>>> On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers
>>>>
>>>> wrote:
>>>>> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
>>>>>> 2013/11/7 Chiradeep Vittal 
>>>>>> 
>>>>>>> While I appreciate the confidence, there are weekly calls to
>>>>>>>attend.
>>>>>>> The particularly interesting one (MANO WG) happens on Wednesdays at
>>>>>>> 6am
>>>>>>> PST.
>>>>>>> I've tried but there's very little chance that I can attend these
>>>>>>> meetings.
>>>>>>> Anybody in a more agreeable timezone?
>>>>>>> 
>>>>>> 
>>>>>> Not sure if I have permitted to join, I'm in agreeable timezone (9pm
>>>>>> at
>>>>>> local time). It's great and I'm willing to join to liaison team.
>>>>> 
>>>>> I'd say you are...  you're a committer on the project.  Perhaps you
>>>>>and
>>>>> Chiradeep can discuss how to get involved?
>>> 
>> 
>

Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

[Chiradeep Vittal]

Missed this one. In a single region, the CloudStack DB is the master for
most operations. If the infra is not in the state the DB says it should
be, generally the approach is to whack it and make it conform. For some
exceptions (live migration/related use cases are exceptions) the DB is the
slave -- the point is that the inconsistency that inevitably arise in an
AP system need a conflict resolution system. In a single region, the
default is to assume that the MySQL DB is correct and handle other cases
carefully.

In a multi-region case, there is no master: disable an account in one
region, and it may not propagate to the other regions for many hours/days.
You could add a user in one region and then add the same user in a
different region and conflict before the sync happens.
 
This is of course not a problem unique to CloudStack -- people pay mucho
dinero for Global AD/LDAP sync. I don't think this is a problem for
CloudStack core to solve: I support the event-based mechanism for those
who want this facility.

Distributed systems are hard and research continues to try and make
building these systems easier, but there are very few solutions for global
state synchronization (Google Spanner comes to mind)

--
Chiradeep


On 11/8/13 4:53 PM, "Chip Childers"  wrote:

>We are already (generally) AP for most infra changes really. I'd use that
>model. Eventual consistency is better in this scenario.
>
>> On Nov 8, 2013, at 6:49 PM, Chiradeep Vittal
>> wrote:
>> 
>> I'd also like to highlight that it isn't a trivial problem.
>> Let's say there's 3 regions: this means there are 3 copies of the user
>> database that are geographically separated by network links that fail
>> quite often (orders of magnitude more than intra-DC networks).
>> 
>> Here we run into the consequences of the CAP theorem [1].
>> We can either have a CP or AP system: either approach makes some
>>tradeoffs:
>> 1. If we run a AP system, then the challenge is to resolve conflicting
>> updates
>> 2. If we run a CP system, then the challenge is to detect partitions
>> reliably and disallow updates during partitions.
>> 
>> [1] http://en.wikipedia.org/wiki/CAP_theorem
>> 
>>> On 11/7/13 11:58 AM, "Chip Childers"  wrote:
>>> 
>>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
>>>  wrote:
>>>> It may be an admin burden, but it has to be optional. There are other
>>>> ways
>>>> to achieve global sync (e.g., LDAP/AD/Oauth).
>>>> A lot of service providers who run cloudstack have their own user
>>>> database
>>>> / portal. In their implementations the CloudStack database is not the
>>>> master source of user records, but a slave.
>>> 
>>> +1 to it being optional.
>> 

Re: [PROPOSAL] Liaison with ETSI NFV ISG

[Chiradeep Vittal]

There's also NFVI - Network Functions Virtualization Infrastructure

On 11/12/13 11:26 AM, "Sebastien Goasguen"  wrote:

>Well, i just learned something and someone sure loves confusion through
>acronyms
>
>-Sebastien
>
>On 12 Nov 2013, at 19:28, Chiradeep Vittal 
>wrote:
>
>> VNF = virtualized network function (e.g., LB virtual appliance)
>> NFV = network functions virtualization (the whole kit and caboodle)
>> 
>> On 11/12/13 6:53 AM, "sebgoa"  wrote:
>> 
>>> 
>>> On Nov 12, 2013, at 7:21 AM, Chiradeep Vittal
>>>  wrote:
>>> 
>>>> OK, here's the draft of the Liaison request (template borrowed from
>>>> OpenDaylight)
>>>> 
>>>> --
>>>> 
>>>> 
>>>> To:
>>>> ETSI Industry Study Group (ISG) on Network Functions Virtualization
>>>> Prodip Sen, Chairman NFV ISG prodip@verizon.com
>>>> Andrew Malis, NFV Liaison Officer 
>>>> 
>>>> I am a member of the Apache CloudStack Project Management Committee
>>>> (PMC)
>>>> and have been asked to serve as liaison from the Apache CloudStack
>>>> community to the ETSI Industry Standard Group on Network Functions
>>>> Virtualization.
>>>> 
>>>> Apache CloudStack is open source software designed to deploy and
>>>>manage
>>>> large networks of virtual machines, as a highly available, highly
>>>> scalable
>>>> Infrastructure as a Service (IaaS) cloud computing platform.  The
>>>> platform
>>>> has pioneered the use of VNF to provide network services to IAAS
>>>> tenants.
>>> 
>>> NFV ? not VNF ?
>>> 
>>>> We are excited to see that NFV is going to realize its potential and
>>>> look
>>>> forward to collaborating to realize this promise expeditiously.
>>>> 
>>>> The community would like to suggest these areas of collaboration:
>>>> 
>>>> 1)  ETSI NFV ISG Documents: It would be very helpful to receive
>>>>pointers
>>>> to the various documents being produced by the ETSI NFV ISG, even
>>>>before
>>>> their formal publication, so that your needs can be incorporated into
>>>> the
>>>> Apache CloudStack development effort.
>>>> 
>>>> 2)  Sharing ideas and experience: We have many shared goals and a
>>>>large
>>>> community of experienced cloud implementors. We have several
>>>> opportunities
>>>> where someone from ETSI NFV ISG could present to the Apache CloudStack
>>>> community, including meetups and online fora , and our CloudStack
>>>> Collaboration Summit. We would also be quite pleased to present on
>>>> Apache
>>>> CloudStack to ETSI NFV ISG in any forum you find appropriate. If
>>>> appropriate we can participate in working groups such as the MANO WG.
>>>> 
>>>> 3)  Open Source:  We would love to get members of the  ETSI NFV ISG
>>>> participate in our community, especially in design ideas, code
>>>> contributions and the like. We hope that we can assist in producing
>>>> reference implementations and help iterate faster on crucial issues
>>>>such
>>>> as interoperability.
>>>> 
>>>> Of course we welcome other ideas for collaboration with the NFV ISG.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>---
>>>>--
>>>> --
>>>> -
>>>> 
>>>> 
>>>> 
>>>> On 11/11/13 1:02 AM, "Sebastien Goasguen"  wrote:
>>>> 
>>>>> How about Chiradeep makes the contact and proposal for CloudStack to
>>>>> join/be represented ?
>>>>> 
>>>>> Then we can decide who is the representative. Daan could do it and
>>>>> Nguyen
>>>>> could be the substitute ?
>>>>> 
>>>>> 
>>>>> On Nov 9, 2013, at 8:38 AM, Daan Hoogland 
>>>>> wrote:
>>>>> 
>>>>>> I don't mind being involved if needed.
>>>>>> 
>>>>>> On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers
>>>>>> 
>>>>>> wrote:
>>>>>>> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
>>>>>>>> 2013/11/7 Chiradeep Vittal 
>>>>>>>> 
>>>>>>>>> While I appreciate the confidence, there are weekly calls to
>>>>>>>>> attend.
>>>>>>>>> The particularly interesting one (MANO WG) happens on Wednesdays
>>>>>>>>>at
>>>>>>>>> 6am
>>>>>>>>> PST.
>>>>>>>>> I've tried but there's very little chance that I can attend these
>>>>>>>>> meetings.
>>>>>>>>> Anybody in a more agreeable timezone?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Not sure if I have permitted to join, I'm in agreeable timezone
>>>>>>>>(9pm
>>>>>>>> at
>>>>>>>> local time). It's great and I'm willing to join to liaison team.
>>>>>>> 
>>>>>>> I'd say you are...  you're a committer on the project.  Perhaps you
>>>>>>> and
>>>>>>> Chiradeep can discuss how to get involved?
>>>>> 
>>>> 
>>> 
>> 

Re: the plea to openstack

[Chiradeep Vittal]

In the same vein (things to watch out for)
http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-vid
eos/presentation/state-of-the-stack


On 11/6/13 8:34 AM, "Marcus Sorensen"  wrote:

>http://stochasticresonance.wordpress.com/2013/11/04/openstack-a-plea/
>
>I thought this was an interesting read. There might be some things
>CloudStack could learn or issues it could avoid by keeping some of his
>points in mind.

Re: [VOTE] Release Apache CloudStack 4.2.1

[Chiradeep Vittal]

Is it possible that devs who missed the cutoff for 4.2 simply put it into
4.2.1? That is the feature was 90% done / tested, but missed.

On 11/14/13 4:58 PM, "David Nalley"  wrote:

>Marcus:
>
>Is this is a -1?
>
>I don't have any legal concerns, and the release builds and tests for
>me (though I haven't tried VPC).  I am somewhat concerned about what
>appears to be drifting away from adhering to semver. (features appear
>to have made it into the 4.2.1 release that weren't in 4.2.0) and I am
>also concerned about sys vm update fatigue, especially given the
>problems we had in 4.2.0 around sysvm updates.
>
>--David
>
>On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen 
>wrote:
>> Yeah, I understand that 4.2.0 had a lot of post-release work needed.
>>
>> We are unable to create VPNs.  This is reported second hand from one
>> of my admins. He seems to think that it was caused by the following,
>> which added a for loop inside a for loop. The error is:
>> 
>>'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExcepti
>>on:
>> Duplicate entry '146-Lb' for key 'vpc_id'
>>
>> We did the following to fix it, something should be added to the sql
>>upgrade.
>> mysql -D cloud -t -e 'alter table vpc_service_map drop key vpc_id, add
>> unique key vpc_id (vpc_id,service,provider)'
>>
>>
>> commit 9050cfad3da673370d6ad1ed7570e31314069996
>>
>> CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map table
>> with the services/providers supported by VPC
>>
>>
>>  @Override
>>  @DB
>> -public void persistVpcServiceProviders(long vpcId, Map> String> serviceProviderMap) {
>> +public void persistVpcServiceProviders(long vpcId, Map> List> serviceProviderMap) {
>>  Transaction txn = Transaction.currentTxn();
>>  txn.start();
>>  for (String service : serviceProviderMap.keySet()) {
>> -VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
>> Network.Service.getService(service),
>> Network.Provider.getProvider(serviceProviderMap.get(service)));
>> -_vpcSvcMap.persist(serviceMap);
>> +for (String provider : serviceProviderMap.get(service)) {
>> +VpcServiceMapVO serviceMap = new
>> VpcServiceMapVO(vpcId, Network.Service.getService(service),
>> Network.Provider.getProvider(provider));
>> +_vpcSvcMap.persist(serviceMap);
>> +}
>>  }
>>  txn.commit();
>>  }
>>
>>
>> On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
>> wrote:
>>> +1 binding (I had not been clear on this in this thread it seems)
>>>
>>> On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek
>>>  wrote:
 Marcus,

   Just summarising your concerns so that they can be followed upon:
 1. Due to a VR script change a restart of VR is required. This should
be
 noted down in upgrade instructions in RN. (Radhika to note)
 2. For a maintenance release we should limit the scope to only
blockers. I
 guess what is done is done probably for better as the main release
had so
 many new features that a whole lot fixes were expected in the
maintenance
 release. But again for further maintenance releases scope should be
 restricted to important fixes.

 Any other thing that has been missed ?

 -abhi


 On 14/11/13 12:06 am, "Marcus Sorensen"  wrote:

>I'm unable to deploy virtual machines after upgrading an existing
>4.2.0 to this release.
>
>It looks like the file savepassword.sh was added at the end of October
>as a virtual router script. This would likely mean that people
>upgrading to 4.2.1 will need to upgrade/redeploy their routers. I can
>verify that deploy works if I reboot the router.
>
>Looking over the current state of 4.2, I'm actually pretty surprised
>at how much has changed. I'm seeing lots of whitespace fixes, changes
>to interfaces, etc. My impression was that we'd only commit fixes for
>blocker bugs once a release has gone production, only touching it if
>we had to. This went pretty well with 4.1, I thought, but everything
>was going through the RM that round.
>
>2013-11-13 11:25:24,917 DEBUG
>[resource.virtualnetwork.VirtualRoutingResource]
>(agentRequest-Handler-2:null) Executing:
>/usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh
>savepassword.sh 169.254.1.163 -v 10.2.4.116 -p fnirq_cnffjbeq
>
>2013-11-13 11:25:25,000 DEBUG
>[resource.virtualnetwork.VirtualRoutingResource]
>(agentRequest-Handler-2:null) Exit value is 127
>
>2013-11-13 11:25:25,001 DEBUG
>[resource.virtualnetwork.VirtualRoutingResource]
>(agentRequest-Handler-2:null) bash: /opt/cloud/bin/savepassword.sh: No
>such file or directory
>
>2013-11-13 11:25:25,002 DEBUG [cloud.agent.Agent]
>(agentRequest-Handler-2:null) Seq 21-289734823:  { Ans: , MgmtId:
>90520732090445, via: 21, Ver: v1, Flags: 110,
>[{"com.cloud.agent

Re: CloudStack.next

[Chiradeep Vittal]

+1 to IAM.

An Autoscale service independent of Netscaler.
I'd like to see the built-in GRE controller fully fleshed out as a
distributed/cross-AZ virtual network provider. Make it the out-of-the-box
virtual network provider instead of VLAN.
Easier service vm insertion into virtual networks.
Better fidelity with AWS VPC APIs




On 11/12/13 6:09 PM, "Simon Murphy"  wrote:

>As a CloudStack user, here are the ares that I feel need attention:
>
>- improved IAM and implementation of a full RBAC security model. This is
>hurting us right now.
>- improved VM import functionality (ie bulk import of VM's and import of
>running VM's from existing vSphere clusters)
>- improved backup functionality and integration with 3rd party tools
>- HA for VPC routers
>
>Cheers,
>Simon Murphy
>Solutions Architect
>  
>ViFX | Cloud Infrastructure
>Level 7, 57 Fort Street, Auckland, New Zealand 1010
>PO Box 106700, Auckland, New Zealand 1143
>M +64 21 285 4519 | S simon_a_murphy
>www.vifx.co.nz  follow us on twitter
>
>Auckland | Wellington | Christchurch
>   
>
> 
>experience. expertise. execution.
> 
>This email and any files transmitted with it are confidential, without
>prejudice and may contain information that is subject to legal privilege.
>It is intended solely for the use of the individual/s to whom it is
>addressed in accordance with the provisions of the Privacy Act (1993). The
>content contained in this email does not, necessarily, reflect the
>official policy position of ViFX nor does ViFX have any responsibility for
>any alterations to the contents of this email that may occur following
>transmission. If you are not the addressee it may be unlawful for you to
>read, copy, distribute, disclose or otherwise use the information
>contained within this email. If you are not the intended recipient, please
>notify the sender prior to deleting this email message from your system.
>Please note ViFX reserves the right to monitor, from time to time, the
>communications sent to and from its email network.
>
>
>
>
>
>
>On 13/11/13 1:18 PM, "David Nalley"  wrote:
>
>>On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson 
>>wrote:
>>> Hi All,
>>>
>>> As we ramp towards freeze on 4.3 and start talking about 4.4, I thought
>>>it would be fun to queue up a discussion here on the list before Collab
>>>next week.
>>>
>>> What do you envision in the next MAJOR release of CloudStack?  Call it
>>>5.0 or whatever you like, but what would you like to see there?  What
>>>would you change?  What would you enhance?  Are there big bets we should
>>>be placing as a community?
>>>
>>> Feel free to post any thoughts here and I'll look forward to talking to
>>>many of you in person at Collab next week.  You are coming to Collab,
>>>right?
>>>
>>
>>
>>Hi Steve,
>>
>>I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>>coming in at least the next 12-18 months. Breaking API compatibility
>>is a BIG DEAL IMO and should be done very deliberately and with a lot
>>of consideration, and a plan around how we help folks adapt.
>>
>>Think about the tons of integrations that we have now: Chef, Puppet,
>>Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
>>disrupts our users who stand a good chance of using one of those
>>integrations or consume CloudStack via one of those tools.
>>
>>--David
>

Re: Trunk interface to VM

[Chiradeep Vittal]

You want to pass the vlan tags into a VM that is actually a XenServer?

On 11/14/13 3:02 PM, "Francois Gaudreault" 
wrote:

>Is there a way to assign a trunked interface to a VM running in CS? Like
>assign the entire guest interface. We have a use case where we need to run
>XenServer hosts within a cloudstack managed infra.
>
>Thanks!
>
>Francois

Re: SDN compat matrix

[Chiradeep Vittal]

Also BigSwitch VNS 4.2

--
Chiradeep

> On Nov 17, 2013, at 2:40 AM, "Hugo Trippaers"  wrote:
> 
> Hey guys,
> 
> I’m building the compatibility matrix for our SDN plugins to use in my 
> presentation for CCCEU13. I think i got everything in there, but would like 
> to check it against your combined knowledge:
> 
> GRE isolation
>supports L2 isolation
>XenServer supported since pre ACS
>KVM supported since pre ACS
>(not taking son extensions branch into account yet)
> VXLAN
>supports L2 isolation
>KVM supported since master (4.3)
> Nicira NVP
>supports L2 isolation
>supports L3 NAT function since 4.1
>supports VPC networks
>XenServer supported since 4.0
>KVM supported since 4.1
>VMware supported since 4.2
> Midokura
>supports L2 isolation
>supports L3 NAT, DHCP, Firewall
>supports VPC networks
>KVM supported since 4.2
> Stratosphere
>supports L2 isolation
>KVM supported since 4.2
> Contrail
>supports L2 isolation
>supports L3 NAT, DHCP
>Xenserver supported since master
>KVM supported since master
> 
> 
> Anything i forgot here?
> 
> Cheers,
> 
> Hugo

Re: Trunk interface to VM

[Chiradeep Vittal]

You can't pass the tags in. Perhaps you can use SDN (GRE tunnels) for the
inner CloudStack?

On 11/15/13 10:01 PM, "Francois Gaudreault" 
wrote:

>Yes. We want to be able spin XS within CloudStack. We also need those XS
>to
>consume VLAN tags to do advanced networking (kind of CS inside CS). Lets
>say we do have devs with ambitious needs :)
>
>Francois
>On 2013-11-15 9:46 PM, "Chiradeep Vittal" 
>wrote:
>
>> You want to pass the vlan tags into a VM that is actually a XenServer?
>>
>> On 11/14/13 3:02 PM, "Francois Gaudreault" 
>> wrote:
>>
>> >Is there a way to assign a trunked interface to a VM running in CS?
>>Like
>> >assign the entire guest interface. We have a use case where we need to
>>run
>> >XenServer hosts within a cloudstack managed infra.
>> >
>> >Thanks!
>> >
>> >Francois
>>
>>

Re: CloudStack.next

[Chiradeep Vittal]

Realhostip.com is not required. See:
http://support.citrix.com/article/CTX133468


But I agree that realhostip should not be made the default (default should
be http).

On 11/16/13 2:30 AM, "Nux!"  wrote:

>On 12.11.2013 23:41, Steve Wilson wrote:
>> Hi All,
>> 
>> As we ramp towards freeze on 4.3 and start talking about 4.4, I
>> thought it would be fun to queue up a discussion here on the list
>> before Collab next week.
>> 
>> What do you envision in the next MAJOR release of CloudStack?  Call
>> it 5.0 or whatever you like, but what would you like to see there?
>> What would you change?  What would you enhance?  Are there big bets we
>> should be placing as a community?
>> 
>> Feel free to post any thoughts here and I'll look forward to talking
>> to many of you in person at Collab next week.  You are coming to
>> Collab, right?
>
>My wishlist, based on not very intensive use so far:
>- better support for KVM (VM snapshots, SPICE support etc)
>- get rid of realhostip.com
>- dynamic size for the ROOT disk (so openstack templates can be used
>with minimal modifications)
>- good support for SDN (make VXLAN default etc)
>
>Lucian
>
>-- 
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro

Re: [DISCUSS] Specific information for hypervisor

[Chiradeep Vittal]

Thanks Nicolas for opening the discussion. Since it is in the offering, I guess 
the user won't be able to see it (which is a good thing).
Is it a generic key/value set you want to send down? Can you take us through 
the flow of how the PCI passthrough would work? I would imagine the Allocator 
would need to be modified as well to know about this?

From: "nfoata@orange.com" 
mailto:nfoata@orange.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, November 12, 2013 12:42 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: 
"cloudstack-...@incubator.cloudstack.org"
 
mailto:cloudstack-...@incubator.cloudstack.org>>
Subject: [DISCUSS] Specific information for hypervisor

Hi all,

I write this e-mail to start (or restart) a discussion on the following topic :
How to send specific information to an hypervisor when we would like to be 
generic from
the CloudStack Management Server (or from the WS API) ?

e.g : Could be able to choose pci for Xen, etc.
https://issues.apache.org/jira/i#browse/CLOUDSTACK-3702

The goal is to find the best way to have this kind of feature in a next release 
if possible and almost
to keep, preserve the spirit of Cloudstack.

Best regards,

NB : Maybe, it’s interesting to see this discussion before
[DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/%3ccagqtxvyvzplcycge1vmwuxfvt5px0xdxwxmb5bwv5edcewu...@mail.gmail.com%3e
[cid:image001.gif@01CDFFC9.76D78E80]

Nicolas Foata
Ingénieur
O/OF/DSIF/DFY/SDFY/RnB
Norsys pour Orange
Sophia Antipolis
nfoata@orange.com
[cid:image002.gif@01CDFFC9.76D78E80]


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: Windows support for KVM

[Chiradeep Vittal]

I don't really understand the issue.
What is the difference between
8 

and

1 
 

 


Why does Windows see only 4 cores in the first case? Is it because the 8
cores are split across physical sockets?


On 11/18/13 6:55 AM, "Arnaud Gaillard" 
wrote:

>Hello,
>
>A few days ago I created a new Jira ticket for the support of topology in
>network offering for KVM. This is needed in order to support Windows VM in
>KVM (currently the limitation are such that it is not really possible to
>deploy real Windows VM with this configuration).
>
>The JIRA is 
>CLOUDSTACK-5071
>and
>is refering to a bug opened before:
>CLOUDSTACK-904
>.
>
>As I have received no comment on it, I would like to know if the support
>of
>topology in service offering was considered as a priority, and if the
>impact on the GUI was studied?
>
>Cheers!

Re: [LXC]How to start System VM

[Chiradeep Vittal]

See this discussion:
http://goo.gl/Kj0rNr

On 11/18/13 2:03 PM, "Frank Zhang"  wrote:

>I have successfully added a LXC host in ACS4.2, however, the system vm
>didn't come up. Is there any specific instruction to make SSVM up?
>Thanks 

Re: About testing of OVS Tunnel Manager, Fail on create new instance

[Chiradeep Vittal]

You have to specify this range in the wizard

On 5/16/13 8:06 PM, "Garnet Tang"  wrote:

>Hi Chiradeep,
>
>Thanks for your suggestion.
>
>When I configures "sdn.ovs.controller" to "true", I do not specify the
>"vnet" (vlan) range of guest network in the create advanced zone wizard.
>
>And, the field "vnet" is null in database table "physical_network".
>
>How to specify this parameters?
>
>--
>From: "Chiradeep Vittal" 
>Sent: Friday, May 17, 2013 1:18 AM
>To: 
>Cc: 
>Subject: Re: About testing of OVS Tunnel Manager, Fail on create new
>instance
>
>> Did you specify the guest network "vlan" range in the create zone
>>wizard?
>> The exception is complaining that there are no virtual network ids
>> available.
>> Vnet ids are populated in the op_dc_vnet_alloc table when the
>> updatePhysicalNetwork api is called.
>>
>> On 5/16/13 8:07 AM, "錦為"  wrote:
>>
>>>Hi all,
>>>According to the design document of OVS Tunnel Manager
>>>(https://cwiki.apache.org/CLOUDSTACK/ovs-tunnel-manager-for-cloudstack.h
>>>tm
>>>l),
>>>I have configured “sdn.ovs.controller” to true, and create one advanced
>>>zone with one physical network whose isolation method is “GRE”.
>>>Advacned zone is created successfully, but when creating new instance,
>>>it
>>>will pop follow error,
>>>“Unable to create a deployment for VM”, and following logs within
>>>“vmops.log”.
>>>If have any suggestion or references for this problem ?
>>>I used CloudStack 4.0.1/4.1 + XenServer 6.0.2. If need another
>>>configuration on XenServer or CloudStack ?
>>>Thanks a lot.
>>>
>>>
>>>--
>>>--
>>>
>>>2013-05-16 14:54:12,508 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) Lock is acquired for network id 204 as a part
>>>of
>>>network implement
>>>2013-05-16 14:54:12,508 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) Asking OvsGuestNetworkGuru to implement
>>>Ntwk[204|Guest|8]
>>>2013-05-16 14:54:12,512 DEBUG [db.Transaction.Transaction]
>>>(Job-Executor-11:job-11) Rolling back the transaction: Time = 1 Name =
>>>-AsyncJobManagerImpl$1.run:401-Executors$RunnableAdapter.call:471-Future
>>>Ta
>>>sk$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:114
>>>6-
>>>ThreadPoolExecutor$Worker.run:615-Thread.run:679; called by
>>>-Transaction.rollback:890-Transaction.removeUpTo:833-Transaction.close:6
>>>57
>>>-TransactionContextBuilder.interceptComplete:56-ComponentInstantiationPo
>>>st
>>>Processor$InterceptorDispatcher.intercept:131-DataCenterDaoImpl.allocate
>>>Vn
>>>et:192-ComponentInstantiationPostProcessor$InterceptorDispatcher.interce
>>>pt
>>>:125-OvsGuestNetworkGuru.allocateVnet:97-GuestNetworkGuru.implement:326-
>>>Ov
>>>sGuestNetworkGuru.implement:114-NetworkManagerImpl.implementNetwork:1425
>>>-C
>>>omponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125
>>>2013-05-16 14:54:12,512 INFO  [utils.exception.CSExceptionErrorCode]
>>>(Job-Executor-11:job-11) Could not find exception:
>>>com.cloud.exception.InsufficientVirtualNetworkCapcityException in error
>>>code list for exceptions
>>>2013-05-16 14:54:12,512 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) Cleaning up because we're unable to implement
>>>the network Ntwk[204|Guest|8]
>>>2013-05-16 14:54:12,519 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) Releasing 0 port forwarding rules for network
>>>id=204 as a part of shutdownNetworkRules
>>>2013-05-16 14:54:12,519 DEBUG [network.firewall.FirewallManagerImpl]
>>>(Job-Executor-11:job-11) There are no rules to forward to the network
>>>elements
>>>2013-05-16 14:54:12,520 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) Releasing 0 static nat rules for network id=204
>>>as a part of shutdownNetworkRules
>>>2013-05-16 14:54:12,520 DEBUG [network.firewall.FirewallManagerImpl]
>>>(Job-Executor-11:job-11) There are no rules to forward to the network
>>>elements
>>>2013-05-16 14:54:12,521 DEBUG [cloud.network.NetworkManagerImpl]
>>>(Job-Executor-11:job-11) There are no rules to forward to the netw

Re: stackmate ToDo

[Chiradeep Vittal]

Hi Dharmesh, 
You got the code structure right. Are you available on IRC
(#cloudstack-dev) so we could discuss more? I am in the process of putting
a web interface on stackmate. I am in PDT time zone.

On 5/20/13 6:36 AM, "Chip Childers"  wrote:

>Dharmesh,
>
>Adding Chiradeep to this thread, since Stackmate isn't actually part of
>Apache CloudStack (but Chiradeep is the author).
>
>-chip
>
>On Fri, May 17, 2013 at 11:27:07PM +0530, Dharmesh Kakadia wrote:
>> Hi,
>> 
>> I would like to contribute to stackmate. I am trying to understand the
>>high
>> level flow from code. Is there any document that I should look first ?
>>My
>> understanding is,
>> 
>> bin/ - interface - does option parsing
>> lib/stakmate/classmap.rb  - gives the ability to use existing AWS tools.
>> lib/stakmate/stack.rb - base. represents a stack
>> lib/stakmate/stack-executer.rb - executes already
>> lib/stakmate/waitcondition_server.rb - didn't understand what it does
>> lib/stakmate/participants/common.rb - wait condition implementation as
>> participants.
>> lib/stakmate/participants/cloudstack.rb - Actual stuff.
>> 
>> I think ToDo list that you mentioned on repo is good place to start for
>> contributions. I would like to know more details on how you are
>>planning to
>> implement those features. say for example, the rollback on error. I
>>assume
>> to rollback on error you will catch exceptions in stack_executer that is
>> raised in cloudstack.rb. Am I on the right track ?
>> 
>> Thanks,
>> Dharmesh

Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?

[Chiradeep Vittal]

+1

On 5/20/13 1:15 PM, "Chip Childers"  wrote:

>All,
>
>As discussed on another thread [1], we identified a bug
>(CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs
>are not configured to sync their time with either the host HV or an NTP
>service.  That bug affects the system VMs for all three primary HVs (KVM,
>Xen and vSphere).  Patches have been committed addressing vSphere and
>KVM.  It appears that a correction for Xen would require the re-build of
>a system VM image and a full round of regression testing that image.
>
>Given that the discussion thread has not resulted in a consensus on this
>issue, I unfortunately believe that the only path forward is to call for
>a formal VOTE.
>
>Please respond with one of the following:
>
>+1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 being
>resolved
>+0: don't care one way or the other
>-1: do *not* proceed with any further 4.1 release candidates until
>CLOUDSTACK-2492 has been fully resolved
>
>-chip
>
>[1] http://markmail.org/message/rw7vciq3r33biasb

Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2

[Chiradeep Vittal]

May I humbly suggest that the configuration (SG + Advanced + VMWare) was
never supported and the end user got themselves into an unfortunate
situation by using an unsupported configuration (even if the software let
them do it).
I have perused both 2.2.13 and 2.2.14 install guides and it is quite clear
that security groups are only supported with Xen and KVM, for basic zone.


On 5/20/13 12:36 PM, "Chip Childers"  wrote:

>On Fri, May 17, 2013 at 03:32:50PM -0400, Sebastien Goasguen wrote:
>> 
>> On May 17, 2013, at 3:01 PM, Animesh Chaturvedi
>> wrote:
>> 
>> > 
>> > 
>> >> -Original Message-
>> >> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> >> Sent: Friday, May 17, 2013 11:47 AM
>> >> To: dev@cloudstack.apache.org
>> >> Cc: 'Chip Childers'; Wei Zhou (w.z...@leaseweb.com)
>> >> Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1
>>vs 4.2
>> >> 
>> >> 
>> >> On May 17, 2013, at 2:25 PM, Animesh Chaturvedi
>> >>  wrote:
>> >> 
>> >>> So I am confused looks like Nicolas was not using this feature as
>>it was not
>> >> supported for Vmware  any way so how is upgrade blocked?
>> >>> 
>> >> 
>> >> Animesh, I talked with nicolas and the way I understand it is that
>>they had to
>> >> enable SG to set their VLANs in advanced zone the way they needed to.
>> >> They actually did not use the SG functionality. Beats me but I don't
>>know
>> >> 2.2.14(13)
>> > [Animesh>] I am not sure why would SG be needed to set their VLANs in
>>advanced zone?
>> 
>> I think only someone with knowledge of 2.2.14 would understand that.
>> 
>> > If Anthony's patch is available in 4.1 wouldn't it fix the issue or
>>is it that upgrade gets stuck in intermediate step during upgrade to 4.0?
>> 
>> I don't know. My understanding is that Anthony's patch won't be usable
>>for vmware hypervisor.
>
>So we are at a bit of an impasse here, and I'm not sure that we have
>figured out what our options might even be.
>
>Here's the situation:
>
>We have people stuck on 2.x right now that were using SG's within
>Advanced Zones.  That feature seems to have been dropped from the code
>from before CloudStack was in the ASF.  We have work in-progress for
>4.2 to make that feature a feature again.  The 4.2 work does *not*
>include VMware environments.
>
>We have some decisions to make:
>
>Decision 1: Do we wait to release 4.1 (and also 4.2) until the work in
>progress is complete for Xen and KVM (and tested)?
>
>Decision 2: Do we wait to release 4.1 (and also 4.2) until *both* the
>Xen/KVM implementation and a VMware implementation exist?
>
>Decision 3: Do we solve the VMware upgrade path by ensuring that the
>right DB bits exist to transition an installation from 2.x to 4.1 in a
>way that drops SG support in advanced zones using Vmware HVs?
>
>Decision 4: Do we keep people in this situation stranded on 2.x?
>
>I'm personally frustrated that we have users stuck on 2.x right now.
>This is happened to us a couple of times since the project came to
>Apache, where the community has found out that something was dropped or
>effectively eaten away by "bit rot".  I am, however, thankful that we are
>able to make decisions about features health as a community going forward.
>
>I'd appreciate if others can bring their ideas / thoughts to this thread
>so that we can move forward.  I'm asking for tactical ideas here...  If
>I'm not clear on the issues as stated so far, correct me please.
>
>If I don't hear anything over the next day or so, I'm going to
>start a VOTE thread to accept the current state of things as is for 4.1
>and move forward with a 4.1 release.  This is not my preference, but
>without specific suggestions to resolve the problem, there isn't much
>else 
>I can see doing get past our current impasse.
>
>-chip

Re: CLOUDSTACK-2554: Yet another blocker?

[Chiradeep Vittal]

Also, why would the 4.2 system vm template block 4.1 ?

On 5/20/13 12:40 PM, "Chip Childers"  wrote:

>On Sun, May 19, 2013 at 06:38:01PM +0530, Prasanna Santhanam wrote:
>> On Fri, May 17, 2013 at 06:28:38PM +, Koushik Das wrote:
>> > The problem is that there is no default ctor in
>> > XcpServerResource.java. Now the default ctor was changed to a
>> > non-default one by this commit. Adding a default ctor should fix the
>> > issue but need to check if there will be any other side effects due
>> > to the version field introduced.
>> > 
>> > commit 63630a412fddc92fdc68dc27e12d2a68dd09f1dd
>> > Author: Edison Su 
>> > Date:   Wed May 8 11:40:37 2013 -0700
>> > 
>> > CLOUDSTACK-1907: Debian Squeeze 6.0 (64-bit) is not experimental
>>any more
>> > 
>> > -Koushik
>> > 
>> 
>> Thanks - I understand the intentions of Edison's checkin here. Our
>>systemVMs
>> have upgraded to squeeze which XCP had only experimental support for.
>>So for
>> the older XCPs in CloudStack(s) systemVMs will remain running as
>>before. But
>> for the newer CloudStack(s) the new template will be usable. But agent
>> reconnects fail because of the empty constructor. So thanks for solving
>>half my
>> problem. How would one enforce this in the inheritance though? Any
>>ideas?
>> 
>> Meanwhile, I've gone ahead and made multiple fixes to get XCP to work,
>>each one
>> going deeper down the rabbithole. So it turned out to be more involved
>>than
>> what appeared on surface. My commits are in the branch
>> CLOUDSTACK-2554, rebased and applied on master now. I ran the full setup
>> and ensured XCP systemVMs came up with the latest Debian template. I'm
>> running a BVT across Xen, XCP and KVM to ensure it's not regressed
>> beyond what it was.
>> 
>> Here are the master commits:
>> 76e19d5f5090880d27b6334da6ade032273288f5 CLOUDSTACK-2554: Incorrect
>>compute of minmemory and cpu
>> fa086d0bb1d662c82cded083d3e9937349ee5a80 CLOUDSTACK-2554: Ensuring that
>>we honor hypervisor xen's memory constraints
>> ac48c38122ee057abfa416c0bf85231debc0cff3 Fixing multiple minor
>>annoyances
>> 66303b5ee52e1172e19b608e8c8b75a2b9e883d0 CLOUDSTACK-2554: CloudStack
>>fails to load XCP 1.6 hypervisors
>> 
>> What was particularly annoying was single line messages to large feature
>> commits (23e54bb0) with little to no comments within code but affecting
>>all
>> hypervisors and many files (~33 files)
>> 
>> Please include enough information in the commit message. At the very
>>least I'd
>> expect the commit message to be as long as the number of files you've
>>changed.
>
>Prasanna,
>
>Just to confirm, the reviewboard submission for the issue that was
>targeting the 4.1 branch was all inclusive of these fixes.  Correct?

Re: About testing of OVS Tunnel Manager, Fail on create new instance

[Chiradeep Vittal]

You can use the updatePhysicalNetwork API with cloud monkey.
Alternatively, set up your zone wizard with GRE isolation BEFORE setting
the global config and THEN set the global config? At least, that works for
me on master.

On 5/19/13 1:40 AM, "錦為"  wrote:

>But, It does not have step to specify the vnet range in the create
>advanced 
>zone wizard.
>
>Is it have some preprocess before specify this range ?
>
>-----原始郵件- 
>From: Chiradeep Vittal
>Sent: Saturday, May 18, 2013 12:45 AM
>To: Garnet Tang ; dev@cloudstack.apache.org
>Subject: Re: About testing of OVS Tunnel Manager, Fail on create new
>instance
>
>You have to specify this range in the wizard
>
>On 5/16/13 8:06 PM, "Garnet Tang"  wrote:
>
>>Hi Chiradeep,
>>
>>Thanks for your suggestion.
>>
>>When I configures "sdn.ovs.controller" to "true", I do not specify the
>>"vnet" (vlan) range of guest network in the create advanced zone wizard.
>>
>>And, the field "vnet" is null in database table "physical_network".
>>
>>How to specify this parameters?
>>
>>--
>>From: "Chiradeep Vittal" 
>>Sent: Friday, May 17, 2013 1:18 AM
>>To: 
>>Cc: 
>>Subject: Re: About testing of OVS Tunnel Manager, Fail on create new
>>instance
>>
>>> Did you specify the guest network "vlan" range in the create zone
>>>wizard?
>>> The exception is complaining that there are no virtual network ids
>>> available.
>>> Vnet ids are populated in the op_dc_vnet_alloc table when the
>>> updatePhysicalNetwork api is called.
>>>
>>> On 5/16/13 8:07 AM, "錦為"  wrote:
>>>
>>>>Hi all,
>>>>According to the design document of OVS Tunnel Manager
>>>>(https://cwiki.apache.org/CLOUDSTACK/ovs-tunnel-manager-for-cloudstack.
>>>>h
>>>>tm
>>>>l),
>>>>I have configured “sdn.ovs.controller” to true, and create one advanced
>>>>zone with one physical network whose isolation method is “GRE”.
>>>>Advacned zone is created successfully, but when creating new instance,
>>>>it
>>>>will pop follow error,
>>>>“Unable to create a deployment for VM”, and following logs within
>>>>“vmops.log”.
>>>>If have any suggestion or references for this problem ?
>>>>I used CloudStack 4.0.1/4.1 + XenServer 6.0.2. If need another
>>>>configuration on XenServer or CloudStack ?
>>>>Thanks a lot.
>>>>
>>>>---
>>>>-
>>>>--
>>>>--
>>>>
>>>>2013-05-16 14:54:12,508 DEBUG [cloud.network.NetworkManagerImpl]
>>>>(Job-Executor-11:job-11) Lock is acquired for network id 204 as a part
>>>>of
>>>>network implement
>>>>2013-05-16 14:54:12,508 DEBUG [cloud.network.NetworkManagerImpl]
>>>>(Job-Executor-11:job-11) Asking OvsGuestNetworkGuru to implement
>>>>Ntwk[204|Guest|8]
>>>>2013-05-16 14:54:12,512 DEBUG [db.Transaction.Transaction]
>>>>(Job-Executor-11:job-11) Rolling back the transaction: Time = 1 Name =
>>>>-AsyncJobManagerImpl$1.run:401-Executors$RunnableAdapter.call:471-Futur
>>>>e
>>>>Ta
>>>>sk$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:11
>>>>4
>>>>6-
>>>>ThreadPoolExecutor$Worker.run:615-Thread.run:679; called by
>>>>-Transaction.rollback:890-Transaction.removeUpTo:833-Transaction.close:
>>>>6
>>>>57
>>>>-TransactionContextBuilder.interceptComplete:56-ComponentInstantiationP
>>>>o
>>>>st
>>>>Processor$InterceptorDispatcher.intercept:131-DataCenterDaoImpl.allocat
>>>>e
>>>>Vn
>>>>et:192-ComponentInstantiationPostProcessor$InterceptorDispatcher.interc
>>>>e
>>>>pt
>>>>:125-OvsGuestNetworkGuru.allocateVnet:97-GuestNetworkGuru.implement:326
>>>>-
>>>>Ov
>>>>sGuestNetworkGuru.implement:114-NetworkManagerImpl.implementNetwork:142
>>>>5
>>>>-C
>>>>omponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125
>>>>2013-05-16 14:54:12,512 INFO  [utils.exception.CSExceptionErrorCode]
>>>>(Job-Executor-11:job-11) Could not find exception:
>>>>com.cloud.exception.InsufficientVirtualNetworkCapcityException in error
>>>>

Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?

[Chiradeep Vittal]

No, they couldn't have set that since this flag is not available on Debian
2.6.32

On 5/20/13 5:26 PM, "John Burwell"  wrote:

>Chip,
>
>Previous releases of CloudStack may have set
>/proc/sys/xen/independent_wallclock in the cloud-early-config script
>which will properly sync clock for paravirtualized VMs.  However, NTP is
>only solution that correct clock drift for both para and full virtualized
>VMs.  Admittedly, I haven't looked in the history to see if this strategy
>was previously employed.
>
>Thanks,
>-John
>
>
>On May 20, 2013, at 8:18 PM, Chip Childers 
>wrote:
>
>> On May 20, 2013, at 7:14 PM, John Burwell  wrote:
>> 
>>> All,
>>> 
>>> While it is tough to do, I must cast a -1 for the following reasons:
>>> 
>>> Given that system VMs write files, this defect makes every file
>>>created/modified timestamp unreliable.
>>> Operational log correlation/debugging is nearly impossible since the
>>>clock is out of sync.
>>> It renders S3-backed Secondary Storage unreliable/useless
>>> 
>>> As Ahmad pointed out, there are likely other instabilities/defects
>>>lurking due to this issue that we haven't discovered.
>>> 
>>> I think we also need to determine whether or not this issue was
>>>introduced in 4.1.  If not, we should consider back porting these fixes.
>> 
>> It can't be this, because the system VM's for 4.1 are the exact same
>> images since 3.x releases.
>> 
>>> 
>>> Thanks,
>>> -John
>>> 
>>> On May 20, 2013, at 5:29 PM, Ahmad Emneina  wrote:
>>> 
>>>> I'm +0 on this, dont want to hold up a release with a neg 1 vote. My
>>>> opinion is that time sync is critical piece for system vm's. Having
>>>>the
>>>> wrong time can lead to system vm's booting and waiting for manual
>>>> intervention via consistency checks (potential blocker bug IMO).
>>>> 
>>>> 
>>>> On Mon, May 20, 2013 at 2:03 PM, Chiradeep Vittal <
>>>> chiradeep.vit...@citrix.com> wrote:
>>>> 
>>>>> +1
>>>>> 
>>>>> On 5/20/13 1:15 PM, "Chip Childers" 
>>>>>wrote:
>>>>> 
>>>>>> All,
>>>>>> 
>>>>>> As discussed on another thread [1], we identified a bug
>>>>>> (CLOUDSTACK-2492) in the current 3.x system VMs, where the System
>>>>>>VMs
>>>>>> are not configured to sync their time with either the host HV or an
>>>>>>NTP
>>>>>> service.  That bug affects the system VMs for all three primary HVs
>>>>>>(KVM,
>>>>>> Xen and vSphere).  Patches have been committed addressing vSphere
>>>>>>and
>>>>>> KVM.  It appears that a correction for Xen would require the
>>>>>>re-build of
>>>>>> a system VM image and a full round of regression testing that image.
>>>>>> 
>>>>>> Given that the discussion thread has not resulted in a consensus on
>>>>>>this
>>>>>> issue, I unfortunately believe that the only path forward is to
>>>>>>call for
>>>>>> a formal VOTE.
>>>>>> 
>>>>>> Please respond with one of the following:
>>>>>> 
>>>>>> +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492
>>>>>>being
>>>>>> resolved
>>>>>> +0: don't care one way or the other
>>>>>> -1: do *not* proceed with any further 4.1 release candidates until
>>>>>> CLOUDSTACK-2492 has been fully resolved
>>>>>> 
>>>>>> -chip
>>>>>> 
>>>>>> [1] http://markmail.org/message/rw7vciq3r33biasb
>>> 
>

Re: [DISCUSS] Should we pause merges into master until 4.1 is out the door?

[Chiradeep Vittal]

I don't see limited interest. It seems that bugs are trickling in every
day and they are being taken up as they come in. Is there any blocker
without any action for more than a few days? The only one I can see
CLOUDSTACK-2463.
That one is baffling to me and several others -- because the configuration
that the bug reporter has was never supported. Even with 4.2, VMWare will
not have security group support. Since it is a non-standard configuration,
it suggests to me that it requires bespoke upgrade support.

On 5/20/13 5:23 PM, "Chip Childers"  wrote:

>On May 20, 2013, at 7:50 PM, Animesh Chaturvedi
> wrote:
>
>>
>>
>>> -Original Message-
>>> From: Chip Childers [mailto:chip.child...@sungard.com]
>>> Sent: Monday, May 20, 2013 1:35 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [DISCUSS] Should we pause merges into master until 4.1 is out
>>>the
>>> door?
>>>
>>> All,
>>>
>>> I can't help but notice that we continue to have features being
>>>developed
>>> and proposed / merged into master while I struggle to get opinions /
>>>help on
>>> 4.1.  I doubt that we (as a community) want to abandon 4.1, but I
>>>can't be
>>> certain.
>> [Animesh>] No we should channelize to get 4.1 blockers resolved besides
>>there are far more committers in community than open bugs so it does not
>>make sense to block everyone on their contribution. Let me ask around
>>who can help out on open blockers for 4.1
>
>The fact that you have to ask around sounds like limited interest from
>others.
>
>>>
>>> Should we abandon an attempt at releasing 4.1, and instead move on to
>>>4.2?
>>> This wouldn't solve any of the blocker bugs holding up 4.1 though...
>>>
>>> Instead, should we hold off on all merges of new features into master
>>>until
>>> 4.1 is complete?  This might allow us to refocus as a community to
>>>complete
>>> the current release goal, but would obviously impact folks that are
>>>working
>>> on new features (although your help in completing 4.1 would be useful).
>>>
>>> -chip
>>

Re: About XAPI task queue

[Chiradeep Vittal]

Are you looking for information on how XAPI does async processing?
http://wiki.xen.org/wiki/VM_Startup

http://wiki.xen.org/wiki/XAPI_Dispatch


On 5/21/13 1:52 AM, "Nguyen Anh Tu"  wrote:

>no one can explain it for me?
>
>
>2013/5/10 Nguyen Anh Tu 
>
>> Hi forks,
>>
>> I'm working on CS + XCP. I have a question:
>>
>> When starting VM, Async job "startvm" is sent to XCP Host via xapi. Then
>> we have to wait until xapi task responses.  This code here:
>>
>> void startVM(Connection conn, Host host, VM vm, String vmName)
>>throws
>> XmlRpcException {
>> Task task = null;
>> try {
>>* task = vm.startOnAsync(conn, host, false, true);*
>> try {
>> //poll every 1 seconds , timeout after 10 minutes
>> *waitForTask(conn, task, 1000, 10 * 60 * 1000);*
>> *checkForSuccess(conn, task);*
>> } catch (Types.HandleInvalid e) {
>> if (vm.getPowerState(conn) ==
>>Types.VmPowerState.RUNNING) {
>> task = null;
>> return;
>> }
>> throw new CloudRuntimeException("Shutdown VM catch
>> HandleInvalid and VM is not in RUNNING state");
>> }
>> } catch (XenAPIException e) {
>> String msg = "Unable to start VM(" + vmName + ") on host(" +
>> _host.uuid +") due to " + e.toString();
>> s_logger.warn(msg, e);
>> throw new CloudRuntimeException(msg);
>> }finally {
>> if( task != null) {
>> try {
>> task.destroy(conn);
>> } catch (Exception e1) {
>> s_logger.debug("unable to destroy task(" +
>> task.toString() + ") on host(" + _host.uuid +") due to " +
>>e1.toString());
>> }
>> }
>> }
>> }
>>
>> Can you explain how xapi task work? How xapi queue work? When its task
>> responses?
>>
>> Thanks,
>>
>> --
>>
>> N.g.U.y.e.N.A.n.H.t.U
>>
>
>
>
>-- 
>
>N.g.U.y.e.N.A.n.H.t.U

Re: About XAPI task queue

[Chiradeep Vittal]

Also
http://docs.vmd.citrix.com/XenServer/4.0.1/sdk/ch04.html#id2538486


On 5/21/13 10:12 AM, "Chiradeep Vittal" 
wrote:

>Are you looking for information on how XAPI does async processing?
>http://wiki.xen.org/wiki/VM_Startup
>
>http://wiki.xen.org/wiki/XAPI_Dispatch
>
>
>On 5/21/13 1:52 AM, "Nguyen Anh Tu"  wrote:
>
>>no one can explain it for me?
>>
>>
>>2013/5/10 Nguyen Anh Tu 
>>
>>> Hi forks,
>>>
>>> I'm working on CS + XCP. I have a question:
>>>
>>> When starting VM, Async job "startvm" is sent to XCP Host via xapi.
>>>Then
>>> we have to wait until xapi task responses.  This code here:
>>>
>>> void startVM(Connection conn, Host host, VM vm, String vmName)
>>>throws
>>> XmlRpcException {
>>> Task task = null;
>>> try {
>>>* task = vm.startOnAsync(conn, host, false, true);*
>>> try {
>>> //poll every 1 seconds , timeout after 10 minutes
>>> *waitForTask(conn, task, 1000, 10 * 60 * 1000);*
>>> *checkForSuccess(conn, task);*
>>> } catch (Types.HandleInvalid e) {
>>> if (vm.getPowerState(conn) ==
>>>Types.VmPowerState.RUNNING) {
>>> task = null;
>>> return;
>>> }
>>> throw new CloudRuntimeException("Shutdown VM catch
>>> HandleInvalid and VM is not in RUNNING state");
>>> }
>>> } catch (XenAPIException e) {
>>> String msg = "Unable to start VM(" + vmName + ") on host("
>>>+
>>> _host.uuid +") due to " + e.toString();
>>> s_logger.warn(msg, e);
>>> throw new CloudRuntimeException(msg);
>>> }finally {
>>> if( task != null) {
>>> try {
>>> task.destroy(conn);
>>> } catch (Exception e1) {
>>> s_logger.debug("unable to destroy task(" +
>>> task.toString() + ") on host(" + _host.uuid +") due to " +
>>>e1.toString());
>>> }
>>> }
>>> }
>>> }
>>>
>>> Can you explain how xapi task work? How xapi queue work? When its task
>>> responses?
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> N.g.U.y.e.N.A.n.H.t.U
>>>
>>
>>
>>
>>-- 
>>
>>N.g.U.y.e.N.A.n.H.t.U
>