Re: [DISCUSS] Don't assign tickets to people when triaging

[Nitin Mehta]

On 09/04/13 11:57 AM, "Prasanna Santhanam"  wrote:

>On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
>> [Animesh>] Folks I wanted to get your opinion on auto-assignment
>> based on the component maintainers list. We can also create shared
>> issues filters based on components. Folks can subscribe to the
>> filters of interest and receive daily email notification.
>
>I have no opinion and am okay whichever way - auto-assign/unassigned.
>But these workflows should be _*clearly*_ mentioned to contributors
>and where they will go looking for them - wiki, website etc.

+1. I am fine either way as well. Perhaps the new folks can communicate
their interest areas as well.


>
>Triaging and assigning issues at the time of release to
>contributors/committers by the Release Manager shouldn't be a problem
>at all as long as it's communicated (as Chip did for the RC bugs)

I think we would need to triage them very close to release especially the
blockers and critical ones, but can have a little more relaxed norm
for other priority issues.


>
>Thanks,
>
>-- 
>Prasanna.,

Review Request: Documentation changes for VMware dvSwitch and Nexus dvSwitch

[Radhika PC]

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

Review request for cloudstack, Pranav Saxena, Sateesh Chodapuneedi, and ilya 
musayev.


Description
---

Documentation on Distributed Switches: nexus and dvSwitch.
Prerequisites part of VMware dvSwitch is still unclear. Please provide 
necessary suggestions.


This addresses bug CLOUDSTACK-772.


Diffs
-

  docs/en-US/Book_Info.xml c125ab8 
  docs/en-US/add-clusters-vsphere.xml 6b2dff2 
  docs/en-US/images/add-cluster.png 383f375ebedd62d9b294a56f777ed4b8c0d92e10 
  docs/en-US/images/dvswitch-config.png PRE-CREATION 
  docs/en-US/images/dvswitchconfig.png PRE-CREATION 
  docs/en-US/vmware-cluster-config-dvswitch.xml PRE-CREATION 
  docs/en-US/vmware-install.xml 467e135 

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


Testing
---

Publican builds, patch applies.


Thanks,

Radhika PC

Re: Review Request: Documentation changes for VMware dvSwitch and Nexus dvSwitch

[Radhika PC]

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

(Updated April 9, 2013, 7:31 a.m.)


Review request for cloudstack, David Nalley, Chip Childers, Jessica Tomechak, 
Pranav Saxena, Sateesh Chodapuneedi, and ilya musayev.


Changes
---

Included Chip and Jessica


Description
---

Documentation on Distributed Switches: nexus and dvSwitch.
Prerequisites part of VMware dvSwitch is still unclear. Please provide 
necessary suggestions.


This addresses bug CLOUDSTACK-772.


Diffs
-

  docs/en-US/Book_Info.xml c125ab8 
  docs/en-US/add-clusters-vsphere.xml 6b2dff2 
  docs/en-US/images/add-cluster.png 383f375ebedd62d9b294a56f777ed4b8c0d92e10 
  docs/en-US/images/dvswitch-config.png PRE-CREATION 
  docs/en-US/images/dvswitchconfig.png PRE-CREATION 
  docs/en-US/vmware-cluster-config-dvswitch.xml PRE-CREATION 
  docs/en-US/vmware-install.xml 467e135 

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


Testing
---

Publican builds, patch applies.


Thanks,

Radhika PC

Re: Cloudstack.org domain

[Prasanna Santhanam]

On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
> On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers  
> wrote:
> > Hi all,
> >
> > One of our graduation checklist items is to get the cloudstack.org
> > domain migrated to ASF infra for registration ownership and probably
> > also for name services (although I'm not sure what the approach is for
> > the latter).
> >
> > Can someone from Citrix with the right authority please work with infra@
> > to get this completed?
> >
> > -chip
> 
> I'll take care of this.
> 
> I'll start the conversation with infra and report back here.
> 
I'm assuming this will takeout the following services:
a) jenkins.cs.o
b) paste.cs.o (replaced by apaste.info)

Any others? 

-- 
Prasanna.,

Review Request: Documentation on Multiple IP per NIC

[Radhika PC]

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

Review request for cloudstack, Jessica Tomechak, Jayapal Reddy, and venkata 
swamy babu  budumuru.


Description
---

Documentation changes for Multiple IP per Nic. This doc contains the following 
info:

- Conceptual info
-How to configure multiple IP
- api changes
- Other service changes


This addresses bug CLOUDSTACK-809.


Diffs
-

  docs/en-US/added-API-commands-4.2.xml PRE-CREATION 
  docs/en-US/multiple-ip-nic.xml PRE-CREATION 
  docs/en-US/networks.xml f877aa5 
  docs/en-US/whats-new.xml 252f87d 

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


Testing
---

Publican builds, patch applies


Thanks,

Radhika PC

RE: How many Private Gateways can be created to a VPC?

[Kishan Kavala]

As mentioned in the spec:
The number is limited by the hypervisor (max number of nics supported).

From: Chandan Purushothama
Sent: Tuesday, 9 April 2013 4:02 AM
To: Kishan Kavala; dev@cloudstack.apache.org
Subject: How many Private Gateways can be created to a VPC?

Hello Kishan,

I referred to the Information present at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+more+than+one+Private+GW+to+a+VPC
 . It doesn't mention any limitations pertaining to how many private gateways 
can be created to a VPC. May I know the limitation for this feature,

Thank you,
Chandan.

RE: Master broken

[Hugo Trippaers]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, April 08, 2013 3:51 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Master broken
> 
> On Mon, Apr 08, 2013 at 07:44:41AM +, Hugo Trippaers wrote:
> >
> >
> > > -Original Message-
> > > From: Chip Childers [mailto:chip.child...@sungard.com]
> > > Sent: Saturday, April 06, 2013 7:16 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Master broken
> > >
> > > On Sat, Apr 06, 2013 at 05:27:11AM +, Prasanna Santhanam wrote:
> > > > Ah - misunderstood. Like Hugo said, a test that fails on presence
> > > > of db
> > > connection should solve this. But I hope ppl will turn mysql on (as
> > > an additional step) to run the bvt. Or better yet, I can look into
> > > those db tests and port them as marvin tests.
> > > >
> > >
> > > Perhaps I'm confused, but having a unit test that fails the build if
> > > MySQL is running on the local machine seems like a really bad idea.
> > >
> > > I think the problem to solve is just that we want to avoid unit
> > > tests that require a DB.  As long as we all know this, and that we
> > > have build jobs that fail on the CI side of things, isn't that enough?
> > >
> > > Am I confused?
> >
> > No :-)
> >
> > The idea is to avoid unit tests that rely on the DB. However this is rather
> difficult to do in some cases. We have a lot of autoloading going on, so in
> some cases a simple fix to components could suddenly result in having a
> component that requires a database connection. If the developer in question
> has an active database, he/she will never notice until the tests hit the 
> master
> branch and Jenkins starts complaining.
> >
> > My idea was to solve this by adding a negative test (break if you have
> database) to give people a reminder (by breaking their build) if they have an
> active database. That could help developers remember to shut it down
> before compiling.
> 
> I'm against this.  It shouldn't be a build requirement to *not* have a DB
> running.  That would be exceptionally complicated for people to deal with all
> the time, just to avoid inappropriate unit tests.

That's a good point :-)  I was also having mixed feelings about this, just 
trying to help people remember that they should build unittests that don't rely 
on the db.

I'm dropping this suggestion :-)

Re: [DIscuss]Storage image store plugin framework refactoring

[Prasanna Santhanam]

On Mon, Apr 08, 2013 at 04:45:23PM -0700, Min Chen wrote:
> Hi All,
> 
> Currently CloudStack does not offer a flexible pluggable framework
> for users to easily integrate and configure any 3rd-party object
> stores for such backup services as registering templates, taking
> snapshots, etc. Along with Edison's recent refactored storage
> subsystem 2.0 that mainly refactored current CloudStack primary
> storage implementation,  we are proposing to develop a storage
> backup object store plugin framework to allow CloudStack to
> systematically manage and configure various types of backup data
> stores from different vendors, like NFS, S3, Swift, etc. With this
> new plugin framework, we would like to achieve following
> functionalities:

> 1. Support different object store providers in a uniform and
> pluggable fashion.
> 2. Enable region wide object backup using S3-like object store.
> 3. Provide pluggable data motion strategies to handle data transfer
> from one data store to another data store.
> 4. Provide a scalable cache storage framework while moving data
> between primary storage and backup storage for certain hypervisor
> needs.
> 5. Support flexible combinations of primary storage, secondary
> storage and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware),
> (ISCSI, Swift, KVM), ?., etc.
> The proposed ImageStore plugin framework architecture is detailed in
> our FS here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Object+Store+Plugin+Framework.
> The JIRA ticket to track this feature is:
> https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
> currently carried out in feature branch  "object_store".
> Please let me know your comments and suggestions.

Perhaps it is too early to ask, will there be a reference
implementation done for any object store solutions as part of the
refactoring?

-- 
Prasanna.,

RE: [Discuss] API name alias

[Kishan Kavala]

Thanks everyone for your inputs. 
We should avoid making changes to the APIs which have only one name. So they'll 
continue to have the annotation:

@APICommand(name="apiName1")

For APIs with multiple names, we should support String[] as suggested by John. 
Preferred and deprecated would be required in case of multiple API names. 
Preferred and deprecated params should also support String[].
@APICommand(name={'Foo', 'Bar', 'FooBar'}, preferred='Foo', 
deprecated={'Bar','FooBar'})


> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Tuesday, 9 April 2013 12:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [Discuss] API name alias
> 
> Rohit, that's like saying we won't fix a leaky faucet today because we're
> moving in a couple of years anyway. It isn't a big deal to add this and it
> clarifies to the end user what is the correct alias to use.
> 
> On 4/8/13 9:52 PM, "Rohit Yadav"  wrote:
> 
> >If we are still on our previously discussed plan (search a wiki shared
> >by
> >Min) on deprecating the whole query based API (Server), it's just
> >unnecessary work on present APIs. I think for now just changing the
> >name attribute type from String to String[] would just work, as John
> suggested.
> >
> >Adding other fields, may not hold much use for now. Except for few of
> >them the rest of 300 apis will have preferred == current apiname and
> >deprecated as blank string.
> >
> >I think we should just deprecated all cmd classes (query based) over a
> >long period say 1 or 2 years, and/or find a way to rewrite/refactor
> >them so as to reuse them with our new rest based API server for future.
> >
> >Cheers.
> >
> >On Tue, Apr 9, 2013 at 3:18 AM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >>
> >>
> >> On 4/8/13 11:18 AM, "Rohit Yadav"  wrote:
> >>
> >> >On Mon, Apr 8, 2013 at 7:10 PM, John Burwell 
> >>wrote:
> >> >
> >> >> Rohit,
> >> >>
> >> >> Why would we need to rewrite any Java code to switch to an array?
> >>As I
> >> >> mentioned, array annotation values are treated as varargs.
> >>Therefore,
> >> >> annotations with single values can be left alone.  Only cases
> >> >> where multiple values are required would require the addition of
> >> >> curly
> >>braces.
> >> >>  For example, for an APICommand with one name, the following would
> >> >>continue  to work:
> >> >>
> >> >
> >> >Hey John, you're right but it's a matter of code styling, I prefer
> >> >writing;
> >> >
> >> >@APICommand(name = {'name1'}) even if it's only one name, this way
> >> >any subsequent api author would know that name is an array and they
> >> >can
> >>have
> >> >aliases which is what Kishan wants.
> >> >
> >> >
> >> >>
> >> >> @APICommand(name="apiName1")
> >> >>
> >> >> While for an APICommand with multiple names, the following form
> >> >>would now  be supported:
> >> >>
> >> >> @APICommand(name={"apiName1", "apiName2", 
> >> >> "apiName3"})@APICommand(name={"apiName1", "apiName2", 
> >> >> "apiName3"})@APICommand(name={"apiName1", "apiName2", "apiName3"})
> >> >>
> >> >> I am not familiar with the Marvin code, so I can not speak to the
> >>impact
> >> >> of this change to it.  However, the only changes to the Java code
> >> >>should be  the API commands with multiple names and the classes
> >> >>that actually consume  the value of this annotation.
> >> >>
> >> >
> >> >Yes, you're right we can skip the code styling I referred then it
> >> >won't consume much coding, we just need to fix these;
> >> >
> >> >- Fix APICommand annotation interface definition to accept name as
> >> >an array
> >> >- Fix method in ApiServer which creates apiname->cmdclass map to
> >> >care
> >>for
> >> >aliases
> >> >- Fix ApiDiscovery to take care of the aliases (create different
> >>response
> >> >objs for the same cmd class)
> >> >- Fix apidocs XmlWriter class to take of the aliases and the api
> >> >html generator to process the same.
> >> >- Fix Marvin's codegenerator.py to take care of the aliases (which
> >>means
> >> >create apiname related modules which would contain cmd and response
> >> >boilterplate fields/class)
> >> >
> >> >Cheers.
> >> >
> >> >
> >> >>
> >> >> Thanks,
> >> >> -John
> >> >>
> >> >> On Apr 8, 2013, at 9:22 AM, Rohit Yadav  wrote:
> >> >>
> >> >> > On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala
> >> >> >> >> >wrote:
> >> >> >
> >> >> >> APICommand annotation in API Cmd object has a name parameter.
> >> >>Currently
> >> >> >> name parameter takes only one value. I plan to enhance this to
> >> >>support
> >> >> >> comma separated values. This will allow multiple API names for
> >> >> >> the
> >> >>same
> >> >> API
> >> >> >> Cmd object.
> >> >> >>
> >> >> >> Current:
> >> >> >> @APICommand(name = "apiName1", ..
> >> >> >>
> >> >> >> Proposed:
> >> >> >> @APICommand(name = "apiName1, apiAlias2, apiAlias3", ..
> >> >> >>
> >> >> >
> >> >> > It's a hack, but doable. While not elegant as John suggests,
> >>parsing
> >> >> comma
> >> >> > separate

Re: Review Request: Improvements for French translation for Admin Web UI (for better display or better meaning). Add some missing translations.

[Sebastien Goasguen]

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

Ship it!


Applied to 4.1 branch: commit   6d2a246807a1024d2775a3560dc0ebe9fc75387c
I will commit to master once we release 4.1

- Sebastien Goasguen


On April 7, 2013, 5:19 p.m., Milamber ASF wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10327/
> ---
> 
> (Updated April 7, 2013, 5:19 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> Improvements for French translation for Admin Web UI (for better display or 
> better meaning). 
> Add some missing translations.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages_fr_FR.properties 267baec 
> 
> Diff: https://reviews.apache.org/r/10327/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Milamber ASF
> 
>

RE: [ACS41] Outstanding work for the release

[Hugo Trippaers]

> 
> RPM Packaging: I believe that Hugo said we are done there, but I'd love a
> confirmation!

Yup, I'm considering the RPM packages done. I'm testing installation of all the 
rpms every four hours using Jenkins. I'm doing limited functional checks on 
management server (startup and zone configuration with xcp hypervisors), agent 
(just start-up) and usage (successful start) so I'm confident that they are 
properly installed. I'm not doing any checks on aws-api (if anybody can give me 
some pointers I'm happy to put some tests in).

As for functionality beyond this, I believe that QA is using these packages for 
their tests as well?



Hugo

Re: [ACS41] Outstanding work for the release

[prasanna]

On 9 April 2013 14:33, Hugo Trippaers  wrote:
>
>>
>> RPM Packaging: I believe that Hugo said we are done there, but I'd love a
>> confirmation!
>
> Yup, I'm considering the RPM packages done. I'm testing installation of all 
> the rpms every four hours using Jenkins. I'm doing limited functional checks 
> on management server (startup and zone configuration with xcp hypervisors), 
> agent (just start-up) and usage (successful start) so I'm confident that they 
> are properly installed. I'm not doing any checks on aws-api (if anybody can 
> give me some pointers I'm happy to put some tests in).
>
> As for functionality beyond this, I believe that QA is using these packages 
> for their tests as well?
>
Yup - RPM gets tested every 4 hours using Xen and KVM as hypervisors
to setup a zone.
http://jenkins.cloudstack.org/view/cloudstack-qa/job/test-packaging/

Re: [PROPOSAL][CLOUDSTACK-768] ACL on private gateway

[Jayapal Reddy Uradi]

Updated the FS  for  new implementation of ACL Deny rules.

 Thanks,
Jayapal

On 01-Apr-2013, at 9:57 AM, Jayapal Reddy Uradi  
wrote:

> Thanks for the commnets.
> I will consider the ACL deny rules and update the FS.
> 
> Thanks,
> Jayapal
> 
>> -Original Message-
>> From: Chiradeep Vittal
>> Sent: Saturday, March 30, 2013 3:49 AM
>> To: dev@cloudstack.apache.org
>> Cc: Jayapal Reddy Uradi; Abhinandan Prateek; Kishan Kavala
>> Subject: Re: [PROPOSAL][CLOUDSTACK-768] ACL on private gateway
>> 
>> This depends on the changes proposed in the ACL deny rules feature. Can
>> you re-word taking into account the new proposed APIs?
>> 
>> On 3/28/13 12:46 AM, "Abhinandan Prateek"
>> 
>> wrote:
>> 
>>> +1, thanks for proposing and working on this feature.
>>> 
>>> On 28/03/13 11:32 AM, "Jayapal Reddy Uradi"
>>>  wrote:
>>> 
 I would like to propose the new feature ACL on private gateway.
 This feature is sub feature of the nTier 2.0 apps.
 
 Currently we do not have way to control the traffic on the private
 gateway.
 Using this feature we can configure the ingress/egress ACL on the
 private gateway.
 
 
 Jira Id:
 https://issues.apache.org/jira/browse/CLOUDSTACK-768
 
 FS:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACLs+on+priv
>> ate
 +GW
 
 Please provide your comments on the above FS.
 
 Thanks,
 Jayapal
 
>>> 
> 

RE: CloudStack Social Media Accounts

[Radhika Puthiyetath]

Hi Joe,

We have two Facebook pages for CloudStack India user group :

https://www.facebook.com/groups/cloudstack/ (Admins - Rajesh Battala/ Radhika)
https://www.facebook.com/groups/cloudstackhyd/ (Admin - Nitin Mehta)

A Podio page:

https://citrix.podio.com/apache-cloudstack-india-user-group/

Regards
-Radhika

-Original Message-
From: Joe Brockmeier [mailto:j...@zonker.net] 
Sent: Tuesday, April 09, 2013 12:49 AM
To: dev@cloudstack.apache.org
Subject: CloudStack Social Media Accounts

Hi all,

We're working on consolidating all the social media accounts, and have set up 
the existing CloudStack accounts for Twitter, Facebook, etc. in HootSuite. 
(e.g., @cloudstack on Twitter, the Facebook page).

If you have created a CloudStack social media handle outside the "main"
one, please do get in touch with the PMC about the additional accounts so we 
can get those consolidated as well. Thanks!

Best,

jzb
--
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [Discuss] API name alias

[Rohit Yadav]

On Tue, Apr 9, 2013 at 12:04 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Rohit, that's like saying we won't fix a leaky faucet today because we're
> moving in a couple of years anyway. It isn't a big deal to add this and it
> clarifies to the end user what is the correct alias to use.
>

Chiradeep, if there are multiple apinames for the same operation (cmd
class) where does the question of "correct alias to use" come?

Excuse my ignorance, I don't understand why we need "preferred" and
"deprecated" fields in that respect. IMO it won't solve any problem but add
confusion and ambiguity, unless there is some use you may explain?

As Kishan shares, he would use the array styled approach which John
suggested and I think it should work, why we want preferred and deprecated
Strings or String[].

Cheers.


> On 4/8/13 9:52 PM, "Rohit Yadav"  wrote:
>
> >If we are still on our previously discussed plan (search a wiki shared by
> >Min) on deprecating the whole query based API (Server), it's just
> >unnecessary work on present APIs. I think for now just changing the name
> >attribute type from String to String[] would just work, as John suggested.
> >
> >Adding other fields, may not hold much use for now. Except for few of them
> >the rest of 300 apis will have preferred == current apiname and deprecated
> >as blank string.
> >
> >I think we should just deprecated all cmd classes (query based) over a
> >long
> >period say 1 or 2 years, and/or find a way to rewrite/refactor them so as
> >to reuse them with our new rest based API server for future.
> >
> >Cheers.
> >
> >On Tue, Apr 9, 2013 at 3:18 AM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >>
> >>
> >> On 4/8/13 11:18 AM, "Rohit Yadav"  wrote:
> >>
> >> >On Mon, Apr 8, 2013 at 7:10 PM, John Burwell 
> >>wrote:
> >> >
> >> >> Rohit,
> >> >>
> >> >> Why would we need to rewrite any Java code to switch to an array?
> >>As I
> >> >> mentioned, array annotation values are treated as varargs.
> >>Therefore,
> >> >> annotations with single values can be left alone.  Only cases where
> >> >> multiple values are required would require the addition of curly
> >>braces.
> >> >>  For example, for an APICommand with one name, the following would
> >> >>continue
> >> >> to work:
> >> >>
> >> >
> >> >Hey John, you're right but it's a matter of code styling, I prefer
> >> >writing;
> >> >
> >> >@APICommand(name = {'name1'}) even if it's only one name, this way any
> >> >subsequent api author would know that name is an array and they can
> >>have
> >> >aliases which is what Kishan wants.
> >> >
> >> >
> >> >>
> >> >> @APICommand(name="apiName1")
> >> >>
> >> >> While for an APICommand with multiple names, the following form would
> >> >>now
> >> >> be supported:
> >> >>
> >> >> @APICommand(name={"apiName1", "apiName2", "apiName3"})
> >> >>
> >> >> I am not familiar with the Marvin code, so I can not speak to the
> >>impact
> >> >> of this change to it.  However, the only changes to the Java code
> >> >>should be
> >> >> the API commands with multiple names and the classes that actually
> >> >>consume
> >> >> the value of this annotation.
> >> >>
> >> >
> >> >Yes, you're right we can skip the code styling I referred then it won't
> >> >consume much coding, we just need to fix these;
> >> >
> >> >- Fix APICommand annotation interface definition to accept name as an
> >> >array
> >> >- Fix method in ApiServer which creates apiname->cmdclass map to care
> >>for
> >> >aliases
> >> >- Fix ApiDiscovery to take care of the aliases (create different
> >>response
> >> >objs for the same cmd class)
> >> >- Fix apidocs XmlWriter class to take of the aliases and the api html
> >> >generator to process the same.
> >> >- Fix Marvin's codegenerator.py to take care of the aliases (which
> >>means
> >> >create apiname related modules which would contain cmd and response
> >> >boilterplate fields/class)
> >> >
> >> >Cheers.
> >> >
> >> >
> >> >>
> >> >> Thanks,
> >> >> -John
> >> >>
> >> >> On Apr 8, 2013, at 9:22 AM, Rohit Yadav  wrote:
> >> >>
> >> >> > On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala
> >> >> >> >> >wrote:
> >> >> >
> >> >> >> APICommand annotation in API Cmd object has a name parameter.
> >> >>Currently
> >> >> >> name parameter takes only one value. I plan to enhance this to
> >> >>support
> >> >> >> comma separated values. This will allow multiple API names for the
> >> >>same
> >> >> API
> >> >> >> Cmd object.
> >> >> >>
> >> >> >> Current:
> >> >> >> @APICommand(name = "apiName1", ..
> >> >> >>
> >> >> >> Proposed:
> >> >> >> @APICommand(name = "apiName1, apiAlias2, apiAlias3", ..
> >> >> >>
> >> >> >
> >> >> > It's a hack, but doable. While not elegant as John suggests,
> >>parsing
> >> >> comma
> >> >> > separated value can lead to some issues.
> >> >> >
> >> >> > Changing the name field to array would require a lot of rewriting
> >>the
> >> >> > present apis annotation name fields, again doable by a small python
> >> >> pr

Re: CloudStack Social Media Accounts

[Nitin Mehta]

Thanks Radhika.
Add to this the linked in group -
http://www.linkedin.com/groups/Cloudstack-User-Group-India-4421326?home=&gi
d=4421326&trk=anet_ug_hm

On 09/04/13 2:45 PM, "Radhika Puthiyetath"
 wrote:

>Hi Joe,
>
>We have two Facebook pages for CloudStack India user group :
>
>https://www.facebook.com/groups/cloudstack/ (Admins - Rajesh Battala/
>Radhika)
>https://www.facebook.com/groups/cloudstackhyd/ (Admin - Nitin Mehta)
>
>A Podio page:
>
>https://citrix.podio.com/apache-cloudstack-india-user-group/
>
>Regards
>-Radhika
>
>-Original Message-
>From: Joe Brockmeier [mailto:j...@zonker.net]
>Sent: Tuesday, April 09, 2013 12:49 AM
>To: dev@cloudstack.apache.org
>Subject: CloudStack Social Media Accounts
>
>Hi all,
>
>We're working on consolidating all the social media accounts, and have
>set up the existing CloudStack accounts for Twitter, Facebook, etc. in
>HootSuite. (e.g., @cloudstack on Twitter, the Facebook page).
>
>If you have created a CloudStack social media handle outside the "main"
>one, please do get in touch with the PMC about the additional accounts so
>we can get those consolidated as well. Thanks!
>
>Best,
>
>jzb
>--
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/

Non-Contiguous Vlan ranges TestPlan

[Kiran Koneti]

Hi,

Non-Contiguous Vlan ranges Test Plan is posted @ 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non-Contiguous+Vlan+ranges.
Please review the same and send me the comments or any additional cases needed 
to be added.

Thanks and Regards,
Kiran Koneti

Review Request: Cloudstack-1534 Disable/Enable-unmanage/manage cluster is setting CPU overcommit and Memory overcommit ratio to 1(default value)

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


Description
---

Cloudstack-1534 Disable/Enable-unmanage/manage cluster is setting CPU 
overcommit  and Memory overcommit ratio to 1(default value)


This addresses bug CLOUDSTACK-1534.


Diffs
-

  api/src/org/apache/cloudstack/api/command/admin/cluster/UpdateClusterCmd.java 
95728dd 
  server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 

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


Testing
---

tested on master.


Thanks,

bharat kumar

FW: git commit: updated refs/heads/4.1 to 9b6ff74

[Pranav Saxena]

Hi Chip,

I had to make a small commit to 4.1 without creating a patch request for it . 
The fix would allow the user to see the instance UUID under the load balancer 
rule when it's "displayname" property is NULL  since prior to this nothing was 
displayed which was blocking the user to know which instance is associated with 
the lb Rule.

Thanks,
Pranav

-Original Message-
From: pran...@apache.org [mailto:pran...@apache.org] 
Sent: Tuesday, April 09, 2013 5:26 PM
To: comm...@cloudstack.apache.org
Subject: git commit: updated refs/heads/4.1 to 9b6ff74

Updated Branches:
  refs/heads/4.1 6d2a24680 -> 9b6ff74e3


CLOUDSTACK-1428:[UI] Instance which are created without display name are not 
visible when added to LB: Using the name property instead in the data flow


Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/9b6ff74e
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/9b6ff74e
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/9b6ff74e

Branch: refs/heads/4.1
Commit: 9b6ff74e3a9535dddfe88121afcfa49cca546cf2
Parents: 6d2a246
Author: Pranav Saxena 
Authored: Tue Apr 9 17:03:41 2013 +0530
Committer: Pranav Saxena 
Committed: Tue Apr 9 17:03:41 2013 +0530

--
 ui/scripts/network.js |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack/blob/9b6ff74e/ui/scripts/network.js
--
diff --git a/ui/scripts/network.js b/ui/scripts/network.js index 
db06c04..1bc4eba 100755
--- a/ui/scripts/network.js
+++ b/ui/scripts/network.js
@@ -3099,7 +3099,7 @@
 });
 
 $.extend(item, {
-  _itemName: 'displayname',
+  _itemName: 'name',
   _itemData: lbInstances,
   _maxLength: {
 name: 7

[ACS41][Patch Request] CLOUDSTACK-1834: Events are not generated for registerUserKeys()

[Murali Reddy]

CLOUDSTACK-1834: Events are not generated for registerUserKeys()

Branch: refs/heads/master
Commit: 9180bd599015ce248e894a0ef476a4604b1533e4
Parents: 47dc989
Author: Murali Reddy mailto:murali.re...@citrix.com>>
Authored: Tue Apr 9 17:45:19 2013 +0530
Committer: Murali Reddy 
mailto:murali.re...@citrix.com>>
Committed: Tue Apr 9 17:45:57 2013 +0530

Re: [ACS41] Outstanding work for the release

[Murali Reddy]

On 08/04/13 7:51 PM, "Chip Childers"  wrote:
>
>CLOUDSTACK-1834 Events are not generated for registerUserKeys(), Enabling
>account and Editing account.  Murali Reddy
>Murali - In your opinion, is this blocking the release?  If not, let's
>change the priority to major.  If so, any ETA on a fix?


Submitted a patch request for 4.1

Re: Network architecture question

[Justin Grudzien]

We have 2 pairs of bonded 10g nics on each box. Wouldn't that require an 
advanced network? Is it possible to do the security groups with small L2 
networks in advanced networking?

Justin 

Sent from my iPhone

On Apr 9, 2013, at 12:38 AM, Chiradeep Vittal  
wrote:

> Have you considered using a basic zone?
> With security groups you can have *lots* (thousands of) with very small L2
> networks.
> 
> On 4/8/13 10:28 PM, "Justin Grudzien"  wrote:
> 
>> My team has been working for three weeks with CloudStack architecture
>> design and we are struggling to put together a network architecture that
>> we feel will scale. From everything I can tell, CloudStack requires a a
>> very large layer 2 network when using shared guest networks. We are
>> looking to deploy almost a thousand physical hosts across 25 cabinets
>> with over 4000 VMs in the next 18 months and having a broadcast domain
>> this large feels problematic.
>> 
>> How have others solved this problem? I don't have a need or a desire for
>> isolation and even if I had 100 guest networks I would still have to tag
>> their VLANs into every host port. There doesn't seem to be a way to tie a
>> network to anything smaller than a zone.
>> 
>> One solution we are looking into is Cisco's 1000v and utilizing VXLANs.
>> This will allow us scale down the broadcast domains. I don't think
>> CloudStack has support in configuring their VXLAN settings? Any comments
>> or suggestions would be appreciated.
>> 
>> Justin
> 

how is failure detection achieved in cloudstack?

[Alejandro Z. Tomsic]

I would like to know how the process of failure detection is achieved in
cloudStack (if any). I would like to know about the implementation details,
i.e. if its done at physical, virtual machine or at application level. Does
cloudStack use any known failure detection mechanisms? e.g. [1][2][3][4] or
any other. Where can I find this information?

Thank you in advance.

Alejandro




[1] M.Bertier,O.Marin,andP.Sens.Implementation and performance evaluation
of an adaptable failure detector. In International Conference on Dependable
Systems and Networks (DSN), pages 354–363, June 2002.

[2] W. Chen, S. Toueg, and M. K. Aguilera. On the quality of service of
failure detectors. IEEE Transactions on Computers, 51(5):561–580, May 2002.

[3] N. Hayashibara, X. De ́fago, R. Yared, and T. Katayama. The φ accrual
failure detector. In IEEE Symposium on Reliable Distributed Systems (SRDS),
pages 66–78, Oct. 2004.

[4] Joshua B. Leners, Hao Wu, Wei-Lun Hung, Marcos K. Aguilera, and Michael
Walfish. 2011. Detecting failures in distributed systems with the Falcon
spy network. In Proceedings of the Twenty-Third ACM Symposium on Operating
Systems Principles (SOSP '11). ACM, New York, NY, USA, 279-294.

Re: [BUG][ACS41][CLOUD-INIT] cloud-init 0.7.2 is not able to pull metadata from cloudstack

[Chip Childers]

On Mon, Apr 08, 2013 at 10:56:50PM +, Musayev, Ilya wrote:
> John,
> 
> Please register with JIRA and create an issue. I will assign the issue to you.

I'd need to set his role to allow issues to be assigned to him.  So I
need the Jira ID.

> 
> Then we need to create a review board request, someone will approve and push 
> it in.
> 
> Regards
> ilya
> 
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Monday, April 08, 2013 4:49 PM
> > To: 
> > Subject: Re: [BUG][ACS41][CLOUD-INIT] cloud-init 0.7.2 is not able to pull
> > metadata from cloudstack
> > 
> > Can you file a bug and submit a patch with the fix?  Thanks for the report!
> > 
> > On Apr 8, 2013, at 4:47 PM, "Yi, John"  wrote:
> > 
> > > CLOUD-INIT 0.7.2 is using a boto library which hardcodes part of the path
> > for getting the metadata for a VM instance. One fix is to add the following
> > rules to the routervm's docroot /var/www/html/latest/.htaccess:
> > >
> > > RewriteRule ^meta-data/$ ../metadata/%{REMOTE_ADDR}/meta-data
> > > [L,NC,QSA] RewriteRule ^meta-data/(.*)$
> > ../metadata/%{REMOTE_ADDR}/$1
> > > [L,NC,QSA]
> > >
> > > I've tested this with my CentOS 6 VMs and this fix seems to solve the 
> > > issue
> > without requiring code changes within cloud-init or boto.
> > >
> > > John
> 
> 
> 

Re: Cloudstack.org domain

[Chip Childers]

On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote:
> On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
> > On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers  
> > wrote:
> > > Hi all,
> > >
> > > One of our graduation checklist items is to get the cloudstack.org
> > > domain migrated to ASF infra for registration ownership and probably
> > > also for name services (although I'm not sure what the approach is for
> > > the latter).
> > >
> > > Can someone from Citrix with the right authority please work with infra@
> > > to get this completed?
> > >
> > > -chip
> > 
> > I'll take care of this.
> > 
> > I'll start the conversation with infra and report back here.
> > 
> I'm assuming this will takeout the following services:
> a) jenkins.cs.o
> b) paste.cs.o (replaced by apaste.info)

Not necessarily.  Changing ownership / nameservers shouldn't force us to
drop those A records from the zone file, right?

If David hears otherwise from infra@, then we can figure it out from
there.

Re: how is failure detection achieved in cloudstack?

[Chip Childers]

On Tue, Apr 09, 2013 at 01:45:24PM +0200, Alejandro Z. Tomsic wrote:
> I would like to know how the process of failure detection is achieved in
> cloudStack (if any). I would like to know about the implementation details,
> i.e. if its done at physical, virtual machine or at application level. Does
> cloudStack use any known failure detection mechanisms? e.g. [1][2][3][4] or
> any other. Where can I find this information?

Failure detection of *what*?

There is a feature to enable "HA" (which is incorrectly named frankly)
for certain compute offerings.  When that feature is enabled, and the
underlying host dies, the affected VMs will be restarted on another
host.

> 
> Thank you in advance.
> 
> Alejandro
> 
> 
> 
> 
> [1] M.Bertier,O.Marin,andP.Sens.Implementation and performance evaluation
> of an adaptable failure detector. In International Conference on Dependable
> Systems and Networks (DSN), pages 354–363, June 2002.
> 
> [2] W. Chen, S. Toueg, and M. K. Aguilera. On the quality of service of
> failure detectors. IEEE Transactions on Computers, 51(5):561–580, May 2002.
> 
> [3] N. Hayashibara, X. De ́fago, R. Yared, and T. Katayama. The φ accrual
> failure detector. In IEEE Symposium on Reliable Distributed Systems (SRDS),
> pages 66–78, Oct. 2004.
> 
> [4] Joshua B. Leners, Hao Wu, Wei-Lun Hung, Marcos K. Aguilera, and Michael
> Walfish. 2011. Detecting failures in distributed systems with the Falcon
> spy network. In Proceedings of the Twenty-Third ACM Symposium on Operating
> Systems Principles (SOSP '11). ACM, New York, NY, USA, 279-294.

Re: FW: git commit: updated refs/heads/4.1 to 9b6ff74

[Chip Childers]

On Tue, Apr 09, 2013 at 11:59:03AM +, Pranav Saxena wrote:
> Hi Chip,
> 
> I had to make a small commit to 4.1 without creating a patch request for it . 
> The fix would allow the user to see the instance UUID under the load balancer 
> rule when it's "displayname" property is NULL  since prior to this nothing 
> was displayed which was blocking the user to know which instance is 
> associated with the lb Rule.
> 

ACK - thanks for the note.  Looks fine.

> Thanks,
> Pranav
> 
> -Original Message-
> From: pran...@apache.org [mailto:pran...@apache.org] 
> Sent: Tuesday, April 09, 2013 5:26 PM
> To: comm...@cloudstack.apache.org
> Subject: git commit: updated refs/heads/4.1 to 9b6ff74
> 
> Updated Branches:
>   refs/heads/4.1 6d2a24680 -> 9b6ff74e3
> 
> 
> CLOUDSTACK-1428:[UI] Instance which are created without display name are not 
> visible when added to LB: Using the name property instead in the data flow
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/9b6ff74e
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/9b6ff74e
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/9b6ff74e
> 
> Branch: refs/heads/4.1
> Commit: 9b6ff74e3a9535dddfe88121afcfa49cca546cf2
> Parents: 6d2a246
> Author: Pranav Saxena 
> Authored: Tue Apr 9 17:03:41 2013 +0530
> Committer: Pranav Saxena 
> Committed: Tue Apr 9 17:03:41 2013 +0530
> 
> --
>  ui/scripts/network.js |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/9b6ff74e/ui/scripts/network.js
> --
> diff --git a/ui/scripts/network.js b/ui/scripts/network.js index 
> db06c04..1bc4eba 100755
> --- a/ui/scripts/network.js
> +++ b/ui/scripts/network.js
> @@ -3099,7 +3099,7 @@
>  });
>  
>  $.extend(item, {
> -  _itemName: 'displayname',
> +  _itemName: 'name',
>_itemData: lbInstances,
>_maxLength: {
>  name: 7
> 
> 

Re: Using VMware dvSwitch in CloudStack for Review

[Chip Childers]

On Tue, Apr 09, 2013 at 04:42:31AM +, Radhika Puthiyetath wrote:
> Hi Ilya/ Sateesh
> 
> Resending the doc .
> 
> Here is the updated section on dvSwitch. Please see 8.3.7. Configuring a 
> vSphere Cluster with VMware Distributed Virtual Switch (page no. 108)
> 
> I also have the following doubts:
> 
> Could you clarify what do you mean by
> 
> Do not attempt to configure DVSwitch by altering VMWare Traffic Label (What 
> is VMware traffic label ? are you talking about the one during zone creation? 
> Or about the one on vCenter side ?) when configuring Physical Networks (then 
> what is the right procedure ?) This will only work for Standard Virtual 
> Switch and not Distributed (what should not be disturbed ?).
> 
> Thanks
> -Radhika
> 
> 
Radhika,

Attachments are stripped.  Was there something you were trying to
attach?

Re: [ACS41][Patch Request] CLOUDSTACK-1834: Events are not generated for registerUserKeys()

[Chip Childers]

On Tue, Apr 09, 2013 at 12:19:29PM +, Murali Reddy wrote:
> CLOUDSTACK-1834: Events are not generated for registerUserKeys()
> 
> Branch: refs/heads/master
> Commit: 9180bd599015ce248e894a0ef476a4604b1533e4
> Parents: 47dc989
> Author: Murali Reddy mailto:murali.re...@citrix.com>>
> Authored: Tue Apr 9 17:45:19 2013 +0530
> Committer: Murali Reddy 
> mailto:murali.re...@citrix.com>>
> Committed: Tue Apr 9 17:45:57 2013 +0530

ACK and applied.  Thanks!

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

Okay so apparently when i fire off cloudstack-management server it is what
appears to be eating all the available memory and causing the laptop to
swap so im not so sure this is viable at this moment unless i can get CS
management to consume considerably less memory


On Wed, Mar 27, 2013 at 8:19 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> This should now be usable for production use as well
> Follow instructions here
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud#QuickClou
> d-howto2
>
> From:  Ahmad Emneina 
> Reply-To:  "aemne...@gmail.com" 
> Date:  Wednesday, March 27, 2013 10:34 AM
> To:  Chiradeep Vittal 
> Cc:  "dev@cloudstack.apache.org" 
> Subject:  Re: [QuickCloud] zero to cloud in less than a minute
>
>
> +1
> so awesome!
>
>
> On Wed, Mar 27, 2013 at 10:17 AM, Chiradeep Vittal
>  wrote:
>
> Yes (actually that's what the instructions say)
>
> On 3/26/13 10:46 PM, "Ahmad Emneina"  wrote:
>
> >would someone be able to fire up all those services (say for a basic zone)
> >on one host?
> >
> >
> >On Tue, Mar 26, 2013 at 10:37 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> Following the discussion [1], we have QuickCloud in a rough-but-ready
> >> state for developers to try out
> >> Instructions  for developers to try it out with DevCloud2 here:
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
> 
> >>
> >> For now only Mac / Unix developers can use this workflow since NFS
> >>mounts
> >> are required.
> >>
> >> [1] http://markmail.org/thread/ajw7b6arhluqcuv2
> >>
>
>
>
>
>
>
>
>
>

Error on Master - systemvms not coming up

[Nitin Mehta]

Using master branch, 6.0 XS and my system vms are not coming up. I am getting 
the following error but unable to find the root cause of it.

Smlog, xensource log and MS log do not seem to say more than this info. I have 
tried to verify the sec. storage, reinstalled the XS host and restarted the 
xapi service with no respite.
I have systemvm.iso and vhd-util on this XS.


2013-04-09 19:24:37,224 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) VLAN is created for 30.  The uuid is 
a751bba8-d5a8-98f3-7713-290d8652cfe6
2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif a700f78b-3270-814e-c014-f1c2f987bb0b on 2
2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Control-169.254.2.56-null]
2013-04-09 19:24:37,638 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) already have a vif on dom0 for link local network
2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif 6b66cff0-805e-7dd3-d211-2add2e1786f9 on 0
2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Management-10.147.28.158-null]
2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif a1189522-add6-6489-fd4a-c43a40ab104a on 1
2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Storage-10.147.28.153-null]
2013-04-09 19:24:38,451 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif cb21b21c-b1f7-729c-52f0-85677d75a75d on 3
2013-04-09 19:24:41,731 WARN  [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Task failed! Task record: uuid: 
2428b55e-1cd0-0ce1-b20b-16734f551401
   nameLabel: Async.VM.start_on
 nameDescription:
   allowedOperations: []
   currentOperations: {}
 created: Tue Apr 09 19:35:52 GMT+05:30 2013
finished: Tue Apr 09 19:35:54 GMT+05:30 2013
  status: failure
  residentOn: com.xensource.xenapi.Host@f55a038a
progress: 1.0
type: 
  result:
   errorInfo: [Traceback (most recent call last):,   File 
"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file, part_offs[0], 
bootfsoptions), IOError: [Errno 95] Operation not supported, ]
 otherConfig: {}
   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []

2013-04-09 19:24:41,771 WARN  [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Unable to start VM(s-5-VM) on 
host(6fcb5a41-8ec2-40ee-857d-af6f4b8c39fc) due to Task failed! Task record: 
uuid: 2428b55e-1cd0-0ce1-b20b-16734f551401
   nameLabel: Async.VM.start_on
 nameDescription:
   allowedOperations: []
   currentOperations: {}
 created: Tue Apr 09 19:35:52 GMT+05:30 2013
finished: Tue Apr 09 19:35:54 GMT+05:30 2013
  status: failure
  residentOn: com.xensource.xenapi.Host@f55a038a
progress: 1.0
type: 
  result:
   errorInfo: [Traceback (most recent call last):,   File 
"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file, part_offs[0], 
bootfsoptions), IOError: [Errno 95] Operation not supported, ]
 otherConfig: {}
   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []

Task failed! Task record: uuid: 
2428b55e-1cd0-0ce1-b20b-16734f551401

Re: Cloudstack.org domain

[Noah Slater]

I shouldn't expect so.


On 9 April 2013 14:13, Chip Childers  wrote:

> On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote:
> > On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
> > > On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers <
> chip.child...@sungard.com> wrote:
> > > > Hi all,
> > > >
> > > > One of our graduation checklist items is to get the cloudstack.org
> > > > domain migrated to ASF infra for registration ownership and probably
> > > > also for name services (although I'm not sure what the approach is
> for
> > > > the latter).
> > > >
> > > > Can someone from Citrix with the right authority please work with
> infra@
> > > > to get this completed?
> > > >
> > > > -chip
> > >
> > > I'll take care of this.
> > >
> > > I'll start the conversation with infra and report back here.
> > >
> > I'm assuming this will takeout the following services:
> > a) jenkins.cs.o
> > b) paste.cs.o (replaced by apaste.info)
>
> Not necessarily.  Changing ownership / nameservers shouldn't force us to
> drop those A records from the zone file, right?
>
> If David hears otherwise from infra@, then we can figure it out from
> there.
>



-- 
NS

RE: Error on Master - systemvms not coming up

[Pranav Saxena]

Did you try clearing up host tags and stale images on your primary storage  . 
Try doing this perhaps through the xencenter or the xe command line. I 
installed latest master today in the afternoon and its working fine for me 

Thanks,
Pranav

-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com] 
Sent: Tuesday, April 09, 2013 7:35 PM
To: dev@cloudstack.apache.org
Subject: Error on Master - systemvms not coming up

Using master branch, 6.0 XS and my system vms are not coming up. I am getting 
the following error but unable to find the root cause of it.

Smlog, xensource log and MS log do not seem to say more than this info. I have 
tried to verify the sec. storage, reinstalled the XS host and restarted the 
xapi service with no respite.
I have systemvm.iso and vhd-util on this XS.


2013-04-09 19:24:37,224 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) VLAN is created for 30.  The uuid is 
a751bba8-d5a8-98f3-7713-290d8652cfe6
2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif a700f78b-3270-814e-c014-f1c2f987bb0b on 2
2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Control-169.254.2.56-null]
2013-04-09 19:24:37,638 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) already have a vif on dom0 for link local network
2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif 6b66cff0-805e-7dd3-d211-2add2e1786f9 on 0
2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Management-10.147.28.158-null]
2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif a1189522-add6-6489-fd4a-c43a40ab104a on 1
2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
[Nic:Storage-10.147.28.153-null]
2013-04-09 19:24:38,451 DEBUG [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Created a vif cb21b21c-b1f7-729c-52f0-85677d75a75d on 3
2013-04-09 19:24:41,731 WARN  [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Task failed! Task record: uuid: 
2428b55e-1cd0-0ce1-b20b-16734f551401
   nameLabel: Async.VM.start_on
 nameDescription:
   allowedOperations: []
   currentOperations: {}
 created: Tue Apr 09 19:35:52 GMT+05:30 2013
finished: Tue Apr 09 19:35:54 GMT+05:30 2013
  status: failure
  residentOn: com.xensource.xenapi.Host@f55a038a
progress: 1.0
type: 
  result:
   errorInfo: [Traceback (most recent call last):,   File 
"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file, part_offs[0], 
bootfsoptions), IOError: [Errno 95] Operation not supported, ]
 otherConfig: {}
   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []

2013-04-09 19:24:41,771 WARN  [xen.resource.CitrixResourceBase] 
(DirectAgent-13:null) Unable to start VM(s-5-VM) on 
host(6fcb5a41-8ec2-40ee-857d-af6f4b8c39fc) due to Task failed! Task record: 
uuid: 2428b55e-1cd0-0ce1-b20b-16734f551401
   nameLabel: Async.VM.start_on
 nameDescription:
   allowedOperations: []
   currentOperations: {}
 created: Tue Apr 09 19:35:52 GMT+05:30 2013
finished: Tue Apr 09 19:35:54 GMT+05:30 2013
  status: failure
  residentOn: com.xensource.xenapi.Host@f55a038a
progress: 1.0
type: 
  result:
   errorInfo: [Traceback (most recent call last):,   File 
"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file, part_offs[0], 
bootfsoptions), IOError: [Errno 95] Operation not supported, ]
 otherConfig: {}
   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []

Task failed! Task record: uuid: 
2428b55e-1cd0-0ce1-b20b-16734f551401

cwiki.apache.org is taking too long to respond. any infra issues?

[Rajesh Battala]

Hi,
It's taking very long time for the https://cwiki.apache.org/ to respond. Saving 
wiki pages is taking long time and sometimes showing blank page as its not 
responding.
Is there any know issue with cwiki.apache.org site?

Thanks
Rajesh Battala

Re: Cloudstack.org domain

[David Nalley]

On Tue, Apr 9, 2013 at 9:13 AM, Chip Childers  wrote:
> On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote:
>> On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
>> > On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers  
>> > wrote:
>> > > Hi all,
>> > >
>> > > One of our graduation checklist items is to get the cloudstack.org
>> > > domain migrated to ASF infra for registration ownership and probably
>> > > also for name services (although I'm not sure what the approach is for
>> > > the latter).
>> > >
>> > > Can someone from Citrix with the right authority please work with infra@
>> > > to get this completed?
>> > >
>> > > -chip
>> >
>> > I'll take care of this.
>> >
>> > I'll start the conversation with infra and report back here.
>> >
>> I'm assuming this will takeout the following services:
>> a) jenkins.cs.o
>> b) paste.cs.o (replaced by apaste.info)
>
> Not necessarily.  Changing ownership / nameservers shouldn't force us to
> drop those A records from the zone file, right?
>
> If David hears otherwise from infra@, then we can figure it out from
> there.

Yes it will.
Infra indicates they won't point to any non-ASF resources.

--David

Re: Cloudstack.org domain

[Chip Childers]

On Tue, Apr 09, 2013 at 10:46:02AM -0400, David Nalley wrote:
> On Tue, Apr 9, 2013 at 9:13 AM, Chip Childers  
> wrote:
> > On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote:
> >> On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
> >> > On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers 
> >> >  wrote:
> >> > > Hi all,
> >> > >
> >> > > One of our graduation checklist items is to get the cloudstack.org
> >> > > domain migrated to ASF infra for registration ownership and probably
> >> > > also for name services (although I'm not sure what the approach is for
> >> > > the latter).
> >> > >
> >> > > Can someone from Citrix with the right authority please work with 
> >> > > infra@
> >> > > to get this completed?
> >> > >
> >> > > -chip
> >> >
> >> > I'll take care of this.
> >> >
> >> > I'll start the conversation with infra and report back here.
> >> >
> >> I'm assuming this will takeout the following services:
> >> a) jenkins.cs.o
> >> b) paste.cs.o (replaced by apaste.info)
> >
> > Not necessarily.  Changing ownership / nameservers shouldn't force us to
> > drop those A records from the zone file, right?
> >
> > If David hears otherwise from infra@, then we can figure it out from
> > there.
> 
> Yes it will.
> Infra indicates they won't point to any non-ASF resources.
> 
> --David
>

That's unfortunate...

RE: cwiki.apache.org is taking too long to respond. any infra issues?

[Venkata SwamyBabu Budumuru]

Im also not able to access cwiki. Can someone look into it?

Thanks




Sent from Samsung tablet

Rajesh Battala  wrote:
Hi,
It's taking very long time for the https://cwiki.apache.org/ to respond. Saving 
wiki pages is taking long time and sometimes showing blank page as its not 
responding.
Is there any know issue with cwiki.apache.org site?

Thanks
Rajesh Battala

Re: cwiki.apache.org is taking too long to respond. any infra issues?

[Chip Childers]

On Tue, Apr 09, 2013 at 02:30:58PM +, Rajesh Battala wrote:
> Hi,
> It's taking very long time for the https://cwiki.apache.org/ to respond. 
> Saving wiki pages is taking long time and sometimes showing blank page as its 
> not responding.
> Is there any know issue with cwiki.apache.org site?
> 
> Thanks
> Rajesh Battala

It seems to be cleared up now.

Re: cwiki.apache.org is taking too long to respond. any infra issues?

[Chip Childers]

On Tue, Apr 09, 2013 at 02:49:51PM +, Venkata SwamyBabu Budumuru wrote:
> Im also not able to access cwiki. Can someone look into it?

This list isn't the ASF infrastructure list.  If you run into problems like 
this, 
infra is the group to contact.

You can always log a bug at https://issues.apache.org/jira/browse/INFRA

-chip

Re: Review Request: Cloudstack-701 Support for non contiguous vlan ranges.

[bharat kumar]

> On April 8, 2013, 9:36 p.m., Likitha Shetty wrote:
> > server/src/com/cloud/network/NetworkServiceImpl.java, line 2377
> > 
> >
> > Please handle the following 2 corner cases where admin user tries to 
> > shrink the existing vnet ranges
> > 1. New start vnet is equal to the start vnet of the existing range and 
> > the new end vnet is less than the existing end vnet
> > 2. New start vnet is greater than the start vnet of the existing range 
> > and the new end vnet is equal to the existing end vnet

The error message is incorrect, It is not about trying to shrink the vlan 
range.  Forgot to remove the error message from previous code.  Thanks for 
pointing this out. Fixed it.


- bharat


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


On April 4, 2013, 12:36 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10238/
> ---
> 
> (Updated April 4, 2013, 12:36 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Description
> ---
> 
> Cloudstack-701: Support for non contiguous vlan ranges.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkService.java ab6d7bf 
>   api/src/com/cloud/network/PhysicalNetwork.java a2044a6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c518830 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java
>  06cf38d 
>   server/src/com/cloud/api/ApiResponseHelper.java 64be7f8 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 1526fb0 
>   server/src/com/cloud/dc/dao/DataCenterVnetDao.java 79e91c4 
>   server/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 5ded0f4 
>   server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java ae00bf2 
>   server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
>   server/src/com/cloud/network/dao/PhysicalNetworkVO.java e5ffcfb 
>   server/src/com/cloud/network/guru/GuestNetworkGuru.java 9c0205a 
>   server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 
>   server/test/com/cloud/network/MockNetworkManagerImpl.java 6da48ec 
>   server/test/com/cloud/network/UpdatePhysicalNetworkTest.java PRE-CREATION 
>   server/test/com/cloud/vpc/MockNetworkManagerImpl.java ead0051 
>   test/integration/smoke/test_non_contigiousvlan.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10238/diff/
> 
> 
> Testing
> ---
> 
> Tested on latest master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Cloudstack-701 Support for non contiguous vlan ranges.

[bharat kumar]

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

(Updated April 9, 2013, 3 p.m.)


Review request for cloudstack and Abhinandan Prateek.


Changes
---

Fixed a few corner cases and improved exception handling.


Description
---

Cloudstack-701: Support for non contiguous vlan ranges.


Diffs (updated)
-

  api/src/com/cloud/network/NetworkService.java ab6d7bf 
  api/src/com/cloud/network/PhysicalNetwork.java a2044a6 
  api/src/org/apache/cloudstack/api/ApiConstants.java c518830 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java
 06cf38d 
  server/src/com/cloud/api/ApiResponseHelper.java 64be7f8 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 1526fb0 
  server/src/com/cloud/dc/dao/DataCenterVnetDao.java 79e91c4 
  server/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 5ded0f4 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java ae00bf2 
  server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
  server/src/com/cloud/network/dao/PhysicalNetworkVO.java e5ffcfb 
  server/src/com/cloud/network/guru/GuestNetworkGuru.java 9c0205a 
  server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 
  server/test/com/cloud/network/MockNetworkManagerImpl.java 6da48ec 
  server/test/com/cloud/network/UpdatePhysicalNetworkTest.java PRE-CREATION 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java ead0051 
  test/integration/smoke/test_non_contigiousvlan.py PRE-CREATION 

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


Testing
---

Tested on latest master.


Thanks,

bharat kumar

Documentation How-To

[Jason Cadmus]

I am working on installing/testing/documenting CS 4.10 on vSphere 5.1 using
vDistributed Switching with CS advanced networking. Can someone please give
me some insight on the proper way to contribute to CS formal documentation?

-- 
Thanks,
JC

Re: cwiki.apache.org is taking too long to respond. any infra issues?

[David Nalley]

On Tue, Apr 9, 2013 at 10:52 AM, Chip Childers
 wrote:
> On Tue, Apr 09, 2013 at 02:49:51PM +, Venkata SwamyBabu Budumuru wrote:
>> Im also not able to access cwiki. Can someone look into it?
>
> This list isn't the ASF infrastructure list.  If you run into problems like 
> this,
> infra is the group to contact.
>
> You can always log a bug at https://issues.apache.org/jira/browse/INFRA
>
> -chip

I'd start by looking at:
http://status.apache.org

You'll see that thor, the machine that runs cwiki, is having issues.
Nagios has of course alerted appropriate folks within infra.
If you really need attention - please look at and follow this page:
http://www.apache.org/dev/infra-contact

You'll note that for outages - they only wish to receive reports if
status.a.o isn't reporting the outage. They already have a monitoring
system that reports outages, additional notification isn't likely to
get things done any quicker.

--David

RE: Documentation How-To

[Radhika Puthiyetath]

Hi Jason,

The doc has been under review for a long time;  however, I can share you the 
draft with you off-list.

I am not sure whatever I have documented is perfect as the feature owner hasn't 
reviewed it yet.

Regards

-Radhika

-Original Message-
From: Jason Cadmus [mailto:jdcad...@gmail.com] 
Sent: Tuesday, April 09, 2013 8:42 PM
To: dev@cloudstack.apache.org
Subject: Documentation How-To

I am working on installing/testing/documenting CS 4.10 on vSphere 5.1 using 
vDistributed Switching with CS advanced networking. Can someone please give me 
some insight on the proper way to contribute to CS formal documentation?

--
Thanks,
JC

Re: Documentation How-To

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 10:12 AM, Jason Cadmus wrote:
> I am working on installing/testing/documenting CS 4.10 on vSphere 5.1
> using vDistributed Switching with CS advanced networking. Can someone please
> give me some insight on the proper way to contribute to CS formal
> documentation?

Thanks, and sure!

I'm not sure what level of help you're asking for, so forgive me if some
of this is information you're already in possession of:

1) Our docs are written in Publican (a subset of DocBook) and stored in
Git with the rest of the code under docs/en-US/

2) Clone the git repo and create a branch to start working on your docs.
Ideally, this would be on a system where you can run Publican to verify
the docs. 

3) There's a README.txt under docs/ that provides a short intro to
Publican, accepted tags, etc. 

4) It sounds like you're going to be doing something that belongs in the
admin guide, so start a new section or chapter with a filename like
"working-with-vdistributed.xml" and add it to the "Admin_Guide.xml"
includes in the order you want it to appear in the guide.

5) Once you're done, test building it with Publican. If that works,
submit a patch (diff) via Review Board
(https://reviews.apache.org/dashboard/) and mark it for the
cloudstack-git repository. For reviewers, select "cloudstack" as the
group, and the appropriate folks for reviewers. (You can add me - jzb -
and I can check it for validity, but not so much for content since I
don't work with vDistributed Switching). 

Note - please make sure you submit a patch that works against master and
4.1 if possible. 

If you have questions, feel free to ping us in IRC on #cloudstack-dev as
well if you want real-time(ish) feedback. I'm usually around during the
day, and chipc, ke4qqq and others can also assist. 

(Or keep asking on dev@ as well, that works too.)

Look forward to the patches!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Documentation How-To

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 10:29 AM, Radhika Puthiyetath wrote:
> Hi Jason,
> 
> The doc has been under review for a long time;  however, I can share you
> the draft with you off-list.

Off-list? Do you have it on Review Board? 

I think you might be referring to this: 

https://reviews.apache.org/r/10366/

If so, maybe Jason can help with this as well?
 
Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Cloudstack.org domain

[Noah Slater]

Do you have a link to the discussion thread, David? I can't find anything
in my mail.


On 9 April 2013 15:46, David Nalley  wrote:

> On Tue, Apr 9, 2013 at 9:13 AM, Chip Childers 
> wrote:
> > On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote:
> >> On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote:
> >> > On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers <
> chip.child...@sungard.com> wrote:
> >> > > Hi all,
> >> > >
> >> > > One of our graduation checklist items is to get the cloudstack.org
> >> > > domain migrated to ASF infra for registration ownership and probably
> >> > > also for name services (although I'm not sure what the approach is
> for
> >> > > the latter).
> >> > >
> >> > > Can someone from Citrix with the right authority please work with
> infra@
> >> > > to get this completed?
> >> > >
> >> > > -chip
> >> >
> >> > I'll take care of this.
> >> >
> >> > I'll start the conversation with infra and report back here.
> >> >
> >> I'm assuming this will takeout the following services:
> >> a) jenkins.cs.o
> >> b) paste.cs.o (replaced by apaste.info)
> >
> > Not necessarily.  Changing ownership / nameservers shouldn't force us to
> > drop those A records from the zone file, right?
> >
> > If David hears otherwise from infra@, then we can figure it out from
> > there.
>
> Yes it will.
> Infra indicates they won't point to any non-ASF resources.
>
> --David
>



-- 
NS

RE: Documentation How-To

[Radhika Puthiyetath]

Hi Joe,

I cannot attach the PDF while replying to dev list. So I offered to send it off 
-list.

The doc was initially checked in to the repo after completing the draft. Only 
Ilya, who tested it,  has provided initial comments on them.

I had many questions, which I posted on the ML, but none was answered.

Since the feature owner hasn't reviewed, I had to *revert* the commit (commit 
8a435f5b43bb013b73875ba4b8cf4a0b537036d4)
and submit a patch on the Review Board so that the doc will reach to larger 
audience.

Correct me if I am wrong.

Regards
-Radhika

-Original Message-
From: Joe Brockmeier [mailto:j...@zonker.net] 
Sent: Tuesday, April 09, 2013 9:11 PM
To: dev@cloudstack.apache.org
Subject: Re: Documentation How-To

On Tue, Apr 9, 2013, at 10:29 AM, Radhika Puthiyetath wrote:
> Hi Jason,
> 
> The doc has been under review for a long time;  however, I can share 
> you the draft with you off-list.

Off-list? Do you have it on Review Board? 

I think you might be referring to this: 

https://reviews.apache.org/r/10366/

If so, maybe Jason can help with this as well?
 
Best,

jzb
--
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

[REMINDER] Weekly IRC Meeting

[Joe Brockmeier]

Reminder: Our weekly IRC meeting is tomorrow (Wednesday, 10 April) at
17:00 UTC [1]. 

The standing agenda is here:
https://cwiki.apache.org/CLOUDSTACK/irc-meetings-logs-and-minutes.html

Please join us in #cloudstack-meeting on Freenode. If you're not a
regular IRC user, you can use the webchat: http://webchat.freenode.net/

It's useful if everyone arrives at the meeting time and stays on topic.
Please try to arrive at or very close to 17:00 UTC and be sure to follow
the topics as they're discussed, and add "EOF" or something similar when
you're done speaking. 

Meeting summaries are posted immediately after the meeting, you can find
older meeting logs here:
http://wilderness.apache.org/archives/#logs-cloudstack-meeting

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Weekly+IRC+Meeting&iso=20130410T17&ah=1

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DIscuss]Storage image store plugin framework refactoring

[Min Chen]

Not yet at this moment. But we are planning to provide a sample plugin
implementation for this effort. If you are looking at object_store branch,
you will see a plugin called "cloud-plugin-storage-image-sample", which
will be the placeholder for a sample image store implementation.

Thanks
-min

On 4/9/13 1:59 AM, "Prasanna Santhanam"  wrote:

>On Mon, Apr 08, 2013 at 04:45:23PM -0700, Min Chen wrote:
>> Hi All,
>> 
>> Currently CloudStack does not offer a flexible pluggable framework
>> for users to easily integrate and configure any 3rd-party object
>> stores for such backup services as registering templates, taking
>> snapshots, etc. Along with Edison's recent refactored storage
>> subsystem 2.0 that mainly refactored current CloudStack primary
>> storage implementation,  we are proposing to develop a storage
>> backup object store plugin framework to allow CloudStack to
>> systematically manage and configure various types of backup data
>> stores from different vendors, like NFS, S3, Swift, etc. With this
>> new plugin framework, we would like to achieve following
>> functionalities:
>
>> 1. Support different object store providers in a uniform and
>> pluggable fashion.
>> 2. Enable region wide object backup using S3-like object store.
>> 3. Provide pluggable data motion strategies to handle data transfer
>> from one data store to another data store.
>> 4. Provide a scalable cache storage framework while moving data
>> between primary storage and backup storage for certain hypervisor
>> needs.
>> 5. Support flexible combinations of primary storage, secondary
>> storage and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware),
>> (ISCSI, Swift, KVM), ?., etc.
>> The proposed ImageStore plugin framework architecture is detailed in
>> our FS here:
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Obj
>>ect+Store+Plugin+Framework.
>> The JIRA ticket to track this feature is:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
>> currently carried out in feature branch  "object_store".
>> Please let me know your comments and suggestions.
>
>Perhaps it is too early to ask, will there be a reference
>implementation done for any object store solutions as part of the
>refactoring?
>
>-- 
>Prasanna.,

Re: Cloudstack.org domain

[David Nalley]

On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater  wrote:
> Do you have a link to the discussion thread, David? I can't find anything
> in my mail.
>

You'll need to use your member karma, as it's on infra-private:
097901ce30c3$c69ff210$53dfd630$@16degrees.com.au

Re: [DIscuss]Storage image store plugin framework refactoring

[Min Chen]

Yes, I will include more api change details in FS in next few days.
According to Chiradeep, it seems that we cannot simply deprecate old API
in 4.2, Edison and I will discuss this and update FS with details on how
to handle these old APIs.

Thanks
-min

On 4/8/13 6:34 PM, "Sangeetha Hariharan" 
wrote:

>Min,
>
>Could you also include the details of the API changes (new parameters)
>that will be proposed as part of this feature?
>Also it would be helpful if you list the request and response parameters
>for the new API calls.
>For all the API calls that are being deprecated , is there any specific
>error message that will be returned?
>
>-Thanks
>Sangeetha 
>
>-Original Message-
>From: Min Chen [mailto:min.c...@citrix.com]
>Sent: Monday, April 08, 2013 4:45 PM
>To: dev@cloudstack.apache.org
>Subject: [DIscuss]Storage image store plugin framework refactoring
>
>Hi All,
>
>Currently CloudStack does not offer a flexible pluggable framework for
>users to easily integrate and configure any 3rd-party object stores for
>such backup services as registering templates, taking snapshots, etc.
>Along with Edison's recent refactored storage subsystem 2.0 that mainly
>refactored current CloudStack primary storage implementation,  we are
>proposing to develop a storage backup object store plugin framework to
>allow CloudStack to systematically manage and configure various types of
>backup data stores from different vendors, like NFS, S3, Swift, etc. With
>this new plugin framework, we would like to achieve following
>functionalities:
>1. Support different object store providers in a uniform and pluggable
>fashion.
>2. Enable region wide object backup using S3-like object store.
>3. Provide pluggable data motion strategies to handle data transfer from
>one data store to another data store.
>4. Provide a scalable cache storage framework while moving data between
>primary storage and backup storage for certain hypervisor needs.
>5. Support flexible combinations of primary storage, secondary storage
>and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware), (ISCSI,
>Swift, KVM), , etc.
>The proposed ImageStore plugin framework architecture is detailed in our
>FS here: 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Obje
>ct+Store+Plugin+Framework.
>The JIRA ticket to track this feature is:
>https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
>currently carried out in feature branch  "object_store".
>Please let me know your comments and suggestions.
>
>Thanks
>-min
>
>

Re: Documentation How-To

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 11:02 AM, Radhika Puthiyetath wrote:
> I cannot attach the PDF while replying to dev list. So I offered to send
> it off -list.
> 
> The doc was initially checked in to the repo after completing the draft.
> Only Ilya, who tested it,  has provided initial comments on them.
> 
> I had many questions, which I posted on the ML, but none was answered.
> 
> Since the feature owner hasn't reviewed, I had to *revert* the commit
> (commit 8a435f5b43bb013b73875ba4b8cf4a0b537036d4)
> and submit a patch on the Review Board so that the doc will reach to
> larger audience.
> 
> Correct me if I am wrong.

It sounds like you're Doing It Right, but I'd recommend pointing Jason
(or others) to the review board patch rather than sending a PDF. 

It looks like this was only in master - any reason why you reverted the
commit rather than just continuing to make modifications? Just curious.
Seems like that would be more work for you. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

[DISCUSS] - Deletion of Users within the Admin account

[Pranav Saxena]

HI,

Do we allow deletion of users created by the admin within the admin account ? 
Currently if we  see the UI (4.1 /master) and create a User within the admin 
account you won't be able to delete any user . Now when you create a user , its 
account type is 1 , account is Admin and domain is ROOT . With this in mind ,  
how do you distinguish between the system generated Admin user and a manual 
generated user .

Also  , the delete User API if invoked for the admin himself will delete the 
admin account leading to a big problem , since the admin won't be able to login 
to the UI as his credentials will be deleted from the db.  So first of all we 
should have a check at the API layer to disallow such an action .

Next , If I need to put a check at the UI layer to hide/show delete options , 
what would be the right conditions needed to be checked to distinguish between 
the system generated user and admin generated manual users ?

Thanks,
Pranav

Re: Cloudstack.org domain

[Noah Slater]

Strange this was on infra-private, and not infra (which is also private). I
only subscribe to the latter. I found your message now. Disappointing. I
had not realised that this was policy. (I guess undocumented.) Wonder if
there's any room for negotiation...


On 9 April 2013 17:21, David Nalley  wrote:

> On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater  wrote:
> > Do you have a link to the discussion thread, David? I can't find anything
> > in my mail.
> >
>
> You'll need to use your member karma, as it's on infra-private:
> 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au
>



-- 
NS

Re: Cloudstack.org domain

[David Nalley]

It was on infra-private as that was where I was told to carry the
conversation when I asked in IRC.
I don't think that there is any negotiation to be done, multiple infra
contractors over a period of almost a year have echoed similar
sentiments.

--David

On Tue, Apr 9, 2013 at 12:35 PM, Noah Slater  wrote:
> Strange this was on infra-private, and not infra (which is also private). I
> only subscribe to the latter. I found your message now. Disappointing. I
> had not realised that this was policy. (I guess undocumented.) Wonder if
> there's any room for negotiation...
>
>
> On 9 April 2013 17:21, David Nalley  wrote:
>
>> On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater  wrote:
>> > Do you have a link to the discussion thread, David? I can't find anything
>> > in my mail.
>> >
>>
>> You'll need to use your member karma, as it's on infra-private:
>> 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au
>>
>
>
>
> --
> NS

Re: Cloudstack.org domain

[Noah Slater]

Ack :(


On 9 April 2013 17:38, David Nalley  wrote:

> It was on infra-private as that was where I was told to carry the
> conversation when I asked in IRC.
> I don't think that there is any negotiation to be done, multiple infra
> contractors over a period of almost a year have echoed similar
> sentiments.
>
> --David
>
> On Tue, Apr 9, 2013 at 12:35 PM, Noah Slater  wrote:
> > Strange this was on infra-private, and not infra (which is also
> private). I
> > only subscribe to the latter. I found your message now. Disappointing. I
> > had not realised that this was policy. (I guess undocumented.) Wonder if
> > there's any room for negotiation...
> >
> >
> > On 9 April 2013 17:21, David Nalley  wrote:
> >
> >> On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater 
> wrote:
> >> > Do you have a link to the discussion thread, David? I can't find
> anything
> >> > in my mail.
> >> >
> >>
> >> You'll need to use your member karma, as it's on infra-private:
> >> 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: [DISCUSS] - Deletion of Users within the Admin account

[Chip Childers]

On Tue, Apr 09, 2013 at 04:31:41PM +, Pranav Saxena wrote:
> HI,
> 
> Do we allow deletion of users created by the admin within the admin account ? 
> Currently if we  see the UI (4.1 /master) and create a User within the admin 
> account you won't be able to delete any user . Now when you create a user , 
> its account type is 1 , account is Admin and domain is ROOT . With this in 
> mind ,  how do you distinguish between the system generated Admin user and a 
> manual generated user .
> 
> Also  , the delete User API if invoked for the admin himself will delete the 
> admin account leading to a big problem , since the admin won't be able to 
> login to the UI as his credentials will be deleted from the db.  So first of 
> all we should have a check at the API layer to disallow such an action .
> 
> Next , If I need to put a check at the UI layer to hide/show delete options , 
> what would be the right conditions needed to be checked to distinguish 
> between the system generated user and admin generated manual users ?
> 
> Thanks,
> Pranav

Is this discussion tied to CLOUDSTACK-1941?

Is the current state of 4.1 and master a change in behaviour from 4.0.0?

If it isn't a change, I'd like to propose that we set the fix version to 
4.2.0 at a minimum.  Pending the outcome of this discussion thread,
perhaps it will be closed with "won't fix", or perhaps it gets fixed.

If it *is* a change, can we implement a fix that restores past behaviour
as a first step?

-chip

RE: [DISCUSS] - Deletion of Users within the Admin account

[Pranav Saxena]

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 09, 2013 10:18 PM
To: dev@cloudstack.apache.org
Cc: Alena Prokharchyk
Subject: Re: [DISCUSS] - Deletion of Users within the Admin account

On Tue, Apr 09, 2013 at 04:31:41PM +, Pranav Saxena wrote:
> HI,
> 
> Do we allow deletion of users created by the admin within the admin account ? 
> Currently if we  see the UI (4.1 /master) and create a User within the admin 
> account you won't be able to delete any user . Now when you create a user , 
> its account type is 1 , account is Admin and domain is ROOT . With this in 
> mind ,  how do you distinguish between the system generated Admin user and a 
> manual generated user .
> 
> Also  , the delete User API if invoked for the admin himself will delete the 
> admin account leading to a big problem , since the admin won't be able to 
> login to the UI as his credentials will be deleted from the db.  So first of 
> all we should have a check at the API layer to disallow such an action .
> 
> Next , If I need to put a check at the UI layer to hide/show delete options , 
> what would be the right conditions needed to be checked to distinguish 
> between the system generated user and admin generated manual users ?
> 
> Thanks,
> Pranav

Is this discussion tied to CLOUDSTACK-1941?
[Pranav] - yes , it is 

Is the current state of 4.1 and master a change in behaviour from 4.0.0?
[Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be 
exactly the same . 

If it isn't a change, I'd like to propose that we set the fix version to
4.2.0 at a minimum.  Pending the outcome of this discussion thread, perhaps it 
will be closed with "won't fix", or perhaps it gets fixed.
[Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in both 
. It is definitely an API bug which needs to be fixed as admin account should 
not be allowed to be deleted . Moreover from the UI perspective , I need a 
condition to distinguish between the two types of users to showcase delete 
options on the UI accordingly.
 

If it *is* a change, can we implement a fix that restores past behaviour as a 
first step?
[Pranav] - I believe , it should be a "demanding" change if at all 4.0 is also 
having a similar behavior ( which I am not sure of right now) since 
conceptually and technically we should not be following the current behavior in 
any version .

-chip

Re: [DISCUSS] - Deletion of Users within the Admin account

[Alena Prokharchyk]

We should allow to delete any CS users except for ones that came as a part
of cloudStack installation ("system" and "admin" users). The users you've
created using API, should be allowed to be removed no matter of their
types.

The right way to distinguish between system generated users, and users
created using APIs would be introducing the flag in the cloud.users DB.

-Alena.



On 4/9/13 9:53 AM, "Pranav Saxena"  wrote:

>
>
>-Original Message-
>From: Chip Childers [mailto:chip.child...@sungard.com]
>Sent: Tuesday, April 09, 2013 10:18 PM
>To: dev@cloudstack.apache.org
>Cc: Alena Prokharchyk
>Subject: Re: [DISCUSS] - Deletion of Users within the Admin account
>
>On Tue, Apr 09, 2013 at 04:31:41PM +, Pranav Saxena wrote:
>> HI,
>> 
>> Do we allow deletion of users created by the admin within the admin
>>account ? Currently if we  see the UI (4.1 /master) and create a User
>>within the admin account you won't be able to delete any user . Now when
>>you create a user , its account type is 1 , account is Admin and domain
>>is ROOT . With this in mind ,  how do you distinguish between the system
>>generated Admin user and a manual generated user .
>> 
>> Also  , the delete User API if invoked for the admin himself will
>>delete the admin account leading to a big problem , since the admin
>>won't be able to login to the UI as his credentials will be deleted from
>>the db.  So first of all we should have a check at the API layer to
>>disallow such an action .
>> 
>> Next , If I need to put a check at the UI layer to hide/show delete
>>options , what would be the right conditions needed to be checked to
>>distinguish between the system generated user and admin generated manual
>>users ?
>> 
>> Thanks,
>> Pranav
>
>Is this discussion tied to CLOUDSTACK-1941?
>[Pranav] - yes , it is
>
>Is the current state of 4.1 and master a change in behaviour from 4.0.0?
>[Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to
>be exactly the same .
>
>If it isn't a change, I'd like to propose that we set the fix version to
>4.2.0 at a minimum.  Pending the outcome of this discussion thread,
>perhaps it will be closed with "won't fix", or perhaps it gets fixed.
>[Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it
>in both . It is definitely an API bug which needs to be fixed as admin
>account should not be allowed to be deleted . Moreover from the UI
>perspective , I need a condition to distinguish between the two types of
>users to showcase delete options on the UI accordingly.
> 
>
>If it *is* a change, can we implement a fix that restores past behaviour
>as a first step?
>[Pranav] - I believe , it should be a "demanding" change if at all 4.0 is
>also having a similar behavior ( which I am not sure of right now) since
>conceptually and technically we should not be following the current
>behavior in any version .
>
>-chip
>

Re: Documentation How-To

[Jason Cadmus]

I would like to see the draft


On Tue, Apr 9, 2013 at 11:29 AM, Radhika Puthiyetath <
radhika.puthiyet...@citrix.com> wrote:

> Hi Jason,
>
> The doc has been under review for a long time;  however, I can share you
> the draft with you off-list.
>
> I am not sure whatever I have documented is perfect as the feature owner
> hasn't reviewed it yet.
>
> Regards
>
> -Radhika
>
> -Original Message-
> From: Jason Cadmus [mailto:jdcad...@gmail.com]
> Sent: Tuesday, April 09, 2013 8:42 PM
> To: dev@cloudstack.apache.org
> Subject: Documentation How-To
>
> I am working on installing/testing/documenting CS 4.10 on vSphere 5.1
> using vDistributed Switching with CS advanced networking. Can someone
> please give me some insight on the proper way to contribute to CS formal
> documentation?
>
> --
> Thanks,
> JC
>



-- 
Thanks,
JC

Re: [DISCUSS] - Deletion of Users within the Admin account

[David Nalley]

On Tue, Apr 9, 2013 at 12:56 PM, Alena Prokharchyk
 wrote:
> We should allow to delete any CS users except for ones that came as a part
> of cloudStack installation ("system" and "admin" users). The users you've
> created using API, should be allowed to be removed no matter of their
> types.
>


I can sorta understand system - but why should I not be able to purge admin?
Is there something that breaks by deleting admin? (user, not account)

--David

Re: [DISCUSS] - Deletion of Users within the Admin account

[Chip Childers]

On Tue, Apr 09, 2013 at 09:56:37AM -0700, Alena Prokharchyk wrote:
> We should allow to delete any CS users except for ones that came as a part
> of cloudStack installation ("system" and "admin" users). The users you've
> created using API, should be allowed to be removed no matter of their
> types.

+1 to this in general terms.  Not sure about requiring a change like
this for 4.1.0 though.

> 
> The right way to distinguish between system generated users, and users
> created using APIs would be introducing the flag in the cloud.users DB.

Do you have any thoughts on how we would correctly identify these
account in existing installs?

RE: [DISCUSS] - Deletion of Users within the Admin account

[Pranav Saxena]

Yes , you won't be able to login to the UI since the admin credentials would no 
more exist in the db then .

-Original Message-
From: David Nalley [mailto:da...@gnsa.us] 
Sent: Tuesday, April 09, 2013 10:30 PM
To: dev@cloudstack.apache.org
Cc: Pranav Saxena
Subject: Re: [DISCUSS] - Deletion of Users within the Admin account

On Tue, Apr 9, 2013 at 12:56 PM, Alena Prokharchyk 
 wrote:
> We should allow to delete any CS users except for ones that came as a 
> part of cloudStack installation ("system" and "admin" users). The 
> users you've created using API, should be allowed to be removed no 
> matter of their types.
>


I can sorta understand system - but why should I not be able to purge admin?
Is there something that breaks by deleting admin? (user, not account)

--David

Re: [DISCUSS] - Deletion of Users within the Admin account

[Chip Childers]

On Tue, Apr 09, 2013 at 04:53:38PM +, Pranav Saxena wrote:
> Is the current state of 4.1 and master a change in behaviour from 4.0.0?
> [Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be 
> exactly the same . 
> 
> If it isn't a change, I'd like to propose that we set the fix version to
> 4.2.0 at a minimum.  Pending the outcome of this discussion thread, perhaps 
> it will be closed with "won't fix", or perhaps it gets fixed.
> [Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in 
> both . It is definitely an API bug which needs to be fixed as admin account 
> should not be allowed to be deleted . Moreover from the UI perspective , I 
> need a condition to distinguish between the two types of users to showcase 
> delete options on the UI accordingly.
>  
> 
> If it *is* a change, can we implement a fix that restores past behaviour as a 
> first step?
> [Pranav] - I believe , it should be a "demanding" change if at all 4.0 is 
> also having a similar behavior ( which I am not sure of right now) since 
> conceptually and technically we should not be following the current behavior 
> in any version .

As far as 4.1.0 goes, I'd like to release without this change...  unless
we know that it behaved more appropriately in 4.0.0.

Thoughts?

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Chiradeep Vittal]

I believe this was never automated.
The apidocs generation tool generates an XML document that contains all
the APIs.
(tools/apidoc/target/commands.xml). We can diff the 4.0 xml and the 4.1
xml using a tool such as xmldiff (https://pypi.python.org/pypi/xmldiff).

I tried this, but it hangs. The man page for xmldiff says:
"xmldiff uses an algorithm with a (too) high algorithmical complexity,
which
makes it unsuitable to process large XML documents. If your document
has more than about 100 nodes, you should probably look for an
alternative solution"

On 4/5/13 9:31 AM, "Joe Brockmeier"  wrote:

>Bumping this. Any ideas?
>
>On Tue, Apr 2, 2013, at 03:33 PM, Joe Brockmeier wrote:
>> Hi all,
>> 
>> So - the build process for generating API docs has changed since 4.0 ->
>> 4.1, and it looks like in the process we've stopped generating a
>> "diff.txt" of APIs changed/added/deleted since the last version.
>> 
>> Any idea how we can generate this automagically rather than combing
>> through the new docs to see what's different since 4.0.x? Thanks!
>> 
>> Best,
>> 
>> jzb
>> -- 
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>
>
>Best,
>
>jzb
>-- 
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/

Re: [DISCUSS] - Deletion of Users within the Admin account

[Alena Prokharchyk]

Dave, you need to have at least one user in order to login to the UI or
execute an API call. You can't do it as a "system" user, so "admin" should
be the one.

-Alena.

On 4/9/13 10:00 AM, "David Nalley"  wrote:

>On Tue, Apr 9, 2013 at 12:56 PM, Alena Prokharchyk
> wrote:
>> We should allow to delete any CS users except for ones that came as a
>>part
>> of cloudStack installation ("system" and "admin" users). The users
>>you've
>> created using API, should be allowed to be removed no matter of their
>> types.
>>
>
>
>I can sorta understand system - but why should I not be able to purge
>admin?
>Is there something that breaks by deleting admin? (user, not account)
>
>--David
>

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Alena Prokharchyk]

I don't think it was ever a part of the Jenkins build process. I used to
generate the diff locally on my machine by feeding the old and new version
commands.xml files to the script.

We can generate this automatically using 2 ways:

1) Using @Since annotation for new parameters/commands. As a part of the
build process, extract all the commands having @Since="current version"
and put them into diff file. The annotation is already in place, but I
believe most of the times people forget to update it for new
commands/parameters they've been adding.

2) By keeping commands.xml of the previous version in the code base. As a
part of the build process, generate the diff between version (n=current
version) commands.xml and version (n-1).

-Alena.


On 4/5/13 9:31 AM, "Joe Brockmeier"  wrote:

>Bumping this. Any ideas?
>
>On Tue, Apr 2, 2013, at 03:33 PM, Joe Brockmeier wrote:
>> Hi all,
>> 
>> So - the build process for generating API docs has changed since 4.0 ->
>> 4.1, and it looks like in the process we've stopped generating a
>> "diff.txt" of APIs changed/added/deleted since the last version.
>> 
>> Any idea how we can generate this automagically rather than combing
>> through the new docs to see what's different since 4.0.x? Thanks!
>> 
>> Best,
>> 
>> jzb
>> -- 
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>
>
>Best,
>
>jzb
>-- 
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/
>

Re: Error on Master - systemvms not coming up

[Nitin Mehta]

Did clean up my primary as well. Master is not latest but I think there is
something peculiar going on here and yeah I don't think everyone must be
facing this.

On 09/04/13 7:52 PM, "Pranav Saxena"  wrote:

>
>Did you try clearing up host tags and stale images on your primary
>storage  . Try doing this perhaps through the xencenter or the xe command
>line. I installed latest master today in the afternoon and its working
>fine for me 
>
>Thanks,
>Pranav
>
>-Original Message-
>From: Nitin Mehta [mailto:nitin.me...@citrix.com]
>Sent: Tuesday, April 09, 2013 7:35 PM
>To: dev@cloudstack.apache.org
>Subject: Error on Master - systemvms not coming up
>
>Using master branch, 6.0 XS and my system vms are not coming up. I am
>getting the following error but unable to find the root cause of it.
>
>Smlog, xensource log and MS log do not seem to say more than this info. I
>have tried to verify the sec. storage, reinstalled the XS host and
>restarted the xapi service with no respite.
>I have systemvm.iso and vhd-util on this XS.
>
>
>2013-04-09 19:24:37,224 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) VLAN is created for 30.  The uuid is
>a751bba8-d5a8-98f3-7713-290d8652cfe6
>2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif a700f78b-3270-814e-c014-f1c2f987bb0b
>on 2
>2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic
>[Nic:Control-169.254.2.56-null]
>2013-04-09 19:24:37,638 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) already have a vif on dom0 for link local network
>2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif 6b66cff0-805e-7dd3-d211-2add2e1786f9
>on 0
>2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic
>[Nic:Management-10.147.28.158-null]
>2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif a1189522-add6-6489-fd4a-c43a40ab104a
>on 1
>2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic
>[Nic:Storage-10.147.28.153-null]
>2013-04-09 19:24:38,451 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif cb21b21c-b1f7-729c-52f0-85677d75a75d
>on 3
>2013-04-09 19:24:41,731 WARN  [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Task failed! Task record: uuid:
>2428b55e-1cd0-0ce1-b20b-16734f551401
>   nameLabel: Async.VM.start_on
> nameDescription:
>   allowedOperations: []
>   currentOperations: {}
> created: Tue Apr 09 19:35:52 GMT+05:30 2013
>finished: Tue Apr 09 19:35:54 GMT+05:30 2013
>  status: failure
>  residentOn: com.xensource.xenapi.Host@f55a038a
>progress: 1.0
>type: 
>  result:
>   errorInfo: [Traceback (most recent call last):,   File
>"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file,
>part_offs[0], bootfsoptions), IOError: [Errno 95] Operation not
>supported, ]
> otherConfig: {}
>   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
>subtasks: []
>
>2013-04-09 19:24:41,771 WARN  [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Unable to start VM(s-5-VM) on
>host(6fcb5a41-8ec2-40ee-857d-af6f4b8c39fc) due to Task failed! Task
>record: uuid: 2428b55e-1cd0-0ce1-b20b-16734f551401
>   nameLabel: Async.VM.start_on
> nameDescription:
>   allowedOperations: []
>   currentOperations: {}
> created: Tue Apr 09 19:35:52 GMT+05:30 2013
>finished: Tue Apr 09 19:35:54 GMT+05:30 2013
>  status: failure
>  residentOn: com.xensource.xenapi.Host@f55a038a
>progress: 1.0
>type: 
>  result:
>   errorInfo: [Traceback (most recent call last):,   File
>"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file,
>part_offs[0], bootfsoptions), IOError: [Errno 95] Operation not
>supported, ]
> otherConfig: {}
>   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
>subtasks: []
>
>Task failed! Task record: uuid:
>2428b55e-1cd0-0ce1-b20b-16734f551401

RE: [DISCUSS] - Deletion of Users within the Admin account

[Pranav Saxena]

If you think that the admin should not have the flexibility to delete a user 
within the admin account from the UI ( one has to use the API's to do such 
tasks then) , we can go ahead without this change for 4.1  and incorporate this 
change for 4.2 .

Thanks,
Pranav

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 09, 2013 10:34 PM
To: dev@cloudstack.apache.org
Cc: Alena Prokharchyk
Subject: Re: [DISCUSS] - Deletion of Users within the Admin account

On Tue, Apr 09, 2013 at 04:53:38PM +, Pranav Saxena wrote:
> Is the current state of 4.1 and master a change in behaviour from 4.0.0?
> [Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be 
> exactly the same . 
> 
> If it isn't a change, I'd like to propose that we set the fix version 
> to
> 4.2.0 at a minimum.  Pending the outcome of this discussion thread, perhaps 
> it will be closed with "won't fix", or perhaps it gets fixed.
> [Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in 
> both . It is definitely an API bug which needs to be fixed as admin account 
> should not be allowed to be deleted . Moreover from the UI perspective , I 
> need a condition to distinguish between the two types of users to showcase 
> delete options on the UI accordingly.
>  
> 
> If it *is* a change, can we implement a fix that restores past behaviour as a 
> first step?
> [Pranav] - I believe , it should be a "demanding" change if at all 4.0 is 
> also having a similar behavior ( which I am not sure of right now) since 
> conceptually and technically we should not be following the current behavior 
> in any version .

As far as 4.1.0 goes, I'd like to release without this change...  unless we 
know that it behaved more appropriately in 4.0.0.

Thoughts?

Re: [DIscuss]Storage image store plugin framework refactoring

[Chiradeep Vittal]

We can have alias for an existing API. See the other ML discussion.

On 4/9/13 9:27 AM, "Min Chen"  wrote:

>Yes, I will include more api change details in FS in next few days.
>According to Chiradeep, it seems that we cannot simply deprecate old API
>in 4.2, Edison and I will discuss this and update FS with details on how
>to handle these old APIs.
>
>Thanks
>-min
>
>On 4/8/13 6:34 PM, "Sangeetha Hariharan" 
>wrote:
>
>>Min,
>>
>>Could you also include the details of the API changes (new parameters)
>>that will be proposed as part of this feature?
>>Also it would be helpful if you list the request and response parameters
>>for the new API calls.
>>For all the API calls that are being deprecated , is there any specific
>>error message that will be returned?
>>
>>-Thanks
>>Sangeetha 
>>
>>-Original Message-
>>From: Min Chen [mailto:min.c...@citrix.com]
>>Sent: Monday, April 08, 2013 4:45 PM
>>To: dev@cloudstack.apache.org
>>Subject: [DIscuss]Storage image store plugin framework refactoring
>>
>>Hi All,
>>
>>Currently CloudStack does not offer a flexible pluggable framework for
>>users to easily integrate and configure any 3rd-party object stores for
>>such backup services as registering templates, taking snapshots, etc.
>>Along with Edison's recent refactored storage subsystem 2.0 that mainly
>>refactored current CloudStack primary storage implementation,  we are
>>proposing to develop a storage backup object store plugin framework to
>>allow CloudStack to systematically manage and configure various types of
>>backup data stores from different vendors, like NFS, S3, Swift, etc. With
>>this new plugin framework, we would like to achieve following
>>functionalities:
>>1. Support different object store providers in a uniform and pluggable
>>fashion.
>>2. Enable region wide object backup using S3-like object store.
>>3. Provide pluggable data motion strategies to handle data transfer from
>>one data store to another data store.
>>4. Provide a scalable cache storage framework while moving data between
>>primary storage and backup storage for certain hypervisor needs.
>>5. Support flexible combinations of primary storage, secondary storage
>>and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware), (ISCSI,
>>Swift, KVM), , etc.
>>The proposed ImageStore plugin framework architecture is detailed in our
>>FS here: 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Obj
>>e
>>ct+Store+Plugin+Framework.
>>The JIRA ticket to track this feature is:
>>https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
>>currently carried out in feature branch  "object_store".
>>Please let me know your comments and suggestions.
>>
>>Thanks
>>-min
>>
>>
>

RE: Error on Master - systemvms not coming up

[Pranav Saxena]

Well , let us know whatever the issue is .  If you are able to solve it soon , 
you can share what the problem was :)

-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com] 
Sent: Tuesday, April 09, 2013 10:42 PM
To: dev@cloudstack.apache.org
Subject: Re: Error on Master - systemvms not coming up

Did clean up my primary as well. Master is not latest but I think there is 
something peculiar going on here and yeah I don't think everyone must be facing 
this.

On 09/04/13 7:52 PM, "Pranav Saxena"  wrote:

>
>Did you try clearing up host tags and stale images on your primary 
>storage  . Try doing this perhaps through the xencenter or the xe 
>command line. I installed latest master today in the afternoon and its 
>working fine for me
>
>Thanks,
>Pranav
>
>-Original Message-
>From: Nitin Mehta [mailto:nitin.me...@citrix.com]
>Sent: Tuesday, April 09, 2013 7:35 PM
>To: dev@cloudstack.apache.org
>Subject: Error on Master - systemvms not coming up
>
>Using master branch, 6.0 XS and my system vms are not coming up. I am 
>getting the following error but unable to find the root cause of it.
>
>Smlog, xensource log and MS log do not seem to say more than this info. 
>I have tried to verify the sec. storage, reinstalled the XS host and 
>restarted the xapi service with no respite.
>I have systemvm.iso and vhd-util on this XS.
>
>
>2013-04-09 19:24:37,224 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) VLAN is created for 30.  The uuid is
>a751bba8-d5a8-98f3-7713-290d8652cfe6
>2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif 
>a700f78b-3270-814e-c014-f1c2f987bb0b
>on 2
>2013-04-09 19:24:37,314 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
>[Nic:Control-169.254.2.56-null]
>2013-04-09 19:24:37,638 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) already have a vif on dom0 for link local network
>2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif 
>6b66cff0-805e-7dd3-d211-2add2e1786f9
>on 0
>2013-04-09 19:24:38,053 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
>[Nic:Management-10.147.28.158-null]
>2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif 
>a1189522-add6-6489-fd4a-c43a40ab104a
>on 1
>2013-04-09 19:24:38,252 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Creating VIF for s-5-VM on nic 
>[Nic:Storage-10.147.28.153-null]
>2013-04-09 19:24:38,451 DEBUG [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Created a vif 
>cb21b21c-b1f7-729c-52f0-85677d75a75d
>on 3
>2013-04-09 19:24:41,731 WARN  [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Task failed! Task record: uuid:
>2428b55e-1cd0-0ce1-b20b-16734f551401
>   nameLabel: Async.VM.start_on
> nameDescription:
>   allowedOperations: []
>   currentOperations: {}
> created: Tue Apr 09 19:35:52 GMT+05:30 2013
>finished: Tue Apr 09 19:35:54 GMT+05:30 2013
>  status: failure
>  residentOn: com.xensource.xenapi.Host@f55a038a
>progress: 1.0
>type: 
>  result:
>   errorInfo: [Traceback (most recent call last):,   File
>"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file,
>part_offs[0], bootfsoptions), IOError: [Errno 95] Operation not 
>supported, ]
> otherConfig: {}
>   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
>subtasks: []
>
>2013-04-09 19:24:41,771 WARN  [xen.resource.CitrixResourceBase]
>(DirectAgent-13:null) Unable to start VM(s-5-VM) on
>host(6fcb5a41-8ec2-40ee-857d-af6f4b8c39fc) due to Task failed! Task
>record: uuid: 2428b55e-1cd0-0ce1-b20b-16734f551401
>   nameLabel: Async.VM.start_on
> nameDescription:
>   allowedOperations: []
>   currentOperations: {}
> created: Tue Apr 09 19:35:52 GMT+05:30 2013
>finished: Tue Apr 09 19:35:54 GMT+05:30 2013
>  status: failure
>  residentOn: com.xensource.xenapi.Host@f55a038a
>progress: 1.0
>type: 
>  result:
>   errorInfo: [Traceback (most recent call last):,   File
>"/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file,
>part_offs[0], bootfsoptions), IOError: [Errno 95] Operation not 
>supported, ]
> otherConfig: {}
>   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
>subtasks: []
>
>Task failed! Task record: uuid:
>2428b55e-1cd0-0ce1-b20b-16734f551401

Re: Error on Master - systemvms not coming up

[Chiradeep Vittal]

I googled the string below and got several hits.

On 4/9/13 10:16 AM, "Pranav Saxena"  wrote:

>IOError: [Errno 95] Operation not
>supported, ]

Re: [DISCUSS] - Deletion of Users within the Admin account

[Chip Childers]

On Tue, Apr 09, 2013 at 05:12:58PM +, Pranav Saxena wrote:
> If you think that the admin should not have the flexibility to delete a user 
> within the admin account from the UI ( one has to use the API's to do such 
> tasks then) , we can go ahead without this change for 4.1  and incorporate 
> this change for 4.2 .
> 

I'm actually trying to understand if this is a *feature change*,
regardless of whether we want it to behave this way or not.  Make sense?

> Thanks,
> Pranav
> 
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com] 
> Sent: Tuesday, April 09, 2013 10:34 PM
> To: dev@cloudstack.apache.org
> Cc: Alena Prokharchyk
> Subject: Re: [DISCUSS] - Deletion of Users within the Admin account
> 
> On Tue, Apr 09, 2013 at 04:53:38PM +, Pranav Saxena wrote:
> > Is the current state of 4.1 and master a change in behaviour from 4.0.0?
> > [Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be 
> > exactly the same . 
> > 
> > If it isn't a change, I'd like to propose that we set the fix version 
> > to
> > 4.2.0 at a minimum.  Pending the outcome of this discussion thread, perhaps 
> > it will be closed with "won't fix", or perhaps it gets fixed.
> > [Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in 
> > both . It is definitely an API bug which needs to be fixed as admin account 
> > should not be allowed to be deleted . Moreover from the UI perspective , I 
> > need a condition to distinguish between the two types of users to showcase 
> > delete options on the UI accordingly.
> >  
> > 
> > If it *is* a change, can we implement a fix that restores past behaviour as 
> > a first step?
> > [Pranav] - I believe , it should be a "demanding" change if at all 4.0 is 
> > also having a similar behavior ( which I am not sure of right now) since 
> > conceptually and technically we should not be following the current 
> > behavior in any version .
> 
> As far as 4.1.0 goes, I'd like to release without this change...  unless we 
> know that it behaved more appropriately in 4.0.0.
> 
> Thoughts?
> 

Review Request: CLOUDSTACK-704. Dedicate Public IP addresses to an account

[Likitha Shetty]

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

Review request for cloudstack.


Summary (updated)
-

CLOUDSTACK-704. Dedicate Public IP addresses to an account


Description (updated)
---

Feature to dedicate a range Public IP addresses to an account.


This addresses bug CLOUDSTACK-704.


Diffs (updated)
-

  api/src/com/cloud/configuration/ConfigurationService.java e63fcec 
  api/src/com/cloud/event/EventTypes.java 5671f99 
  
api/src/org/apache/cloudstack/api/command/admin/vlan/DedicatePublicIpRangeCmd.java
 PRE-CREATION 
  
api/src/org/apache/cloudstack/api/command/admin/vlan/ReleasePublicIpRangeCmd.java
 PRE-CREATION 
  client/tomcatconf/commands.properties.in 163c2ce 
  server/src/com/cloud/configuration/ConfigurationManager.java 20e9884 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 1526fb0 
  server/src/com/cloud/network/NetworkManagerImpl.java 6296011 
  server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
  server/src/com/cloud/server/ManagementServerImpl.java af77ba5 
  server/src/com/cloud/user/AccountManagerImpl.java 9736aa1 
  server/test/com/cloud/configuration/ConfigurationManagerTest.java 
PRE-CREATION 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java d96e831 
  test/integration/component/test_public_ip_range.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py f3370eb 

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


Testing
---


Thanks,

Likitha Shetty

Re: Error on Master - systemvms not coming up

[Chiradeep Vittal]

My guess is that your sysvms are corrupted.

On 4/9/13 10:18 AM, "Chiradeep Vittal"  wrote:

>I googled the string below and got several hits.
>
>On 4/9/13 10:16 AM, "Pranav Saxena"  wrote:
>
>>IOError: [Errno 95] Operation not
>>supported, ]
>

Re: Network architecture question

[Chiradeep Vittal]

You can do bonded nics in basic zone. The limitation with basic zone is
that the Vms cannot have multiple nics. Did you need multiple nics for
your vms?
If you need advanced network services such as static NAT and load
balancing, advanced networking is probably your best bet (currently,
unless you want to invest in a Netscaler for these services).

Not sure that VXLAN will solve your problems since that has scaling
problems as well. On vSphere an NX1000v DVS can only handle about 64
hypervisors IIRC.



On 4/9/13 5:39 AM, "Justin Grudzien"  wrote:

>We have 2 pairs of bonded 10g nics on each box. Wouldn't that require an
>advanced network? Is it possible to do the security groups with small L2
>networks in advanced networking?
>
>Justin 
>
>Sent from my iPhone
>
>On Apr 9, 2013, at 12:38 AM, Chiradeep Vittal
> wrote:
>
>> Have you considered using a basic zone?
>> With security groups you can have *lots* (thousands of) with very small
>>L2
>> networks.
>> 
>> On 4/8/13 10:28 PM, "Justin Grudzien"  wrote:
>> 
>>> My team has been working for three weeks with CloudStack architecture
>>> design and we are struggling to put together a network architecture
>>>that
>>> we feel will scale. From everything I can tell, CloudStack requires a a
>>> very large layer 2 network when using shared guest networks. We are
>>> looking to deploy almost a thousand physical hosts across 25 cabinets
>>> with over 4000 VMs in the next 18 months and having a broadcast domain
>>> this large feels problematic.
>>> 
>>> How have others solved this problem? I don't have a need or a desire
>>>for
>>> isolation and even if I had 100 guest networks I would still have to
>>>tag
>>> their VLANs into every host port. There doesn't seem to be a way to
>>>tie a
>>> network to anything smaller than a zone.
>>> 
>>> One solution we are looking into is Cisco's 1000v and utilizing VXLANs.
>>> This will allow us scale down the broadcast domains. I don't think
>>> CloudStack has support in configuring their VXLAN settings? Any
>>>comments
>>> or suggestions would be appreciated.
>>> 
>>> Justin
>> 

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 12:12 PM, Alena Prokharchyk wrote:
> I don't think it was ever a part of the Jenkins build process. I used to
> generate the diff locally on my machine by feeding the old and new
> version commands.xml files to the script.

Sorry, which script?

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 12:05 PM, Chiradeep Vittal wrote:
> I believe this was never automated.
> The apidocs generation tool generates an XML document that contains all
> the APIs.
> (tools/apidoc/target/commands.xml). We can diff the 4.0 xml and the 4.1
> xml using a tool such as xmldiff (https://pypi.python.org/pypi/xmldiff).

This is helpful, thanks!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DIscuss]Storage image store plugin framework refactoring

[Min Chen]

It may not be that simple to just use api name alias. For example, we
currently have listS3sCmd, with new image store plugin framework, we
introduced a new API "listImageStoresCmd" to cover image stores from
various providers, not only S3. We also introduced a new response
ImageStoreResponse for this new listImageStoreCmd api. So you are
suggesting to use the following naming alias to direct old apis to the new
apis, right?

@APICommand(name = "listImageStores, listS3s, listSwift", ..


But there are two issues here:
1. Previous listS3sCmd api is corresponding to new API
listImageStores&provider=S3, so this will not be a simple redirect.
2. Previous listS3sCmd response is S3Response, which is different from new
ImageStoreResponse, although its information can be found in new
ImageStoreResponse. Will this break back compatibility as well?

Thanks
-min


On 4/9/13 10:14 AM, "Chiradeep Vittal"  wrote:

>We can have alias for an existing API. See the other ML discussion.
>
>On 4/9/13 9:27 AM, "Min Chen"  wrote:
>
>>Yes, I will include more api change details in FS in next few days.
>>According to Chiradeep, it seems that we cannot simply deprecate old API
>>in 4.2, Edison and I will discuss this and update FS with details on how
>>to handle these old APIs.
>>
>>Thanks
>>-min
>>
>>On 4/8/13 6:34 PM, "Sangeetha Hariharan" 
>>wrote:
>>
>>>Min,
>>>
>>>Could you also include the details of the API changes (new parameters)
>>>that will be proposed as part of this feature?
>>>Also it would be helpful if you list the request and response parameters
>>>for the new API calls.
>>>For all the API calls that are being deprecated , is there any specific
>>>error message that will be returned?
>>>
>>>-Thanks
>>>Sangeetha 
>>>
>>>-Original Message-
>>>From: Min Chen [mailto:min.c...@citrix.com]
>>>Sent: Monday, April 08, 2013 4:45 PM
>>>To: dev@cloudstack.apache.org
>>>Subject: [DIscuss]Storage image store plugin framework refactoring
>>>
>>>Hi All,
>>>
>>>Currently CloudStack does not offer a flexible pluggable framework for
>>>users to easily integrate and configure any 3rd-party object stores for
>>>such backup services as registering templates, taking snapshots, etc.
>>>Along with Edison's recent refactored storage subsystem 2.0 that mainly
>>>refactored current CloudStack primary storage implementation,  we are
>>>proposing to develop a storage backup object store plugin framework to
>>>allow CloudStack to systematically manage and configure various types of
>>>backup data stores from different vendors, like NFS, S3, Swift, etc.
>>>With
>>>this new plugin framework, we would like to achieve following
>>>functionalities:
>>>1. Support different object store providers in a uniform and pluggable
>>>fashion.
>>>2. Enable region wide object backup using S3-like object store.
>>>3. Provide pluggable data motion strategies to handle data transfer from
>>>one data store to another data store.
>>>4. Provide a scalable cache storage framework while moving data between
>>>primary storage and backup storage for certain hypervisor needs.
>>>5. Support flexible combinations of primary storage, secondary storage
>>>and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware), (ISCSI,
>>>Swift, KVM), , etc.
>>>The proposed ImageStore plugin framework architecture is detailed in our
>>>FS here: 
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Ob
>>>j
>>>e
>>>ct+Store+Plugin+Framework.
>>>The JIRA ticket to track this feature is:
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
>>>currently carried out in feature branch  "object_store".
>>>Please let me know your comments and suggestions.
>>>
>>>Thanks
>>>-min
>>>
>>>
>>
>

RE: [DISCUSS] - Deletion of Users within the Admin account

[Pranav Saxena]

More of a modification of an existing functionality  . Probably a new feature 
in a sense by giving flexibility to the admin to delete users from the UI 
within the admin account.

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, April 09, 2013 10:50 PM
To: dev@cloudstack.apache.org
Cc: Alena Prokharchyk
Subject: Re: [DISCUSS] - Deletion of Users within the Admin account

On Tue, Apr 09, 2013 at 05:12:58PM +, Pranav Saxena wrote:
> If you think that the admin should not have the flexibility to delete a user 
> within the admin account from the UI ( one has to use the API's to do such 
> tasks then) , we can go ahead without this change for 4.1  and incorporate 
> this change for 4.2 .
> 

I'm actually trying to understand if this is a *feature change*, regardless of 
whether we want it to behave this way or not.  Make sense?

> Thanks,
> Pranav
> 
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, April 09, 2013 10:34 PM
> To: dev@cloudstack.apache.org
> Cc: Alena Prokharchyk
> Subject: Re: [DISCUSS] - Deletion of Users within the Admin account
> 
> On Tue, Apr 09, 2013 at 04:53:38PM +, Pranav Saxena wrote:
> > Is the current state of 4.1 and master a change in behaviour from 4.0.0?
> > [Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be 
> > exactly the same . 
> > 
> > If it isn't a change, I'd like to propose that we set the fix 
> > version to
> > 4.2.0 at a minimum.  Pending the outcome of this discussion thread, perhaps 
> > it will be closed with "won't fix", or perhaps it gets fixed.
> > [Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in 
> > both . It is definitely an API bug which needs to be fixed as admin account 
> > should not be allowed to be deleted . Moreover from the UI perspective , I 
> > need a condition to distinguish between the two types of users to showcase 
> > delete options on the UI accordingly.
> >  
> > 
> > If it *is* a change, can we implement a fix that restores past behaviour as 
> > a first step?
> > [Pranav] - I believe , it should be a "demanding" change if at all 4.0 is 
> > also having a similar behavior ( which I am not sure of right now) since 
> > conceptually and technically we should not be following the current 
> > behavior in any version .
> 
> As far as 4.1.0 goes, I'd like to release without this change...  unless we 
> know that it behaved more appropriately in 4.0.0.
> 
> Thoughts?
> 

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Alena Prokharchyk]

Joe, here is the file:

./server/src/com/cloud/api/doc/ApiXmlDocReader.java


I used to run it this way:

Java -cp  com.cloud.api.doc.ApiXmlDocReader -old  -new  -d 


-Alena.


On 4/9/13 10:27 AM, "Joe Brockmeier"  wrote:

>On Tue, Apr 9, 2013, at 12:12 PM, Alena Prokharchyk wrote:
>> I don't think it was ever a part of the Jenkins build process. I used to
>> generate the diff locally on my machine by feeding the old and new
>> version commands.xml files to the script.
>
>Sorry, which script?
>
>Best,
>
>jzb
>-- 
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/
>

Review Request: CLOUDSTACK-1517 - fix resource file for pt_BR (Portuguese Brazil). Remove bad encoded chars, convert into ASCII with unicode chars, sort keys

[Milamber ASF]

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

Review request for cloudstack and Sebastien Goasguen.


Description
---

CLOUDSTACK-1517 - fix resource file for pt_BR (Portuguese Brazil). Remove bad 
encoded chars, convert into ASCII with unicode chars, sort keys


This addresses bug CLOUDSTACK-1517.


Diffs
-

  client/WEB-INF/classes/resources/messages_pt_BR.properties fdd8154 

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


Testing
---


Thanks,

Milamber ASF

Re: [DISCUSS] - Deletion of Users within the Admin account

[Chip Childers]

On Tue, Apr 09, 2013 at 05:33:28PM +, Pranav Saxena wrote:
> More of a modification of an existing functionality  . Probably a new feature 
> in a sense by giving flexibility to the admin to delete users from the UI 
> within the admin account.

Good clarification!

OK, so I'm going to move this to a fix-version of 4.2 (but we could
consider releasing a fix within a 4.1.1 bug-fix release).  If someone
strongly disagrees, now's the time to shout.

RE: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules"

[Prachi Damle]

Comments Inline.

Thanks,
Prachi
-Original Message-
From: prasanna [mailto:srivatsav.prasa...@gmail.com] On Behalf Of Prasanna 
Santhanam
Sent: Monday, April 08, 2013 11:17 PM
To: dev@cloudstack.apache.org
Subject: Re: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules"

On Mon, Apr 08, 2013 at 01:56:55PM -0700, Prachi Damle wrote:
> Prasanna,
> Affinity Group Processing is a pre-planning step. It will set the 
> scope for the deployment planners, there is no conflict between the 
> planner strategies and affinity groups. These are separate steps of 
> deployment planning.

My only confusion stems from the fact that we have two steps that do the same 
thing - pre-planning by affinty/anti-affinity rules and the deployment planning 
that does the same using concentration/dispersion.
The only difference being the latter is in the control of the administrator. 
And if I enable vm-host, vm-vm affinity rules on my vmware cluster [1], say, 
then that's another layer of filtering to make placement decisions. Other 
providers [2] use affinity rules to place vms in the same physical group (pod, 
cluster, storage) to help with costs, latency etc which cloudstack can do using 
tags (more confusion for end users).

>> They are not doing the same thing. As mentioned in the FS, Affinity is a way 
>> to specify user preference Vs deployment planners are admin decided 
>> heuristics to order the available set of resources. Planners are not visible 
>> to the user. Also setting tags on backend and using them in service offering 
>> is not in the hands of a user. There is no way for a user to let us know any 
>> deployment preference. Affinity Groups is one way of facilitating that.
Affinity groups just narrows down the scope of searching the required 
resources. And under the given scope(a zone or a pod or a cluster etc) a 
planner will try to order the rest of the resources based on the heuristics 
admin wants. Thus Affinity is just modifying the input of the planners and not 
conflicting with any  planner algorithm.


OTOH, I think that the pluginizing of the deployment planner steps in this 
feature is useful. But beyond the placement decisions on host, storage what 
other kind of placement planning can exploit this plugin?
[1] http://s.apache.org/FQU
[2] http://s.apache.org/CSs

>> Again its letting user provide a preference Vs admin deciding- Host 
>> anti-affinity plugin in this feature is letting user set a relation between 
>> VMs - it is not choosing any particular host or pool, just lets CS know that 
>> keep this set of VMs on different hosts. 

--
Prasanna.,

Re: [DISCUSS] - Deletion of Users within the Admin account

[Alena Prokharchyk]

Chip, 

1) "System" user is always identified by the cloud.user DB id=1 (hardcoded
in User.java interface). This user is never exposed via API, you can't
remove it - the checks are already in place for it.

2) For users of "admin" account, currently there is no direct way to tell
if the user was added by the system, or using API call. We can't rely on
name "admin" as it's not reserved name and renaming is also allowed.

I think for upgrade we can rely on the cloud.user db id - expect it to be
"system_user_db_id + 1" as we know that 2 users come with the default
cloudStack install.


-Alena.



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

>On Tue, Apr 09, 2013 at 09:56:37AM -0700, Alena Prokharchyk wrote:
>> We should allow to delete any CS users except for ones that came as a
>>part
>> of cloudStack installation ("system" and "admin" users). The users
>>you've
>> created using API, should be allowed to be removed no matter of their
>> types.
>
>+1 to this in general terms.  Not sure about requiring a change like
>this for 4.1.0 though.
>
>> 
>> The right way to distinguish between system generated users, and users
>> created using APIs would be introducing the flag in the cloud.users DB.
>
>Do you have any thoughts on how we would correctly identify these
>account in existing installs?
>
>

RE: Documentation How-To

[Radhika Puthiyetath]

I am not getting enough feedback when I shared the PDF off-list, after 
committing the draft files to the  Master.

So, I reverted the entire stuff and submitted as a patch so that the patch 
might get more attention from a wider audience :-)  Last attempt/ trick to get 
the review comments...

-Original Message-
From: Joe Brockmeier [mailto:j...@zonker.net] 
Sent: Tuesday, April 09, 2013 9:59 PM
To: dev@cloudstack.apache.org
Subject: Re: Documentation How-To

On Tue, Apr 9, 2013, at 11:02 AM, Radhika Puthiyetath wrote:
> I cannot attach the PDF while replying to dev list. So I offered to 
> send it off -list.
> 
> The doc was initially checked in to the repo after completing the draft.
> Only Ilya, who tested it,  has provided initial comments on them.
> 
> I had many questions, which I posted on the ML, but none was answered.
> 
> Since the feature owner hasn't reviewed, I had to *revert* the commit 
> (commit 8a435f5b43bb013b73875ba4b8cf4a0b537036d4)
> and submit a patch on the Review Board so that the doc will reach to 
> larger audience.
> 
> Correct me if I am wrong.

It sounds like you're Doing It Right, but I'd recommend pointing Jason (or 
others) to the review board patch rather than sending a PDF. 

It looks like this was only in master - any reason why you reverted the commit 
rather than just continuing to make modifications? Just curious.
Seems like that would be more work for you. 

Best,

jzb
--
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Error on Master - systemvms not coming up

[Nitin Mehta]

Thanks Chiradeep. Googling didn't point at any specific directions and I
had replaced the system template as well (on primary and secondary) but to
no respite. 
Maybe I am missing something fundamental. Will sleep a while and see if
tomorrow is going to be a better day :).

On 09/04/13 10:50 PM, "Chiradeep Vittal" 
wrote:

>My guess is that your sysvms are corrupted.
>
>On 4/9/13 10:18 AM, "Chiradeep Vittal" 
>wrote:
>
>>I googled the string below and got several hits.
>>
>>On 4/9/13 10:16 AM, "Pranav Saxena"  wrote:
>>
>>>IOError: [Errno 95] Operation not
>>>supported, ]
>>
>

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Joe Brockmeier]

Hi Alena, 

On Tue, Apr 9, 2013, at 12:36 PM, Alena Prokharchyk wrote:
> Joe, here is the file:
> 
> ./server/src/com/cloud/api/doc/ApiXmlDocReader.java
> 
> 
> I used to run it this way:
> 
> Java -cp  com.cloud.api.doc.ApiXmlDocReader -old  old xml file> -new  -d 

Thanks! I will give that a shot. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

RE: Documentation How-To

[Radhika Puthiyetath]

Jason, I have already sent the PDF. The patch is on the review board.

Please help me with suggestions/ reviews.

Many thanks, I was so worried that I am not getting much help ...

-Radhika

-Original Message-
From: Jason Cadmus [mailto:jdcad...@gmail.com] 
Sent: Tuesday, April 09, 2013 10:29 PM
To: dev@cloudstack.apache.org
Subject: Re: Documentation How-To

I would like to see the draft


On Tue, Apr 9, 2013 at 11:29 AM, Radhika Puthiyetath < 
radhika.puthiyet...@citrix.com> wrote:

> Hi Jason,
>
> The doc has been under review for a long time;  however, I can share 
> you the draft with you off-list.
>
> I am not sure whatever I have documented is perfect as the feature 
> owner hasn't reviewed it yet.
>
> Regards
>
> -Radhika
>
> -Original Message-
> From: Jason Cadmus [mailto:jdcad...@gmail.com]
> Sent: Tuesday, April 09, 2013 8:42 PM
> To: dev@cloudstack.apache.org
> Subject: Documentation How-To
>
> I am working on installing/testing/documenting CS 4.10 on vSphere 5.1 
> using vDistributed Switching with CS advanced networking. Can someone 
> please give me some insight on the proper way to contribute to CS 
> formal documentation?
>
> --
> Thanks,
> JC
>



--
Thanks,
JC

Re: [ACS41][DOCS] Generate diff of APIs changed/added/deleted?

[Rohit Yadav]

In cloudmonkey I can enable the diffing and outputting when sync is done
(something like git), so when you do a sync, it can tell you stats like how
many new apis were discovered (difference of set of APIs before and after)
etc. Do we want such a feature?

Cheers.

On Tue, Apr 9, 2013 at 11:14 PM, Joe Brockmeier  wrote:

> Hi Alena,
>
> On Tue, Apr 9, 2013, at 12:36 PM, Alena Prokharchyk wrote:
> > Joe, here is the file:
> >
> > ./server/src/com/cloud/api/doc/ApiXmlDocReader.java
> >
> >
> > I used to run it this way:
> >
> > Java -cp  com.cloud.api.doc.ApiXmlDocReader -old  > old xml file> -new  -d 
>
> Thanks! I will give that a shot.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>

Re: [DISCUSS] pause VM

[Kelven Yang]

On 4/8/13 7:11 PM, "Marcus Sorensen"  wrote:

>Perhaps. I think there are separate issues here. There is volume snapshot
>and vm snapshot. If the hypervisor is capable of making volumes consistent
>, but VM snapshot is more about saving running state, then the two may not
>serve the same purpose when leveraging san-based snapshots. Its absolutely
>possible to pause the VM, quiesce the disks, and then snapshot them
>consistently utilizing underlying storage capabilities.
>
>But we are getting off in the weeds here with a single example, when what
>I
>want to discuss is pausing a VM in general.

For a general pause-VM feature, I agree that we probably need it for some
use cases, just not so convinced that we need it in any urgency, and the
use case of using it to cover application level data integrity issue may
mislead users.

Let's see if there are more opinions in the community about this, adding a
new VM state actually involves some work in Sync, resource allocation
areas, that's the reason I'm cautious to ask about the real
mandatory/valid use case for this feature.

-Kelven

>On Apr 8, 2013 6:19 PM, "Kelven Yang"  wrote:
>
>>
>>
>> On 4/8/13 4:19 PM, "Marcus Sorensen"  wrote:
>>
>> >Oh yes, I know these things, but here's my point. You said:
>> >
>> >"When CloudStack takes a snapshot of volume, it already utilizes
>>snapshot
>> >feature provided by hypervisor to allow taking point of time storage
>>image
>> >in a safe manner from operating system point of view."
>> >
>> >What about five volumes? Can we ensure they are all snapshotted at that
>> >same point in time without also pausing the VM, in addition to using
>>those
>> >hypervisor-provided features?  For example, let's say the VM is using a
>> >volume manager and striping data across five data disks, we absolutely
>> >have
>> >to take all data disk snapshots at the same point in such a scenario.
>>We
>> >of
>> >course have to rely on the user to tell us that they want this, but we
>> >should have the capability.
>> >
>> >If we already have a VM snapshot feature that does every connected disk
>> >simultaneously while the VM is suspended, or the hypervisor can do it
>>for
>> >us by quickly pausing/snapshotting/resuming seamlessly then fine,
>>that's
>> >great. It just didn't seem like that functionality existed now, so I
>>was
>> >wondering if anyone is working on it.
>>
>> I'm not sure using the tactic to pause a VM for the purpose of ensuring
>> full data integrity is the right answer for the use case you pointed. As
>> far as I know for VMware hypervisors, taking a VM snapshot does all the
>> things your mentioned above (quiesce the guest file system, snapshot
>> memory etc). Xen Server may be a little different, for crash
>>consistency,
>> I think we ask user to stop a VM(instead of pausing it) before taking a
>> volume snapshot.
>>
>> So the question is, can "pausing VM" offer what we are looking for or is
>> it a half-completed solution? Forcely-pausing a VM to offer a not
>>ensured
>> solution to customer is what I'm worrying about.
>>
>> -Kelven
>>
>> >
>> >That aside, it seems like all of the hypervisors CS controls provide
>>their
>> >own UI to pause a VM. Is it something that has been discussed?
>> >
>> >
>> >
>> >
>> >On Mon, Apr 8, 2013 at 4:16 PM, Kelven Yang 
>> >wrote:
>> >
>> >>
>> >>
>> >> On 4/8/13 1:39 PM, "Marcus Sorensen"  wrote:
>> >>
>> >> >Has anyone put together a suggestion for adding a 'paused' state to
>> >> >virtual
>> >> >machines? Or is anyone working on it? This seems fairly
>> >>straightforward,
>> >> >and I think we may need the functionality going forward. Even if
>>people
>> >> >rarely use it themselves, if storage solutions are going to offer
>> >> >snapshots
>> >> >they may want to pause the VM in order to get an atomic snapshot if
>> >>the VM
>> >> >has multiple disks. So at least internally it may be a useful
>>utility.
>> >>
>> >> Pause VM itself can not ensure data integrity. True data integrity
>>can't
>> >> be ensured without participant of guest OS and related application
>>(for
>> >> example, Microsoft offers Volume Shadow Copy Service to orchestrate
>>and
>> >> allow applications to participate the process via a set of tools and
>>API
>> >> interaction to achieve that).
>> >>
>> >> When CloudStack takes a snapshot of volume, it already utilizes
>>snapshot
>> >> feature provided by hypervisor to allow taking point of time storage
>> >>image
>> >> in a safe manner from operating system point of view. The ability of
>> >> pausing VM is not mandatory in this case, although pausing/resuming
>>VM
>> >>may
>> >> be useful in certain use case, it does not seem to be in any urgency
>>or
>> >> fit naturally in general cloud-operations.
>> >>
>> >> -Kelven
>> >>
>> >> >
>> >>
>> >>
>>
>>

Re: [Discuss] API name alias

[Chiradeep Vittal]

In Kishan's case he is adding a better, accurate name for the API. The API
was misnamed in the previous version (ACL = Access Control List, but ACL
was referring to an individual item within the list). Similarly, there are
other poorly worded APIs (createIpForwardingRule instead of
createStaticNat comes to mind).

On 4/9/13 2:19 AM, "Rohit Yadav"  wrote:

>On Tue, Apr 9, 2013 at 12:04 PM, Chiradeep Vittal <
>chiradeep.vit...@citrix.com> wrote:
>
>> Rohit, that's like saying we won't fix a leaky faucet today because
>>we're
>> moving in a couple of years anyway. It isn't a big deal to add this and
>>it
>> clarifies to the end user what is the correct alias to use.
>>
>
>Chiradeep, if there are multiple apinames for the same operation (cmd
>class) where does the question of "correct alias to use" come?
>
>Excuse my ignorance, I don't understand why we need "preferred" and
>"deprecated" fields in that respect. IMO it won't solve any problem but
>add
>confusion and ambiguity, unless there is some use you may explain?
>
>As Kishan shares, he would use the array styled approach which John
>suggested and I think it should work, why we want preferred and deprecated
>Strings or String[].
>
>Cheers.
>
>
>> On 4/8/13 9:52 PM, "Rohit Yadav"  wrote:
>>
>> >If we are still on our previously discussed plan (search a wiki shared
>>by
>> >Min) on deprecating the whole query based API (Server), it's just
>> >unnecessary work on present APIs. I think for now just changing the
>>name
>> >attribute type from String to String[] would just work, as John
>>suggested.
>> >
>> >Adding other fields, may not hold much use for now. Except for few of
>>them
>> >the rest of 300 apis will have preferred == current apiname and
>>deprecated
>> >as blank string.
>> >
>> >I think we should just deprecated all cmd classes (query based) over a
>> >long
>> >period say 1 or 2 years, and/or find a way to rewrite/refactor them so
>>as
>> >to reuse them with our new rest based API server for future.
>> >
>> >Cheers.
>> >
>> >On Tue, Apr 9, 2013 at 3:18 AM, Chiradeep Vittal <
>> >chiradeep.vit...@citrix.com> wrote:
>> >
>> >>
>> >>
>> >> On 4/8/13 11:18 AM, "Rohit Yadav"  wrote:
>> >>
>> >> >On Mon, Apr 8, 2013 at 7:10 PM, John Burwell 
>> >>wrote:
>> >> >
>> >> >> Rohit,
>> >> >>
>> >> >> Why would we need to rewrite any Java code to switch to an array?
>> >>As I
>> >> >> mentioned, array annotation values are treated as varargs.
>> >>Therefore,
>> >> >> annotations with single values can be left alone.  Only cases
>>where
>> >> >> multiple values are required would require the addition of curly
>> >>braces.
>> >> >>  For example, for an APICommand with one name, the following would
>> >> >>continue
>> >> >> to work:
>> >> >>
>> >> >
>> >> >Hey John, you're right but it's a matter of code styling, I prefer
>> >> >writing;
>> >> >
>> >> >@APICommand(name = {'name1'}) even if it's only one name, this way
>>any
>> >> >subsequent api author would know that name is an array and they can
>> >>have
>> >> >aliases which is what Kishan wants.
>> >> >
>> >> >
>> >> >>
>> >> >> @APICommand(name="apiName1")
>> >> >>
>> >> >> While for an APICommand with multiple names, the following form
>>would
>> >> >>now
>> >> >> be supported:
>> >> >>
>> >> >> @APICommand(name={"apiName1", "apiName2", "apiName3"})
>> >> >>
>> >> >> I am not familiar with the Marvin code, so I can not speak to the
>> >>impact
>> >> >> of this change to it.  However, the only changes to the Java code
>> >> >>should be
>> >> >> the API commands with multiple names and the classes that actually
>> >> >>consume
>> >> >> the value of this annotation.
>> >> >>
>> >> >
>> >> >Yes, you're right we can skip the code styling I referred then it
>>won't
>> >> >consume much coding, we just need to fix these;
>> >> >
>> >> >- Fix APICommand annotation interface definition to accept name as
>>an
>> >> >array
>> >> >- Fix method in ApiServer which creates apiname->cmdclass map to
>>care
>> >>for
>> >> >aliases
>> >> >- Fix ApiDiscovery to take care of the aliases (create different
>> >>response
>> >> >objs for the same cmd class)
>> >> >- Fix apidocs XmlWriter class to take of the aliases and the api
>>html
>> >> >generator to process the same.
>> >> >- Fix Marvin's codegenerator.py to take care of the aliases (which
>> >>means
>> >> >create apiname related modules which would contain cmd and response
>> >> >boilterplate fields/class)
>> >> >
>> >> >Cheers.
>> >> >
>> >> >
>> >> >>
>> >> >> Thanks,
>> >> >> -John
>> >> >>
>> >> >> On Apr 8, 2013, at 9:22 AM, Rohit Yadav 
>>wrote:
>> >> >>
>> >> >> > On Mon, Apr 8, 2013 at 6:33 PM, Kishan Kavala
>> >> >>> >> >> >wrote:
>> >> >> >
>> >> >> >> APICommand annotation in API Cmd object has a name parameter.
>> >> >>Currently
>> >> >> >> name parameter takes only one value. I plan to enhance this to
>> >> >>support
>> >> >> >> comma separated values. This will allow multiple API names for
>>the
>> >> >>same
>> >> >> API
>> >> >> >> Cmd object.
>> 

Re: [DIscuss]Storage image store plugin framework refactoring

[Nitin Mehta]

On 09/04/13 11:03 PM, "Min Chen"  wrote:

>It may not be that simple to just use api name alias. For example, we
>currently have listS3sCmd, with new image store plugin framework, we
>introduced a new API "listImageStoresCmd" to cover image stores from
>various providers, not only S3. We also introduced a new response
>ImageStoreResponse for this new listImageStoreCmd api. So you are
>suggesting to use the following naming alias to direct old apis to the new
>apis, right?
>
>@APICommand(name = "listImageStores, listS3s, listSwift", ..
>
>
>But there are two issues here:
>1. Previous listS3sCmd api is corresponding to new API
>listImageStores&provider=S3, so this will not be a simple redirect.
>2. Previous listS3sCmd response is S3Response, which is different from new
>ImageStoreResponse, although its information can be found in new
>ImageStoreResponse. Will this break back compatibility as well?

My $.02
Yes, it will break the backward compatibility. For now keep both the
api's, but the UI should start using the new api with
listImageStores&provider=S3.
We should use deprecated annotation to mark that the api is deprecated
just like in the Java Docs and finally remove the api in 5.0.

>
>Thanks
>-min
>
>
>On 4/9/13 10:14 AM, "Chiradeep Vittal" 
>wrote:
>
>>We can have alias for an existing API. See the other ML discussion.
>>
>>On 4/9/13 9:27 AM, "Min Chen"  wrote:
>>
>>>Yes, I will include more api change details in FS in next few days.
>>>According to Chiradeep, it seems that we cannot simply deprecate old API
>>>in 4.2, Edison and I will discuss this and update FS with details on how
>>>to handle these old APIs.
>>>
>>>Thanks
>>>-min
>>>
>>>On 4/8/13 6:34 PM, "Sangeetha Hariharan"
>>>
>>>wrote:
>>>
Min,

Could you also include the details of the API changes (new parameters)
that will be proposed as part of this feature?
Also it would be helpful if you list the request and response
parameters
for the new API calls.
For all the API calls that are being deprecated , is there any specific
error message that will be returned?

-Thanks
Sangeetha 

-Original Message-
From: Min Chen [mailto:min.c...@citrix.com]
Sent: Monday, April 08, 2013 4:45 PM
To: dev@cloudstack.apache.org
Subject: [DIscuss]Storage image store plugin framework refactoring

Hi All,

Currently CloudStack does not offer a flexible pluggable framework for
users to easily integrate and configure any 3rd-party object stores for
such backup services as registering templates, taking snapshots, etc.
Along with Edison's recent refactored storage subsystem 2.0 that mainly
refactored current CloudStack primary storage implementation,  we are
proposing to develop a storage backup object store plugin framework to
allow CloudStack to systematically manage and configure various types
of
backup data stores from different vendors, like NFS, S3, Swift, etc.
With
this new plugin framework, we would like to achieve following
functionalities:
1. Support different object store providers in a uniform and pluggable
fashion.
2. Enable region wide object backup using S3-like object store.
3. Provide pluggable data motion strategies to handle data transfer
from
one data store to another data store.
4. Provide a scalable cache storage framework while moving data between
primary storage and backup storage for certain hypervisor needs.
5. Support flexible combinations of primary storage, secondary storage
and hypervisors, such as (NFS, NFS, Xen), (NF3, S3, Vmware), (ISCSI,
Swift, KVM), , etc.
The proposed ImageStore plugin framework architecture is detailed in
our
FS here: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+O
b
j
e
ct+Store+Plugin+Framework.
The JIRA ticket to track this feature is:
https://issues.apache.org/jira/browse/CLOUDSTACK-1975. The work is
currently carried out in feature branch  "object_store".
Please let me know your comments and suggestions.

Thanks
-min


>>>
>>
>

Re: [DISCUSS] Don't assign tickets to people when triaging

[Rohit Yadav]

On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam  wrote:

> On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > [Animesh>] Folks I wanted to get your opinion on auto-assignment
> > based on the component maintainers list. We can also create shared
> > issues filters based on components. Folks can subscribe to the
> > filters of interest and receive daily email notification.
>
> I have no opinion and am okay whichever way - auto-assign/unassigned.
> But these workflows should be _*clearly*_ mentioned to contributors
> and where they will go looking for them - wiki, website etc.
>
>
A non-sponsored new/old (casual/hippie) contributor would try to search
among unassigned issues, while managers/developers/committers whose $dayjob
allows them to work on ACS fulltime will tend to do 'cookie lickin' which
is understandable and will assure that someone gets the privilege to work
on it and their employers will make sure the task would be done :)

I would prefer an environment where every contributor (sponsored or
otherwise) would assign the tickets themselves, and unassign if they cannot
do it or don't have time/resources for it.

We've already seen several occasions where someone assigns an issue to
someone and we see cycle of assignments because the "assigner" had no clue
about the issue or did not really know who would could really resolve the
issue. Just saying.

Cheers.

Triaging and assigning issues at the time of release to
> contributors/committers by the Release Manager shouldn't be a problem
> at all as long as it's communicated (as Chip did for the RC bugs)
>
> Thanks,
>
> --
> Prasanna.,
>

Re: Review Request: Cloudstack-701 Support for non contiguous vlan ranges.

[Likitha Shetty]

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


All guest vlan ranges belonging to one physical network are being updated in 
the same column. This would mean there is no way to uniquely identify or 
operate on each of the individual ranges. 
Shouldn't we instead have a separate entry for each range in the 
physical_network table? Or maybe have a new table to hold the guest vlan ranges 
where they are mapped to the corresponding physical network?

- Likitha Shetty


On April 9, 2013, 3 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10238/
> ---
> 
> (Updated April 9, 2013, 3 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Description
> ---
> 
> Cloudstack-701: Support for non contiguous vlan ranges.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkService.java ab6d7bf 
>   api/src/com/cloud/network/PhysicalNetwork.java a2044a6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c518830 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java
>  06cf38d 
>   server/src/com/cloud/api/ApiResponseHelper.java 64be7f8 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 1526fb0 
>   server/src/com/cloud/dc/dao/DataCenterVnetDao.java 79e91c4 
>   server/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 5ded0f4 
>   server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java ae00bf2 
>   server/src/com/cloud/network/NetworkServiceImpl.java 4eb620c 
>   server/src/com/cloud/network/dao/PhysicalNetworkVO.java e5ffcfb 
>   server/src/com/cloud/network/guru/GuestNetworkGuru.java 9c0205a 
>   server/src/com/cloud/resource/ResourceManagerImpl.java 82bca51 
>   server/test/com/cloud/network/MockNetworkManagerImpl.java 6da48ec 
>   server/test/com/cloud/network/UpdatePhysicalNetworkTest.java PRE-CREATION 
>   server/test/com/cloud/vpc/MockNetworkManagerImpl.java ead0051 
>   test/integration/smoke/test_non_contigiousvlan.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10238/diff/
> 
> 
> Testing
> ---
> 
> Tested on latest master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Documentation How-To

[Joe Brockmeier]

On Tue, Apr 9, 2013, at 12:44 PM, Radhika Puthiyetath wrote:
> I am not getting enough feedback when I shared the PDF off-list, after
> committing the draft files to the  Master.

Did you call for feedback on dev@ as well? It's fine to send the PDF
separately to specific folks who request it, since attachments would be
stripped anyway - but I hope we're always asking publicly as well. 

In this case, I think you might be making more work for yourself by
reverting and creating a patch, because other things may change and
you'd have to re-do the patch if you get out of sync. If you have a Jira
issue that relates to it, maybe leave that open until it's reviewed
instead? Just a thought, but I know it's been a hassle in the past
having to re-do patches because they've sat for a while. 

But I am glad to see we're being thorough in getting reviews!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

deployDataCenter.py doesn't work for me on master

[Mike Tutkowski]

Hi,

Any thoughts on this?

I'm trying to set up DevCloud2 by running deployDataCenter (below) and get
a HTTP 530 back.

I even re-installed the DevCloud2 appliance to be sure there wasn't
something weird going on with its current state.

This works for me on 4.1.

Thanks!

mtutkowski-LT:incubator-cloudstack mtutkowski$ cd tools/devcloud ; python
../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 455, in 
deploy.deploy()
  File "../marvin/marvin/deployDataCenter.py", line 440, in deploy
self.createZones(self.config.zones)
  File "../marvin/marvin/deployDataCenter.py", line 312, in createZones
self.createpods(zone.pods, zoneId, networkid)
  File "../marvin/marvin/deployDataCenter.py", line 109, in createpods
self.createClusters(pod.clusters, zoneId, podId)
  File "../marvin/marvin/deployDataCenter.py", line 73, in createClusters
cluster.hypervisor)
  File "../marvin/marvin/deployDataCenter.py", line 53, in addHosts
self.apiClient.addHost(hostcmd)
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
line 1189, in addHost
response = self.connection.make_request(command, response)
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 174, in make_request
result = self.make_request_with_auth(commandName, requests)
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 88, in make_request_with_auth
raise e
urllib2.HTTPError: HTTP Error 530: 530

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*

Re: [DISCUSS] Don't assign tickets to people when triaging

[Noah Slater]

When you say it's understandable that people being paid to work on
CloudStack full time engage in cookie licking, do you mean to say you think
it is acceptable? Or do you believe we should be working to prevent it?


On 9 April 2013 19:14, Rohit Yadav  wrote:

> On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam 
> wrote:
>
> > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > [Animesh>] Folks I wanted to get your opinion on auto-assignment
> > > based on the component maintainers list. We can also create shared
> > > issues filters based on components. Folks can subscribe to the
> > > filters of interest and receive daily email notification.
> >
> > I have no opinion and am okay whichever way - auto-assign/unassigned.
> > But these workflows should be _*clearly*_ mentioned to contributors
> > and where they will go looking for them - wiki, website etc.
> >
> >
> A non-sponsored new/old (casual/hippie) contributor would try to search
> among unassigned issues, while managers/developers/committers whose $dayjob
> allows them to work on ACS fulltime will tend to do 'cookie lickin' which
> is understandable and will assure that someone gets the privilege to work
> on it and their employers will make sure the task would be done :)
>
> I would prefer an environment where every contributor (sponsored or
> otherwise) would assign the tickets themselves, and unassign if they cannot
> do it or don't have time/resources for it.
>
> We've already seen several occasions where someone assigns an issue to
> someone and we see cycle of assignments because the "assigner" had no clue
> about the issue or did not really know who would could really resolve the
> issue. Just saying.
>
> Cheers.
>
> Triaging and assigning issues at the time of release to
> > contributors/committers by the Release Manager shouldn't be a problem
> > at all as long as it's communicated (as Chip did for the RC bugs)
> >
> > Thanks,
> >
> > --
> > Prasanna.,
> >
>



-- 
NS

Re: Review Request: Changes for Egress firewall rules feature support in SRX

[Sheng Yang]

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



server/src/com/cloud/upgrade/dao/Upgrade410to420.java


This would by default allow all egress traffic right? How can these rules 
applied to SRX after mgmt server upgrade?


- Sheng Yang


On April 9, 2013, 6:12 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10336/
> ---
> 
> (Updated April 9, 2013, 6:12 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Sheng Yang, and Murali 
> Reddy.
> 
> 
> Description
> ---
> 
> Added egress firewall rules support for SRX device.
> Supported networks:
> 1. Advanced Isolated networks.
> 
> 
> This addresses bug CLOUDSTACK-779.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/FirewallRuleTO.java 7f77936 
>   
> plugins/network-elements/juniper-srx/src/com/cloud/network/element/JuniperSRXExternalFirewallElement.java
>  af0912a 
>   
> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>  8482168 
>   scripts/network/juniper/application-add.xml 6603850 
>   scripts/network/juniper/security-policy-add.xml 632a17d 
>   server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 1fc32d0 
>   server/src/com/cloud/upgrade/dao/Upgrade410to420.java f39038f 
> 
> Diff: https://reviews.apache.org/r/10336/diff/
> 
> 
> Testing
> ---
> 
> Unit Testing done.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>