Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[Wei Zhou]

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

(Updated Sept. 9, 2013, 8:09 a.m.)


Review request for cloudstack and edison su.


Changes
---

(3) change rpm and debian packaging to support automatic update (c1-c4)

Testing ok in CentOS and Ubuntu installation.


Bugs: CLOUDSTACK-4405


Repository: cloudstack-git


Description
---

There still exist two issues after Edison's commits.
(1) Migration from new hosts to old hosts failed.
The bridge name on old host is set to cloudVirBr* if network.bridge.name.schema 
is set to 3.0 in /etc/cloudstack/agent/agent.properties, but the actual bridge 
name is breth*-* after running cloudstack-agent-upgrade.

(2) all ports of vms (Basic zone, or Advanced zone with security groups) on old 
hosts are open, because the iptables rules are binding to device (bridge) name 
which is changed by cloudstack-agent-upgrade.


Diffs (updated)
-

  agent/bindir/cloudstack-agent-upgrade.in 4972d39 
  debian/cloudstack-agent.postinst 499ae6a 
  debian/rules 5e3d58c 
  packaging/centos63/cloud.spec 2b814f8 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 e3779a7 
  scripts/vm/network/security_group.py 0ac8b74 

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


Testing
---

tested ok on my environment.

After this, the KVM upgrade steps :
a. Install 4.2 cloudstack agent on each kvm host 
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
bridge name to new bridge name, and update related firewall rules.
   c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
/etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
c5. service cloudstack-agent restart


Thanks,

Wei Zhou

Re: documentation/wiki is a mess

[Daan Hoogland]

+1 to Darren's 'We should be careful about "no X, no commit"' One
exception though; (unit)tests. And I can live with a #!human script
like Marty describes. Even though your point is valid, David,
developers (like me) have an internal company need for a fix or a
feature, and are inclined to work on it as priority shifts. It is not
a good idea to allow for features only as they are becoming proven
technology. When done they are done. When used they become documented.
When unused they will eventually leave the code base again.

no rant intended,
Daan

On Fri, Sep 6, 2013 at 3:42 PM, Tracy Phillips  wrote:
> +1 to Marty.
>
>
> On Fri, Sep 6, 2013 at 2:32 AM, Marty Sweet  wrote:
>
>> My view is that when a feature is added the developer should give a short
>> overview of how to use all of the items which have been added, a doc
>> contributor can then write this up in a user friendly manner which is
>> similar to the whole style of the rest of the documentation.
>>
>> Example description of documentation subtask on feature bug:
>> -> Click Storage Tab
>> -> Click on the volume you require
>> -> Click the 'Resize Volume' icon, this may only appear if xyz
>> -> Put in a value
>>  -> If it's less then it will shrink, causing xyz
>>  -> If it's more then it will expand, although the user must expand the
>> filesystem in the OS (This then would create another document, as the
>> process differs on win/linux)
>>
>> The doc contributor then has a useful set of notes for reference, so they
>> don't have to spend lots of time trying to workout the in's and out's of a
>> implemented feature.
>>
>> Marty
>>
>>
>> On Thu, Sep 5, 2013 at 5:16 PM, Darren Shepherd <
>> darren.s.sheph...@gmail.com
>> > wrote:
>>
>> > On 09/05/2013 07:56 AM, David Nalley wrote:
>> >
>> >> On Thu, Sep 5, 2013 at 7:00 AM, Daan Hoogland 
>> >> wrote:
>> >>
>> >>> -1 on no docs no submits.
>> >>>
>> >>> Docs are important to people that need a contribution they didn't
>> >>> write themselves. The first ones are the ones to write docs where
>> >>> missing. You contribute because you need code, not because you need
>> >>> docs on it.
>> >>>
>> >>>
>> >> If the developer who wrote the code for a feature can't tell me (or
>> >> the rest of the userbase) how it works and how to use it, then I
>> >> question exactly how useful the feature is.
>> >>
>> >>
>> > Everyone should be on the hook to document in some fashion.  The doc
>> > writer are usually just better at it.
>> >
>> > So as somebody who is more dev focused, I just don't know where to put
>> > things.  I'm not about to touch the XML docs.  That seems like a doc
>> team's
>> > domain.
>> >
>> > So personally I'd like to see a bit more organization in the wiki and
>> then
>> > a clear cut definition of when stuff goes to the XML.  Additional
>> proposals
>> > and design specs don't count as documenting functionality. Those things
>> are
>> > just SDLC artifacts.  Frankly I think the current design template should
>> > have the scope, impact, and QA notes and then link to another place in
>> the
>> > wiki with the design.  As the development is in progress the wiki page
>> can
>> > be marked with WIP.
>> >
>> > We should be careful about "no X, no commit" policies.  We don't want to
>> > discourage contributions.  Documentation is useful and if somebody wants
>> to
>> > contribute then I think they would be inclined to put some documentation
>> > such that it can be used by other people.  If we make the process easy
>> and
>> > obvious to do such, I think more documentation will exist.
>> >
>> > Darren
>> >
>> >
>>

Re: [ANNOUNCE] New Committer: Dave Cahill

[Daan Hoogland]

good, Dave. At it!

On Sat, Sep 7, 2013 at 6:01 PM, Saksham Srivastava
 wrote:
> Congrats Dave.
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Saturday, September 7, 2013 7:51 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New Committer: Dave Cahill
>
> The Project Management Committee (PMC) for Apache CloudStack has asked Dave 
> Cahill to become a committer and we are pleased to announce that he has 
> accepted.
>
> Dave has been an active member of the community for quite awhile, and has 
> provided us with things such as the midonet plugin, multiple patches, 
> bugfixes, feedback, and suggestions.
>
> Being a committer enables easier contribution to the project since there is 
> no need to go via the patch submission process. This should enable better 
> productivity.
>
> Please join us in congratulating Dave!

[Responsiveness report] 2013w35

[Daan Hoogland]

H, Is anybody still using these?

http://markmail.org/message/xixk3pnxa7g7ykyx Missing resize volume
button for users in 4.1.1? by Salvatore Sciacco
http://markmail.org/message/o47d6xh7na6qjmgb Web console cannot go up
in CloudStack 4.1.1 + XenServer 6.1 by Minh

regards

[Responsiveness report] users 2013w36

[Daan Hoogland]

http://markmail.org/message/5pfd3por7uvhntgh Change vncterm in
XenServer 6.0.2 for CloudStack 4.1.1 by Minh

regards,

[Responsiveness report] dev 2013w35

[Daan Hoogland]

http://markmail.org/message/ks6rikz4zgocvwep CloudStack + XCP by
Thomas Schneider

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chip Childers]

On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> -1 ... sorry guys, especially with Simon chiming in.
> 
> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.

Agreed.

I'm -1, given simon's perspective as well.  Since we have the fix, let's
get it into the release.

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[Wei Zhou]

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


please ignore the r2 version for issue CLOUDSTACK-3565

- Wei Zhou


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Simon Weller]

-1 from me as well. 


I know we're trying to hit timed releases, but I think it's very important to 
preserve key underlying functionality across releases. If a supported and 
documented feature is known to be broken, we need to address it...if we don't, 
it's going to cause lots of pain, and reflect badly on ACS as a project. 

- Original Message -

From: "Chip Childers"  
To: dev@cloudstack.apache.org 
Sent: Monday, September 9, 2013 9:24:23 AM 
Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round) 

On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote: 
> -1 ... sorry guys, especially with Simon chiming in. 
> 
> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked. 

Agreed. 

I'm -1, given simon's perspective as well. Since we have the fix, let's 
get it into the release. 

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chip Childers]

On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> -1 from me as well. 
> 
> 
> I know we're trying to hit timed releases, but I think it's very important to 
> preserve key underlying functionality across releases. If a supported and 
> documented feature is known to be broken, we need to address it...if we 
> don't, it's going to cause lots of pain, and reflect badly on ACS as a 
> project. 
> 

Agreed.  The idea of "time-based" is all about feature development.
Quality shouldn't be sacrificed.

Re: CS 4.2 release date

[Ron Wheeler]

There are still 10 unresolved issues that I have reported which should 
be fixed before It is released.


There is not much point releasing a system that will not install if you 
follow the instructions provided!



Ron

On 09/09/2013 12:10 AM, Travis Graham wrote:

The vote has been extended until at least EOD Monday.

On Sep 9, 2013, at 12:06 AM, Dean Kamali  wrote:


Any updates on this?


On Tue, Sep 3, 2013 at 6:10 AM, Sebastien Goasguen  wrote:


On Sep 3, 2013, at 6:03 AM, Gaspare A Silvestri 
wrote:


Hello everybody,

when will the CS 4.2 version be released?

Thanks in advance,

Gaspare

Hi, there should be a new VOTE on the dev@ mailing list starting today or
tomorrow.
The vote is open to everyone registered on dev@ and is open for 72 hours.

So not before the end of the week,

-Sebastien








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Configuration variable changes...

[Alex Huang]

As part of the work to pull apart orchestration from self service, I made some 
changes to how configuration parameters work.  The problem with the current 
system are as follows:

- configuration variables are all stored as enums in Config.java which means 
plugins have to modify a single file.  We established that to be a bad pattern 
in some earlier thread.
- No way to tell during upgrades whether a config variable has become useless 
or if the defaults have changed.
- No way to consistently have variables be dynamically updated.
- No way to consistently migrate a global variable to a scoped variable.
- No way to use more than one type of storage (db) to store config variables.
- Some of the code are still using text strings to retrieve configuration.
- No way to consistently validate variables.  (although this is not done yet 
but I described how it can be done in this new framework.)

The changes are detailed on wiki [1].  There's a detail list of todo items in 
ConfigDepotImpl.java if you're interested in picking up any of the work.  The 
old way still works but I recommend we move all new way for new config 
parameters.

If everyone reviewed it all and like how it works then we can remove the old 
way of how it all works.

--Alex
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Matthew Fusaro]

I would agree, being someone who is interested in deploying CloudStack and
has been following the dev list for a while now to see what the status is,
I wouldn't touch this release with a 10 foot pole. Especially after the
last few build failures I've had. I understand the need to draw the line
but whats the point of a release thats riddled with fun landmines for the
user to step on?


On Mon, Sep 9, 2013 at 2:02 PM, Marcus Sorensen  wrote:

> Its the consequence of our anemic testing capability compared to the
> feature set. I don't think we can accept regressions in general at all for
> storage types, hypervisor types, network, etc unless it is due to an
> abandoned feature, otherwise it will be impossible for people to navigate a
> swiss cheese feature set. We will need a matrix showing each release and
> what's broken/working, maybe a helper app that will tell people which
> versions are safe.
> On Sep 9, 2013 11:52 AM, "Animesh Chaturvedi" <
> animesh.chaturv...@citrix.com>
> wrote:
>
> >
> >
> > > -Original Message-
> > > From: Chip Childers [mailto:chip.child...@sungard.com]
> > > Sent: Monday, September 09, 2013 8:25 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> > >
> > > On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> > > > -1 from me as well.
> > > >
> > > >
> > > > I know we're trying to hit timed releases, but I think it's very
> > > important to preserve key underlying functionality across releases. If
> a
> > > supported and documented feature is known to be broken, we need to
> > > address it...if we don't, it's going to cause lots of pain, and reflect
> > > badly on ACS as a project.
> > > >
> > >
> > > Agreed.  The idea of "time-based" is all about feature development.
> > > Quality shouldn't be sacrificed.
> >
> > [Animesh>] But we have to draw the line at some point otherwise we cannot
> > maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this
> > is our 4th VOTE round for 4.2. IMHO if something is in core orchestration
> > layer, failed upgrade, cannot install and the likes and affects most
> users
> > it should block a release. Other remaining issues should be picked up for
> > subsequent maintenance release. May be we should discuss when should be
> the
> > next maintenance release on 4.2, 4 weeks or 6 weeks rather than delaying
> > 4.2.
> >
> >
>



-- 
Thank you,
Matthew Fusaro
Zentific LLC
Developer & Network Engineer

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

Its the consequence of our anemic testing capability compared to the
feature set. I don't think we can accept regressions in general at all for
storage types, hypervisor types, network, etc unless it is due to an
abandoned feature, otherwise it will be impossible for people to navigate a
swiss cheese feature set. We will need a matrix showing each release and
what's broken/working, maybe a helper app that will tell people which
versions are safe.
On Sep 9, 2013 11:52 AM, "Animesh Chaturvedi" 
wrote:

>
>
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Monday, September 09, 2013 8:25 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >
> > On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> > > -1 from me as well.
> > >
> > >
> > > I know we're trying to hit timed releases, but I think it's very
> > important to preserve key underlying functionality across releases. If a
> > supported and documented feature is known to be broken, we need to
> > address it...if we don't, it's going to cause lots of pain, and reflect
> > badly on ACS as a project.
> > >
> >
> > Agreed.  The idea of "time-based" is all about feature development.
> > Quality shouldn't be sacrificed.
>
> [Animesh>] But we have to draw the line at some point otherwise we cannot
> maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this
> is our 4th VOTE round for 4.2. IMHO if something is in core orchestration
> layer, failed upgrade, cannot install and the likes and affects most users
> it should block a release. Other remaining issues should be picked up for
> subsequent maintenance release. May be we should discuss when should be the
> next maintenance release on 4.2, 4 weeks or 6 weeks rather than delaying
> 4.2.
>
>

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

We just need to have basic automated testing of every core supported
platform.  With 4.1 we released a product that didn't even work on Ubuntu
KVM, nobody tested it.  As long as we rely on devs to individually test
things at their leisure, we will always end up with 3-4 round release
votes. An RC should pass a test suite first, and that test suite should do
a basic test for every item we claim support for, BEFORE it goes up for a
vote.
On Sep 9, 2013 12:02 PM, "Chiradeep Vittal" 
wrote:

> Agree with Animesh.
> From a somewhat selfish perspective, I've gone through 2 rounds of
> testing, not relishing the 3rd round.
> There are literally hundreds of features in CloudStack. Another delay
> could bring one more bug (existing perhaps, or newly introduced).
> And another round of testing.
>
> Draw the line somewhere.
> --
> Chiradeep
>
>
> On 9/9/13 10:51 AM, "Animesh Chaturvedi" 
> wrote:
>
> >
> >
> >> -Original Message-
> >> From: Chip Childers [mailto:chip.child...@sungard.com]
> >> Sent: Monday, September 09, 2013 8:25 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >>
> >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> >> > -1 from me as well.
> >> >
> >> >
> >> > I know we're trying to hit timed releases, but I think it's very
> >> important to preserve key underlying functionality across releases. If a
> >> supported and documented feature is known to be broken, we need to
> >> address it...if we don't, it's going to cause lots of pain, and reflect
> >> badly on ACS as a project.
> >> >
> >>
> >> Agreed.  The idea of "time-based" is all about feature development.
> >> Quality shouldn't be sacrificed.
> >
> >[Animesh>] But we have to draw the line at some point otherwise we cannot
> >maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this
> >is our 4th VOTE round for 4.2. IMHO if something is in core orchestration
> >layer, failed upgrade, cannot install and the likes and affects most
> >users it should block a release. Other remaining issues should be picked
> >up for subsequent maintenance release. May be we should discuss when
> >should be the next maintenance release on 4.2, 4 weeks or 6 weeks rather
> >than delaying 4.2.
> >
>
>

Re: Configuration variable changes...

[Daan Hoogland]

Looks great Alex,

One question; Adding a scope or a multiplier is featured on the wiki
but not specified. Can you add a pointer to it?

Very nice indeed,
Daan

On Mon, Sep 9, 2013 at 7:20 PM, Alex Huang  wrote:
> As part of the work to pull apart orchestration from self service, I made 
> some changes to how configuration parameters work.  The problem with the 
> current system are as follows:
>
> - configuration variables are all stored as enums in Config.java which means 
> plugins have to modify a single file.  We established that to be a bad 
> pattern in some earlier thread.
> - No way to tell during upgrades whether a config variable has become useless 
> or if the defaults have changed.
> - No way to consistently have variables be dynamically updated.
> - No way to consistently migrate a global variable to a scoped variable.
> - No way to use more than one type of storage (db) to store config variables.
> - Some of the code are still using text strings to retrieve configuration.
> - No way to consistently validate variables.  (although this is not done yet 
> but I described how it can be done in this new framework.)
>
> The changes are detailed on wiki [1].  There's a detail list of todo items in 
> ConfigDepotImpl.java if you're interested in picking up any of the work.  The 
> old way still works but I recommend we move all new way for new config 
> parameters.
>
> If everyone reviewed it all and like how it works then we can remove the old 
> way of how it all works.
>
> --Alex
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Daan Hoogland]

hear hear,

but this can not be managed if not automated. not in 4 months or, with
a product like ACS not on a halve year basis. Weren't you advocating a
release dedicated to automated testing in another thread, Marcus?

Daan

On Mon, Sep 9, 2013 at 8:10 PM, Marcus Sorensen  wrote:
> We just need to have basic automated testing of every core supported
> platform.  With 4.1 we released a product that didn't even work on Ubuntu
> KVM, nobody tested it.  As long as we rely on devs to individually test
> things at their leisure, we will always end up with 3-4 round release
> votes. An RC should pass a test suite first, and that test suite should do
> a basic test for every item we claim support for, BEFORE it goes up for a
> vote.
> On Sep 9, 2013 12:02 PM, "Chiradeep Vittal" 
> wrote:
>
>> Agree with Animesh.
>> From a somewhat selfish perspective, I've gone through 2 rounds of
>> testing, not relishing the 3rd round.
>> There are literally hundreds of features in CloudStack. Another delay
>> could bring one more bug (existing perhaps, or newly introduced).
>> And another round of testing.
>>
>> Draw the line somewhere.
>> --
>> Chiradeep
>>
>>
>> On 9/9/13 10:51 AM, "Animesh Chaturvedi" 
>> wrote:
>>
>> >
>> >
>> >> -Original Message-
>> >> From: Chip Childers [mailto:chip.child...@sungard.com]
>> >> Sent: Monday, September 09, 2013 8:25 AM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> >>
>> >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
>> >> > -1 from me as well.
>> >> >
>> >> >
>> >> > I know we're trying to hit timed releases, but I think it's very
>> >> important to preserve key underlying functionality across releases. If a
>> >> supported and documented feature is known to be broken, we need to
>> >> address it...if we don't, it's going to cause lots of pain, and reflect
>> >> badly on ACS as a project.
>> >> >
>> >>
>> >> Agreed.  The idea of "time-based" is all about feature development.
>> >> Quality shouldn't be sacrificed.
>> >
>> >[Animesh>] But we have to draw the line at some point otherwise we cannot
>> >maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this
>> >is our 4th VOTE round for 4.2. IMHO if something is in core orchestration
>> >layer, failed upgrade, cannot install and the likes and affects most
>> >users it should block a release. Other remaining issues should be picked
>> >up for subsequent maintenance release. May be we should discuss when
>> >should be the next maintenance release on 4.2, 4 weeks or 6 weeks rather
>> >than delaying 4.2.
>> >
>>
>>

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[Kelven Yang]

John,

I understand. The effort we did in 4.1 was mainly to free developers from
the needs to work at low-level plumbing layer, prior to 4.1, not every
developer knows how to modify ComponentLocator safely, switching to a
standard framework can let us focus on Cloud operating business logic.

Breaking CloudStack into a more modularized architecture is a long journey
which we are still striving to get there, Daren's work will again bring us
one step closer, I think this incremental refactoring approach can help
reduce the turbulence during the flight and ensure smoother releases along
the way.

kelven


On 8/25/13 8:35 PM, "John Burwell"  wrote:

>Kelven,
>
>Please don't take my proposal as a criticism of the approach taken in
>4.1.  I think the current model is a big improvement over the previous
>approach.  Given the time constraints and ambitions of that work, I think
>it was a solid, pragmatic first step.  I believe we are at a point to
>assess our needs, and determine a good next step that (hopefully) further
>improves the model.
>
>Thanks,
>-John
>
>On Aug 22, 2013, at 7:44 PM, Kelven Yang  wrote:
>
>> Spring is not meant to be used as a solution for run-time "plug-ins".
>> Darren is correct that Spring XML should be treated as code (ideal place
>> for it is the resource section inside the jar). Why we end up the way
>>now
>> is mainly for practical reason. Since most of our current pluggable
>> features are not yet designed to be fully run-time loadable, most of
>>them
>> have compile time linkage to other framework components that are solved
>>at
>> loading time by Spring.
>> 
>> Only after we have cleaned up all these tightly coupled loading time
>> bindings, can we have a much simpler plugin configuration. And this
>> run-time loadable framework does not necessary to be based on any
>>complex
>> ones (i.e., OSGi).
>> 
>> Kelven 
>> 
>> On 8/21/13 8:42 AM, "Darren Shepherd" 
>>wrote:
>> 
>>> I also agree with this.  Spring XML should always be treated as code
>>>not
>>> really configuration.  It's not good to have a sysadmin touch spring
>>> config and frankly it's just mean to force them to.
>>> 
>>> I would ideally like to see that registering a module is as simple as
>>> putting a jar in a directory.  If its in the directory it gets loaded.
>>> Then additionally you should have a way such that you can explicitly
>>>tell
>>> it not to load modules based on some configuration.  That way, if for
>>> some reason moving the jar is not possible, you can still disallow it.
>>> 
>>> So for example the directory based approach works well with rpm/deb's
>>>so
>>> "yum install mycoolplugin" will just place jar somewhere.  But say your
>>> troubleshooting or whatever, you don't really want to have to do "yum
>>> remove..." just to troubleshoot.  It would be nice to just edit some
>>>file
>>> and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>>> 
>>> Darren
>>> 
>>> On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam  wrote:
>>> 
 On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
> Leaky Abstraction:  Plugins are registered through a Spring
> configuration file.  In addition to being operator unfriendly (most
> sysadmins are not Spring experts nor do they want to be), we expose
> the core bootstrapping mechanism to operators.  Therefore, a
> misconfiguration could negatively impact the injection/configuration
> of internal management server components.  Essentially handing them
> a loaded shotgun pointed at our right foot.
 
 This has been my pet-peeve too and I was told you can write properties
 files
 above the spring contexts to make it simpler for operators to look at.
 
 Overall a great proposal and look forward to see more concrete steps
 that follow on the implementation details.
 
 -- 
 Prasanna.,
 
 
 Powered by BigRock.com
 
>> 
>

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, September 09, 2013 8:25 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> > -1 from me as well.
> >
> >
> > I know we're trying to hit timed releases, but I think it's very
> important to preserve key underlying functionality across releases. If a
> supported and documented feature is known to be broken, we need to
> address it...if we don't, it's going to cause lots of pain, and reflect
> badly on ACS as a project.
> >
> 
> Agreed.  The idea of "time-based" is all about feature development.
> Quality shouldn't be sacrificed.

[Animesh>] But we have to draw the line at some point otherwise we cannot 
maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this is 
our 4th VOTE round for 4.2. IMHO if something is in core orchestration layer, 
failed upgrade, cannot install and the likes and affects most users it should 
block a release. Other remaining issues should be picked up for subsequent 
maintenance release. May be we should discuss when should be the next 
maintenance release on 4.2, 4 weeks or 6 weeks rather than delaying 4.2.
 

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chiradeep Vittal]

Agree with Animesh.
>From a somewhat selfish perspective, I've gone through 2 rounds of
testing, not relishing the 3rd round.
There are literally hundreds of features in CloudStack. Another delay
could bring one more bug (existing perhaps, or newly introduced).
And another round of testing.

Draw the line somewhere.
--
Chiradeep


On 9/9/13 10:51 AM, "Animesh Chaturvedi" 
wrote:

>
>
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Monday, September 09, 2013 8:25 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> 
>> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
>> > -1 from me as well.
>> >
>> >
>> > I know we're trying to hit timed releases, but I think it's very
>> important to preserve key underlying functionality across releases. If a
>> supported and documented feature is known to be broken, we need to
>> address it...if we don't, it's going to cause lots of pain, and reflect
>> badly on ACS as a project.
>> >
>> 
>> Agreed.  The idea of "time-based" is all about feature development.
>> Quality shouldn't be sacrificed.
>
>[Animesh>] But we have to draw the line at some point otherwise we cannot
>maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this
>is our 4th VOTE round for 4.2. IMHO if something is in core orchestration
>layer, failed upgrade, cannot install and the likes and affects most
>users it should block a release. Other remaining issues should be picked
>up for subsequent maintenance release. May be we should discuss when
>should be the next maintenance release on 4.2, 4 weeks or 6 weeks rather
>than delaying 4.2.
> 

what do you do if your mshost mac changes?

[Darren Shepherd]

I just ran into this.  For whatever reason my box listed eth2 before 
eth0 for "ifconfig -a" so it looked like management server mac changed. 
 Then nothing worked...  I finally just hacked up the code to get it to 
work again.


So whats the real procedure if you do a chassis swap and your management 
server MAC addr changes?  How does cloudstack deal with that?


Darren

Question: Supported API calls in the Simulator

[David Grizzanti]

Hi All,

I was curious is there is a known set of API calls that will/should work
when CloudStack is in simulator mode?

Some background.  I'm running CS 4.2 (commit
8d043c0e4d4c9ace8628f542eacf19e5339e28e8 to be specific), on rhel 6.3
64-bit, built from source following simulator instructions here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python#Marvin-TestingwithPython-Building

Simulator appears to work fine, however, I'm starting encounter API calls
that fail.  Specifically attachVolume fails with a NullPointerException.
 Is this a bug within the simulator or a known limitation?

Log statement for attachVolume:
ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-19:job-30 = [
fca87e69-c688-428c-82ca-4a44f5b169ff ]) Unexpected exception while
executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
java.lang.NullPointerException
at
com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.getMaxDataVolumesLimit(HypervisorCapabilitiesDaoImpl.java:90)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.storage.VolumeManagerImpl.getMaxDataVolumesSupported(VolumeManagerImpl.java:1696)
at
com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1762)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)

Thanks!

-- 
David Grizzanti
Software Engineer
Sungard Availability Services

e: david.grizza...@sungard.com
w: 215.446.1431
c: 570.575.0315

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Daan Hoogland]

Animesh,

Without wanting to pass judgement on the quality of those tests or the
accuracy with which they were performed, there is now a mismatch
between what passed those tests and what people expect to work in the
current release. I assume that the tests where performed at an
acceptable level of expertise and I expect they were programmed at
such a level. This would leave only the coverage as a cause of our
present problem.

To get back to the subject of the thread; If the bugs are in new
features that is completely acceptable to me. If the bug are newly
discovered in old features as well. If however new bugs are introduced
to old features that people are using anywhere, this cuts them of from
upgrading with the rest of us. I would say no men gets left behind. If
need be new features need to be cut out but better is fix everything
that is introduced in this release.

€0,02
Daan

On Mon, Sep 9, 2013 at 8:31 PM, Animesh Chaturvedi
 wrote:
>
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Monday, September 09, 2013 11:10 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>>
>> We just need to have basic automated testing of every core supported
>> platform.  With 4.1 we released a product that didn't even work on
>> Ubuntu KVM, nobody tested it.  As long as we rely on devs to
>> individually test things at their leisure, we will always end up with 3-
>> 4 round release votes. An RC should pass a test suite first, and that
>> test suite should do a basic test for every item we claim support for,
>> BEFORE it goes up for a vote.
>
> [Animesh>] It did may be you missed the test results from Prasanna for this 
> VOTE.
>
>
>> On Sep 9, 2013 12:02 PM, "Chiradeep Vittal"
>> 
>> wrote:
>>
>> > Agree with Animesh.
>> > From a somewhat selfish perspective, I've gone through 2 rounds of
>> > testing, not relishing the 3rd round.
>> > There are literally hundreds of features in CloudStack. Another delay
>> > could bring one more bug (existing perhaps, or newly introduced).
>> > And another round of testing.
>> >
>> > Draw the line somewhere.
>> > --
>> > Chiradeep
>> >
>> >
>> > On 9/9/13 10:51 AM, "Animesh Chaturvedi"
>> > 
>> > wrote:
>> >
>> > >
>> > >
>> > >> -Original Message-
>> > >> From: Chip Childers [mailto:chip.child...@sungard.com]
>> > >> Sent: Monday, September 09, 2013 8:25 AM
>> > >> To: dev@cloudstack.apache.org
>> > >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> > >>
>> > >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
>> > >> > -1 from me as well.
>> > >> >
>> > >> >
>> > >> > I know we're trying to hit timed releases, but I think it's very
>> > >> important to preserve key underlying functionality across releases.
>> > >> If a supported and documented feature is known to be broken, we
>> > >> need to address it...if we don't, it's going to cause lots of pain,
>> > >> and reflect badly on ACS as a project.
>> > >> >
>> > >>
>> > >> Agreed.  The idea of "time-based" is all about feature development.
>> > >> Quality shouldn't be sacrificed.
>> > >
>> > >[Animesh>] But we have to draw the line at some point otherwise we
>> > >cannot maintain a 4 month cadence. 4.3 code freeze is in just 6-7
>> > >weeks and this is our 4th VOTE round for 4.2. IMHO if something is in
>> > >core orchestration layer, failed upgrade, cannot install and the
>> > >likes and affects most users it should block a release. Other
>> > >remaining issues should be picked up for subsequent maintenance
>> > >release. May be we should discuss when should be the next maintenance
>> > >release on 4.2, 4 weeks or 6 weeks rather than delaying 4.2.
>> > >
>> >
>> >

Re: Configuration variable changes...

[Daan Hoogland]

Alex,

I looked up the constructors and figured it out. next question is
about two of them:

public ConfigKey(Class type, String name, String category,
String defaultValue, String description, boolean isDynamic);
and
public ConfigKey(String category, Class type, String name,
String defaultValue, String description, boolean isDynamic);

should one of them be removed?

makes more sense to add a
public ConfigKey(Class type, String name, String category,
String defaultValue, String description, boolean isDynamic, T
multiplier);
that uses global scope.



On Mon, Sep 9, 2013 at 7:48 PM, Daan Hoogland  wrote:
> Looks great Alex,
>
> One question; Adding a scope or a multiplier is featured on the wiki
> but not specified. Can you add a pointer to it?
>
> Very nice indeed,
> Daan
>
> On Mon, Sep 9, 2013 at 7:20 PM, Alex Huang  wrote:
>> As part of the work to pull apart orchestration from self service, I made 
>> some changes to how configuration parameters work.  The problem with the 
>> current system are as follows:
>>
>> - configuration variables are all stored as enums in Config.java which means 
>> plugins have to modify a single file.  We established that to be a bad 
>> pattern in some earlier thread.
>> - No way to tell during upgrades whether a config variable has become 
>> useless or if the defaults have changed.
>> - No way to consistently have variables be dynamically updated.
>> - No way to consistently migrate a global variable to a scoped variable.
>> - No way to use more than one type of storage (db) to store config variables.
>> - Some of the code are still using text strings to retrieve configuration.
>> - No way to consistently validate variables.  (although this is not done yet 
>> but I described how it can be done in this new framework.)
>>
>> The changes are detailed on wiki [1].  There's a detail list of todo items 
>> in ConfigDepotImpl.java if you're interested in picking up any of the work.  
>> The old way still works but I recommend we move all new way for new config 
>> parameters.
>>
>> If everyone reviewed it all and like how it works then we can remove the old 
>> way of how it all works.
>>
>> --Alex
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration

Re: Configuration variable changes...

[Darren Shepherd]

On 09/09/2013 10:20 AM, Alex Huang wrote:

As part of the work to pull apart orchestration from self service, I made some 
changes to how configuration parameters work.  The problem with the current 
system are as follows:

- configuration variables are all stored as enums in Config.java which means 
plugins have to modify a single file.  We established that to be a bad pattern 
in some earlier thread.
- No way to tell during upgrades whether a config variable has become useless 
or if the defaults have changed.
- No way to consistently have variables be dynamically updated.
- No way to consistently migrate a global variable to a scoped variable.
- No way to use more than one type of storage (db) to store config variables.
- Some of the code are still using text strings to retrieve configuration.
- No way to consistently validate variables.  (although this is not done yet 
but I described how it can be done in this new framework.)

The changes are detailed on wiki [1].  There's a detail list of todo items in 
ConfigDepotImpl.java if you're interested in picking up any of the work.  The 
old way still works but I recommend we move all new way for new config 
parameters.

If everyone reviewed it all and like how it works then we can remove the old 
way of how it all works.

--Alex
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration



Can the generic API be

 ConfigKey get(String paramName, Class type);

Just to be a little easier to use.  I know the method is discouraged, 
but I do so some places it would be useful.  Besides that I like it. 
The contract is simple enough that the implementation can become quite 
flexible.


Scoped values seems a little strange though.  Why do you define the 
scope in the key?  Why wouldn't you pass the scope when you call 
valueIn?  Its seems a bit odd.  Because as the caller, you need to know 
what the Long is (is it a zone id, pool id, etc.).  So it seems more 
natural to pass valueIn(Scope.Zone, 42) because it is very explicit to 
the caller.  Also, why can't I have a key that is scoped at a different 
level depending on the calling context.


Darren

RE: Configuration variable changes...

[Alex Huang]

Daan,

Yeah... I would have preferred to use the first constructor only just because 
it makes more sense.  The problem is the second constructor saved me a lot of 
typing when I convert from the enums in Config.java to using this class.  So I 
kept both in there.  I think as long as it's no ambiguous, it should be okay.  
If we want to make sure, we probably should remove the first constructor.  The 
number of things I have to type for the first one was just prohibitive.  :P

As for the multiplier, I figure its usage is probably too small to deserve 
another constructor.  If there's a need for it, please go ahead and add another 
constructor.  

--Alex

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, September 9, 2013 12:01 PM
> To: dev
> Subject: Re: Configuration variable changes...
> 
> Alex,
> 
> I looked up the constructors and figured it out. next question is about two of
> them:
> 
> public ConfigKey(Class type, String name, String category, String
> defaultValue, String description, boolean isDynamic); and
> public ConfigKey(String category, Class type, String name, String
> defaultValue, String description, boolean isDynamic);
> 
> should one of them be removed?
> 
> makes more sense to add a
> public ConfigKey(Class type, String name, String category, String
> defaultValue, String description, boolean isDynamic, T multiplier); that uses
> global scope.
> 
> 
> 
> On Mon, Sep 9, 2013 at 7:48 PM, Daan Hoogland 
> wrote:
> > Looks great Alex,
> >
> > One question; Adding a scope or a multiplier is featured on the wiki
> > but not specified. Can you add a pointer to it?
> >
> > Very nice indeed,
> > Daan
> >
> > On Mon, Sep 9, 2013 at 7:20 PM, Alex Huang 
> wrote:
> >> As part of the work to pull apart orchestration from self service, I made
> some changes to how configuration parameters work.  The problem with the
> current system are as follows:
> >>
> >> - configuration variables are all stored as enums in Config.java which
> means plugins have to modify a single file.  We established that to be a bad
> pattern in some earlier thread.
> >> - No way to tell during upgrades whether a config variable has become
> useless or if the defaults have changed.
> >> - No way to consistently have variables be dynamically updated.
> >> - No way to consistently migrate a global variable to a scoped variable.
> >> - No way to use more than one type of storage (db) to store config
> variables.
> >> - Some of the code are still using text strings to retrieve configuration.
> >> - No way to consistently validate variables.  (although this is not
> >> done yet but I described how it can be done in this new framework.)
> >>
> >> The changes are detailed on wiki [1].  There's a detail list of todo items 
> >> in
> ConfigDepotImpl.java if you're interested in picking up any of the work.  The
> old way still works but I recommend we move all new way for new config
> parameters.
> >>
> >> If everyone reviewed it all and like how it works then we can remove the
> old way of how it all works.
> >>
> >> --Alex
> >> [1]
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

I did see those tests, but they were this round, and they don't cover any
of the things I mentioned.
On Sep 9, 2013 12:31 PM, "Animesh Chaturvedi" 
wrote:

>
>
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Monday, September 09, 2013 11:10 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >
> > We just need to have basic automated testing of every core supported
> > platform.  With 4.1 we released a product that didn't even work on
> > Ubuntu KVM, nobody tested it.  As long as we rely on devs to
> > individually test things at their leisure, we will always end up with 3-
> > 4 round release votes. An RC should pass a test suite first, and that
> > test suite should do a basic test for every item we claim support for,
> > BEFORE it goes up for a vote.
>
> [Animesh>] It did may be you missed the test results from Prasanna for
> this VOTE.
>
>
> > On Sep 9, 2013 12:02 PM, "Chiradeep Vittal"
> > 
> > wrote:
> >
> > > Agree with Animesh.
> > > From a somewhat selfish perspective, I've gone through 2 rounds of
> > > testing, not relishing the 3rd round.
> > > There are literally hundreds of features in CloudStack. Another delay
> > > could bring one more bug (existing perhaps, or newly introduced).
> > > And another round of testing.
> > >
> > > Draw the line somewhere.
> > > --
> > > Chiradeep
> > >
> > >
> > > On 9/9/13 10:51 AM, "Animesh Chaturvedi"
> > > 
> > > wrote:
> > >
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Chip Childers [mailto:chip.child...@sungard.com]
> > > >> Sent: Monday, September 09, 2013 8:25 AM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> > > >>
> > > >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> > > >> > -1 from me as well.
> > > >> >
> > > >> >
> > > >> > I know we're trying to hit timed releases, but I think it's very
> > > >> important to preserve key underlying functionality across releases.
> > > >> If a supported and documented feature is known to be broken, we
> > > >> need to address it...if we don't, it's going to cause lots of pain,
> > > >> and reflect badly on ACS as a project.
> > > >> >
> > > >>
> > > >> Agreed.  The idea of "time-based" is all about feature development.
> > > >> Quality shouldn't be sacrificed.
> > > >
> > > >[Animesh>] But we have to draw the line at some point otherwise we
> > > >cannot maintain a 4 month cadence. 4.3 code freeze is in just 6-7
> > > >weeks and this is our 4th VOTE round for 4.2. IMHO if something is in
> > > >core orchestration layer, failed upgrade, cannot install and the
> > > >likes and affects most users it should block a release. Other
> > > >remaining issues should be picked up for subsequent maintenance
> > > >release. May be we should discuss when should be the next maintenance
> > > >release on 4.2, 4 weeks or 6 weeks rather than delaying 4.2.
> > > >
> > >
> > >
>

Re: Configuration variable changes...

[Darren Shepherd]

On 09/09/2013 12:41 PM, Alex Huang wrote:
> The problem is the second constructor saved me a lot of typing when I 
convert from the enums in Config.java to using this class.


You could immediately deprecate the new method :)

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chiradeep Vittal]

I think that Animesh is trying to stress what is "key". If it hits 1% of
cloud operators is it key?


On 9/9/13 7:42 AM, "Simon Weller"  wrote:

>-1 from me as well.
>
>
>I know we're trying to hit timed releases, but I think it's very
>important to preserve key underlying functionality across releases. If a
>supported and documented feature is known to be broken, we need to
>address it...if we don't, it's going to cause lots of pain, and reflect
>badly on ACS as a project.
>
>- Original Message -
>
>From: "Chip Childers" 
>To: dev@cloudstack.apache.org
>Sent: Monday, September 9, 2013 9:24:23 AM
>Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>
>On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>> -1 ... sorry guys, especially with Simon chiming in.
>> 
>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>
>Agreed. 
>
>I'm -1, given simon's perspective as well. Since we have the fix, let's
>get it into the release.
>

RE: Question: Supported API calls in the Simulator

[Edison Su]

The current implementation of simulator has its own limitation: the simulator 
itself is a separate hypervisor type, thus a lot of condition checks against 
hypervisor type in mgt server will fail if simulator is used.
For example, currently, the zone wide primary storage only works for vmware and 
kvm, so if you add a zone wide primary storage into a zone which only has 
simulator as hypervisor, then you can't use that zone wide primary storage at 
all.
The simulator should be able to simulate any other hypervisors, maybe fixed in 
4.3?

> -Original Message-
> From: David Grizzanti [mailto:david.grizza...@sungard.com]
> Sent: Monday, September 09, 2013 12:04 PM
> To: dev@cloudstack.apache.org
> Subject: Question: Supported API calls in the Simulator
> 
> Hi All,
> 
> I was curious is there is a known set of API calls that will/should work when
> CloudStack is in simulator mode?
> 
> Some background.  I'm running CS 4.2 (commit
> 8d043c0e4d4c9ace8628f542eacf19e5339e28e8 to be specific), on rhel 6.3 64-
> bit, built from source following simulator instructions here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-
> +Testing+with+Python#Marvin-TestingwithPython-Building
> 
> Simulator appears to work fine, however, I'm starting encounter API calls
> that fail.  Specifically attachVolume fails with a NullPointerException.
>  Is this a bug within the simulator or a known limitation?
> 
> Log statement for attachVolume:
> ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-19:job-30 =
> [ fca87e69-c688-428c-82ca-4a44f5b169ff ]) Unexpected exception while
> executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> java.lang.NullPointerException
> at
> com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.getMaxDataVolum
> esLimit(HypervisorCapabilitiesDaoImpl.java:90)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercep
> torDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> com.cloud.storage.VolumeManagerImpl.getMaxDataVolumesSupported(Vol
> umeManagerImpl.java:1696)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManag
> erImpl.java:1762)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercep
> torDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execut
> e(AttachVolumeCmd.java:122)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:5
> 31)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
> a:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
> va:615)
> at java.lang.Thread.run(Thread.java:679)
> 
> Thanks!
> 
> --
> David Grizzanti
> Software Engineer
> Sungard Availability Services
> 
> e: david.grizza...@sungard.com
> w: 215.446.1431
> c: 570.575.0315

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 09, 2013 11:10 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> We just need to have basic automated testing of every core supported
> platform.  With 4.1 we released a product that didn't even work on
> Ubuntu KVM, nobody tested it.  As long as we rely on devs to
> individually test things at their leisure, we will always end up with 3-
> 4 round release votes. An RC should pass a test suite first, and that
> test suite should do a basic test for every item we claim support for,
> BEFORE it goes up for a vote.
 
[Animesh>] It did may be you missed the test results from Prasanna for this 
VOTE. 


> On Sep 9, 2013 12:02 PM, "Chiradeep Vittal"
> 
> wrote:
> 
> > Agree with Animesh.
> > From a somewhat selfish perspective, I've gone through 2 rounds of
> > testing, not relishing the 3rd round.
> > There are literally hundreds of features in CloudStack. Another delay
> > could bring one more bug (existing perhaps, or newly introduced).
> > And another round of testing.
> >
> > Draw the line somewhere.
> > --
> > Chiradeep
> >
> >
> > On 9/9/13 10:51 AM, "Animesh Chaturvedi"
> > 
> > wrote:
> >
> > >
> > >
> > >> -Original Message-
> > >> From: Chip Childers [mailto:chip.child...@sungard.com]
> > >> Sent: Monday, September 09, 2013 8:25 AM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> > >>
> > >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> > >> > -1 from me as well.
> > >> >
> > >> >
> > >> > I know we're trying to hit timed releases, but I think it's very
> > >> important to preserve key underlying functionality across releases.
> > >> If a supported and documented feature is known to be broken, we
> > >> need to address it...if we don't, it's going to cause lots of pain,
> > >> and reflect badly on ACS as a project.
> > >> >
> > >>
> > >> Agreed.  The idea of "time-based" is all about feature development.
> > >> Quality shouldn't be sacrificed.
> > >
> > >[Animesh>] But we have to draw the line at some point otherwise we
> > >cannot maintain a 4 month cadence. 4.3 code freeze is in just 6-7
> > >weeks and this is our 4th VOTE round for 4.2. IMHO if something is in
> > >core orchestration layer, failed upgrade, cannot install and the
> > >likes and affects most users it should block a release. Other
> > >remaining issues should be picked up for subsequent maintenance
> > >release. May be we should discuss when should be the next maintenance
> > >release on 4.2, 4 weeks or 6 weeks rather than delaying 4.2.
> > >
> >
> >

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, September 09, 2013 11:50 AM
> To: dev
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> Animesh,
> 
> Without wanting to pass judgement on the quality of those tests or the
> accuracy with which they were performed, there is now a mismatch between
> what passed those tests and what people expect to work in the current
> release. I assume that the tests where performed at an acceptable level
> of expertise and I expect they were programmed at such a level. This
> would leave only the coverage as a cause of our present problem.
> 
> To get back to the subject of the thread; If the bugs are in new
> features that is completely acceptable to me. If the bug are newly
> discovered in old features as well. If however new bugs are introduced
> to old features that people are using anywhere, this cuts them of from
> upgrading with the rest of us. I would say no men gets left behind. If
> need be new features need to be cut out but better is fix everything
> that is introduced in this release.
> 
> €0,02
> Daan
[Animesh>]Daan I would also prefer to fix as many issues as possible but 
suggesting a pragmatic approach where we also consider maintenance release. I 
have no problem cutting another RC, but the feedback is slowly trickling in. 
The issues in discussion also appeared in 4th VOTE not during the prior VOTEs.

> 
> On Mon, Sep 9, 2013 at 8:31 PM, Animesh Chaturvedi
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >> Sent: Monday, September 09, 2013 11:10 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >>
> >> We just need to have basic automated testing of every core supported
> >> platform.  With 4.1 we released a product that didn't even work on
> >> Ubuntu KVM, nobody tested it.  As long as we rely on devs to
> >> individually test things at their leisure, we will always end up with
> >> 3-
> >> 4 round release votes. An RC should pass a test suite first, and that
> >> test suite should do a basic test for every item we claim support
> >> for, BEFORE it goes up for a vote.
> >
> > [Animesh>] It did may be you missed the test results from Prasanna for
> this VOTE.
> >
> >
> >> On Sep 9, 2013 12:02 PM, "Chiradeep Vittal"
> >> 
> >> wrote:
> >>
> >> > Agree with Animesh.
> >> > From a somewhat selfish perspective, I've gone through 2 rounds of
> >> > testing, not relishing the 3rd round.
> >> > There are literally hundreds of features in CloudStack. Another
> >> > delay could bring one more bug (existing perhaps, or newly
> introduced).
> >> > And another round of testing.
> >> >
> >> > Draw the line somewhere.
> >> > --
> >> > Chiradeep
> >> >
> >> >
> >> > On 9/9/13 10:51 AM, "Animesh Chaturvedi"
> >> > 
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > >> -Original Message-
> >> > >> From: Chip Childers [mailto:chip.child...@sungard.com]
> >> > >> Sent: Monday, September 09, 2013 8:25 AM
> >> > >> To: dev@cloudstack.apache.org
> >> > >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >> > >>
> >> > >> On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote:
> >> > >> > -1 from me as well.
> >> > >> >
> >> > >> >
> >> > >> > I know we're trying to hit timed releases, but I think it's
> >> > >> > very
> >> > >> important to preserve key underlying functionality across
> releases.
> >> > >> If a supported and documented feature is known to be broken, we
> >> > >> need to address it...if we don't, it's going to cause lots of
> >> > >> pain, and reflect badly on ACS as a project.
> >> > >> >
> >> > >>
> >> > >> Agreed.  The idea of "time-based" is all about feature
> development.
> >> > >> Quality shouldn't be sacrificed.
> >> > >
> >> > >[Animesh>] But we have to draw the line at some point otherwise we
> >> > >cannot maintain a 4 month cadence. 4.3 code freeze is in just 6-7
> >> > >weeks and this is our 4th VOTE round for 4.2. IMHO if something is
> >> > >in core orchestration layer, failed upgrade, cannot install and
> >> > >the likes and affects most users it should block a release. Other
> >> > >remaining issues should be picked up for subsequent maintenance
> >> > >release. May be we should discuss when should be the next
> >> > >maintenance release on 4.2, 4 weeks or 6 weeks rather than
> delaying 4.2.
> >> > >
> >> >
> >> >

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Mike Tutkowski]

Do we have any statistics that say how many of our customers are using
feature x, feature y, etc.?

If not, I would say if we know about a feature that has regressed to the
point of breakage in 4.2 that it should be fixed before releasing (or at
the very least well documented, so - if it is impactful to someone - they
do not upgrade until it has been fixed).


On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> I think that Animesh is trying to stress what is "key". If it hits 1% of
> cloud operators is it key?
>
>
> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>
> >-1 from me as well.
> >
> >
> >I know we're trying to hit timed releases, but I think it's very
> >important to preserve key underlying functionality across releases. If a
> >supported and documented feature is known to be broken, we need to
> >address it...if we don't, it's going to cause lots of pain, and reflect
> >badly on ACS as a project.
> >
> >- Original Message -
> >
> >From: "Chip Childers" 
> >To: dev@cloudstack.apache.org
> >Sent: Monday, September 9, 2013 9:24:23 AM
> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >
> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> >> -1 ... sorry guys, especially with Simon chiming in.
> >>
> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
> >
> >Agreed.
> >
> >I'm -1, given simon's perspective as well. Since we have the fix, let's
> >get it into the release.
> >
>
>


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

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, September 09, 2013 1:46 PM
> To: dev
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> I think we are hitting a well documented feature of open source here,
> Mike. If someone is reporting it, someone is testing it. if someone is
> testing it someone is using it. Meaning the reported issues are being
> used. If it is by one or by one percent is not or should not be
> important.
> The fact they are slowing the release is because the testing is slow and
> hardly automated. Those that are automated are no issue.
> 
> @Animesh: you are giving an argument for releasing release candidates.
> We have discussed the cons of that extensively. The fact that 4.2 is so
> loaded with new features is due to the slow testing. I see your point
> about new issues, but these are due to 'only having 72 hours'
[Animesh>] I did extend the fourth VOTE which was expected to close on Friday. 
I also deliberately did not cancel out the third round sooner and start a new 
VOTE because I also wanted more people to try out the RC even though I had to 
pull in few fixes. 
> per vote round for things that are not automatically tested. Maybe you
> are right and we should leave some behind to save the whole.
[Animesh>] That's my reasoning, the current issue we already have a fix so easy 
to spin another RC but that may not just be the end. IMO as we put in the RC 
date for a release we should also put in a GA date that we should strive to 
achieve as community.
> 
> 
> 
> On Mon, Sep 9, 2013 at 10:24 PM, Mike Tutkowski
>  wrote:
> > Do we have any statistics that say how many of our customers are using
> > feature x, feature y, etc.?
> >
> > If not, I would say if we know about a feature that has regressed to
> > the point of breakage in 4.2 that it should be fixed before releasing
> > (or at the very least well documented, so - if it is impactful to
> > someone - they do not upgrade until it has been fixed).
> >
> >
> > On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> > chiradeep.vit...@citrix.com> wrote:
> >
> >> I think that Animesh is trying to stress what is "key". If it hits 1%
> >> of cloud operators is it key?
> >>
> >>
> >> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
> >>
> >> >-1 from me as well.
> >> >
> >> >
> >> >I know we're trying to hit timed releases, but I think it's very
> >> >important to preserve key underlying functionality across releases.
> >> >If a supported and documented feature is known to be broken, we need
> >> >to address it...if we don't, it's going to cause lots of pain, and
> >> >reflect badly on ACS as a project.
> >> >
> >> >- Original Message -
> >> >
> >> >From: "Chip Childers" 
> >> >To: dev@cloudstack.apache.org
> >> >Sent: Monday, September 9, 2013 9:24:23 AM
> >> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >> >
> >> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> >> >> -1 ... sorry guys, especially with Simon chiming in.
> >> >>
> >> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-
> picked.
> >> >
> >> >Agreed.
> >> >
> >> >I'm -1, given simon's perspective as well. Since we have the fix,
> >> >let's get it into the release.
> >> >
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

There was one other thing I saw come through regarding KVM bridges,
that should probably be added as well, but I haven't looked at it
extensively, maybe someone else can confirm.

On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen  wrote:
> Maybe before we get to carried away talking about future releases and more 
> automated testing (which is great and many of us have advocating for and 
> Prasanna has done outstanding working on BVT, jenkins and the test matrix), 
> we need to focus on how to get 4.2 out.
>
> Marcus has a binding -1, so that means the vote fails and we need another RC 
> (unless someone challenges Marcus's veto and he changes his mind).
>
> So what needs to be in the RC (aside from the cherry pick mentioned by 
> Marcus).
> Are there more blockers ?
> Do we need to invest in more testing before cutting that new RC or is it just 
> that one cherry pick ?
>
> If we agree on that and test before cutting, then maybe the vote can pass :)
>
> -sebastien
>
>
> On Sep 9, 2013, at 4:47 PM, Daan Hoogland  wrote:
>
>> Why can't we cover every use case, Marcus. We will need help from
>> users, but if they do help it will be easy to do so.
>>
>> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen  wrote:
>>> I was actually talking about separate things in relation to this
>>> thread and the other where I mentioned that I'd like to see a release
>>> focused on bugfixing and testing. With that, I'm advocating a test for
>>> every api call and focusing on broadening use case test coverage.
>>>
>>> Here, I'm simply talking about taking the support matrix and doing
>>> some vary basic testing. This can be a dozen or so tests, each
>>> platform we say we support needs to successfully deploy a zone and a
>>> vm on every storage type that is in the support matrix. I don't think
>>> this would include plugins (or maybe those are left to the developer
>>> of the third party plugin). For KVM, this is literally a marvin script
>>> away from being there, I don't think there's a ton of work. I have no
>>> idea what we have or can do with vmware, and I'm guessing Xen is
>>> largely covered already.
>>>
>>> We'll never be able to cover every use case, I may be able to deploy a
>>> zone with my KVM setup, but not someone else's special network layout.
>>> I'd just like to see sanity checks to say it works, at all, on the
>>> handful of 'supported' systems.
>>>
>>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>>>  wrote:
 Do we have any statistics that say how many of our customers are using
 feature x, feature y, etc.?

 If not, I would say if we know about a feature that has regressed to the
 point of breakage in 4.2 that it should be fixed before releasing (or at
 the very least well documented, so - if it is impactful to someone - they
 do not upgrade until it has been fixed).


 On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
 chiradeep.vit...@citrix.com> wrote:

> I think that Animesh is trying to stress what is "key". If it hits 1% of
> cloud operators is it key?
>
>
> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>
>> -1 from me as well.
>>
>>
>> I know we're trying to hit timed releases, but I think it's very
>> important to preserve key underlying functionality across releases. If a
>> supported and documented feature is known to be broken, we need to
>> address it...if we don't, it's going to cause lots of pain, and reflect
>> badly on ACS as a project.
>>
>> - Original Message -
>>
>> From: "Chip Childers" 
>> To: dev@cloudstack.apache.org
>> Sent: Monday, September 9, 2013 9:24:23 AM
>> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>>
>> On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>>> -1 ... sorry guys, especially with Simon chiming in.
>>>
>>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>>
>> Agreed.
>>
>> I'm -1, given simon's perspective as well. Since we have the fix, let's
>> get it into the release.
>>
>
>


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

Re: Review Request 13771: CLOUDSTACK-4346 replace URI getHost() and create(String) calls

[ASF Subversion and Git Services]

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


Commit 25c8cee01a450ee924fe108cafe54b046485ab2b in branch refs/heads/master 
from Daan Hoogland
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25c8cee ]

CLOUDSTACK-4346 uses of parseInt and parseLong secured


- ASF Subversion and Git Services


On Aug. 31, 2013, 7:57 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13771/
> ---
> 
> (Updated Aug. 31, 2013, 7:57 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, Dave Cahill, Hugo Trippaers, 
> Wido den Hollander, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-4346
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> After global search and replace all calls to retrieve ids for networks from 
> URIs using getHost() should be gone. Creating URI should now all use 
> appropriate calls as well so maitaining the way uris are built can now be 
> done centrally.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
>  07ee12d 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  195cf40 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  a156ae6 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java
>  7038d7e 
>   plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java 
> 59ba001 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  5ab2216 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  ecdec1e 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/element/BigSwitchVnsElement.java
>  54623e9 
>   
> plugins/network-elements/cisco-vnmc/src/com/cloud/network/element/CiscoVnmcElement.java
>  3ae6a08 
>   
> plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
>  1733712 
>   
> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>  3d3d797 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java
>  c7d0884 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
>  ff238ed 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
>  36a807f 
>   server/src/com/cloud/api/ApiResponseHelper.java c771431 
>   server/src/com/cloud/network/ExternalDeviceUsageManagerImpl.java e91dcfa 
>   server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java a934024 
>   server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
> c14d5c7 
>   server/src/com/cloud/network/NetworkManagerImpl.java 00103e3 
>   server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java 5b87d54 
>   server/src/com/cloud/network/guru/ExternalGuestNetworkGuru.java 00598dd 
>   server/src/com/cloud/network/guru/GuestNetworkGuru.java b0da42f 
>   server/src/com/cloud/network/guru/PrivateNetworkGuru.java 6521cf4 
>   server/src/com/cloud/network/guru/PublicNetworkGuru.java d109468 
>   
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>  ee0d058 
>   utils/src/com/cloud/utils/net/NetUtils.java 05b485b 
> 
> Diff: https://reviews.apache.org/r/13771/diff/
> 
> 
> Testing
> ---
> 
> tested with old style uris in regular networks and vpc based networks as well 
> as in nicira based networks
> test build in nonoss but not all code has probably been touched yet. or at 
> least I am unsure of that.
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Question about hypervisor snapshots

[Kelven Yang]

On 9/8/13 4:21 PM, "Mike Tutkowski"  wrote:

>Hi,
>
>I have a couple questions regarding how hypervisor snapshots work in
>XenServer and ESX through CloudStack.
>
>For XenServer, let's say I have a root disk on SR1 and a data disk on SR2.
>
>1) If we take a hypervisor snapshot, do we snapshot both disks by default?

For VMware, yes.

>
>2) Assuming we do, is the snapshot always stored with the disk it is a
>snapshot of on the same SR?

Yes, snapshot is stored along with its base disk in the same datastore

>
>3) Assuming they are, will the entire snapshot process fail if there is
>insufficient space on any SR?

If anyone fails, it will fail the snapshot as whole.

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

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Sebastien Goasguen]

On Sep 9, 2013, at 5:08 PM, Animesh Chaturvedi  
wrote:

> 
>> 
>> On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen 
>> wrote:
>>> Maybe before we get to carried away talking about future releases and
>> more automated testing (which is great and many of us have advocating
>> for and Prasanna has done outstanding working on BVT, jenkins and the
>> test matrix), we need to focus on how to get 4.2 out.
>>> 
>>> Marcus has a binding -1, so that means the vote fails and we need
>> another RC (unless someone challenges Marcus's veto and he changes his
>> mind).
>>> 
> [Animesh>] Sebastien the VOTE is by majority not a VETO. 

Ah, thought it was consensus.

should be consensus for releases imho.

> 
>>> So what needs to be in the RC (aside from the cherry pick mentioned by
>> Marcus).
>>> Are there more blockers ?
>>> Do we need to invest in more testing before cutting that new RC or is
>> it just that one cherry pick ?
>>> 
>>> If we agree on that and test before cutting, then maybe the vote can
>>> pass :)
>>> 
>>> -sebastien
>>> 
>>> 
>>> On Sep 9, 2013, at 4:47 PM, Daan Hoogland 
>> wrote:
>>> 
 Why can't we cover every use case, Marcus. We will need help from
 users, but if they do help it will be easy to do so.
 
 On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen
>>  wrote:
> I was actually talking about separate things in relation to this
> thread and the other where I mentioned that I'd like to see a
> release focused on bugfixing and testing. With that, I'm advocating
> a test for every api call and focusing on broadening use case test
>> coverage.
> 
> Here, I'm simply talking about taking the support matrix and doing
> some vary basic testing. This can be a dozen or so tests, each
> platform we say we support needs to successfully deploy a zone and a
> vm on every storage type that is in the support matrix. I don't
> think this would include plugins (or maybe those are left to the
> developer of the third party plugin). For KVM, this is literally a
> marvin script away from being there, I don't think there's a ton of
> work. I have no idea what we have or can do with vmware, and I'm
> guessing Xen is largely covered already.
> 
> We'll never be able to cover every use case, I may be able to deploy
> a zone with my KVM setup, but not someone else's special network
>> layout.
> I'd just like to see sanity checks to say it works, at all, on the
> handful of 'supported' systems.
> 
> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>  wrote:
>> Do we have any statistics that say how many of our customers are
>> using feature x, feature y, etc.?
>> 
>> If not, I would say if we know about a feature that has regressed
>> to the point of breakage in 4.2 that it should be fixed before
>> releasing (or at the very least well documented, so - if it is
>> impactful to someone - they do not upgrade until it has been
>> fixed).
>> 
>> 
>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>> chiradeep.vit...@citrix.com> wrote:
>> 
>>> I think that Animesh is trying to stress what is "key". If it hits
>>> 1% of cloud operators is it key?
>>> 
>>> 
>>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>>> 
 -1 from me as well.
 
 
 I know we're trying to hit timed releases, but I think it's very
 important to preserve key underlying functionality across
 releases. If a supported and documented feature is known to be
 broken, we need to address it...if we don't, it's going to cause
 lots of pain, and reflect badly on ACS as a project.
 
 - Original Message -
 
 From: "Chip Childers" 
 To: dev@cloudstack.apache.org
 Sent: Monday, September 9, 2013 9:24:23 AM
 Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
 
 On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> -1 ... sorry guys, especially with Simon chiming in.
> 
> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-
>> picked.
 
 Agreed.
 
 I'm -1, given simon's perspective as well. Since we have the fix,
 let's get it into the release.
 
>>> 
>>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*
>>> 

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> 
> On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen 
> wrote:
> > Maybe before we get to carried away talking about future releases and
> more automated testing (which is great and many of us have advocating
> for and Prasanna has done outstanding working on BVT, jenkins and the
> test matrix), we need to focus on how to get 4.2 out.
> >
> > Marcus has a binding -1, so that means the vote fails and we need
> another RC (unless someone challenges Marcus's veto and he changes his
> mind).
> >
[Animesh>] Sebastien the VOTE is by majority not a VETO. 

> > So what needs to be in the RC (aside from the cherry pick mentioned by
> Marcus).
> > Are there more blockers ?
> > Do we need to invest in more testing before cutting that new RC or is
> it just that one cherry pick ?
> >
> > If we agree on that and test before cutting, then maybe the vote can
> > pass :)
> >
> > -sebastien
> >
> >
> > On Sep 9, 2013, at 4:47 PM, Daan Hoogland 
> wrote:
> >
> >> Why can't we cover every use case, Marcus. We will need help from
> >> users, but if they do help it will be easy to do so.
> >>
> >> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen
>  wrote:
> >>> I was actually talking about separate things in relation to this
> >>> thread and the other where I mentioned that I'd like to see a
> >>> release focused on bugfixing and testing. With that, I'm advocating
> >>> a test for every api call and focusing on broadening use case test
> coverage.
> >>>
> >>> Here, I'm simply talking about taking the support matrix and doing
> >>> some vary basic testing. This can be a dozen or so tests, each
> >>> platform we say we support needs to successfully deploy a zone and a
> >>> vm on every storage type that is in the support matrix. I don't
> >>> think this would include plugins (or maybe those are left to the
> >>> developer of the third party plugin). For KVM, this is literally a
> >>> marvin script away from being there, I don't think there's a ton of
> >>> work. I have no idea what we have or can do with vmware, and I'm
> >>> guessing Xen is largely covered already.
> >>>
> >>> We'll never be able to cover every use case, I may be able to deploy
> >>> a zone with my KVM setup, but not someone else's special network
> layout.
> >>> I'd just like to see sanity checks to say it works, at all, on the
> >>> handful of 'supported' systems.
> >>>
> >>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
> >>>  wrote:
>  Do we have any statistics that say how many of our customers are
>  using feature x, feature y, etc.?
> 
>  If not, I would say if we know about a feature that has regressed
>  to the point of breakage in 4.2 that it should be fixed before
>  releasing (or at the very least well documented, so - if it is
>  impactful to someone - they do not upgrade until it has been
> fixed).
> 
> 
>  On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>  chiradeep.vit...@citrix.com> wrote:
> 
> > I think that Animesh is trying to stress what is "key". If it hits
> > 1% of cloud operators is it key?
> >
> >
> > On 9/9/13 7:42 AM, "Simon Weller"  wrote:
> >
> >> -1 from me as well.
> >>
> >>
> >> I know we're trying to hit timed releases, but I think it's very
> >> important to preserve key underlying functionality across
> >> releases. If a supported and documented feature is known to be
> >> broken, we need to address it...if we don't, it's going to cause
> >> lots of pain, and reflect badly on ACS as a project.
> >>
> >> - Original Message -
> >>
> >> From: "Chip Childers" 
> >> To: dev@cloudstack.apache.org
> >> Sent: Monday, September 9, 2013 9:24:23 AM
> >> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >>
> >> On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> >>> -1 ... sorry guys, especially with Simon chiming in.
> >>>
> >>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-
> picked.
> >>
> >> Agreed.
> >>
> >> I'm -1, given simon's perspective as well. Since we have the fix,
> >> let's get it into the release.
> >>
> >
> >
> 
> 
>  --
>  *Mike Tutkowski*
>  *Senior CloudStack Developer, SolidFire Inc.*
>  e: mike.tutkow...@solidfire.com
>  o: 303.746.7302
>  Advancing the way the world uses the
>  cloud
>  *(tm)*
> >

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Daan Hoogland]

I think we are hitting a well documented feature of open source here,
Mike. If someone is reporting it, someone is testing it. if someone is
testing it someone is using it. Meaning the reported issues are being
used. If it is by one or by one percent is not or should not be
important.
The fact they are slowing the release is because the testing is slow
and hardly automated. Those that are automated are no issue.

@Animesh: you are giving an argument for releasing release candidates.
We have discussed the cons of that extensively. The fact that 4.2 is
so loaded with new features is due to the slow testing. I see your
point about new issues, but these are due to 'only having 72 hours'
per vote round for things that are not automatically tested. Maybe you
are right and we should leave some behind to save the whole.



On Mon, Sep 9, 2013 at 10:24 PM, Mike Tutkowski
 wrote:
> Do we have any statistics that say how many of our customers are using
> feature x, feature y, etc.?
>
> If not, I would say if we know about a feature that has regressed to the
> point of breakage in 4.2 that it should be fixed before releasing (or at
> the very least well documented, so - if it is impactful to someone - they
> do not upgrade until it has been fixed).
>
>
> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
>
>> I think that Animesh is trying to stress what is "key". If it hits 1% of
>> cloud operators is it key?
>>
>>
>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>>
>> >-1 from me as well.
>> >
>> >
>> >I know we're trying to hit timed releases, but I think it's very
>> >important to preserve key underlying functionality across releases. If a
>> >supported and documented feature is known to be broken, we need to
>> >address it...if we don't, it's going to cause lots of pain, and reflect
>> >badly on ACS as a project.
>> >
>> >- Original Message -
>> >
>> >From: "Chip Childers" 
>> >To: dev@cloudstack.apache.org
>> >Sent: Monday, September 9, 2013 9:24:23 AM
>> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> >
>> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>> >> -1 ... sorry guys, especially with Simon chiming in.
>> >>
>> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>> >
>> >Agreed.
>> >
>> >I'm -1, given simon's perspective as well. Since we have the fix, let's
>> >get it into the release.
>> >
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chiradeep Vittal]

Umm, it requires a majority of +1 binding votes to release. -1 is not an
automatic veto.

On 9/9/13 2:01 PM, "Sebastien Goasguen"  wrote:

>Maybe before we get to carried away talking about future releases and
>more automated testing (which is great and many of us have advocating for
>and Prasanna has done outstanding working on BVT, jenkins and the test
>matrix), we need to focus on how to get 4.2 out.
>
>Marcus has a binding -1, so that means the vote fails and we need another
>RC (unless someone challenges Marcus's veto and he changes his mind).
>
>So what needs to be in the RC (aside from the cherry pick mentioned by
>Marcus).
>Are there more blockers ?
>Do we need to invest in more testing before cutting that new RC or is it
>just that one cherry pick ?
>
>If we agree on that and test before cutting, then maybe the vote can pass
>:)
>
>-sebastien
>
>
>On Sep 9, 2013, at 4:47 PM, Daan Hoogland  wrote:
>
>> Why can't we cover every use case, Marcus. We will need help from
>> users, but if they do help it will be easy to do so.
>> 
>> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen 
>>wrote:
>>> I was actually talking about separate things in relation to this
>>> thread and the other where I mentioned that I'd like to see a release
>>> focused on bugfixing and testing. With that, I'm advocating a test for
>>> every api call and focusing on broadening use case test coverage.
>>> 
>>> Here, I'm simply talking about taking the support matrix and doing
>>> some vary basic testing. This can be a dozen or so tests, each
>>> platform we say we support needs to successfully deploy a zone and a
>>> vm on every storage type that is in the support matrix. I don't think
>>> this would include plugins (or maybe those are left to the developer
>>> of the third party plugin). For KVM, this is literally a marvin script
>>> away from being there, I don't think there's a ton of work. I have no
>>> idea what we have or can do with vmware, and I'm guessing Xen is
>>> largely covered already.
>>> 
>>> We'll never be able to cover every use case, I may be able to deploy a
>>> zone with my KVM setup, but not someone else's special network layout.
>>> I'd just like to see sanity checks to say it works, at all, on the
>>> handful of 'supported' systems.
>>> 
>>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>>>  wrote:
 Do we have any statistics that say how many of our customers are using
 feature x, feature y, etc.?
 
 If not, I would say if we know about a feature that has regressed to
the
 point of breakage in 4.2 that it should be fixed before releasing (or
at
 the very least well documented, so - if it is impactful to someone -
they
 do not upgrade until it has been fixed).
 
 
 On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
 chiradeep.vit...@citrix.com> wrote:
 
> I think that Animesh is trying to stress what is "key". If it hits
>1% of
> cloud operators is it key?
> 
> 
> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
> 
>> -1 from me as well.
>> 
>> 
>> I know we're trying to hit timed releases, but I think it's very
>> important to preserve key underlying functionality across releases.
>>If a
>> supported and documented feature is known to be broken, we need to
>> address it...if we don't, it's going to cause lots of pain, and
>>reflect
>> badly on ACS as a project.
>> 
>> - Original Message -
>> 
>> From: "Chip Childers" 
>> To: dev@cloudstack.apache.org
>> Sent: Monday, September 9, 2013 9:24:23 AM
>> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> 
>> On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>>> -1 ... sorry guys, especially with Simon chiming in.
>>> 
>>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be
>>>cherry-picked.
>> 
>> Agreed.
>> 
>> I'm -1, given simon's perspective as well. Since we have the fix,
>>let's
>> get it into the release.
>> 
> 
> 
 
 
 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the
 cloud
 **
>

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Monday, September 09, 2013 2:04 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> 
> 
> > -Original Message-
> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > Sent: Monday, September 09, 2013 1:46 PM
> > To: dev
> > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> >
> > I think we are hitting a well documented feature of open source here,
> > Mike. If someone is reporting it, someone is testing it. if someone is
> > testing it someone is using it. Meaning the reported issues are being
> > used. If it is by one or by one percent is not or should not be
> > important.
> > The fact they are slowing the release is because the testing is slow
> > and hardly automated. Those that are automated are no issue.
> >
> > @Animesh: you are giving an argument for releasing release candidates.
> > We have discussed the cons of that extensively. The fact that 4.2 is
> > so loaded with new features is due to the slow testing. I see your
> > point about new issues, but these are due to 'only having 72 hours'
> [Animesh>] I did extend the fourth VOTE which was expected to close on
> Friday. I also deliberately did not cancel out the third round sooner
> and start a new VOTE because I also wanted more people to try out the RC
> even though I had to pull in few fixes.
> > per vote round for things that are not automatically tested. Maybe you
> > are right and we should leave some behind to save the whole.
> [Animesh>] That's my reasoning, the current issue we already have a fix
> so easy to spin another RC but that may not just be the end. IMO as we
> put in the RC date for a release we should also put in a GA date that we
> should strive to achieve as community.
[Animesh>] We also need to consider all the users that have been waiting to 
leverage the new release.
> >
> >
> >
> > On Mon, Sep 9, 2013 at 10:24 PM, Mike Tutkowski
> >  wrote:
> > > Do we have any statistics that say how many of our customers are
> > > using feature x, feature y, etc.?
> > >
> > > If not, I would say if we know about a feature that has regressed to
> > > the point of breakage in 4.2 that it should be fixed before
> > > releasing (or at the very least well documented, so - if it is
> > > impactful to someone - they do not upgrade until it has been fixed).
> > >
> > >
> > > On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> > > chiradeep.vit...@citrix.com> wrote:
> > >
> > >> I think that Animesh is trying to stress what is "key". If it hits
> > >> 1% of cloud operators is it key?
> > >>
> > >>
> > >> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
> > >>
> > >> >-1 from me as well.
> > >> >
> > >> >
> > >> >I know we're trying to hit timed releases, but I think it's very
> > >> >important to preserve key underlying functionality across
> releases.
> > >> >If a supported and documented feature is known to be broken, we
> > >> >need to address it...if we don't, it's going to cause lots of
> > >> >pain, and reflect badly on ACS as a project.
> > >> >
> > >> >- Original Message -
> > >> >
> > >> >From: "Chip Childers" 
> > >> >To: dev@cloudstack.apache.org
> > >> >Sent: Monday, September 9, 2013 9:24:23 AM
> > >> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> > >> >
> > >> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
> > >> >> -1 ... sorry guys, especially with Simon chiming in.
> > >> >>
> > >> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-
> > picked.
> > >> >
> > >> >Agreed.
> > >> >
> > >> >I'm -1, given simon's perspective as well. Since we have the fix,
> > >> >let's get it into the release.
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > *Mike Tutkowski*
> > > *Senior CloudStack Developer, SolidFire Inc.*
> > > e: mike.tutkow...@solidfire.com
> > > o: 303.746.7302
> > > Advancing the way the world uses the
> > > cloud
> > > *(tm)*

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Daan Hoogland]

Why can't we cover every use case, Marcus. We will need help from
users, but if they do help it will be easy to do so.

On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen  wrote:
>  I was actually talking about separate things in relation to this
> thread and the other where I mentioned that I'd like to see a release
> focused on bugfixing and testing. With that, I'm advocating a test for
> every api call and focusing on broadening use case test coverage.
>
> Here, I'm simply talking about taking the support matrix and doing
> some vary basic testing. This can be a dozen or so tests, each
> platform we say we support needs to successfully deploy a zone and a
> vm on every storage type that is in the support matrix. I don't think
> this would include plugins (or maybe those are left to the developer
> of the third party plugin). For KVM, this is literally a marvin script
> away from being there, I don't think there's a ton of work. I have no
> idea what we have or can do with vmware, and I'm guessing Xen is
> largely covered already.
>
> We'll never be able to cover every use case, I may be able to deploy a
> zone with my KVM setup, but not someone else's special network layout.
> I'd just like to see sanity checks to say it works, at all, on the
> handful of 'supported' systems.
>
> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>  wrote:
>> Do we have any statistics that say how many of our customers are using
>> feature x, feature y, etc.?
>>
>> If not, I would say if we know about a feature that has regressed to the
>> point of breakage in 4.2 that it should be fixed before releasing (or at
>> the very least well documented, so - if it is impactful to someone - they
>> do not upgrade until it has been fixed).
>>
>>
>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>> chiradeep.vit...@citrix.com> wrote:
>>
>>> I think that Animesh is trying to stress what is "key". If it hits 1% of
>>> cloud operators is it key?
>>>
>>>
>>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>>>
>>> >-1 from me as well.
>>> >
>>> >
>>> >I know we're trying to hit timed releases, but I think it's very
>>> >important to preserve key underlying functionality across releases. If a
>>> >supported and documented feature is known to be broken, we need to
>>> >address it...if we don't, it's going to cause lots of pain, and reflect
>>> >badly on ACS as a project.
>>> >
>>> >- Original Message -
>>> >
>>> >From: "Chip Childers" 
>>> >To: dev@cloudstack.apache.org
>>> >Sent: Monday, September 9, 2013 9:24:23 AM
>>> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>>> >
>>> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>>> >> -1 ... sorry guys, especially with Simon chiming in.
>>> >>
>>> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>>> >
>>> >Agreed.
>>> >
>>> >I'm -1, given simon's perspective as well. Since we have the fix, let's
>>> >get it into the release.
>>> >
>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *™*

Re: what do you do if your mshost mac changes?

[Kelven Yang]

On 9/9/13 12:07 PM, "Darren Shepherd"  wrote:

>I just ran into this.  For whatever reason my box listed eth2 before
>eth0 for "ifconfig -a" so it looked like management server mac changed.
>  Then nothing worked...

It is supposed to work if you are sure a previous running MS java process
is killed and the IP associated is still valid for the setup. A mac change
will cause CloudStack to think there is another MS node is UP, however, it
will try to detect if there is any other node which is currently using the
MS IP, it may do self-fencing to shut itself down if a previous running MS
java process is still running there.

The only requirement for it to work is that, mac address can be changed,
but the associated IP should be valid to the setup

Kelven


>I finally just hacked up the code to get it to
>work again.
>
>So whats the real procedure if you do a chassis swap and your management
>server MAC addr changes?  How does cloudstack deal with that?
>
>Darren

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

 I was actually talking about separate things in relation to this
thread and the other where I mentioned that I'd like to see a release
focused on bugfixing and testing. With that, I'm advocating a test for
every api call and focusing on broadening use case test coverage.

Here, I'm simply talking about taking the support matrix and doing
some vary basic testing. This can be a dozen or so tests, each
platform we say we support needs to successfully deploy a zone and a
vm on every storage type that is in the support matrix. I don't think
this would include plugins (or maybe those are left to the developer
of the third party plugin). For KVM, this is literally a marvin script
away from being there, I don't think there's a ton of work. I have no
idea what we have or can do with vmware, and I'm guessing Xen is
largely covered already.

We'll never be able to cover every use case, I may be able to deploy a
zone with my KVM setup, but not someone else's special network layout.
I'd just like to see sanity checks to say it works, at all, on the
handful of 'supported' systems.

On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
 wrote:
> Do we have any statistics that say how many of our customers are using
> feature x, feature y, etc.?
>
> If not, I would say if we know about a feature that has regressed to the
> point of breakage in 4.2 that it should be fixed before releasing (or at
> the very least well documented, so - if it is impactful to someone - they
> do not upgrade until it has been fixed).
>
>
> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
>
>> I think that Animesh is trying to stress what is "key". If it hits 1% of
>> cloud operators is it key?
>>
>>
>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>>
>> >-1 from me as well.
>> >
>> >
>> >I know we're trying to hit timed releases, but I think it's very
>> >important to preserve key underlying functionality across releases. If a
>> >supported and documented feature is known to be broken, we need to
>> >address it...if we don't, it's going to cause lots of pain, and reflect
>> >badly on ACS as a project.
>> >
>> >- Original Message -
>> >
>> >From: "Chip Childers" 
>> >To: dev@cloudstack.apache.org
>> >Sent: Monday, September 9, 2013 9:24:23 AM
>> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>> >
>> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>> >> -1 ... sorry guys, especially with Simon chiming in.
>> >>
>> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>> >
>> >Agreed.
>> >
>> >I'm -1, given simon's perspective as well. Since we have the fix, let's
>> >get it into the release.
>> >
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Sebastien Goasguen]

Maybe before we get to carried away talking about future releases and more 
automated testing (which is great and many of us have advocating for and 
Prasanna has done outstanding working on BVT, jenkins and the test matrix), we 
need to focus on how to get 4.2 out.

Marcus has a binding -1, so that means the vote fails and we need another RC 
(unless someone challenges Marcus's veto and he changes his mind).

So what needs to be in the RC (aside from the cherry pick mentioned by Marcus).
Are there more blockers ?
Do we need to invest in more testing before cutting that new RC or is it just 
that one cherry pick ?

If we agree on that and test before cutting, then maybe the vote can pass :)

-sebastien


On Sep 9, 2013, at 4:47 PM, Daan Hoogland  wrote:

> Why can't we cover every use case, Marcus. We will need help from
> users, but if they do help it will be easy to do so.
> 
> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen  wrote:
>> I was actually talking about separate things in relation to this
>> thread and the other where I mentioned that I'd like to see a release
>> focused on bugfixing and testing. With that, I'm advocating a test for
>> every api call and focusing on broadening use case test coverage.
>> 
>> Here, I'm simply talking about taking the support matrix and doing
>> some vary basic testing. This can be a dozen or so tests, each
>> platform we say we support needs to successfully deploy a zone and a
>> vm on every storage type that is in the support matrix. I don't think
>> this would include plugins (or maybe those are left to the developer
>> of the third party plugin). For KVM, this is literally a marvin script
>> away from being there, I don't think there's a ton of work. I have no
>> idea what we have or can do with vmware, and I'm guessing Xen is
>> largely covered already.
>> 
>> We'll never be able to cover every use case, I may be able to deploy a
>> zone with my KVM setup, but not someone else's special network layout.
>> I'd just like to see sanity checks to say it works, at all, on the
>> handful of 'supported' systems.
>> 
>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>>  wrote:
>>> Do we have any statistics that say how many of our customers are using
>>> feature x, feature y, etc.?
>>> 
>>> If not, I would say if we know about a feature that has regressed to the
>>> point of breakage in 4.2 that it should be fixed before releasing (or at
>>> the very least well documented, so - if it is impactful to someone - they
>>> do not upgrade until it has been fixed).
>>> 
>>> 
>>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>>> chiradeep.vit...@citrix.com> wrote:
>>> 
 I think that Animesh is trying to stress what is "key". If it hits 1% of
 cloud operators is it key?
 
 
 On 9/9/13 7:42 AM, "Simon Weller"  wrote:
 
> -1 from me as well.
> 
> 
> I know we're trying to hit timed releases, but I think it's very
> important to preserve key underlying functionality across releases. If a
> supported and documented feature is known to be broken, we need to
> address it...if we don't, it's going to cause lots of pain, and reflect
> badly on ACS as a project.
> 
> - Original Message -
> 
> From: "Chip Childers" 
> To: dev@cloudstack.apache.org
> Sent: Monday, September 9, 2013 9:24:23 AM
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
> 
> On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>> -1 ... sorry guys, especially with Simon chiming in.
>> 
>> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
> 
> Agreed.
> 
> I'm -1, given simon's perspective as well. Since we have the fix, let's
> get it into the release.
> 
 
 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud
>>> *™*

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

It's doable in theory, but the issue is that in reality nobody looks
at it until it's out the door. It's a similar issue with feature
branches, they get merged, and it's not until after the merge that
people say "hey, this breaks all sorts of stuff", because the devs
don't necessarily know all of the use cases, and the users are not
devs.

Even if it is doable, I think it's probably a bridge too far. The
reality is that devs don't really like to work on bugs as much as they
do new features, so I'd like to get there one step at a time, rather
than present something massive sounding that will just turn everyone
off completely.

On Mon, Sep 9, 2013 at 2:47 PM, Daan Hoogland  wrote:
> Why can't we cover every use case, Marcus. We will need help from
> users, but if they do help it will be easy to do so.
>
> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen  wrote:
>>  I was actually talking about separate things in relation to this
>> thread and the other where I mentioned that I'd like to see a release
>> focused on bugfixing and testing. With that, I'm advocating a test for
>> every api call and focusing on broadening use case test coverage.
>>
>> Here, I'm simply talking about taking the support matrix and doing
>> some vary basic testing. This can be a dozen or so tests, each
>> platform we say we support needs to successfully deploy a zone and a
>> vm on every storage type that is in the support matrix. I don't think
>> this would include plugins (or maybe those are left to the developer
>> of the third party plugin). For KVM, this is literally a marvin script
>> away from being there, I don't think there's a ton of work. I have no
>> idea what we have or can do with vmware, and I'm guessing Xen is
>> largely covered already.
>>
>> We'll never be able to cover every use case, I may be able to deploy a
>> zone with my KVM setup, but not someone else's special network layout.
>> I'd just like to see sanity checks to say it works, at all, on the
>> handful of 'supported' systems.
>>
>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>>  wrote:
>>> Do we have any statistics that say how many of our customers are using
>>> feature x, feature y, etc.?
>>>
>>> If not, I would say if we know about a feature that has regressed to the
>>> point of breakage in 4.2 that it should be fixed before releasing (or at
>>> the very least well documented, so - if it is impactful to someone - they
>>> do not upgrade until it has been fixed).
>>>
>>>
>>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>>> chiradeep.vit...@citrix.com> wrote:
>>>
 I think that Animesh is trying to stress what is "key". If it hits 1% of
 cloud operators is it key?


 On 9/9/13 7:42 AM, "Simon Weller"  wrote:

 >-1 from me as well.
 >
 >
 >I know we're trying to hit timed releases, but I think it's very
 >important to preserve key underlying functionality across releases. If a
 >supported and documented feature is known to be broken, we need to
 >address it...if we don't, it's going to cause lots of pain, and reflect
 >badly on ACS as a project.
 >
 >- Original Message -
 >
 >From: "Chip Childers" 
 >To: dev@cloudstack.apache.org
 >Sent: Monday, September 9, 2013 9:24:23 AM
 >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
 >
 >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
 >> -1 ... sorry guys, especially with Simon chiming in.
 >>
 >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
 >
 >Agreed.
 >
 >I'm -1, given simon's perspective as well. Since we have the fix, let's
 >get it into the release.
 >


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

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Mathias Mullins]

Technically I don't see any binding -1 vetoes being declared. Animesh is
correct on this. 

Just as a reminder on the terms of a release vote as per the by-laws
(http://cloudstack.apache.org/bylaws.html)

"3.4.4. Product Release
When a release of one of the project's products is ready, a vote is
required to accept the release as an official release of the project. Lazy
Majority of active PMC members is required for approval. Any active
committer or PMC member may call a vote. The vote must occur on the
project development mailing list."


but there is currently a PMC votes (cloudstack.apache.org/who.html):
Alex Huang (ahuang) - No Vote
Alex Karasulu (akarasulu)- No Vote
Brett Porter (brett)- No Vote
Chip Childers (chipchilders) -1 (Not declared Binding or Veto)
Chiradeep Vittal (chiradeep) +1
Disheng Su (edison)- No Vote
Matt Richard Hogstrom (hogstrom)- No Vote
Hugo Trippaers (hugo)- No Vote
John Burwell (jburwell)- No Vote
Jim Jagielski (jim)- No Vote
John Kinsella (jlk)- No Vote
Joe Brockmeier (jzb)- No Vote
David Nalley (ke4qqq)- No Vote
Kevin Kluge (kluge)- No Vote
Marcus Sorensen (mlsorensen) -1 (Not declared Binding or Veto)
Mohammad Nour El-Din (mnour)- No Vote
Noah Slater (nslater)- No Vote
Olivier Lamy (olamy)- No Vote
Prasanna Santhanam (tsp) +1 (Declared Binding)
Sebastien Goasguen (sebgoa) +1 (Not sure if it was changed to -1)
Wido den Hollander (widodh)- No Vote
William Chan (willchan)- No Vote

PMC Votes - 3 +1 / 2 -1

So Animesh is correct unless Sebastien you changed your vote to a -1 in
all of these conversations and I missed it. Remember is is Lazy Majority
of PMC Members only.


Cheers,
Matt 


On 9/9/13 5:08 PM, "Animesh Chaturvedi" 
wrote:

>
>> 
>> On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen 
>> wrote:
>> > Maybe before we get to carried away talking about future releases and
>> more automated testing (which is great and many of us have advocating
>> for and Prasanna has done outstanding working on BVT, jenkins and the
>> test matrix), we need to focus on how to get 4.2 out.
>> >
>> > Marcus has a binding -1, so that means the vote fails and we need
>> another RC (unless someone challenges Marcus's veto and he changes his
>> mind).
>> >
>[Animesh>] Sebastien the VOTE is by majority not a VETO.
>
>> > So what needs to be in the RC (aside from the cherry pick mentioned by
>> Marcus).
>> > Are there more blockers ?
>> > Do we need to invest in more testing before cutting that new RC or is
>> it just that one cherry pick ?
>> >
>> > If we agree on that and test before cutting, then maybe the vote can
>> > pass :)
>> >
>> > -sebastien
>> >
>> >
>> > On Sep 9, 2013, at 4:47 PM, Daan Hoogland 
>> wrote:
>> >
>> >> Why can't we cover every use case, Marcus. We will need help from
>> >> users, but if they do help it will be easy to do so.
>> >>
>> >> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen
>>  wrote:
>> >>> I was actually talking about separate things in relation to this
>> >>> thread and the other where I mentioned that I'd like to see a
>> >>> release focused on bugfixing and testing. With that, I'm advocating
>> >>> a test for every api call and focusing on broadening use case test
>> coverage.
>> >>>
>> >>> Here, I'm simply talking about taking the support matrix and doing
>> >>> some vary basic testing. This can be a dozen or so tests, each
>> >>> platform we say we support needs to successfully deploy a zone and a
>> >>> vm on every storage type that is in the support matrix. I don't
>> >>> think this would include plugins (or maybe those are left to the
>> >>> developer of the third party plugin). For KVM, this is literally a
>> >>> marvin script away from being there, I don't think there's a ton of
>> >>> work. I have no idea what we have or can do with vmware, and I'm
>> >>> guessing Xen is largely covered already.
>> >>>
>> >>> We'll never be able to cover every use case, I may be able to deploy
>> >>> a zone with my KVM setup, but not someone else's special network
>> layout.
>> >>> I'd just like to see sanity checks to say it works, at all, on the
>> >>> handful of 'supported' systems.
>> >>>
>> >>> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
>> >>>  wrote:
>>  Do we have any statistics that say how many of our customers are
>>  using feature x, feature y, etc.?
>> 
>>  If not, I would say if we know about a feature that has regressed
>>  to the point of breakage in 4.2 that it should be fixed before
>>  releasing (or at the very least well documented, so - if it is
>>  impactful to someone - they do not upgrade until it has been
>> fixed).
>> 
>> 
>>  On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
>>  chiradeep.vit...@citrix.com> wrote:
>> 
>> > I think that Animesh is trying to stress what is "key". If it hits
>> > 1% of cloud operators is it key?
>> >
>> >
>> > On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>> >
>> >> -1 from me as well.
>> >>
>> >>
>> >> I know we're tryin

Re: [Responsiveness report] users 2013w36

[Kelven Yang]

4.1.1 is actually using SSL tunneling port 443 opened at XS host to
connect to VNC terminal. Changing VNC configuration in XS host does not
help to resolve the console connectivity issue.

Kelven

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

>http://markmail.org/message/5pfd3por7uvhntgh Change vncterm in
>XenServer 6.0.2 for CloudStack 4.1.1 by Minh
>
>regards,

Re: Question about hypervisor snapshots

[Mike Tutkowski]

Thanks for that info on VMware snapshots, Kelven!

Anyone have insight into XenServer here?

Thanks!


On Mon, Sep 9, 2013 at 2:38 PM, Kelven Yang  wrote:

>
>
> On 9/8/13 4:21 PM, "Mike Tutkowski"  wrote:
>
> >Hi,
> >
> >I have a couple questions regarding how hypervisor snapshots work in
> >XenServer and ESX through CloudStack.
> >
> >For XenServer, let's say I have a root disk on SR1 and a data disk on SR2.
> >
> >1) If we take a hypervisor snapshot, do we snapshot both disks by default?
>
> For VMware, yes.
>
> >
> >2) Assuming we do, is the snapshot always stored with the disk it is a
> >snapshot of on the same SR?
>
> Yes, snapshot is stored along with its base disk in the same datastore
>
> >
> >3) Assuming they are, will the entire snapshot process fail if there is
> >insufficient space on any SR?
>
> If anyone fails, it will fail the snapshot as whole.
>
> >
> >Thanks!
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkow...@solidfire.com
> >o: 303.746.7302
> >Advancing the way the world uses the
> >cloud
> >* *
>
>


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

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Sudha Ponnaganti]

Would like provide some perspective on testing efforts done.  All test plans, 
results, automation has been posted to community and I took the data from that 
only[1]. 

 Thanks for raising the issues around testing before code check-in.  This would 
help in all fronts esp frontloading quality. Enabling development to run tests 
require good test suites and community has been helping with patches to fix 
failing test cases and adding new test suites.  I hope this would be taken 
seriously and feature owners check in test code religiously.   

-New test plans developed and posted on cwiki
Around 5500+ test cases ran manually [1]
Another 2000+ test cases ran through automation across all HV, with multiple 
configurations  [2]

- Logged defects and verified defects. 
Created 2200 ,  resolved 1850, verified 1650 Defects.

- several have helped to run automation
6 configurations for BVTs with Xen, KVM and VMWare on various configurations and
 6 more additional configurations are being run for regression covering HVs and 
various configurations

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/QA+-+4.2+Test+Execution+Results
[2]https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+4.2+Automation+Results+-+Baseline

Hope these discussions would help to put focus on quality and bring in 
contributors for automation efforts. There are several features which people 
can just pick up and run with it. Even today there are several automation 
patches pending on review board. If people can pick these up and help to review 
, fix and submit it would help everyone. 


-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Monday, September 09, 2013 1:48 PM
To: dev
Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

Why can't we cover every use case, Marcus. We will need help from users, but if 
they do help it will be easy to do so.

On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen  wrote:
>  I was actually talking about separate things in relation to this 
> thread and the other where I mentioned that I'd like to see a release 
> focused on bugfixing and testing. With that, I'm advocating a test for 
> every api call and focusing on broadening use case test coverage.
>
> Here, I'm simply talking about taking the support matrix and doing 
> some vary basic testing. This can be a dozen or so tests, each 
> platform we say we support needs to successfully deploy a zone and a 
> vm on every storage type that is in the support matrix. I don't think 
> this would include plugins (or maybe those are left to the developer 
> of the third party plugin). For KVM, this is literally a marvin script 
> away from being there, I don't think there's a ton of work. I have no 
> idea what we have or can do with vmware, and I'm guessing Xen is 
> largely covered already.
>
> We'll never be able to cover every use case, I may be able to deploy a 
> zone with my KVM setup, but not someone else's special network layout.
> I'd just like to see sanity checks to say it works, at all, on the 
> handful of 'supported' systems.
>
> On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski 
>  wrote:
>> Do we have any statistics that say how many of our customers are 
>> using feature x, feature y, etc.?
>>
>> If not, I would say if we know about a feature that has regressed to 
>> the point of breakage in 4.2 that it should be fixed before releasing 
>> (or at the very least well documented, so - if it is impactful to 
>> someone - they do not upgrade until it has been fixed).
>>
>>
>> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal < 
>> chiradeep.vit...@citrix.com> wrote:
>>
>>> I think that Animesh is trying to stress what is "key". If it hits 
>>> 1% of cloud operators is it key?
>>>
>>>
>>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
>>>
>>> >-1 from me as well.
>>> >
>>> >
>>> >I know we're trying to hit timed releases, but I think it's very 
>>> >important to preserve key underlying functionality across releases. 
>>> >If a supported and documented feature is known to be broken, we 
>>> >need to address it...if we don't, it's going to cause lots of pain, 
>>> >and reflect badly on ACS as a project.
>>> >
>>> >- Original Message -
>>> >
>>> >From: "Chip Childers" 
>>> >To: dev@cloudstack.apache.org
>>> >Sent: Monday, September 9, 2013 9:24:23 AM
>>> >Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>>> >
>>> >On Sun, Sep 08, 2013 at 12:40:30AM -0600, Marcus Sorensen wrote:
>>> >> -1 ... sorry guys, especially with Simon chiming in.
>>> >>
>>> >> I'd request f2c5b5fbfe45196dfad2821fca513ddd6efa25c9 be cherry-picked.
>>> >
>>> >Agreed.
>>> >
>>> >I'm -1, given simon's perspective as well. Since we have the fix, 
>>> >let's get it into the release.
>>> >
>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud

Getting Unable to find the Network Element implementing the Service Provider 'Netscaler' while adding a VPX

[Syed Mushtaq]

Hi,

I am building from master and am trying to add a Netscaler VPX to my
network config but I keep getting the following error

Unable to find the Network Element implementing the Service Provider
'Netscaler'

Also, when opening the page for listing Netscaler devices I get another
error saying

Unknown API command: listNetscalerLoadBalancers

does anyone else have this issue? Is there some config that I am missing?

Thanks
-Syed

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Edison Su]

+1(binding), tested on devcloud, and based on the QA's recently test result, 
seems it's stabilized for a while now(QA team didn't "bother" me for a few 
weeks:))

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Tuesday, September 03, 2013 9:43 PM
> To: dev@cloudstack.apache.org
> Subject: [VOTE] Apache CloudStack 4.2.0 (fourth 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: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02
> 
> 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 (Friday, 9/6 10:00 PM 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)
> 
> 
> Thanks
> Animesh

Re: Review Request 13895: CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be used for ssh instead of ipaddress of nic

[Rayees Namathponnan]

> On Sept. 5, 2013, 4:53 a.m., ASF Subversion and Git Services wrote:
> > Commit 0fb2014d19832a6e747a5c0775cd7c16f5ff786b in branch refs/heads/master 
> > from Girish Shilamkar
> > [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0fb2014 ]
> > 
> > CLOUDSTACK-4531: Resolved ssh error for basic zone. Public ip should be 
> > used for ssh instead of ipaddress of nic
> > 
> > Signed-off-by: venkataswamybabu budumuru 
> > 
> > (cherry picked from commit 4f3b411d4cf9a6986337dea98cd902b25efefb95)
> >

Still not working with this fix 


- Rayees


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


On Sept. 3, 2013, 12:32 p.m., Girish Shilamkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13895/
> ---
> 
> (Updated Sept. 3, 2013, 12:32 p.m.)
> 
> 
> Review request for cloudstack, venkata swamy babu  budumuru and Prasanna 
> Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4531
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4531: Resolved ssh error for basic zone. Public
>  ip should be used for ssh instead of ipaddress of nic
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py 3016ee4 
> 
> Diff: https://reviews.apache.org/r/13895/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Girish Shilamkar
> 
>

Re: Getting Unable to find the Network Element implementing the Service Provider 'Netscaler' while adding a VPX

[Syed Mushtaq]

I was not building a nonoss build and hence getting the error. Fixed it
now. Sorry for the spam.

Thanks,
-Syed


On Mon, Sep 9, 2013 at 7:39 PM, Syed Mushtaq wrote:

> Hi,
>
> I am building from master and am trying to add a Netscaler VPX to my
> network config but I keep getting the following error
>
> Unable to find the Network Element implementing the Service Provider
> 'Netscaler'
>
> Also, when opening the page for listing Netscaler devices I get another
> error saying
>
> Unknown API command: listNetscalerLoadBalancers
>
> does anyone else have this issue? Is there some config that I am missing?
>
> Thanks
> -Syed
>
>
>

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Marcus Sorensen]

Sorry, I should have declared my vote as binding, I meant to.

That's great news that we are improving teat coverage like that. What
procedures need to be followed if we need to add to that or find holes? I
could run daily KVM tests, do I use the Jenkins api to report results, or
can we request something in the current infrastructure?

I'm just a bit jaded I think from the fact that we released 4.1 as totally
unusable on Ubuntu(libvirt incompatibility), and nearly broke CLVM had I
not tried it on a whim. These things are very easy to catch, require very
little setup to test, and we state them as supported, but apparently have
zero regression testing and rely on individual devs to tell us if there's a
problem.

I'm still for getting automated test results to be good before calling an
RC vote, as well, to minimize the number of RC re-dos.
On Sep 9, 2013 5:22 PM, "Sudha Ponnaganti" 
wrote:

> Would like provide some perspective on testing efforts done.  All test
> plans, results, automation has been posted to community and I took the data
> from that only[1].
>
>  Thanks for raising the issues around testing before code check-in.  This
> would help in all fronts esp frontloading quality. Enabling development to
> run tests require good test suites and community has been helping with
> patches to fix failing test cases and adding new test suites.  I hope this
> would be taken seriously and feature owners check in test code religiously.
>
> -New test plans developed and posted on cwiki
> Around 5500+ test cases ran manually [1]
> Another 2000+ test cases ran through automation across all HV, with
> multiple configurations  [2]
>
> - Logged defects and verified defects.
> Created 2200 ,  resolved 1850, verified 1650 Defects.
>
> - several have helped to run automation
> 6 configurations for BVTs with Xen, KVM and VMWare on various
> configurations and
>  6 more additional configurations are being run for regression covering
> HVs and various configurations
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QA+-+4.2+Test+Execution+Results
> [2]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+4.2+Automation+Results+-+Baseline
>
> Hope these discussions would help to put focus on quality and bring in
> contributors for automation efforts. There are several features which
> people can just pick up and run with it. Even today there are several
> automation patches pending on review board. If people can pick these up and
> help to review , fix and submit it would help everyone.
>
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, September 09, 2013 1:48 PM
> To: dev
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>
> Why can't we cover every use case, Marcus. We will need help from users,
> but if they do help it will be easy to do so.
>
> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen 
> wrote:
> >  I was actually talking about separate things in relation to this
> > thread and the other where I mentioned that I'd like to see a release
> > focused on bugfixing and testing. With that, I'm advocating a test for
> > every api call and focusing on broadening use case test coverage.
> >
> > Here, I'm simply talking about taking the support matrix and doing
> > some vary basic testing. This can be a dozen or so tests, each
> > platform we say we support needs to successfully deploy a zone and a
> > vm on every storage type that is in the support matrix. I don't think
> > this would include plugins (or maybe those are left to the developer
> > of the third party plugin). For KVM, this is literally a marvin script
> > away from being there, I don't think there's a ton of work. I have no
> > idea what we have or can do with vmware, and I'm guessing Xen is
> > largely covered already.
> >
> > We'll never be able to cover every use case, I may be able to deploy a
> > zone with my KVM setup, but not someone else's special network layout.
> > I'd just like to see sanity checks to say it works, at all, on the
> > handful of 'supported' systems.
> >
> > On Mon, Sep 9, 2013 at 2:24 PM, Mike Tutkowski
> >  wrote:
> >> Do we have any statistics that say how many of our customers are
> >> using feature x, feature y, etc.?
> >>
> >> If not, I would say if we know about a feature that has regressed to
> >> the point of breakage in 4.2 that it should be fixed before releasing
> >> (or at the very least well documented, so - if it is impactful to
> >> someone - they do not upgrade until it has been fixed).
> >>
> >>
> >> On Mon, Sep 9, 2013 at 2:12 PM, Chiradeep Vittal <
> >> chiradeep.vit...@citrix.com> wrote:
> >>
> >>> I think that Animesh is trying to stress what is "key". If it hits
> >>> 1% of cloud operators is it key?
> >>>
> >>>
> >>> On 9/9/13 7:42 AM, "Simon Weller"  wrote:
> >>>
> >>> >-1 from me as well.
> >>> >
> >>> >
> >>> >I know we're trying to hit timed releases, but I think it's very
> >>> >important to preserve key underlying f

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chip Childers]

On Mon, Sep 9, 2013 at 5:12 PM, Sebastien Goasguen  wrote:

>
> On Sep 9, 2013, at 5:08 PM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
>
> >
> >>
> >> On Mon, Sep 9, 2013 at 3:01 PM, Sebastien Goasguen 
> >> wrote:
> >>> Maybe before we get to carried away talking about future releases and
> >> more automated testing (which is great and many of us have advocating
> >> for and Prasanna has done outstanding working on BVT, jenkins and the
> >> test matrix), we need to focus on how to get 4.2 out.
> >>>
> >>> Marcus has a binding -1, so that means the vote fails and we need
> >> another RC (unless someone challenges Marcus's veto and he changes his
> >> mind).
> >>>
> > [Animesh>] Sebastien the VOTE is by majority not a VETO.
>
> Ah, thought it was consensus.
>
> should be consensus for releases imho.
>
>
The ASF has defined releases for projects as something that aren't able to
be veto'ed.  Voting is what counts here.

If people are +1, then great!  If people are -1, then that's their choice
(as I've voted for this RC).  I can't block this release as a PMC member.
 All I can do is vote as I see fit.

Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Chip Childers]

On Mon, Sep 9, 2013 at 5:40 PM, Mathias Mullins
wrote:

> Technically I don't see any binding -1 vetoes being declared. Animesh is
> correct on this.
>
>
I don't have to write "Binding" next to my vote. Votes are technically
"binding" when the person voting is considered to have binding vote.

Also, -1 is not a veto.  It's a vote!  Unless this is a technical matter
(which releases are specifically excluded from), there isn't any veto'ing...

As a reminder, all votes (binding / PMC or otherwise) are important to this
process.  They help people express opinions about the RC.

[snip]


> PMC Votes - 3 +1 / 2 -1
>
> So Animesh is correct unless Sebastien you changed your vote to a -1 in
> all of these conversations and I missed it. Remember is is Lazy Majority
> of PMC Members only.
>
>
> Cheers,
> Matt
>

Matt's right.  Animesh is now free to make a decision on his own about
this.  He's got enough votes to release 4.2.0 at this point, and has kept
the thread open for more than enough time to gather input.

As the RM (specifically... as a committer that called the vote), Animesh
can either choose to re-spin another RC to accommodate the concerns raised
(for which there happens to be a clear fix), or he can move forward with
the release promotion from dist/dev to dist/release.

As I said in my vote, I'm -1 because we have known users that are not going
to be able to upgrade.  That's my personal vote though, and it isn't a /
can't be a veto.

-chip

Re: Question: Supported API calls in the Simulator

[Chip Childers]

On Mon, Sep 9, 2013 at 4:10 PM, Edison Su  wrote:

> The current implementation of simulator has its own limitation: the
> simulator itself is a separate hypervisor type, thus a lot of condition
> checks against hypervisor type in mgt server will fail if simulator is used.
> For example, currently, the zone wide primary storage only works for
> vmware and kvm, so if you add a zone wide primary storage into a zone which
> only has simulator as hypervisor, then you can't use that zone wide primary
> storage at all.
> The simulator should be able to simulate any other hypervisors, maybe
> fixed in 4.3?
>
>
Yeah, that's probably the best way to fix this up. Being able to have the
simulator "emulate" another HV for the orchestration logic would be good.
 OTOH, I don't think we want to make this overly complex...

RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

[Sudha Ponnaganti]

With current setup, you can request to run tests on a dev branch if need to run 
- I am sure we are not equipped to run tests for every check-in, but if 
community is making architectural changes, definitely that can be accommodated. 
Within the boundaries of what has been automated we can run automation i.e not 
every feature can be covered. Tests suites are self-explanatory and can be 
reviewed in repo so you will have an idea on what has been automated and what 
is not. 

It has been difficult to cover all the features that are being coded given the 
dev:qa ratio in community. So certain features might not have been picked up. 
When we do periodic reviews, I have been  identifying and posting such requests 
asking community to help on feature coverage.  Issues are being raised only 
when RC is sent for voting but if we pay a little attention when countdown 
starts, that would help. 


-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Monday, September 09, 2013 8:01 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.2.0 (fourth round)

Sorry, I should have declared my vote as binding, I meant to.

That's great news that we are improving teat coverage like that. What 
procedures need to be followed if we need to add to that or find holes? I could 
run daily KVM tests, do I use the Jenkins api to report results, or can we 
request something in the current infrastructure?

I'm just a bit jaded I think from the fact that we released 4.1 as totally 
unusable on Ubuntu(libvirt incompatibility), and nearly broke CLVM had I not 
tried it on a whim. These things are very easy to catch, require very little 
setup to test, and we state them as supported, but apparently have zero 
regression testing and rely on individual devs to tell us if there's a problem.

I'm still for getting automated test results to be good before calling an RC 
vote, as well, to minimize the number of RC re-dos.
On Sep 9, 2013 5:22 PM, "Sudha Ponnaganti" 
wrote:

> Would like provide some perspective on testing efforts done.  All test 
> plans, results, automation has been posted to community and I took the 
> data from that only[1].
>
>  Thanks for raising the issues around testing before code check-in.  
> This would help in all fronts esp frontloading quality. Enabling 
> development to run tests require good test suites and community has 
> been helping with patches to fix failing test cases and adding new 
> test suites.  I hope this would be taken seriously and feature owners check 
> in test code religiously.
>
> -New test plans developed and posted on cwiki Around 5500+ test cases 
> ran manually [1] Another 2000+ test cases ran through automation 
> across all HV, with multiple configurations  [2]
>
> - Logged defects and verified defects.
> Created 2200 ,  resolved 1850, verified 1650 Defects.
>
> - several have helped to run automation
> 6 configurations for BVTs with Xen, KVM and VMWare on various 
> configurations and
>  6 more additional configurations are being run for regression 
> covering HVs and various configurations
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QA+-+4.2+Test+E
> xecution+Results
> [2]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+4.2+Automat
> ion+Results+-+Baseline
>
> Hope these discussions would help to put focus on quality and bring in 
> contributors for automation efforts. There are several features which 
> people can just pick up and run with it. Even today there are several 
> automation patches pending on review board. If people can pick these 
> up and help to review , fix and submit it would help everyone.
>
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, September 09, 2013 1:48 PM
> To: dev
> Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round)
>
> Why can't we cover every use case, Marcus. We will need help from 
> users, but if they do help it will be easy to do so.
>
> On Mon, Sep 9, 2013 at 10:43 PM, Marcus Sorensen 
> wrote:
> >  I was actually talking about separate things in relation to this 
> > thread and the other where I mentioned that I'd like to see a 
> > release focused on bugfixing and testing. With that, I'm advocating 
> > a test for every api call and focusing on broadening use case test coverage.
> >
> > Here, I'm simply talking about taking the support matrix and doing 
> > some vary basic testing. This can be a dozen or so tests, each 
> > platform we say we support needs to successfully deploy a zone and a 
> > vm on every storage type that is in the support matrix. I don't 
> > think this would include plugins (or maybe those are left to the 
> > developer of the third party plugin). For KVM, this is literally a 
> > marvin script away from being there, I don't think there's a ton of 
> > work. I have no idea what we have or can do with vmware, and I'm 
> > guessing Xen is largely covered already.
> >
> > We'll never b

Re: what do you do if your mshost mac changes?

[Prasanna Santhanam]

On Mon, Sep 09, 2013 at 08:53:45PM +, Kelven Yang wrote:
> 
> 
> On 9/9/13 12:07 PM, "Darren Shepherd"  wrote:
> 
> >I just ran into this.  For whatever reason my box listed eth2 before
> >eth0 for "ifconfig -a" so it looked like management server mac changed.
> >  Then nothing worked...
> 
> It is supposed to work if you are sure a previous running MS java process
> is killed and the IP associated is still valid for the setup. A mac change
> will cause CloudStack to think there is another MS node is UP, however, it
> will try to detect if there is any other node which is currently using the
> MS IP, it may do self-fencing to shut itself down if a previous running MS
> java process is still running there.
> 
> The only requirement for it to work is that, mac address can be changed,
> but the associated IP should be valid to the setup
> 
only last week this was found to be a problem with 4.2.0 by someone
who tried this internally.
 
cf: https://issues.apache.org/jira/browse/CLOUDSTACK-4621

> Kelven
> 
> 
> >I finally just hacked up the code to get it to
> >work again.
> >
> >So whats the real procedure if you do a chassis swap and your management
> >server MAC addr changes?  How does cloudstack deal with that?
> >
> >Darren

-- 
Prasanna.,


Powered by BigRock.com

Re: Question: Supported API calls in the Simulator

[Prasanna Santhanam]

On Tue, Sep 10, 2013 at 12:08:11AM -0400, Chip Childers wrote:
> On Mon, Sep 9, 2013 at 4:10 PM, Edison Su  wrote:
> 
> > The current implementation of simulator has its own limitation: the
> > simulator itself is a separate hypervisor type, thus a lot of condition
> > checks against hypervisor type in mgt server will fail if simulator is used.
> > For example, currently, the zone wide primary storage only works for
> > vmware and kvm, so if you add a zone wide primary storage into a zone which
> > only has simulator as hypervisor, then you can't use that zone wide primary
> > storage at all.
> > The simulator should be able to simulate any other hypervisors, maybe
> > fixed in 4.3?
> >
Some of this dependency on the hypervisor is unavoidable but will keep
improving as the architecture allows it. OTOH, Zone-Wide primary storage
should be easy to add to the simulator, I'll look into that. 

> Yeah, that's probably the best way to fix this up. Being able to have the
> simulator "emulate" another HV for the orchestration logic would be good.
>  OTOH, I don't think we want to make this overly complex...


The original problem posed by David about the NPE comes because of a
config check from the `hypervisor_capabilities` table, if you include
a row for the simulator similar to the other hypervisors then you
should be able to get past the NPE.
-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 14058: Including tests for VPC VM Lifecycle on Tagged hosts

[Ashutosh Kelkar]

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

(Updated Sept. 10, 2013, 5:53 a.m.)


Review request for cloudstack, Girish Shilamkar and Prasanna Santhanam.


Summary (updated)
-

Including tests for VPC VM Lifecycle on Tagged hosts


Repository: cloudstack-git


Description (updated)
---

Added 10 tests for VPC VM liftcycle on tagged hosts

New class added  : TestVMLifeCycleDiffHosts

def test_01_deploy_instance_in_network(self):
def test_02_stop_instance_in_network(self):
def test_03_start_instance_in_network(self):
def test_04_reboot_instance_in_network(self):
def test_05_destroy_instance_in_network(self):
def test_06_recover_instance_in_network(self):
def test_07_migrate_instance_in_network(self):
def test_08_user_data(self):
def test_09_meta_data(self):
def test_10_expunge_instance_in_network(self):

This set of tests requires a multi host tagged setup (3 hosts - 2 hosts with 
tag 'host1' and  1 host with tag 'host2')


Diffs
-

  test/integration/component/test_vpc_vm_life_cycle.py 9844c1f 

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


Testing
---


Thanks,

Ashutosh Kelkar