[ANNOUNCE] Apache CloudStack 4.2.0 Released

[Animesh]

 
The Apache CloudStack project is excited to announce the
4.2 feature release of the CloudStack cloud orchestration platform. This is the
next feature release of the 4.0 branch which first released on November 6, 2012
with the 4.1 release on June 5. This is the second major release from Apache
CloudStack since its graduation from the Apache Incubator on March 20th. 

This release represents over six months of work from the
Apache CloudStack community with 57 new and 29 improved features being
provided. Many new features incorporate contributions from major corporations
and support for industry standards. New integrated support of the Cisco UCS
compute chassis, SolidFire storage arrays, and the S3 storage protocol are just
a few of the features available in this release.

## Documentation
The 4.2 release includes over 160 issues from 4.1.0 and
4.1.1 were fixed; including fixes for swift support, fixes to documentation,
and more. Please see the Release Notes for a full list of corrected issues and
upgrade instructions. 

The official installation, administration and API
documentation for each release are available on our Documentation Page.

## Downloads
The official source code for the 4.2 release can be
downloaded from our Downloads Page.

In addition to the official source code release,
individual contributors have also made convenience binaries available on the
Apache CloudStack download page.

## Apache CloudStack
Apache CloudStack is an integrated
Infrastructure-as-a-Service (IaaS) software platform that allows users to build
feature-rich public and private cloud environments. CloudStack includes an
intuitive user interface and rich APIs for managing the compute, networking,
software, and storage infrastructure resources. The project became an Apache
top level project in March 2013.

For additional marketing or communications information,
please contact the marketing mailing list.

To learn how to join and contribute to the Apache
CloudStack community please visit our website.



Animesh Chaturvedi
Committer Apache CloudStack
anim...@apache.org     

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Monday, September 16, 2013 10:18 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> 
> If it is fine with community I am willing to take up 4.2.1 maintenance
> release.
> 
> -abhi
[Animesh>] Abhi looks like you are the only one for 4.2.1. Let me know if you 
need any help. 
> 
> On 16/09/13 5:05 pm, "Daan Hoogland"  wrote:
> 
> >Animesh, I am passing till next time, I am willing though if really no
> >one can be found.
> >
> >Daan
> >
> >On Wed, Sep 11, 2013 at 7:57 AM, Animesh Chaturvedi
> > wrote:
> >> Folks
> >>
> >> Now that 4.2.0 VOTE has passed I want to call out for any committers
> >>who are interested in taking over as the release manager for the
> >>upcoming 4.2.1 maintenance release and the 4.3.0 release.
> >>
> >>
> >> Following our 4 month release cycle the feature freeze for 4.3.0
> >>should be by end of October and as community we need to figure out the
> >>timelines for 4.2.1 maintenance release.
> >>
> >> I will update my experience and learning from the 4.2.0 release in
> >>the wiki shortly after the formal release announcement  later this
> week.
> >>
> >> Thanks
> >> Animesh
> >>
> >>
> >>
> >>

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Monday, September 16, 2013 10:30 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Call for 4.3 and 4.2.1 Release Managers!
> 
> 
> 
> > -Original Message-
> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > Sent: Monday, September 16, 2013 4:35 AM
> > To: dev
> > Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> >
> > Animesh, I am passing till next time, I am willing though if really no
> > one can be found.
> >
> > Dann
> 
> [Animesh>] Daan thanks for the offer, I was getting worried that no one
> wants to be RM. Let's see who else turns up.
> 
[Animesh>] Daan do you want to take up 4.3.0? I have added  a 4.3.0 release 
page with tentative dates for now. If you don't want to do it now, I can 
continue for 4.3.0.
> >
> > On Wed, Sep 11, 2013 at 7:57 AM, Animesh Chaturvedi
> >  wrote:
> > > Folks
> > >
> > > Now that 4.2.0 VOTE has passed I want to call out for any committers
> > who are interested in taking over as the release manager for the
> > upcoming 4.2.1 maintenance release and the 4.3.0 release.
> > >
> > >
> > > Following our 4 month release cycle the feature freeze for 4.3.0
> > should be by end of October and as community we need to figure out the
> > timelines for 4.2.1 maintenance release.
> > >
> > > I will update my experience and learning from the 4.2.0 release in
> > > the
> > wiki shortly after the formal release announcement  later this week.
> > >
> > > Thanks
> > > Animesh
> > >
> > >
> > >
> > >

[VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

The vote has *passed* with the following results (binding PMC votes indicated 
with a "*" next to their name:

+1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*, Wido*,  Sebastien, 
Rajesh Batala, Sheng, Vijay, Abhi, Likitha, Ian, Gavin,  Daan, Amogh, Simon 
Weller, 

I'm going to proceed with moving the release into the distribution repo now and 
work on release notes and other documentation tasks.


Thanks
Animesh



On Fri, Sep 13, 2013 at 4:12 PM, Animesh Chaturvedi < 
animesh.chaturv...@citrix.com> wrote:

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

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Wido den Hollander [mailto:w...@widodh.nl]
> Sent: Wednesday, September 18, 2013 4:55 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> 
> 
> On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> >
> > The vote has *passed* with the following results (binding PMC votes
> indicated with a "*" next to their name:
> >
> > +1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*, Wido*,
> > +Sebastien, Rajesh Batala, Sheng, Vijay, Abhi, Likitha, Ian, Gavin,
> > +Daan, Amogh, Simon Weller,
> >
> > I'm going to proceed with moving the release into the distribution
> repo now and work on release notes and other documentation tasks.
> >
> Who is going to build the RPM and Deb packages?
> 
> I think I should build the .deb packages since I'm the one in
> debian/changelog who set the version to 4.2
> 
> Give me a sign and I'll put the packages online in the DEB repo.
> 
> Wido
[Animesh>] Chip/David do we need to wait for the docs to be closed out first?
> 
> >
> > Thanks
> > Animesh
> >
> >
> >
> > On Fri, Sep 13, 2013 at 4:12 PM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
> >
> >>
> >> I've created a 4.2.0 release, with the following artifacts up for a
> vote:
> >>
> >> Git Branch and Commit SH:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h
> >> =
> >> refs/heads/4.2
> >> Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f
> >>
> >> List of changes:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain
> >> ;
> >> f=CHANGES;hb=4.2
> >>
> >> Source release (checksums and signatures are available at the same
> >> location):
> >> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> >>
> >> PGP release keys (signed using 94BE0D7C):
> >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >>
> >> Testing instructions are here:
> >>
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+p
> >> r
> >> ocedure
> >>
> >> Vote will be open for 72 hours (Wednesday 9/18 End of Day PST).
> >>
> >> For sanity in tallying the vote, can PMC members please be sure to
> >> indicate "(binding)" with their vote?
> >>
> >> [ ] +1  approve
> >> [ ] +0  no opinion
> >> [ ] -1  disapprove (and reason why)
> >>
> >>

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Thursday, September 19, 2013 9:49 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> We do need to ensure that we have the db upgrade fix that was mentioned
> on the other thread, otherwise people going from 4.1 to 4.2 will have
> their VPCs break. Looks like we are waiting on a script. It sounds like
> the plan will be to provide instructions in the release notes. Really
> wish we would have caught that, its not just that we find bugs at RC,
> but the severity of ones we miss is astounding sometimes.

[Animesh>] I am also stumped why this was not caught earlier. Kishan has a fix 
that is being tested.

> On Sep 19, 2013 10:18 AM, "Animesh Chaturvedi" <
> animesh.chaturv...@citrix.com> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Wido den Hollander [mailto:w...@widodh.nl]
> > > Sent: Wednesday, September 18, 2013 4:55 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > > round)
> > >
> > >
> > >
> > > On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> > > >
> > > > The vote has *passed* with the following results (binding PMC
> > > > votes
> > > indicated with a "*" next to their name:
> > > >
> > > > +1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*, Wido*,
> > > > +Sebastien, Rajesh Batala, Sheng, Vijay, Abhi, Likitha, Ian,
> > > > +Gavin, Daan, Amogh, Simon Weller,
> > > >
> > > > I'm going to proceed with moving the release into the distribution
> > > repo now and work on release notes and other documentation tasks.
> > > >
> > > Who is going to build the RPM and Deb packages?
> > >
> > > I think I should build the .deb packages since I'm the one in
> > > debian/changelog who set the version to 4.2
> > >
> > > Give me a sign and I'll put the packages online in the DEB repo.
> > >
> > > Wido
> > [Animesh>] Chip/David do we need to wait for the docs to be closed out
> > first?
> > >
> > > >
> > > > Thanks
> > > > Animesh
> > > >
> > > >
> > > >
> > > > On Fri, Sep 13, 2013 at 4:12 PM, Animesh Chaturvedi <
> > > animesh.chaturv...@citrix.com> wrote:
> > > >
> > > >>
> > > >> I've created a 4.2.0 release, with the following artifacts up for
> > > >> a
> > > vote:
> > > >>
> > > >> Git Branch and Commit SH:
> > > >>
> > > >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortl
> > > >> og;h
> > > >> =
> > > >> refs/heads/4.2
> > > >> Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f
> > > >>
> > > >> List of changes:
> > > >>
> > > >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_p
> > > >> lain
> > > >> ;
> > > >> f=CHANGES;hb=4.2
> > > >>
> > > >> Source release (checksums and signatures are available at the
> > > >> same
> > > >> location):
> > > >> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> > > >>
> > > >> PGP release keys (signed using 94BE0D7C):
> > > >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > >>
> > > >> Testing instructions are here:
> > > >>
> > > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+te
> > > >> st+p
> > > >> r
> > > >> ocedure
> > > >>
> > > >> Vote will be open for 72 hours (Wednesday 9/18 End of Day PST).
> > > >>
> > > >> For sanity in tallying the vote, can PMC members please be sure
> > > >> to indicate "(binding)" with their vote?
> > > >>
> > > >> [ ] +1  approve
> > > >> [ ] +0  no opinion
> > > >> [ ] -1  disapprove (and reason why)
> > > >>
> > > >>
> >

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, September 19, 2013 10:43 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> 
> 
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Thursday, September 19, 2013 9:49 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > round)
> >
> > We do need to ensure that we have the db upgrade fix that was
> > mentioned on the other thread, otherwise people going from 4.1 to 4.2
> > will have their VPCs break. Looks like we are waiting on a script. It
> > sounds like the plan will be to provide instructions in the release
> > notes. Really wish we would have caught that, its not just that we
> > find bugs at RC, but the severity of ones we miss is astounding
> sometimes.
> 
> [Animesh>] I am also stumped why this was not caught earlier. Kishan has
> a fix that is being tested.
[Animesh>] So while the fix  is being tested we have two options

1. Release 4.2, release note this issue, provide a separate script that would 
have to be run if someone was using VPC in 4.1 and upgraded to 4.2, fix this 
issue in 4.2.1

2. Since we have not released 4.2 yet, respin another RC and another round of 
VOTE. That would be a record 6th RC Vote and 2 recalls after successful votes 
:(  

Thoughts?

> 
> > On Sep 19, 2013 10:18 AM, "Animesh Chaturvedi" <
> > animesh.chaturv...@citrix.com> wrote:
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Wido den Hollander [mailto:w...@widodh.nl]
> > > > Sent: Wednesday, September 18, 2013 4:55 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > > (fifth
> > > > round)
> > > >
> > > >
> > > >
> > > > On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> > > > >
> > > > > The vote has *passed* with the following results (binding PMC
> > > > > votes
> > > > indicated with a "*" next to their name:
> > > > >
> > > > > +1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*, Wido*,
> > > > > +Sebastien, Rajesh Batala, Sheng, Vijay, Abhi, Likitha, Ian,
> > > > > +Gavin, Daan, Amogh, Simon Weller,
> > > > >
> > > > > I'm going to proceed with moving the release into the
> > > > > distribution
> > > > repo now and work on release notes and other documentation tasks.
> > > > >
> > > > Who is going to build the RPM and Deb packages?
> > > >
> > > > I think I should build the .deb packages since I'm the one in
> > > > debian/changelog who set the version to 4.2
> > > >
> > > > Give me a sign and I'll put the packages online in the DEB repo.
> > > >
> > > > Wido
> > > [Animesh>] Chip/David do we need to wait for the docs to be closed
> > > out first?
> > > >
> > > > >
> > > > > Thanks
> > > > > Animesh
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 13, 2013 at 4:12 PM, Animesh Chaturvedi <
> > > > animesh.chaturv...@citrix.com> wrote:
> > > > >
> > > > >>
> > > > >> I've created a 4.2.0 release, with the following artifacts up
> > > > >> for a
> > > > vote:
> > > > >>
> > > > >> Git Branch and Commit SH:
> > > > >>
> > > > >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shor
> > > > >> tl
> > > > >> og;h
> > > > >> =
> > > > >> refs/heads/4.2
> > > > >> Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f
> > > > >>
> > > > >> List of changes:
> > > > >>
> > > > >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob
> > > > >> _p
> > > > >> lain
> > > > >> ;
> > > > >> f=CHANGES;hb=4.2
> > > > >>
> > > > >> Source release (checksums and signatures are available at the
> > > > >> same
> > > > >> location):
> > > > >> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> > > > >>
> > > > >> PGP release keys (signed using 94BE0D7C):
> > > > >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > > >>
> > > > >> Testing instructions are here:
> > > > >>
> > > > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+
> > > > >> te
> > > > >> st+p
> > > > >> r
> > > > >> ocedure
> > > > >>
> > > > >> Vote will be open for 72 hours (Wednesday 9/18 End of Day PST).
> > > > >>
> > > > >> For sanity in tallying the vote, can PMC members please be sure
> > > > >> to indicate "(binding)" with their vote?
> > > > >>
> > > > >> [ ] +1  approve
> > > > >> [ ] +0  no opinion
> > > > >> [ ] -1  disapprove (and reason why)
> > > > >>
> > > > >>
> > >

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Thursday, September 19, 2013 4:46 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> I prefer a respin, as painful as that seems. VPC is a major feature, do
> we really want to release something that we know will break anyone who
> tries to upgrade?  I could deal with #1 if we are able to include the
> hotfix script in the packaging, such that the release notes can provide
> dead simple instructions for upgrade (no 'go download this script'). I'm
> just not clear on what we can change and what we can't post-vote.

[Animesh>] I don't think the  release artifacts can be changed so the script 
will have to be downloaded. David/Chip/Wido any thoughts on that? We can have 
the script available before the release announcement if we continue with 
current VOTE.

> 
> On Thu, Sep 19, 2013 at 3:59 PM, Animesh Chaturvedi
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> Sent: Thursday, September 19, 2013 10:43 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> >> round)
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >> > Sent: Thursday, September 19, 2013 9:49 AM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> >> > round)
> >> >
> >> > We do need to ensure that we have the db upgrade fix that was
> >> > mentioned on the other thread, otherwise people going from 4.1 to
> >> > 4.2 will have their VPCs break. Looks like we are waiting on a
> >> > script. It sounds like the plan will be to provide instructions in
> >> > the release notes. Really wish we would have caught that, its not
> >> > just that we find bugs at RC, but the severity of ones we miss is
> >> > astounding
> >> sometimes.
> >>
> >> [Animesh>] I am also stumped why this was not caught earlier. Kishan
> >> has a fix that is being tested.
> > [Animesh>] So while the fix  is being tested we have two options
> >
> > 1. Release 4.2, release note this issue, provide a separate script
> > that would have to be run if someone was using VPC in 4.1 and upgraded
> > to 4.2, fix this issue in 4.2.1
> >
> > 2. Since we have not released 4.2 yet, respin another RC and another
> > round of VOTE. That would be a record 6th RC Vote and 2 recalls after
> > successful votes :(
> >
> > Thoughts?
> >
> >>
> >> > On Sep 19, 2013 10:18 AM, "Animesh Chaturvedi" <
> >> > animesh.chaturv...@citrix.com> wrote:
> >> >
> >> > >
> >> > >
> >> > > > -Original Message-
> >> > > > From: Wido den Hollander [mailto:w...@widodh.nl]
> >> > > > Sent: Wednesday, September 18, 2013 4:55 PM
> >> > > > To: dev@cloudstack.apache.org
> >> > > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> >> > > > (fifth
> >> > > > round)
> >> > > >
> >> > > >
> >> > > >
> >> > > > On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> >> > > > >
> >> > > > > The vote has *passed* with the following results (binding PMC
> >> > > > > votes
> >> > > > indicated with a "*" next to their name:
> >> > > > >
> >> > > > > +1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*,
> >> > > > > +Wido*, Sebastien, Rajesh Batala, Sheng, Vijay, Abhi,
> >> > > > > +Likitha, Ian, Gavin, Daan, Amogh, Simon Weller,
> >> > > > >
> >> > > > > I'm going to proceed with moving the release into the
> >> > > > > distribution
> >> > > > repo now and work on release notes and other documentation
> tasks.
> >> > > > >
> >> > > > Who is going to build the RPM and Deb packages?
> >> > > >
> >> > > > I think I should build the .deb packages since I'm the one in
> >> > > > debian/changelog who set the version to 4.2
> 

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, September 19, 2013 5:15 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> 
> 
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Thursday, September 19, 2013 4:46 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > round)
> >
> > I prefer a respin, as painful as that seems. VPC is a major feature,
> > do we really want to release something that we know will break anyone
> > who tries to upgrade?  I could deal with #1 if we are able to include
> > the hotfix script in the packaging, such that the release notes can
> > provide dead simple instructions for upgrade (no 'go download this
> > script'). I'm just not clear on what we can change and what we can't
> post-vote.
> 
> [Animesh>] I don't think the  release artifacts can be changed so the
> script will have to be downloaded. David/Chip/Wido any thoughts on that?
> We can have the script available before the release announcement if we
> continue with current VOTE.
> 
> >
[Animesh>] Only Marcus, Indra and Simon have responded I am prepared to respin 
tomorrow after VPC testing is complete with fixes from Alena. I would like to 
stick to 72 hour VOTE including weekend since last time most of the VOTEs were 
received over weekend. 


> > On Thu, Sep 19, 2013 at 3:59 PM, Animesh Chaturvedi
> >  wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > >> Sent: Thursday, September 19, 2013 10:43 AM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > >> round)
> > >>
> > >>
> > >>
> > >> > -Original Message-
> > >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > >> > Sent: Thursday, September 19, 2013 9:49 AM
> > >> > To: dev@cloudstack.apache.org
> > >> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > >> > (fifth
> > >> > round)
> > >> >
> > >> > We do need to ensure that we have the db upgrade fix that was
> > >> > mentioned on the other thread, otherwise people going from 4.1 to
> > >> > 4.2 will have their VPCs break. Looks like we are waiting on a
> > >> > script. It sounds like the plan will be to provide instructions
> > >> > in the release notes. Really wish we would have caught that, its
> > >> > not just that we find bugs at RC, but the severity of ones we
> > >> > miss is astounding
> > >> sometimes.
> > >>
> > >> [Animesh>] I am also stumped why this was not caught earlier.
> > >> Kishan has a fix that is being tested.
> > > [Animesh>] So while the fix  is being tested we have two options
> > >
> > > 1. Release 4.2, release note this issue, provide a separate script
> > > that would have to be run if someone was using VPC in 4.1 and
> > > upgraded to 4.2, fix this issue in 4.2.1
> > >
> > > 2. Since we have not released 4.2 yet, respin another RC and another
> > > round of VOTE. That would be a record 6th RC Vote and 2 recalls
> > > after successful votes :(
> > >
> > > Thoughts?
> > >
> > >>
> > >> > On Sep 19, 2013 10:18 AM, "Animesh Chaturvedi" <
> > >> > animesh.chaturv...@citrix.com> wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > > > -Original Message-
> > >> > > > From: Wido den Hollander [mailto:w...@widodh.nl]
> > >> > > > Sent: Wednesday, September 18, 2013 4:55 PM
> > >> > > > To: dev@cloudstack.apache.org
> > >> > > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > >> > > > (fifth
> > >> > > > round)
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> > >> > > > >
> > >> > > > > The vote has *passed* with the following results (binding
> > >> 

RE: http://jenkins.cloudstack.org/ is down ?

[Animesh Chaturvedi]

NS lookup fails

animeshc@SJCLANIMESHC01 
$ nslookup cloudstack.org
*** sjcpdc04.citrite.net can't find cloudstack.org: Server failed
Server:  sjcpdc04.citrite.net
Address:  10.216.4.21


> -Original Message-
> From: Rayees Namathponnan [mailto:rayees.namathpon...@citrix.com]
> Sent: Friday, September 20, 2013 10:04 AM
> To: dev@cloudstack.apache.org
> Subject: http://jenkins.cloudstack.org/ is down ?
> 

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Friday, September 20, 2013 12:51 AM
> To: dev
> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> 
> H Animesh and the rest,
> 
> I had some consults at home and at Schuberg Philis. The conclusion is
> that it is not wise to take up the task as release manager right now.
> I will be glad to take it up some future iteration.
> 
> sorry to lay this burden back,
> Daan
> 
[Animesh>]  Ok anyone else wants to step up to the plate.

> On Wed, Sep 18, 2013 at 10:24 AM, Daan Hoogland
>  wrote:
> > Community,
> >
> > And especially our friends at Citrix, i am willing but am kind of a
> > dictator in this role. Im an experienced developper but not in such a
> > big oss project. I know i havey style and obsessions that some of you
> > might not like. A fixation on automated tests os one that i know is
> > likely to be accepted. Others will come out of the hat.
> >
> > Thought i had to warm you all,
> > Daan
> >
> > mobile biligual spell checker used
> >
> > Op 18 sep. 2013 07:22 schreef "Animesh Chaturvedi"
> >  het volgende:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> > Sent: Monday, September 16, 2013 10:30 AM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: RE: Call for 4.3 and 4.2.1 Release Managers!
> >> >
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> > > Sent: Monday, September 16, 2013 4:35 AM
> >> > > To: dev
> >> > > Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> >> > >
> >> > > Animesh, I am passing till next time, I am willing though if
> >> > > really no one can be found.
> >> > >
> >> > > Dann
> >> >
> >> > [Animesh>] Daan thanks for the offer, I was getting worried that no
> >> > one wants to be RM. Let's see who else turns up.
> >> >
> >> [Animesh>] Daan do you want to take up 4.3.0? I have added  a 4.3.0
> >> release page with tentative dates for now. If you don't want to do it
> >> now, I can continue for 4.3.0.
> >> > >
> >> > > On Wed, Sep 11, 2013 at 7:57 AM, Animesh Chaturvedi
> >> > >  wrote:
> >> > > > Folks
> >> > > >
> >> > > > Now that 4.2.0 VOTE has passed I want to call out for any
> >> > > > committers
> >> > > who are interested in taking over as the release manager for the
> >> > > upcoming 4.2.1 maintenance release and the 4.3.0 release.
> >> > > >
> >> > > >
> >> > > > Following our 4 month release cycle the feature freeze for
> >> > > > 4.3.0
> >> > > should be by end of October and as community we need to figure
> >> > > out the timelines for 4.2.1 maintenance release.
> >> > > >
> >> > > > I will update my experience and learning from the 4.2.0 release
> >> > > > in the
> >> > > wiki shortly after the formal release announcement  later this
> week.
> >> > > >
> >> > > > Thanks
> >> > > > Animesh
> >> > > >
> >> > > >
> >> > > >
> >> > > >

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

Ok it's on the way VPC upgrade has been tested and working now. Just pulled the 
commits into 4.2 and building another RC now



> -Original Message-
> From: Tracy Phillips [mailto:tracp...@mantoso.com]
> Sent: Friday, September 20, 2013 7:55 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> I agree with the respin.
> 
> Cloudstack is still a young open source project and we don't need any
> negative press/tweets/blogs/gossip :)
> 
> 
> On Fri, Sep 20, 2013 at 1:03 AM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > > Sent: Thursday, September 19, 2013 5:15 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > > round)
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > > Sent: Thursday, September 19, 2013 4:46 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > > (fifth
> > > > round)
> > > >
> > > > I prefer a respin, as painful as that seems. VPC is a major
> > > > feature, do we really want to release something that we know will
> > > > break anyone who tries to upgrade?  I could deal with #1 if we are
> > > > able to include the hotfix script in the packaging, such that the
> > > > release notes can provide dead simple instructions for upgrade (no
> > > > 'go download this script'). I'm just not clear on what we can
> > > > change and what we can't
> > > post-vote.
> > >
> > > [Animesh>] I don't think the  release artifacts can be changed so
> > > the script will have to be downloaded. David/Chip/Wido any thoughts
> on that?
> > > We can have the script available before the release announcement if
> > > we continue with current VOTE.
> > >
> > > >
> > [Animesh>] Only Marcus, Indra and Simon have responded I am prepared
> > to respin tomorrow after VPC testing is complete with fixes from
> > Alena. I would like to stick to 72 hour VOTE including weekend since
> > last time most of the VOTEs were received over weekend.
> >
> >
> > > > On Thu, Sep 19, 2013 at 3:59 PM, Animesh Chaturvedi
> > > >  wrote:
> > > > >
> > > > >
> > > > >> -Original Message-
> > > > >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > > > >> Sent: Thursday, September 19, 2013 10:43 AM
> > > > >> To: dev@cloudstack.apache.org
> > > > >> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > > >> (fifth
> > > > >> round)
> > > > >>
> > > > >>
> > > > >>
> > > > >> > -Original Message-
> > > > >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > > >> > Sent: Thursday, September 19, 2013 9:49 AM
> > > > >> > To: dev@cloudstack.apache.org
> > > > >> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > > >> > (fifth
> > > > >> > round)
> > > > >> >
> > > > >> > We do need to ensure that we have the db upgrade fix that was
> > > > >> > mentioned on the other thread, otherwise people going from
> > > > >> > 4.1 to
> > > > >> > 4.2 will have their VPCs break. Looks like we are waiting on
> > > > >> > a script. It sounds like the plan will be to provide
> > > > >> > instructions in the release notes. Really wish we would have
> > > > >> > caught that, its not just that we find bugs at RC, but the
> > > > >> > severity of ones we miss is astounding
> > > > >> sometimes.
> > > > >>
> > > > >> [Animesh>] I am also stumped why this was not caught earlier.
> > > > >> Kishan has a fix that is being tested.
> > > > > [Animesh>] So while the fix  is being tested we have two options
> > > > >
> > > > > 1. Rele

RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Simon Weller [mailto:swel...@ena.com]
> Sent: Friday, September 20, 2013 8:05 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> Animesh,
> 
> 
> Are you aware of any proposed upgrade documentation as of yet? I'd
> really like to try a couple of upgrades to test the procedure.
> 
> 
> - Si
[Animesh>]Here is the upgrade steps from RN for ACS 4.1.0 release. It should be 
the same for 4.1.0 to 4.2.0 
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Release_Notes/upgrade-instructions.html#upgrade-from-4.0-to-4.1

> 
> - Original Message -
> 
> From: "Animesh Chaturvedi" 
> To: dev@cloudstack.apache.org
> Sent: Friday, September 20, 2013 12:03:41 AM
> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> round)
> 
> 
> 
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Thursday, September 19, 2013 5:15 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > round)
> >
> >
> >
> > > -Original Message-
> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > Sent: Thursday, September 19, 2013 4:46 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > > round)
> > >
> > > I prefer a respin, as painful as that seems. VPC is a major feature,
> > > do we really want to release something that we know will break
> > > anyone who tries to upgrade? I could deal with #1 if we are able to
> > > include the hotfix script in the packaging, such that the release
> > > notes can provide dead simple instructions for upgrade (no 'go
> > > download this script'). I'm just not clear on what we can change and
> > > what we can't
> > post-vote.
> >
> > [Animesh>] I don't think the release artifacts can be changed so the
> > script will have to be downloaded. David/Chip/Wido any thoughts on
> that?
> > We can have the script available before the release announcement if we
> > continue with current VOTE.
> >
> > >
> [Animesh>] Only Marcus, Indra and Simon have responded I am prepared to
> respin tomorrow after VPC testing is complete with fixes from Alena. I
> would like to stick to 72 hour VOTE including weekend since last time
> most of the VOTEs were received over weekend.
> 
> 
> > > On Thu, Sep 19, 2013 at 3:59 PM, Animesh Chaturvedi
> > >  wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > > >> Sent: Thursday, September 19, 2013 10:43 AM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > >> (fifth
> > > >> round)
> > > >>
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > >> > Sent: Thursday, September 19, 2013 9:49 AM
> > > >> > To: dev@cloudstack.apache.org
> > > >> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > >> > (fifth
> > > >> > round)
> > > >> >
> > > >> > We do need to ensure that we have the db upgrade fix that was
> > > >> > mentioned on the other thread, otherwise people going from 4.1
> > > >> > to
> > > >> > 4.2 will have their VPCs break. Looks like we are waiting on a
> > > >> > script. It sounds like the plan will be to provide instructions
> > > >> > in the release notes. Really wish we would have caught that,
> > > >> > its not just that we find bugs at RC, but the severity of ones
> > > >> > we miss is astounding
> > > >> sometimes.
> > > >>
> > > >> [Animesh>] I am also stumped why this was not caught earlier.
> > > >> Kishan has a fix that is being tested.
> > > > [Animesh>] So while the fix is being tested we have two options
> > > >
> > > > 1. Release 4.2, release note this issue, provide a separate script
> > > > that would have to be run if someone was using VP

[VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

I've created a 4.2.0 release, with the following artifacts up for a vote:

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2
Commit: 69c459342c568e2400d57ee88572b301603d8686

List of changes:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/

PGP release keys (signed using 94BE0D7C):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Testing instructions are here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure

Vote will be open for 72 hours (Monday 9/23 PST EOD).

For sanity in tallying the vote, can PMC members please be sure to indicate 
"(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

RE: Volunteers to Complete the 4.2 Release Notes

[Animesh Chaturvedi]

Indra

I am unable to download the ReleaseNotes attachment from the bug at this time. 
I will get back with more comments once I am able to get to it. Few comments 
in-line

> -Original Message-
> From: Indra Pramana [mailto:in...@sg.or.id]
> Sent: Friday, September 20, 2013 9:54 PM
> To: Radhika Puthiyetath
> Cc: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Re: Volunteers to Complete the 4.2 Release Notes
> 
> Hi Radhika,
> 
> I have downloaded the PDF document, thank you very much.
> 
> I noted that there is no specific upgrade instruction from 4.1.1 to
> 4.2.0.
> What we have there is the generic upgrade instruction from 4.x.x to
> 4.2.0.
> 
> I have actually tried to follow this instruction on my earlier (failed)
> upgrade attempt from 4.1.1 to 4.2.0, and found out that some of the
> steps are no longer applicable. For example:
> 
> Step 6: Changes from /etc/cloud/management/components.xml to
> /etc/cloudstack/management/componentContext.xml is no longer required
> for upgrade from 4.1.1 to 4.2.0, since we are already using
> /etc/cloudstack folder (instead of /etc/cloud folder) on 4.1.1.
[Animesh>] Yes this is left over and is not applicable for this upgrade and 
will have to be cleaned up
> 
> Step 8h: Uninstalling old cloud-* packages are not required for upgrade
> from 4.1.1 to 4.2.0 (cloud-* packages do not exist).
[Animesh>] Yes this is left over and is not applicable for this upgrade and 
will have to be cleaned up
> 
> Step 10: (KVM Only): point a - Manually clean up /var/cache/cloudstack
> <-- I believe this is supposed to be done on the KVM hosts? There is no
> /var/cache/cloudstack folder on our KVM hosts running CloudStack agent
> version 4.1.1. I have verified on all my KVM hosts. Is this step
> required on the KVM hosts for upgrade from 4.1.1 to 4.2.0?
> 
> I found /var/cache/cloudstack folder on my CloudStack management server
> though. Is this step supposed to be done on the management server
> instead of the KVM hosts? If yes, it's not clearly mentioned.
> 
> Step 12: When I tried to run the cloudstack-sysvmadm script to restart
> the system VMs, the script failed to run with some error messages.
> Unfortunately, I didn't manage to take down the error messages. Is this
> step required for upgrade from 4.1.1 to 4.2.0? If for some reason, we
> are not able to run the script, are we able to restart the system VMs
> manually (say from the CloudStack GUI)?
> 
> Looking forward to your reply, thank you.
> 
> Cheers.
> 
> 
> 
> On Fri, Sep 20, 2013 at 5:45 PM, Radhika Puthiyetath <
> radhika.puthiyet...@citrix.com> wrote:
> 
> >  Thanks Indra.
> >
> > ** **
> >
> > I shall attach the PDF file at
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4245.
> >
> > ** **
> >
> > ** **
> >
> > ** **
> >
> > *From:* Indra Pramana [mailto:in...@sg.or.id]
> > *Sent:* Friday, September 20, 2013 12:07 PM
> > *To:* Radhika Puthiyetath
> > *Cc:* us...@cloudstack.apache.org
> >
> > *Subject:* Re: Volunteers to Complete the 4.2 Release Notes
> >
> > ** **
> >
> > Hi Radhika,
> >
> > ** **
> >
> > May I know how can I view the release notes in normal HTML format,
> > instead of the original XML format?
> >
> > ** **
> >
> > Does it specifically contain migration steps from 4.1.1 to 4.2.0?
> >
> > ** **
> >
> > Would like to try again to upgrade my current CloudStack 4.1.1 to
> > 4.2.0, provided I can get the detailed instruction on what to do. Last
> > time I tried to follow the existing documentation on the .tar.bz2 file
> > (provided by Animesh when he started the vote) and some of the steps
> > seem to be not applicable anymore, and I might have missed out some
> > other steps which are actually required.
> >
> > ** **
> >
> > Looking forward to your reply, thank you.
> >
> > ** **
> >
> > Cheers.
> >
> > ** **
> >
> > ** **
> >
> > On Thu, Sep 19, 2013 at 2:42 PM, Radhika Puthiyetath <
> > radhika.puthiyet...@citrix.com> wrote:
> >
> > This has been updated. Could someone please validate the API section
> > ?
> >
> >
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >
> > Sent: Sunday, September 15, 2013 4:16 AM
> > To: 
> > Cc: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> > Subject: Re: Volunteers to Complete the 4.2 Release Notes
> >
> > I have added a public fi

RE: Upgrade from 4.1.1 to 4.2.0 failed: Error creating bean with name 'apiDBUtils'

[Animesh Chaturvedi]

Can you post the log, mailing list will not take an attachment, so you can 
create a JIRA ticket and put in the log as attachment.

Thanks
Animesh

> -Original Message-
> From: Indra Pramana [mailto:in...@sg.or.id]
> Sent: Monday, September 23, 2013 10:10 AM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Upgrade from 4.1.1 to 4.2.0 failed: Error creating bean with
> name 'apiDBUtils'
> 
> Dear all,
> 
> Apologise, reposting this issue since the subject on the earlier thread
> might not be clearly depicting the problem.
> 
> I tried to perform upgrade of CloudStack version 4.1.1 to 4.2.0, and I
> am not able to access the CloudStack GUI after the upgrade.
> 
> I am able to start the cloudstack-management service:
> 
> root@cs-mgmt-01:/usr/share# service cloudstack-management start
>  * Starting CloudStack-specific Tomcat servlet engine cloudstack-
> management [ OK ]
> 
> However, I am not able to access the GUI with this error message:
> 
> =
> HTTP Status 404 -
> 
> type Status report
> 
> message
> 
> description The requested resource () is not available.
> Apache Tomcat/6.0.35
> =
> 
> I am getting this error message on
> /var/log/cloudstack/management/management-server.log:
> 
> =
> 2013-09-23 21:36:57,003 ERROR [web.context.ContextLoader] (main:null)
> Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'apiDBUtils': Injection of autowired dependencies failed;
> =
> 
> Full log can be found here: http://pastebin.com/0FP9itAf
> 
> Any help is greatly appreciated, thank you.

RE: Volunteers to Complete the 4.2 Release Notes

[Animesh Chaturvedi]

; Edit /etc/cloudstack/agent/agent.properties to change the resource
> parameter from
> com.cloud.agent.resource.computing.LibvirtComputingResource to
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
> 
> We need to run the following too,
> 
> Upgrade all the existing bridge names to new bridge names by running
> this script:
> 
> # cloudstack-agent-upgrade
> 
> . Install a libvirt hook with the following commands:
> # mkdir /etc/libvirt/hooks
> # cp /usr/share/cloudstack-agent/lib/libvirtqemuhook
> /etc/libvirt/hooks/qemu # chmod +x /etc/libvirt/hooks/qemu
> 
> . Restart libvirtd.
> # service libvirtd restart
> 
> . Start the agent.
> # service cloudstack-agent start
> 
>  Note : This step will be added after step 13.d in section 3.2 and 21.e
> in section 3.3
> 
> 7.  We need to add a section for 4.0.x to 4.2 upgrades.
> 
> Thanks and regards,
> Abhinav
> 
> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Sunday, September 22, 2013 10:24 PM
> To: dev@cloudstack.apache.org; Radhika Puthiyetath
> Cc: us...@cloudstack.apache.org
> Subject: RE: Volunteers to Complete the 4.2 Release Notes
> 
> Indra
> 
> I am unable to download the ReleaseNotes attachment from the bug at this
> time. I will get back with more comments once I am able to get to it.
> Few comments in-line
> 
> > -Original Message-
> > From: Indra Pramana [mailto:in...@sg.or.id]
> > Sent: Friday, September 20, 2013 9:54 PM
> > To: Radhika Puthiyetath
> > Cc: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> > Subject: Re: Volunteers to Complete the 4.2 Release Notes
> >
> > Hi Radhika,
> >
> > I have downloaded the PDF document, thank you very much.
> >
> > I noted that there is no specific upgrade instruction from 4.1.1 to
> > 4.2.0.
> > What we have there is the generic upgrade instruction from 4.x.x to
> > 4.2.0.
> >
> > I have actually tried to follow this instruction on my earlier
> > (failed) upgrade attempt from 4.1.1 to 4.2.0, and found out that some
> > of the steps are no longer applicable. For example:
> >
> > Step 6: Changes from /etc/cloud/management/components.xml to
> > /etc/cloudstack/management/componentContext.xml is no longer required
> > for upgrade from 4.1.1 to 4.2.0, since we are already using
> > /etc/cloudstack folder (instead of /etc/cloud folder) on 4.1.1.
> [Animesh>] Yes this is left over and is not applicable for this upgrade
> and will have to be cleaned up
> >
> > Step 8h: Uninstalling old cloud-* packages are not required for
> > upgrade from 4.1.1 to 4.2.0 (cloud-* packages do not exist).
> [Animesh>] Yes this is left over and is not applicable for this upgrade
> and will have to be cleaned up
> >
> > Step 10: (KVM Only): point a - Manually clean up /var/cache/cloudstack
> > <-- I believe this is supposed to be done on the KVM hosts? There is
> > no /var/cache/cloudstack folder on our KVM hosts running CloudStack
> > agent version 4.1.1. I have verified on all my KVM hosts. Is this step
> > required on the KVM hosts for upgrade from 4.1.1 to 4.2.0?
> >
> > I found /var/cache/cloudstack folder on my CloudStack management
> > server though. Is this step supposed to be done on the management
> > server instead of the KVM hosts? If yes, it's not clearly mentioned.
> >
> > Step 12: When I tried to run the cloudstack-sysvmadm script to restart
> > the system VMs, the script failed to run with some error messages.
> > Unfortunately, I didn't manage to take down the error messages. Is
> > this step required for upgrade from 4.1.1 to 4.2.0? If for some
> > reason, we are not able to run the script, are we able to restart the
> > system VMs manually (say from the CloudStack GUI)?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> > On Fri, Sep 20, 2013 at 5:45 PM, Radhika Puthiyetath <
> > radhika.puthiyet...@citrix.com> wrote:
> >
> > >  Thanks Indra.
> > >
> > > ** **
> > >
> > > I shall attach the PDF file at
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4245.
> > >
> > > ** **
> > >
> > > ** **
> > >
> > > ** **
> > >
> > > *From:* Indra Pramana [mailto:in...@sg.or.id]
> > > *Sent:* Friday, September 20, 2013 12:07 PM
> > > *To:* Radhika Puthiyetath
> > > *Cc:* us...@cloudstack.apache.org
> > >
> > > *Subject:* Re: Volunteers to Complete the 4.2 Re

RE: [PROPOSAL] move away from time-based releases and/or revamp release process

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 23, 2013 12:25 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [PROPOSAL] move away from time-based releases and/or revamp
> release process
> 
> On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi"
> 
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > Sent: Monday, September 23, 2013 11:38 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: [PROPOSAL] move away from time-based releases and/or revamp
> > > release process
> > >
> > > Guys,  I think we are not currently in a state to handle time-based
> > > releases.  Until we can cut master at any time and have it
> > > releasable, or at least at a reasonable RC-level matching minimum
> > > tested requirements, it's just going to continue to be an exercise
> > > in frustration to cut RCs simply because we hit a deadline.
> > [Animesh>] David is going to propose Release Criterion up for
> > discussion
> as per his thread [1]
> 
> I see that thread more about defining what minimum bar we should always
> have master at in order to meet time-based releases. Its where we want
> to go, but not what to do in the meantime.
[Animesh>] His proposal is not just for master, but also for deciding the 
release exit criterion and IMO is something we should follow for 4.3.0 and 
onwards
> 
> > >
> > > Maybe we can get away with sticking to time-based if we revamp our
> > > schedule and procedures, I don't know, but in light of how 4.1
> > > (dragged on so long that some were seriously considering
> > > skipping/not releasing it with 4.2 on its heels) and 4.2 (six rounds
> > > of votes so
> > > far) have worked it's probably worth discussing.
> > >
> > > Any suggestions on what might be better? It's been mentioned in the
> > > past that it's a chicken-egg thing, many really don't try it until
> > > we hit an RC, which causes multiple iterations. I do agree that many
> > > don't take it seriously until we start cutting artifacts, but maybe
> > > we do this in a more deliberate fashion instead of jumping right to
> > > the vote. After feature/code freeze, cut some alpha artifacts, wait
> > > a week, cut alpha2 or some beta artifacts, etc, and then at some
> > > point anyone can propose that certain artifacts (or a new set of
> > > artifacts) be put up for a vote as an RC. This gives us a way to
> > > signal that we're gearing up for release and gives plenty of time
> > > for people to test their components, or see the [PROPOSAL] and say
> > > 'oh crap, I had better test my stuff', prior to cutting an RC.
> > > Maybe this wouldn't help in practice, but I think right now we go
> > > from telling the community "code is frozen, don't check anything in
> > > unless its a bug fix" to "here's our RC, try it out", without a
> formal testing window.
> > > I realize the whole thing should be a testing window, but I don't
> > > think it's conveyed well.
> >
> > [Animesh>] After the code freeze is all the stabilization and
> > integration
> testing phase and has been documented at [2].  No one should be waiting
> until the RC to test their components for the first time. It should be
> happening after code freeze.
> 
> >
> > [1] http://markmail.org/thread/wlaq4zg36xnpgsjm
> > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> >
> 
> Got it. As mentioned I realize that the whole time there is supposed to
> be testing, but its not really working that way in practice. People are
> volunteers, they forget where things are, or they dont want to mess with
> it unless there is an indication that its semi-stable, and then suddenly
> an RC is thrown over the fence and we go through iterations of RC. By
> the time the RC comes through we should be done testing and just verify
> that someone's last minute bug fix didn't cause a regression or
> something.
[Animesh>] RC is not thrown in it is discussed as part of the release schedule. 
 After the code-freeze date everyone is expected to complete their integration 
testing by RC date. In fact I had sent numerous reminders prior to the first RC 
starting from 2 weeks before the proposed RC date. 

CloudSatck SF BayArea Meetup on October 15th @ SAP Labs : Spread the word

[Animesh Chaturvedi]

Folks

I am happy to announce the CloudStack Bay area meetup is on October  15th. Here 
is the link for meetup details 
http://www.meetup.com/CloudStack-SF-Bay-Area-Users-Group/events/141814852/

If you wish to be the speaker for this meetup please reach out to Karen Vuong, 
John Kinsella or Animesh. Please spread the word.

Thanks
Animesh
Folks

RE: [PROPOSAL] move away from time-based releases and/or revamp release process

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 23, 2013 11:38 AM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] move away from time-based releases and/or revamp
> release process
> 
> Guys,  I think we are not currently in a state to handle time-based
> releases.  Until we can cut master at any time and have it releasable,
> or at least at a reasonable RC-level matching minimum tested
> requirements, it's just going to continue to be an exercise in
> frustration to cut RCs simply because we hit a deadline.
[Animesh>] David is going to propose Release Criterion up for discussion as per 
his thread [1] 
> 
> Maybe we can get away with sticking to time-based if we revamp our
> schedule and procedures, I don't know, but in light of how 4.1 (dragged
> on so long that some were seriously considering skipping/not releasing
> it with 4.2 on its heels) and 4.2 (six rounds of votes so
> far) have worked it's probably worth discussing.
> 
> Any suggestions on what might be better? It's been mentioned in the past
> that it's a chicken-egg thing, many really don't try it until we hit an
> RC, which causes multiple iterations. I do agree that many don't take it
> seriously until we start cutting artifacts, but maybe we do this in a
> more deliberate fashion instead of jumping right to the vote. After
> feature/code freeze, cut some alpha artifacts, wait a week, cut alpha2
> or some beta artifacts, etc, and then at some point anyone can propose
> that certain artifacts (or a new set of artifacts) be put up for a vote
> as an RC. This gives us a way to signal that we're gearing up for
> release and gives plenty of time for people to test their components, or
> see the [PROPOSAL] and say 'oh crap, I had better test my stuff', prior
> to cutting an RC.  Maybe this wouldn't help in practice, but I think
> right now we go from telling the community "code is frozen, don't check
> anything in unless its a bug fix" to "here's our RC, try it out",
> without a formal testing window.
> I realize the whole thing should be a testing window, but I don't think
> it's conveyed well.

[Animesh>] After the code freeze is all the stabilization and integration 
testing phase and has been documented at [2].  No one should be waiting until 
the RC to test their components for the first time. It should be happening 
after code freeze.

[1] http://markmail.org/thread/wlaq4zg36xnpgsjm
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases

RE: community testing

[Animesh Chaturvedi]

> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Wednesday, September 11, 2013 11:58 PM
> To: Prasanna Santhanam
> Cc: Mike Tutkowski; Marcus Sorensen; dev@cloudstack.apache.org; Ahmad
> Emneina
> Subject: Re: community testing
> 
> 
> While everything happens on the mailing list, maybe we can setup a
> meeting to discuss this. Google hangout ?
> Anyone interested in testing could join.
> 
> Mike is west coast I believe, Prasanna is in india. Scheduling might be
> tough but we should try ?
> 
> -sebastien
> 
> >[Animesh>] Sebastien did this meeting happen? If so can you share the 
> >discussion notes

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Saturday, September 21, 2013 12:55 PM
> To: 
> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> 
> > On Sep 20, 2013, at 1:27 PM, Animesh Chaturvedi
>  wrote:
> >
> >
> >
> >> -Original Message-
> >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> Sent: Friday, September 20, 2013 12:51 AM
> >> To: dev
> >> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> >>
> >> H Animesh and the rest,
> >>
> >> I had some consults at home and at Schuberg Philis. The conclusion is
> >> that it is not wise to take up the task as release manager right now.
> >> I will be glad to take it up some future iteration.
> >>
> >> sorry to lay this burden back,
> >> Daan
> > [Animesh>]  Ok anyone else wants to step up to the plate.
> 
> I'm willing to do 4.3 if nobody else can / wants too.
> 
> I'd suggest someone else rolls with 4.2.1 (or Animesh takes it on).
[Animesh>] Abhinandan asked  to be release manager for 4.2.1
> 
> 
> >
> >> On Wed, Sep 18, 2013 at 10:24 AM, Daan Hoogland
> >>  wrote:
> >>> Community,
> >>>
> >>> And especially our friends at Citrix, i am willing but am kind of a
> >>> dictator in this role. Im an experienced developper but not in such
> >>> a big oss project. I know i havey style and obsessions that some of
> >>> you might not like. A fixation on automated tests os one that i know
> >>> is likely to be accepted. Others will come out of the hat.
> >>>
> >>> Thought i had to warm you all,
> >>> Daan
> >>>
> >>> mobile biligual spell checker used
> >>>
> >>> Op 18 sep. 2013 07:22 schreef "Animesh Chaturvedi"
> >>>  het volgende:
> >>>
> >>>>
> >>>>
> >>>>> -Original Message-
> >>>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >>>>> Sent: Monday, September 16, 2013 10:30 AM
> >>>>> To: dev@cloudstack.apache.org
> >>>>> Subject: RE: Call for 4.3 and 4.2.1 Release Managers!
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >>>>>> Sent: Monday, September 16, 2013 4:35 AM
> >>>>>> To: dev
> >>>>>> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> >>>>>>
> >>>>>> Animesh, I am passing till next time, I am willing though if
> >>>>>> really no one can be found.
> >>>>>>
> >>>>>> Dann
> >>>>>
> >>>>> [Animesh>] Daan thanks for the offer, I was getting worried that
> >>>>> no one wants to be RM. Let's see who else turns up.
> >>>> [Animesh>] Daan do you want to take up 4.3.0? I have added  a 4.3.0
> >>>> release page with tentative dates for now. If you don't want to do
> >>>> it now, I can continue for 4.3.0.
> >>>>>>
> >>>>>> On Wed, Sep 11, 2013 at 7:57 AM, Animesh Chaturvedi
> >>>>>>  wrote:
> >>>>>>> Folks
> >>>>>>>
> >>>>>>> Now that 4.2.0 VOTE has passed I want to call out for any
> >>>>>>> committers
> >>>>>> who are interested in taking over as the release manager for the
> >>>>>> upcoming 4.2.1 maintenance release and the 4.3.0 release.
> >>>>>>>
> >>>>>>>
> >>>>>>> Following our 4 month release cycle the feature freeze for
> >>>>>>> 4.3.0
> >>>>>> should be by end of October and as community we need to figure
> >>>>>> out the timelines for 4.2.1 maintenance release.
> >>>>>>>
> >>>>>>> I will update my experience and learning from the 4.2.0 release
> >>>>>>> in the
> >>>>>> wiki shortly after the formal release announcement  later this
> >> week.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Animesh
> >

RE: Volunteers to Complete the 4.2 Release Notes

[Animesh Chaturvedi]

> -Original Message-
> From: Abhinav Roy [mailto:abhinav@citrix.com]
> Sent: Monday, September 23, 2013 11:55 AM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Radhika
> Puthiyetath; Harikrishna Patnala
> Subject: RE: Volunteers to Complete the 4.2 Release Notes
> 
> Hi Milamber,
> 
> Created a defect for both the issues you pointed out at
> https://issues.apache.org/jira/browse/CLOUDSTACK-4728
> 
> Thanks and regards,
> Abhinav
> 
[Animesh>] Updated the release notes with this change

> -Original Message-
> From: Milamber [mailto:milam...@apache.org]
> Sent: Tuesday, September 24, 2013 12:08 AM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org; Radhika
> Puthiyetath; Harikrishna Patnala
> Subject: Re: Volunteers to Complete the 4.2 Release Notes
> 
> 
> Le 23/09/2013 18:47, Abhinav Roy a ecrit :
> > Yes , that’s true Milamber. It's my fault, Somehow I overlooked it.
> > But, the check for 8096 API port is already there for 4.1.x to 4.2
> upgrades.
> 
> Sure?
> 
> I've just found this in 4.1.x to 4.2 section:
> 10. Once you've upgraded the packages on your management servers, you'll
> need to restart the sys- tem VMs. Make sure port 8096 is open in your
> local host firewall to do this.
> 
> 
> In 3.0.2 to 4.2.0 section, I've found a good mention:
> 15. If you are upgrading from 3.0.2, perform the following:
> a. Ensure that the admin port is set to 8096 by using the
> "integration.api.port" global parameter.
> This port is used by the cloud-sysvmadm script at the end of the upgrade
> procedure. For infor-
> mation about how to set this parameter, see "Setting Global
> Configuration Parameters" in the
> Installation Guide.
> 
> 
> Milamber
> 
> 
> >
> > Thanks and regards,
> > Abhinav
> >
> > -Original Message-
> > From: Milamber [mailto:milam...@apache.org]
> > Sent: Monday, September 23, 2013 10:53 PM
> > To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Radhika
> Puthiyetath; Harikrishna Patnala
> > Subject: Re: Volunteers to Complete the 4.2 Release Notes
> >
> >
> > Le 23/09/2013 10:48, Abhinav Roy a ecrit :
> >> Hi,
> >>
> >> Here are some of the steps which are missing from the release notes,
> >>
> >> 1. Before upgrading from any version to 4.2 we need to register the
> new 4.2 systemvm templates .
> >>   This step is there in section 3.3 i.e for upgrade from 2.2.14
> to 4.2, but it is missing in section 3.1 and 3.2 .
> >> +  Name: systemvm-kvm-4.2.0
> >> +Description: systemvm-kvm-4.2.0
> > My upgrade test (from 4.1.1 to 4.2) have failed, because I used
> "systemvm-kvm-4.2.0" for the name of new system vm... (my system vms
> still in debian 6.0)
> >
> > Please Note:
> > The name for the new system vms (xen, kvm, vmware, etc) must be only
> "4.2" (not "4.2.0) at the end.
> >
> > 1) systemvm-xenserver-4.2
> > 2) systemvm-kvm-4.2
> > 3) systemvm-vmware-4.2
> > 4) systemvm-hyperv-4.2
> > 5) systemvm-lxc-4.2
> >
> > Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-3355
> > (close this issue?)
> >
> >
> >> Have you enabled the "integration.api.port" under Global Settings
> menu in CS management GUI? If not, set it to 8096, restart management
> and see if the problem goes away.
> > Add some lines to check if the key intergration.api.port is set to
> 8096 before the upgrade seems important too. (for section 4.1.x to 4.2)
> >
> >
> > Milamber
> >
> >
> >
> >
> >> 2. Section 3.1
> >>
> >>   Step 3&4 : it should be cloudstack-management and cloudstack-
> usage as the naming conventions have been changed from 4.1 onwards.
> >>
> >>   Step 6 : The cloudstack 4.2 repo has not been published yet,
> currently at http://cloudstack.apt-get.eu/ the repo is available only
> for 4.0.x and 4.1.x
> >>What Indira pointed to, needs to be removed,
> step 6.g) and 6.h) and step 8 also need to be removed
> >>   In step 6.f) It should be service cloudstack-
> agent  stop
> >>
> >>   Step 9.b) : It should be sudo yum upgrade cloudstack-client
> >>
> >>   Step 9.c) : it should be sudo yum upgrade cloudstack-agent
> and the following line is not required [[" During the installation of
> cloudstack-agent, the RPM will copy your agent.properties,log4j-
> cloud.xml, a

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

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 23, 2013 2:44 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> 
> I can change my vote to +1 if we include instructions similar to the
> following in the upgrade notes:
> 
> If using local storage on KVM, the local storage path needs to be
> changed in order to pass new validation. Remove any trailing slashes in
> the path column of the storage_pool table before starting agents.
> e.g.:
> 
> mysql -e 'update cloud.storage_pool set path="/var/lib/libvirt/images"
> where path="/var/lib/libvirt/images/"';
> 
> If using a custom path, insert your path in place of
> "/var/lib/libvirt/images/". If your custom path did not contain a
> trailing "/", there's no need to do this procedure.


[Animesh>] Marcus do you want to go ahead and update the Release Notes in 4.2 
branch  in file docs/en-US/Release_Notes.xml. I just finished making few other 
changes that were discussed. 

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

[VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

This vote has passed with no -1 votes.  

+1 votes were from (with * binding):
Chiradeep*, Hugo*, Chip*, Milamber,  Amogh

+0: Marcus*

Marcus agreed to change his VOTE to +1 with a Release Note change that he will 
make. 

Wido can you build and publish  the .deb packages

Thanks
Animesh

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

[RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

 
 This vote has passed with no -1 votes.
 
 +1 votes were from (with * binding):
 Chiradeep*, Hugo*, Chip*, Milamber,  Amogh
 
 +0: Marcus*
 
 Marcus agreed to change his VOTE to +1 with a Release Note change that
 he will make.
 
 Wido can you build and publish  the .deb packages
 
 Thanks
 Animesh
 
> > -Original Message-
> > From: Animesh Chaturvedi
> > Sent: Friday, September 20, 2013 8:36 PM
> > To: dev@cloudstack.apache.org
> > Subject: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> >
> >
> >
> >
> >
> > I've created a 4.2.0 release, with the following artifacts up for a
> > vote:
> >
> > Git Branch and Commit SH:
> > https://git-wip-
> > us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2
> > Commit: 69c459342c568e2400d57ee88572b301603d8686
> >
> > List of changes:
> > https://git-wip-
> > us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> >
> > PGP release keys (signed using 94BE0D7C):
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> > Testing instructions are here:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
> > oc
> > edure
> >
> > Vote will be open for 72 hours (Monday 9/23 PST EOD).
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> > indicate "(binding)" with their vote?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >

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

[Animesh Chaturvedi]

> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Tuesday, September 24, 2013 9:32 AM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> >
> > 1 - Finish the docs (release notes especially) and publish them to
> > cloudstack.apache.org/docs
> >
> >   *We need someone to own this*
> 
> I can do this, but it may be tomorrow before it gets done.
[Animesh>] I updated the RN yesterday. David what needs to be done to publish 
to cloudstack.apache.org/docs
> 
> >
> > 2 - Build the DEB packages
> >
> >   Wido has this one
> >
> > 3 - Build the RPM packages
> >
> >   *We need someone to own this one*
> 
> I'll take care of RPMs.
> 
> >
> > 4 - Move the source artifacts from dist/dev to dist/release and stage
> > the download page changes
> >
> >   A PMC member needs to do this.  I'll take this one.
> >
> > 5 - Finish the release announcement
> >
> >   This was started by Mathias here:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Ann
> > ouncement
> >
> >   It should really be finished.
> >
> >   *Someone needs to own finalizing this.*
> >
> > 6 - Publish the website and announce the release (using the finished
> > announcement) after 1 through 5 are done.
> >
> >   This can be any committer, but Animesh you'd probably want the
> honors!
[Animesh>] Chip for 6 can you clarify on what needs to be done to publish the 
website?
> >
> >
> > There are also other marketing related things to get done, but that
> > thread started on marketing@ and can happen after / in parallel to the
> > work listed above.
> >
> > -chip

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

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Tuesday, September 24, 2013 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> 
> Someone please check this, as I'm not familiar with the doc layout,
> especially trying to decipher it in xml.
> 
> commit to 4.2 branch: da56b6212bbcf9e363ba1add180516584a3d695b
> 
[Animesh>] I kicked off a new Release Note build on Jenkins, looking at the 
diff it should be fine

> On Mon, Sep 23, 2013 at 4:35 PM, Marcus Sorensen 
> wrote:
> > I think I'll wait until the vote passes, just to be sure that it won't
> > need to be backed out.
> >

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

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Tuesday, September 24, 2013 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> 
> Someone please check this, as I'm not familiar with the doc layout,
> especially trying to decipher it in xml.
> 
> commit to 4.2 branch: da56b6212bbcf9e363ba1add180516584a3d695b
[Animesh>] Marcus a minor xml closing tag was missed, I fixed and kicked off a 
new build. 
> 
> On Mon, Sep 23, 2013 at 4:35 PM, Marcus Sorensen 
> wrote:
> > I think I'll wait until the vote passes, just to be sure that it won't
> > need to be backed out.
> >
> > On Mon, Sep 23, 2013 at 3:47 PM, Animesh Chaturvedi
> >  wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >>> Sent: Monday, September 23, 2013 2:44 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> >>>
> >>> I can change my vote to +1 if we include instructions similar to the
> >>> following in the upgrade notes:
> >>>
> >>> If using local storage on KVM, the local storage path needs to be
> >>> changed in order to pass new validation. Remove any trailing slashes
> >>> in the path column of the storage_pool table before starting agents.
> >>> e.g.:
> >>>
> >>> mysql -e 'update cloud.storage_pool set
> path="/var/lib/libvirt/images"
> >>> where path="/var/lib/libvirt/images/"';
> >>>
> >>> If using a custom path, insert your path in place of
> >>> "/var/lib/libvirt/images/". If your custom path did not contain a
> >>> trailing "/", there's no need to do this procedure.
> >>
> >>
> >> [Animesh>] Marcus do you want to go ahead and update the Release
> Notes in 4.2 branch  in file docs/en-US/Release_Notes.xml. I just
> finished making few other changes that were discussed.
> >>
> >>>
> >>> On Mon, Sep 23, 2013 at 3:00 PM, Chiradeep Vittal
> >>>  wrote:
> >>> > +1 (binding)
> >>> >
> >>> > On 9/20/13 8:36 PM, "Animesh Chaturvedi"
> >>> > 
> >>> > wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>I've created a 4.2.0 release, with the following artifacts up for
> >>> >>a
> >>> vote:
> >>> >>
> >>> >>Git Branch and Commit SH:
> >>> >>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlo
> >>> >>g;h=
> >>> >>refs
> >>> >>/heads/4.2
> >>> >>Commit: 69c459342c568e2400d57ee88572b301603d8686
> >>> >>
> >>> >>List of changes:
> >>> >>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_pl
> >>> >>ain;
> >>> >>f=CH
> >>> >>ANGES;hb=4.2
> >>> >>
> >>> >>Source release (checksums and signatures are available at the same
> >>> >>location):
> >>> >>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> >>> >>
> >>> >>PGP release keys (signed using 94BE0D7C):
> >>> >>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >>> >>
> >>> >>Testing instructions are here:
> >>> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+tes
> >>> >>t+pr
> >>> >>oced
> >>> >>ure
> >>> >>
> >>> >>Vote will be open for 72 hours (Monday 9/23 PST EOD).
> >>> >>
> >>> >>For sanity in tallying the vote, can PMC members please be sure to
> >>> >>indicate "(binding)" with their vote?
> >>> >>
> >>> >>[ ] +1  approve
> >>> >>[ ] +0  no opinion
> >>> >>[ ] -1  disapprove (and reason why)
> >>> >>
> >>> >>
> >>> >

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Wednesday, September 25, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Cc: David Nalley
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> On Tue, Sep 24, 2013 at 07:12:15PM +, Animesh Chaturvedi wrote:
> > > I can do this, but it may be tomorrow before it gets done.
> > [Animesh>] I updated the RN yesterday. David what needs to be done to
> publish to cloudstack.apache.org/docs
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releasing+Docs
> 
> Animesh, are you able to take this?
[Animesh>] I don't have publican installed. Will give it a try and let you know 
if I run into issues. 

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

[Animesh Chaturvedi]

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

Hugo can you review this patch


- Animesh


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


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

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

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, September 25, 2013 1:15 PM
> To: dev@cloudstack.apache.org
> Cc: David Nalley
> Subject: RE: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> 
> 
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Wednesday, September 25, 2013 10:22 AM
> > To: dev@cloudstack.apache.org
> > Cc: David Nalley
> > Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> > round)
> >
> > On Tue, Sep 24, 2013 at 07:12:15PM +, Animesh Chaturvedi wrote:
> > > > I can do this, but it may be tomorrow before it gets done.
> > > [Animesh>] I updated the RN yesterday. David what needs to be done
> to
> > publish to cloudstack.apache.org/docs
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releasing+Docs
> >
> > Animesh, are you able to take this?
> [Animesh>] I don't have publican installed. Will give it a try and let
> you know if I run into issues.
[Animesh>] Chip couple of questions.

1. The referenced instructions call out to install Apache Cloudstack branding 
package? I see something in docs/publican-cloudstack directory. Is that the 
branding and needs to be installed by running "yum install 
publican-cloudstack"? Or just running publican build in doc directory will work
2. Which guides do we publish, the instructions mentions 4 which I think would 
be (ReleaseNotes, Install, Dev, Admin) . I see other .cfg files 
publican-all.cfg, publican-niciranvp.cfg and publican-midonet.cfg. Do we need 
to build them too. Atleast p-all.cfg should be built
3. In the "Install the documentation" step I am not clear what changes needed 
to be made to acsdocs.cfg.
 

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

[Animesh Chaturvedi]

+1 for accepting the donation

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

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Wednesday, September 25, 2013 2:05 PM
> To: dev@cloudstack.apache.org
> Cc: David Nalley
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> On Wed, Sep 25, 2013 at 08:59:49PM +, Animesh Chaturvedi wrote:
> > > [Animesh>] I don't have publican installed. Will give it a try and
> > > let you know if I run into issues.
> > [Animesh>] Chip couple of questions.
> >
> > 1. The referenced instructions call out to install Apache Cloudstack
> > branding package? I see something in docs/publican-cloudstack
> > directory. Is that the branding and needs to be installed by running
> "yum install publican-cloudstack"? Or just running publican build in doc
> directory will work 2. Which guides do we publish, the instructions
> mentions 4 which I think would be (ReleaseNotes, Install, Dev, Admin) .
> I see other .cfg files publican-all.cfg, publican-niciranvp.cfg and
> publican-midonet.cfg. Do we need to build them too. Atleast p-all.cfg
> should be built 3. In the "Install the documentation" step I am not
> clear what changes needed to be made to acsdocs.cfg.
> >
> >
> 
> Actually, nope.  Joe and / or Dave have been the ones to push the docs
> so far.  I'm in the same boat as you!
[Animesh>] I am happy to try and learn but looks like David we need your help 
to get this accomplished for now.

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, September 24, 2013 9:22 AM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> On Tue, Sep 24, 2013 at 04:21:19AM +, Animesh Chaturvedi wrote:
> >
> >
> >  This vote has passed with no -1 votes.
> >
> >  +1 votes were from (with * binding):
> >  Chiradeep*, Hugo*, Chip*, Milamber,  Amogh
> >
> >  +0: Marcus*
> >
> >  Marcus agreed to change his VOTE to +1 with a Release Note change
> > that  he will make.
> >
> >  Wido can you build and publish  the .deb packages
> 
> Animesh,
> 
> Just to help get things clearly listed, here are the todo's that I see
> for 4.2:
> 
> 1 - Finish the docs (release notes especially) and publish them to
> cloudstack.apache.org/docs
> 
>   *We need someone to own this*
[Animesh>] David I fixed up the ReleaseNotes and tried to follow the 
instruction on building the docs but not clear on few steps. Can you finish it 
up.
> 
> 2 - Build the DEB packages
> 
>   Wido has this one
> 
> 3 - Build the RPM packages
> 
>   *We need someone to own this one*
> 
> 4 - Move the source artifacts from dist/dev to dist/release and stage
> the download page changes
> 
>   A PMC member needs to do this.  I'll take this one.
> 
> 5 - Finish the release announcement
> 
>   This was started by Mathias here:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Annou
> ncement
> 
>   It should really be finished.
> 
>   *Someone needs to own finalizing this.*
[Animesh>] David, Chip Mathias has incorporated the comments received so far. 
What is pending here? The feature description is brief should we add more 
details?
> 
> 6 - Publish the website and announce the release (using the finished
> announcement) after 1 through 5 are done.
> 
>   This can be any committer, but Animesh you'd probably want the honors!
> 
> 
> There are also other marketing related things to get done, but that
> thread started on marketing@ and can happen after / in parallel to the
> work listed above.
> 
> -chip

RE: [ANNOUNCE] New committer: Rajesh Battala

[Animesh Chaturvedi]

Congrats Rajesh

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, September 24, 2013 8:30 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New committer: Rajesh Battala
> 
> The Project Management Committee (PMC) for Apache CloudStack has asked
> Rajesh Battala to become a committer and we are pleased to announce that
> they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the
> project and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Rajesh!
> 
> -chip
> on behalf of the CloudStack PMC

RE: Lines of contributed code

[Animesh Chaturvedi]

I used sloccount and it reports roughly 1.35 million lines of code without 
comments.


SLOCDirectory   SLOC-by-Language (Sorted)
651515  awsapi  java=651509,sh=6
142854  client  javascript=121639,python=11230,sh=6951,jsp=3007,
perl=27
127014  server  java=127009,sh=5
97243   plugins java=94186,python=2928,sh=129
75653   engine  java=75648,jsp=5
73218   testpython=65414,java=6910,sh=894
52898   api java=52869,python=29
28910   depsjava=28905,sh=5
17697   utils   java=17678,python=19
14923   corejava=14923
14730   ui  javascript=14730
11171   tools   python=9323,sh=1569,ruby=182,java=97
10949   servicesjava=8488,javascript=1611,sh=690,python=160
8572vmware-base java=8572
7085patches sh=6878,python=207
3761usage   java=3589,sh=172
3136agent   java=2533,sh=326,python=277
2921framework   java=2921
2877python  python=2601,sh=276
815 cloud-cli   python=815
755 packaging   sh=755
697 setup   python=697
592 awsapi-setupsh=530,python=62
56  debian  sh=56
11  docssh=11
0   agent-simulator (none)
0   build   (none)
0   developer   (none)
0   scripts (none)
0   target  (none)
0   top_dir (none)


Totals grouped by language (dominant language first):
java:   1095837 (81.17%)
javascript:137980 (10.22%)
python:   93762 (6.95%)
sh:   19253 (1.43%)
jsp:   3012 (0.22%)
ruby:   182 (0.01%)
perl:27 (0.00%)




Total Physical Source Lines of Code (SLOC)= 1,350,053
Development Effort Estimate, Person-Years (Person-Months) = 387.17 (4,646.00)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 5.16 (61.86)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 75.10
Total Estimated Cost to Develop   = $ 52,300,999
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."



> -Original Message-
> From: La Motta, David [mailto:david.lamo...@netapp.com]
> Sent: Thursday, September 26, 2013 9:39 AM
> To: dev@cloudstack.apache.org
> Subject: Lines of contributed code
> 
> Hey everybody, as an advocate of CloudStack for NetApp and our
> customers, I am often times asked to compare and contrast ACS with
> OpenStack.  One interesting metric that I am looking at right now is
> that OpenStack has about 1.7 million lines of contributed code.
> 
> How many can we say about CloudStack??
> 
> Thanks!
> 
> 
> David La Motta
> Technical Marketing Engineer - Citrix Solutions | NetApp
> Direct: 1.919.476.5042
> Mobile: 1.919.413.5600
> 
> [NetApp] [@virtualcrusader]
>   [LinkedIn]
> 
> [@virtualcrusader] 
> [dlamo...@netapp.com] 
> 

RE: Lines of contributed code

[Animesh Chaturvedi]

Looking at Chip's email, sloccount did not report HTML and CSS

Thanks
Animesh

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, September 26, 2013 9:53 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Lines of contributed code
> 
> I used sloccount and it reports roughly 1.35 million lines of code
> without comments.
> 
> 
> SLOCDirectory   SLOC-by-Language (Sorted)
> 651515  awsapi  java=651509,sh=6
> 142854  client  javascript=121639,python=11230,sh=6951,jsp=3007,
> perl=27
> 127014  server  java=127009,sh=5
> 97243   plugins java=94186,python=2928,sh=129
> 75653   engine  java=75648,jsp=5
> 73218   testpython=65414,java=6910,sh=894
> 52898   api java=52869,python=29
> 28910   depsjava=28905,sh=5
> 17697   utils   java=17678,python=19
> 14923   corejava=14923
> 14730   ui  javascript=14730
> 11171   tools   python=9323,sh=1569,ruby=182,java=97
> 10949   servicesjava=8488,javascript=1611,sh=690,python=160
> 8572vmware-base java=8572
> 7085patches sh=6878,python=207
> 3761usage   java=3589,sh=172
> 3136agent   java=2533,sh=326,python=277
> 2921framework   java=2921
> 2877python  python=2601,sh=276
> 815 cloud-cli   python=815
> 755 packaging   sh=755
> 697 setup   python=697
> 592 awsapi-setupsh=530,python=62
> 56  debian  sh=56
> 11  docssh=11
> 0   agent-simulator (none)
> 0   build   (none)
> 0   developer   (none)
> 0   scripts (none)
> 0   target  (none)
> 0   top_dir (none)
> 
> 
> Totals grouped by language (dominant language first):
> java:   1095837 (81.17%)
> javascript:137980 (10.22%)
> python:   93762 (6.95%)
> sh:   19253 (1.43%)
> jsp:   3012 (0.22%)
> ruby:   182 (0.01%)
> perl:27 (0.00%)
> 
> 
> 
> 
> Total Physical Source Lines of Code (SLOC)= 1,350,053
> Development Effort Estimate, Person-Years (Person-Months) = 387.17
> (4,646.00) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
> Schedule Estimate, Years (Months) = 5.16 (61.86)
> (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated
> Average Number of Developers (Effort/Schedule)  = 75.10
> Total Estimated Cost to Develop   = $ 52,300,999
> (average salary = $56,286/year, overhead = 2.40).
> SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open
> Source Software/Free Software, licensed under the GNU GPL.
> SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
> redistribute it under certain conditions as specified by the GNU GPL
> license; see the documentation for details.
> Please credit this data as "generated using David A. Wheeler's
> 'SLOCCount'."
> 
> 
> 
> > -Original Message-
> > From: La Motta, David [mailto:david.lamo...@netapp.com]
> > Sent: Thursday, September 26, 2013 9:39 AM
> > To: dev@cloudstack.apache.org
> > Subject: Lines of contributed code
> >
> > Hey everybody, as an advocate of CloudStack for NetApp and our
> > customers, I am often times asked to compare and contrast ACS with
> > OpenStack.  One interesting metric that I am looking at right now is
> > that OpenStack has about 1.7 million lines of contributed code.
> >
> > How many can we say about CloudStack??
> >
> > Thanks!
> >
> >
> > David La Motta
> > Technical Marketing Engineer - Citrix Solutions | NetApp
> > Direct: 1.919.476.5042
> > Mobile: 1.919.413.5600
> >
> > [NetApp]<http://netapp.com/> [@virtualcrusader]
> > <http://twitter.com/virtualcrusader>  [LinkedIn]
> > <https://www.linkedin.com/profile/view?id=4658253&trk>
> > [@virtualcrusader] <https://plus.google.com/110793446514662070219>
> > [dlamo...@netapp.com] <mailto:david.lamo...@netapp.com>
> >

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

+1

Ilya I am glad that you brought it up and recognize the challenge. I survived 
on 3 cups of JetFuel[1] every day for last 3 months. It's like doing two 
$dayjob$ shifts

http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-people

 

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 9:02 AM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Release Managers for future ACS releases - enhacement
> 
> I apologize in advance if this is a repeat of something that was
> previously stated.
> 
> As Animesh learned recently with ACS 4.2, RM work for major versions
> takes a lot of effort, to lesser extent the 4.2.x minor release may not
> be as involved, but still decent amount of work.
> 
> What complicates the matter further, is many of us have $dayjobs$ that
> don't emphasize heavy involvement on ACS.
> 
> Perhaps we can revisit the strategy and have 2 -3 release managers for
> major version and 1-2 for minor.
> 
> Obviously, one is going the be a Lead RM, and others will be secondary
> but also involved.
> 
> Any thoughts on this approach?
> 
> Thanks
> ilya

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Thursday, September 26, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> Agreed.  If you look at what a release manager has to do today
> 
> - triage bugs
> - follow up on reviews and ask people to commit them
> - cherry-pick fixes
> 
> To me it is a lot of work for one person to do for CloudStack.  We can
> certainly divide up the work.  For example,
> 
>  - One RM is responsible for overall release
>  - One RM is responsible for following up on review board
>  - Two or three RMs is responsible for triaging bugs
>  - One is responsible for cherry-pick
> 
> I also like to propose that we stop the practice of only assigning bugs
> to yourself.  I know it's there to make sure there's no cookie-licking
> but really let's not make ourselves less efficient just for the sake of
> appearances.   RMs should be able to assign bugs as part of the process
> to ask for someone to look at the bug rather than having to ask
> privately and have the person assign to themselves.  Keeping track of
> such things with the amount of changes CloudStack goes through in a
> release just makes us less efficient and less enjoyable to work on
> CloudStack.
> 
> --Alex
[Animesh>] Alex thanks for bringing this up I was going to reopen the "Do not 
assign tickets to people" thread after 4.2 is announced. To set the perspective 
4.2 was a huge release whereas community  fixed 1900+ issues in 7 months. That 
speaks a lot about the vibrancy of our community but as a release manager not 
being able to assign the bugs was a huge hindrance.  I had to export all the 
data out every day in excel run pivots and follow through in private emails and 
keep an inventory on which one did not get responded to in offline 
spreadsheets. It is so much easier to use JIRA and keep the whole context in 
one place and also it makes all the effort towards shipping a release  
transparent and public.

If you look in JIRA we have over 250 unassigned issues that were create over 6 
months ago and over 700 open unassigned issues, without active triage and the 
ability to assign our backlog will continue to grow.


Thanks
Animesh


> 
> > -Original Message-
> > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > Sent: Thursday, September 26, 2013 9:02 AM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > I apologize in advance if this is a repeat of something that was
> > previously stated.
> >
> > As Animesh learned recently with ACS 4.2, RM work for major versions
> > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > not be as involved, but still decent amount of work.
> >
> > What complicates the matter further, is many of us have $dayjobs$ that
> > don't emphasize heavy involvement on ACS.
> >
> > Perhaps we can revisit the strategy and have 2 -3 release managers for
> > major version and 1-2 for minor.
> >
> > Obviously, one is going the be a Lead RM, and others will be secondary
> > but also involved.
> >
> > Any thoughts on this approach?
> >
> > Thanks
> > ilya

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

I have not thought through it all, but some quick comments for now, I will come 
back and refine tomorrow or later tonight

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 4:06 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was
> involved in past.
> 
> Here is a bit of uncharted territory we need to address about bug
> assignment.
> 
> In past I've seen folks ask - we have X number of bugs that need to be
> triaged, who can take what? Are we still keeping this framework and do
> we default to whoever wrote the code/patch initially - if no one
> volunteers?
[Animesh>] We have list of maintainers by component that may be something to 
start with. This does not mean they have to do it, but they can call back and 
say I do not have time right now can someone else look into it. Or if an 
assigned issue is not worked on for a week it automatically gets unassigned, 
would need to check on JIRA support for the workflow, having  played with JIRA 
at least such reports are easy to generate.
> 
> While Citrix is one of the main supporters of CloudStack project and has
> people employed to do development, how does one - who has no insight
> into Citrix - assign bugs to people who are employed by Citrix (and can
> we even do that without their full consent)?
> 
[Animesh>] We can look up the maintainers list by component and I can 
facilitate within Citrix. Even for the prior release I have received emails 
from nonCitrix community members to follow through with Citrix folks.

> One other part, since Citrix and other companies have QA teams, perhaps
> we can have a closer collaboration as to what testing was done on Citrix
> side when it comes to major releases? (i.e. ACS 4.2 release)
> 
[Animesh>] Yes, QA contributors have published test plans and Sudha has called 
out help with QA tasks in community. Alex, Amogh, Frank and Prasanna are 
working on a test infrastructure design that can be replicated across sites to 
make testing simpler for anyone who wants or can contribute. You should see a 
proposal on that soon.


> I know in past Citrix would branch of from ACS or even have a separate
> codebase, but with future releases, its all going to be one ACS code
> base. So future actual release testing/qa (not automated as part of
> built process) should get easier since we have folks dedicated to work
> on ACS project to do QA or is this an incorrect assumption?
> 
[Animesh>] We are aligned already from code perspective and you would have seen 
huge QA engagement in 4.2 . I wanted to call out like every place there is no 
Elastic human capital available so as a community we have to reduce the 
reliance on just Citrix QA. Citrix QA is a good community citizen but will 
naturally focus on Citrix priorities first. If you contribute a code to 
CloudStack ideally you should be prepared to maintain and test as well. 
Community testing is indeed needed for this project.

> I am also under impression it would help to have at least one person
> from Citrix on RM team, helps with communication, as they can tap people
> by other means other than mailing lists.
[Animesh>] Yes I am always there to facilitate with community. Sudha, Abhi and 
Ram Ganesh are also available to help out. 
> 
> There are a lot of assumptions here, I could be wrong on all or some of
> these, please clarify or voice your opinion.
[Animesh>] Thanks for bringing up these issues they are all valid and its best 
to clear out any expectations.
> 
> Thanks
> ilya
> 
> 
> 
> 
> 
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Thursday, September 26, 2013 5:25 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > +1
> >
> > Ilya I am glad that you brought it up and recognize the challenge. I
> > survived on 3 cups of JetFuel[1] every day for last 3 months. It's
> > like doing two $dayjob$ shifts
> >
> > http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-
> > people
> >
> >
> >
> > > -Original Message-
> > > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > > Sent: Thursday, September 26, 2013 9:02 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: [DISCUSS] Release Managers for future ACS releases -
> > > enhacement
> > >
> > > I apologize in advance if this is a repeat of something that was
> > > previously stated.
> > 

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, September 24, 2013 9:22 AM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> 5 - Finish the release announcement
> 
>   This was started by Mathias here:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Annou
> ncement
> 
>   It should really be finished.
> 
>   *Someone needs to own finalizing this.*
> 
> 6 - Publish the website and announce the release (using the finished
> announcement) after 1 through 5 are done.
> 
>   This can be any committer, but Animesh you'd probably want the honors!
> 
> 
[Animesh>] Chip so should I go ahead and publish the website? For the 
announcement tomorrow, I have to send an email to dev, user, marketing mailing 
list at 7 AM PST (10 AM EST) right? Let me know if I missed anything

> There are also other marketing related things to get done, but that
> thread started on marketing@ and can happen after / in parallel to the
> work listed above.
> 
> -chip

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Monday, September 30, 2013 11:55 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> On Mon, Sep 30, 2013 at 06:48:00PM +, Animesh Chaturvedi wrote:
> > [Animesh>] Chip so should I go ahead and publish the website? For the
> > announcement tomorrow, I have to send an email to dev, user, marketing
> > mailing list at 7 AM PST (10 AM EST) right? Let me know if I missed
> > anything
> 
> Please don't do the website yet.  We've discussed on marketing@, and
> I'll take care of publishing it tomorrow at 9 AM ET (6 AM PT).
> 
> I will also publish the announcement to the CloudStack blog at 10 AM ET
> (concurrent with you emailing the announcement out), and do some
> tweeting from @CloudStack.
> 
> As for the announcement, it should go out in separate emails to the
> following lists:
> 
> us...@cloudstack.apache.org
> d...@cloudstack.apacehe.org
> annou...@cloudstack.apache.org
> annou...@apache.org
> 
> The announcement email should be sent from your *apache.org* email
> address.
> 
[Animesh>] Done sent the release announcement.

> Let me know if you have any issues!
> 
> -chip

RE: Announcement emails...

[Animesh Chaturvedi]

Ok will resend them with links in few minutes. Formatting the text with all  
the 6 links..

From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Tuesday, October 01, 2013 7:18 AM
To: Animesh Chaturvedi; 
Subject: Announcement emails...

Animesh,

I've not moderated the emails through, hoping that I can get you to re-send 
them to include URLs for our site and the download page.

-chip

RE: [ANNOUNCE] New PMC member: Daan Hoogland

[Animesh Chaturvedi]

Congrats Daan

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, October 01, 2013 7:48 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New PMC member: Daan Hoogland
> 
> The Project Management Committee (PMC) for Apache CloudStack has asked
> Daan Hoogland to join the PMC and we are pleased to announce that they
> have accepted.
> 
> Join me in congratulating Daan!
> 
> -The CloudStack PMC

RE: Unable to create instance after upgrading to CloudStack 4.2.0

[Animesh Chaturvedi]

Copying Sanjay

Animesh

> -Original Message-
> From: Indra Pramana [mailto:in...@sg.or.id]
> Sent: Tuesday, October 01, 2013 11:06 AM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: Re: Unable to create instance after upgrading to CloudStack
> 4.2.0
> 
> Dear all,
> 
> Further investigation reveals that there might be some issues with the
> schema upgrade. When we check the resource_count table for the account
> ID:
> 
> mysql> select * from resource_count where account_id=2;
> +++---+---+---+
> | id | account_id | domain_id | type  | count |
> +++---+---+---+
> | 17 |  2 |  NULL | user_vm   |30 |
> | 18 |  2 |  NULL | public_ip | 4 |
> | 19 |  2 |  NULL | volume|40 |
> | 20 |  2 |  NULL | snapshot  | 1 |
> | 21 |  2 |  NULL | template  |40 |
> | 22 |  2 |  NULL | project   | 0 |
> | 23 |  2 |  NULL | network   | 2 |
> | 24 |  2 |  NULL | vpc   | 0 |
> +++---+---+---+
> 
> There's no 'primary_storage' type there. In comparison, Abhinav's
> database contains the details:
> 
> mysql> SELECT * FROM cloud.resource_count where account_id=2;
> +++---+---+-+
> | id | account_id | domain_id | type  | count   |
> +++---+---+-+
> | 17 |  2 |  NULL | user_vm   |   4 |
> | 18 |  2 |  NULL | public_ip |   1 |
> | 19 |  2 |  NULL | volume|   3 |
> | 20 |  2 |  NULL | snapshot  |   3 |
> | 21 |  2 |  NULL | template  |   1 |
> | 22 |  2 |  NULL | project   |   0 |
> | 23 |  2 |  NULL | network   |   2 |
> | 24 |  2 |  NULL | vpc   |   1 |
> | 33 |  2 |  NULL | cpu   |   2 |
> | 34 |  2 |  NULL | memory|1536 |
> | 35 |  2 |  NULL | primary_storage   |  8589934592 |
> | 36 |  2 |  NULL | secondary_storage | 27866955776 |
> +++---+---+-+
> 
> These types are missing from my resource_count table for each of the
> accounts:
> 
> | 33 |  2 |  NULL | cpu   |   2 |
> | 34 |  2 |  NULL | memory|1536 |
> | 35 |  2 |  NULL | primary_storage   |  8589934592 |
> | 36 |  2 |  NULL | secondary_storage | 27866955776 |
> 
> I tried to re-do the schema upgrade manually pertaining to that
> particular table, which is part of this section under:
> 
> /usr/share/cloudstack-management/setup/db/schema-410to420.sql
> 
> DROP VIEW IF EXISTS `cloud`.`account_view`; CREATE VIEW
> `cloud`.`account_view` AS
> 
> But I am still not able to get the four types (cpu, memory,
> primary_storage, secondary_storage) to appear on my resource_count
> table.
> 
> Anyone can help? This is my third attempt to upgrade to 4.2.0 and I
> don't want to revert back again now.
> 
> Looking forward to your reply, thank you.
> 
> Cheers.
> 
> 
> 
> On Wed, Oct 2, 2013 at 12:49 AM, Indra Pramana  wrote:
> 
> > Dear all,
> >
> > I am having problems of unable to create new instances after upgrading
> > to 4.2.0. The error message is:
> >
> > Failed to increment resource count of type primary_storage for account
> > id=2
> >
> > Excerpt from management-server.log:
> >
> > 
> > 2013-10-02 00:40:57,770 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-15:null) ===START===  -- GET
> > command=queryAsyncJobResult&jobId=183063da-fb08-425b-8057-157e33320674
> > &response=json&sessionkey=VEyky3f1rsQVfLVs9pGg2sXh60o%3D&_=13806456467
> > 39
> > 2013-10-02 00:40:57,785 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEntity name
> > is:com.cloud.offering.ServiceOffering
> > 2013-10-02 00:40:57,791 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.template.VirtualMachineTemplate
> > 2013-10-02 00:40:57,795 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) ControlledEntity name
> > is:com.cloud.network.Network
> > 2013-10-02 00:40:57,798 DEBUG [cloud.api.ApiDispatcher]
> > (catalina-exec-16:null) InfrastructureEnt

RE: Post-release work

[Animesh Chaturvedi]

> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Wednesday, October 02, 2013 7:22 AM
> To: dev@cloudstack.apache.org
> Subject: Post-release work
> 
> As previously discussed, now that 4.2 is released, I moving docs to
> their own repo.
> 
> https://git-wip-us.apache.org/repos/cloudstack-docs.git
> 
> For present, I am pushing the 4.2 docs into a 4.2 branch, and will deal
> with master in a bit.
> 
> 
> We also need to merge anything in 4.2-forward into 4.2 and purge 4.2-
> forward as we prepare for 4.2.1.
[Animesh>] Yes I plan to do it later today.
> 
> --David

RE: [DISCUSS] Breaking out Marvin from CloudStack

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Wednesday, October 02, 2013 1:10 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
> 
> On Wed, Oct 02, 2013 at 07:38:33PM +, Alex Huang wrote:
> > I don't really understand what purpose would this serve.  Would we
> ever use newer marvin against older CloudStack or vice versa?  What's
> the benefit?
> >
> > I can understand it for cloudmonkey because cloudmonkey is an admin
> cli tool and reving it differently is not a bad idea.  I just don't see
> it for marvin and, especially for the tests.
> >
> > --Alex
> 
> IMO, we should consider Marvin the "framework" to be the thing to break
> out, and the tests should be different from the framework.
> 
> Now that leads to the question: to test or not to test (in the main
> repo)?
> 
> I'd suggest that *tests* belong in the main repo, because they are tied
> to the software's capabilities and versions.
> 
> The Marvin framework, on the other hand, since the re-work that Prasanna
> did, is mostly distinct (and uses API discovery).
> 
> Anyone else agree?
[Animesh>] I agree tests belong in the main repo. Breaking up the marvin 
framework gives flexibility in its usage beyond cloudstack and separate release 
cycle.

RE: [DISCUSS] Components in JIRA and bug assignment

[Animesh Chaturvedi]

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Wednesday, October 02, 2013 3:15 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Components in JIRA and bug assignment
> 
> I would like to separate this thread on tickets assignments in JIRA.
> 
> Previously it was mentioned that we can add additional components into
> JIRA CLOUDSTACK project and have ticket default to maintainer of the
> component - who can then assign it to a proper developer.
> 
[Animesh>] Yes JIRA allows adding a component lead. I can add components and 
the primary lead if the community agrees to it. This will be based on our 
maintainers list [1]

> What do you think?
[Animesh>]+1,  I had brought up the same idea in the thread [2] and that time 
it was not approved by the community. With my experience from 4.2.0 I would 
like it to be reconsidered.

> 
> Any other suggestions?
> 
[Animesh>] In the thread [3] I had also called out the email subscriptions for 
each of the components based on JIRA filter, but at that time I did not get 
much response.
 
> If agreed, who has the karma in JIRA to do this?
[Animesh>] There are few folks that have Admin access to JIRA including me. 
Alex, David, Chip are ofcourse administrators.
> 
> What components we need to add or remove to lower the confusion?
[Animesh>] We should review the current component list and refine them. Some of 
them are over used like "management Server" as Sheng mentioned in the other 
thread.
> 
> Last but not least, if someone can explain how bug reporter would
> identify the proper component, we can then post it on WIKI and minimize
> the error rate caused by improper bug filling.
[Animesh>] We can add a description column in [1] to provide description for 
the components.

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainers+Per+Component
[2] http://markmail.org/thread/btovj6t6opqxge5q 
[3] http://markmail.org/thread/2gm4lq3lgfdzeo53

RE: Post-release work

[Animesh Chaturvedi]

I merged 4.2-forward into 4.2 last night. I will keep 4.2-forward around for 
couple of days just in case something is missed. I will send a separate email 
to mailing list that 4.2 is now open for checkin and do not checkin into 
4.2-forward.

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, October 02, 2013 12:13 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Post-release work
> 
> 
> 
> > -Original Message-
> > From: David Nalley [mailto:da...@gnsa.us]
> > Sent: Wednesday, October 02, 2013 7:22 AM
> > To: dev@cloudstack.apache.org
> > Subject: Post-release work
> >
> > As previously discussed, now that 4.2 is released, I moving docs to
> > their own repo.
> >
> > https://git-wip-us.apache.org/repos/cloudstack-docs.git
> >
> > For present, I am pushing the 4.2 docs into a 4.2 branch, and will
> > deal with master in a bit.
> >
> >
> > We also need to merge anything in 4.2-forward into 4.2 and purge 4.2-
> > forward as we prepare for 4.2.1.
> [Animesh>] Yes I plan to do it later today.

> >
> > --David

4.2-forward branch is now merged into 4.2 branch

[Animesh Chaturvedi]

Folks

Last night I merged 4.2-forward branch into 4.2 branch. So from now on 4.2 
branch is available for bug fixes and will be the branch from which 4.2.1 will 
be released. 

Do not make any new checkins into 4.2-forward branch. I will keep 4.2-forward 
around for a few days just in case and will be deleted after that.

Thanks
Animesh

RE: [ACS4.2.1] UI tickets

[Animesh Chaturvedi]

Abhi

It is best to set up a shared filter. You will need to open a INFRA ticket like 
this one https://issues.apache.org/jira/i#browse/INFRA-6145 to get relevant 
permissions for the JIRA


Thanks
Animesh


> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Friday, October 04, 2013 6:14 AM
> To: dev@cloudstack.apache.org
> Cc: Brian Federle; Jessica Wang; Sonny Chhen
> Subject: Re: [ACS4.2.1] UI tickets
> 
> Yes, specially the one in CC.
> 
> On 04/10/13 6:16 pm, "Sudha Ponnaganti" 
> wrote:
> 
> >Do you mean UI guys??
> >
> >-Original Message-
> >From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> >Sent: Friday, October 04, 2013 4:54 AM
> >To: CloudStack Dev
> >Cc: Brian Federle; Jessica Wang; Sonny Chhen
> >Subject: [ACS4.2.1] UI tickets
> >
> >
> >There are around ~72 UI tickets open. Most of them are major, can
> >documentation guys go thru the tickets and start picking them.
> >
> >Following Jira query will give the tickets that are open.
> >
> >project = CLOUDSTACK AND resolution = Unresolved AND fixVersion in
> >("4.2.0", "4.2.1") AND text ~ "UI"
> >
> >-abhi

RE: [DISCUSS] Components in JIRA and bug assignment

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, October 04, 2013 10:28 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> 
> On Fri, Oct 04, 2013 at 05:11:32PM +, Musayev, Ilya wrote:
> > Question to JIRA experienced admins, we can preserve "assign to me"
> option, and if unassigned goto "component" maintainer?
> 
> Absolutely.  Initial assignment does not equal the actual assignee.
> Component-based assignment is just a way to skip the unassigned phase,
> but people can reassign to themselves or others.
> 
> -chip
[Animesh>] Chip does that mean you are open to folks assigning tickets to 
others? Should this be posted in the original thread 
http://markmail.org/thread/btovj6t6opqxge5q. because the threads where Ilya 
reopened the discussion has received few responses from Alex, Sheng, Alena, 
Sudha, RamG

RE: [DISCUSS] Components in JIRA and bug assignment

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, October 04, 2013 10:45 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> 
> On Fri, Oct 04, 2013 at 05:40:06PM +, Animesh Chaturvedi wrote:
> >
> > [Animesh>] Chip does that mean you are open to folks assigning tickets
> > to others? Should this be posted in the original thread
> > http://markmail.org/thread/btovj6t6opqxge5q. because the threads where
> > Ilya reopened the discussion has received few responses from Alex,
> > Sheng, Alena, Sudha, RamG
> >
> 
> No, that just means that I was explaining the technical capabilities of
> Jira.
> 
> I'm -0, so move forward if everyone else continues to agree.  I still
> don't think it's the right way to operate, but I'm not interested in
> blocking it if everyone else wants to do it this way.
> 
> I won't reiterate my previous reasoning, since you pointed to that
> thread.
> 
> Cheers!
> 
> -chip
[Animesh>] Chip  I get the principle behind the reasoning in  thread[2] which 
should be maintained but at the same time not being able to assign the issues 
is a big hindrance in running a release. I am not sure if you saw my response 
in this thread [1] started by Ilya which was based on my experience as RM for 
4.2.0 


I am +1 on the proposal

[1] http://markmail.org/thread/cwxxxjnkor6trq4s 
[2] http://markmail.org/thread/btovj6t6opqxge5q

RE: [DISCUSS] Components in JIRA and bug assignment

[Animesh Chaturvedi]

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Friday, October 04, 2013 12:10 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Components in JIRA and bug assignment
> 
> Response in line:
> 
> > -Original Message-
> > From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
> > Sent: Friday, October 04, 2013 2:02 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [DISCUSS] Components in JIRA and bug assignment
> >
> > Not Sure, if it falls under similar lines\requires a separate thread.
> > I am trying to see if there is a way we can add  a component field,
> > primary owner fields for component  available to be assigned for a
> > given review under Http://reviews.apache.org.
> 
> While we want to extend JIRA and add various components to address
> current limitations, I'm not certain if this is in the same scope. I
> also have to admit, that I only use JIRA as basic user, so I don't know
> if what you are asking is doable. Perhaps someone else can?
> 
[Animesh>] Reviews are managed in separate tool called ReviewBoard
> 
> >
> > This way i will select component as "Automation", branch as "4.1" and
> > so etc , save that query on my dashboard and everytime i login, i can
> > see reviews based upon my query saved.
> 
> We can create a separate component Automation, so you can create filters
> as described.
> 
[Animesh>] JIRA already has a component for Automation. Santhosh you should 
open a separate thread for review board enhancements

> >
> > If this facility is already there, then i will search more to find it
> out.
> >
> > Regards,
> > Santhosh
> > 
> > From: Chip Childers [chip.child...@sungard.com]
> > Sent: Friday, October 04, 2013 1:45 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> >
> > On Fri, Oct 04, 2013 at 05:40:06PM +, Animesh Chaturvedi wrote:
> > >
> > > [Animesh>] Chip does that mean you are open to folks assigning
> > > tickets to others? Should this be posted in the original thread
> > > http://markmail.org/thread/btovj6t6opqxge5q. because the threads
> > where
> > > Ilya reopened the discussion has received few responses from Alex,
> > > Sheng, Alena, Sudha, RamG
> > >
> >
> > No, that just means that I was explaining the technical capabilities
> of Jira.
> >
> > I'm -0, so move forward if everyone else continues to agree.  I still
> > don't think it's the right way to operate, but I'm not interested in
> > blocking it if everyone else wants to do it this way.
> >
> > I won't reiterate my previous reasoning, since you pointed to that
> thread.
> >
> > Cheers!
> >
> > -chip
> 

RE: [DISCUSS] Breaking out Marvin from CloudStack

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, October 04, 2013 1:53 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
> 
> 
> Fair warning - some of this is a straw man argument to explore the
> situation, and a little bit of ranting at the end.
> 
> On Fri, Oct 04, 2013 at 05:57:58PM +0530, Prasanna Santhanam wrote:
> > I'll summarize and address the concerns raised so far.
> >
> > Marvin has been in this repo for a long time for us to start writing
> > tests. The only tests I've seen coming are from a specific set of
> > people focussed on QA efforts.
> 
> I agree - and that's a problem.  New features should *ALL* have tests
> before they merge into master.  I think that assuming that the only test
> writers are a group of folks that write the tests today is actually a
> larger problem.

> 
> > I want to reduce the impediment for
> > people who are writing tests *today*. Those looking to get started in
> > the near future won't have any new learning to do, just that their
> > code goes in an alternate repo that is pointed to right
> > infrastructure.
> >
> > Automated testing also works in a push-to-production style very often.
> > Testers need to run their tests on a deployed environment(s) quickly
> > to be able to ensure it is valid and passes. By making them go through
> > reviewboard each time for each test we massively slow down the
> > process. (tons of fixes to tests are on rb today, not just new tests).
> > We don't know if they run until they run on the environment.
> 
> I want to be clear about this part - a different repo doesn't change the
> need for someone to be a committer to commit.
> 
[Animesh>] Test code contribution is similar to code contribution and the issue 
is not reviewboard but folks not responding to reviews. We need to address them 
as community. If we have to get new committers we should bring them forward.

> There's a thread on private@ that you should weigh in on here.  If we
> have more people that should be committers, then let's get *that* done.
> 
> >
> > Reason for tests and framework to go together is simple.  If I go look
> > at the jclouds repository today I find tests for rackspace cloud,
> > openstack cloud, cloudstack cloud, euca clouds in the jclouds
> > repository and not in the respective provider/project repository. A
> > newcomer to the marvin repository will be someone interested in
> > writing tests and he will also thus be able to find tests in the
> > marvin repository.
> >
> > This also allows for more heterogenous testing of cloudstack. No one
> > needs to be tied down to a framework / tool to write integration
> > tests. If python is not your forte, use Chip's ruby client, or perhaps
> > in the near future Chiradeep's stackmate to write your test, or even
> > jclouds.
> 
> But that's actually true today, right?  I mean if I wanted to write an
> integration test using some other method, I'd do that...  but would it
> be useful for others?  Probably not!  That's because the way that we do
> testing of this type is via Marvin.  The Citrix infra wouldn't be setup
> for whatever other framework I used, and the community as a whole would
> get less benefit than if I was consistent.
> 
[Animesh>] I agree having consistent tooling shortens the learning cycle for 
new contributors
> >
> > Now the question of supporting older version of marvin against newer
> > versions of cloudstack. Marvin now fully auto-generates itself (see
> > the design in the proposal) based on endpoint. So you have the marvin
> > version that will work with your endpoint only. As for being backwards
> > compatible (also addressed in the design doc) - no old tests are
> > broken, they will still run perfectly fine.
> >
> 
> That's marvin, not the tests, right?  If I add a new feature for 4.3,
> should that test appear in a 4.2 run?  Aren't we aiming for (I know
> we're not there) a situation where *all* tests pass before we release?
> IMO not versioning the tests (not the Marvin framework) with the target
> of the tests is confusing.
> 
[Animesh>] IMO "Things that change together, should live together", separate 
repo for tests does not sit well


> > The infrastructure (currently) only looks at the changes in the test
> > directory before performing a run. It doesn't care whether server/ was
> > changed or plugins/x/y/z was changed. That's because the tests are
> > unrelated to what is in the rest of 

RE: [DISCUSS] Breaking out Marvin from CloudStack

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Saturday, October 05, 2013 3:22 AM
> To: dev
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
> 
> H Chip,
> 
> As a feature-dev driven by a 150-man-strong-cloud-operator-base that is
> not interested in anything but me showing that they can work with what
> they asked for:
> 
> On Fri, Oct 4, 2013 at 10:52 PM, Chip Childers
> wrote:
> ...
> 
> > On Fri, Oct 04, 2013 at 05:57:58PM +0530, Prasanna Santhanam wrote:
> > > I'll summarize and address the concerns raised so far.
> > >
> > > Marvin has been in this repo for a long time for us to start writing
> > > tests. The only tests I've seen coming are from a specific set of
> > > people focussed on QA efforts.
> >
> > I agree - and that's a problem.  New features should *ALL* have tests
> > before they merge into master.  I think that assuming that the only
> > test writers are a group of folks that write the tests today is
> > actually a larger problem.
> >
> 
> Yes and we will need to work down a backlog of scenarios before we ever
> can rely on guys like me doing that. Not because they won't but because
> there is to much to write tests for edging on the new features they
> write. Just because those tests aren't there yet. I think giving Citrix
> QA a repo to work on is fine but I would like to see it merged back at
> some point and a continued possibility to write them in the main tree.
> 
[Animesh>] While I don't agree to a separate repo for tests (marvin framework 
is ok) I do want to call out the proposal is not for giving Citrix QA a repo to 
work on and I don't think Prasanna meant that way. 

> >
> > > I want to reduce the impediment for
> > > people who are writing tests *today*. Those looking to get started
> > > in the near future won't have any new learning to do, just that
> > > their code goes in an alternate repo that is pointed to right
> > > infrastructure.
> >
> @prasanna: education of the developers is also something to consider. I
> know I could contribute more to integration and at Schuberg Philis we
> have some work going on in that direction. It would be nice to see easy
> integration of this with the Citrix work.
> 
> 
> >
> ...
> 
> > >
> > > Reason for tests and framework to go together is simple.
> >
> Guys, why not both. some general tests that will be valid for any ACS
> version can go in the marvin code base. Others that change over time
> should be tied to the version of ACS they apply to.
> 
> Test can be moved from one repo to the other if needed.
> 
> ...
> 
> >
> > That's marvin, not the tests, right?  If I add a new feature for 4.3,
> > should that test appear in a 4.2 run?  Aren't we aiming for (I know
> > we're not there) a situation where *all* tests pass before we release?
> > IMO not versioning the tests (not the Marvin framework) with the
> > target of the tests is confusing.
> >
> That I agree with completely.
> 
> 
> > > The infrastructure (currently) only looks at the changes in the test
> > > directory before performing a run. It doesn't care whether server/
> > > was changed or plugins/x/y/z was changed. That's because the tests
> > > are unrelated to what is in the rest of the repository. In fact you
> > > can't even run them without a deployed cloud. So I don't see why
> > > idle code should lie in the repo.
> >
> You can trigger the building of a cloud when code changes and run the
> tests against that.
> 
> >  >
> > > Integration tests are essential, they will keep coming as long as
> > > Citrix QA is invested in the effort, but they need to come faster
> > > into the repos and that will be addressed by the separation IMO.
> >
> > How?
> >
> > > Managing
> > > the feature submitted to cloudstack against tests submitted to
> > > marvin is not a hard thing to do. We simply mirror the release
> > > branches in marvin and submit tests there. In fact I wonder why we
> > > didn't have this question when docs were separated? It doesn't work
> > > any differently really.
> >
> > Well, it turns out that docs are absolutely not being done before code
> > comes into master.  I dislike this fact, but live with it.
> >
> I don't see why a feature has to be published when it is implemented. So
> I don't agree on the docs. The great advantage of hidden features is
> that y

RE: [DISCUSS] Components in JIRA and bug assignment

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Sunday, October 06, 2013 12:16 PM
> To: dev
> Cc: Musayev, Ilya
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> 
> I have doubts about this thought it would seem productive. It constructs
> a small assignment hierarchy in the community which feels fine for any
> company project I have worked on in the past.
> 
> It feels out of place.
> . Are those component maintainers going to have monopoly on assigning
> tickets pertaining to 'their' component?
[Animesh>] There is no monopoly or hierarchy, everyone is equal. When someone 
asks another person to pick up an issue it is a request not an assignment. They 
can always say they can't and unassign with comments
> . as a featurist: a ticket will usually pertain to several components.
> it can be for instance UI - API - orchestration - provisioning - network
> - storage. I would think the person entering the ticket has the
> responsibility of finding devs/assigning the work. (dis)agree?
> 
[Animesh>] That's reasonable for a ticket created by a QA member of the 
community but for tickets coming from users they may not know who should those 
be assigned and we would like to lower the barrier of entry for users reporting 
the defects.

> I actually prefer unassigned tickets and a irc meeting like discussion
> on them once in a while.
> 
> just €0,02
> Daan
> 
> 
> 
> On Sun, Oct 6, 2013 at 6:08 AM, Rajesh Battala
> wrote:
> 
> > +1 for the proposal.
> >
> > -Original Message-
> > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> > Sent: Saturday, October 5, 2013 12:42 AM
> > To: dev@cloudstack.apache.org; Musayev, Ilya
> > Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> > Importance: High
> >
> > On 10/4/13 10:37 AM, "Musayev, Ilya"  wrote:
> >
> > >> On Fri, Oct 04, 2013 at 05:11:32PM +, Musayev, Ilya wrote:
> > >> > Question to JIRA experienced admins, we can preserve "assign to
> me"
> > >> option, and if unassigned goto "component" maintainer?
> > >>
> > >> Absolutely.  Initial assignment does not equal the actual assignee.
> > >> Component-based assignment is just a way to skip the unassigned
> > >> phase, but people can reassign to themselves or others.
> > >>
> > >> -chip
> > >
> > >Chip, thanks for the answer.
> > >
> > >So far, I've yet to see someone speaking negatively on this proposal.
> > >We do need  better structure - that will also help us being
> productive.
> > >
> > >Please kindly respond with +1, 0 or -1
> > >
> > >If -1, please explain why.
> > >
> > >Thanks
> > >ilya
> > >
> > >
> >
> >
> > +1
> >
> > -Alena.
> >
> >

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, October 07, 2013 8:22 AM
> To: 
> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> 
> I think you might be able to help though!
> 
> We basically need to structure the work around various "cat herding" [1]
> activities (forgive the metaphore, but it's appropriate... ;-) ).  I'm
> sure that there is something...  perhaps helping keep on top of
> reviewboard submissions, to politely nudge relevant committers to review
> specific submissions.
> 
> Whomever wants to take the lead for 4.3 should probably (IMO), start a
> discussion on (1) coordination of work and 
[Animesh>] Since we are getting closer to code freeze date and we cannot find 
overall release management I can pick up 4.3 and call out the roles and ask for 
volunteers for them. 

(2) re-thinking the schedule
> to reset based on both historic performance and reality of the calendar
> (we've really been working on 4.2 when we should have moved on to 4.3).
[Animesh>] Chip my preference would be to stick to the timeline of 4.3 which 
will make it a smaller release but will give us the opportunity to clear up our 
technical debt.
> 
> That should give us a view into where help is needed!
> 
> -chip
> 
> [1] http://www.urbandictionary.com/define.php?term=herding%20cats
> 
> 
> On Mon, Oct 7, 2013 at 11:17 AM, Frankie Onuonga 
> wrote:
> 
> >
> > I would volunteer with but I think I am still to junior to .
> >
> > Kind regards
> > Frankie Onuonga
> > Sent from my Windows Phone
> > 
> > From: Chip Childers<mailto:chip.child...@sungard.com>
> > Sent: 10/7/2013 5:34 PM
> > To: <mailto:dev@cloudstack.apache.org>
> > Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> >
> > On Sat, Sep 21, 2013 at 03:55:27PM -0400, Chip Childers wrote:
> > > > On Sep 20, 2013, at 1:27 PM, Animesh Chaturvedi <
> > animesh.chaturv...@citrix.com> wrote:
> > > >
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > > >> Sent: Friday, September 20, 2013 12:51 AM
> > > >> To: dev
> > > >> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> > > >>
> > > >> H Animesh and the rest,
> > > >>
> > > >> I had some consults at home and at Schuberg Philis. The
> > > >> conclusion is that it is not wise to take up the task as release
> manager right now.
> > > >> I will be glad to take it up some future iteration.
> > > >>
> > > >> sorry to lay this burden back,
> > > >> Daan
> > > > [Animesh>]  Ok anyone else wants to step up to the plate.
> > >
> > > I'm willing to do 4.3 if nobody else can / wants too.
> >
> > I'm actually going to have to pass on this. Also, given the idea of
> > breaking up the work, perhaps someone can volunteer the list of
> "rolls"
> > and others can step up to take each of the partial RM rolls for 4.3?
> >
> > -chip
> >

RE: Call for 4.3 and 4.2.1 Release Managers!

[Animesh Chaturvedi]

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Tuesday, October 08, 2013 11:21 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Call for 4.3 and 4.2.1 Release Managers!
> 
> +1.
> We should get a call out to the community to see who is expecting to
> merge for 4.3.
> Although  10/31 is the feature freeze date, proposals and branches
> should be in already IMHO.
[Animesh>] While I had created and updated the 4.3 page with dates it was not 
explicitly called out since I was expecting the to-be release manager to state 
that. We are already passed the feature proposal date of 9/30, does anyone 
think that the feature proposal last day should be extended to Friday 10/11 
giving 72 hour notice. I prefer not to change and stick to the original dates 
as below.

Feature freeze : 10/31
Code Freeze : 11/29
RC : 12/23 (This is close to Christmas, so either we pull in by couple of days, 
or make it first week of Jan)

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.3+Release



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

[ACS43] [DISCUSS] Release management tasks up for grabs

[Animesh Chaturvedi]

Folks 

As per the thread [1] release management for CloudStack is complex and runs 
into many tasks and it is hard for one person to do it all.

While I am taking the overall release management for 4.3 release there are 
several areas where we need volunteers:


I have put down my thoughts please review and refine as appropriate. 

# Review board management#

- Context: We are lagging severely behind on the reviews of the patches 
submitted and have around 100 pending reviews
- Task Duties:
   * Periodically check on review board [2] for pending reviews
   * If reviewers are not called out for the patch direct the submitter to our 
component maintainers page [3] and help identify the appropriate reviewer
   * Follow up with submitter if they have not responded to review comments in 
5 days
   * Follow up with reviewers if they have not attended to reviews where they 
are called out
   * Reminders can be sent out by either replying to review emails or adding 
comments in review board for the patches
   * Check if a reviewer is overloaded with many pending reviews and call out 
in mailing list that another reviewer to help out is needed
   * Remind the submitter if the BugId, targeted branch is missing
   * Remind the submitter to close out the review when the patch has been 
accepted and submitted in the appropriate branch
   * Close out the review if it submitter for some reason is not able to close 
it out (Administrator privilege is needed) 
   * More details are mentioned in Review board guidelines [4]
- We probably need two volunteers one for code contribution and one for test 
patches contribution 


# Documentation management#

During ACS 4.2 several folks raised questions on insufficient or incorrect 
documentation, this is an area where we need multiple volunteers to come 
forward and help fix documentation


# Jira issues management #

As per thread [5] as community now we have agreed to assign issues. There are 
few things that need to be done to keep the number of unassigned issues  to a 
manageable number:

1. Refine our component list
2. Make the primary maintainers the owners of the components in JIRA, so that 
new issues for the components go to the primary maintainers first instead of 
being unassigned. 
3. Check with INFRA if a workflow can be setup where if an assigned issue is 
not change to InProgres in a week it goes back to un-assigned or to primary 
maintainer of the component (whichever the community prefers)

Workflow:
1. The primary maintainers can redistribute the issues to other community 
members
2. If the assignee can fix the issue promptly they should change the status to 
"In Progress" indicating that issue is being worked on
3. If for whatever reason the assignee is not able to fix the issue they should 
either un-assign or ask someone else to pick up the issue.

Bug triage:
The more hands we can get for bug triage the better it would be so if you want 
to help out please step up.



# Release announcement preparation #

When we are ready to release there are several activities that need to be done 
and we need help.
* Preparing release statement
* Preparing press plan
* Building docs
* Publishing docs to the site



I am sure I may have omitted few important activities feel free to add them to 
the list


[1] http://markmail.org/thread/gkrq2inc2bkupner
[2] https://reviews.apache.org/dashboard/
[3] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainers+Per+Component
[4] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines  

[5] http://markmail.org/thread/vtwod332xqwdmll7


Thanks
Animesh
Committer Apache CloudStack
anim...@apache.org  

RE: [DISCUSS] Add upgrade path from 4.2.1 to 4.3.0 in Master branch

[Animesh Chaturvedi]

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Friday, October 11, 2013 4:51 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Add upgrade path from 4.2.1 to 4.3.0 in Master branch
> 
> Hi there,
> 
> Based on my understanding, 4.2.1 is scheduled to come before 4.3.0
> release. 
[Animesh>] Yes based on Abhi's proposal
If this is true, should we add an upgrade path from 4.2.1 to
> 4.3.0 in Master? 
[Animesh>] Should we wait until we cut 4.3 from master. I will publish the 
schedule for 4.3 soon

This will help us to cherry-pick some commits done in
> 4.2.1 branch that involves schema changes to master. Any objections on
> this? If not, what will be the recommended way to cherry-pick those
> commits to Master? Merging schema change into schema-420to430.sql?
> 
> Thanks
> -min

Patches in reviewboard that were updated over two months ago

[Animesh Chaturvedi]

| rb-jenkins-integration test patch 
 |   1 | tsp  | 
Spark404 tsp  |



Please help in bringing these issues to closure.

Thanks
Animesh
Committer Apache CloudStack
anim...@apache.org  

RE: [ACS43] [DISCUSS] Release management tasks up for grabs

[Animesh Chaturvedi]

Travis thanks for your help, really appreciate the offer. Looking forward to 
working closely with you.



> -Original Message-
> From: Travis Graham [mailto:tgra...@tgraham.us]
> Sent: Friday, October 11, 2013 5:34 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS43] [DISCUSS] Release management tasks up for grabs
> 
> Animesh,
> 
> I'm volunteering to help out with the docs. I've put a hold on fixing
> things until there's a Review Board in place for cloudstack-docs to make
> it easier to submit patches.
> 
> Travis
> 
> On Oct 11, 2013, at 7:01 PM, Animesh Chaturvedi
>  wrote:
> 
> > Folks
> >
> > As per the thread [1] release management for CloudStack is complex and
> runs into many tasks and it is hard for one person to do it all.
> >
> > While I am taking the overall release management for 4.3 release there
> are several areas where we need volunteers:
> >
> >
> > I have put down my thoughts please review and refine as appropriate.
> >
> > # Review board management#
> >
> > - Context: We are lagging severely behind on the reviews of the
> > patches submitted and have around 100 pending reviews
> > - Task Duties:
> >   * Periodically check on review board [2] for pending reviews
> >   * If reviewers are not called out for the patch direct the submitter
> to our component maintainers page [3] and help identify the appropriate
> reviewer
> >   * Follow up with submitter if they have not responded to review
> comments in 5 days
> >   * Follow up with reviewers if they have not attended to reviews
> where they are called out
> >   * Reminders can be sent out by either replying to review emails or
> adding comments in review board for the patches
> >   * Check if a reviewer is overloaded with many pending reviews and
> call out in mailing list that another reviewer to help out is needed
> >   * Remind the submitter if the BugId, targeted branch is missing
> >   * Remind the submitter to close out the review when the patch has
> been accepted and submitted in the appropriate branch
> >   * Close out the review if it submitter for some reason is not able
> to close it out (Administrator privilege is needed)
> >   * More details are mentioned in Review board guidelines [4]
> > - We probably need two volunteers one for code contribution and one
> > for test patches contribution
> >
> >
> > # Documentation management#
> >
> > During ACS 4.2 several folks raised questions on insufficient or
> > incorrect documentation, this is an area where we need multiple
> > volunteers to come forward and help fix documentation
> >
> >
> > # Jira issues management #
> >
> > As per thread [5] as community now we have agreed to assign issues.
> There are few things that need to be done to keep the number of
> unassigned issues  to a manageable number:
> >
> > 1. Refine our component list
> > 2. Make the primary maintainers the owners of the components in JIRA,
> so that new issues for the components go to the primary maintainers
> first instead of being unassigned.
> > 3. Check with INFRA if a workflow can be setup where if an assigned
> > issue is not change to InProgres in a week it goes back to un-assigned
> > or to primary maintainer of the component (whichever the community
> > prefers)
> >
> > Workflow:
> > 1. The primary maintainers can redistribute the issues to other
> > community members 2. If the assignee can fix the issue promptly they
> > should change the status to "In Progress" indicating that issue is
> being worked on 3. If for whatever reason the assignee is not able to
> fix the issue they should either un-assign or ask someone else to pick
> up the issue.
> >
> > Bug triage:
> > The more hands we can get for bug triage the better it would be so if
> you want to help out please step up.
> >
> >
> >
> > # Release announcement preparation #
> >
> > When we are ready to release there are several activities that need to
> be done and we need help.
> > * Preparing release statement
> > * Preparing press plan
> > * Building docs
> > * Publishing docs to the site
> >
> >
> >
> > I am sure I may have omitted few important activities feel free to add
> > them to the list
> >
> >
> > [1] http://markmail.org/thread/gkrq2inc2bkupner
> > [2] https://reviews.apache.org/dashboard/
> > [3]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintaine
> rs+Per+Component
> > [4]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guid
> elines
> > [5] http://markmail.org/thread/vtwod332xqwdmll7
> >
> >
> > Thanks
> > Animesh
> > Committer Apache CloudStack
> > anim...@apache.org
> >

[ACS43] Proposed schedule

[Animesh Chaturvedi]

Folks

I would like to propose the following schedule for 4.3. Please note that I have 
pushed it out by 1 week for multiple reasons 
1) Until end of September our focus was on 4.2 and master needs to be 
stabilized before feature freeze
2) The original RC was scheduled closer to Christmas and it seemed impractical 
because of holidays  so I moved it out to January 10th giving us some extra 
time for RC preparation

I would like to also propose that we target 1/31 as our GA date. 

4.3 is expected to be a much smaller release compared to 4.2 and the focus is 
to reduce our technical debt. We have  600+ unresolved issues out of which 400 
are unassigned


=
 4.3 detailed schedule proposal:
 


 2013-11-08
   Feature Freeze
   All new feature need to have been merged into master by this date.
   Release branch will be cut on this date.
   Jenkins updated to include new release branch builds.
 
 2013-11-09 through 2013-12-06
   Testing/Bug Fixes (testing against jenkins artifacts)
   Documentation Finalization
 
 2013-12-06
   Docs Freeze (except release notes and translations)
   Release Branch moves to limited updates only (only commits allowed  in would 
be release blockers fixes, translation updates, etc...)
 
 2013-12-07 through 2014-01-10
   Translation Development and Integration (should be ongoing, but  focused 
effort)
   Final regression testing / bug fixes / doc fixes
 
 2013-01-10
   4.3.0-RC1 is created, and project level VOTE is called

 2013-01-31
   4.3.0 is released

RE: [DISCUSS] Add upgrade path from 4.2.1 to 4.3.0 in Master branch

[Animesh Chaturvedi]

Well I take it back, I think it is easier to add the path now in master

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Friday, October 11, 2013 6:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Add upgrade path from 4.2.1 to 4.3.0 in Master
> branch
> 
> Then what should we do to cherry-pick some commits from 4.2.1 to master?
> No cherry-pick until 4.3 is cut?
> 
> Thanks
> -min
> 
> On 10/11/13 5:25 PM, "Animesh Chaturvedi"
> 
> wrote:
> 
> >> -Original Message-
> >> From: Min Chen [mailto:min.c...@citrix.com]
> >> Sent: Friday, October 11, 2013 4:51 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: [DISCUSS] Add upgrade path from 4.2.1 to 4.3.0 in Master
> >> branch
> >>
> >> Hi there,
> >>
> >> Based on my understanding, 4.2.1 is scheduled to come before 4.3.0
> >> release.
> >[Animesh>] Yes based on Abhi's proposal If this is true, should we add
> >an upgrade path from 4.2.1 to
> >> 4.3.0 in Master?
> >[Animesh>] Should we wait until we cut 4.3 from master. I will publish
> >the schedule for 4.3 soon
> >
> >This will help us to cherry-pick some commits done in
> >> 4.2.1 branch that involves schema changes to master. Any objections
> >> on this? If not, what will be the recommended way to cherry-pick
> >> those commits to Master? Merging schema change into schema-
> 420to430.sql?
> >>
> >> Thanks
> >> -min
> >

RE: [ACS43] Proposed schedule

[Animesh Chaturvedi]

That would be preferred but may be impractical. For 4.1 also until we hit the 
RC Chip had allowed folks to checkin critical fixes check the thread below 

http://markmail.org/thread/qkkxycablpsmogsx

Animesh

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Monday, October 14, 2013 6:44 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS43] Proposed schedule
> 
> just a little feedback
> 
> After 12/06 can we limit commits to the RM. It worked quite well for
> 4.1.
> 
> -sebastien
> 
> On Oct 14, 2013, at 12:13 AM, Mike Tutkowski
>  wrote:
> 
> > This schedule looks good to me.
> >
> >
> > On Sun, Oct 13, 2013 at 12:57 PM, Daan Hoogland
> wrote:
> >
> >> looks like a plan, Animesh
> >>
> >>
> >> On Sat, Oct 12, 2013 at 3:14 AM, Animesh Chaturvedi
> >>  wrote:
> >>> Folks
> >>>
> >>> I would like to propose the following schedule for 4.3. Please note
> >>> that
> >> I have pushed it out by 1 week for multiple reasons
> >>> 1) Until end of September our focus was on 4.2 and master needs to
> >>> be
> >> stabilized before feature freeze
> >>> 2) The original RC was scheduled closer to Christmas and it seemed
> >> impractical because of holidays  so I moved it out to January 10th
> >> giving us some extra time for RC preparation
> >>>
> >>> I would like to also propose that we target 1/31 as our GA date.
> >>>
> >>> 4.3 is expected to be a much smaller release compared to 4.2 and the
> >> focus is to reduce our technical debt. We have  600+ unresolved
> >> issues out of which 400 are unassigned
> >>>
> >>>
> >>> =
> >>> 4.3 detailed schedule proposal:
> >>> 
> >>>
> >>>
> >>> 2013-11-08
> >>>   Feature Freeze
> >>>   All new feature need to have been merged into master by this date.
> >>>   Release branch will be cut on this date.
> >>>   Jenkins updated to include new release branch builds.
> >>>
> >>> 2013-11-09 through 2013-12-06
> >>>   Testing/Bug Fixes (testing against jenkins artifacts)
> >>>   Documentation Finalization
> >>>
> >>> 2013-12-06
> >>>   Docs Freeze (except release notes and translations)
> >>>   Release Branch moves to limited updates only (only commits allowed
> >> in would be release blockers fixes, translation updates, etc...)
> >>>
> >>> 2013-12-07 through 2014-01-10
> >>>   Translation Development and Integration (should be ongoing, but
> >> focused effort)
> >>>   Final regression testing / bug fixes / doc fixes
> >>>
> >>> 2013-01-10
> >>>   4.3.0-RC1 is created, and project level VOTE is called
> >>>
> >>> 2013-01-31
> >>>   4.3.0 is released
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud<http://solidfire.com/solution/overview/?video=play>
> > *(tm)*

RE: Re-Introduction and Assist

[Animesh Chaturvedi]

Frankie thanks for your note, I have added you for Documentation

From: Frankie Onuonga [mailto:frankie.onuo...@gmail.com]
Sent: Sunday, October 13, 2013 12:40 PM
To: dev@cloudstack.apache.org
Cc: Animesh Chaturvedi
Subject: Re-Introduction and Assist

Hi guys.

Firstly, I would like to introduce myself.
My name is Frankie Onuonga. I work at  Angani Ltd. This is a company in Kenya.
www.angani.co<http://www.angani.co>
Most of you probably know me through my office email 
fran...@angani.co<mailto:fran...@angani.co>

I am writing to kindly inform you I am switching from using my office email to 
using my gmail account.
There are many reasons that i would not like to get into at this time as to why 
it works out better for me.


I also would like to assist in doing some release maintenance in documentation 
and code.

Kindly do let me know how I can be of help.


Kind Regards,

RE: [ACS43] [DISCUSS] Release management tasks up for grabs

[Animesh Chaturvedi]

Folks I have updated the 4.3 release page [1] with a section on Release 
Management that has a table for Role and Volunteers. So far Frankie and Travis 
have stepped up for documentation. If you plan to volunteer for specific roles 
please reply to this thread and put your name and email on the Release wiki page



https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.3+Release


> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, October 11, 2013 5:39 PM
> To: dev@cloudstack.apache.org
> Cc: fran...@angani.co; Jonathan Creasy (jonathan.cre...@contegix.com)
> Subject: RE: [ACS43] [DISCUSS] Release management tasks up for grabs
> 
> Travis thanks for your help, really appreciate the offer. Looking
> forward to working closely with you.
> 
> 
> 
> > -Original Message-
> > From: Travis Graham [mailto:tgra...@tgraham.us]
> > Sent: Friday, October 11, 2013 5:34 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [ACS43] [DISCUSS] Release management tasks up for grabs
> >
> > Animesh,
> >
> > I'm volunteering to help out with the docs. I've put a hold on fixing
> > things until there's a Review Board in place for cloudstack-docs to
> > make it easier to submit patches.
> >
> > Travis
> >
> > On Oct 11, 2013, at 7:01 PM, Animesh Chaturvedi
> >  wrote:
> >
> > > Folks
> > >
> > > As per the thread [1] release management for CloudStack is complex
> > > and
> > runs into many tasks and it is hard for one person to do it all.
> > >
> > > While I am taking the overall release management for 4.3 release
> > > there
> > are several areas where we need volunteers:
> > >
> > >
> > > I have put down my thoughts please review and refine as appropriate.
> > >
> > > # Review board management#
> > >
> > > - Context: We are lagging severely behind on the reviews of the
> > > patches submitted and have around 100 pending reviews
> > > - Task Duties:
> > >   * Periodically check on review board [2] for pending reviews
> > >   * If reviewers are not called out for the patch direct the
> > > submitter
> > to our component maintainers page [3] and help identify the
> > appropriate reviewer
> > >   * Follow up with submitter if they have not responded to review
> > comments in 5 days
> > >   * Follow up with reviewers if they have not attended to reviews
> > where they are called out
> > >   * Reminders can be sent out by either replying to review emails or
> > adding comments in review board for the patches
> > >   * Check if a reviewer is overloaded with many pending reviews and
> > call out in mailing list that another reviewer to help out is needed
> > >   * Remind the submitter if the BugId, targeted branch is missing
> > >   * Remind the submitter to close out the review when the patch has
> > been accepted and submitted in the appropriate branch
> > >   * Close out the review if it submitter for some reason is not able
> > to close it out (Administrator privilege is needed)
> > >   * More details are mentioned in Review board guidelines [4]
> > > - We probably need two volunteers one for code contribution and one
> > > for test patches contribution
> > >
> > >
> > > # Documentation management#
> > >
> > > During ACS 4.2 several folks raised questions on insufficient or
> > > incorrect documentation, this is an area where we need multiple
> > > volunteers to come forward and help fix documentation
> > >
> > >
> > > # Jira issues management #
> > >
> > > As per thread [5] as community now we have agreed to assign issues.
> > There are few things that need to be done to keep the number of
> > unassigned issues  to a manageable number:
> > >
> > > 1. Refine our component list
> > > 2. Make the primary maintainers the owners of the components in
> > > JIRA,
> > so that new issues for the components go to the primary maintainers
> > first instead of being unassigned.
> > > 3. Check with INFRA if a workflow can be setup where if an assigned
> > > issue is not change to InProgres in a week it goes back to
> > > un-assigned or to primary maintainer of the component (whichever the
> > > community
> > > prefers)
> > >
> > > Workflow:
> > > 1. The primary maintainers can redistribute the issues to other
> > > community members 2. If the assigne

[ACS43] Feature tickets

[Animesh Chaturvedi]

Folks

The schedule for ACS43 release is out. If you are planning to deliver a feature 
for 4.3 release please make sure to update  JIRA issues with the fixVersion as 
4.3 and post the design specs at [1]. I want to have the Release Dashboard 
setup by tomorrow.


[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.3+Design+Documents


Thanks
Animesh

RE: Release management tasks up for grabs

[Animesh Chaturvedi]

Certainly all help is appreciated. I am copying the dev mailing list too.

From: Vinod Nair [mailto:vinodn...@juniper.net]
Sent: Monday, October 14, 2013 5:29 PM
To: anim...@apache.org
Subject: Release management tasks up for grabs

Hi Animesh

I can spend an hour  a day or so ,.  If no one signed up, I can help out " 
Review board management"


Thanks
Vinod

RE: CloudStack Bay Area Meetup

[Animesh Chaturvedi]

Adding the users mailing list too

> -Original Message-
> From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
> Sent: Monday, October 14, 2013 11:08 AM
> To: dev@cloudstack.apache.org
> Subject: CloudStack Bay Area Meetup
> 
> Hi All,
> 
> The CloudStack Bay Area meet-up will be held tomm. (10/15) with Juniper
> doing a Contrail integration demo, followed by a DevCloud intro session
> to help new CloudStack developers.
> More details on
> http://www.meetup.com/CloudStack-SF-Bay-Area-Users-
> Group/events/141814852/
> 
> Do join in if around!
> 
> Thanks,
> Amogh

RE: Incomplete API docs?

[Animesh Chaturvedi]

Demetrius do you mind creating an issue in JIRA?

> -Original Message-
> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> Sent: Tuesday, October 15, 2013 5:15 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Incomplete API docs?
> 
> The commands.xml generated as a result of mvn build (mvn clean install -
> P developer,systemvm -DskipTests), doesn't include the commands
> mentioned by Demetrius. Looks like some regression bug in
> ApiXmlDocWriter - it used to include all the commands in 3.0.x version
> of the code.
> 
> -Alena.
> 
> From: Demetrius Tsitrelis
> mailto:dtsitre...@live.com>>
> Reply-To: "dev@cloudstack.apache.org"
> mailto:dev@cloudstack.apache.org>>
> Date: Tuesday, October 15, 2013 4:33 PM
> To: "dev@cloudstack.apache.org"
> mailto:dev@cloudstack.apache.org>>
> Subject: Incomplete API docs?
> 
> 
> 
> I grep'ed the source code and came up with a list of the APIs which the
> UI uses.  That list is at the end of this message.
> You can see that many of them (addNetscalerLoadBalancer, addVmwareDc,
> etc.) are not in the generated API documentation which appears at
> http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html
> 
> 
> Is this something wrong with the input files or is a tool at fault?
> 
> 
> Here's the list of APIs used by the UI:
> 
> activateProject
> 
> addAccountToProject
> 
> addBaremetalDhcp
> 
> addBaremetalPxeKickStartServer
> 
> addCluster
> 
> addHost
> 
> addImageStore
> 
> addIpToNic
> 
> addLdapConfiguration
> 
> addNetscalerLoadBalancer
> 
> addNetworkServiceProvider
> 
> addNicToVirtualMachine
> 
> addRegion
> 
> addTrafficType
> 
> addUcsManager
> 
> addVmwareDc
> 
> addVpnUser
> 
> archiveAlerts
> 
> archiveEvents
> 
> assignToGlobalLoadBalancerRule
> 
> assignToLoadBalancerRule
> 
> assignVirtualMachine
> 
> associateIpAddress
> 
> associateUcsProfileToBlade
> 
> attachIso
> 
> attachVolume
> 
> authorizeSecurityGroupEgress
> 
> authorizeSecurityGroupIngress
> 
> cancelHostMaintenance
> 
> cancelStorageMaintenance
> 
> configureInternalLoadBalancerElement
> 
> configureVirtualRouterElement
> 
> copyIso
> 
> copyTemplate
> 
> createAccount
> 
> createAffinityGroup
> 
> createAutoScalePolicy
> 
> createAutoScaleVmGroup
> 
> createAutoScaleVmProfile
> 
> createCondition
> 
> createDiskOffering
> 
> createDomain
> 
> createEgressFirewallRule
> 
> createFirewallRule
> 
> createGlobalLoadBalancerRule
> 
> createIpForwardingRule
> 
> createLBHealthCheckPolicy
> 
> createLBStickinessPolicy
> 
> createLoadBalancer
> 
> createLoadBalancerRule
> 
> createNetwork
> 
> createNetworkACL
> 
> createNetworkACLList
> 
> createNetworkOffering
> 
> createPhysicalNetwork
> 
> createPod
> 
> createPortableIpRange
> 
> createPortForwardingRule
> 
> createPrivateGateway
> 
> createProject
> 
> createRemoteAccessVpn
> 
> createSecondaryStagingStore
> 
> createSecurityGroup
> 
> createServiceOffering
> 
> createSnapshot
> 
> createSnapshotPolicy
> 
> createStaticRoute
> 
> createStorageNetworkIpRange
> 
> createStoragePool
> 
> createTags
> 
> createTemplate
> 
> createUser
> 
> createVlanIpRange
> 
> createVMSnapshot
> 
> createVolume
> 
> createVPC
> 
> createVpnConnection
> 
> createVpnCustomerGateway
> 
> createVpnGateway
> 
> createZone
> 
> dedicateCluster
> 
> dedicateGuestVlanRange
> 
> dedicateHost
> 
> dedicatePod
> 
> dedicatePublicIpRange
> 
> dedicateZone
> 
> deleteAccount
> 
> deleteAccountFromProject
> 
> deleteAffinityGroup
> 
> deleteAlerts
> 
> deleteBigSwitchVnsDevice
> 
> deleteCiscoNexusVSM
> 
> deleteCluster
> 
> deleteCondition
> 
> deleteDiskOffering
> 
> deleteDomain
> 
> deleteEgressFirewallRule
> 
> deleteEvents
> 
> deleteF5LoadBalancer
> 
> deleteFirewallRule
> 
> deleteGlobalLoadBalancerRule
> 
> deleteHost
> 
> deleteImageStore
> 
> deleteIpForwardingRule
> 
> deleteIso
> 
> deleteLBHealthCheckPolicy
> 
> deleteLBStickinessPolicy
> 
> deleteLdapConfiguration
> 
> deleteLoadBalancer
> 
> deleteLoadBalancerRule
> 
> deleteNetscalerLoadBalancer
> 
> deleteNetwork
> 
> deleteNetworkACL
> 
> deleteNetworkACLList
> 
> deleteNetworkOffering
> 
> deleteNetworkServiceProvider
> 
> deleteNiciraNvpDevice
> 
> deletePhysicalNetwork
> 
> deletePod
> 
> deletePortableIpRange
> 
> deletePortForwardingRule
> 
> deletePrivateGateway
> 
> deleteProject
> 
> deleteProjectInvitation
> 
> deleteRemoteAccessVpn
> 
> deleteSecondaryStagingStore
> 
> deleteSecurityGroup
> 
> deleteServiceOffering
> 
> deleteSnapshot
> 
> deleteSnapshotPolicies
> 
> deleteSrxFirewall
> 
> deleteStaticRoute
> 
> deleteStorageNetworkIpRange
> 
> deleteStoragePool
> 
> deleteTags
> 
> deleteTemplate
> 
> deleteUcsManager
> 
> deleteUser
> 
> deleteVlanIpRange
> 
> deleteVMSnapshot
> 
> deleteVolume
> 
> deleteVPC
> 
> deleteVpnConnection
> 
> deleteVpnCustomerGateway
> 
> deleteVpnGateway
> 
> deleteZone
> 
> deployVirtualMachine
> 
> destroyRouter
> 
> destroySystemVm
> 
> destroyVirtualMachine
>

RE: Incomplete API docs?

[Animesh Chaturvedi]

+1

Radhika on the 4.3 release page I have solicited volunteers for different 
release activities. Looks like the high level tasks could use a better 
breakdown, do you want to take a stab at breaking doc into sub tasks and folks 
interested can fill in their name.

Animesh

> -Original Message-
> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com]
> Sent: Wednesday, October 16, 2013 3:24 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Incomplete API docs?
> 
> Hi All,
> 
> Our API documentation requires a serious refurbishment.
> 
> How about creating a doc sprint for enhancing API documentation ?
> 
> I am in the process of setting up a Wiki page at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Documentation+Spr
> int+for+Enhancing+API+Documentation to track this activity. Feel free to
> add/ edit/ remove the page content.
> 
> I request all of you to volunteer so that we will have a comprehensive
> API doc set by next release.
> 
> Appreciate your feedback.
> 
> Regards
> -Radhika
> 
> 
> 
> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, October 16, 2013 7:36 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Incomplete API docs?
> 
> Demetrius do you mind creating an issue in JIRA?
> 
> > -Original Message-
> > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> > Sent: Tuesday, October 15, 2013 5:15 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Incomplete API docs?
> >
> > The commands.xml generated as a result of mvn build (mvn clean install
> > - P developer,systemvm -DskipTests), doesn't include the commands
> > mentioned by Demetrius. Looks like some regression bug in
> > ApiXmlDocWriter - it used to include all the commands in 3.0.x version
> > of the code.
> >
> > -Alena.
> >
> > From: Demetrius Tsitrelis
> > mailto:dtsitre...@live.com>>
> > Reply-To:
> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
> > mailto:dev@cloudstack.apache.org>>
> > Date: Tuesday, October 15, 2013 4:33 PM
> > To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
> > mailto:dev@cloudstack.apache.org>>
> > Subject: Incomplete API docs?
> >
> >
> >
> > I grep'ed the source code and came up with a list of the APIs which
> > the UI uses.  That list is at the end of this message.
> > You can see that many of them (addNetscalerLoadBalancer, addVmwareDc,
> > etc.) are not in the generated API documentation which appears at
> > http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html
> >
> >
> > Is this something wrong with the input files or is a tool at fault?
> >
> >
> > Here's the list of APIs used by the UI:
> >
> > activateProject
> >
> > addAccountToProject
> >
> > addBaremetalDhcp
> >
> > addBaremetalPxeKickStartServer
> >
> > addCluster
> >
> > addHost
> >
> > addImageStore
> >
> > addIpToNic
> >
> > addLdapConfiguration
> >
> > addNetscalerLoadBalancer
> >
> > addNetworkServiceProvider
> >
> > addNicToVirtualMachine
> >
> > addRegion
> >
> > addTrafficType
> >
> > addUcsManager
> >
> > addVmwareDc
> >
> > addVpnUser
> >
> > archiveAlerts
> >
> > archiveEvents
> >
> > assignToGlobalLoadBalancerRule
> >
> > assignToLoadBalancerRule
> >
> > assignVirtualMachine
> >
> > associateIpAddress
> >
> > associateUcsProfileToBlade
> >
> > attachIso
> >
> > attachVolume
> >
> > authorizeSecurityGroupEgress
> >
> > authorizeSecurityGroupIngress
> >
> > cancelHostMaintenance
> >
> > cancelStorageMaintenance
> >
> > configureInternalLoadBalancerElement
> >
> > configureVirtualRouterElement
> >
> > copyIso
> >
> > copyTemplate
> >
> > createAccount
> >
> > createAffinityGroup
> >
> > createAutoScalePolicy
> >
> > createAutoScaleVmGroup
> >
> > createAutoScaleVmProfile
> >
> > createCondition
> >
> > createDiskOffering
> >
> > createDomain
> >
> > createEgressFirewallRule
> >
> > createFirewallRule
> >
> > createGlobalLoadBalancerRule
> >
> > createIpForwardingRule
> >
> > createLBHealthCheckPolicy
> >
> > c

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

[Animesh Chaturvedi]

+1

> -Original Message-
> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> Sent: Monday, October 21, 2013 11:12 AM
> To: dev@cloudstack.apache.org
> Subject: [VOTE] Accept the donation of RDP client code into Apache
> CloudStack
> 
> As stated in a previous thread [1], Citrix is proposing the donation of
> source for an RDP client.  After donation, the client would be
> integrated with the console system VM in order to provide access to
> Hyper-V based VMs.
> 
> The client's source is in the diff attached to the Review Board
> submission https://reviews.apache.org/r/14701/
> 
> [1] http://markmail.org/thread/q6sfqrhosmirm3bg
> 
> I would like to call a vote here, so that we have a formal consensus on
> accepting the code into the project.  I suggest that it be accepted into
> a branch, and then we work through any technical concerns / reviews /
> changes prior to a master branch merge.
> 
> VOTING will be left open for 72 hours.
> 
> This is a technical decision, which means committer and PMC votes are
> binding.
> 
> 
> DL

[ACS43] Three weeks to feature freeze on 11/08

[Animesh Chaturvedi]

Folks

We are now just 3 weeks from ACS 4.3 feature freeze on 11/08.  I have setup the 
Release Dashboard for 4.3 at [1]. If you are experiencing issues with master 
please create issues and target them for 4.3.0 release so that they can be 
tracked and addressed quickly. 

If you are working on a contribution for 4.3 make sure that you have set the 
fixVersion to 4.3. Do plan on providing weekly update in your tracking ticket 
as comments by Wednesday. If your contribution is unlikely to make it to 4.3 
feature freeze on 11/8 please move them out of 4.3 release to 'Future'.


Thanks 
Animesh

[1] http://s.apache.org/dFk

RE: [ANNOUNCE] New PMC member: Animesh Chaturvedi

[Animesh Chaturvedi]

Thank you all. I am truly honoured

Animesh 

From: chip.child...@sungard.com [chip.child...@sungard.com] on behalf of Chip 
Childers [chipchild...@apache.org]
Sent: Monday, October 21, 2013 12:01 PM
To: 
Subject: [ANNOUNCE] New PMC member: Animesh Chaturvedi

The Project Management Committee (PMC) for Apache CloudStack has asked
Animesh Chaturvedi to join the PMC and we are pleased to announce that they
have accepted.

Join me in congratulating Animesh!

-The CloudStack PMC

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

[Animesh Chaturvedi]

> -Original Message-
> From: Wido den Hollander [mailto:w...@widodh.nl]
> Sent: Tuesday, October 22, 2013 11:24 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [ASF4.2.1] default to 64-bit system VM template
> 
> On 10/23/2013 07:32 AM, Abhinandan Prateek wrote:
> >
> >We are planning to  make 64-bit system vm templates as default
> offering in 4.2.1.
> > This is an initial email to have thoughts from the community on this.
> >
> 
> I'd say -1.
> 
> Since it is going to be a minor upgrade and although this seems like a
> harmless thing, it would postpone it to 4.3


[Animesh>] Given that we are now 2 weeks from feature freeze we should lock 
down on system templates for 4.3 soon, I will track the 64bit template for 4.3


> 
> A minor release should be bugfixes only imho and changing the
> architecture of a System VM isn't a bugfix.
> 
> Wido
> 
> > -abhi
> >

RE: RN-KnownIssuesIn4.2

[Animesh Chaturvedi]

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Monday, October 28, 2013 1:31 AM
> To: dev@cloudstack.apache.org; Animesh Chaturvedi
> Subject: Re: RN-KnownIssuesIn4.2
> 
> Animesh owns that filter,
> 
> On Oct 27, 2013, at 6:39 AM, Marty Sweet  wrote:
> 
> > Hi Guys,
> >
> > Following the issues I have had upgrading to 4.2.0, I have noticed
> > that the known issues filter in Jira is set to used fixedVersion as
> > opposed to affectedVersion. This changes the results dramatically, if
> > I was able to see any of the issues I was having using this filter I
> > believe the upgrade would of gone a lot smoother. This is linked from
> > the Known Issues part of
> > 4.2.0 documentation.
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4902?filter=12324873
> >
> > It's currently:
> > project = CLOUDSTACK AND type = Bug AND fixVersion = "4.2.0" AND
> > resolution is EMPTY AND level = "Public" ORDER BY priority DESC, key
> > ASC
> >
> > I think it should be:
> > project = CLOUDSTACK AND type = Bug AND affectedVersion = "4.2.0" AND
> > resolution is EMPTY AND level = "Public" ORDER BY priority DESC, key
> > ASC
> >
> > Thanks,
> > Marty
[Animesh>] Thanks for the note I changed the query to include both 
affectedVersion and fixVersion)

 project = CLOUDSTACK AND type = Bug AND (affectedVersion = "4.2.0" or 
fixVersion = "4.2.0") AND resolution is EMPTY AND level = "Public" ORDER BY 
priority DESC, key ASC

I also updated the Release management wiki  page [1] with this filter


[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Management

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

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@gmail.com]
> Sent: Thursday, October 24, 2013 6:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Accept the donation of RDP client code into Apache
> CloudStack
> 
> 
> 
> > On Oct 24, 2013, at 3:20 PM, Donal Lafferty
>  wrote:
> >
> > It's been a bit over 72 hours, and I would like to now close voting on
> the RDP client code donation.
> >
> > We have an acceptance with the following results:
> >
> > +1
> > Animesh Chaturvedi
> > Devdeep Singh
> > Chiradeep Vittal
> > Ahmad Emneina
> > Rajesh Battala
> > Kelven Yang
> > Chip Childers
> > Clayton Weise
> > John Kinsella
> > Sateesh Chodapuneedi
> > Ryan Shafer
> >
> > +0
> > Wido den Hollander
> > Daan hoogland
> >
> > The next stage is to put in place IP clearance paper work in advance
> before the code can go into a branch of master.  I will contact a PMC
> member to arrange for this paperwork.
> 
> No need to contact any PMC members off list (unless there are legal
> concerns, in which case email to private@cs.a.o, not individuals). I
> just need an ack from secretary@ saying that a properly signed Software
> Grant Agreement has been received by the ASF to move through the
> procedural steps. Citrix has done these before, so they should be known
> to your legal dept.
> 
> Thanks!

[Animesh>] I just emailed the signed SGA to secretary@ and private@

> 
> 
> >
> > Thanks for participating everyone!
> >
> >
> >> -Original Message-
> >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> >> Sent: 21 October 2013 19:12
> >> To: dev@cloudstack.apache.org
> >> Subject: [VOTE] Accept the donation of RDP client code into Apache
> >> CloudStack
> >>
> >> As stated in a previous thread [1], Citrix is proposing the donation
> >> of source for an RDP client.  After donation, the client would be
> >> integrated with the console system VM in order to provide access to
> Hyper-V based VMs.
> >>
> >> The client's source is in the diff attached to the Review Board
> >> submission https://reviews.apache.org/r/14701/
> >>
> >> [1] http://markmail.org/thread/q6sfqrhosmirm3bg
> >>
> >> I would like to call a vote here, so that we have a formal consensus
> >> on accepting the code into the project.  I suggest that it be
> >> accepted into a branch, and then we work through any technical
> >> concerns / reviews / changes prior to a master branch merge.
> >>
> >> VOTING will be left open for 72 hours.
> >>
> >> This is a technical decision, which means committer and PMC votes are
> >> binding.
> >>
> >>
> >> DL
> >

[ACS43] Schedule reminder feature freeze on 11/08

[Animesh Chaturvedi]

Folks

We are now just 9 days from feature freeze on 11/08. There are still many open 
feature and improvement tickets. If your contribution is unlikely to make it to 
4.3 feature freeze on 11/8 please move them out of 4.3 release to 'Future'.

Do remember that we have a 72 hour notice period to solicit feedback for MERGE 
requests. So the absolute last day for merge requests for 4.3 features/ 
improvements will be 11/05. The contribution has to be in master after 
satisfying any merge concerns by 11/08 to be included  in 4.3.0 release.

For detailed branch merge requirement check [1]

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations


Thanks
Animesh

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Monday, October 21, 2013 5:32 PM
> To: dev@cloudstack.apache.org
> Subject: [ACS43] Three weeks to feature freeze on 11/08
> 
> Folks
> 
> We are now just 3 weeks from ACS 4.3 feature freeze on 11/08.  I have
> setup the Release Dashboard for 4.3 at [1]. If you are experiencing
> issues with master please create issues and target them for 4.3.0
> release so that they can be tracked and addressed quickly.
> 
> If you are working on a contribution for 4.3 make sure that you have set
> the fixVersion to 4.3. Do plan on providing weekly update in your
> tracking ticket as comments by Wednesday. If your contribution is
> unlikely to make it to 4.3 feature freeze on 11/8 please move them out
> of 4.3 release to 'Future'.
> 
> 
> Thanks
> Animesh
> 
> [1] http://s.apache.org/dFk
> 

[ACS43] Schedule reminder : feature freeze this Friday 11/08

[Animesh Chaturvedi]

Folks

Friday 11/8 is the feature freeze date for ACS 4.3. If your contribution is 
unlikely to make it to 4.3 feature freeze on 11/8 please move them out of 4.3 
release to 'Future'.

Do remember that we have a 72 hour notice period to solicit feedback for MERGE 
requests. So the absolute last day for merge requests for 4.3 features/ 
improvements is tomorrow 11/05. Contributors if you have patches in reviewboard 
that you had planned for 4.3 make sure to follow up with reviewers. The 
contribution has to be in master after satisfying any merge concerns / review 
comments  by 11/08 to be included  in 4.3.0 release.


For detailed branch merge requirement check [1]

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations


Thanks
Animesh

RE: [ACS43] Schedule reminder : feature freeze this Friday 11/08

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Tuesday, November 05, 2013 9:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS43] Schedule reminder : feature freeze this Friday
> 11/08
> 
> One thing to note, and perhaps this becomes a minor exception to the
> merge timing.  IP Clearance for the RDP client won't be done until the
> morning of the 7th.
> 
> I'd propose that it is brought in to master at that time.  I won't have
> time to do the actual commit myself, but perhaps someone can own
> handling this on the morning of the 7th (ET).  Any takers?
> 
> -chip
[Animesh>] Devdeep or I can take care of committing it into master


> 
> On Mon, Nov 4, 2013 at 9:58 PM, Animesh Chaturvedi
>  wrote:
> > Folks
> >
> > Friday 11/8 is the feature freeze date for ACS 4.3. If your
> contribution is unlikely to make it to 4.3 feature freeze on 11/8 please
> move them out of 4.3 release to 'Future'.
> >
> > Do remember that we have a 72 hour notice period to solicit feedback
> for MERGE requests. So the absolute last day for merge requests for 4.3
> features/ improvements is tomorrow 11/05. Contributors if you have
> patches in reviewboard that you had planned for 4.3 make sure to follow
> up with reviewers. The contribution has to be in master after satisfying
> any merge concerns / review comments  by 11/08 to be included  in 4.3.0
> release.
> >
> >
> > For detailed branch merge requirement check [1]
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Ex
> > pectations
> >
> >
> > Thanks
> > Animesh
> >
> >

RE: [JENKINS] Preparing for the 4.3 branch

[Animesh Chaturvedi]

Thanks Hugo for taking care of these. Do you mind taking a moment to update 
Release Management wiki page [1] on what it takes to set up Jenkins build jobs  
for a new release.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Management


> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Wednesday, November 06, 2013 2:16 AM
> To: dev@cloudstack.apache.org
> Subject: [JENKINS] Preparing for the 4.3 branch
> 
> I've setup all the jenkins jobs for the release branch and a pipeline
> view.
> 
> When the branch is cut we only need to enable the jobs.
> 
> http://jenkins.buildacloud.org/view/4.3/
> http://jenkins.buildacloud.org/view/cloudstack-4.3-pipeline/
> 
> 
> Cheers,
> 
> Hugo

RE: [JENKINS] Preparing for the 4.3 branch

[Animesh Chaturvedi]

Prasanna I have added a link to your newly added wiki page, but need more 
information for a beginner to clone the build jobs for a new release

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, November 06, 2013 11:41 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [JENKINS] Preparing for the 4.3 branch
> 
> Thanks Hugo for taking care of these. Do you mind taking a moment to
> update Release Management wiki page [1] on what it takes to set up
> Jenkins build jobs  for a new release.
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Managemen
> t
> 
> 
> > -Original Message-
> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > Sent: Wednesday, November 06, 2013 2:16 AM
> > To: dev@cloudstack.apache.org
> > Subject: [JENKINS] Preparing for the 4.3 branch
> >
> > I've setup all the jenkins jobs for the release branch and a pipeline
> > view.
> >
> > When the branch is cut we only need to enable the jobs.
> >
> > http://jenkins.buildacloud.org/view/4.3/
> > http://jenkins.buildacloud.org/view/cloudstack-4.3-pipeline/
> >
> >
> > Cheers,
> >
> > Hugo

RE: [New Feature FS] SSL Offload Support for Cloudstack

[Animesh Chaturvedi]

Darren, Murali

Can you review the final patch and if acceptable merge into master. Syed the 
deadline is hard. I will cut the branch on 11/08 late night or early morning 
next day

Animesh

> -Original Message-
> From: Syed Ahmed [mailto:sah...@cloudops.com]
> Sent: Wednesday, November 06, 2013 8:26 AM
> To: dev@cloudstack.apache.org
> Cc: Murali Reddy; Darren Shepherd
> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
> 
> Hi All,
> 
> Many thanks to Darren and Murali for reviewing my code. I feel that the
> code is in a good condition to be merged into the master. I see that the
> code freeze is at the end of this week. Is it possible for my patch to
> be merged by then? Is it a hard deadline?
> 
> Thanks,
> -Syed
> 
> On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote:
> > Hi All,
> >
> > I would like to get this code into 4.3. Is it possible for this to be
> > reviewed? Is there anything needed from my side? I would be glad to
> > provide more information.
> >
> > Thanks,
> > -Syed
> >
> > On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
> >> Hi All,
> >>
> >> I have the patch for adding SSL termination support at
> >> https://reviews.apache.org/r/14976/ . It would be great if this can
> >> be reviewed.
> >>
> >> Thanks,
> >> -Syed
> >>
> >> On 13-10-15 03:01 AM, Murali Reddy wrote:
> >>> On 11/10/13 9:31 PM, "Syed Ahmed"  wrote:
> >>>
> >>>> Thanks for your valuable feedback Murali. Here are my comments.
> >>>>
> >>>>> IMO,
> >>>>> its better we introduce new api's say
> >>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalance
> >>>>> r
> >>>>> than
> >>>>> force fit existing API's for associate/dis-associate certificates.
> >>>> Personally, I was going to do it this way. But I am not sure how
> >>>> good of an idea it is to add a new api just for this feature as I
> >>>> can see assignToLoadbalancer is semantically similar. But if
> >>>> everyone agrees I have no problem with it.
> >>> CloudStack already has distinct API's for each of the LB
> >>> sub-functionality (health check, stickiness etc) [1]. We are not
> >>> adding any redundant API, so resulting API are much cleaner just
> >>> managing SSL termination for a LB rule.
> >>>
> >>>>> On second thought may be an CloudStack usage event on assigning
> >>>>> certificate seems good enough to me.
> >>>> So what I got from your earlier post was that when adding a
> >>>> network offering the provider can choose to enable SSL Termination
> >>>> or not as it is a value added service. I was thinking of adding
> >>>> "SSL termination"
> >>>> under supportedservices for the  createNetworkOffering API call.
> >>>> And when someone calls the API to assign a cert to LB we can check
> >>>> if this network offering has SSL termination enabled. Does this
> make sense?
> >>> So there is notion of network service and network service capability
> >>> [2].
> >>> I would attribute 'SSL termination' as capability of LB service.
> >>> createNetworkOffering API take a capability list. It does make sense
> >>> to check if the network offering has SSL termination enabled when
> >>> API to assign a cert to LB is called. Also note that, 'Network
> Elements'
> >>> declare
> >>> their capabilities for the supported services. So it can verified
> >>> that service provider for LB actually supports 'SSL termination'
> >>> capability while creating network offering.
> >>>
> >>>
> >>>> Also when you say usage event, what does this imply? I am sorry I
> >>>> am not familiar with that term. Can you please elaborate.
> >>> Its an event generated and persisted in the DB for every resource
> >>> consumption and release. These events are used for billing etc.
> >>> Please check publishUsageEvent calls in the code.
> >>>
> >>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
> >>> [2] api/src/com/cloud/network/Network.java
> >>>
> >>
> >
> >
> 

RE: [ACS43] Schedule reminder : feature freeze this Friday 11/08

[Animesh Chaturvedi]

Chip can you confirm if the IP clearance is done, should Devdeep proceed with 
merging into master?

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Tuesday, November 05, 2013 9:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS43] Schedule reminder : feature freeze this Friday
> 11/08
> 
> One thing to note, and perhaps this becomes a minor exception to the
> merge timing.  IP Clearance for the RDP client won't be done until the
> morning of the 7th.
> 
> I'd propose that it is brought in to master at that time.  I won't have
> time to do the actual commit myself, but perhaps someone can own
> handling this on the morning of the 7th (ET).  Any takers?
> 
> -chip
> 
> On Mon, Nov 4, 2013 at 9:58 PM, Animesh Chaturvedi
>  wrote:
> > Folks
> >
> > Friday 11/8 is the feature freeze date for ACS 4.3. If your
> contribution is unlikely to make it to 4.3 feature freeze on 11/8 please
> move them out of 4.3 release to 'Future'.
> >
> > Do remember that we have a 72 hour notice period to solicit feedback
> for MERGE requests. So the absolute last day for merge requests for 4.3
> features/ improvements is tomorrow 11/05. Contributors if you have
> patches in reviewboard that you had planned for 4.3 make sure to follow
> up with reviewers. The contribution has to be in master after satisfying
> any merge concerns / review comments  by 11/08 to be included  in 4.3.0
> release.
> >
> >
> > For detailed branch merge requirement check [1]
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Ex
> > pectations
> >
> >
> > Thanks
> > Animesh
> >
> >

Re: Review Request 15068: Change labels for VLAN to vNet

[Animesh Chaturvedi]

> On Nov. 4, 2013, 10:24 p.m., Jessica Wang wrote:
> > Ship It!

Has this been applied? 


- Animesh


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


On Nov. 1, 2013, 4:52 p.m., Chris Cameron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15068/
> ---
> 
> (Updated Nov. 1, 2013, 4:52 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle, Jessica Wang, Marcus Sorensen, 
> Pranav Saxena, and Toshiaki Hatano.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We would like to change the labels for VLAN to vNet to make the term more 
> generic for VXLAN and VLAN. This relates to the work being done to add in 
> VXLAN support to Cloudstack.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties 3210aca 
>   ui/dictionary.jsp 35cba22 
>   ui/scripts/network.js 12e5389 
>   ui/scripts/system.js 479883c 
> 
> Diff: https://reviews.apache.org/r/15068/diff/
> 
> 
> Testing
> ---
> 
> Checked through the GUI for changed elements.
> 
> 
> Thanks,
> 
> Chris Cameron
> 
>

RE: [Merge] Palo Alto Networks firewall integration to master

[Animesh Chaturvedi]

Fails RAT on 
plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java


> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: Wednesday, November 06, 2013 10:15 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [Merge] Palo Alto Networks firewall integration to master
> 
> Great!  Thank you Sheng...
> 
> 
> On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang  wrote:
> 
> > Looks good to me.
> >
> > Applied to MASTER branch. Thanks!
> >
> > --Sheng
> >
> >
> > On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens 
> > wrote:
> >
> > > @Sheng:  This should be ready to go now.  I built the patch from
> > tonight's
> > > master and I included a more detailed commit message as you
> requested.
> >  Let
> > > me know if you have any questions/problems...
> > >
> > > @David:  As per this discussion (and a previous one [1]), I have
> > > moved
> > this
> > > code from being built with the depreciated 'nonoss' flag to core
> > > since it does not depend on any 3rd party libraries at build or
> runtime.
> > >
> > > Cheers,
> > >
> > > Will
> > >
> > > [1]
> > >
> > >
> > http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
> > ubator%2Ecloudstack-%2A+Palo+Alto
> > >
> > >
> > > On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
> > > 
> > > wrote:
> > >
> > > > Thanks for that David.  You are absolutely correct, this plugin
> > > > has no dependencies on any 3rd party code at build or runtime.
> > > > Everything the plugin requires is built into the plugin.  I was
> > > > unclear if its
> > > dependance
> > > > on a 3rd party API and appliance to be functional was relevant.
> > > >
> > > > I think you are right.  I think it should probably be in the core
> > build.
> > > >  I will make that change when I merge in the latest master for
> > > > Sheng
> > and
> > > > rebuild the patch.
> > > >
> > > > Thanks,
> > > >
> > > > Will
> > > >
> > > >
> > > > On Tue, Nov 5, 2013 at 10:19 AM, David Nalley 
> wrote:
> > > >
> > > >> So perhaps a bit of history.
> > > >>
> > > >> nonoss/noredist is for targets that aren't built 'by default'
> (e.g.
> > > >> you must explicitly turn them on). We do this because the ASF
> > > >> wants the default build to be truly unencumbered and where there
> > > >> are dependencies on non-open source, or non-Apache compatible
> > > >> code, we typically turn them off. In example: historically,
> > > >> Netscaler libraries were not open source, and we had a dependency
> > > >> on those libraries, so we placed the netscaler plugin into the
> > > >> nonoss. Since then the netscaler libraries have been open
> > > >> sourced, and we could move those out of noredist.
> > > >>
> > > >> So - is there third party code that you have as a build or
> > > >> runtime dependency? If so what is the license for that third
> > > >> party code? (My really fast perusal didn't catch anything that
> > > >> was immediately
> > > >> troubling)
> > > >>
> > > >> --David
> > > >>
> > > >> On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
> > > >> 
> > > >> wrote:
> > > >> > Its dependence on a third party API and appliance, similar to
> > > >> > the
> > srx
> > > >> and
> > > >> > netscaler. I am not convinced it should be in noredist, but I
> > > >> > was
> > > >> following
> > > >> > the same model as other similar plugins.  Feedback on this
> > > >> > would be helpful.
> > > >> >
> > > >> > Ws
> > > >> >
> > > >> > On Tuesday, November 5, 2013, David Nalley wrote:
> > > >> >
> > > >> >> On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens <
> > wstev...@cloudops.com
> > > >> >
> > > >> >> wrote:
> > > >> >> > Sheng, I will rebuild the patch for the latest master.  The
> > latest
> > > >> master
> > > >> >> > has depreciated the 'nonoss' flag in favour of 'noredist'. I
> > > >> >> > was
> > > >> building
> > > >> >> > in nonoss previously. I am guessing I should use the
> > > >> >> > noredist
> > flag
> > > >> now?
> > > >> >> >
> > > >> >>
> > > >> >> Will - what is causing this to be noredist/nonoss? My quick
> > > >> >> perusal
> > > of
> > > >> >> your patch didn't surface anything that would push it into
> > > >> >> that category.
> > > >> >>
> > > >> >> --David
> > > >> >>
> > > >>
> > > >
> > > >
> > >
> >

Reviewboard needs your attention

[Animesh Chaturvedi]

There are large number of patches in review board. I went through some of them 
and followed up and closed out few that are already checked in, but the list is 
huge. Given that we are approaching the 4.3 feature freeze tomorrow if you have 
submitted patches and are still pending reviews please reach out to your 
reviewers. If you have received feedback on your patch please provide an 
updated patch. Reviewers take a moment to review the patches under your name 
and help clear up the reviews.


If you are unsure how to help please check Review Board Guidelines [1]

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines

Re: Review Request 14381: KVM: add connect/disconnect capabilities to StorageAdaptors so that external storage services can attach/detach devices on-demand

[Animesh Chaturvedi]

> On Oct. 7, 2013, 7:49 p.m., Mike Tutkowski wrote:
> > This looks reasonable to me, Marcus.
> > 
> > When do you think you might start the process of getting this into master?

is this expected for 4.3? then this should be in master soon


- Animesh


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


On Sept. 30, 2013, 5:14 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14381/
> ---
> 
> (Updated Sept. 30, 2013, 5:14 p.m.)
> 
> 
> Review request for cloudstack, edison su and Mike Tutkowski.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> With custom storage plugins comes the need to prep the KVM host prior to 
> utilizing the disks. e.g. an iscsi initiator needs to log into the target and 
> scan for the lun before it can be used on the host. This patch is an example 
> I developed against 4.2, minor changes may be necessary to apply to master, 
> but I want to share with others who are working on storage so they can ensure 
> it works for them. Please tweak as you see fit.
> 
> MigrateCommand: pass vmTO object so we can see which disks/storage pool types 
> belong to the vm when migrating a VM. This facilitates being able to call 
> disconnectPhysicalDisksViaVmSpec
> 
> VirtualMachineManagerImpl: pass VirtualMachineTO when migrating so that we 
> can see which disks belong to the VM and what storage pools/adaptors should 
> be used
> 
> LibvirtComputingResource: add calls KVMStoragePoolManager's 
> connectPhysicalDiskViaVmSpec and disconnectPhysicalDiskViaVmSpec calls where 
> appropriate (when starting a vm, migrating a vm). Ensure that we create 'raw' 
> format XML disk definitions when the storage format is RAW. Move cleanupDisk 
> logic to storage adaptors so that each adaptor type can clean up its disks in 
> is own way.
> 
> KVMStoragePoolManager:  add connectPhysicalDisk, disconnectPhysicalDisk, 
> connectPhysicalDiskViaVmSpec, disconnectPhysicalDiskViaVmSpec, 
> disconnectPhysicalDiskByPath. These all call the specific StorageAdaptor's 
> connectPhysicalDisk, disconnectPhysicalDisk, or disconnectPhysicalDiskByPath 
> calls.
> 
> KVMStorageProcessor: Call connectPhysicalDisk/disconnectPhysicalDisk on the 
> storage adaptor. Whether or not this is implemented is up to the storage 
> adaptor.
> 
> LibvirtStorageAdaptor: implement dummy 
> connectPhysicalDisk/disconnectPhysicalDisk, move cleanupDisk logic from 
> LibvirtComputingResource to disconnectPhysicalDiskByPath
> 
> StorageAdaptor: define 
> connectPhysicalDisk/disconnectPhysicalDisk/disconnectPhysicalDiskByPath in 
> the interface
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/api/MigrateCommand.java 5042b8c 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  3ee811f 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
>  e09c9ba 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java
>  c69f9b0 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  123a9f1 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java
>  4956d8d 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java d46bbb0 
> 
> Diff: https://reviews.apache.org/r/14381/diff/
> 
> 
> Testing
> ---
> 
> Basic testing with my storage adaptor
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: Review Request 12679: CLOUDSTACK-904: Changed multiple vcpus to one vcpu with multiple sockets

[Animesh Chaturvedi]

> On July 17, 2013, 4:43 p.m., Wido den Hollander wrote:
> > Hmm, I'm not sure about this one.
> > 
> > In the UI we indeed mention the amount of cores, however, the API parameter 
> > is "cpunumber".
> > 
> > So I get the reasoning, but we would be changing a lot here. I don't know 
> > if this changes anything by the way Qemu spreads out threads over the 
> > hypervisor's cores?
> 
> Rene Diepstraten wrote:
> Perhaps it's best if it's decided that a complete review of the cpu cores 
> model is needed.
> The API should in my opinion accept both cpu sockets and cpu cores as 
> parameters. It should for example be possible to create a vm with 2 sockets 
> and 16 cores.
> Qemu/KVM does support this for quite some time, as do for example Red Hat 
> Enterprise Virtualization and Proxmox VE, which both use KVM .
>

May be this should be brought to mailing list as a DISCUSS topic?


- Animesh


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


On July 18, 2013, 4:06 p.m., Rene Diepstraten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12679/
> ---
> 
> (Updated July 18, 2013, 4:06 p.m.)
> 
> 
> Review request for cloudstack and Wido den Hollander.
> 
> 
> Bugs: CLOUDSTACK-904
> https://issues.apache.org/jira/browse/CLOUDSTACK-904
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cloudstack defines a vm with multiple CPUs instead of one CPU with multiple 
> cores. 
> For Windows as well as RHEL guests, the license is based on the amount of CPU 
> sockets.
> The definition of VCPUs should therefore translate to the amount of cores, 
> not CPUs.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
>  5120870 
> 
> Diff: https://reviews.apache.org/r/12679/diff/
> 
> 
> Testing
> ---
> 
> Only tested the output of the append rule.
> 
> 
> Thanks,
> 
> Rene Diepstraten
> 
>

Re: Review Request 12660: Replaced multiple grep/awk/head commands by one awk

[Animesh Chaturvedi]

> On July 26, 2013, 10:24 p.m., Jenkins Cloudstack.org wrote:
> > Review 12660 failed the build test : FAILURE
> > The url of build cloudstack-master-with-patch #55 is : 
> > http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/55/

Patch needs to br updated, fails the build


- Animesh


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


On July 18, 2013, 3:57 p.m., Rene Diepstraten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12660/
> ---
> 
> (Updated July 18, 2013, 3:57 p.m.)
> 
> 
> Review request for cloudstack and Wido den Hollander.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Replaced multiple grep/awk/head commands by one awk.
> 
> 
> Diffs
> -
> 
>   scripts/vm/network/security_group.py c1c87da 
> 
> Diff: https://reviews.apache.org/r/12660/diff/
> 
> 
> Testing
> ---
> 
> Tested output. Not able to test using cloudstack function execute() or real 
> ebtables output.
> 
> 
> Thanks,
> 
> Rene Diepstraten
> 
>

RE: [Merge] Palo Alto Networks firewall integration to master

[Animesh Chaturvedi]

RAT is release audit tool and checks for missing license headers. You can run 
it as below


mvn --projects='org.apache.cloudstack:cloudstack' 
org.apache.rat:apache-rat-plugin:0.8:check


The build should FAIL if there are any non-compliant files that are not 
specifically excluded from the ASF license header requirement. You can 
optionally review the target/rat.txt file after the run completes. 


> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: Thursday, November 07, 2013 10:51 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [Merge] Palo Alto Networks firewall integration to master
> 
> Just so I know, can you explain what it means to 'Fail RAT'?  Thx...
> 
> 
> On Thu, Nov 7, 2013 at 1:46 PM, Sheng Yang  wrote:
> 
> > Fixed.
> >
> > --Sheng
> >
> >
> > On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi <
> > animesh.chaturv...@citrix.com> wrote:
> >
> > > Fails RAT on
> > >
> > plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpCli
> > entWrapper.java
> > >
> > >
> > > > -Original Message-
> > > > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com]
> > > > On Behalf Of Will Stevens
> > > > Sent: Wednesday, November 06, 2013 10:15 AM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: [Merge] Palo Alto Networks firewall integration to
> > > > master
> > > >
> > > > Great!  Thank you Sheng...
> > > >
> > > >
> > > > On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang 
> wrote:
> > > >
> > > > > Looks good to me.
> > > > >
> > > > > Applied to MASTER branch. Thanks!
> > > > >
> > > > > --Sheng
> > > > >
> > > > >
> > > > > On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > @Sheng:  This should be ready to go now.  I built the patch
> > > > > > from
> > > > > tonight's
> > > > > > master and I included a more detailed commit message as you
> > > > requested.
> > > > >  Let
> > > > > > me know if you have any questions/problems...
> > > > > >
> > > > > > @David:  As per this discussion (and a previous one [1]), I
> > > > > > have moved
> > > > > this
> > > > > > code from being built with the depreciated 'nonoss' flag to
> > > > > > core since it does not depend on any 3rd party libraries at
> > > > > > build or
> > > > runtime.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Will
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
> > > > > ubator%2Ecloudstack-%2A+Palo+Alto
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
> > > > > > 
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks for that David.  You are absolutely correct, this
> > > > > > > plugin has no dependencies on any 3rd party code at build or
> runtime.
> > > > > > > Everything the plugin requires is built into the plugin.  I
> > > > > > > was unclear if its
> > > > > > dependance
> > > > > > > on a 3rd party API and appliance to be functional was
> relevant.
> > > > > > >
> > > > > > > I think you are right.  I think it should probably be in the
> > > > > > > core
> > > > > build.
> > > > > > >  I will make that change when I merge in the latest master
> > > > > > > for Sheng
> > > > > and
> > > > > > > rebuild the patch.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Will
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Nov 5, 2013 at 10:19 AM, David Nalley
> > > > > > > 
&g

RE: [ACS43] Schedule reminder : feature freeze this Friday 11/08

[Animesh Chaturvedi]

That's what I thought because you had said 7th morning

> -Original Message-
> From: Chip Childers [mailto:chip.child...@gmail.com]
> Sent: Thursday, November 07, 2013 10:59 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS43] Schedule reminder : feature freeze this Friday
> 11/08
> 
> I was off - this morning it cleared.  Sorry.
> 
> Merge away.
> 
> On Thu, Nov 7, 2013 at 1:55 PM, Chip Childers 
> wrote:
> > Please wait for tomorrow morning US time. 72 hours is not up yet.
> >
> >> On Nov 7, 2013, at 12:45 PM, Animesh Chaturvedi
>  wrote:
> >>
> >> Chip can you confirm if the IP clearance is done, should Devdeep
> proceed with merging into master?
> >>
> >>> -Original Message-
> >>> From: Chip Childers [mailto:chipchild...@apache.org]
> >>> Sent: Tuesday, November 05, 2013 9:36 AM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [ACS43] Schedule reminder : feature freeze this Friday
> >>> 11/08
> >>>
> >>> One thing to note, and perhaps this becomes a minor exception to the
> >>> merge timing.  IP Clearance for the RDP client won't be done until
> >>> the morning of the 7th.
> >>>
> >>> I'd propose that it is brought in to master at that time.  I won't
> >>> have time to do the actual commit myself, but perhaps someone can
> >>> own handling this on the morning of the 7th (ET).  Any takers?
> >>>
> >>> -chip
> >>>
> >>> On Mon, Nov 4, 2013 at 9:58 PM, Animesh Chaturvedi
> >>>  wrote:
> >>>> Folks
> >>>>
> >>>> Friday 11/8 is the feature freeze date for ACS 4.3. If your
> >>> contribution is unlikely to make it to 4.3 feature freeze on 11/8
> >>> please move them out of 4.3 release to 'Future'.
> >>>>
> >>>> Do remember that we have a 72 hour notice period to solicit
> >>>> feedback
> >>> for MERGE requests. So the absolute last day for merge requests for
> >>> 4.3 features/ improvements is tomorrow 11/05. Contributors if you
> >>> have patches in reviewboard that you had planned for 4.3 make sure
> >>> to follow up with reviewers. The contribution has to be in master
> >>> after satisfying any merge concerns / review comments  by 11/08 to
> >>> be included  in 4.3.0 release.
> >>>>
> >>>>
> >>>> For detailed branch merge requirement check [1]
> >>>>
> >>>> [1]
> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge
> >>>> +Ex
> >>>> pectations
> >>>>
> >>>>
> >>>> Thanks
> >>>> Animesh
> >>>>
> >>>>

RE: Review Request 14381: KVM: add connect/disconnect capabilities to StorageAdaptors so that external storage services can attach/detach devices on-demand

[Animesh Chaturvedi]

Ok I closed out the review as "submitted"

> -Original Message-
> From: Mike Tutkowski [mailto:nore...@reviews.apache.org] On Behalf Of
> Mike Tutkowski
> Sent: Thursday, November 07, 2013 1:03 PM
> To: Edison Su; Mike Tutkowski
> Cc: Marcus Sorensen; cloudstack
> Subject: Re: Review Request 14381: KVM: add connect/disconnect
> capabilities to StorageAdaptors so that external storage services can
> attach/detach devices on-demand
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14381/#review28443
> ---
> 
> Ship it!
> 
> 
> Ship It!
> 
> - Mike Tutkowski
> 
> 
> On Sept. 30, 2013, 5:14 p.m., Marcus Sorensen wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/14381/
> > ---
> >
> > (Updated Sept. 30, 2013, 5:14 p.m.)
> >
> >
> > Review request for cloudstack, edison su and Mike Tutkowski.
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > With custom storage plugins comes the need to prep the KVM host prior
> to utilizing the disks. e.g. an iscsi initiator needs to log into the
> target and scan for the lun before it can be used on the host. This
> patch is an example I developed against 4.2, minor changes may be
> necessary to apply to master, but I want to share with others who are
> working on storage so they can ensure it works for them. Please tweak as
> you see fit.
> >
> > MigrateCommand: pass vmTO object so we can see which disks/storage
> pool types belong to the vm when migrating a VM. This facilitates being
> able to call disconnectPhysicalDisksViaVmSpec
> >
> > VirtualMachineManagerImpl: pass VirtualMachineTO when migrating so
> that we can see which disks belong to the VM and what storage
> pools/adaptors should be used
> >
> > LibvirtComputingResource: add calls KVMStoragePoolManager's
> connectPhysicalDiskViaVmSpec and disconnectPhysicalDiskViaVmSpec calls
> where appropriate (when starting a vm, migrating a vm). Ensure that we
> create 'raw' format XML disk definitions when the storage format is RAW.
> Move cleanupDisk logic to storage adaptors so that each adaptor type can
> clean up its disks in is own way.
> >
> > KVMStoragePoolManager:  add connectPhysicalDisk,
> disconnectPhysicalDisk, connectPhysicalDiskViaVmSpec,
> disconnectPhysicalDiskViaVmSpec, disconnectPhysicalDiskByPath. These all
> call the specific StorageAdaptor's connectPhysicalDisk,
> disconnectPhysicalDisk, or disconnectPhysicalDiskByPath calls.
> >
> > KVMStorageProcessor: Call connectPhysicalDisk/disconnectPhysicalDisk
> on the storage adaptor. Whether or not this is implemented is up to the
> storage adaptor.
> >
> > LibvirtStorageAdaptor: implement dummy
> connectPhysicalDisk/disconnectPhysicalDisk, move cleanupDisk logic from
> LibvirtComputingResource to disconnectPhysicalDiskByPath
> >
> > StorageAdaptor: define
> connectPhysicalDisk/disconnectPhysicalDisk/disconnectPhysicalDiskByPath
> in the interface
> >
> >
> > Diffs
> > -
> >
> >   core/src/com/cloud/agent/api/MigrateCommand.java 5042b8c
> >
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtCom
> putingResource.java 3ee811f
> >
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageP
> oolManager.java e09c9ba
> >
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageP
> rocessor.java c69f9b0
> >
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStor
> ageAdaptor.java 123a9f1
> >
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdap
> tor.java 4956d8d
> >   server/src/com/cloud/vm/VirtualMachineManagerImpl.java d46bbb0
> >
> > Diff: https://reviews.apache.org/r/14381/diff/
> >
> >
> > Testing
> > ---
> >
> > Basic testing with my storage adaptor
> >
> >
> > Thanks,
> >
> > Marcus Sorensen
> >
> >

RE: Reviewboard needs your attention

[Animesh Chaturvedi]

I can see it fine, were you logged in at that time

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Thursday, November 07, 2013 6:03 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Reviewboard needs your attention
> 
> Hi Animesh,
> 
> For whatever reason, I can no longer edit
> https://reviews.apache.org/r/13865/.
> 
> Any thoughts on this?
> 
> Thanks!
> 
> 
> On Thu, Nov 7, 2013 at 6:41 PM, Nguyen Anh Tu  wrote:
> 
> > 2013/11/8 Animesh Chaturvedi 
> >
> > > Given that we are approaching the 4.3 feature freeze tomorrow if you
> > > have submitted patches and are still pending reviews please reach
> > > out to your reviewers
> >
> >
> > Dear Sebastien & Hugo,
> >
> > I have two pending patches on review board need to review:
> >
> > Rebase OVS (sdnextensions branch) to master branch:
> > https://reviews.apache.org/r/15205/
> > AutoScaling without NetScaler: https://reviews.apache.org/r/14628/
> >
> > Thanks,
> >
> >
> > --
> >
> > N.g.U.y.e.N.A.n.H.t.U
> >
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

RE: Reviewboard needs your attention

[Animesh Chaturvedi]

Mike is this the only review that you cannot see, or it's a general problem you 
are seeing with reviewboard. May be try another browser

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, November 08, 2013 4:47 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Reviewboard needs your attention
> 
> This is what I see when logged in:
> 
> http://i.imgur.com/RZvXuy1.png
> 
> Am I missing something?
> 
> Thanks!
> 
> 
> On Thu, Nov 7, 2013 at 10:01 PM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
> 
> > I can see it fine, were you logged in at that time
> >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Thursday, November 07, 2013 6:03 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: Reviewboard needs your attention
> > >
> > > Hi Animesh,
> > >
> > > For whatever reason, I can no longer edit
> > > https://reviews.apache.org/r/13865/.
> > >
> > > Any thoughts on this?
> > >
> > > Thanks!
> > >
> > >
> > > On Thu, Nov 7, 2013 at 6:41 PM, Nguyen Anh Tu 
> wrote:
> > >
> > > > 2013/11/8 Animesh Chaturvedi 
> > > >
> > > > > Given that we are approaching the 4.3 feature freeze tomorrow if
> > > > > you have submitted patches and are still pending reviews please
> > > > > reach out to your reviewers
> > > >
> > > >
> > > > Dear Sebastien & Hugo,
> > > >
> > > > I have two pending patches on review board need to review:
> > > >
> > > > Rebase OVS (sdnextensions branch) to master branch:
> > > > https://reviews.apache.org/r/15205/
> > > > AutoScaling without NetScaler: https://reviews.apache.org/r/14628/
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > --
> > > >
> > > > N.g.U.y.e.N.A.n.H.t.U
> > > >
> > >
> > >
> > >
> > > --
> > > *Mike Tutkowski*
> > > *Senior CloudStack Developer, SolidFire Inc.*
> > > e: mike.tutkow...@solidfire.com
> > > o: 303.746.7302
> > > Advancing the way the world uses the
> > > cloud<http://solidfire.com/solution/overview/?video=play>
> > > *(tm)*
> >
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

RE: api incompatibility between 4.1 and 4.2 in ACLs

[Animesh Chaturvedi]

I will let Kishan comment but found this thread 
http://markmail.org/thread/fxzki6ftqacyrylk


> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Friday, November 08, 2013 9:13 AM
> To: dev@cloudstack.apache.org
> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
> 
> So I take the silence to simply be a collective "oops".  I guess this
> just should serve as a reminder to not break API compatibility without a
> discussion. Perhaps our tests will surface this better in the future
> (although I need to look, I wonder if any ACL tests were also simply
> changed to accomodate the new behavior).
> 
> On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen 
> wrote:
> > Maybe this has been discussed already, but we seem to have run into an
> > api incompatibility. In 4.1, you could create ad-hoc ACL rules that
> > applied to a network. In 4.2, you have to first create an 'ACL list',
> > then add those rules to the list, then apply the list to a network. Or
> > so it seems.  This means that applications that are coded to the
> > cloudstack API and utilize createNetworkACL will break, because the
> > flow has changed.
> >
> > Am I correct on this? And if so, shouldn't we have deployed 4.2 as
> > 5.0, since the stated versioning is based on API compatibility?

RE: api incompatibility between 4.1 and 4.2 in ACLs

[Animesh Chaturvedi]

Actually use this link to the message in that thread http://s.apache.org/QKI



> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, November 08, 2013 11:24 AM
> To: dev@cloudstack.apache.org
> Cc: Kishan Kavala
> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
> 
> 
> I will let Kishan comment but found this thread
> http://markmail.org/thread/fxzki6ftqacyrylk
> 
> 
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Friday, November 08, 2013 9:13 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
> >
> > So I take the silence to simply be a collective "oops".  I guess this
> > just should serve as a reminder to not break API compatibility without
> > a discussion. Perhaps our tests will surface this better in the future
> > (although I need to look, I wonder if any ACL tests were also simply
> > changed to accomodate the new behavior).
> >
> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen 
> > wrote:
> > > Maybe this has been discussed already, but we seem to have run into
> > > an api incompatibility. In 4.1, you could create ad-hoc ACL rules
> > > that applied to a network. In 4.2, you have to first create an 'ACL
> > > list', then add those rules to the list, then apply the list to a
> > > network. Or so it seems.  This means that applications that are
> > > coded to the cloudstack API and utilize createNetworkACL will break,
> > > because the flow has changed.
> > >
> > > Am I correct on this? And if so, shouldn't we have deployed 4.2 as
> > > 5.0, since the stated versioning is based on API compatibility?