Re: Fast way to rebuild the GUI?

[Punith S]

hi mike,

mvn -P developer -*pl* :cloud-client-ui -DskipTests=true

i guess running this command only builds  the cloud-client-ui package,
ie client/target/cloud-client-ui-4.4.0-SNAPSHOT.war
but it won't be extracted to client/target/cloud-client-ui-4.4.0-SNAPSHOT

hence the new changes will not be reflected.

for an easy workaround you can scp the changed js file form your workspace
to the script folder in the running cloudstack and on refreshing the
browser will reflect the changes.

thanks.


On Sat, Aug 9, 2014 at 11:58 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I should clarify that that command runs successfully, but the GUI does not
> incorporate the new changes from running that command anymore.
>
>
> On Sat, Aug 9, 2014 at 12:12 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I could be wrong, but I thought we compressed JS files now.
> >
> > This used to work:
> >
> > mvn -P developer -pl :cloud-client-ui -DskipTests=true
> >
> > Unfortunately it no longer does.
> >
> >
> > On Sat, Aug 9, 2014 at 12:08 AM, Punith S 
> wrote:
> >
> >> hi mike,
> >>
> >> you can just replace the js file in
> >> cloudstack-management/webapps/client/scripts/ folder and reload the
> >> browser, js file will be reloaded in the cloudstack ui.
> >>
> >> thanks.
> >>
> >>
> >> On Sat, Aug 9, 2014 at 11:32 AM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > When you change a JavaScript file for the GUI, is there a fast way to
> >> > update the management server with this file short of having to rebuild
> >> the
> >> > entire codebase?
> >> >
> >> > 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
> >> > *™*
> >> >
> >>
> >>
> >>
> >> --
> >> regards,
> >>
> >> punith s
> >> cloudbyte.com
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>



-- 
regards,

punith s
cloudbyte.com

Re: Fast way to rebuild the GUI?

[Mike Tutkowski]

I should clarify that that command runs successfully, but the GUI does not
incorporate the new changes from running that command anymore.


On Sat, Aug 9, 2014 at 12:12 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I could be wrong, but I thought we compressed JS files now.
>
> This used to work:
>
> mvn -P developer -pl :cloud-client-ui -DskipTests=true
>
> Unfortunately it no longer does.
>
>
> On Sat, Aug 9, 2014 at 12:08 AM, Punith S  wrote:
>
>> hi mike,
>>
>> you can just replace the js file in
>> cloudstack-management/webapps/client/scripts/ folder and reload the
>> browser, js file will be reloaded in the cloudstack ui.
>>
>> thanks.
>>
>>
>> On Sat, Aug 9, 2014 at 11:32 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Hi,
>> >
>> > When you change a JavaScript file for the GUI, is there a fast way to
>> > update the management server with this file short of having to rebuild
>> the
>> > entire codebase?
>> >
>> > 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
>> > *™*
>> >
>>
>>
>>
>> --
>> regards,
>>
>> punith s
>> cloudbyte.com
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>



-- 
*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: Fast way to rebuild the GUI?

[Mike Tutkowski]

I could be wrong, but I thought we compressed JS files now.

This used to work:

mvn -P developer -pl :cloud-client-ui -DskipTests=true

Unfortunately it no longer does.


On Sat, Aug 9, 2014 at 12:08 AM, Punith S  wrote:

> hi mike,
>
> you can just replace the js file in
> cloudstack-management/webapps/client/scripts/ folder and reload the
> browser, js file will be reloaded in the cloudstack ui.
>
> thanks.
>
>
> On Sat, Aug 9, 2014 at 11:32 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Hi,
> >
> > When you change a JavaScript file for the GUI, is there a fast way to
> > update the management server with this file short of having to rebuild
> the
> > entire codebase?
> >
> > 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
> > *™*
> >
>
>
>
> --
> regards,
>
> punith s
> cloudbyte.com
>



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

Re: Fast way to rebuild the GUI?

[Punith S]

hi mike,

you can just replace the js file in
cloudstack-management/webapps/client/scripts/ folder and reload the
browser, js file will be reloaded in the cloudstack ui.

thanks.


On Sat, Aug 9, 2014 at 11:32 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> When you change a JavaScript file for the GUI, is there a fast way to
> update the management server with this file short of having to rebuild the
> entire codebase?
>
> 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
> *™*
>



-- 
regards,

punith s
cloudbyte.com

Fast way to rebuild the GUI?

[Mike Tutkowski]

Hi,

When you change a JavaScript file for the GUI, is there a fast way to
update the management server with this file short of having to rebuild the
entire codebase?

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: Import Template: qcow2

[Punith S]

hi mo,

you can put your centos qcow2 template in webapps/client directory and give
the registration url as http://xx.xx.xx.243:8080/client/
a22ed0a2-9285-42da-bc34-fc4e71d48910.qcow2 while registering the template
or you can create a simple python web server in centos and upload the
template.
be sure to give the exact os conf of the template.

thanks


On Sat, Aug 9, 2014 at 12:51 AM, mo  wrote:

> Hello,
>
> Question, I previously saved a CentOS 6.5 template (e.g. downloaded) and I
> got the file: a22ed0a2-9285-42da-bc34-fc4e71d48910.qcow2 on my local
> machine. I then uploaded it to my new install of CloudStack 4.4, but it
> won’t boot, it hangs at ‘Booting from Hard drive’, when I registered the
> template it “uploaded” rapidly, when it is in fact 2.2 gigs in size.
>
> How do you import templates? Because obviously this is not accurate how I
> proceeded.
>
> - Mo




-- 
regards,

punith s
cloudbyte.com

Jenkins build is still unstable: simulator-singlerun #93

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #92

[jenkins]

See 

Re: [VOTE] git workflow

[Sheng Yang]

Rohit,

Thank you to bring this to a end.

Finally handling multiple maintenance release is recognized as an issue in
this model.

--Sheng

On Fri, Aug 8, 2014 at 4:28 AM, Rohit Yadav 
wrote:

> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Thanks for reaching out. I don't think git-flow suits your use case very
> well. Git flow was mainly optimized as a set of rules to help bring forth
> "forward-only" releases, and does not support multiple concurrent and
> non-chronological releases very well. The main reason is that getting all
> the details down leads to much complexity. Back when the git-flow model was
> devised it was meant to be a rule set that could be automated, and aimed at
> a single release stream. Adding multiple concurrent releases would
> significantly complicate the model.
>
> I have no advice on what model would work better for you. Of course you
> could make a variant of git-flow that works with multiple "master"
> branches, one for each release, but the exact semantics of which of those
> to merge hot fixes in, for example, are not documented somewhere formally.
>
> Cheers,
> Vincent
> “
>
> On 08-Aug-2014, at 9:23 am, Daan Hoogland  wrote:
>
> > Rohit, this is not a git-flow or gitflow discussion. It seems to be at
> > times but it is not. It is a discussion about how to branch in our
> > repository. That discussion should not end, but maybe so in this
> > thread.
> >
> > On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav 
> wrote:
> >> Hi all,
> >>
> >> Let’s end this discussion thread.
> >>
> >> I asked Vincent (nvie) and some friends from google and facebook on
> this and all of them recommended that this is not for us; then I read the
> whole thread again without prejudice or ego and I think it’s not for us
> though we should pick up couple of good ideas from it:
> >>
> >> - git-flow was designed for only “forward” releases
> >> - git-flow does not support multiple concurrent and non-chronological
> releases/support very well (no nvie documentation on how to do that)
> >>
> >> Instead, if you’re interested on such topic I started a proposal
> (inspired by couple of workflows) on solving cherry-picking issue by
> adapting our release/master workflow please have a look on that. Some good
> reads on other git workflows we can get ideas from;
> >>
> >>
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows
> (my new proposal uses this idea)
> >> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> (read this at least once)
> >>
> >> PS. Let me know privately if you want me to forward you Vincent’s email
> >>
> >> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> >>
> >>> This is what I was wondering about, as well. It seems all of our
> 'master'
> >>> problems become 'develop' problems.
> >>>
> >>> I do like the idea of merging versus cherry picking (as a general
> rule),
> >>> though.
> >>>
> >>>
> >>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> >>> alena.prokharc...@citrix.com> wrote:
> >>>
>  Sebastian, addressing the following comment of yours
> 
> 
>  "The main issue with master right now is that it moves really fast as
> a
>  shared branch, people merge features without warning, we see
> regressions
>  etc..
>  By the time we release a major version, master has moved so much that
> it
>  feels like starting over with the next release. It's almost as if we
> are
>  forking our own software. CI alone (even if it were really good) will
> not
>  fix this.”
> 
> 
>  You will still have this problem. You cut the next release branch
> from the
>  *develop branch, not from master. And the *develop branch will move
> with
>  the same pace as the old master, after the release branch is cut. So
>  “master moving really fast” problem would become “develop moving
> really
>  fast”.
> 
>  The problems you’ve mentioned - people merge features without
> warning, we
>  see regressions - can be fixed only with automation in place and the
>  requirement to run this automation (CI/BVT) before the merge is done.
>  Otherwise you are just shifting all existing problems from master to
>  develop.
> 
> 
>  -Alena.
> 
> 
> 
>  On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
> 
> >
> > On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> >  wrote:
> >
> >>
> >>
> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
> >>
> >>>
> >>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
> >>>
>  On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
> run...@gmail.com>
>  wrote:
> >
> > On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
> >
> >> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>  wrote:
> >>> Edison, thank you for raising the concern about the

Jenkins build is still unstable: simulator-singlerun #91

[jenkins]

See 

Re: [ACS44] committing to 4.4

[Rohit Yadav]

Hi Daan,

May I suggest if we can take the next week to test 4.4 branch rigorously and 
fix bugs, also get some participation from dev and QA folks in the community, 
4.4.0 release IMO could have found some more attention from the community. I 
just request to do it right this time. In case you’re going somewhere (vacation 
perhaps?), one of our previous RMs/PMCs folks such as Animesh, Hugo, Chip can 
guide us.

My personal interest is to rigorously test api/cloudmonkey, KVM, LXC, db, 
agent, usage, systemvms, events, storage and networking; I’m sure others can 
help out with testing Xen, VMWare, sdn, vmsync, orchestrator, platform/service 
layer, and other components.

Regards.

On 08-Aug-2014, at 11:20 pm, Daan Hoogland  wrote:

> That's alright, and it turned out all right. I'm just nervous whether
> I can make a 4.4.1 on sunday.
>
> On Fri, Aug 8, 2014 at 11:11 PM, Rohit Yadav  
> wrote:
>> Hi Daan,
>>
>> Sorry about that, my frivolous fix broke the systemvm build job and that led 
>> series of brute force fixes.
>>
>> On 08-Aug-2014, at 10:26 pm, Daan Hoogland  wrote:
>>
>>> H,
>>>
>>> Please stop committing to 4.4 the coming time. If there are things to
>>> make a branch with the following name structure:
>>>
>>> hotfix/4.4-
>>>
>>> This is not to be instructive or corrective for anyone's good work
>>> over the last day, just to make sure we keep a solid state on 4.4
>>>
>>> I will do any merge that is requested either this weekend or after we
>>> have 4.4.1 out.
>>>
>>> thanks,
>>> --
>>> Daan
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure 
>> Support
>> CloudStack Bootcamp Training 
>> Courses
>>
>> This email and any attachments to it may be confidential and are intended 
>> solely for the use of the individual to whom it is addressed. Any views or 
>> opinions expressed are solely those of the author and do not necessarily 
>> represent those of Shape Blue Ltd or related companies. If you are not the 
>> intended recipient of this email, you must neither take any action based 
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if you believe you have received this email in error. Shape Blue Ltd is a 
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a 
>> company incorporated in India and is operated under license from Shape Blue 
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a 
>> company registered by The Republic of South Africa and is traded under 
>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Jenkins build is still unstable: simulator-singlerun #90

[jenkins]

See 

Re: [ACS44] committing to 4.4

[Daan Hoogland]

That's alright, and it turned out all right. I'm just nervous whether
I can make a 4.4.1 on sunday.

On Fri, Aug 8, 2014 at 11:11 PM, Rohit Yadav  wrote:
> Hi Daan,
>
> Sorry about that, my frivolous fix broke the systemvm build job and that led 
> series of brute force fixes.
>
> On 08-Aug-2014, at 10:26 pm, Daan Hoogland  wrote:
>
>> H,
>>
>> Please stop committing to 4.4 the coming time. If there are things to
>> make a branch with the following name structure:
>>
>> hotfix/4.4-
>>
>> This is not to be instructive or corrective for anyone's good work
>> over the last day, just to make sure we keep a solid state on 4.4
>>
>> I will do any merge that is requested either this weekend or after we
>> have 4.4.1 out.
>>
>> thanks,
>> --
>> Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.



-- 
Daan

Re: [ACS44] committing to 4.4

[Rohit Yadav]

Hi Daan,

Sorry about that, my frivolous fix broke the systemvm build job and that led 
series of brute force fixes.

On 08-Aug-2014, at 10:26 pm, Daan Hoogland  wrote:

> H,
>
> Please stop committing to 4.4 the coming time. If there are things to
> make a branch with the following name structure:
>
> hotfix/4.4-
>
> This is not to be instructive or corrective for anyone's good work
> over the last day, just to make sure we keep a solid state on 4.4
>
> I will do any merge that is requested either this weekend or after we
> have 4.4.1 out.
>
> thanks,
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Jenkins build is still unstable: simulator-singlerun #89

[jenkins]

See 

[ACS44] committing to 4.4

[Daan Hoogland]

H,

Please stop committing to 4.4 the coming time. If there are things to
make a branch with the following name structure:

hotfix/4.4-

This is not to be instructive or corrective for anyone's good work
over the last day, just to make sure we keep a solid state on 4.4

I will do any merge that is requested either this weekend or after we
have 4.4.1 out.

thanks,
-- 
Daan

Re: [ACS441] systemvm template for XenServer

[Daan Hoogland]

ok, i will check in a versioned version on branch 4.4 if the rc passes
so jenkins builds a good versioned one after vote before upping the
version to 4.4.2, and upload that one. great

On Fri, Aug 8, 2014 at 8:54 PM, Pierre-Luc Dion  wrote:
> Hi Daan,
>
> I've test  4.4.1 with the systemvm from bac.o[1] on xenserver and it's
> working better than 4.4.0 so far.
> no more pause issue, version is correct, java as well.
>
>
> [1]
> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/87/
>
>
> Pierre-Luc



-- 
Daan

Re: git commit: updated refs/heads/master to ffe0f2f

[Daan Hoogland]

Thanks

On Fri, Aug 8, 2014 at 7:22 PM,   wrote:
> Repository: cloudstack
> Updated Branches:
>   refs/heads/master d33278250 -> ffe0f2f60
>
>
> appliance: use the right way to get git branch name
>
> Taken from Junio C Hamano's blog [1], git's maintainer, he must not be wrong 
> :)
>
> [1] 
> http://git-blame.blogspot.ch/2013/06/checking-current-branch-programatically.html
>
> Signed-off-by: Rohit Yadav 
> (cherry picked from commit e16414e56d8f398f8ddbbde89d3ee833582b8bb2)
> Signed-off-by: Rohit Yadav 
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/ffe0f2f6
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/ffe0f2f6
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/ffe0f2f6
>
> Branch: refs/heads/master
> Commit: ffe0f2f60f664482f4b5fdb52b33eb45f0b25d88
> Parents: d332782
> Author: Rohit Yadav 
> Authored: Fri Aug 8 19:18:32 2014 +0200
> Committer: Rohit Yadav 
> Committed: Fri Aug 8 19:22:20 2014 +0200
>
> --
>  tools/appliance/build.sh | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/ffe0f2f6/tools/appliance/build.sh
> --
> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
> index 13e7c84..d377cc5 100755
> --- a/tools/appliance/build.sh
> +++ b/tools/appliance/build.sh
> @@ -31,12 +31,9 @@ build_date=`date +%Y-%m-%d`
>  branch=
>
>  if [ -z "$branch" ] ; then
> -  branch=$(git rev-parse --abbrev-ref HEAD)
> +  branch=`git symbolic-ref --short -q HEAD 2>/dev/null || echo unknown`
>  fi
>
> -if [ -z "$branch" ] ; then
> -branch=unknown
> -fi
>  rootdir=$PWD
>
>  # Initialize veewee and dependencies
>



-- 
Daan

[ACS441] upgrading tests from 4.2.1 to 4.4.1

[Pierre-Luc Dion]

Upgrade tests from 4.2.1 to 4.4.1 with xenserver did upgrade smoothly as it
should :-)

upgrade instruction will be simple.

Cluster settings are also visible after the upgrade which is great !

Thanks !!!   so rc1 = +1 ;-)

Pierre-Luc

Import Template: qcow2

[mo]

Hello,

Question, I previously saved a CentOS 6.5 template (e.g. downloaded) and I got 
the file: a22ed0a2-9285-42da-bc34-fc4e71d48910.qcow2 on my local machine. I 
then uploaded it to my new install of CloudStack 4.4, but it won’t boot, it 
hangs at ‘Booting from Hard drive’, when I registered the template it 
“uploaded” rapidly, when it is in fact 2.2 gigs in size. 

How do you import templates? Because obviously this is not accurate how I 
proceeded. 

- Mo

Jenkins build is still unstable: simulator-singlerun #88

[jenkins]

See 

[ACS441] systemvm template for XenServer

[Pierre-Luc Dion]

Hi Daan,

I've test  4.4.1 with the systemvm from bac.o[1] on xenserver and it's
working better than 4.4.0 so far.
no more pause issue, version is correct, java as well.


[1]
http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/87/


Pierre-Luc

Re: Review Request 24314: CLOUDSTACK-6695: UI: Added support for uploading a chain of certificates

[ASF Subversion and Git Services]

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


Commit d0ff6cd461d9169133a7782850c93c9a3e994ba8 in cloudstack's branch 
refs/heads/4.4 from Jessica Wang
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d0ff6cd ]

CLOUDSTACK-6695: Added support to the UI for uploading a chain of certificates

In the "SSL Certificate" dialog we added:
- new field for the root certificate;
- a button to add intermediate certificates if necessary; when this is pressed, 
a new field, called "Intermediate certificate 1" is added; pressed again, 
"Intermediate certificate 2" field is added, and so on.

We upload the certificates in order: first the root certificate (with id=1), 
then the intermediate certificates (with id=2,3,..) and finally the server 
certificate.
When uploading a certificate, we wait for the upload to be completed 
successfully and only then we proceed to uploading the next one. If one fails, 
we report failure and don't continue with the remaining.

Signed-off-by: Mihaela Stoica 


- ASF Subversion and Git Services


On Aug. 5, 2014, 9:03 p.m., Mihaela Stoica wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24314/
> ---
> 
> (Updated Aug. 5, 2014, 9:03 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle, Jessica Wang, and Nitin Mehta.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6695: Added support to the UI for uploading a chain of certificates
> 
> In the "SSL Certificate" dialog we added:
> - new field for the root certificate; 
> - a button to add intermediate certificates if necessary; when this is 
> pressed, a new field, called "Intermediate certificate 1" is added; pressed 
> again, "Intermediate certificate 2" field is added, and so on.
> 
> We upload the certificates in order: first the root certificate (with id=1), 
> then the intermediate certificates (with id=2,3,..) and finally the server 
> certificate.
> When uploading a certificate, we wait for the upload to be completed 
> succesfully and only then we proceed to uploading the next one. If one fails, 
> we report failure and don't continue with the remaining.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties a0205e1 
>   ui/css/cloudstack3.css 23681a7 
>   ui/dictionary.jsp 10aeaf9 
>   ui/scripts/ui-custom/physicalResources.js ac379b4 
> 
> Diff: https://reviews.apache.org/r/24314/diff/
> 
> 
> Testing
> ---
> 
> Yes, with a sample certificate chain.
> 
> 
> Thanks,
> 
> Mihaela Stoica
> 
>

Jenkins build is still unstable: simulator-singlerun #87

[jenkins]

See 

Re: Unable to add ISO

[Nitin Mehta]

See if the wiki helps
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Sec
ondary+storage+troubleshooting


On 08/08/14 10:40 AM, "Elapavuluri, Jaya" 
wrote:

>Hello,
>
>I am trying to register an iso under the template-> iso section of
>cloudstack. I have given proper url link for the ISO. However, when I
>click on the iso, the Ready state: NO and the Status is not showing the
>download percentage.
>
>Any insight on this matter?

Re: Review Request 24314: CLOUDSTACK-6695: UI: Added support for uploading a chain of certificates

[ASF Subversion and Git Services]

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


Commit 57f611df16c48419e582f41c1e630faa739c11c5 in cloudstack's branch 
refs/heads/master from Mihaela Stoica
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=57f611d ]

CLOUDSTACK-6695: Added support to the UI for uploading a chain of certificates

In the "SSL Certificate" dialog we added:
- new field for the root certificate;
- a button to add intermediate certificates if necessary; when this is pressed, 
a new field, called "Intermediate certificate 1" is added; pressed again, 
"Intermediate certificate 2" field is added, and so on.

We upload the certificates in order: first the root certificate (with id=1), 
then the intermediate certificates (with id=2,3,..) and finally the server 
certificate.
When uploading a certificate, we wait for the upload to be completed 
successfully and only then we proceed to uploading the next one. If one fails, 
we report failure and don't continue with the remaining.

Signed-off-by: Mihaela Stoica 


- ASF Subversion and Git Services


On Aug. 5, 2014, 9:03 p.m., Mihaela Stoica wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24314/
> ---
> 
> (Updated Aug. 5, 2014, 9:03 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle, Jessica Wang, and Nitin Mehta.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6695: Added support to the UI for uploading a chain of certificates
> 
> In the "SSL Certificate" dialog we added:
> - new field for the root certificate; 
> - a button to add intermediate certificates if necessary; when this is 
> pressed, a new field, called "Intermediate certificate 1" is added; pressed 
> again, "Intermediate certificate 2" field is added, and so on.
> 
> We upload the certificates in order: first the root certificate (with id=1), 
> then the intermediate certificates (with id=2,3,..) and finally the server 
> certificate.
> When uploading a certificate, we wait for the upload to be completed 
> succesfully and only then we proceed to uploading the next one. If one fails, 
> we report failure and don't continue with the remaining.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties a0205e1 
>   ui/css/cloudstack3.css 23681a7 
>   ui/dictionary.jsp 10aeaf9 
>   ui/scripts/ui-custom/physicalResources.js ac379b4 
> 
> Diff: https://reviews.apache.org/r/24314/diff/
> 
> 
> Testing
> ---
> 
> Yes, with a sample certificate chain.
> 
> 
> Thanks,
> 
> Mihaela Stoica
> 
>

RE: issues remaining for 4.4.1

[Animesh Chaturvedi]

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Thursday, August 07, 2014 1:53 AM
> To: dev
> Subject: issues remaining for 4.4.1
> 
> H,
> 
> have a look at https://issues.apache.org/jira/browse/CLOUDSTACK-
> 6358?filter=12328007
> 
> It is a disappointing 280+ list of issues with 4.4 but I think a lot of them 
> can
> be marked as won't solve, future releases or resolved.
[Animesh] We should not mark them as won't solve since they are still fresh. 
You can move them to 4.5. I am doing triage daily and looking over unassigned 
and finding someone to help. But you are right there are 1000+ unresolved 
issues (200 blocker, critical) and 1/2 of them are from prior year. We need 
volunteers to help triage and resolve issues. Some of really old ones can be 
resolved as obsolete


> 
> Please help me weed through these.
> 
> thanks,
> --
> Daan

[DISCUSS] Removing template URL format checking logic

[Rohit Yadav]

Hi,

With reference to https://issues.apache.org/jira/browse/CLOUDSTACK-5512 Marcus 
and I think we should remove the template URL format checking logic because:

- It does not handle pre-signed URL (say something that does not end with .vhd 
etc, but has bunch of http params)
- One can game the system by say renaming any file to respective format
- We dumb down, take whatever URL user gives and use the format they specify in 
their register template API call

Marcus also notes that TemplateUtils utility would validate selected format.

Please discuss if you’ve any use-case that can get affected by this?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Unable to add ISO

[Elapavuluri, Jaya]

Hello,

I am trying to register an iso under the template-> iso section of cloudstack. 
I have given proper url link for the ISO. However, when I click on the iso, the 
Ready state: NO and the Status is not showing the download percentage.

Any insight on this matter?

Re: git commit: updated refs/heads/4.4 to 00265fb

[Rohit Yadav]

wat? http://people.apache.org/~bhaisaab/wat.jpg

That should have worked, let me try again; probably bash issue? I used $() 
instead of ``.

Will fix it.

Cheers.

On 08-Aug-2014, at 6:17 pm, Daan Hoogland  wrote:

> well, that one didn't work out:
> systemvm64template-HEAD-2014-08-08-kvm.qcow2.bz2290.03 MB view
> systemvm64template-HEAD-2014-08-08-vmware.ova278.88 MB view
> systemvm64template-HEAD-2014-08-08-vmware.vmdk.bz2241.25 MB view
> systemvm64template-HEAD-2014-08-08-xen.vhd.bz2241.11 MB view
> s/HEAD/4.4/ was what I hoped for
>
> better go back to the good old ugly unix way
>
> On Fri, Aug 8, 2014 at 3:41 PM, Rohit Yadav  wrote:
>> On Fri, Aug 8, 2014 at 3:23 PM,  wrote:
>>
>>> Repository: cloudstack
>>> Updated Branches:
>>>  refs/heads/4.4 e77da80e0 -> 00265fba3
>>>
>>>
>>> did git change it output format since this script was made?
>>>
>>
>> That's just ugly, to get branch why not do:
>>
>> git rev-parse --abbrev-ref HEAD
>>
>> I'll fix it on both master and 4.4.
>>
>> Cheers.
>>
>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/00265fba
>>> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/00265fba
>>> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/00265fba
>>>
>>> Branch: refs/heads/4.4
>>> Commit: 00265fba342efd54823c38f7a6abf7304b4c3a03
>>> Parents: e77da80
>>> Author: Daan Hoogland 
>>> Authored: Fri Aug 8 15:22:30 2014 +0200
>>> Committer: Daan Hoogland 
>>> Committed: Fri Aug 8 15:22:30 2014 +0200
>>>
>>> --
>>> tools/appliance/build.sh | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> --
>>>
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/00265fba/tools/appliance/build.sh
>>> --
>>> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
>>> index db5dcb0..13c9ca7 100755
>>> --- a/tools/appliance/build.sh
>>> +++ b/tools/appliance/build.sh
>>> @@ -31,7 +31,7 @@ build_date=`date +%Y-%m-%d`
>>> branch=
>>>
>>> if [ -z "$branch" ] ; then
>>> -  branch=`git status | grep '# On branch' | awk '{print $4}'`
>>> +  branch=`git status | grep 'On branch' | awk '{print $3}'`
>>> fi
>>>
>>> if [ -z "$branch" ] ; then
>>>
>>>
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Review Request 22939: CLOUDSTACK-6460 - CLVM primary storage migration fails due to incorrect identification of source format.

[Simon Weller]

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

(Updated Aug. 8, 2014, 4:51 p.m.)


Review request for cloudstack, edison su and Marcus Sorensen.


Changes
---

Removed whitespace as per Daan's comment.


Bugs: CLOUDSTACK-6460
https://issues.apache.org/jira/browse/CLOUDSTACK-6460


Repository: cloudstack-git


Description
---

Addresses CLOUDSTACK-6460.
CLVM storage source was being identified as QCOW2, rather than raw when 
attempting a primary storage migration.  This caused the migration to fail when 
qemu-img attempted to image the file back from secondary storage to the new 
primary storage selected. This patch forces CLVM to be treated as RAW while 
continuing to acquire sourceFormat from other storage types via 
disk.getFormat();


Diffs (updated)
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
 e9c588e 

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


Testing
---

Stop VM. Migrate from one primary storage to another. Migration completes 
successfully. Start vm.


Thanks,

Simon Weller

Re: git commit: updated refs/heads/4.4 to 00265fb

[Daan Hoogland]

well, that one didn't work out:
systemvm64template-HEAD-2014-08-08-kvm.qcow2.bz2290.03 MB view
systemvm64template-HEAD-2014-08-08-vmware.ova278.88 MB view
systemvm64template-HEAD-2014-08-08-vmware.vmdk.bz2241.25 MB view
systemvm64template-HEAD-2014-08-08-xen.vhd.bz2241.11 MB view
s/HEAD/4.4/ was what I hoped for

better go back to the good old ugly unix way

On Fri, Aug 8, 2014 at 3:41 PM, Rohit Yadav  wrote:
> On Fri, Aug 8, 2014 at 3:23 PM,  wrote:
>
>> Repository: cloudstack
>> Updated Branches:
>>   refs/heads/4.4 e77da80e0 -> 00265fba3
>>
>>
>> did git change it output format since this script was made?
>>
>
> That's just ugly, to get branch why not do:
>
> git rev-parse --abbrev-ref HEAD
>
> I'll fix it on both master and 4.4.
>
> Cheers.
>
>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/00265fba
>> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/00265fba
>> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/00265fba
>>
>> Branch: refs/heads/4.4
>> Commit: 00265fba342efd54823c38f7a6abf7304b4c3a03
>> Parents: e77da80
>> Author: Daan Hoogland 
>> Authored: Fri Aug 8 15:22:30 2014 +0200
>> Committer: Daan Hoogland 
>> Committed: Fri Aug 8 15:22:30 2014 +0200
>>
>> --
>>  tools/appliance/build.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/00265fba/tools/appliance/build.sh
>> --
>> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
>> index db5dcb0..13c9ca7 100755
>> --- a/tools/appliance/build.sh
>> +++ b/tools/appliance/build.sh
>> @@ -31,7 +31,7 @@ build_date=`date +%Y-%m-%d`
>>  branch=
>>
>>  if [ -z "$branch" ] ; then
>> -  branch=`git status | grep '# On branch' | awk '{print $4}'`
>> +  branch=`git status | grep 'On branch' | awk '{print $3}'`
>>  fi
>>
>>  if [ -z "$branch" ] ; then
>>
>>



-- 
Daan

Re: List APIs Behavior

[Alena Prokharchyk]

Gaurav,

"Ideally, when we search by Id, then exception should be thrown and when
We expect by passing account/domainid/projectid/networkid etc, then
Noneshould be returned. Do all List APIs follow a similar guideline?²

Yes, all of CS APIs follow this behavior. If non-existing Id is passed in,
then the error is thrown by the DB Id validator. In case of public ip
address its different, and let me explain why.

When the ip gets disassociated, it doesn¹t get deleted. It¹s just marked
as non-allocated, and left in the DB so next associateIpAddress can pick
it up. Therefore you don¹t see any exception when requesting the ip by id.
Why empty list is returned then? Because by default, listPublicIpAddresses
returns allocated ips only. If you want to see free ips as well, you have
to pass ³allocatedOnly=false² to the call.

Hope it answers your question.

-Alena.



On 8/8/14, 2:05 AM, "Gaurav Aradhye"  wrote:

>Thanks Daan. I will update the page.
>
>Regards,
>Gaurav
>
>
>On Fri, Aug 8, 2014 at 2:20 PM, Daan Hoogland 
>wrote:
>
>> Gaurav,
>>
>> I think you are now pointing at one of the qualities of our API that
>> need to be addressed in 5.0 [1]. I may be wrong but I don't think a
>> standard behavior in these cases is defined and every list api has a
>> choice of several conventions to folow. Feel free to define what the
>> behavior should be in a future version by editing [1] :)
>>
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes
>>
>> On Fri, Aug 8, 2014 at 10:44 AM, Gaurav Aradhye
>>  wrote:
>> > Hello,
>> >
>> > Can somebody please address this query?
>> >
>> > Regards,
>> > Gaurav
>> >
>> >
>> > On Thu, Aug 7, 2014 at 10:23 PM, Gaurav Aradhye <
>> gaurav.arad...@clogeny.com>
>> > wrote:
>> >
>> >> I want to understand the output of the list APIs when the entity is
>>not
>> >> present / deleted. Suppose I create an account, create a network
>>within
>> it
>> >> and acquire a public IP address in the network.
>> >>
>> >> 1) ListPublicIpAddresses  - public ip id passed, returns public IP
>> >> 2) ListPublicIpAddresses - account, domainid passed, returns public
>>IP
>> >>
>> >> Now I delete the public IP (Disassociate).
>> >>
>> >> After this operation, I expect following results:
>> >> 1) ListPublicIpAddreses - account,domain id passed, result: None
>> (assuming
>> >> there was only one)
>> >> 2) ListPublicIpAddresses - public ip id passed, I expect exception
>>here
>> >> because the id must have been removed from DB. But I get "None" as
>> result
>> >> here.
>> >>
>> >> If I get None, then can I assume that id is still present in DB but
>>it
>> is
>> >> marked as obsolete?
>> >>
>> >> When can I expect an exception in return? And when can I expect None?
>> >> Ideally, when we search by Id, then exception should be thrown and
>>when
>> we
>> >> expect by passing account/domainid/projectid/networkid etc, then None
>> >> should be returned. Do all List APIs follow a similar guideline?
>> >>
>> >> Regards,
>> >> Gaurav
>> >>
>>
>>
>>
>> --
>> Daan

Re: What is the behaviour of VPC Reset?

[Alena Prokharchyk]

"But, I do not see any code that makes a call to delete the rules and reapplies 
it. If it reapplies how does it get the information for each tier to reapply 
the ACLs.
I see that just shutdownVpc() API call is made and VPCVRElement just invokes 
destroyRouter…”

If you look further, you should see the call to “startVpc”. From this method, 
call to implement all the vpc resources is made (element.implementVpc). Then it 
comes to the VpcVirtualRouterElement, implement method. From there the VR gets 
deployed. In turn, deployRouter consists of a) starting/creating the VR b) 
implementing all the rules. You can find all the rules that are being 
re-applied, in finalizeCommandsOnStart() method of the 
VpcVirtualNetworkApplianceManagerImpl.


-Alena.

From: Suresh Ramamurthy 
mailto:suresh.ramamur...@nuagenetworks.net>>
Date: Thursday, August 7, 2014 at 5:17 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Sheng Yang 
mailto:sheng.y...@citrix.com>>
Subject: Re: What is the behaviour of VPC Reset?

Hi Alena,

Thanks for quick response.

But, I do not see any code that makes a call to delete the rules and reapplies 
it. If it reapplies how does it get the information for each tier to reapply 
the ACLs.
I see that just shutdownVpc() API call is made and VPCVRElement just invokes 
destroyRouter...

Am I missing something here. Can you please point me to code that deletes and 
re-applies all Rules, NAT etc. Is it in VR code? I am trying to understand the 
behaviour
so that I can replicate in our SDN solution.

I see this happening in case of Network Restart with clean up option.

Thanks,
Suresh




On Thu, Aug 7, 2014 at 4:32 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Suresh,

Yes, it does. All the rules for all the networks inside the VPC, are being
reapplied on the VPC VR after its up.

I don¹t see it being documented neither in the FS, nor in the API itself.
Please file a CS doc bug on that.

-Alena.

On 8/7/14, 3:40 PM, "Suresh Ramamurthy"
mailto:suresh.ramamur...@nuagenetworks.net>>
 wrote:

>Hi Alena, Sheng Yang,
>
>Could you please shed some light on the behaviour of VPC Reset
>functionality?
>
>When I went through the code, VPC Reset shuts down the VR and restarts it.
>Does it also clean all ACL, NAT etc associated to all the tiers in the VPC
>and then reconfigure the current value?
>
>Is there any document that I can read to get an idea about the behaviour?
>
>Thanks,
>Suresh Ramamurthy

Jenkins build is still unstable: simulator-singlerun #86

[jenkins]

See 

Review Request 24504: CLOUDSTACK-7293: UI: Fixed localization issues on the login page

[Mihaela Stoica]

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

Review request for cloudstack, Brian Federle and Jessica Wang.


Repository: cloudstack-git


Description
---

- Reverted the validator.messages to the original values (jquery.validator.js).
- Added a function to localize validator.messages which is called before login.


Diffs
-

  ui/lib/jquery.validate.js 2ee3961 
  ui/scripts/cloudStack.js 2285276 
  ui/scripts/ui/utils.js 769aea7 

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


Testing
---


Thanks,

Mihaela Stoica

Jenkins build is still unstable: simulator-singlerun #85

[jenkins]

See 

Re: git commit: updated refs/heads/4.4 to 00265fb

[Rohit Yadav]

On Fri, Aug 8, 2014 at 3:23 PM,  wrote:

> Repository: cloudstack
> Updated Branches:
>   refs/heads/4.4 e77da80e0 -> 00265fba3
>
>
> did git change it output format since this script was made?
>

That's just ugly, to get branch why not do:

git rev-parse --abbrev-ref HEAD

I'll fix it on both master and 4.4.

Cheers.


>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/00265fba
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/00265fba
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/00265fba
>
> Branch: refs/heads/4.4
> Commit: 00265fba342efd54823c38f7a6abf7304b4c3a03
> Parents: e77da80
> Author: Daan Hoogland 
> Authored: Fri Aug 8 15:22:30 2014 +0200
> Committer: Daan Hoogland 
> Committed: Fri Aug 8 15:22:30 2014 +0200
>
> --
>  tools/appliance/build.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/00265fba/tools/appliance/build.sh
> --
> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
> index db5dcb0..13c9ca7 100755
> --- a/tools/appliance/build.sh
> +++ b/tools/appliance/build.sh
> @@ -31,7 +31,7 @@ build_date=`date +%Y-%m-%d`
>  branch=
>
>  if [ -z "$branch" ] ; then
> -  branch=`git status | grep '# On branch' | awk '{print $4}'`
> +  branch=`git status | grep 'On branch' | awk '{print $3}'`
>  fi
>
>  if [ -z "$branch" ] ; then
>
>

Jenkins build is still unstable: simulator-singlerun #84

[jenkins]

See 

Re: abount usage-server config

[Rajani Karuturi]

Hi,
Was the issue resolved? Can you send all the records in usage_job?


On Thu, Aug 7, 2014 at 12:47 PM, 李栋  wrote:

>  cloudstack version is 4.2.1
>
> 于 2014/8/7 15:02, 李栋 写道:
>
> *hi all:*
>
> *We followed the document
> (http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/usage.html
> )
> configured usage-server and it worked *
>
>
> * then modify the global variable parameters, as follows: *
>
>
>
>
>
> *But the usage of the database is still no data, there is only one
> unfinished task record in usage_job in: *
>
>
>
> *usage_log is this: *
> 2014-08-07 05:34:50,600 INFO
> [context.support.ClassPathXmlApplicationContext] (main:null) Refreshing
> org.springframework.context.support.ClassPathXmlApplicationContext@5d5bdc50:
> startup date [Thu Aug 07 13:34:50 CST 2014]; root of context hierarchy
> 2014-08-07 05:34:50,850 INFO  [factory.xml.XmlBeanDefinitionReader]
> (main:null) Loading XML bean definitions from class path resource
> [usageApplicationContext.xml]
> 2014-08-07 05:34:51,508 INFO
> [context.annotation.ClassPathBeanDefinitionScanner] (main:null) JSR-330
> 'javax.inject.Named' annotation found and supported for component scanning
> 2014-08-07 05:34:52,469 INFO
> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:null)
> JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
> 2014-08-07 05:34:52,557 INFO
> [context.support.ClassPathXmlApplicationContext] (main:null) Bean
> 'transactionContextBuilder' of type [class
> com.cloud.utils.db.TransactionContextBuilder] is not eligible for getting
> processed by all BeanPostProcessors (for example: not eligible for
> auto-proxying)
> 2014-08-07 05:34:52,603 INFO  [factory.support.DefaultListableBeanFactory]
> (main:null) Pre-instantiating singletons in
> org.springframework.beans.factory.support.DefaultListableBeanFactory@44d6b059:
> defining beans
> [org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,usageAlertManagerImpl,usageManagerImpl,networkOfferingUsageParser,VMInstanceUsageParser,loadBalancerUsageParser,volumeUsageParser,vmDiskUsageParser,networkUsageParser,securityGroupUsageParser,VPNUserUsageParser,IPAddressUsageParser,portForwardingUsageParser,VMSnapshotUsageParser,storageUsageParser,usageJobDaoImpl,usageVMInstanceDaoImpl,usageSecurityGroupDaoImpl,usagePortForwardingRuleDaoImpl,usageVmDiskDaoImpl,usageDaoImpl,externalPublicIpStatisticsDaoImpl,usageVMSnapshotDaoImpl,usageStorageDaoImpl,usageVPNUserDaoImpl,usageIPAddressDaoImpl,usageLoadBalancerPolicyDaoImpl,usageNetworkOfferingDaoImpl,usageNetworkDaoImpl,usageVolumeDaoImpl,eventDaoImpl,usageEventDaoImpl,eventJoin
> Da
> oImpl,accountDaoImpl,vmDiskStatisticsDaoImpl,userStatsLogDaoImpl,userAccountDaoImpl,userStatisticsDaoImpl,SSHKeyPairDaoImpl,userDaoImpl,resourceCountDaoImpl,resourceLimitDaoImpl,configurationDaoImpl,alertDaoImpl,domainDaoImpl,transactionContextBuilder,instantiatePostProcessor,ComponentContext,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
> root of factory hierarchy
>
> 2014-08-07 05:34:53,233 DEBUG [utils.crypt.EncryptionSecretKeyChecker]
> (main:null) Encryption Type: file
> 2014-08-07 05:34:56,686 INFO  [utils.component.ComponentContext]
> (main:null) Setup Spring Application context
> 2014-08-07 05:34:59,507 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_10af8e24
> 2014-08-07 05:34:59,514 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.configuration.dao.ResourceCountDaoImpl_EnhancerByCloudStack_17475fe1
> 2014-08-07 05:34:59,522 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.UsageSecurityGroupDaoImpl_EnhancerByCloudStack_132b816b
> 2014-08-07 05:34:59,522 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.user.dao.SSHKeyPairDaoImpl_EnhancerByCloudStack_c87a2086
> 2014-08-07 05:34:59,523 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.ExternalPublicIpStatisticsDaoImpl_EnhancerByCloudStack_abdd868b
> 2014-08-07 05:34:59,524 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.user.dao.AccountDaoImpl_EnhancerByCloudStack_d3b285cc
> 2014-08-07 05:34:59,524 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.domain.dao.DomainDaoImpl_EnhancerByCloudStack_ba7a7fbc
> 2014-08-07 05:34:59,525 INFO  [utils.component.ComponentContext]
> (main:null) Configuring
> com.cloud.usage.dao.UsageVPNUserDaoImpl_EnhancerByCloudStack_5f95c12b
> 2014-08-07 

Re: Review Request 24502: CLOUDSTACK-7292: Fixed issue in test_deploy_vm_root_resize.py

[ASF Subversion and Git Services]

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


Commit a52a1cd4fcac8d45165b52d36c04c5a274fc57c3 in cloudstack's branch 
refs/heads/master from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a52a1cd ]

CLOUDSTACK-7292: Fixed issue in test_deploy_vm_root_resize.py

Signed-off-by: Santhosh Edukulla 


- ASF Subversion and Git Services


On Aug. 8, 2014, 12:32 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24502/
> ---
> 
> (Updated Aug. 8, 2014, 12:32 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7292
> https://issues.apache.org/jira/browse/CLOUDSTACK-7292
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed issue by matching the hypervisor string properly with the string 
> constant.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vm_root_resize.py 9a09e46 
> 
> Diff: https://reviews.apache.org/r/24502/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test deploy virtual machine with root resize ... === TestName: 
> test_00_deploy_vm_root_resize | Status : SUCCESS ===
> ok
> Test proper failure to deploy virtual machine with rootdisksize of 0 ... === 
> TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
> ok
> Test proper failure to deploy virtual machine with rootdisksize less than 
> template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
> SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 208.422s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 24502: CLOUDSTACK-7292: Fixed issue in test_deploy_vm_root_resize.py

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On Aug. 8, 2014, 12:32 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24502/
> ---
> 
> (Updated Aug. 8, 2014, 12:32 p.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7292
> https://issues.apache.org/jira/browse/CLOUDSTACK-7292
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed issue by matching the hypervisor string properly with the string 
> constant.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vm_root_resize.py 9a09e46 
> 
> Diff: https://reviews.apache.org/r/24502/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test deploy virtual machine with root resize ... === TestName: 
> test_00_deploy_vm_root_resize | Status : SUCCESS ===
> ok
> Test proper failure to deploy virtual machine with rootdisksize of 0 ... === 
> TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
> ok
> Test proper failure to deploy virtual machine with rootdisksize less than 
> template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
> SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 208.422s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Review Request 24502: CLOUDSTACK-7292: Fixed issue in test_deploy_vm_root_resize.py

[Gaurav Aradhye]

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

Review request for cloudstack and Santhosh Edukulla.


Bugs: CLOUDSTACK-7292
https://issues.apache.org/jira/browse/CLOUDSTACK-7292


Repository: cloudstack-git


Description
---

Fixed issue by matching the hypervisor string properly with the string constant.


Diffs
-

  test/integration/smoke/test_deploy_vm_root_resize.py 9a09e46 

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


Testing
---

Yes.

Log:
Test deploy virtual machine with root resize ... === TestName: 
test_00_deploy_vm_root_resize | Status : SUCCESS ===
ok
Test proper failure to deploy virtual machine with rootdisksize of 0 ... === 
TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
ok
Test proper failure to deploy virtual machine with rootdisksize less than 
template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
SUCCESS ===
ok

--
Ran 3 tests in 208.422s

OK


Thanks,

Gaurav Aradhye

Re: [jira] [Closed] (CLOUDSTACK-6323) GetUser API always returns admin info

[Daan Hoogland]

right

On Fri, Aug 8, 2014 at 2:17 PM, Pierre-Luc Dion  wrote:
> I'll update the Release-note accordingly.
> it only affect GetUser  API call right ?
>
>
> Pierre-Luc DION
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
> 420 rue Guy | Montreal | Quebec | H3J 1S6
> w cloudops.com | tw @CloudOps_
>
>
>
> On Fri, Aug 8, 2014 at 7:16 AM, Rohit Yadav 
> wrote:
>>
>>
>> On 08-Aug-2014, at 1:11 pm, Daan Hoogland  wrote:
>>
>> > No, dumb question of mine (the only type of question that is really
>> > dumb is one for a known answer)
>> >
>> > It seems unlikely that it could have worked with a parameter with a
>> > conflicting name. If it didn't work at all before, we are fine. In the
>> > unlikely otherwise, we should make the api still accept the old
>> > parameter.
>>
>> Yeah, I was going to write that :)
>> This API did not ever work at all :P
>>
>> Cheers.
>>
>> >
>> > On Fri, Aug 8, 2014 at 1:01 PM, Daan Hoogland 
>> > wrote:
>> >> Pierre-Luc,
>> >>
>> >> Can you?
>> >> @Rohit: the old parameter is still accepted is it?
>> >>
>> >> On Fri, Aug 8, 2014 at 12:57 PM, Rohit Yadav (JIRA) 
>> >> wrote:
>> >>>
>> >>> [
>> >>> https://issues.apache.org/jira/browse/CLOUDSTACK-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> >>> ]
>> >>>
>> >>> Rohit Yadav closed CLOUDSTACK-6323.
>> >>> ---
>> >>>
>> >>>
>> >>> [~dahn] In the release notes we have to mention that this API has
>> >>> changed and will accept apikey by userapikey arg in the HTTP request.
>> >>>
>>  GetUser API always returns admin info
>>  -
>> 
>> Key: CLOUDSTACK-6323
>> URL:
>>  https://issues.apache.org/jira/browse/CLOUDSTACK-6323
>> Project: CloudStack
>>  Issue Type: Bug
>>  Security Level: Public(Anyone can view this level - this is the
>>  default.)
>>  Components: API
>>    Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0
>>    Reporter: Chiradeep Vittal
>>    Assignee: Rohit Yadav
>> Fix For: 4.4.1
>> 
>> 
>>  The annotation is API_KEY for the parameter apikey which
>>  automatically gets set to the requesters api key instead of the 
>>  requested
>>  API key. The annotation should be USER_API_KEY instead.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> This message was sent by Atlassian JIRA
>> >>> (v6.2#6252)
>> >>
>> >>
>> >>
>> >> --
>> >> Daan
>> >
>> >
>> >
>> > --
>> > Daan
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design &
>> Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training
>> Courses
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a
>> company incorporated in India and is operated under license from Shape Blue
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a
>> company registered by The Republic of South Africa and is traded under
>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
>



-- 
Daan

Re: [VOTE] git workflow

[Daan Hoogland]

This sounds like an end goal that we shouldn't try to reach in one go.
Let's take baby steps.

On Fri, Aug 8, 2014 at 1:28 PM, Rohit Yadav  wrote:
> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Thanks for reaching out. I don't think git-flow suits your use case very 
> well. Git flow was mainly optimized as a set of rules to help bring forth 
> "forward-only" releases, and does not support multiple concurrent and 
> non-chronological releases very well. The main reason is that getting all the 
> details down leads to much complexity. Back when the git-flow model was 
> devised it was meant to be a rule set that could be automated, and aimed at a 
> single release stream. Adding multiple concurrent releases would 
> significantly complicate the model.
>
> I have no advice on what model would work better for you. Of course you could 
> make a variant of git-flow that works with multiple "master" branches, one 
> for each release, but the exact semantics of which of those to merge hot 
> fixes in, for example, are not documented somewhere formally.
>
> Cheers,
> Vincent
> “
>
> On 08-Aug-2014, at 9:23 am, Daan Hoogland  wrote:
>
>> Rohit, this is not a git-flow or gitflow discussion. It seems to be at
>> times but it is not. It is a discussion about how to branch in our
>> repository. That discussion should not end, but maybe so in this
>> thread.
>>
>> On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav  
>> wrote:
>>> Hi all,
>>>
>>> Let’s end this discussion thread.
>>>
>>> I asked Vincent (nvie) and some friends from google and facebook on this 
>>> and all of them recommended that this is not for us; then I read the whole 
>>> thread again without prejudice or ego and I think it’s not for us though we 
>>> should pick up couple of good ideas from it:
>>>
>>> - git-flow was designed for only “forward” releases
>>> - git-flow does not support multiple concurrent and non-chronological 
>>> releases/support very well (no nvie documentation on how to do that)
>>>
>>> Instead, if you’re interested on such topic I started a proposal (inspired 
>>> by couple of workflows) on solving cherry-picking issue by adapting our 
>>> release/master workflow please have a look on that. Some good reads on 
>>> other git workflows we can get ideas from;
>>>
>>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows 
>>> (my new proposal uses this idea)
>>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read 
>>> this at least once)
>>>
>>> PS. Let me know privately if you want me to forward you Vincent’s email
>>>
>>> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski  
>>> wrote:
>>>
 This is what I was wondering about, as well. It seems all of our 'master'
 problems become 'develop' problems.

 I do like the idea of merging versus cherry picking (as a general rule),
 though.


 On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
 alena.prokharc...@citrix.com> wrote:

> Sebastian, addressing the following comment of yours
>
>
> "The main issue with master right now is that it moves really fast as a
> shared branch, people merge features without warning, we see regressions
> etc..
> By the time we release a major version, master has moved so much that it
> feels like starting over with the next release. It's almost as if we are
> forking our own software. CI alone (even if it were really good) will not
> fix this.”
>
>
> You will still have this problem. You cut the next release branch from the
> *develop branch, not from master. And the *develop branch will move with
> the same pace as the old master, after the release branch is cut. So
> “master moving really fast” problem would become “develop moving really
> fast”.
>
> The problems you’ve mentioned - people merge features without warning, we
> see regressions - can be fixed only with automation in place and the
> requirement to run this automation (CI/BVT) before the merge is done.
> Otherwise you are just shifting all existing problems from master to
> develop.
>
>
> -Alena.
>
>
>
> On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>
>>
>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>  wrote:
>>
>>>
>>>
>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>>>

 On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:

> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
> wrote:
>>
>> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>>
>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>  wrote:
 Edison, thank you for raising the concern about the BVT/CI.
 Somebody
 mentioned earlier that we should separate git workflow
 implementation from
 the CI effort, but 

Re: [jira] [Closed] (CLOUDSTACK-6323) GetUser API always returns admin info

[Pierre-Luc Dion]

I'll update the Release-note accordingly.
it only affect GetUser  API call right ?


*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_



On Fri, Aug 8, 2014 at 7:16 AM, Rohit Yadav 
wrote:

>
> On 08-Aug-2014, at 1:11 pm, Daan Hoogland  wrote:
>
> > No, dumb question of mine (the only type of question that is really
> > dumb is one for a known answer)
> >
> > It seems unlikely that it could have worked with a parameter with a
> > conflicting name. If it didn't work at all before, we are fine. In the
> > unlikely otherwise, we should make the api still accept the old
> > parameter.
>
> Yeah, I was going to write that :)
> This API did not ever work at all :P
>
> Cheers.
>
> >
> > On Fri, Aug 8, 2014 at 1:01 PM, Daan Hoogland 
> wrote:
> >> Pierre-Luc,
> >>
> >> Can you?
> >> @Rohit: the old parameter is still accepted is it?
> >>
> >> On Fri, Aug 8, 2014 at 12:57 PM, Rohit Yadav (JIRA) 
> wrote:
> >>>
> >>> [
> https://issues.apache.org/jira/browse/CLOUDSTACK-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >>>
> >>> Rohit Yadav closed CLOUDSTACK-6323.
> >>> ---
> >>>
> >>>
> >>> [~dahn] In the release notes we have to mention that this API has
> changed and will accept apikey by userapikey arg in the HTTP request.
> >>>
>  GetUser API always returns admin info
>  -
> 
> Key: CLOUDSTACK-6323
> URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-6323
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the
> default.)
>  Components: API
>    Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0
>    Reporter: Chiradeep Vittal
>    Assignee: Rohit Yadav
> Fix For: 4.4.1
> 
> 
>  The annotation is API_KEY for the parameter apikey which
> automatically gets set to the requesters api key instead of the requested
> API key. The annotation should be USER_API_KEY instead.
> >>>
> >>>
> >>>
> >>> --
> >>> This message was sent by Atlassian JIRA
> >>> (v6.2#6252)
> >>
> >>
> >>
> >> --
> >> Daan
> >
> >
> >
> > --
> > Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>

Jenkins build is still unstable: simulator-singlerun #83

[jenkins]

See 

Re: [VOTE] git workflow

[Rohit Yadav]

Hi,

Vincent (nvie) has allowed me to share his email publicly, here you go:

"
Hi Rohit,

Thanks for reaching out. I don't think git-flow suits your use case very well. 
Git flow was mainly optimized as a set of rules to help bring forth 
"forward-only" releases, and does not support multiple concurrent and 
non-chronological releases very well. The main reason is that getting all the 
details down leads to much complexity. Back when the git-flow model was devised 
it was meant to be a rule set that could be automated, and aimed at a single 
release stream. Adding multiple concurrent releases would significantly 
complicate the model.

I have no advice on what model would work better for you. Of course you could 
make a variant of git-flow that works with multiple "master" branches, one for 
each release, but the exact semantics of which of those to merge hot fixes in, 
for example, are not documented somewhere formally.

Cheers,
Vincent
“

On 08-Aug-2014, at 9:23 am, Daan Hoogland  wrote:

> Rohit, this is not a git-flow or gitflow discussion. It seems to be at
> times but it is not. It is a discussion about how to branch in our
> repository. That discussion should not end, but maybe so in this
> thread.
>
> On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav  wrote:
>> Hi all,
>>
>> Let’s end this discussion thread.
>>
>> I asked Vincent (nvie) and some friends from google and facebook on this and 
>> all of them recommended that this is not for us; then I read the whole 
>> thread again without prejudice or ego and I think it’s not for us though we 
>> should pick up couple of good ideas from it:
>>
>> - git-flow was designed for only “forward” releases
>> - git-flow does not support multiple concurrent and non-chronological 
>> releases/support very well (no nvie documentation on how to do that)
>>
>> Instead, if you’re interested on such topic I started a proposal (inspired 
>> by couple of workflows) on solving cherry-picking issue by adapting our 
>> release/master workflow please have a look on that. Some good reads on other 
>> git workflows we can get ideas from;
>>
>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my 
>> new proposal uses this idea)
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read 
>> this at least once)
>>
>> PS. Let me know privately if you want me to forward you Vincent’s email
>>
>> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski  
>> wrote:
>>
>>> This is what I was wondering about, as well. It seems all of our 'master'
>>> problems become 'develop' problems.
>>>
>>> I do like the idea of merging versus cherry picking (as a general rule),
>>> though.
>>>
>>>
>>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>>> alena.prokharc...@citrix.com> wrote:
>>>
 Sebastian, addressing the following comment of yours


 "The main issue with master right now is that it moves really fast as a
 shared branch, people merge features without warning, we see regressions
 etc..
 By the time we release a major version, master has moved so much that it
 feels like starting over with the next release. It's almost as if we are
 forking our own software. CI alone (even if it were really good) will not
 fix this.”


 You will still have this problem. You cut the next release branch from the
 *develop branch, not from master. And the *develop branch will move with
 the same pace as the old master, after the release branch is cut. So
 “master moving really fast” problem would become “develop moving really
 fast”.

 The problems you’ve mentioned - people merge features without warning, we
 see regressions - can be fixed only with automation in place and the
 requirement to run this automation (CI/BVT) before the merge is done.
 Otherwise you are just shifting all existing problems from master to
 develop.


 -Alena.



 On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:

>
> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>  wrote:
>
>>
>>
>> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>>
>>>
>>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>>>
 On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
 wrote:
>
> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>
>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>  wrote:
>>> Edison, thank you for raising the concern about the BVT/CI.
>>> Somebody
>>> mentioned earlier that we should separate git workflow
>>> implementation from
>>> the CI effort, but I do think we have to do in in conjunction.
>>> Otherwise
>>> what is the point in introducing staging/develop branch? If there
>>> is
>>> no
>>> daily automation run verifying all the code merged from
>>> hotFixes/feature
>>> branches (and

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.

[Rohit Yadav]

> On Aug. 8, 2014, 10:59 a.m., daan Hoogland wrote:
> > b8deb6ba3f72d7da1944c47ee60db3ff4127da6c on master

We'll keep an eye on the systemvm build and test the systemvms (I'll do for 
KVM, do I hear anyone else for XEN?) and if does not work revert; else we can 
cherry-pick on 4.4 as well.


- Rohit


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


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: [jira] [Closed] (CLOUDSTACK-6323) GetUser API always returns admin info

[Rohit Yadav]

On 08-Aug-2014, at 1:11 pm, Daan Hoogland  wrote:

> No, dumb question of mine (the only type of question that is really
> dumb is one for a known answer)
>
> It seems unlikely that it could have worked with a parameter with a
> conflicting name. If it didn't work at all before, we are fine. In the
> unlikely otherwise, we should make the api still accept the old
> parameter.

Yeah, I was going to write that :)
This API did not ever work at all :P

Cheers.

>
> On Fri, Aug 8, 2014 at 1:01 PM, Daan Hoogland  wrote:
>> Pierre-Luc,
>>
>> Can you?
>> @Rohit: the old parameter is still accepted is it?
>>
>> On Fri, Aug 8, 2014 at 12:57 PM, Rohit Yadav (JIRA)  wrote:
>>>
>>> [ 
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>  ]
>>>
>>> Rohit Yadav closed CLOUDSTACK-6323.
>>> ---
>>>
>>>
>>> [~dahn] In the release notes we have to mention that this API has changed 
>>> and will accept apikey by userapikey arg in the HTTP request.
>>>
 GetUser API always returns admin info
 -

Key: CLOUDSTACK-6323
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6323
Project: CloudStack
 Issue Type: Bug
 Security Level: Public(Anyone can view this level - this is the 
 default.)
 Components: API
   Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0
   Reporter: Chiradeep Vittal
   Assignee: Rohit Yadav
Fix For: 4.4.1


 The annotation is API_KEY for the parameter apikey which automatically 
 gets set to the requesters api key instead of the requested API key. The 
 annotation should be USER_API_KEY instead.
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.2#6252)
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [jira] [Closed] (CLOUDSTACK-6323) GetUser API always returns admin info

[Daan Hoogland]

No, dumb question of mine (the only type of question that is really
dumb is one for a known answer)

It seems unlikely that it could have worked with a parameter with a
conflicting name. If it didn't work at all before, we are fine. In the
unlikely otherwise, we should make the api still accept the old
parameter.

On Fri, Aug 8, 2014 at 1:01 PM, Daan Hoogland  wrote:
> Pierre-Luc,
>
> Can you?
> @Rohit: the old parameter is still accepted is it?
>
> On Fri, Aug 8, 2014 at 12:57 PM, Rohit Yadav (JIRA)  wrote:
>>
>>  [ 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>  ]
>>
>> Rohit Yadav closed CLOUDSTACK-6323.
>> ---
>>
>>
>> [~dahn] In the release notes we have to mention that this API has changed 
>> and will accept apikey by userapikey arg in the HTTP request.
>>
>>> GetUser API always returns admin info
>>> -
>>>
>>> Key: CLOUDSTACK-6323
>>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6323
>>> Project: CloudStack
>>>  Issue Type: Bug
>>>  Security Level: Public(Anyone can view this level - this is the 
>>> default.)
>>>  Components: API
>>>Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0
>>>Reporter: Chiradeep Vittal
>>>Assignee: Rohit Yadav
>>> Fix For: 4.4.1
>>>
>>>
>>> The annotation is API_KEY for the parameter apikey which automatically gets 
>>> set to the requesters api key instead of the requested API key. The 
>>> annotation should be USER_API_KEY instead.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.2#6252)
>
>
>
> --
> Daan



-- 
Daan

Re: Review Request 21696: CLOUDSTACK-6716: /usr volume is to small on SVMs. Reshuffling some space to fix that.

[daan Hoogland]

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

Ship it!


b8deb6ba3f72d7da1944c47ee60db3ff4127da6c on master

- daan Hoogland


On May 20, 2014, 2:30 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21696/
> ---
> 
> (Updated May 20, 2014, 2:30 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Ian Duffy, Rohit Yadav, and 
> Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6716
> https://issues.apache.org/jira/browse/CLOUDSTACK-6716
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We noticed after upgrading our svms to 4.3 that the /usr volume was nearly 
> full. When inspecting this on SSVMs and CVMs we noticed that on thse 
> instances it was already 100% full (because ACS jars get copied to this 
> volume). By reshuffling some space the /usr volume should end up around 80% 
> full. Also i've reduced swap a bit because this does not make a lot of sense 
> on virtual instances.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/preseed.cfg 635432a 
>   tools/appliance/definitions/systemvmtemplate/preseed.cfg deb2f94 
> 
> Diff: https://reviews.apache.org/r/21696/diff/
> 
> 
> Testing
> ---
> 
> Used the ACS tooling/procedure to build both systemvmtemplate and 
> systemvm64template.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: must read

[Daan Hoogland]

On Fri, Aug 8, 2014 at 12:27 PM, Rohit Yadav  wrote:
> Hi Daan,
>
> On 08-Aug-2014, at 12:05 pm, Daan Hoogland  wrote:
>
>> Rohit,
>>
>> A remark and a question:
...
>> Why insist on fast-forward? (In the git-flow document it is emphasised
>> that --no-ff should be used at all times)
>
> So, in my proposal I ask developers to merge release (or stable) branches to 
> master (or develop/feature branch) often (say couple of times in the day), 
> using --no-ff will generate a merge commit every time we do that. With 
> fast-forward we’ll get linear history so that’s why I keep insisting on it.
>
> IMO We should only use --no-ff only when we want to have git to track the 
> merge history (i.e. for someone to go and see what feature/branch got merged 
> and what work was done in that merge branch).

Right, I just committed two fixes that are now just commits on 4.4 and
would have shown with merge commits, proving I eat my own dogfood. I
must say I am really not sure what I prefer. Leo showed me another
example of the difference where a merge was done on a branch that had
grown since the branch-off. Let's define carefully what we need when.
Not everybody is going to be savvy on this within the community and a
clear "do this, don't do that" might save the day.

A linear history is maybe good for little fixes/hotfixes but for
bigger features you do want the merge commit so you see clearly the
sideway that was created during the implementation.

ok?

Re: must read

[Rohit Yadav]

Hi Daan,

On 08-Aug-2014, at 12:05 pm, Daan Hoogland  wrote:

> Rohit,
>
> A remark and a question:
> I would say merge and if not applicable cherry-pick. (to be sure that
> the optimal solution is used)

+1

> Why insist on fast-forward? (In the git-flow document it is emphasised
> that --no-ff should be used at all times)

So, in my proposal I ask developers to merge release (or stable) branches to 
master (or develop/feature branch) often (say couple of times in the day), 
using --no-ff will generate a merge commit every time we do that. With 
fast-forward we’ll get linear history so that’s why I keep insisting on it.

IMO We should only use --no-ff only when we want to have git to track the merge 
history (i.e. for someone to go and see what feature/branch got merged and what 
work was done in that merge branch).

Cheers.

>
> thanks, and thanks for seeing the first step to freedom so clearly,
> Daan
>
> On Fri, Aug 8, 2014 at 11:59 AM, Rohit Yadav  
> wrote:
>> Another note on this blog/workflow/idea:
>>
>> Say I’ve a bug for multiple ACS releases, the way our workflow should be to 
>> fix it on the earliest ACS release branch we want to support and then to the 
>> next ones, finally on master and then feature/personal branches. Example, 
>> you fix on 4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally 
>> master. One can use cherry-picking or merge with fast-forward whatever is 
>> applicable.
>>
>> Cheers.
>>
>> On 08-Aug-2014, at 10:25 am, Daan Hoogland  wrote:
>>
>>> And another thank you:
>>>
>>> 
>>> Long-running release branches for long-term support
>>>
>>> What are the main long-running branches in this model?
>>>
>>> We have a master branch – which in Subversion (SVN) terms you would
>>> call trunk – that is stable-ish. It is in a alpha/RC state.
>>> We have stable release branches for each product release we have to
>>> ship updates to.
>>>
>>> Commits always are merged upwards from older to newer branches. If a
>>> fix needs to be applied to stable branch 2.2 for example, a bug fix
>>> branch is created off the stable branch. First it gets merged back to
>>> that branch, and then that branch is merged upwards towards master.
>>> These chains of merges can be several branches long, but this
>>> operation is almost completely automated.
>>> 
>>>
>>> I think this most resembles what we want (source: the link about
>>> atlassian stash from
>>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>>>
>>> Daan
>>>
>>> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland  
>>> wrote:
 thanks Rohit,

 I had missed this one. It contains obligatory release management
 knowledge for every keyboard toucher that is allowed to use git:
 https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

 I think if we all read this and then study  a bit we don't need to
 discuss or branching model. It will become clear that we are in fact
 doing almost fine and need only small changes.

 --
 Daan
>>>
>>>
>>>
>>> --
>>> Daan
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure 
>> Support
>> CloudStack Bootcamp Training 
>> Courses
>>
>> This email and any attachments to it may be confidential and are intended 
>> solely for the use of the individual to whom it is addressed. Any views or 
>> opinions expressed are solely those of the author and do not necessarily 
>> represent those of Shape Blue Ltd or related companies. If you are not the 
>> intended recipient of this email, you must neither take any action based 
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if you believe you have received this email in error. Shape Blue Ltd is a 
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a 
>> company incorporated in India and is operated under license from Shape Blue 
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a 
>> company registered by The Republic of South Africa and is traded under 
>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

IaaS Cloud Design & Build

Re: must read (git.git workflow)

[Leo Simons]

git.git workflow is a logical superset of gitflow with shorter branch names. 
All the basic practices are the same. Unsurprisingly, perhaps :-)

The key difference is the use of long lived stable branches rather than 
per-release stable branches that wither & die off.

I would guess it’s a little easier to understand coming from current cloudstack 
practice.

This setup does require a little bit more git-fu to recover from mistakes, and 
periodic rewind/rebase of integration branches (git has a ‘proposal’ branch if 
I remember correctly that is `git reset` every now and then). Like most git 
man-pages it assumes you understand git pretty well :-). Of course only one 
person needs to do that.

I guess that may also be a good fit for cloudstack which is already used to the 
release manager announcing these kinds of coordinated shifts and doing branch 
maintenance.


cheers,


Leo

On Aug 8, 2014, at 9:46 AM, Daan Hoogland  wrote:
> I had missed this one. It contains obligatory release management
> knowledge for every keyboard toucher that is allowed to use git:
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> 
> I think if we all read this and then study  a bit we don't need to
> discuss or branching model. It will become clear that we are in fact
> doing almost fine and need only small changes.

Re: must read

[Daan Hoogland]

Rohit,

A remark and a question:
I would say merge and if not applicable cherry-pick. (to be sure that
the optimal solution is used)
Why insist on fast-forward? (In the git-flow document it is emphasised
that --no-ff should be used at all times)

thanks, and thanks for seeing the first step to freedom so clearly,
Daan

On Fri, Aug 8, 2014 at 11:59 AM, Rohit Yadav  wrote:
> Another note on this blog/workflow/idea:
>
> Say I’ve a bug for multiple ACS releases, the way our workflow should be to 
> fix it on the earliest ACS release branch we want to support and then to the 
> next ones, finally on master and then feature/personal branches. Example, you 
> fix on 4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally master. 
> One can use cherry-picking or merge with fast-forward whatever is applicable.
>
> Cheers.
>
> On 08-Aug-2014, at 10:25 am, Daan Hoogland  wrote:
>
>> And another thank you:
>>
>> 
>> Long-running release branches for long-term support
>>
>> What are the main long-running branches in this model?
>>
>> We have a master branch – which in Subversion (SVN) terms you would
>> call trunk – that is stable-ish. It is in a alpha/RC state.
>> We have stable release branches for each product release we have to
>> ship updates to.
>>
>> Commits always are merged upwards from older to newer branches. If a
>> fix needs to be applied to stable branch 2.2 for example, a bug fix
>> branch is created off the stable branch. First it gets merged back to
>> that branch, and then that branch is merged upwards towards master.
>> These chains of merges can be several branches long, but this
>> operation is almost completely automated.
>> 
>>
>> I think this most resembles what we want (source: the link about
>> atlassian stash from
>> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>>
>> Daan
>>
>> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland  
>> wrote:
>>> thanks Rohit,
>>>
>>> I had missed this one. It contains obligatory release management
>>> knowledge for every keyboard toucher that is allowed to use git:
>>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>>
>>> I think if we all read this and then study  a bit we don't need to
>>> discuss or branching model. It will become clear that we are in fact
>>> doing almost fine and need only small changes.
>>>
>>> --
>>> Daan
>>
>>
>>
>> --
>> Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.



-- 
Daan

Re: must read

[Rohit Yadav]

Another note on this blog/workflow/idea:

Say I’ve a bug for multiple ACS releases, the way our workflow should be to fix 
it on the earliest ACS release branch we want to support and then to the next 
ones, finally on master and then feature/personal branches. Example, you fix on 
4.1, then cherry-pick/fix to 4.2, then 4.3, 4.4 and finally master. One can use 
cherry-picking or merge with fast-forward whatever is applicable.

Cheers.

On 08-Aug-2014, at 10:25 am, Daan Hoogland  wrote:

> And another thank you:
>
> 
> Long-running release branches for long-term support
>
> What are the main long-running branches in this model?
>
> We have a master branch – which in Subversion (SVN) terms you would
> call trunk – that is stable-ish. It is in a alpha/RC state.
> We have stable release branches for each product release we have to
> ship updates to.
>
> Commits always are merged upwards from older to newer branches. If a
> fix needs to be applied to stable branch 2.2 for example, a bug fix
> branch is created off the stable branch. First it gets merged back to
> that branch, and then that branch is merged upwards towards master.
> These chains of merges can be several branches long, but this
> operation is almost completely automated.
> 
>
> I think this most resembles what we want (source: the link about
> atlassian stash from
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)
>
> Daan
>
> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland  wrote:
>> thanks Rohit,
>>
>> I had missed this one. It contains obligatory release management
>> knowledge for every keyboard toucher that is allowed to use git:
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>
>> I think if we all read this and then study  a bit we don't need to
>> discuss or branching model. It will become clear that we are in fact
>> doing almost fine and need only small changes.
>>
>> --
>> Daan
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Build failed in Jenkins: simulator-hotfix-trigger #16

[jenkins]

See 

--
[...truncated 7101 lines...]
[WARNING] The requested profile "simulator" could not be activated because it 
does not exist.
[simulator-hotfix-trigger] $ mvn -P developer -pl developer -Ddeploydb-simulator
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.4.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[WARNING] Ignoring missing properties file: 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO] 
[INFO] >>> exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer >>>
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-developer ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] <<< exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer <<<
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema-simulator) @ 
cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.4.1-SNAPSHOT/cloud-developer-4.4.1-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 21.385s
[INFO] Finished at: Fri Aug 08 05:00:58 EDT 2014
[INFO] Final Memory: 39M/196M
[INFO] 
[simulator-hotfix-trigger] $ /bin/bash -x /tmp/hudson7001705075217727141.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=25713
+ '[' 0 -lt 44 ']'
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management s

Re: must read

[Rohit Yadav]

Hi Daan,

On 08-Aug-2014, at 10:25 am, Daan Hoogland  wrote:

> And another thank you:
>
> 
> Long-running release branches for long-term support
>
> What are the main long-running branches in this model?
>
> We have a master branch – which in Subversion (SVN) terms you would
> call trunk – that is stable-ish. It is in a alpha/RC state.
> We have stable release branches for each product release we have to
> ship updates to.
>
> Commits always are merged upwards from older to newer branches. If a
> fix needs to be applied to stable branch 2.2 for example, a bug fix
> branch is created off the stable branch. First it gets merged back to
> that branch, and then that branch is merged upwards towards master.
> These chains of merges can be several branches long, but this
> operation is almost completely automated.
> 
>
> I think this most resembles what we want (source: the link about
> atlassian stash from
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)

Exactly, thanks for reading it!

This is “what" my proposal thread is about, to bring this in ACS release 
workflow.
I’ll start a vote on this next week, once we have a healthy discussion around 
it.

Cheers.

>
> Daan
>
> On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland  wrote:
>> thanks Rohit,
>>
>> I had missed this one. It contains obligatory release management
>> knowledge for every keyboard toucher that is allowed to use git:
>> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>
>> I think if we all read this and then study  a bit we don't need to
>> discuss or branching model. It will become clear that we are in fact
>> doing almost fine and need only small changes.
>>
>> --
>> Daan
>
>
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Regarding CLOUDSTACK-6169

[Namita Chaudhari]

Hi,

I was going through the 4.4 issue list and came across an issue
https://issues.apache.org/jira/browse/CLOUDSTACK-6169

​I tried reproducing the issue and moved a VM between accounts via
'assignVirtualMachine' and observed that the resource_tags table in the
database is not getting updated. The tag points to the old account/domainid.
Is there any other place where the associated resource tags shows the old
account/domainid other than database?​


Thanks and Regards,
-- 

*Namita Chaudhari* ● Engineer - Product Development ● SunGard Availability
Services, India. ● 2nd Floor, Wing 4, Cluster D, MIDC Kharadi Knowledge
Park, Pune - 411 014 ● Email: namita.chaudh...@sungardas.com
 ● www.sungardas.in



[image: Description: cid:image019.png@01CF48EC.6617C7F0]  [image:
Description: cid:image020.png@01CF48EC.6617C7F0]  [image: Description:
cid:image021.png@01CF48EC.6617C7F0]  [image: Description:
cid:image022.png@01CF48EC.6617C7F0]  [image: Description:
cid:image023.png@01CF48EC.6617C7F0]  [image: Description:
cid:image024.png@01CF48EC.6617C7F0]

Re: [CLOUDSTACK-6114][GSoC] End of second term approaching

[Sebastien Goasguen]

Ian,

This is terrific. I hope folks will take time to check all the scenarios you 
have covered.

This will make testing cloudstack super easy as well as remove the need for 
devcloud (which tends to break in the latest releases).

Great work,

-sebastien

On Aug 7, 2014, at 4:58 PM, Ian Duffy  wrote:

> Hi All,
> 
> Giving a very brief overview of everything that has been done. If any
> questions or expansion is wanted please reply back.
> 
> TL;DR "vagrant up" for: Cloudstack basic zone from source, Cloudstack
> advanced zone from source, Cloudstack Simulator, Cloudstack binary
> installation and configuration. All provisioning/setup done by chef.
> 
> VagrantFiles / Example usage: https://github.com/imduffy15/GSoC-2014
> 
> Chef recipe: https://github.com/imduffy15/cookbook_cloudstack
> 
> 
> *CLOUDSTACK-6114 - GSoC: Create config management recipes to install
> CloudStack. ( https://issues.apache.org/jira/browse/CLOUDSTACK-6114
>  ) *
> 
> *"Devcloud" basic (https://github.com/imduffy15/GSoC-2014/tree/master/basic
> )*
> 
> Re-jigged version of devcloud using vagrant and chef.
> 
> Made up of:
> 1) "Management" VM. Acts as NFS, MySQL and a Gateway.
> 2)  XenServer VM. (Built using packer
> https://github.com/imduffy15/packer-xenserver)
> 
> Cloudstack is ran on the developers machine.
> Marvin is also ran on the developers machine with a supplied configuration
> for a basic zone.
> 
> MySQL is forwarded from the VM to localhost 3306. This means deploydb works
> without issue.
> 
> Unlike the old implementation, the VMs brought up by cloudstack have
> internet access.
> 
> VagrantFile and Marvin config can be found at
> https://github.com/imduffy15/GSoC-2014/tree/master/basic
> 
> *"Devcloud" advanced
> (https://github.com/imduffy15/GSoC-2014/tree/master/advanced
> )*
> 
> Extension of the above described "Devcloud" basic.
> 
> This extension introduces more virtual network cards. This allows for an
> advanced zone to be deployed.
> 
> Again, Cloudstack and Marvin will the ran on the developers machine. A
> marvin config file has been supplied for this.
> 
> VagrantFile and Marvin config can be found at
> https://github.com/imduffy15/GSoC-2014/tree/master/advanced
> 
>  Note 
> *The ttylinux_vhd supplied with devcloud has hard coded dns servers in
> resolv.conf.*
> 
> *These are not overwrote by the DHCP lease.*
> 
> *As a side project and workaround I have supplied Debian
> images http://dl.openvm.eu/cloudstack/debian/vanilla/7/x86_64/
>  Thanks to Nux for
> hosting and exoscale supplying boxes to build the images automatically. *
> 
> *Simulator (https://github.com/imduffy15/GSoC-2014/tree/master/simulator
> )*
> 
> This is a single virtual machine. All development tools and mysql are
> installed onto this box. A specified version of Cloudstack source is
> downloaded and compiled.
> 
> The simulator is booted, when completed marvin is executed on the box and
> the simulator is configured.
> 
> Takes a bit of time to come up... faster solution below.
> 
> VagrantFile at https://github.com/imduffy15/GSoC-2014/tree/master/simulator
> 
> *Simulator fast
> (https://github.com/imduffy15/GSoC-2014/tree/master/simulator-fast
> )*
> 
> This is a single virtual machine that supplies the cloudstack simulator. I*t
> comes up in however fast you can download the 128mb cloud-client-ui war.*
> 
> This is restricted to running the cloud-client.war I have supplied (based
> of 4.4). This is due to inflexibility around the database. I was hoping to
> just use the basic create-schema files and let the upgrade handle the rest
> however the upgrade fails. If anybody has a solution to this I would love
> to hear it.
> 
> This works by taking the cloud-client.war and deploying it with jetty.
> 
> VagrantFile at
> https://github.com/imduffy15/GSoC-2014/tree/master/simulator-fast
> 
> *Binary Installation
> (https://github.com/imduffy15/GSoC-2014/tree/master/binary-installation
> )*
> 
> Takes the Cloudstack RPMs, installs them and all requirements.
> 
> Installs marvin and executes it against a configuration supplied within the
> chef recipe to configure your cloud.
> 
> The hypervisor is to be considered a static node. In a real world
> environment it must exist before executing the chef recipe.
> 
> For demoing and testing purposes a VagrantFile for this can be found at
> https://github.com/imduffy15/GSoC-2014/tree/master/binary-installation
> 
>  Note 
> 
> All of the above described boxes are not baked. They are fried on boot up
> using chef, this means you can use the recipe outsi

Re: [GSoC] End of second term approaching

[Sebastien Goasguen]

Great job Darren,

I am excited to see VPC support in ec2stack and equally excited to see gcloud 
compatibility with stack (in addition to gcutil).

You are in the last stretch, getting snapshots in ec2stack would be great.

-sebastien

On Aug 7, 2014, at 3:23 PM, Darren Brogan  wrote:

> Hi all,
> 
> With the second term of GSOC coming to an end I thought I'd update you on
> what I've been doing since my last email.
> 
> Ec2stack user profiles can now be configured / used in a similar way to
> gstack. You can configure a profile of your choice with the optional -p or
> --profile flag at configuration time.
> 
>$ ec2stack-configure -p exampleprofile
> 
> And run ec2stack with that profile configuration.
> 
>$ ec2stack -p exampleprofile
> 
> Ec2stack now has support for VPC operations. CreateVpc, DeleteVpc &
> DescribeVpc actions were all added. To be able to use VPC actions ec2stack
> will have to be configured with an advanced zone.
> 
>$ ec2stack-configure -a True
> 
> Snapshot support is being worked on on a branch called snapshot_support[1],
> this should be completed shortly.
> 
> In terms of gstack, it was modified to allow it to work with the latest
> release of the google_cloud_sdk. This means the setup of gstack will be
> slightly different than it used to be. Check out the user guide[2] on the
> wiki for more information.
> 
> [1] https://github.com/BroganD1993/ec2stack/tree/snapshot_support
> [2] https://github.com/NOPping/gstack/wiki/User-Guide
> 
> If you have any questions about either ec2stack or gstack don't hesitate
> get in touch.
> 
> Thanks,
> Darren

Re: List APIs Behavior

[Gaurav Aradhye]

Thanks Daan. I will update the page.

Regards,
Gaurav


On Fri, Aug 8, 2014 at 2:20 PM, Daan Hoogland 
wrote:

> Gaurav,
>
> I think you are now pointing at one of the qualities of our API that
> need to be addressed in 5.0 [1]. I may be wrong but I don't think a
> standard behavior in these cases is defined and every list api has a
> choice of several conventions to folow. Feel free to define what the
> behavior should be in a future version by editing [1] :)
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes
>
> On Fri, Aug 8, 2014 at 10:44 AM, Gaurav Aradhye
>  wrote:
> > Hello,
> >
> > Can somebody please address this query?
> >
> > Regards,
> > Gaurav
> >
> >
> > On Thu, Aug 7, 2014 at 10:23 PM, Gaurav Aradhye <
> gaurav.arad...@clogeny.com>
> > wrote:
> >
> >> I want to understand the output of the list APIs when the entity is not
> >> present / deleted. Suppose I create an account, create a network within
> it
> >> and acquire a public IP address in the network.
> >>
> >> 1) ListPublicIpAddresses  - public ip id passed, returns public IP
> >> 2) ListPublicIpAddresses - account, domainid passed, returns public IP
> >>
> >> Now I delete the public IP (Disassociate).
> >>
> >> After this operation, I expect following results:
> >> 1) ListPublicIpAddreses - account,domain id passed, result: None
> (assuming
> >> there was only one)
> >> 2) ListPublicIpAddresses - public ip id passed, I expect exception here
> >> because the id must have been removed from DB. But I get "None" as
> result
> >> here.
> >>
> >> If I get None, then can I assume that id is still present in DB but it
> is
> >> marked as obsolete?
> >>
> >> When can I expect an exception in return? And when can I expect None?
> >> Ideally, when we search by Id, then exception should be thrown and when
> we
> >> expect by passing account/domainid/projectid/networkid etc, then None
> >> should be returned. Do all List APIs follow a similar guideline?
> >>
> >> Regards,
> >> Gaurav
> >>
>
>
>
> --
> Daan
>

Re: List APIs Behavior

[Daan Hoogland]

Gaurav,

I think you are now pointing at one of the qualities of our API that
need to be addressed in 5.0 [1]. I may be wrong but I don't think a
standard behavior in these cases is defined and every list api has a
choice of several conventions to folow. Feel free to define what the
behavior should be in a future version by editing [1] :)

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes

On Fri, Aug 8, 2014 at 10:44 AM, Gaurav Aradhye
 wrote:
> Hello,
>
> Can somebody please address this query?
>
> Regards,
> Gaurav
>
>
> On Thu, Aug 7, 2014 at 10:23 PM, Gaurav Aradhye 
> wrote:
>
>> I want to understand the output of the list APIs when the entity is not
>> present / deleted. Suppose I create an account, create a network within it
>> and acquire a public IP address in the network.
>>
>> 1) ListPublicIpAddresses  - public ip id passed, returns public IP
>> 2) ListPublicIpAddresses - account, domainid passed, returns public IP
>>
>> Now I delete the public IP (Disassociate).
>>
>> After this operation, I expect following results:
>> 1) ListPublicIpAddreses - account,domain id passed, result: None (assuming
>> there was only one)
>> 2) ListPublicIpAddresses - public ip id passed, I expect exception here
>> because the id must have been removed from DB. But I get "None" as result
>> here.
>>
>> If I get None, then can I assume that id is still present in DB but it is
>> marked as obsolete?
>>
>> When can I expect an exception in return? And when can I expect None?
>> Ideally, when we search by Id, then exception should be thrown and when we
>> expect by passing account/domainid/projectid/networkid etc, then None
>> should be returned. Do all List APIs follow a similar guideline?
>>
>> Regards,
>> Gaurav
>>



-- 
Daan

Re: [DB-CHANGE] Infrastructure tab fails to load with db exception

[Daan Hoogland]

Ah
Mike, I now see what you where commenting on. It seemed strange that
you would urge to send out a mail in the actual thread that was send
out as you so desire. 8}

On Fri, Aug 8, 2014 at 10:33 AM, Saksham Srivastava
 wrote:
> Agree, we should be using the same tag.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/mail+tags+to+use+to+help+each+other
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Thursday, August 7, 2014 11:29 PM
> To: dev@cloudstack.apache.org
> Cc: Alena Prokharchyk
> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db exception
>
> That is true. It was not my intent to address that problem, though. I was 
> simply commenting on the question of whether we should continue to use the 
> [DB-CHANGE] e-mail tag (I believe we should).
>
>
> On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi > wrote:
>
>> Don’t you think we are overlooking the actual problem of handle
>> migrations on the development branch?
>>
>> ~Rajani
>>
>>
>>
>> On 07-Aug-2014, at 12:21 am, Mike Tutkowski
>> 
>> wrote:
>>
>> > Yep, I agree.
>> >
>> > I guess my point was that a manually created e-mail should still be
>> issued
>> > by the developer.
>> >
>> > On Wednesday, August 6, 2014, Alena Prokharchyk <
>> > alena.prokharc...@citrix.com> wrote:
>> >
>> >> I doubt we can fully automate this one, Mike, for the case when
>> >> data migration/modification is involved (.java file is modified in
>> >> this
>> case).
>> >> Only for the changes to .sql files we can automate the
>> >> instructions. For data modification, the developer who’s made the
>> >> changes, still needs to provide the instructions on the dev list.
>> >>
>> >> -Alena.
>> >>
>> >>  From: Mike Tutkowski > >> >
>> >> Date: Wednesday, August 6, 2014 at 11:33 AM
>> >> To: "dev@cloudstack.apache.org
>> >> " <
>> >> dev@cloudstack.apache.org
>> >> >
>> >> Cc: Alena Prokharchyk > >> >,
>> Koushik
>> >> Das > >> >
>> >> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db
>> >> exception
>> >>
>> >> What about the details for updating your DB?
>> >>
>> >> If we just receive a general e-mail notification, then each dev
>> >> will independently have to examine the DB changes to come up with a
>> workaround
>> >> to keep his/her current env running properly after a code update.
>> >>
>> >> On Wednesday, August 6, 2014, Nitin Mehta > >> > wrote:
>> >>
>> >>> Agreed. Added that information in the bug.
>> >>>
>> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" <
>> alena.prokharc...@citrix.com>
>> >>> wrote:
>> >>>
>>  Thank you, Nitin. I think we should add one more item to the
>>  things
>> that
>>  the script checks: modifications to the older upgrade paths
>>  shouldn¹t
>> be
>>  allowed. If we already released 4.4, db upgrade changes should be
>> >>> accepted
>>  only to 4.4-4.5 scripts. If someone makes the changes to, say
>>  4.3-4.4,
>> >>> the
>>  mailing list should be notified, and the changes have to be reverted.
>> 
>>  -Alena.
>> 
>>  On 8/6/14, 11:03 AM, "Nitin Mehta"  wrote:
>> 
>> > This should be automated. We can't rely on the good intentions
>> > of
>> dev.
>> > All we need is a script which checks changes in the schema/java
>> Upgrade
>> > files and to sends a notification to the dev list.
>> > Filed a bug for this -
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-7273
>> >
>> >
>> > Thanks,
>> > -Nitin
>> >
>> > On 06/08/14 5:28 AM, "Koushik Das"  wrote:
>> >
>> >> Thanks Saksham. This fixed the initial issue. But I noticed a
>> >> new
>> one,
>> >> after destroying the last VR if you select the infra view it
>> >> again results in exception. Not sure if anything else needs to be 
>> >> fixed.
>> >>
>> >> -Original Message-
>> >> From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com]
>> >> Sent: Wednesday, 6 August 2014 3:37 PM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: [DB-CHANGE] Infrastructure tab fails to load with db
>> exception
>> >>
>> >> I remember we used to follow the practice of informing others
>> >> in
>> case
>> >>> db
>> >> changes are committed, but we do not do it anymore.
>> >> In case you are on dev setup on master branch post the
>> >> following
>> commit
>> >> :
>> >> commit b9d834e83854009483f6d061f9996e5ffaa9b883
>> >> Author: Nitin Mehta 
>> >> Date:   Tue Aug 5 17:29:34 2014 -0700
>> >> CLOUDSTACK-4200: listSystemVMs API and listRouters API should
>> >> return hypervisor property since dynamic scaling is not enabled
>> >> for all the hypervisors and that action can be showed only for
>> >> the hypervisors t
>> >>
>> >> Update your database with :
>> >>
>> >> DROP VIEW IF EXISTS `cloud`.`domain_router_view`; CREATE VIEW
>> >> `cloud`.`domain_router_view` AS
>> >>   select
>> >> 

Re: List APIs Behavior

[Gaurav Aradhye]

Hello,

Can somebody please address this query?

Regards,
Gaurav


On Thu, Aug 7, 2014 at 10:23 PM, Gaurav Aradhye 
wrote:

> I want to understand the output of the list APIs when the entity is not
> present / deleted. Suppose I create an account, create a network within it
> and acquire a public IP address in the network.
>
> 1) ListPublicIpAddresses  - public ip id passed, returns public IP
> 2) ListPublicIpAddresses - account, domainid passed, returns public IP
>
> Now I delete the public IP (Disassociate).
>
> After this operation, I expect following results:
> 1) ListPublicIpAddreses - account,domain id passed, result: None (assuming
> there was only one)
> 2) ListPublicIpAddresses - public ip id passed, I expect exception here
> because the id must have been removed from DB. But I get "None" as result
> here.
>
> If I get None, then can I assume that id is still present in DB but it is
> marked as obsolete?
>
> When can I expect an exception in return? And when can I expect None?
> Ideally, when we search by Id, then exception should be thrown and when we
> expect by passing account/domainid/projectid/networkid etc, then None
> should be returned. Do all List APIs follow a similar guideline?
>
> Regards,
> Gaurav
>

Re: Review Request 22939: CLOUDSTACK-6460 - CLVM primary storage migration fails due to incorrect identification of source format.

[daan Hoogland]

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


seems fine except for the trailing whitespace. branch hotfix/4.4-6460 created.

- daan Hoogland


On July 23, 2014, 4:30 p.m., Simon Weller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22939/
> ---
> 
> (Updated July 23, 2014, 4:30 p.m.)
> 
> 
> Review request for cloudstack, edison su and Marcus Sorensen.
> 
> 
> Bugs: CLOUDSTACK-6460
> https://issues.apache.org/jira/browse/CLOUDSTACK-6460
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Addresses CLOUDSTACK-6460.
> CLVM storage source was being identified as QCOW2, rather than raw when 
> attempting a primary storage migration.  This caused the migration to fail 
> when qemu-img attempted to image the file back from secondary storage to the 
> new primary storage selected. This patch forces CLVM to be treated as RAW 
> while continuing to acquire sourceFormat from other storage types via 
> disk.getFormat();
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  ecf3e08 
> 
> Diff: https://reviews.apache.org/r/22939/diff/
> 
> 
> Testing
> ---
> 
> Stop VM. Migrate from one primary storage to another. Migration completes 
> successfully. Start vm.
> 
> 
> Thanks,
> 
> Simon Weller
> 
>

Re: issues remaining for 4.4.1

[Daan Hoogland]

I have created hotfix/4.4-6460 and am running a validation build on
it, if no feedback before sunday night I will merge and include it.

On Thu, Aug 7, 2014 at 10:27 PM, Daan Hoogland  wrote:
> Marcus, Edison,
>
> Can you have a look? It looks alright by me, but I have no time/env to test.
>
> thanks,
> Daan
>
> On Thu, Aug 7, 2014 at 3:31 PM, Simon Weller  wrote:
>> Daan,
>>
>> I have a patch in reviewboard for CLOUDSTACK-6460.
>>
>> https://reviews.apache.org/r/22939/
>>
>> - Si
>> 
>> From: Daan Hoogland 
>> Sent: Thursday, August 07, 2014 3:53 AM
>> To: dev
>> Subject: issues remaining for 4.4.1
>>
>> H,
>>
>> have a look at 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6358?filter=12328007
>>
>> It is a disappointing 280+ list of issues with 4.4 but I think a lot
>> of them can be marked as won't solve, future releases or resolved.
>>
>> Please help me weed through these.
>>
>> thanks,
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: Review Request 22939: CLOUDSTACK-6460 - CLVM primary storage migration fails due to incorrect identification of source format.

[ASF Subversion and Git Services]

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


Commit 536ec0578111cf85e93122deaf9a95270d66f778 in cloudstack's branch 
refs/heads/hotfix/4.4-6460 from Simon Weller
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=536ec05 ]

CLOUDSTACK-6460 - Force RAW when storage type is CLVM. Fixes primary storage 
migration for CLVM

Signed-off-by: Daan Hoogland 


- ASF Subversion and Git Services


On July 23, 2014, 4:30 p.m., Simon Weller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22939/
> ---
> 
> (Updated July 23, 2014, 4:30 p.m.)
> 
> 
> Review request for cloudstack, edison su and Marcus Sorensen.
> 
> 
> Bugs: CLOUDSTACK-6460
> https://issues.apache.org/jira/browse/CLOUDSTACK-6460
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Addresses CLOUDSTACK-6460.
> CLVM storage source was being identified as QCOW2, rather than raw when 
> attempting a primary storage migration.  This caused the migration to fail 
> when qemu-img attempted to image the file back from secondary storage to the 
> new primary storage selected. This patch forces CLVM to be treated as RAW 
> while continuing to acquire sourceFormat from other storage types via 
> disk.getFormat();
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  ecf3e08 
> 
> Diff: https://reviews.apache.org/r/22939/diff/
> 
> 
> Testing
> ---
> 
> Stop VM. Migrate from one primary storage to another. Migration completes 
> successfully. Start vm.
> 
> 
> Thanks,
> 
> Simon Weller
> 
>

RE: [DB-CHANGE] Infrastructure tab fails to load with db exception

[Saksham Srivastava]

Agree, we should be using the same tag.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/mail+tags+to+use+to+help+each+other

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Thursday, August 7, 2014 11:29 PM
To: dev@cloudstack.apache.org
Cc: Alena Prokharchyk
Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db exception

That is true. It was not my intent to address that problem, though. I was 
simply commenting on the question of whether we should continue to use the 
[DB-CHANGE] e-mail tag (I believe we should).


On Wed, Aug 6, 2014 at 10:04 PM, Rajani Karuturi  wrote:

> Don’t you think we are overlooking the actual problem of handle 
> migrations on the development branch?
>
> ~Rajani
>
>
>
> On 07-Aug-2014, at 12:21 am, Mike Tutkowski 
> 
> wrote:
>
> > Yep, I agree.
> >
> > I guess my point was that a manually created e-mail should still be
> issued
> > by the developer.
> >
> > On Wednesday, August 6, 2014, Alena Prokharchyk < 
> > alena.prokharc...@citrix.com> wrote:
> >
> >> I doubt we can fully automate this one, Mike, for the case when 
> >> data migration/modification is involved (.java file is modified in 
> >> this
> case).
> >> Only for the changes to .sql files we can automate the 
> >> instructions. For data modification, the developer who’s made the 
> >> changes, still needs to provide the instructions on the dev list.
> >>
> >> -Alena.
> >>
> >>  From: Mike Tutkowski  >> >
> >> Date: Wednesday, August 6, 2014 at 11:33 AM
> >> To: "dev@cloudstack.apache.org
> >> " < 
> >> dev@cloudstack.apache.org 
> >> >
> >> Cc: Alena Prokharchyk  >> >,
> Koushik
> >> Das  >> >
> >> Subject: Re: [DB-CHANGE] Infrastructure tab fails to load with db 
> >> exception
> >>
> >> What about the details for updating your DB?
> >>
> >> If we just receive a general e-mail notification, then each dev 
> >> will independently have to examine the DB changes to come up with a
> workaround
> >> to keep his/her current env running properly after a code update.
> >>
> >> On Wednesday, August 6, 2014, Nitin Mehta  >> > wrote:
> >>
> >>> Agreed. Added that information in the bug.
> >>>
> >>> On 06/08/14 11:08 AM, "Alena Prokharchyk" <
> alena.prokharc...@citrix.com>
> >>> wrote:
> >>>
>  Thank you, Nitin. I think we should add one more item to the 
>  things
> that
>  the script checks: modifications to the older upgrade paths 
>  shouldn¹t
> be
>  allowed. If we already released 4.4, db upgrade changes should be
> >>> accepted
>  only to 4.4-4.5 scripts. If someone makes the changes to, say 
>  4.3-4.4,
> >>> the
>  mailing list should be notified, and the changes have to be reverted.
> 
>  -Alena.
> 
>  On 8/6/14, 11:03 AM, "Nitin Mehta"  wrote:
> 
> > This should be automated. We can't rely on the good intentions 
> > of
> dev.
> > All we need is a script which checks changes in the schema/java
> Upgrade
> > files and to sends a notification to the dev list.
> > Filed a bug for this -
> > https://issues.apache.org/jira/browse/CLOUDSTACK-7273
> >
> >
> > Thanks,
> > -Nitin
> >
> > On 06/08/14 5:28 AM, "Koushik Das"  wrote:
> >
> >> Thanks Saksham. This fixed the initial issue. But I noticed a 
> >> new
> one,
> >> after destroying the last VR if you select the infra view it 
> >> again results in exception. Not sure if anything else needs to be 
> >> fixed.
> >>
> >> -Original Message-
> >> From: Saksham Srivastava [mailto:saksham.srivast...@citrix.com]
> >> Sent: Wednesday, 6 August 2014 3:37 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: [DB-CHANGE] Infrastructure tab fails to load with db
> exception
> >>
> >> I remember we used to follow the practice of informing others 
> >> in
> case
> >>> db
> >> changes are committed, but we do not do it anymore.
> >> In case you are on dev setup on master branch post the 
> >> following
> commit
> >> :
> >> commit b9d834e83854009483f6d061f9996e5ffaa9b883
> >> Author: Nitin Mehta 
> >> Date:   Tue Aug 5 17:29:34 2014 -0700
> >> CLOUDSTACK-4200: listSystemVMs API and listRouters API should 
> >> return hypervisor property since dynamic scaling is not enabled 
> >> for all the hypervisors and that action can be showed only for 
> >> the hypervisors t
> >>
> >> Update your database with :
> >>
> >> DROP VIEW IF EXISTS `cloud`.`domain_router_view`; CREATE VIEW 
> >> `cloud`.`domain_router_view` AS
> >>   select
> >>   vm_instance.id id,
> >>   vm_instance.name name,
> >>   account.id account_id,
> >>   account.uuid account_uuid,
> >>   account.account_name account_name,
> >>   account.type account_type,
> >>   domain.id domain_id,
> >>   domain.uuid domain_uuid,
> >>   domain.name domain_name,
> >>   d

Re: must read

[Daan Hoogland]

And another thank you:


Long-running release branches for long-term support

What are the main long-running branches in this model?

We have a master branch – which in Subversion (SVN) terms you would
call trunk – that is stable-ish. It is in a alpha/RC state.
We have stable release branches for each product release we have to
ship updates to.

Commits always are merged upwards from older to newer branches. If a
fix needs to be applied to stable branch 2.2 for example, a bug fix
branch is created off the stable branch. First it gets merged back to
that branch, and then that branch is merged upwards towards master.
These chains of merges can be several branches long, but this
operation is almost completely automated.


I think this most resembles what we want (source: the link about
atlassian stash from
http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/)

Daan

On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland  wrote:
> thanks Rohit,
>
> I had missed this one. It contains obligatory release management
> knowledge for every keyboard toucher that is allowed to use git:
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> I think if we all read this and then study  a bit we don't need to
> discuss or branching model. It will become clear that we are in fact
> doing almost fine and need only small changes.
>
> --
> Daan



-- 
Daan

must read

[Daan Hoogland]

thanks Rohit,

I had missed this one. It contains obligatory release management
knowledge for every keyboard toucher that is allowed to use git:
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

I think if we all read this and then study  a bit we don't need to
discuss or branching model. It will become clear that we are in fact
doing almost fine and need only small changes.

-- 
Daan

Re: [VOTE] git workflow

[Daan Hoogland]

Rohit, this is not a git-flow or gitflow discussion. It seems to be at
times but it is not. It is a discussion about how to branch in our
repository. That discussion should not end, but maybe so in this
thread.

On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav  wrote:
> Hi all,
>
> Let’s end this discussion thread.
>
> I asked Vincent (nvie) and some friends from google and facebook on this and 
> all of them recommended that this is not for us; then I read the whole thread 
> again without prejudice or ego and I think it’s not for us though we should 
> pick up couple of good ideas from it:
>
> - git-flow was designed for only “forward” releases
> - git-flow does not support multiple concurrent and non-chronological 
> releases/support very well (no nvie documentation on how to do that)
>
> Instead, if you’re interested on such topic I started a proposal (inspired by 
> couple of workflows) on solving cherry-picking issue by adapting our 
> release/master workflow please have a look on that. Some good reads on other 
> git workflows we can get ideas from;
>
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my 
> new proposal uses this idea)
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this 
> at least once)
>
> PS. Let me know privately if you want me to forward you Vincent’s email
>
> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski  
> wrote:
>
>> This is what I was wondering about, as well. It seems all of our 'master'
>> problems become 'develop' problems.
>>
>> I do like the idea of merging versus cherry picking (as a general rule),
>> though.
>>
>>
>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>> Sebastian, addressing the following comment of yours
>>>
>>>
>>> "The main issue with master right now is that it moves really fast as a
>>> shared branch, people merge features without warning, we see regressions
>>> etc..
>>> By the time we release a major version, master has moved so much that it
>>> feels like starting over with the next release. It's almost as if we are
>>> forking our own software. CI alone (even if it were really good) will not
>>> fix this.”
>>>
>>>
>>> You will still have this problem. You cut the next release branch from the
>>> *develop branch, not from master. And the *develop branch will move with
>>> the same pace as the old master, after the release branch is cut. So
>>> “master moving really fast” problem would become “develop moving really
>>> fast”.
>>>
>>> The problems you’ve mentioned - people merge features without warning, we
>>> see regressions - can be fixed only with automation in place and the
>>> requirement to run this automation (CI/BVT) before the merge is done.
>>> Otherwise you are just shifting all existing problems from master to
>>> develop.
>>>
>>>
>>> -Alena.
>>>
>>>
>>>
>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>>>

 On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
  wrote:

>
>
> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>
>>
>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>>
>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>>> wrote:

 On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:

> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>  wrote:
>> Edison, thank you for raising the concern about the BVT/CI.
>> Somebody
>> mentioned earlier that we should separate git workflow
>> implementation from
>> the CI effort, but I do think we have to do in in conjunction.
>> Otherwise
>> what is the point in introducing staging/develop branch? If there
>> is
>> no
>> daily automation run verifying all the code merged from
>> hotFixes/feature
>> branches (and possibly reverting wrong checkins), we can as well
>> merge the
>> code directly to master.
>>
>
> Yes! - please.
> Doing this without CI as a gating factor buys us very little.
>
> --David

 David, can you clarify. Are you going to be against any change of git
 workflow until we get CI/BVT in place ?

>>>
>>> No, please don't take it that way.
>>> I understand Leo's point about Cherry-picking being for fruit, and not
>>> code. But, I don't think that the workflow changes I've seen proposed
>>> affect quality. So shifting for quality's sake doesn't make a lot of
>>> sense in my mind. They could be a component of fixing the quality
>>> problem.
>>>
>>> --David
>>
>> Agreed, the changes don't affect quality but should support a CI infra
>> that helps improves quality.
>>
>> I do think the changes provide
>>
>> -a stable master that represent released software
>
>
> You can always look at the latest release branch to get it,

>>>

Re: [VOTE] git workflow

[Daan Hoogland]

3 it should be made in a hotfix/4.4- branch and reviewed
and merged from there

On Fri, Aug 8, 2014 at 9:16 AM, Rajani Karuturi  wrote:
> A git workflow change will not solve the quality problems we have. They
> have to be dealt with independently. Just because we are changing the way
> we commit the code doesnt mean we wont have any quality issues introduced
> by the commits. It just ensures that issues/fixes are properly transferred
> to the next releases and we have a better way to understand where all the
> issue is fixed/or first seen.
>
> Yes the problems we have on master will shift to develop branch. But the
> workflow change is not intended to solve them. It cannot tell us how to
> write bug free code/ inform there are bugs.
>
> What is the problem with having stable master branch pointing to latest
> release? Any user/developer who wants to try out cloudstack, can just
> checkout code and deploy and gets a nice first impression. Without having
> to look at what is the latest release whether 4.4 is stable or 4.3.1 or
> 4.2. In my opinion thats a big advantage.
> At this point, we arent sure that if we pass BVT, then we can release the
> code. Though that can be the first step( See 4.4 for example.)
> When we reach such a point, then we can merge stuff to master as soon as
> they pass BVT. But, until then it has to be the released code in my opinion.
>
> Following git-flow doesnt mean we have to follow each and every aspect of
> it. Lets start with it and make any amendments as required to fit our way.
> As the git-flow says a fix from support branch should reach master through
> hotfix doesnt mean we have to follow the same. If you feel they havent
> diverged a lot and can be merged, that can be merged. The important thing
> being, if the bug is relevant for the next release, it should go to
> develop/master.
>
> Also, as leo already said earlier, cherry-picking in itself is not the
> devil. The tool exists for a reason and it has to be used when required.
> For example when you are backporting a fix from minor release(which has
> diverged a lot from master and doesn't make sense to merge)
>
>
> (The discussion[s] has been so long that I feel like I am repeating my self)
>
> we haven't planned 4.5 yet though the code freeze date is long gone. We
> don't have RM for it. We have to release 4.4.1 immediately(It is a hotfix).
> This discussion is masking everything else.
>
> As we all agree that we have to solve the cherry-picking issue we have, can
> we focus on that please? We can get back to staging/develop branch later.
> CI/BVT as and when they are available. step-by-step.
>
> Let us use our current model with minor change that no cherry-picking after
> the release branch is created. Lets just work on the release branch
> directly.
> 1. it should only contain bug fixes and any bug going to the branch should
> be discussed/notified on the dev list(preferably before you work on it).
> 2. It should be merged/committed to the release branch only after it passes
> BVT(whether you run it locally or let jenkins run it by creating a
> hotfix/CS-* branch).
>
> thoughts?
>
>
> On Fri, Aug 8, 2014 at 3:22 AM, Mike Tutkowski > wrote:
>
>> This is what I was wondering about, as well. It seems all of our 'master'
>> problems become 'develop' problems.
>>
>> I do like the idea of merging versus cherry picking (as a general rule),
>> though.
>>
>>
>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>> > Sebastian, addressing the following comment of yours
>> >
>> >
>> > "The main issue with master right now is that it moves really fast as a
>> > shared branch, people merge features without warning, we see regressions
>> > etc..
>> > By the time we release a major version, master has moved so much that it
>> > feels like starting over with the next release. It's almost as if we are
>> > forking our own software. CI alone (even if it were really good) will not
>> > fix this.”
>> >
>> >
>> > You will still have this problem. You cut the next release branch from
>> the
>> > *develop branch, not from master. And the *develop branch will move with
>> > the same pace as the old master, after the release branch is cut. So
>> > “master moving really fast” problem would become “develop moving really
>> > fast”.
>> >
>> > The problems you’ve mentioned - people merge features without warning, we
>> > see regressions - can be fixed only with automation in place and the
>> > requirement to run this automation (CI/BVT) before the merge is done.
>> > Otherwise you are just shifting all existing problems from master to
>> > develop.
>> >
>> >
>> > -Alena.
>> >
>> >
>> >
>> > On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>> >
>> > >
>> > >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>> > > wrote:
>> > >
>> > >>
>> > >>
>> > >> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>> > >>
>> > >>>
>> > >>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>> > >>>
>> >  On Thu, Aug 7

Re: [VOTE] git workflow

[Rohit Yadav]

Hi all,

Let’s end this discussion thread.

I asked Vincent (nvie) and some friends from google and facebook on this and 
all of them recommended that this is not for us; then I read the whole thread 
again without prejudice or ego and I think it’s not for us though we should 
pick up couple of good ideas from it:

- git-flow was designed for only “forward” releases
- git-flow does not support multiple concurrent and non-chronological 
releases/support very well (no nvie documentation on how to do that)

Instead, if you’re interested on such topic I started a proposal (inspired by 
couple of workflows) on solving cherry-picking issue by adapting our 
release/master workflow please have a look on that. Some good reads on other 
git workflows we can get ideas from;

http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows (my 
new proposal uses this idea)
https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html (read this 
at least once)

PS. Let me know privately if you want me to forward you Vincent’s email

On 07-Aug-2014, at 11:52 pm, Mike Tutkowski  
wrote:

> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>> Sebastian, addressing the following comment of yours
>>
>>
>> "The main issue with master right now is that it moves really fast as a
>> shared branch, people merge features without warning, we see regressions
>> etc..
>> By the time we release a major version, master has moved so much that it
>> feels like starting over with the next release. It's almost as if we are
>> forking our own software. CI alone (even if it were really good) will not
>> fix this.”
>>
>>
>> You will still have this problem. You cut the next release branch from the
>> *develop branch, not from master. And the *develop branch will move with
>> the same pace as the old master, after the release branch is cut. So
>> “master moving really fast” problem would become “develop moving really
>> fast”.
>>
>> The problems you’ve mentioned - people merge features without warning, we
>> see regressions - can be fixed only with automation in place and the
>> requirement to run this automation (CI/BVT) before the merge is done.
>> Otherwise you are just shifting all existing problems from master to
>> develop.
>>
>>
>> -Alena.
>>
>>
>>
>> On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>>
>>>
>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>>  wrote:
>>>


 On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:

>
> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>
>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>> wrote:
>>>
>>> On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>>>
 On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
  wrote:
> Edison, thank you for raising the concern about the BVT/CI.
> Somebody
> mentioned earlier that we should separate git workflow
> implementation from
> the CI effort, but I do think we have to do in in conjunction.
> Otherwise
> what is the point in introducing staging/develop branch? If there
> is
> no
> daily automation run verifying all the code merged from
> hotFixes/feature
> branches (and possibly reverting wrong checkins), we can as well
> merge the
> code directly to master.
>

 Yes! - please.
 Doing this without CI as a gating factor buys us very little.

 --David
>>>
>>> David, can you clarify. Are you going to be against any change of git
>>> workflow until we get CI/BVT in place ?
>>>
>>
>> No, please don't take it that way.
>> I understand Leo's point about Cherry-picking being for fruit, and not
>> code. But, I don't think that the workflow changes I've seen proposed
>> affect quality. So shifting for quality's sake doesn't make a lot of
>> sense in my mind. They could be a component of fixing the quality
>> problem.
>>
>> --David
>
> Agreed, the changes don't affect quality but should support a CI infra
> that helps improves quality.
>
> I do think the changes provide
>
> -a stable master that represent released software


 You can always look at the latest release branch to get it,
>>>
>>> Yes I know how to get to the latest released software.
>>>
>>> I actually don't have good answers for your questions but I think Nate's
>>> email (couple emails back) answers a lot of them.
>>>
 as we are
 planning to keep them around to support maintenance. From the developer
 stand point, I would be more interested in getting the latest stable
 code,
 not the latest stable release.
>>>
>>>

Re: [VOTE] git workflow

[Daan Hoogland]

I see a lot of confusion around the fact that the name of gitflow is
being used. What was proposed was a model that could be supported by
the tool gitflow, not a workflow exactly as gitflow 'prescribes' it.
If we forget about gitflow for a moment and look at the branching
model that we want we all agree.

For instance the idea of a shift of our current master problems to
develop. it is there but half of the problems are shifted beyond
develop onto all those branches that we are going to create. develop
is going to suffer at times but it will keep the trouble away from
master, as it won't be merged when not passing bvt/ci.

In gitflow master is only for releases, in our model for all potential
major.minor releases, even if we don't release them. The only ones
that won't be on there are the conflicting bugfix releases.

As for the problem 'branch moving really fast', we can ask to only
merge to develop/master if the feature branch passes some test and
make it a committer responsibility to guard this. I think we have or
can make automatic records of passing or failing of feature branches.
this would be how we mitigate the second half of the problems, the
pre-merging regression ones. For now we would rely on each other but
that will alter.

On Thu, Aug 7, 2014 at 11:52 PM, Mike Tutkowski
 wrote:
> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>> Sebastian, addressing the following comment of yours
>>
>>
>> "The main issue with master right now is that it moves really fast as a
>> shared branch, people merge features without warning, we see regressions
>> etc..
>> By the time we release a major version, master has moved so much that it
>> feels like starting over with the next release. It's almost as if we are
>> forking our own software. CI alone (even if it were really good) will not
>> fix this.”
>>
>>
>> You will still have this problem. You cut the next release branch from the
>> *develop branch, not from master. And the *develop branch will move with
>> the same pace as the old master, after the release branch is cut. So
>> “master moving really fast” problem would become “develop moving really
>> fast”.
>>
>> The problems you’ve mentioned - people merge features without warning, we
>> see regressions - can be fixed only with automation in place and the
>> requirement to run this automation (CI/BVT) before the merge is done.
>> Otherwise you are just shifting all existing problems from master to
>> develop.
>>
>>
>> -Alena.
>>
>>
>>
>> On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
>>
>> >
>> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>> > wrote:
>> >
>> >>
>> >>
>> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
>> >>
>> >>>
>> >>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
>> >>>
>>  On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen 
>>  wrote:
>> >
>> > On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
>> >
>> >> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>> >>  wrote:
>> >>> Edison, thank you for raising the concern about the BVT/CI.
>> >>>Somebody
>> >>> mentioned earlier that we should separate git workflow
>> >>> implementation from
>> >>> the CI effort, but I do think we have to do in in conjunction.
>> >>> Otherwise
>> >>> what is the point in introducing staging/develop branch? If there
>> >>>is
>> >>> no
>> >>> daily automation run verifying all the code merged from
>> >>> hotFixes/feature
>> >>> branches (and possibly reverting wrong checkins), we can as well
>> >>> merge the
>> >>> code directly to master.
>> >>>
>> >>
>> >> Yes! - please.
>> >> Doing this without CI as a gating factor buys us very little.
>> >>
>> >> --David
>> >
>> > David, can you clarify. Are you going to be against any change of git
>> > workflow until we get CI/BVT in place ?
>> >
>> 
>>  No, please don't take it that way.
>>  I understand Leo's point about Cherry-picking being for fruit, and not
>>  code. But, I don't think that the workflow changes I've seen proposed
>>  affect quality. So shifting for quality's sake doesn't make a lot of
>>  sense in my mind. They could be a component of fixing the quality
>>  problem.
>> 
>>  --David
>> >>>
>> >>> Agreed, the changes don't affect quality but should support a CI infra
>> >>> that helps improves quality.
>> >>>
>> >>> I do think the changes provide
>> >>>
>> >>> -a stable master that represent released software
>> >>
>> >>
>> >> You can always look at the latest release branch to get it,
>> >
>> >Yes I know how to get to the latest released software.
>> >
>> >I actually don't have good answers for your questions but I think Nate's
>> >email 

Re: [VOTE] git workflow

[Rajani Karuturi]

A git workflow change will not solve the quality problems we have. They
have to be dealt with independently. Just because we are changing the way
we commit the code doesnt mean we wont have any quality issues introduced
by the commits. It just ensures that issues/fixes are properly transferred
to the next releases and we have a better way to understand where all the
issue is fixed/or first seen.

Yes the problems we have on master will shift to develop branch. But the
workflow change is not intended to solve them. It cannot tell us how to
write bug free code/ inform there are bugs.

What is the problem with having stable master branch pointing to latest
release? Any user/developer who wants to try out cloudstack, can just
checkout code and deploy and gets a nice first impression. Without having
to look at what is the latest release whether 4.4 is stable or 4.3.1 or
4.2. In my opinion thats a big advantage.
At this point, we arent sure that if we pass BVT, then we can release the
code. Though that can be the first step( See 4.4 for example.)
When we reach such a point, then we can merge stuff to master as soon as
they pass BVT. But, until then it has to be the released code in my opinion.

Following git-flow doesnt mean we have to follow each and every aspect of
it. Lets start with it and make any amendments as required to fit our way.
As the git-flow says a fix from support branch should reach master through
hotfix doesnt mean we have to follow the same. If you feel they havent
diverged a lot and can be merged, that can be merged. The important thing
being, if the bug is relevant for the next release, it should go to
develop/master.

Also, as leo already said earlier, cherry-picking in itself is not the
devil. The tool exists for a reason and it has to be used when required.
For example when you are backporting a fix from minor release(which has
diverged a lot from master and doesn't make sense to merge)


(The discussion[s] has been so long that I feel like I am repeating my self)

we haven't planned 4.5 yet though the code freeze date is long gone. We
don't have RM for it. We have to release 4.4.1 immediately(It is a hotfix).
This discussion is masking everything else.

As we all agree that we have to solve the cherry-picking issue we have, can
we focus on that please? We can get back to staging/develop branch later.
CI/BVT as and when they are available. step-by-step.

Let us use our current model with minor change that no cherry-picking after
the release branch is created. Lets just work on the release branch
directly.
1. it should only contain bug fixes and any bug going to the branch should
be discussed/notified on the dev list(preferably before you work on it).
2. It should be merged/committed to the release branch only after it passes
BVT(whether you run it locally or let jenkins run it by creating a
hotfix/CS-* branch).

thoughts?


On Fri, Aug 8, 2014 at 3:22 AM, Mike Tutkowski  wrote:

> This is what I was wondering about, as well. It seems all of our 'master'
> problems become 'develop' problems.
>
> I do like the idea of merging versus cherry picking (as a general rule),
> though.
>
>
> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
> > Sebastian, addressing the following comment of yours
> >
> >
> > "The main issue with master right now is that it moves really fast as a
> > shared branch, people merge features without warning, we see regressions
> > etc..
> > By the time we release a major version, master has moved so much that it
> > feels like starting over with the next release. It's almost as if we are
> > forking our own software. CI alone (even if it were really good) will not
> > fix this.”
> >
> >
> > You will still have this problem. You cut the next release branch from
> the
> > *develop branch, not from master. And the *develop branch will move with
> > the same pace as the old master, after the release branch is cut. So
> > “master moving really fast” problem would become “develop moving really
> > fast”.
> >
> > The problems you’ve mentioned - people merge features without warning, we
> > see regressions - can be fixed only with automation in place and the
> > requirement to run this automation (CI/BVT) before the merge is done.
> > Otherwise you are just shifting all existing problems from master to
> > develop.
> >
> >
> > -Alena.
> >
> >
> >
> > On 8/7/14, 2:15 PM, "Sebastien Goasguen"  wrote:
> >
> > >
> > >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> > > wrote:
> > >
> > >>
> > >>
> > >> On 8/7/14, 1:42 PM, "Sebastien Goasguen"  wrote:
> > >>
> > >>>
> > >>> On Aug 7, 2014, at 8:33 AM, David Nalley  wrote:
> > >>>
> >  On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
> run...@gmail.com>
> >  wrote:
> > >
> > > On Aug 6, 2014, at 7:15 PM, David Nalley  wrote:
> > >
> > >> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> > >>  wrote:
> > >>> Edison, thank you for raising the concern about t