Re: Variable renaming in classes meant for Agents

[Daan Hoogland]

tackled exactly that problem; the proposal
> > > presented in [1] decoupled client and server sides from variable name
> by
> > > using semantic annotations. The concept, the formalization and the
> > > experiments are all presented in paper [1]. The serialization and
> > > deserialization core of the proposal presented in [1] can be found in
> > [2].
> > >
> > > The idea of decoupling our web APIs from variable names is great, but
> it
> > is
> > > something that will require some effort to be fully and properly
> > > implemented. If you wish to push that forward count on me.
> > >
> > > [1] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6928953&tag=1
> > > [2] https://github.com/ivansalvadori/gsonld
> > >
> > >
> > > On Fri, May 20, 2016 at 3:30 AM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > Guys, we should rename fields that have improper names. I do not
> agreee
> > > > with the statement at all. Your two solutions to the serialisation
> > hazard
> > > > are both acceptable to me. leaving a non compliant or non explanatory
> > > name
> > > > in because it slipped through the nets at some points does not seem
> > > > acceptable to me. We must improve are code.
> > > >
> > > > On Fri, May 20, 2016 at 6:53 AM, Tutkowski, Mike <
> > > > mike.tutkow...@netapp.com>
> > > > wrote:
> > > >
> > > > > Thanks for sending out this e-mail, Anshul.
> > > > >
> > > > > This is a bit of a strange situation because we need to make sure
> > > people
> > > > > are either aware of the fact that properties in Command classes are
> > > > > serialized (and not change existing variable names) or come up
> with a
> > > > less
> > > > > fragile way of choosing property names when sending data (perhaps
> > using
> > > > > annotations).
> > > > >
> > > > > At the very least, we should have comments in these classes
> > indicating
> > > > the
> > > > > dangers of changing property names. It might also be beneficial to
> > have
> > > > > unit tests in place that expect certain variable names and assert
> if
> > > they
> > > > > are not as expected.
> > > > >
> > > > > In the meanwhile, I plan to change the variable names back that
> were
> > > > > changed in PR #816.
> > > > >
> > > > > Additional thoughts on how this should be addressed long term?
> > > > >
> > > > > Thanks!
> > > > > Mike
> > > > > 
> > > > > From: Anshul Gangwar 
> > > > > Sent: Thursday, May 19, 2016 10:47 PM
> > > > > To: dev@cloudstack.apache.org
> > > > > Subject: Variable renaming in classes meant for Agents
> > > > >
> > > > > Hi,
> > > > >
> > > > > We should not allow renaming of variables in classes which ends
> with
> > > > > Command and TO. As these objects are meant to be consumed by
> Agents.
> > > > >
> > > > > Agents may not be written in java so relying on these variable
> names
> > to
> > > > > get the info. One such example is Hyper-V agent.
> > > > >
> > > > > Hyper-V support is currently broken as there are some variables
> > renamed
> > > > in
> > > > > PR https://github.com/apache/cloudstack/pull/816.
> > > > >
> > > > > Regards,
> > > > > Anshul
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > DISCLAIMER
> > > > > ==
> > > > > This e-mail may contain privileged and confidential information
> which
> > > is
> > > > > the property of Accelerite, a Persistent Systems business. It is
> > > intended
> > > > > only for the use of the individual or entity to which it is
> > addressed.
> > > If
> > > > > you are not the intended recipient, you are not authorized to read,
> > > > retain,
> > > > > copy, print, distribute or use this message. If you have received
> > this
> > > > > communication in error, please notify the sender and delete all
> > copies
> > > of
> > > > > this message. Accelerite, a Persistent Systems business does not
> > accept
> > > > any
> > > > > liability for virus infected mails.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Daan
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

Re: Migrating CloudStack content from download.cloud.com

[Daan Hoogland]

is there no way, within foundation bylaws, to host this somewhere on
apache.org? we are using peoples wibesites for tests as well, aren't we.

On Fri, May 20, 2016 at 7:04 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> We could host a mirror here. We are in South America, Brazil.
>
> On Fri, May 20, 2016 at 2:01 PM, Chiradeep Vittal 
> wrote:
>
> > I was proposing a new S3 bucket earlier (templates.cloudstack.org), but
> I
> > realized that someone needs to own the account. There is no legal entity
> > for Apache CloudStack (except the ASF) that can enter into a contract
> with
> > AWS (even if it is for a few bucks a month).  To make this work,
> > alternatives:
> >  (1) ASF Infra creates this bucket and IAM keys to the PMC to operate
> this
> > bucket. ACS users might want to make targeted donations to support this
> > bucket, but I don't believe that it is possible.
> >
> > (2) Cloudstack.org gets registered as a (non-profit?) entity etc and ACS
> > users make donations to this entity. PMC has control over the bucket.
> >
> > A mirror list and a python script (e.g., [1]) sounds like a much better
> > idea :)
> >
> > Raise of hands:
> > Who is willing to host a mirror of systemvm templates and default
> > templates. I figure we need at least 5, preferably all over the world,
> > especially in East Asia.
> >
> > [1]
> >
> >
> http://code.activestate.com/recipes/284631-a-python-script-to-test-download-mirrors/
> >
> >
> >
> >
> >
> > On Fri, May 20, 2016 at 9:52 AM, Chiradeep Vittal 
> > wrote:
> >
> > > Agree with Daan : we shouldn't be pushing these ancient insecure
> > > templates!
> > >
> > >
> > > On Fri, May 20, 2016 at 9:51 AM, Chiradeep Vittal <
> chirade...@gmail.com>
> > > wrote:
> > >
> > >> :) According to Raja, there is some time before download.cloud.com is
> > >> doomed. Let's pretend that date is Jan 1 2017. Now pretend that it is
> > Dec
> > >> 25, 2016 and we're still debating mirror list vs steps and what not.
> > Now,
> > >> just change the 2017 to 2016 and re-consider. We need this done
> > yesterday!
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Fri, May 20, 2016 at 1:53 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > >> wrote:
> > >>
> > >>> send by tablet, no warranties in existence
> > >>> On 20 May 2016 09:29, "Paul Angus"  wrote:
> > >>> >
> > >>> > I'm a -1 on adding another step to the installation process.
> > >>> >
> > >>> > I agree with Will, it will only be another barrier to platform
> > >>> adoption.
> > >>> >
> > >>> > The SSVM going and downloading the built-in template is a good
> > >>> milestone
> > >>> in a CloudStack build.
> > >>> >
> > >>> > To be honest the mgmt. server should be able to go get the template
> > >>> itself if required rather than making it a user installation step.
> > >>> great idea, looking forward to your PR.
> > >>>
> > >>> >
> > >>> > Kind regards,
> > >>> >
> > >>> > Paul Angus
> > >>> >
> > >>> > paul.an...@shapeblue.com
> > >>> > www.shapeblue.com
> > >>> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > >>> > @shapeblue
> > >>> >
> > >>> >
> > >>> >
> > >>> > -Original Message-
> > >>> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > >>> > Sent: 19 May 2016 23:06
> > >>> > To: dev 
> > >>> > Subject: Re: Migrating CloudStack content from download.cloud.com
> > >>> >
> > >>> > sounds good, so if we put both sections together the worry is over.
> > acs
> > >>> is a complex system and requires a lot of reading so let''s not put
> it
> > >>> in a
> > >>> different section. would be duplicate code anyhow.
> > >>> >
> > >>> > On Thu, May 19, 2016 at 11:56 PM, Chiradeep Vittal <
> > >>> chirade...@gmail.com>
> > >>> > wrote:
>

Re: Variable renaming in classes meant for Agents

[Daan Hoogland]

Rafael [2] is a members only link (pornographia academia?)

On Fri, May 20, 2016 at 5:12 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Hi guys,
> I agree with Daan that if class fields have improper (not descriptive or
> not suitable) names we should change them. However, I do not find the
> change (on variable names) introduced by PR #816 good. It added an
> “_”(underline) before variable names; even though Apache CloudStack has a
> lot of that currently, I think that is a pattern we should avoid.
>
> Your ideas to use annotations to avoid relying on variable names are great;
> but, let’s not re-create the well here. There is a research [1] that has
> been conducted in 2014 that tackled exactly that problem; the proposal
> presented in [1] decoupled client and server sides from variable name by
> using semantic annotations. The concept, the formalization and the
> experiments are all presented in paper [1]. The serialization and
> deserialization core of the proposal presented in [1] can be found in [2].
>
> The idea of decoupling our web APIs from variable names is great, but it is
> something that will require some effort to be fully and properly
> implemented. If you wish to push that forward count on me.
>
> [1] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6928953&tag=1
> [2] https://github.com/ivansalvadori/gsonld
>
>
> On Fri, May 20, 2016 at 3:30 AM, Daan Hoogland 
> wrote:
>
> > Guys, we should rename fields that have improper names. I do not agreee
> > with the statement at all. Your two solutions to the serialisation hazard
> > are both acceptable to me. leaving a non compliant or non explanatory
> name
> > in because it slipped through the nets at some points does not seem
> > acceptable to me. We must improve are code.
> >
> > On Fri, May 20, 2016 at 6:53 AM, Tutkowski, Mike <
> > mike.tutkow...@netapp.com>
> > wrote:
> >
> > > Thanks for sending out this e-mail, Anshul.
> > >
> > > This is a bit of a strange situation because we need to make sure
> people
> > > are either aware of the fact that properties in Command classes are
> > > serialized (and not change existing variable names) or come up with a
> > less
> > > fragile way of choosing property names when sending data (perhaps using
> > > annotations).
> > >
> > > At the very least, we should have comments in these classes indicating
> > the
> > > dangers of changing property names. It might also be beneficial to have
> > > unit tests in place that expect certain variable names and assert if
> they
> > > are not as expected.
> > >
> > > In the meanwhile, I plan to change the variable names back that were
> > > changed in PR #816.
> > >
> > > Additional thoughts on how this should be addressed long term?
> > >
> > > Thanks!
> > > Mike
> > > 
> > > From: Anshul Gangwar 
> > > Sent: Thursday, May 19, 2016 10:47 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Variable renaming in classes meant for Agents
> > >
> > > Hi,
> > >
> > > We should not allow renaming of variables in classes which ends with
> > > Command and TO. As these objects are meant to be consumed by Agents.
> > >
> > > Agents may not be written in java so relying on these variable names to
> > > get the info. One such example is Hyper-V agent.
> > >
> > > Hyper-V support is currently broken as there are some variables renamed
> > in
> > > PR https://github.com/apache/cloudstack/pull/816.
> > >
> > > Regards,
> > > Anshul
> > >
> > >
> > >
> > >
> > >
> > >
> > > DISCLAIMER
> > > ==
> > > This e-mail may contain privileged and confidential information which
> is
> > > the property of Accelerite, a Persistent Systems business. It is
> intended
> > > only for the use of the individual or entity to which it is addressed.
> If
> > > you are not the intended recipient, you are not authorized to read,
> > retain,
> > > copy, print, distribute or use this message. If you have received this
> > > communication in error, please notify the sender and delete all copies
> of
> > > this message. Accelerite, a Persistent Systems business does not accept
> > any
> > > liability for virus infected mails.
> > >
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

RE: Migrating CloudStack content from download.cloud.com

[Daan Hoogland]

send by tablet, no warranties in existence
On 20 May 2016 09:29, "Paul Angus"  wrote:
>
> I'm a -1 on adding another step to the installation process.
>
> I agree with Will, it will only be another barrier to platform adoption.
>
> The SSVM going and downloading the built-in template is a good milestone
in a CloudStack build.
>
> To be honest the mgmt. server should be able to go get the template
itself if required rather than making it a user installation step.
great idea, looking forward to your PR.

>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 19 May 2016 23:06
> To: dev 
> Subject: Re: Migrating CloudStack content from download.cloud.com
>
> sounds good, so if we put both sections together the worry is over. acs
is a complex system and requires a lot of reading so let''s not put it in a
different section. would be duplicate code anyhow.
>
> On Thu, May 19, 2016 at 11:56 PM, Chiradeep Vittal 
> wrote:
>
> > Well, you have to define "worry" :)
> >
> > I'm proposing an almost identical step to
> >
> > http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/
> > 4.6/management-server/#prepare-the-system-vm-template
> >
> > If they can do that, then it is not a stretch to assume they can
> > download the default template in a similar manner. The
> > "cloud-install-default-template" (proposed) script can do the mirror
> > checking etc.
> >
> >
> >
> >
> > On Thu, May 19, 2016 at 2:44 PM, Will Stevens 
> > wrote:
> >
> > > I definitely agree with this.  I don't think people doing a PoC
> > > should
> > have
> > > to worry about getting a template installed on first setup.  I think
> > > that is a basic feature if we want platform adoption.  Getting the
> > > first boot process from download to first VM launched should be as
> > > smooth as
> > possible.
> > >
> > > *Will STEVENS*
> > > Lead Developer
> > >
> > > *CloudOps* *| *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|*
> > > tw @CloudOps_
> > >
> > > On Thu, May 19, 2016 at 5:37 PM, Daan Hoogland
> > > 
> > > wrote:
> > >
> > > > Chiradeep,
> > > >
> > > > It makes sense not to have this old default very insecure guest
> > template
> > > > still be downloaded but it would be nice to have some kind of
> > > > meta-data pointing to the latest version of an acceptable template
> > > > (symlink) for trial installs so PoCcers are swiftly on their way.
Would you agree?
> > > >
> > > > On Thu, May 19, 2016 at 8:15 PM, Chiradeep Vittal <
> > chirade...@gmail.com>
> > > > wrote:
> > > >
> > > > > Pierre,
> > > > > I meant the auto-download of default templates, not systemvm.
> > > > > Note that the initial systemvm template has to be
> > > > > hand-downloaded
> > > anyway.
> > > > > If you are a single hypervisor cloud, then that is all that is
> > needed.
> > > > >
> > > > > On Thu, May 19, 2016 at 11:08 AM, Pierre-Luc Dion <
> > pd...@cloudops.com>
> > > > > wrote:
> > > > >
> > > > > > I would be -1 about disabling the autodownload of the systemvm
> > > > template,
> > > > > > has this should be simplify deployment of a cloudstack system.
> > > > > > although, the download URL should be a configurable value,
> > > > > > maybe
> > in a
> > > > > > property file or thru the API somehow or via a pre-install
command.
> > > > > >
> > > > > > I really like  download.cloudstack.org + mirror. I'm looking
> > > > > > at
> > > > getting
> > > > > > the
> > > > > > DNS entry: builds.cloudstack.org for the new Jenkins and I got
> > > > > > no objections on using the cloudstack.org domain for community
> > services
> > > > so
> > > > > > I'm
> > > > > > pretty sure we would be ok to use download.cloudstack.org,
> > > > > > where
> > > would
>

Re: Regarding: "AmazonEC2stub.java"

[Daan Hoogland]

OK, those were generated files that are now removed from the project.

send by tablet, no warranties in existence
On 20 May 2016 08:58, "sangeeta lal"  wrote:

> Dear Sir,
>
> I am using version 4.3.0.
>
> Thanks for  your reply!
>
> On Fri, May 20, 2016 at 12:03 PM, Daan Hoogland 
> wrote:
>
>> Sangeeta,
>>
>> What version of the code are you analysing? There used to be a lot of
>> generated ec2 code in the project some versions back. I can not find the
>> java file you are talking about.
>>
>> On Fri, May 20, 2016 at 8:03 AM, sangeeta lal 
>> wrote:
>>
>> > Dear Dev Team,
>> >
>> >
>> > I am Sangeeta, a PhD scholar from India. I am working in the area of
>> > automated software engineering and my aim is to analyse logging
>> statements.
>> >
>> > While analysing the CloudStack project, I found a file:*
>> > AmazonEC2Stub.java*
>> >
>> >
>> >
>> > Can anyone please tell me the reason, why* this file have no logging
>> > statement?*
>> >
>> >
>> >
>> > I  highly appreciate your help!
>> >
>> > Thank You
>> >
>> > --
>> > Regards...
>> > Sangeeta
>> > Assistant Professor
>> > CSE Department @JIIT Noida
>> >
>>
>>
>>
>> --
>> Daan
>>
>
>
>
> --
> Regards...
> Sangeeta
> Assistant Professor
> CSE Department @JIIT Noida
>
>

Re: Regarding: "AmazonEC2stub.java"

[Daan Hoogland]

Sangeeta,

What version of the code are you analysing? There used to be a lot of
generated ec2 code in the project some versions back. I can not find the
java file you are talking about.

On Fri, May 20, 2016 at 8:03 AM, sangeeta lal 
wrote:

> Dear Dev Team,
>
>
> I am Sangeeta, a PhD scholar from India. I am working in the area of
> automated software engineering and my aim is to analyse logging statements.
>
> While analysing the CloudStack project, I found a file:*
> AmazonEC2Stub.java*
>
>
>
> Can anyone please tell me the reason, why* this file have no logging
> statement?*
>
>
>
> I  highly appreciate your help!
>
> Thank You
>
> --
> Regards...
> Sangeeta
> Assistant Professor
> CSE Department @JIIT Noida
>



-- 
Daan

Re: Variable renaming in classes meant for Agents

[Daan Hoogland]

Guys, we should rename fields that have improper names. I do not agreee
with the statement at all. Your two solutions to the serialisation hazard
are both acceptable to me. leaving a non compliant or non explanatory name
in because it slipped through the nets at some points does not seem
acceptable to me. We must improve are code.

On Fri, May 20, 2016 at 6:53 AM, Tutkowski, Mike 
wrote:

> Thanks for sending out this e-mail, Anshul.
>
> This is a bit of a strange situation because we need to make sure people
> are either aware of the fact that properties in Command classes are
> serialized (and not change existing variable names) or come up with a less
> fragile way of choosing property names when sending data (perhaps using
> annotations).
>
> At the very least, we should have comments in these classes indicating the
> dangers of changing property names. It might also be beneficial to have
> unit tests in place that expect certain variable names and assert if they
> are not as expected.
>
> In the meanwhile, I plan to change the variable names back that were
> changed in PR #816.
>
> Additional thoughts on how this should be addressed long term?
>
> Thanks!
> Mike
> 
> From: Anshul Gangwar 
> Sent: Thursday, May 19, 2016 10:47 PM
> To: dev@cloudstack.apache.org
> Subject: Variable renaming in classes meant for Agents
>
> Hi,
>
> We should not allow renaming of variables in classes which ends with
> Command and TO. As these objects are meant to be consumed by Agents.
>
> Agents may not be written in java so relying on these variable names to
> get the info. One such example is Hyper-V agent.
>
> Hyper-V support is currently broken as there are some variables renamed in
> PR https://github.com/apache/cloudstack/pull/816.
>
> Regards,
> Anshul
>
>
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>



-- 
Daan

Re: Migrating CloudStack content from download.cloud.com

[Daan Hoogland]

sounds good, so if we put both sections together the worry is over. acs is
a complex system and requires a lot of reading so let''s not put it in a
different section. would be duplicate code anyhow.

On Thu, May 19, 2016 at 11:56 PM, Chiradeep Vittal 
wrote:

> Well, you have to define "worry" :)
>
> I'm proposing an almost identical step to
>
> http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.6/management-server/#prepare-the-system-vm-template
>
> If they can do that, then it is not a stretch to assume they can download
> the default template in a similar manner. The
> "cloud-install-default-template" (proposed) script can do the mirror
> checking etc.
>
>
>
>
> On Thu, May 19, 2016 at 2:44 PM, Will Stevens 
> wrote:
>
> > I definitely agree with this.  I don't think people doing a PoC should
> have
> > to worry about getting a template installed on first setup.  I think that
> > is a basic feature if we want platform adoption.  Getting the first boot
> > process from download to first VM launched should be as smooth as
> possible.
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, May 19, 2016 at 5:37 PM, Daan Hoogland 
> > wrote:
> >
> > > Chiradeep,
> > >
> > > It makes sense not to have this old default very insecure guest
> template
> > > still be downloaded but it would be nice to have some kind of meta-data
> > > pointing to the latest version of an acceptable template (symlink) for
> > > trial installs so PoCcers are swiftly on their way. Would you agree?
> > >
> > > On Thu, May 19, 2016 at 8:15 PM, Chiradeep Vittal <
> chirade...@gmail.com>
> > > wrote:
> > >
> > > > Pierre,
> > > > I meant the auto-download of default templates, not systemvm.
> > > > Note that the initial systemvm template has to be hand-downloaded
> > anyway.
> > > > If you are a single hypervisor cloud, then that is all that is
> needed.
> > > >
> > > > On Thu, May 19, 2016 at 11:08 AM, Pierre-Luc Dion <
> pd...@cloudops.com>
> > > > wrote:
> > > >
> > > > > I would be -1 about disabling the autodownload of the systemvm
> > > template,
> > > > > has this should be simplify deployment of a cloudstack system.
> > > > > although, the download URL should be a configurable value, maybe
> in a
> > > > > property file or thru the API somehow or via a pre-install command.
> > > > >
> > > > > I really like  download.cloudstack.org + mirror. I'm looking at
> > > getting
> > > > > the
> > > > > DNS entry: builds.cloudstack.org for the new Jenkins and I got no
> > > > > objections on using the cloudstack.org domain for community
> services
> > > so
> > > > > I'm
> > > > > pretty sure we would be ok to use download.cloudstack.org, where
> > would
> > > > we
> > > > > setting this up? on the current webserver of our website? could we
> ?
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > PL
> > > > >
> > > > > On Thu, May 19, 2016 at 11:00 AM, Giles Sirett <
> > > > giles.sir...@shapeblue.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Erik
> > > > > > I agree on the existing users - not the end of the world. We
> could
> > > even
> > > > > > release a tiny patch to update the DB records
> > > > > >
> > > > > > The piece that we need to be really careful with is the "I've
> just
> > > > > > downloaded cloudstack  thing for the first time" scenario
> > > > > >
> > > > > > But - there seems to be plenty of good ideas flowing on that
> > > > > >
> > > > > >
> > > > > > Kind Regards
> > > > > > Giles
> > > > > >
> > > > > >
> > > > > > giles.sir...@shapeblue.com
> > > > > > www.shapeblue.com
> > > > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > > > @shapeblue
> > > > > >
> > &g

Re: Migrating CloudStack content from download.cloud.com

[Daan Hoogland]

Chiradeep,

It makes sense not to have this old default very insecure guest template
still be downloaded but it would be nice to have some kind of meta-data
pointing to the latest version of an acceptable template (symlink) for
trial installs so PoCcers are swiftly on their way. Would you agree?

On Thu, May 19, 2016 at 8:15 PM, Chiradeep Vittal 
wrote:

> Pierre,
> I meant the auto-download of default templates, not systemvm.
> Note that the initial systemvm template has to be hand-downloaded anyway.
> If you are a single hypervisor cloud, then that is all that is needed.
>
> On Thu, May 19, 2016 at 11:08 AM, Pierre-Luc Dion 
> wrote:
>
> > I would be -1 about disabling the autodownload of the systemvm template,
> > has this should be simplify deployment of a cloudstack system.
> > although, the download URL should be a configurable value, maybe in a
> > property file or thru the API somehow or via a pre-install command.
> >
> > I really like  download.cloudstack.org + mirror. I'm looking at getting
> > the
> > DNS entry: builds.cloudstack.org for the new Jenkins and I got no
> > objections on using the cloudstack.org domain for community services so
> > I'm
> > pretty sure we would be ok to use download.cloudstack.org, where would
> we
> > setting this up? on the current webserver of our website? could we ?
> >
> >
> > Cheers,
> >
> > PL
> >
> > On Thu, May 19, 2016 at 11:00 AM, Giles Sirett <
> giles.sir...@shapeblue.com
> > >
> > wrote:
> >
> > > Erik
> > > I agree on the existing users - not the end of the world. We could even
> > > release a tiny patch to update the DB records
> > >
> > > The piece that we need to be really careful with is the "I've just
> > > downloaded cloudstack  thing for the first time" scenario
> > >
> > > But - there seems to be plenty of good ideas flowing on that
> > >
> > >
> > > Kind Regards
> > > Giles
> > >
> > >
> > > giles.sir...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > > -Original Message-
> > > From: Erik Weber [mailto:terbol...@gmail.com]
> > > Sent: 19 May 2016 09:32
> > > To: dev 
> > > Subject: Re: Migrating CloudStack content from download.cloud.com
> > >
> > > As a user (with old ACS installations) I'd say that this isn't all that
> > > troublesome, this is easily fixed by updating the appropriate db
> records.
> > >
> > > We should ensure that we have some good posts discovered by Google and
> > > other search engines, so that when somebody running old installations
> hit
> > > this issue they find the workaround.
> > > There's a lot of time to reach out to users and inform of the fix
> > > necessary.
> > >
> > > --
> > > Erik
> > >
> > >
> > > On Tue, May 17, 2016 at 10:34 AM, Giles Sirett <
> > giles.sir...@shapeblue.com
> > > >
> > > wrote:
> > >
> > > > This is a MAJOR problem and needs to be figured out before the
> current
> > > > download site is removed - @Raja - have Citrix committed to it being
> > > there
> > > > another year ?
> > > >
> > > > It is my understanding that Cloudstack relies on this download at
> > initial
> > > > build/startup and then periodically if people do things like build a
> > new
> > > > zone
> > > >
> > > > So, users environments aren't going to stop if its pulled, but nobody
> > > > would be a able to build/install cloudstack and it may cause issues
> as
> > > and
> > > > when users make config changes
> > > >
> > > > The problem is, for new builds, its hard coded : you start the  Sec
> > > > Storage VM, CloudStack will try to download the built in template
> from
> > > > download.cloud.com
> > > >
> > > > My understanding is that its simple db  change to make once an
> > > environment
> > > > is running (exisiting users) but *may* require a code patch to fix
> the
> > > > initial install
> > > >
> > > > #notideal
> > > >
> > > > Really, this should be maintained by ASF/ the project as its key to
> the
> > > > software working, however my understanding is it involves binaries
> > which
> > > > ASF is never keen on (and may be some 3rd party binaries) - so that
> > just
> > > > wont happen
> > > >
> > > >
> > > >
> > > > Apt-get is controlled by Wido et al (for which we all owe him a
> massive
> > > > thanks)  - but you are right, it is a 3rd party dependency and
> > arguably a
> > > > SPOF.  But, if ASF wont host binaries, we're always going to have
> this
> > > > issue.
> > > >
> > > > So, we could patch the code to point somewhere else - but where ? -
> by
> > > > definition its got to be something maintained by a 3rd party
> > > >
> > > >
> > > > We had this debate some time ago when talking about the repositories.
> > We
> > > > (ShapeBlue) maintain a repo for our customers, which wev'e always
> > opened
> > > up
> > > > as public. However, there were concerns about having a company domain
> > > name
> > > > (which I understand) - so apt-get became our preferred repo.
> > > >
> > > >
> > > > Thoughts on how to fix this:

Re: Refactoring CitrixResourceBase

[Daan Hoogland]

Syed,

gogogo. actually it has shrunk to 5k lines since 2012 ;)

I like your initiative and initial direction. A lot of small steps to
improve the blob have been taken and I would sugest to keep going in small
steps.

On Thu, May 19, 2016 at 9:44 PM, Tim Mackey  wrote:

> +1
>
> When I went through this last time, not only was it hard to understand the
> flows, but the XenServer version management was a pain. Would suggest
> creating a base class which always works (i.e. is independent of XenServer
> version) for core functions. Then add in that which exists for a specific
> version. Should help greatly with testing IMO.
>
> -tim
>
> On Thu, May 19, 2016 at 2:37 PM, Syed Mushtaq 
> wrote:
>
> > Hi All,
> >
> > I would like to refactor CitrixResourceBase class which is responsible
> for
> > communicating with Xenserver. It has grown too long (>5K lines) and has
> > absolutely no testing.
> >
> > In my first pass I want to separate out the functionality buy the
> subsystem
> > it targets (compute, storage, network etc) and will go on from there.
> What
> > do you think? Is anyone working on this currently?
> >
> > Thanks,
> > -Syed
> >
>



-- 
Daan

Re: jenkins pr check

[Daan Hoogland]

Maybe I should have formulated my request A little less open minded :) Hope
it did help. As I choose one of two possible solutions let me know if I
should try the other one.

On Thu, May 19, 2016 at 5:25 PM, Will Stevens  wrote:

> Haha.  Too bad you can't batch this email to a smaller groups.  Daan just
> crashed the Jenkins...  :P
>
> Seriously, thank you for your help on this.  I think this will make a big
> difference going forward.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Thu, May 19, 2016 at 7:46 AM, Daan Hoogland 
> wrote:
>
> > People,
> >
> > I've asked several people to reopen their pr because of jenkins
> > configuration problems. I think i found the little checkbox that needed
> > setting now. Please do not hurry but reopen any failed PRs on jenkins
> > problems, if you fell it wasn't in your code. don't do it all at once as
> > builds.a.o is kind of heavily loaded.
> >
> > --
> > Daan
> >
>



-- 
Daan

jenkins pr check

[Daan Hoogland]

People,

I've asked several people to reopen their pr because of jenkins
configuration problems. I think i found the little checkbox that needed
setting now. Please do not hurry but reopen any failed PRs on jenkins
problems, if you fell it wasn't in your code. don't do it all at once as
builds.a.o is kind of heavily loaded.

-- 
Daan

Re: [ANNOUNCE] Will Stevens as new Apache CloudStack VP

[Daan Hoogland]

thanks Sebastien,

looking forward to a workshop on your new endevours and please have a
thought for poor Will once in a while.

On Thu, May 19, 2016 at 10:32 AM, Jayapal Uradi <
jayapal.ur...@accelerite.com> wrote:

> Congrats Will.
>
> Thanks,
> Jayapal
> > On 19-May-2016, at 1:54 pm, Rohit Yadav 
> wrote:
> >
> > Congrats Will.
> >
> > Regards,
> > Rohit Yadav
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> > On May 19 2016, at 12:26 pm, Sebastien Goasguen 
> wrote:
> >
> > Morning Everyone,
> >
> > Yesterday at the ASF board meeting, the board passed the resolution
> making Will Stevens the new Vice President of the Apache CloudStack project.
> >
> > Join me in congratulating Will on this appointment, wish him luck and
> bring your unwavering support !
> >
> > You may have noticed that Will took on RM duties for the new releases
> going forward and has also taken a very active role to finish bringing us
> to github based workflow and CI. Will has some updates on that front that I
> am sure you will all like.
> >
> > -Sebastien
> > Former VP CloudStack
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>



-- 
Daan

Re: How to fix Jenkins git workspace issues

[Daan Hoogland]

On Thu, May 19, 2016 at 7:22 AM, Rajani Karuturi  wrote:

> untracked


​good call Rajani, it was only doing an ordinary clean in the rat check
step.​



-- 
Daan

Re: How to fix Jenkins git workspace issues

[Daan Hoogland]

Here it is I haven't checked it yet


  
<h1>cloudstack Build</h1>
<ul>
 <li>Checks out Pull requests to Apache CloudStack from
<code>github</code></li>
  <li>Does a
license check against it</li>
  <li>Builds the target
branch with Maven and runs unit tests</li>
  <li>runs
analysis tools on the
code</li>
</ul>
false  
  30
30
-1
-1  

  
   

http://github.com/apache/cloudstack/



false


false
false


1
0
true
project

  2
  
https://github.com/apache/cloudstack

  **
 
false
   



ubuntu
false  false
false
 false
 latest1.8  
  

  true  
  if [ -f target/reat.txt ]then  rm
target/rat.txtfi
  clean
--projects='org.apache.cloudstack:cloudstack'
org.apache.rat:apache-rat-plugin:0.10:check
maven-3.3.3
false

-Penablefindbugs install cobertura:cobertura
maven-3.3.3
false

  
  low
[CHECKSTYLE] 

false
false
false
false  












   

  
false
true
false



   
low  [FINDBUGS]
  
false
false
false
false  












   

  
false
true
false
  false




  
low  [PMD]
  
false
false
false
false  












   

  
false
true
false


  
low  [DRY]
  
false
false
false
false  












   

  
false
true
false
  50
25

target/rat.txt
false
false
false
true
true


 
**/target/site/cobertura/coverage.xml
 false
false
false
false
false
false
0
true  


METHOD
   800
 
LINE
   800
 
CONDITIONAL
   700  
  

METHOD
   0
LINE
   0
CONDITIONAL
   0  
  

METHOD
   0
LINE
   0
CONDITIONAL
   0  
  ASCII


clover
clover.xml
70
80
80  
      
  
  
  400
3
180
  


false  false






On Wed, May 18, 2016 at 8:56 PM, Daan Hoogland 
wrote:

> Rafael, I think I can access jenkins and download the config.
> Will, files not included in a PR sticking around "kinda" makes sense as
> these will not be cleaned by mvn clean on another job
>
> On Wed, May 18, 2016 at 8:02 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> Do any of the PMCs have access to those VMs? Or at least admin access to
>> Jenkins; with admin access we could check the Jenkins Jobs build configs.
>>
>> On Wed, May 18, 2016 at 2:02 PM, Will Stevens 
>> wrote:
>>
>> > I have seen quite a few situations where tests are failing and they are
>> > referencing files that are not even included in that PR.
>> >
>> > I have also seen situations like this, so the git workspace (index) has
>> > fragments of previous CI runs and is no longer in a mergeable state.
>> >
>> > > git checkout -b master origin/master
>> > FATAL: Could not checkout master with start point
>> > origin/masterhudson.plugins.git.GitException
>> > <
>> >
>> http://stacktrace.jenkins-ci.org/search?query=hudson.plugins.git.GitException
>> > >:
>> > Could not checkout master with start point origin/master
>> > at
>> >
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1962)
>> > <
>> >
>> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute&entity=method
>> > >
>> > at
>> >
>> org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch(AbstractGitAPIImpl.java:82)
>> > <
>> >
>> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch&entity=method
>> > >
>> > at
>> >
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPIImpl.java:62)
>> > <
>> >
>> http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch&entity=method
>> > >
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> > at
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.lang.reflect.Method.invoke(Method.java:606)

Re: How to fix Jenkins git workspace issues

[Daan Hoogland]

tBuild.java:529)
> > at hudson.model.Run.execute(Run.java:1738)
> > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> > at
> > hudson.model.ResourceController.execute(ResourceController.java:98)
> > at hudson.model.Executor.run(Executor.java:410)
> > Caused by: hudson.plugins.git.GitException: Command "git checkout -b
> > master origin/master" returned status code 1:
> > stdout:
> >
> plugins/hypervisors/simulator/src/com/cloud/api/commands/SimulatorAddSecondaryAgent.java:
> > needs merge
> >
> >
> plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/resource/SimulatorSecondaryStorageResource.java:
> > needs merge
> > plugins/hypervisors/ucs/src/com/cloud/ucs/structure/UcsCookie.java: needs
> > merge
> > vmware-base/src/com/cloud/hypervisor/vmware/mo/FeatureKeyConstants.java:
> > needs merge
> >
> > stderr: error: you need to resolve your current index first
> >
> > at
> >
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
> > at
> >
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:62)
> > at
> >
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:1956)
> > at
> >
> org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.checkoutBranch(AbstractGitAPIImpl.java:82)
> > at
> >
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkoutBranch(CliGitAPIImpl.java:62)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at
> >
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
> > at
> >
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
> > at
> >
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
> > at hudson.remoting.UserRequest.perform(UserRequest.java:120)
> > at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> > at hudson.remoting.Request$2.run(Request.java:326)
> > at
> >
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Wed, May 18, 2016 at 12:26 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Me neither.
> > > Do we need to open a ticket to infra to check that? Or do we have
> someone
> > > among the PMCs that have access to those VMs?
> > >
> > > On Wed, May 18, 2016 at 12:51 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > > > I hav no access to the nodes so I wouldn't know about that.
> > > >
> > > > On Wed, May 18, 2016 at 5:36 PM, Rafael Weingärtner <
> > > > rafaelweingart...@gmail.com> wrote:
> > > >
> > > > > Parallel builds will use different workspace, so that should not
> be a
> > > > > problem.
> > > > >
> > > > > Maybe the “@” symbol it uses to differentiate the workspace
> folders?
> > > > > I mean, when it runs parallel builds, it will use a “@” and then it
> > > will
> > > > > append a number to identify the builds.
> > > > >
> > > > > For instance, if we have workspace called “Test”, when running
> > parallel
> > > > > builds we would get something like: “Test@2” , “Test@3”  and so
> > forth.
> > > > > That
> > > > > “@” symbol in a folder may break some scripts.
> > > > >
> 

Re: How to fix Jenkins git workspace issues

[Daan Hoogland]

I hav no access to the nodes so I wouldn't know about that.

On Wed, May 18, 2016 at 5:36 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Parallel builds will use different workspace, so that should not be a
> problem.
>
> Maybe the “@” symbol it uses to differentiate the workspace folders?
> I mean, when it runs parallel builds, it will use a “@” and then it will
> append a number to identify the builds.
>
> For instance, if we have workspace called “Test”, when running parallel
> builds we would get something like: “Test@2” , “Test@3”  and so forth.
> That
> “@” symbol in a folder may break some scripts.
>
> Also, if the scripts that are executed were not prepared to run in
> parallel, they might use the very same temp folder and files, which can
> cause problems.
>
> On Wed, May 18, 2016 at 12:26 PM, Daan Hoogland 
> wrote:
>
> > It also does a mvn clean so that should not be an issue. I am thinking
> more
> > along the line of parallel builds on the same node.
> >
> > On Wed, May 18, 2016 at 5:04 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Is Jenkins configure to clean the workspace before it starts a new
> build?
> > >
> > > It should have an option such as "Delete workspace before build
> starts".
> > >
> > > On Wed, May 18, 2016 at 12:00 PM, Will Stevens <
> williamstev...@gmail.com
> > >
> > > wrote:
> > >
> > > > If Jenkins has problems with fragments being left over in it's
> > workspace
> > > > which is causing following runs against other PRs to fail, how do we
> > fix
> > > > that?
> > > >
> > > > Thanks...
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: How to fix Jenkins git workspace issues

[Daan Hoogland]

It also does a mvn clean so that should not be an issue. I am thinking more
along the line of parallel builds on the same node.

On Wed, May 18, 2016 at 5:04 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Is Jenkins configure to clean the workspace before it starts a new build?
>
> It should have an option such as "Delete workspace before build starts".
>
> On Wed, May 18, 2016 at 12:00 PM, Will Stevens 
> wrote:
>
> > If Jenkins has problems with fragments being left over in it's workspace
> > which is causing following runs against other PRs to fail, how do we fix
> > that?
> >
> > Thanks...
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Problem enabling Intermediate SSL Certificate on Console VM

[Daan Hoogland]

Thanks for reporting back Ohzan,

sorry we couldn't be of much help ;)

On Wed, May 18, 2016 at 2:52 PM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:

> Hi;
> I solved the issue, somehow Alpha SSL has an extra space character in their
> intermediate CA file. So i removed the space character and reinstall the
> intermediate CA an now Console VM is fine. I will also remind Alpha SSL
> about the extra space character in their intermediate CA file.
>
> Thanks for your time.
>
> Regards
> Özhan
>
> On Wed, May 18, 2016 at 1:08 PM, Özhan Rüzgar Karaman <
> oruzgarkara...@gmail.com> wrote:
>
> > Hi Developers;
> > My console vm works successfully over SSL connections. Yesterday we
> > realised that firefox could not validate our SSL certificate and it gives
> > us certificate validation errors.
> >
> > We checked keystore table on database and noticed that we have not
> > imported intermediate certificate and console vm works over SSL without
> any
> > intermediate SSL certificates. We checked Alpha SSL web site and
> downloaded
> > the certificate file(
> > https://www.alphassl.com/support/install-root-certificate.html)  and
> > delete the keystore table and re import all root cert + intermediate +
> > server cert + private key from Cloudstack Admin interface. After that we
> > have checked the console vm logs(/var/log/cloud/cloud.out) and we noticed
> > that it could not successfully download the ssl certificate from ACS. The
> > errors are below.
> >
> > I checked the keystore table and it looks okey. After that i restored the
> > keystore table from backup which does not have any intermediate
> > certificate, console vm started to work, but because we do not have
> > intermediate certificate in console vm, windows firefox clients again
> could
> > not connect to console sessions.
> >
> > Does anyone experience this kind of problem on enabling intermediate
> > certificate? Also which kind of intermediate certificate format need to
> be
> > used on ACS, are all formats valid for CloudStack 4.8 ? Alpha SSL
> provides
> > SHA-1 and SHA-256 formats for intermediate certificates.
> >
> > Thanks for all responses & time.
> >
> > Regards
> > Özhan
> >
> >
> >
> > 2016-05-18 09:45:56,205 INFO
> >  [cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl]
> > (Console-Proxy-Main:null) Start initializing SSL
> > 2016-05-18 09:45:56,205 INFO
> >  [cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl]
> > (Console-Proxy-Main:null) No certificates passed, recheck global
> > configuration and certificates
> > 2016-05-18 09:45:56,205 INFO
> >  [cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl]
> > (Console-Proxy-Main:null) Start initializing SSL
> > 2016-05-18 09:45:56,206 INFO
> >  [cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl]
> > (Console-Proxy-Main:null) No certificates passed, recheck global
> > configuration and certificates
> > 2016-05-18 09:45:56,227 ERROR
> > [cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl]
> > (Console-Proxy-Main:null) java.lang.NullPointerException: null SSLContext
> > java.lang.NullPointerException: null SSLContext
> > at
> >
> com.sun.net.httpserver.HttpsConfigurator.(HttpsConfigurator.java:81)
> > at
> >
> com.cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl$1.(ConsoleProxySecureServerFactoryImpl.java:82)
> > at
> >
> com.cloud.consoleproxy.ConsoleProxySecureServerFactoryImpl.createHttpServerInstance(ConsoleProxySecureServerFactoryImpl.java:82)
> > at
> >
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:356)
> > at com.cloud.consoleproxy.ConsoleProxy.start(ConsoleProxy.java:331)
> > at
> >
> com.cloud.consoleproxy.ConsoleProxy.startWithContext(ConsoleProxy.java:316)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at
> >
> com.cloud.agent.resource.consoleproxy.ConsoleProxyResource$1.runInContext(ConsoleProxyResource.java:331)
> > at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> > at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> > at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> > at
> >
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> > at
> >
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> > at java.lang.Thread.run(Thread.java:745)
> > 2016-05-18 09:45:56,240 ERROR [cloud.consoleproxy.ConsoleProxy]
> > (Console-Proxy-Main:null) null
> > java.lang.NullPointerException
> > at
> >
> com.cloud.consoleproxy.ConsoleProxy.startupHttpMain(ConsoleProxy.java:357)

Re: Juniper Build Failure

[Daan Hoogland]

I have been going past that point twice today but got stuck on it twice as
well. I think juniper is having network problems ;) (had to say that but I
really think it is maven central that has the problems)

On Tue, May 17, 2016 at 3:52 PM, Will Stevens 
wrote:

> I have run into this a few times this morning already.  Builds fail because
> of this:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process
> (default) on project cloud-client-ui: Error resolving project artifact:
> Could not transfer artifact
> net.juniper.contrail:juniper-contrail-api:pom:1.0-SNAPSHOT from/to
> apache.snapshots (http://repository.apache.org/snapshots): Failed to
> transfer file:
>
> http://repository.apache.org/snapshots/net/juniper/contrail/juniper-contrail-api/1.0-SNAPSHOT/juniper-contrail-api-1.0-SNAPSHOT.pom
> .
> Return code is: 503, ReasonPhrase: Service Unavailable. for project
> net.juniper.contrail:juniper-contrail-api:jar:1.0-SNAPSHOT -> [Help 1]
>
> I have seen this problem periodically in the past.  Are we having issues
> with this repository?
>



-- 
Daan

Re: old error back?

[Daan Hoogland]

On Tue, May 17, 2016 at 3:43 PM, Will Stevens  wrote:

> have not tested


​I have, works!​



-- 
Daan

Re: old error back?

[Daan Hoogland]

yes, you are right. I did one thing that wasn't needed. the firstbootscript
needs to be overrided and the config needs to be editted.

On Tue, May 17, 2016 at 3:10 PM, Will Stevens  wrote:

> BTW, you shouldn't need the java7 file anymore in the new bubble (have not
> tested), but the override system lets us use the same role and just change
> what is done for ACS for that role.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Tue, May 17, 2016 at 9:08 AM, Will Stevens 
> wrote:
>
>> Alright, i have it running on one of my fast bbls.  I will keep you
>> posted...
>>
>> *Will STEVENS*
>> Lead Developer
>>
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>>
>> On Tue, May 17, 2016 at 8:53 AM, Daan Hoogland 
>> wrote:
>>
>>> thanks, I will see in my backlog if any PR is up for my next try.
>>>
>>> On Tue, May 17, 2016 at 2:52 PM, Will Stevens 
>>> wrote:
>>>
>>>> I will get that PR in one of my Bubbles today to see if I have problems.
>>>>
>>>> *Will STEVENS*
>>>> Lead Developer
>>>>
>>>> *CloudOps* *| *Cloud Solutions Experts
>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>> w cloudops.com *|* tw @CloudOps_
>>>>
>>>> On Tue, May 17, 2016 at 8:51 AM, Daan Hoogland >>> > wrote:
>>>>
>>>>> Rohit, the connector installs from epel and the mysql repo does not
>>>>> contain the python connector. I think we are not talking about the same
>>>>> problem.
>>>>>
>>>>> On Tue, May 17, 2016 at 2:40 PM, Daan Hoogland <
>>>>> daan.hoogl...@gmail.com> wrote:
>>>>>
>>>>>> I am now trying 1297, for the third time today.
>>>>>> next to the rpm-build error, I had an error in building the UI and it
>>>>>> just stopped with the rpm-build error again.
>>>>>> I did go to master in the bubble scripts. I had to re-add the java7
>>>>>> conf and change the config to use the cloudstack section. Other than that
>>>>>> it seems to work. The rpm-build error arose before going to the head of 
>>>>>> the
>>>>>> bubble branch, so I don't think it is related to the bubble itself.
>>>>>>
>>>>>> On Tue, May 17, 2016 at 2:32 PM, Will Stevens 
>>>>>> wrote:
>>>>>>
>>>>>>> Can you send me the error you are getting?  Also, are you testing
>>>>>>> against 4.7, 4.8 or master?
>>>>>>>
>>>>>>> *Will STEVENS*
>>>>>>> Lead Developer
>>>>>>>
>>>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 8:26 AM, Daan Hoogland <
>>>>>>> daan.hoogl...@gmail.com> wrote:
>>>>>>>
>>>>>>>> H Will, I don't want to break your mojo on this other bughunting
>>>>>>>> but do you see any rpm packaging errors concerning mysql-connector?
>>>>>>>> I added the repo for mysql to find out the connector was already
>>>>>>>> installed.
>>>>>>>>
>>>>>>>> BTW this is only one of four to five intermittent errors I'm
>>>>>>>> getting. Hardly any run succeeds.
>>>>>>>>
>>>>>>>> On Tue, May 17, 2016 at 1:55 PM, Will Stevens <
>>>>>>>> wstev...@cloudops.com> wrote:
>>>>>>>>
>>>>>>>>> Yes. I did a clean setup in 6 CI environments. With these PRs in
>>>>>>>>> place all 6 had the addHost issue. I reverted and did a clean setup 
>>>>>>>>> again
>>>>>>>>> and all 6 came up perfectly.
>>>>>>>>>
>>>>>>>>> I am using bubble on commit
>>>>>>>>> 9134cf8be930d0b982829da216471feaf214621f to test. I create the CS and 
>>>>>>>>> KVM
>>>>>>>>&g

Re: old error back?

[Daan Hoogland]

thanks, I will see in my backlog if any PR is up for my next try.

On Tue, May 17, 2016 at 2:52 PM, Will Stevens  wrote:

> I will get that PR in one of my Bubbles today to see if I have problems.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Tue, May 17, 2016 at 8:51 AM, Daan Hoogland 
> wrote:
>
>> Rohit, the connector installs from epel and the mysql repo does not
>> contain the python connector. I think we are not talking about the same
>> problem.
>>
>> On Tue, May 17, 2016 at 2:40 PM, Daan Hoogland 
>> wrote:
>>
>>> I am now trying 1297, for the third time today.
>>> next to the rpm-build error, I had an error in building the UI and it
>>> just stopped with the rpm-build error again.
>>> I did go to master in the bubble scripts. I had to re-add the java7 conf
>>> and change the config to use the cloudstack section. Other than that it
>>> seems to work. The rpm-build error arose before going to the head of the
>>> bubble branch, so I don't think it is related to the bubble itself.
>>>
>>> On Tue, May 17, 2016 at 2:32 PM, Will Stevens 
>>> wrote:
>>>
>>>> Can you send me the error you are getting?  Also, are you testing
>>>> against 4.7, 4.8 or master?
>>>>
>>>> *Will STEVENS*
>>>> Lead Developer
>>>>
>>>> *CloudOps* *| *Cloud Solutions Experts
>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>> w cloudops.com *|* tw @CloudOps_
>>>>
>>>> On Tue, May 17, 2016 at 8:26 AM, Daan Hoogland >>> > wrote:
>>>>
>>>>> H Will, I don't want to break your mojo on this other bughunting but
>>>>> do you see any rpm packaging errors concerning mysql-connector?
>>>>> I added the repo for mysql to find out the connector was already
>>>>> installed.
>>>>>
>>>>> BTW this is only one of four to five intermittent errors I'm getting.
>>>>> Hardly any run succeeds.
>>>>>
>>>>> On Tue, May 17, 2016 at 1:55 PM, Will Stevens 
>>>>> wrote:
>>>>>
>>>>>> Yes. I did a clean setup in 6 CI environments. With these PRs in
>>>>>> place all 6 had the addHost issue. I reverted and did a clean setup again
>>>>>> and all 6 came up perfectly.
>>>>>>
>>>>>> I am using bubble on commit 9134cf8be930d0b982829da216471feaf214621f
>>>>>> to test. I create the CS and KVM instances and then check out the code 
>>>>>> and
>>>>>> deploy (two script in bubble).
>>>>>>
>>>>>> Once ACS is up and running it does a DeployDC and it fails at this
>>>>>> point.
>>>>>>
>>>>>> I can test your PR and send you the logs.
>>>>>> On May 17, 2016 12:40 AM, "Rohit Yadav"  wrote:
>>>>>>
>>>>>>> Will,
>>>>>>>
>>>>>>> Alright, I've reopened a PR with the changes that were reverted to
>>>>>>> be reviewed/tested separately again. Can you share if you're able to get
>>>>>>> your CI env working again after the revert?
>>>>>>> Can you share in detail how may I reproduce the issues you get that
>>>>>>> you think are because of Nio related changes, so I can try to fix them.
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 2:49 AM, Will Stevens >>>>>> > wrote:
>>>>>>>
>>>>>>>> I would be running these commands:
>>>>>>>>
>>>>>>>> git revert 540d9572fd491db3ce182d26636fc74ada4e171c   (1543)
>>>>>>>> git revert f88cb880974fa56866492c437af291e40bd1a4f6 -m 1  (1538)
>>>>>>>> git revert 9f970f28b18534dffe33196ead60ea861f501fa9 -m 1  (1534)
>>>>>>>> git revert 7ce0e10fbcd949375e43535aae168421ecdaa562 -m 1  (1493)
>>>>>>>>
>>>>>>>> *Will STEVENS*
>>>>>>>> Lead Developer
>>>>>>>>
>>>>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>>>>> 420 rue Guy *|* Montreal *|* Qu

Re: old error back?

[Daan Hoogland]

Rohit, the connector installs from epel and the mysql repo does not contain
the python connector. I think we are not talking about the same problem.

On Tue, May 17, 2016 at 2:40 PM, Daan Hoogland 
wrote:

> I am now trying 1297, for the third time today.
> next to the rpm-build error, I had an error in building the UI and it just
> stopped with the rpm-build error again.
> I did go to master in the bubble scripts. I had to re-add the java7 conf
> and change the config to use the cloudstack section. Other than that it
> seems to work. The rpm-build error arose before going to the head of the
> bubble branch, so I don't think it is related to the bubble itself.
>
> On Tue, May 17, 2016 at 2:32 PM, Will Stevens 
> wrote:
>
>> Can you send me the error you are getting?  Also, are you testing against
>> 4.7, 4.8 or master?
>>
>> *Will STEVENS*
>> Lead Developer
>>
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>>
>> On Tue, May 17, 2016 at 8:26 AM, Daan Hoogland 
>> wrote:
>>
>>> H Will, I don't want to break your mojo on this other bughunting but do
>>> you see any rpm packaging errors concerning mysql-connector?
>>> I added the repo for mysql to find out the connector was already
>>> installed.
>>>
>>> BTW this is only one of four to five intermittent errors I'm getting.
>>> Hardly any run succeeds.
>>>
>>> On Tue, May 17, 2016 at 1:55 PM, Will Stevens 
>>> wrote:
>>>
>>>> Yes. I did a clean setup in 6 CI environments. With these PRs in place
>>>> all 6 had the addHost issue. I reverted and did a clean setup again and all
>>>> 6 came up perfectly.
>>>>
>>>> I am using bubble on commit 9134cf8be930d0b982829da216471feaf214621f to
>>>> test. I create the CS and KVM instances and then check out the code and
>>>> deploy (two script in bubble).
>>>>
>>>> Once ACS is up and running it does a DeployDC and it fails at this
>>>> point.
>>>>
>>>> I can test your PR and send you the logs.
>>>> On May 17, 2016 12:40 AM, "Rohit Yadav"  wrote:
>>>>
>>>>> Will,
>>>>>
>>>>> Alright, I've reopened a PR with the changes that were reverted to be
>>>>> reviewed/tested separately again. Can you share if you're able to get your
>>>>> CI env working again after the revert?
>>>>> Can you share in detail how may I reproduce the issues you get that
>>>>> you think are because of Nio related changes, so I can try to fix them.
>>>>> Thanks.
>>>>>
>>>>> Regards.
>>>>>
>>>>> On Tue, May 17, 2016 at 2:49 AM, Will Stevens 
>>>>> wrote:
>>>>>
>>>>>> I would be running these commands:
>>>>>>
>>>>>> git revert 540d9572fd491db3ce182d26636fc74ada4e171c   (1543)
>>>>>> git revert f88cb880974fa56866492c437af291e40bd1a4f6 -m 1  (1538)
>>>>>> git revert 9f970f28b18534dffe33196ead60ea861f501fa9 -m 1  (1534)
>>>>>> git revert 7ce0e10fbcd949375e43535aae168421ecdaa562 -m 1  (1493)
>>>>>>
>>>>>> *Will STEVENS*
>>>>>> Lead Developer
>>>>>>
>>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>
>>>>>> On Mon, May 16, 2016 at 5:19 PM, Will Stevens 
>>>>>> wrote:
>>>>>>
>>>>>>> I think I am going to have to revert #1493 (
>>>>>>> https://github.com/apache/cloudstack/pull/1493) because it seems to
>>>>>>> be responsible for the `addHost` issue I am having in all my CI
>>>>>>> environments while doing DeployDC.  On completely new deployments, I got
>>>>>>> the `addHost` error on all 6 of my CI environments with #1493 included. 
>>>>>>>  I
>>>>>>> have noticed this as an intermittent issue for the last while, but could
>>>>>>> not isolate it.
>>>>>>>
>>>>>>> I have reverted #1493 (and it's descendants) locally and I have not
>>>>>>> had the error in my first 3 tests after reverting it.  I only started
>>>>>>> seeing th

Re: old error back?

[Daan Hoogland]

I am now trying 1297, for the third time today.
next to the rpm-build error, I had an error in building the UI and it just
stopped with the rpm-build error again.
I did go to master in the bubble scripts. I had to re-add the java7 conf
and change the config to use the cloudstack section. Other than that it
seems to work. The rpm-build error arose before going to the head of the
bubble branch, so I don't think it is related to the bubble itself.

On Tue, May 17, 2016 at 2:32 PM, Will Stevens  wrote:

> Can you send me the error you are getting?  Also, are you testing against
> 4.7, 4.8 or master?
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Tue, May 17, 2016 at 8:26 AM, Daan Hoogland 
> wrote:
>
>> H Will, I don't want to break your mojo on this other bughunting but do
>> you see any rpm packaging errors concerning mysql-connector?
>> I added the repo for mysql to find out the connector was already
>> installed.
>>
>> BTW this is only one of four to five intermittent errors I'm getting.
>> Hardly any run succeeds.
>>
>> On Tue, May 17, 2016 at 1:55 PM, Will Stevens 
>> wrote:
>>
>>> Yes. I did a clean setup in 6 CI environments. With these PRs in place
>>> all 6 had the addHost issue. I reverted and did a clean setup again and all
>>> 6 came up perfectly.
>>>
>>> I am using bubble on commit 9134cf8be930d0b982829da216471feaf214621f to
>>> test. I create the CS and KVM instances and then check out the code and
>>> deploy (two script in bubble).
>>>
>>> Once ACS is up and running it does a DeployDC and it fails at this
>>> point.
>>>
>>> I can test your PR and send you the logs.
>>> On May 17, 2016 12:40 AM, "Rohit Yadav"  wrote:
>>>
>>>> Will,
>>>>
>>>> Alright, I've reopened a PR with the changes that were reverted to be
>>>> reviewed/tested separately again. Can you share if you're able to get your
>>>> CI env working again after the revert?
>>>> Can you share in detail how may I reproduce the issues you get that you
>>>> think are because of Nio related changes, so I can try to fix them. Thanks.
>>>>
>>>> Regards.
>>>>
>>>> On Tue, May 17, 2016 at 2:49 AM, Will Stevens 
>>>> wrote:
>>>>
>>>>> I would be running these commands:
>>>>>
>>>>> git revert 540d9572fd491db3ce182d26636fc74ada4e171c   (1543)
>>>>> git revert f88cb880974fa56866492c437af291e40bd1a4f6 -m 1  (1538)
>>>>> git revert 9f970f28b18534dffe33196ead60ea861f501fa9 -m 1  (1534)
>>>>> git revert 7ce0e10fbcd949375e43535aae168421ecdaa562 -m 1  (1493)
>>>>>
>>>>> *Will STEVENS*
>>>>> Lead Developer
>>>>>
>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>
>>>>> On Mon, May 16, 2016 at 5:19 PM, Will Stevens 
>>>>> wrote:
>>>>>
>>>>>> I think I am going to have to revert #1493 (
>>>>>> https://github.com/apache/cloudstack/pull/1493) because it seems to
>>>>>> be responsible for the `addHost` issue I am having in all my CI
>>>>>> environments while doing DeployDC.  On completely new deployments, I got
>>>>>> the `addHost` error on all 6 of my CI environments with #1493 included.  
>>>>>> I
>>>>>> have noticed this as an intermittent issue for the last while, but could
>>>>>> not isolate it.
>>>>>>
>>>>>> I have reverted #1493 (and it's descendants) locally and I have not
>>>>>> had the error in my first 3 tests after reverting it.  I only started
>>>>>> seeing the problem after #1493.
>>>>>>
>>>>>> With the freeze basically here, I need my CI environments in action
>>>>>> cause I have a few PRs that I really want to run before I merge and
>>>>>> freeze...
>>>>>>
>>>>>> *Will STEVENS*
>>>>>> Lead Developer
>>>>>>
>>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>> w cloudops.com *|* tw @CloudOps_
>&

Re: old error back?

[Daan Hoogland]

H Will, I don't want to break your mojo on this other bughunting but do you
see any rpm packaging errors concerning mysql-connector?
I added the repo for mysql to find out the connector was already installed.

BTW this is only one of four to five intermittent errors I'm getting.
Hardly any run succeeds.

On Tue, May 17, 2016 at 1:55 PM, Will Stevens  wrote:

> Yes. I did a clean setup in 6 CI environments. With these PRs in place all
> 6 had the addHost issue. I reverted and did a clean setup again and all 6
> came up perfectly.
>
> I am using bubble on commit 9134cf8be930d0b982829da216471feaf214621f to
> test. I create the CS and KVM instances and then check out the code and
> deploy (two script in bubble).
>
> Once ACS is up and running it does a DeployDC and it fails at this point.
>
> I can test your PR and send you the logs.
> On May 17, 2016 12:40 AM, "Rohit Yadav"  wrote:
>
>> Will,
>>
>> Alright, I've reopened a PR with the changes that were reverted to be
>> reviewed/tested separately again. Can you share if you're able to get your
>> CI env working again after the revert?
>> Can you share in detail how may I reproduce the issues you get that you
>> think are because of Nio related changes, so I can try to fix them. Thanks.
>>
>> Regards.
>>
>> On Tue, May 17, 2016 at 2:49 AM, Will Stevens 
>> wrote:
>>
>>> I would be running these commands:
>>>
>>> git revert 540d9572fd491db3ce182d26636fc74ada4e171c   (1543)
>>> git revert f88cb880974fa56866492c437af291e40bd1a4f6 -m 1  (1538)
>>> git revert 9f970f28b18534dffe33196ead60ea861f501fa9 -m 1  (1534)
>>> git revert 7ce0e10fbcd949375e43535aae168421ecdaa562 -m 1  (1493)
>>>
>>> *Will STEVENS*
>>> Lead Developer
>>>
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> w cloudops.com *|* tw @CloudOps_
>>>
>>> On Mon, May 16, 2016 at 5:19 PM, Will Stevens 
>>> wrote:
>>>
>>>> I think I am going to have to revert #1493 (
>>>> https://github.com/apache/cloudstack/pull/1493) because it seems to be
>>>> responsible for the `addHost` issue I am having in all my CI environments
>>>> while doing DeployDC.  On completely new deployments, I got the `addHost`
>>>> error on all 6 of my CI environments with #1493 included.  I have noticed
>>>> this as an intermittent issue for the last while, but could not isolate it.
>>>>
>>>> I have reverted #1493 (and it's descendants) locally and I have not had
>>>> the error in my first 3 tests after reverting it.  I only started seeing
>>>> the problem after #1493.
>>>>
>>>> With the freeze basically here, I need my CI environments in action
>>>> cause I have a few PRs that I really want to run before I merge and
>>>> freeze...
>>>>
>>>> *Will STEVENS*
>>>> Lead Developer
>>>>
>>>> *CloudOps* *| *Cloud Solutions Experts
>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>> w cloudops.com *|* tw @CloudOps_
>>>>
>>>> On Mon, May 16, 2016 at 1:53 PM, Will Stevens 
>>>> wrote:
>>>>
>>>>> I mean revert them locally to test (for now)...
>>>>>
>>>>> *Will STEVENS*
>>>>> Lead Developer
>>>>>
>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>
>>>>> On Mon, May 16, 2016 at 1:53 PM, Will Stevens 
>>>>> wrote:
>>>>>
>>>>>> I am getting it more than not right now.  I am concerned we have a
>>>>>> bigger issue here.  It only started happening for me after #1493 went in,
>>>>>> but I don't want to blame it on that without knowing for sure.
>>>>>>
>>>>>> Maybe I will revert those ones and see if it changes anything...  :(
>>>>>>
>>>>>> *Will STEVENS*
>>>>>> Lead Developer
>>>>>>
>>>>>> *CloudOps* *| *Cloud Solutions Experts
>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>>>>> w cloudops.com *|* tw @CloudOps_
>>>>>>
>>>>>> On Mon, May 16, 2016 at 1:45 PM, Daan Hoogland <
>>>>>> daan.hoogl...@gmail.com> wrote:
>>>>>>
>&g

Re: old error back?

[Daan Hoogland]

yes, I'm having the same thing. I need to restart the kvm1 vm to have it be
able to connect to the ms. It seems intermittent.

On Mon, May 16, 2016 at 7:38 PM, Will Stevens  wrote:

> I am currently running into an issue in DeployDC that I started getting on
> Thursday or Friday.  I am not sure if it is a bubble issue or an issue with
> ACS.
>
> I am trying to get it sorted out now...
>
>  Deploy DC Started 
>
> Exception Occurred :['Traceback (most recent call last):\n', '  File
> "/data/git/cs1/cloudstack/tools/marvin/marvin/deployDataCenter.py", line
> 142, in addHosts\nret = self.__apiClient.addHost(hostcmd)\n', '  File
>
> "/usr/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1530, in addHost\nresponse =
> self.connection.marvinRequest(command, response_type=response,
> method=method)\n', '  File
> "/usr/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute
> cmd: addhost failed, due to: errorCode: 530, errorText:Unable to add the
> host\n']
>
> Exception Occurred :['Traceback (most recent call last):\n', '  File
> "/data/git/cs1/cloudstack/tools/marvin/marvin/deployDataCenter.py", line
> 142, in addHosts\nret = self.__apiClient.addHost(hostcmd)\n', '  File
>
> "/usr/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1530, in addHost\nresponse =
> self.connection.marvinRequest(command, response_type=response,
> method=method)\n', '  File
> "/usr/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest\nraise e\n', 'CloudstackAPIException: Execute
> cmd: addhost failed, due to: errorCode: 530, errorText:Guid is not updated
> for cluster with specified cluster id; need to wait for hosts in this
> cluster to come up\n']
>
> ===deploy dc failed, so cleaning the created entries===
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Mon, May 16, 2016 at 12:51 PM, Daan Hoogland 
> wrote:
>
> > I understoud the request to try it out. I have #1547 running once again
> now
> > and will try Remi's new version with the next one i'll run.
> >
> > On Mon, May 16, 2016 at 6:34 PM, Will Stevens 
> > wrote:
> >
> > > Sorry. My phone decides to write whatever the hell it wants to. I need
> to
> > > proof read everything on my phone.  You can probably understand my
> > previous
> > > email though.
> > > On May 16, 2016 12:32 PM, "Will Stevens" 
> > wrote:
> > >
> > > > Remi and I have been discussing this. I suggested we implement an
> > > override
> > > > system so she could reuse lost of the code, but be able to override
> > files
> > > > specific to cosmic and cloudstack without impacting each other. Remi
> > > > implemented this concept and asked me to verify it is working as
> > > expected,
> > > > but I didn't want to push my luck with the freeze so close and I had
> > > > working bubbles.
> > > >
> > > > I think the recent changes are going to help mitigate issues going
> > > > forward, but I have not had a chance to validate yet.
> > > > On May 16, 2016 12:27 PM, "Daan Hoogland" 
> > > wrote:
> > > >
> > > >> trying that one but I think we need to add that repo to the cs
> system
> > in
> > > >> or
> > > >> before the build script. Also this is not the last (HEAD) of the
> > master
> > > >> branch of the bubble. I saw some cosmic specific changes. We have
> some
> > > >> challenges on the road ahead.
> > > >>
> > > >> On Mon, May 16, 2016 at 3:06 PM, Will Stevens <
> wstev...@cloudops.com>
> > > >> wrote:
> > > >>
> > > >> > Daan, I am using bubble commit
> > > 9134cf8be930d0b982829da216471feaf214621f
> > > >> and
> > > >> > things seem to be working.  Let me know if that is not working for
> > > >> you...
> > > >> >
> > > >> > *Will STEVENS*
> > > >> > Lead Developer
> > > >> >
> > > >> > *CloudOps* *| *Cloud Solutions Experts
> > > >> > 420 rue Gu

Re: old error back?

[Daan Hoogland]

I understoud the request to try it out. I have #1547 running once again now
and will try Remi's new version with the next one i'll run.

On Mon, May 16, 2016 at 6:34 PM, Will Stevens 
wrote:

> Sorry. My phone decides to write whatever the hell it wants to. I need to
> proof read everything on my phone.  You can probably understand my previous
> email though.
> On May 16, 2016 12:32 PM, "Will Stevens"  wrote:
>
> > Remi and I have been discussing this. I suggested we implement an
> override
> > system so she could reuse lost of the code, but be able to override files
> > specific to cosmic and cloudstack without impacting each other. Remi
> > implemented this concept and asked me to verify it is working as
> expected,
> > but I didn't want to push my luck with the freeze so close and I had
> > working bubbles.
> >
> > I think the recent changes are going to help mitigate issues going
> > forward, but I have not had a chance to validate yet.
> > On May 16, 2016 12:27 PM, "Daan Hoogland" 
> wrote:
> >
> >> trying that one but I think we need to add that repo to the cs system in
> >> or
> >> before the build script. Also this is not the last (HEAD) of the master
> >> branch of the bubble. I saw some cosmic specific changes. We have some
> >> challenges on the road ahead.
> >>
> >> On Mon, May 16, 2016 at 3:06 PM, Will Stevens 
> >> wrote:
> >>
> >> > Daan, I am using bubble commit
> 9134cf8be930d0b982829da216471feaf214621f
> >> and
> >> > things seem to be working.  Let me know if that is not working for
> >> you...
> >> >
> >> > *Will STEVENS*
> >> > Lead Developer
> >> >
> >> > *CloudOps* *| *Cloud Solutions Experts
> >> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >> > w cloudops.com *|* tw @CloudOps_
> >> >
> >> > On Mon, May 16, 2016 at 8:02 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> > > Thanks Rohit,
> >> > >
> >> > > I did try the manual install on the build host but that didn't help.
> >> I'll
> >> > > have a look at the extra yum repo to add later.
> >> > >
> >> > > On Mon, May 16, 2016 at 12:26 PM, Rohit Yadav <
> >> rohit.ya...@shapeblue.com
> >> > >
> >> > > wrote:
> >> > >
> >> > > > I checked this again today, with the recent changes wrt rpm
> >> > > deps/packaging
> >> > > > the mysql-connector-python is not availble in default CentOS
> >> > repositories
> >> > > > therefore we'll need to modify documentation to install it from
> >> MySQL
> >> > yum
> >> > > > repos:
> >> > > > http://dev.mysql.com/downloads/repo/yum
> >> > > >
> >> > > > Regards,
> >> > > > Rohit Yadav
> >> > > >
> >> > > >
> >> > > > Regards,
> >> > > >
> >> > > > Rohit Yadav
> >> > > >
> >> > > > rohit.ya...@shapeblue.com
> >> > > > www.shapeblue.com
> >> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >> > > > @shapeblue
> >> > > > On May 16 2016, at 8:37 am, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> >> > > wrote:
> >> > > >
> >> > > > Daan,
> >> > > >
> >> > > > mysql-connector-python was recently added as a pure-python
> >> dependency,
> >> > > can
> >> > > > you try to install that on your host system and retry rpm
> building.
> >> > > >
> >> > > > Regards.
> >> > > > 
> >> > > > From: Daan Hoogland 
> >> > > > Sent: 15 May 2016 14:34:49
> >> > > > To: dev
> >> > > > Subject: old error back?
> >> > > >
> >> > > > anybody else seeing this in the bubble or during rpm build?
> >> > > >
> >> > > > ```
> >> > > > error: Failed build dependencies:
> >> > > > mysql-connector-python is needed by
> >> > > > cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
> >> > > > RPM Build Failed
> >> > > > ```
> >> > > >
> >> > > > --
> >> > > > Daan
> >> > > >
> >> > > > Regards,
> >> > > >
> >> > > > Rohit Yadav
> >> > > >
> >> > > > rohit.ya...@shapeblue.com
> >> > > > www.shapeblue.com
> >> > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> >> > > > @shapeblue
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Daan
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Daan
> >>
> >
>



-- 
Daan

Re: old error back?

[Daan Hoogland]

trying that one but I think we need to add that repo to the cs system in or
before the build script. Also this is not the last (HEAD) of the master
branch of the bubble. I saw some cosmic specific changes. We have some
challenges on the road ahead.

On Mon, May 16, 2016 at 3:06 PM, Will Stevens  wrote:

> Daan, I am using bubble commit 9134cf8be930d0b982829da216471feaf214621f and
> things seem to be working.  Let me know if that is not working for you...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Mon, May 16, 2016 at 8:02 AM, Daan Hoogland 
> wrote:
>
> > Thanks Rohit,
> >
> > I did try the manual install on the build host but that didn't help. I'll
> > have a look at the extra yum repo to add later.
> >
> > On Mon, May 16, 2016 at 12:26 PM, Rohit Yadav  >
> > wrote:
> >
> > > I checked this again today, with the recent changes wrt rpm
> > deps/packaging
> > > the mysql-connector-python is not availble in default CentOS
> repositories
> > > therefore we'll need to modify documentation to install it from MySQL
> yum
> > > repos:
> > > http://dev.mysql.com/downloads/repo/yum
> > >
> > > Regards,
> > > Rohit Yadav
> > >
> > >
> > > Regards,
> > >
> > > Rohit Yadav
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > > On May 16 2016, at 8:37 am, Rohit Yadav 
> > wrote:
> > >
> > > Daan,
> > >
> > > mysql-connector-python was recently added as a pure-python dependency,
> > can
> > > you try to install that on your host system and retry rpm building.
> > >
> > > Regards.
> > > 
> > > From: Daan Hoogland 
> > > Sent: 15 May 2016 14:34:49
> > > To: dev
> > > Subject: old error back?
> > >
> > > anybody else seeing this in the bubble or during rpm build?
> > >
> > > ```
> > > error: Failed build dependencies:
> > > mysql-connector-python is needed by
> > > cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
> > > RPM Build Failed
> > > ```
> > >
> > > --
> > > Daan
> > >
> > > Regards,
> > >
> > > Rohit Yadav
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: old error back?

[Daan Hoogland]

Thanks Rohit,

I did try the manual install on the build host but that didn't help. I'll
have a look at the extra yum repo to add later.

On Mon, May 16, 2016 at 12:26 PM, Rohit Yadav 
wrote:

> I checked this again today, with the recent changes wrt rpm deps/packaging
> the mysql-connector-python is not availble in default CentOS repositories
> therefore we'll need to modify documentation to install it from MySQL yum
> repos:
> http://dev.mysql.com/downloads/repo/yum
>
> Regards,
> Rohit Yadav
>
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> On May 16 2016, at 8:37 am, Rohit Yadav  wrote:
>
> Daan,
>
> mysql-connector-python was recently added as a pure-python dependency, can
> you try to install that on your host system and retry rpm building.
>
> Regards.
> 
> From: Daan Hoogland 
> Sent: 15 May 2016 14:34:49
> To: dev
> Subject: old error back?
>
> anybody else seeing this in the bubble or during rpm build?
>
> ```
> error: Failed build dependencies:
> mysql-connector-python is needed by
> cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
> RPM Build Failed
> ```
>
> --
> Daan
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>



-- 
Daan

Re: old error back?

[Daan Hoogland]

sorry, i think you meaan to read #124

On Mon, May 16, 2016 at 12:00 AM, Daan Hoogland 
wrote:

> 3aa1707648f9a059bc30b71d4ad530815fcf92f5
>
> On Sun, May 15, 2016 at 11:20 PM, Will Stevens 
> wrote:
>
>> What PR are you on in your bubble?  There was a fix that went into bubble
>> for that, but I am not sure which PR.  There are some changes in bubble
>> which I have not had a chance to test yet.  Basically, the ability to
>> override configs so Cosmic and CloudStack can override files and reuse
>> more
>> of the code base.
>>
>> *Will STEVENS*
>> Lead Developer
>>
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>>
>> On Sun, May 15, 2016 at 5:04 AM, Daan Hoogland 
>> wrote:
>>
>> > anybody else seeing this in the bubble or during rpm build?
>> >
>> > ```
>> > error: Failed build dependencies:
>> > mysql-connector-python is needed by
>> > cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
>> > RPM Build Failed
>> > ```
>> >
>> > --
>> > Daan
>> >
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: old error back?

[Daan Hoogland]

3aa1707648f9a059bc30b71d4ad530815fcf92f5

On Sun, May 15, 2016 at 11:20 PM, Will Stevens 
wrote:

> What PR are you on in your bubble?  There was a fix that went into bubble
> for that, but I am not sure which PR.  There are some changes in bubble
> which I have not had a chance to test yet.  Basically, the ability to
> override configs so Cosmic and CloudStack can override files and reuse more
> of the code base.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Sun, May 15, 2016 at 5:04 AM, Daan Hoogland 
> wrote:
>
> > anybody else seeing this in the bubble or during rpm build?
> >
> > ```
> > error: Failed build dependencies:
> > mysql-connector-python is needed by
> > cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
> > RPM Build Failed
> > ```
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: Autoscaling without netscaler

[Daan Hoogland]

Adrian, I am not familiar with the autoscale functionality but are willing
to help you fix it. Do you have a (marvin) definition of an environment in
which the button should show but doesn't display? Can you send it or attach
to a jira ticket?

On Sun, May 15, 2016 at 4:56 AM, Adrian Sender 
wrote:

> Hi Guys,
>
> Autoscaling without a netscaler has been in the code since late 2013 it
> used
> to work in the UI as well. It looks like all of the 4.x releases have been
> missing the button it in the UI.
>
> Is there a reason it has not been enabled in the UI? it seems all the API
> functionality is there still.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-7751
>
> Not sure if it has been fixed in 4.8, this looks like a netscaler specific
> issue.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9235
>
> Regards,
> Adrian Sender
>
> Testlabs Australia
>
> M: +61.487-440-732
> E: asen...@testlabs.com.au
> W: www.testlabs.com.au
>



-- 
Daan

old error back?

[Daan Hoogland]

anybody else seeing this in the bubble or during rpm build?

```
error: Failed build dependencies:
mysql-connector-python is needed by
cloudstack-4.9.0-SNAPSHOT.el7.centos.x86_64
RPM Build Failed
```

-- 
Daan

Re: ACS PRs Status - 2016/05/12

[Daan Hoogland]

just resurfaced from testing 1536. I'm missing it in your list.

Get sleep and maybe a weekend now and again!

On Thu, May 12, 2016 at 11:02 PM, Will Stevens 
wrote:

> ACS PRs
>
>- 1537 - master (ready, pending Jenkins)
>- 1514 - 4.7 (pending Jenkins)
>- 1520 - master (ready, pending Jenkins)
>- 1482 - 4.7 (pending Jenkins & LGTM)
>- 1403 - master (pending LGTM, run CI again to be sure)
>- 1532 - master (ready, pending LGTM and Jenkins)
>- 956 - master (ready, pending Jenkins and verification)
>- 1516 - master (ready, pending Travis)
>- 1455 - master (ready, pending LGTM)
>- 1376 - master (ready, pending 1515 conflict)
>- 1280 - master (ready, pending LGTM)
>- 1424 - master (pending LGTM)
>- 1297 - master (pending verification)
>- 1464 - master (pending LGTM)
>- 1410 - 4.7 (ready, pending LGTM)
>- 1486 - 4.7 (ready, pending LGTM)
>- 1436 - master (CI posted, needs review)
>- * 1423 - master + svm (*pending CI)
>- 1371 - master + svm (figure out how to test)
>- 872 - master + svm (pending CI)
>- 866 - master (pending LGTM)
>- 1523 - master (*pending CI)
>- 1304 - master (needs work)
>- 1503 - master (bbl1)
>- 1513 - 4.8 (bbl2)
>- 1450 - 4.7 (ready, pending LGTM)
>- 1331 - 4.7 (cs1)
>- 1470 - 4.7 (being fixed)
>- 1471 - 4.7 (pending comments)
>- 1412 - 4.6 (pending ALL)
>- 1406 - 4.6 (pending LGTM)
>- 1378 - 4.6 (pending LGTM)
>- 1533 - master (pending LGTM)
>- 1491 - 4.7 (ready, pending LGTM)
>- 1360 - master (pending LGTM)
>- 1499 - master (pending ALL)
>- 883 - master (pending ALL)
>- 956 - master (needs work)
>- 846 - master (pending CI)
>- 1244 - master (needs work)
>- 1511 - master (bbl4)
>- 1530 (1351) - master (pending tests)
>- 1519 - 4.7 (needs work)
>- 1437 - master (pending HyperV CI)
>- 985 - master (bbl3)
>- 1269 - master (pending LGTM)
>- 669 - master (pending ALL)
>- 1494 - master (bbl3)
>- 1417 - master (marvin fails to import)
>- 1540 - master (pending LGTM and verification)
>
> ​Sorry this update is so late.  I have been pretty buried trying to stay on
> top of everything in preparation for the freeze next week.
>
> If you have some time *PLEASE* help out with some code review.  We have​ 18
> PRs that are pending LGTM reviews and most of them are ready to merge
> assuming I get some code review.
>
> I will be freezing master early next week.  I said Monday, but it will
> likely be Tuesday since I expect to have a lot of work trying to get the
> last stuff in that has been reviewed.
>
> If there are PRs that you think are ready that you think should be in 4.9,
> speak now or forever hold your peace.  I am doing my best to keep things
> moving and getting the different PRs into a good place...
>
> Right now we are down to *161 PRs* so we have definitely made progress.  I
> think there are another 20 that we could reasonably get in if we do a bit
> of a blitz of code review...
>
> Cheers,
>
> Will
>
> PS: I don't know how Remi did this for so long.  I need some sleep...  :P
>



-- 
Daan

Re: RM after 4.9

[Daan Hoogland]

Will, you are taking RM work yet another step in to our future, good work.
I of course hope the next RM will make us almost forget your achievements
as you are making us work to remember your predecessors (building on their
work of course).

On Wed, May 4, 2016 at 4:18 PM, Will Stevens 
wrote:

> Haha, ya I am hearing crickets...  :)
>
> We are slowly working towards systems which will remove a lot of the day to
> day work for the RM and will spread that work over the community better.
> Things like managing the status of the PRs and what is needed for them to
> move forward and testing to make sure PRs are not going to break anything.
> A lot of the tools we have not make things much easier, now we just need to
> get the repo moved so we can start using labels.
>
> On Wed, May 4, 2016 at 4:08 AM, Wido den Hollander  wrote:
>
> > Hi Will,
> >
> > Staying awfully silent in this thread.
> >
> > > Op 3 mei 2016 om 0:43 schreef Will Stevens :
> > >
> > >
> > > Hello All,
> > > As you all know, I am the RM for the 4.9 release.  Unfortunately, this
> is
> > > not a position I will be able to maintain for the long term, so we
> should
> > > start this discussion sooner rather than later.
> > >
> > > I am actively working to simplify the RM role by working towards the
> > > following goals:
> > > - Get the cloudstack repo moved to the 'apache-cloudstack' github org
> so
> > we
> > > can use labels, etc so the community can better organize itself
> regarding
> > > the status of different PRs
> >
> > Good, cool! Looking forward to that.
> >
> > > - Make it easier to setup distributed CI environments so the RM is not
> > > responsible for all the CI.
> > > - Build tooling to simplify contributing back the results of CI runs.
> > > - Improve our set of 'standard tests' to be more complete yet still
> > > manageable to be run on every PR.
> > >
> > > I will continue to work towards lowering the bar for the RM, but we
> need
> > to
> > > start the conversation of who is next in line as the RM.  :)
> > >
> >
> > I will not volunteer since I can't promise that I can dedicate the time
> it
> > takes to be a RM. Running a company and trying to be RM is something I
> > can't combine.
> >
> > Wido
> >
> > > Cheers,
> > >
> > > Will
> >
>



-- 
Daan

Re: [DISCUSS] Pull Requests Triage sprint

[Daan Hoogland]

great work Rohit, thanks

I will go through my work, hopefully within the coming day (1 earth spin)

On Mon, May 2, 2016 at 3:16 PM, Rohit Yadav 
wrote:

> All,
>
> I've tried to triage all open PRs, starting from oldest to newest. Based
> on my understanding, I've put tag: in comments (as tagging was not
> allowed on PRs) to sort them as following:
>
> tag:mergeready  - PRs that are ready for merge, may need one more
> LGTM
> tag:easypr - these are PRs with small changes, have 1+
> LGTM or can be easily reviewed
> tag:vmware-pickup   - vmware related PRs, that may need to be picked up
> (if the author has left project)
> tag:pickup - likely a PR that need to be picked up by
> someone
> tag:needlove- PR that can use some reviewing and are quite
> needed (such as strongswan PR)
> tag:closeme - old PRs that are already merged on 4.7+ or
> need to be reopened for 4.7+
>
> One can get a list of PRs by searching these keywords on
> github.com/apache/cloudstack/pulls.
> Hope this helps.
>
> Regards,
> Rohit Yadav
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>



-- 
Daan

Re: Build failed in Jenkins: build-master-jdk18 #509

[Daan Hoogland]

the timout on this job was 60, (or 400% of the last job) I upped it to 120
minuted

On Thu, Apr 28, 2016 at 11:58 PM, Will Stevens 
wrote:

> Some of the tests that were added can take some time, so is it possible to
> bump the timeout value on Jenkins?  If we were close before, we are going
> to be over now.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Thu, Apr 28, 2016 at 5:46 PM,  wrote:
>
>> See <http://jenkins.buildacloud.org/job/build-master-jdk18/509/changes>
>>
>> Changes:
>>
>> [anshul.gangwar] CLOUDSTACK-9194:  Making the console popup window
>> resizable in IE to
>>
>> [Daan Hoogland] CLOUDSTACK-9142 Migrate VM changes xmlDesc in a safe way
>>
>> [David Amorim Faria] CLOUDSTACK-9283: add pid to java arguments in
>>
>> [dmabry] Let hypervisor type KVM and Simulator detach root volumes.
>> Updated
>>
>> [dmabry] Modified test_volumes.py to include a hypervisor test for root
>>
>> [dmabry] Added required_hardware="false" attr above
>>
>> [Rohit Yadav] maven: Upgrade dependency versions
>>
>> [Rohit Yadav] framework/quota: fix checkstyle issue
>>
>> [Rohit Yadav] further maven dependency updates from Daan
>>
>> [Rohit Yadav] maven: fix dependency version support by JDK7
>>
>> [Rohit Yadav] engine/schema: fix upgrade path to work with MySQL 5.7
>>
>> [abhinandan.prateek] CLOUDSTACK-9323: Fix Cancel maintenance so that if
>> maintenance is
>>
>> [dmabry] Removed sleeps and used validateList as requested.
>>
>> [njohnson] Log responses from asynchronous api commands
>>
>> --
>> [...truncated 37087 lines...]
>> 2459/2764 KB
>> 2463/2764 KB
>> 2467/2764 KB
>> 2471/2764 KB
>> 2475/2764 KB
>> 2479/2764 KB
>> 2483/2764 KB
>> 2487/2764 KB
>> 2491/2764 KB
>> 2495/2764 KB
>> 2499/2764 KB
>> 2503/2764 KB
>> 2507/2764 KB
>> 2511/2764 KB
>> 2515/2764 KB
>> 2519/2764 KB
>> 2523/2764 KB
>> 2527/2764 KB
>> 2531/2764 KB
>> 2535/2764 KB
>> 2539/2764 KB
>> 2543/2764 KB
>> 2547/2764 KB
>> 2551/2764 KB
>> 2555/2764 KB
>> 2559/2764 KB
>> 2563/2764 KB
>> 2567/2764 KB
>> 2571/2764 KB
>> 2575/2764 KB
>> 2579/2764 KB
>> 2583/2764 KB
>> 2587/2764 KB
>> 2591/2764 KB
>> 2595/2764 KB
>> 2599/2764 KB
>> 2603/2764 KB
>> 2607/2764 KB
>> 2611/2764 KB
>> 2615/2764 KB
>> 2619/2764 KB
>> 2623/2764 KB
>> 2627/2764 KB
>> 2631/2764 KB
>> 2635/2764 KB
>> 2639/2764 KB
>> 2643/2764 KB
>> 2647/2764 KB
>> 2651/2764 KB
>> 2655/2764 KB
>> 2659/2764 KB
>> 2663/2764 KB
>> 2667/2764 KB
>> 2671/2764 KB
>> 2675/2764 KB
>> 2679/2764 KB
>> 2683/2764 KB
>> 2687/2764 KB
>> 2691/2764 KB
>> 2695/2764 KB
>> 2699/2764 KB
>> 2703/2764 KB
>> 2707/2764 KB
>> 2711/2764 KB
>> 2715/2764 KB
>> 2719/2764 KB
>> 2723/2764 KB
>> 2727/2764 KB
>> 2731/2764 KB
>> 2735/2764 KB
>> 2739/2764 KB
>> 2743/2764 KB
>> 2747/2764 KB
>> 2751/2764 KB
>> 2755/2764 KB
>> 2759/2764 KB
>> 2763/2764 KB
>> 2764/2764 KB
>>
>> Downloaded:
>> http://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/8.0.30/tomcat-embed-core-8.0.30.jar
>> (2764 KB at 9031.6 KB/sec)
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
>> cloudstack-service-console-proxy-rdpclient ---
>> [INFO] Deleting <
>> http://jenkins.buildacloud.org/job/build-master-jdk18/ws/services/console-proxy-rdp/rdpconsole/target>
>> (includes = [**/*], excludes = [])
>> [INFO] Deleting <
>> http://jenkins.buildacloud.org/job/build-master-jdk18/ws/services/console-proxy-rdp/rdpconsole>
>> (includes = [target, dist], excludes = [])
>> [INFO]
>> [INFO] --- maven-checkstyle-plugin:2.17:check (cloudstack-checkstyle) @
>> cloudstack-service-console-proxy-rdpclient ---
>> [INFO] Starting audit...
>> Audit done.
>> [INFO]
>> [INFO] --- maven-remote-resources-plugin:1.3:process (default) @
>> cloudstack-service-console-proxy-rdpclient ---
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
>> cloudstack-service-console-proxy-rdpclient ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding t

Re: [ANNOUNCE] New committer: Simon Weller

[Daan Hoogland]

welcome, kiwi. Good work and keep going.

On Thu, Apr 28, 2016 at 11:25 AM, Nick LIVENS  wrote:

> Congrats Simon!
>
> Kind regards,
> Nick Livens
>
> On Thu, Apr 28, 2016 at 10:15 AM, Nux!  wrote:
>
> > Congrats! :-)
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> > > From: "Paul Angus" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Thursday, 28 April, 2016 08:44:36
> > > Subject: RE: [ANNOUNCE] New committer: Simon Weller
> >
> > > Congratulations Simon!
> > >
> > >
> > >
> > > Kind regards,
> > >
> > > Paul Angus
> > >
> > > Regards,
> > >
> > > Paul Angus
> > >
> > > paul.an...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > > -Original Message-
> > > From: Erik Weber [mailto:terbol...@gmail.com]
> > > Sent: 28 April 2016 08:24
> > > To: dev 
> > > Subject: [ANNOUNCE] New committer: Simon Weller
> > >
> > > The Project Management Committee (PMC) for Apache CloudStack has asked
> > Simon
> > > Weller to become a committer and we are pleased to announce that they
> > have
> > > accepted.
> > >
> > >
> > > Being a committer allows many contributors to contribute more
> > autonomously. For
> > > developers, it makes it easier to submit changes and eliminates the
> need
> > to
> > > have contributions reviewed via the patch submission process. Whether
> > > contributions are development-related or otherwise, it is a recognition
> > of a
> > > contributor's participation in the project and commitment to the
> project
> > and
> > > the Apache Way.
> > >
> > > Please join me in congratulating Simon
> > >
> > > --Erik
> > > on behalf of the CloudStack PMC
> >
>



-- 
Daan

[ANNOUNCE] Rafael Weingartner joining the PMC

[Daan Hoogland]

Guess I should have facilitated everybody's mail filters

On Thu, Apr 28, 2016 at 12:59 PM, Daan Hoogland 
wrote:

> People,
>
> The PMC has ask Rafael to join them to oversee the project and he has
> gracefully accepted. Please join me in congratulating Rafael and wish him
> wisdom in his new task.
>
> ​on behalve of the PMC,​
> --
> Daan
>



-- 
Daan

Rafael Weingartner joining the PMC

[Daan Hoogland]

People,

The PMC has ask Rafael to join them to oversee the project and he has
gracefully accepted. Please join me in congratulating Rafael and wish him
wisdom in his new task.

​on behalve of the PMC,​
-- 
Daan

Re: [ANNOUNCE] Open source distributed virtual machine scheduling platform

[Daan Hoogland]

congratulation guys

On Tue, Apr 26, 2016 at 10:59 PM, Gabriel Beims Bräscher <
gabrasc...@gmail.com> wrote:

> Hello CloudStack community members (@dev and @users),
>
> This email is meant to announce the publication of a project on Github that
> provides a distributed virtual machine scheduling platform that can be
> easily integrated with Apache CloudStack (ACS). The project is available at
> [1], you can find a detailed explanation of the idea of the project, its
> aspirations, basic concepts, installation and uninstallation processes and
> other information at [2]. Also, if you want to know more about the
> Autonomiccs and its creators, you can access the link [3].
>
> The code that was opened at Github is part of a bigger system that has the
> goal of managing a cloud computing environment autonomously. All of that is
> being developed and used in my Ph. D. thesis and the masters’ thesis of
> some colleagues. The formalization of that component will be published at
> the 12th IEEE World Congress on Services (SERVICES 2016) at San Francisco
> USA.
>
> You can see the stats of our code at [4] and [5]. Right now we only have
> ~40% of code test coverage. However, we intend to increase that value to
> ~60% until next week and ~90% until the end of June.
>
> To give you a picture of what we are preparing for the future, we can
> highlight the following goals for this year (You can find others short term
> goals at [6]):
>
>-
>
>Integrate our platform [1] with a multi-agent system (MAS) platform, in
>order to facilitate the development of agents. Currently, we are using
>Spring-integration to “emulate” and an agent life cycle; that can
> become a
>problem when needing to add more agents and they start to communicate
> with
>each other. Therefore, we will integrate the platform in [1] with JADE
> [7];
>-
>
>Today the metrics about the use of resource are not properly gathered by
>ACS; in order to develop more accurate predictions we need to store
>resource usage metrics. Also, those metrics have to be gathered in a
>distributed way without causing service degradation. For that and a few
>other reasons (you can send us an email so we can provide you more
>details), we are developing an autonomic monitoring platform that will
>integrate with the system available in [1];
>-
>
>We also foresee the need to develop a better way to visualize the cloud
>environment, a way to detect hot spots (pods and hosts) with higher
>resource usage trends (VMs trends). We see the need to change the rustic
>view of the environment with tables for a better suitable one for humans
>(this is a surprise that we intend to present at the CCCBR).
>
> We hope you like the software and that it meets your expectations. If it
> does not suffice all of your needs, let’s work together to improve it. If
> you have any doubts or suggestions please send us an email; we will reply
> it as fast as we can. Also, critics that can help us improve that platform
> are very welcome.
>
> [1] https://github.com/Autonomiccs/autonomiccs-platform
>
> [2] https://github.com/Autonomiccs/autonomiccs-platform/wiki
>
> [3] http://autonomiccs.com.br/
>
> [4] http://jenkins.autonomiccs.com.br/
>
> [5] http://sonar.autonomiccs.com.br/
>
> [6] https://github.com/Autonomiccs/autonomiccs-platform#project-evolution
>
> [7] http://jade.tilab.com/
>
>
> Cheers, Gabriel.
>



-- 
Daan

Re: No module named marvin

[Daan Hoogland]

About travis. I only saw timeouts in the prepare scripts, so far.

On Tue, Apr 26, 2016 at 1:16 PM, Will Stevens 
wrote:

> Thank you for the hints re:Travis script. Will review that as well.  Travis
> has also been failing a lot recently though. That is another thing I need
> to review.
> On Apr 26, 2016 4:24 AM, "Rohit Yadav"  wrote:
>
> > Will, checkout tools/travis/install.sh for hints (much of travis scripts
> > can be used as hints on how to setup a marvin env).
> >
> > You'll need to install mysql-connector-python manually, unfortunately
> > oracle/mysql hosts them at their cdn and pypi/pip scks as not fetching
> > external deps on their own. So you'll need to do something like, pip
> > install --upgrade --egg 
> >
> > Regards.
> >
> > Regards,
> >
> > Rohit Yadav
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> > -Original Message-
> > From: Will Stevens [mailto:williamstev...@gmail.com]
> > Sent: Monday, April 25, 2016 11:37 PM
> > To: dev@cloudstack.apache.org
> > Subject: No module named marvin
> >
> > Could this:
> >
> > Deploy data center..
> > Traceback (most recent call last):
> >   File
> "/data/git/cs3/cloudstack/tools/marvin/marvin/deployDataCenter.py",
> > line 28, in 
> > from marvin import configGenerator
> > ImportError: No module named marvin
> >
> > Be caused by this:
> >
> > Installing Marvin
> > DEPRECATION: --allow-external has been deprecated and will be removed in
> > the future. Due to changes in the repository protocol, it no longer has
> any
> > effect.
> > Processing ./tools/marvin/dist/Marvin-4.9.0-SNAPSHOT.tar.gz
> > Collecting mysql-connector-python>=1.1.6 (from Marvin===4.9.0-SNAPSHOT)
> >   Could not find a version that satisfies the requirement
> > mysql-connector-python>=1.1.6 (from Marvin===4.9.0-SNAPSHOT) (from
> > versions: )
> > No matching distribution found for mysql-connector-python>=1.1.6 (from
> > Marvin===4.9.0-SNAPSHOT)
> >
> > This seems to be happening in all my CI environments this morning.
> > Thoughts?
> >
> > Thanks,
> >
> > Will
> >
>



-- 
Daan

Re: No module named marvin

[Daan Hoogland]

I had this some bubbles back. the mysql connector python driver is not the
stablest of packages it seems. I started a new environment in my bubble
last this afternoon (your morning). I will restart one later tonight, just
to see.

On Mon, Apr 25, 2016 at 8:06 PM, Will Stevens 
wrote:

> Could this:
>
> Deploy data center..
> Traceback (most recent call last):
>   File "/data/git/cs3/cloudstack/tools/marvin/marvin/deployDataCenter.py",
> line 28, in 
> from marvin import configGenerator
> ImportError: No module named marvin
>
> Be caused by this:
>
> Installing Marvin
> DEPRECATION: --allow-external has been deprecated and will be removed in
> the future. Due to changes in the repository protocol, it no longer has any
> effect.
> Processing ./tools/marvin/dist/Marvin-4.9.0-SNAPSHOT.tar.gz
> Collecting mysql-connector-python>=1.1.6 (from Marvin===4.9.0-SNAPSHOT)
>   Could not find a version that satisfies the requirement
> mysql-connector-python>=1.1.6 (from Marvin===4.9.0-SNAPSHOT) (from
> versions: )
> No matching distribution found for mysql-connector-python>=1.1.6 (from
> Marvin===4.9.0-SNAPSHOT)
>
> This seems to be happening in all my CI environments this morning.
> Thoughts?
>
> Thanks,
>
> Will
>



-- 
Daan

Re: Multithreaded Builds

[Daan Hoogland]

No Will, it was to prove you need extra hardware!

On Sat, Apr 23, 2016 at 3:55 PM, Will Stevens 
wrote:

> Haha. Awesome. :)
>
> This was more to validate that it was OK that I configure parallelism in my
> CI environment.
> On Apr 23, 2016 9:34 AM, "Ian Rae"  wrote:
>
> > Ok ok, point made, we can buy you new hardware Will ;)
> >
> > On Saturday, 23 April 2016, Will Stevens 
> wrote:
> >
> > > Thanks for the reports guys. :)
> > > On Apr 23, 2016 7:22 AM, "Paul Angus"  > > > wrote:
> > >
> > > > My local builds (Centos6 on VMware Workstation) run happily using 4
> > > cores.
> > > > The speed itself is down to my overclocked processor, but still, it
> > runs
> > > > stably on 4 cores running at 25% over there stock speed.
> > > >
> > > > mvn -T 4.0C -Dnoredist install
> > > >
> > > > [INFO] BUILD SUCCESS
> > > > [INFO]
> > > >
> > 
> > > > [INFO] Total time: 03:20 min (Wall Clock)
> > > >
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Paul Angus
> > > >
> > > > Regards,
> > > >
> > > > Paul Angus
> > > >
> > > > paul.an...@shapeblue.com 
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > > -Original Message-
> > > > From: Wido den Hollander [mailto:w...@widodh.nl ]
> > > > Sent: 22 April 2016 07:57
> > > > To: dev@cloudstack.apache.org 
> > > > Subject: Re: Multithreaded Builds
> > > >
> > > >
> > > >
> > > > > Op 22 apr. 2016 om 00:03 heeft Will Stevens <
> > williamstev...@gmail.com
> > > >
> > > > het volgende geschreven:
> > > > >
> > > > > Well the multithreaded build did complete successfully and it took.
> > > > >
> > > > > real7m3.933s
> > > > > user25m31.969s
> > > > > sys 3m2.880s
> > > > >
> > > > > Which compares to a non-multithreaded build on the same machine
> which
> > > > takes.
> > > > >
> > > > > real10m8.288s
> > > > > user18m23.564s
> > > > > sys 1m19.215s
> > > > >
> > > > > It is not a huge improvement, but for CI runs I will take any
> minutes
> > > > > I can shave.  :)
> > > > >
> > > >
> > > > Indeed! Locally I always run with 2C, works fine for me. Takes about
> 6
> > > > minutes to build.
> > > >
> > > > Wido
> > > >
> > > > > Cheers,
> > > > >
> > > > > Will
> > > > >
> > > > > On Thu, Apr 21, 2016 at 5:44 PM, Will Stevens
> > > > > >
> > > > > wrote:
> > > > >
> > > > >> Is it a reasonable expectation for ACS to be able to be built
> using
> > > > >> the `-T 1C` flag?  I am trying it now, but if it works once, it
> may
> > > > >> not mean that it would always work.
> > > > >>
> > > > >> I see a lot of messages like this:
> > > > >>
> > > > >> [WARNING]
> > > > *
> > > > >> [WARNING] * Your build is requesting parallel execution, but
> project
> > > >   *
> > > > >> [WARNING] * contains the following plugin(s) that have goals not
> > > > marked   *
> > > > >> [WARNING] * as @threadSafe to support parallel building.
> > > >   *
> > > > >> [WARNING] * While this /may/ work fine, please look for plugin
> > updates
> > > >   *
> > > > >> [WARNING] * and/or request plugins be made thread-safe.
> > > >*
> > > > >> [WARNING] * If reporting an issue, report it against the plugin in
> > > >   *
> > > > >> [WARNING] * question, not against maven-core
> > > >   *
> > > > >> [WARNING]
> > > > >> *
> > > > >> [WARNING] The following plugins are not marked @threadSafe in
> Apache
> > > > >> CloudStack Framework - Spring Life Cycle:
> > > > >> [WARNING] org.apache.maven.plugins:maven-site-plugin:3.1
> > > > >> [WARNING] Enable debug to see more precisely which goals are not
> > > > >> marked @threadSafe.
> > > > >> [WARNING]
> > > > >> *
> > > > >> [WARNING]
> > > > *
> > > > >> [WARNING] * Your build is requesting parallel execution, but
> project
> > > >   *
> > > > >> [WARNING] * contains the following plugin(s) that have goals not
> > > > marked   *
> > > > >> [WARNING] * as @threadSafe to support parallel building.
> > > >   *
> > > > >> [WARNING] * While this /may/ work fine, please look for plugin
> > updates
> > > >   *
> > > > >> [WARNING] * and/or request plugins be made thread-safe.
> > > >*
> > > > >> [WARNING] * If reporting an issue, report it against the plugin in
> > > >   *
> > > > >> [WARNING] * question, not against maven-core
> > > >   *
> > > > >> [WARNING]
> > > > >> *
> > > > >> [WARNING] The following plugins are not marked @threadSafe in
> Apache
> > > > >> CloudStack API:
> > > > >> [WARNING] org.apache.maven.plugins:maven-site-plugin:3.1
> > > > >> [WARNING] Enable debug to see more precisely which goals are not
> > > > >> marked @threadSafe.
> > > > >> [WARNING]
> >

Re: CaaS in CloudStack with Kubernetes

[Daan Hoogland]

Nice site, Go skipbox

On Sat, Apr 23, 2016 at 11:19 AM, Madan Ganesh Velayudham <
madangan...@actonmagic.com> wrote:

> +1 Sebastien; This is a great add to CloudStack.
>
> Congratulations to Skippbox and Shapeblue for this milestone.
>
> Would love to give it a real try to embrace it in AoC.
>
> Cheers
> Madan
>
> Madan Ganesh Velayudham
> Founder & CEO
> ActOnMagic
>
> *Cloud Governance, Management, Intelligence & Brokering **Simplified!*
> *www.actoncloud.com *
> @Go2Maga | @ActOnMagic | +91 966 336 7468
> 
> Important Disclaimer
>
> This message may contain confidential, proprietary or legally privileged
> information and is for the sole use of the intended recipient(s). Any
> unauthorised review, use, disclosure or distribution is strictly
> prohibited. If you are not the original intended recipient of the
> message, please reply to the sender and destroy all copies of the original
> message.
> www.actonmagic.com
> 
>
> On 22 April 2016 at 9:32:31 PM, Sebastien Goasguen (run...@gmail.com)
> wrote:
>
> Hi folks,
>
> I have been quite silent this past few weeks because aside from voting in
> a new VP (soon to be announced), I have been hard at work for my new
> endeavors with Skippbox.
>
> I am quite excited that today we could not wait and Skippbox together with
> Shapeblue announced a preview of a Kubernetes/CloudStack integration:
>
> http://www.benzinga.com/pressreleases/16/04/g7872516/shapeblue-harness-the-power-of-kubernetes-and-apache-cloudstack-to-give
>
> This is currently still a by request preview, but once we are done with
> much better testing and even tighter integration, the code will be open
> sourced as a CloudStack plugin.
>
> I wouldn’t mind couple supportive tweets and if you want a demo before you
> can run it yourself, ping me.
>
> Cheers,
>
> -Sebastien
>
>


-- 
Daan

Re: [DISCUSS] Using framework level API argument validation

[Daan Hoogland]

checked out the code, looks good Rohit. It will give us a handle to keep
the API from becoming even more inconsistent, and maybe even improve.

On Thu, Apr 21, 2016 at 1:07 PM, Rohit Yadav 
wrote:

> All,
>
> Whenever we've to write new APIs, we end up putting a lot of validations
> such as Strings.isNullOrEmpty or checks on API args such as on id we do
> this a lot getId() != null && getId() > 0 and on failing throw server api
> exception (as cloudstack entity ids are always > 0, such as ids of vms,
> volumes etc).
>
> While working on recent dynamic-roles PR, I ended up writing several such
> validations for all the new APIs and based on suggestions from John I could
> rid of all such checks by introducing a new @Parameter annotation field
> call validators() which is a list of validators we want to run for an API
> arg. This does not break any existing API which might have inconsistent
> assumptions (such as few accept id to be -1), and on local env all existing
> unit tests and smoke tests have passed.
>
> Please find an implementation in the dynamic-roles PR where all the new
> dynamic roles APIs use these annotations:
> https://github.com/apache/cloudstack/pull/1489
>
> Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-9361
>
> As soon as the PR is accepted and merged, I'll update the wiki page and we
> can get this pattern adopted over time:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Annotations+use+in+the+API
>
> Regards,
> Rohit Yadav
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>



-- 
Daan

Re: ACS Testing

[Daan Hoogland]

I think we want to test both, but we will have to consider and judge each
test on it's own merits.

We can start a run with everything from both directories as a parallel
track and then see what to do with the failing ones.

On Wed, Apr 20, 2016 at 11:52 PM, Will Stevens 
wrote:

> This is going to be a stupid question, but I don't know the answer, so I
> would like some guidance on this.
>
> Under 'cloudstack/test/integration/' there are the following folders:
> - component
> - smoke
> - plugins
> - testpaths
>
> Looking specifically at 'components' and 'smoke', there seems to be a lot
> of overlap in test cases.  Why would you test one vs the other?  Should we
> be testing both?
>
> Thanks,
>
> Will
> - The n00b RM -
>



-- 
Daan

Re: [DISCUSS] Network offerings for Isolated Networks / VPCs

[Daan Hoogland]

that came out wrong, I mean You are right!

On Wed, Apr 20, 2016 at 2:59 PM, Daan Hoogland 
wrote:

> thanks Will, That is a bummer and a discouragement.
>
> On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens 
> wrote:
>
>> Ws: Inline
>>
>> On Apr 20, 2016 8:24 AM, "Daan Hoogland"  wrote:
>> >
>> > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens > >
>> > wrote:
>> >
>> > > I'm not sure that is a good idea. There are a LOT of implications with
>> this
>> > > idea.
>> > >
>> > > For example, many hardware appliances can not handle overlapping ip
>> space
>> > > between networks. Because of this they can't be implemented in a vpc,
>> only
>> > > isolated guest networks.
>> > >
>> > ​Why is this a problem in VPC specifically, Will? Or more to the point
>> what
>> > do you mean by overlap?
>>
>> Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
>> external hardware device with an isolated guest network, the network guru
>> ensures that two networks do not have overlapping ip space, so that would
>> have to get added to vpcs as well.
>> >
>> > Even if a vpc would contain any kind of overlap, it would still mean
>> that
>> > those pieces of hardware can handle only one tier​. the implemetation of
>> > that tier would not matter, would it?
>> >
>> It means you would have to have a network appliance per vpc and they can't
>> be shared between multiple networks.
>>
>> My only point is that there are a lot of implications in this suggestion
>> which need to be thought through. It is not going to be as easy as people
>> may think. A bunch of functionality will have to be added to the vpcs and
>> a
>> lot of plugins will have to be rewritten.
>> >
>> > > I know there are a lot more examples like this, so it would be a
>> dramatic
>> >
>> > rewrite of a lot of code to make it work.
>> > >
>> > ​Nice, let's go. (pun intended only for those that want to see it)​
>> >
>> >
>> >
>> > > On Apr 20, 2016 12:49 AM, "Koushik Das" 
>> > > wrote:
>> > >
>> > > Another way to look at it would be to make isolated network a special
>> case
>> > > of VPC (having a single tier).
>> > >
>> > ​I would love to see that.​
>> >
>> >
>> >
>> > >
>> > > -Koushik
>> > >
>> > > 
>> > > From: Nick LIVENS 
>> > > Sent: Tuesday, April 19, 2016 2:46 PM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
>> > >
>> > > Hi all,
>> > >
>> > > Currently, there is no reliable way to tell whether an offering was
>> created
>> > > for an Isolated Network or for tiers in a VPC. This is determined
>> based
>> on
>> > > providers. (ConfigurationManagerImpl.isOfferingForVpc)
>> > >
>> > > In the UI, you have the possibility to check a flag for "VPC" during
>> > > creation of a network offering. This flag changes the list of
>> providers
>> per
>> > > service. However, this flag does not get sent to the backend, and is
>> not
>> > > persisted as a result.
>> > >
>> > > It is possible to create a network offering that was originally meant
>> for
>> > > VPCs, but without using any of those providers which results in a
>> network
>> > > offering that can't be used by VPCs because of this check. This is
>> very
>> > > confusing for an end user, and is actually wrong.
>> > >
>> > > Short term, I suggest we persist this flag "forvpc" in order to
>> determine
>> > > whether a network offering is meant for VPCs or Isolated Networks.
>> > >
>> > > Long term, we might want to rethink this implementation to a more
>> generic
>> > > solution to make network offerings usable for both Isolated Networks
>> and
>> > > VPCs at once, if possible.
>> > >
>> > > What do you guys think?
>> > >
>> > > Kind regards,
>> > > Nick Livens
>> > >
>> > >
>> > >
>> > > DISCLAIMER
>> > > ==
>> > > This e-mail may contain privileged and confidential information which
>> is
>> > > the property of Accelerite, a Persistent Systems business. It is
>> intended
>> > > only for the use of the individual or entity to which it is addressed.
>> If
>> > > you are not the intended recipient, you are not authorized to read,
>> retain,
>> > > copy, print, distribute or use this message. If you have received this
>> > > communication in error, please notify the sender and delete all copies
>> of
>> > > this message. Accelerite, a Persistent Systems business does not
>> accept
>> any
>> > > liability for virus infected mails.
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: [DISCUSS] Network offerings for Isolated Networks / VPCs

[Daan Hoogland]

thanks Will, That is a bummer and a discouragement.

On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens 
wrote:

> Ws: Inline
>
> On Apr 20, 2016 8:24 AM, "Daan Hoogland"  wrote:
> >
> > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens 
> > wrote:
> >
> > > I'm not sure that is a good idea. There are a LOT of implications with
> this
> > > idea.
> > >
> > > For example, many hardware appliances can not handle overlapping ip
> space
> > > between networks. Because of this they can't be implemented in a vpc,
> only
> > > isolated guest networks.
> > >
> > ​Why is this a problem in VPC specifically, Will? Or more to the point
> what
> > do you mean by overlap?
>
> Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
> external hardware device with an isolated guest network, the network guru
> ensures that two networks do not have overlapping ip space, so that would
> have to get added to vpcs as well.
> >
> > Even if a vpc would contain any kind of overlap, it would still mean that
> > those pieces of hardware can handle only one tier​. the implemetation of
> > that tier would not matter, would it?
> >
> It means you would have to have a network appliance per vpc and they can't
> be shared between multiple networks.
>
> My only point is that there are a lot of implications in this suggestion
> which need to be thought through. It is not going to be as easy as people
> may think. A bunch of functionality will have to be added to the vpcs and a
> lot of plugins will have to be rewritten.
> >
> > > I know there are a lot more examples like this, so it would be a
> dramatic
> >
> > rewrite of a lot of code to make it work.
> > >
> > ​Nice, let's go. (pun intended only for those that want to see it)​
> >
> >
> >
> > > On Apr 20, 2016 12:49 AM, "Koushik Das" 
> > > wrote:
> > >
> > > Another way to look at it would be to make isolated network a special
> case
> > > of VPC (having a single tier).
> > >
> > ​I would love to see that.​
> >
> >
> >
> > >
> > > -Koushik
> > >
> > > 
> > > From: Nick LIVENS 
> > > Sent: Tuesday, April 19, 2016 2:46 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
> > >
> > > Hi all,
> > >
> > > Currently, there is no reliable way to tell whether an offering was
> created
> > > for an Isolated Network or for tiers in a VPC. This is determined based
> on
> > > providers. (ConfigurationManagerImpl.isOfferingForVpc)
> > >
> > > In the UI, you have the possibility to check a flag for "VPC" during
> > > creation of a network offering. This flag changes the list of providers
> per
> > > service. However, this flag does not get sent to the backend, and is
> not
> > > persisted as a result.
> > >
> > > It is possible to create a network offering that was originally meant
> for
> > > VPCs, but without using any of those providers which results in a
> network
> > > offering that can't be used by VPCs because of this check. This is very
> > > confusing for an end user, and is actually wrong.
> > >
> > > Short term, I suggest we persist this flag "forvpc" in order to
> determine
> > > whether a network offering is meant for VPCs or Isolated Networks.
> > >
> > > Long term, we might want to rethink this implementation to a more
> generic
> > > solution to make network offerings usable for both Isolated Networks
> and
> > > VPCs at once, if possible.
> > >
> > > What do you guys think?
> > >
> > > Kind regards,
> > > Nick Livens
> > >
> > >
> > >
> > > DISCLAIMER
> > > ==
> > > This e-mail may contain privileged and confidential information which
> is
> > > the property of Accelerite, a Persistent Systems business. It is
> intended
> > > only for the use of the individual or entity to which it is addressed.
> If
> > > you are not the intended recipient, you are not authorized to read,
> retain,
> > > copy, print, distribute or use this message. If you have received this
> > > communication in error, please notify the sender and delete all copies
> of
> > > this message. Accelerite, a Persistent Systems business does not accept
> any
> > > liability for virus infected mails.
> > >
> >
> >
> >
> > --
> > Daan
>



-- 
Daan

Re: [DISCUSS] Emeritus Committer Status

[Daan Hoogland]

If their addresses are not valid? It would be a security measure for/from
my part.

On Wed, Apr 20, 2016 at 2:23 PM, John Burwell 
wrote:

> Daan,
>
> I disagree with automatically placing someone in emeritus status.  I think
> it is very important that some explicitly requests the status.
>
> Thanks,
> -John
>
> >
> Regards,
>
> John Burwell
>
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> On Apr 20, 2016, at 8:01 AM, Daan Hoogland 
> wrote:
> >
> > Guys, one thing is to ping their apache known forwarding address if we
> > suspect they are no longer active. Some might have still addresses of
> > former employers listed and those are emeritus when found, if I may have
> > that opinion.
>
>


-- 
Daan

Re: [DISCUSS] Network offerings for Isolated Networks / VPCs

[Daan Hoogland]

On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens 
wrote:

> I'm not sure that is a good idea. There are a LOT of implications with this
> idea.
>
> For example, many hardware appliances can not handle overlapping ip space
> between networks. Because of this they can't be implemented in a vpc, only
> isolated guest networks.
>
​Why is this a problem in VPC specifically, Will? Or more to the point what
do you mean by overlap?

Even if a vpc would contain any kind of overlap, it would still mean that
those pieces of hardware can handle only one tier​. the implemetation of
that tier would not matter, would it?


> I know there are a lot more examples like this, so it would be a dramatic

rewrite of a lot of code to make it work.
>
​Nice, let's go. (pun intended only for those that want to see it)​



> On Apr 20, 2016 12:49 AM, "Koushik Das" 
> wrote:
>
> Another way to look at it would be to make isolated network a special case
> of VPC (having a single tier).
>
​I would love to see that.​



>
> -Koushik
>
> 
> From: Nick LIVENS 
> Sent: Tuesday, April 19, 2016 2:46 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
>
> Hi all,
>
> Currently, there is no reliable way to tell whether an offering was created
> for an Isolated Network or for tiers in a VPC. This is determined based on
> providers. (ConfigurationManagerImpl.isOfferingForVpc)
>
> In the UI, you have the possibility to check a flag for "VPC" during
> creation of a network offering. This flag changes the list of providers per
> service. However, this flag does not get sent to the backend, and is not
> persisted as a result.
>
> It is possible to create a network offering that was originally meant for
> VPCs, but without using any of those providers which results in a network
> offering that can't be used by VPCs because of this check. This is very
> confusing for an end user, and is actually wrong.
>
> Short term, I suggest we persist this flag "forvpc" in order to determine
> whether a network offering is meant for VPCs or Isolated Networks.
>
> Long term, we might want to rethink this implementation to a more generic
> solution to make network offerings usable for both Isolated Networks and
> VPCs at once, if possible.
>
> What do you guys think?
>
> Kind regards,
> Nick Livens
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>



-- 
Daan

Re: [DISCUSS] Emeritus Committer Status

[Daan Hoogland]

Guys, one thing is to ping their apache known forwarding address if we
suspect they are no longer active. Some might have still addresses of
former employers listed and those are emeritus when found, if I may have
that opinion.

Re: [QUESTION] ACS 4.8 Centos 7 ARM / Raspberry PI B 2 with Intel KVM hypervisor

[Daan Hoogland]

H Patrick, nobody is answerring but I know they have, Not to start off with
as you intent to, though. Let us know.

On Tue, Apr 19, 2016 at 6:25 PM, Patrick Miller <
patrick.mil...@sungardas.com> wrote:

> I built  ACS 4.8 on Centos 7 ARM on a Raspberry PI B 2.  With ACS 4.8 built
> on a Centos 7 x86_68 for the cloudstack_agent code.
>
> And I am planning on managing a cluster of  Intel Centos 7 kvm hypervisors.
>
>  I was wonder if anyone has tried a mixed platform configuration before. I
> will report back my progress.
>
> Thanks
>   Patrick
>
> Patrick Miller ▪ Senior Systems Engineer ▪ Sungard Availability Services
> 2481 Deerwood Dr, San Ramon, Ca 94583 ▪  Office: 925-831-7738
> patrick.mil...@sungardas.com  ▪
> www.sungardas.com
>
>
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
>



-- 
Daan

anybody doing load testing?

[Daan Hoogland]

I will go to a talk this evening about http://gatling.io/ Is there anybody
busy testing cloudstack this way? What tools are you using?

​nice to hear,​
-- 
Daan

Re: [discuss] CloudStack logging

[Daan Hoogland]

Paul,

I think that asking for input is a good approach. Those that have problem
with a certain log message or - sequence are the best to say what should be
different.

Whether we should make hundreds of PRs or one?.. neither. I would say
change anything from a big class to a small package, or get the flow for
one API call and change anything in that. That would be cross package and
may require classes in the management -, service -, orchestration and
resource layers to be revisited for several flows.


On Fri, Apr 15, 2016 at 10:06 AM, Paul Angus 
wrote:

> Great, I'll pick up the issue that Wido has already created
> https://issues.apache.org/jira/browse/CLOUDSTACK-8645
>
> Does anyone have an suggestions wrt to structure of pull requests?
> I'm inclinded to ask the community for copies of logs - particularly ones
> that people have found difficult to read so that I or others can work
> through them looking for anamolies - it's very messy from a thoroughness
> point of view - but it would return the most useful changes first.  It also
> puts the error msg in a context to make the categorisation more acurate.
>
>
>
> Kind regards,
>
> Paul Angus
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
> -Original Message-
> From: Wido den Hollander [mailto:w...@widodh.nl]
> Sent: 14 April 2016 15:04
> To: Paul Angus ; dev@cloudstack.apache.org
> Subject: Re: [discuss] CloudStack logging
>
>
> > Op 14 april 2016 om 14:49 schreef Paul Angus :
> >
> >
> > Hi All
> >
> > I think that we can all agree that CloudStack logs are very difficult
> > to read, especially for operational staff.
> >
> > I believe that the primary reason for this is that a large amount of
> > what should be INFO level events are categorised as DEBUG.  The
> > logging therefore must be set at DEBUG for the logs to capture these
> > events.  By defaulting the logging to DEBUG we include a lot of detail
> > which is counter-productive when using the logs to diagnose operational
> issues.
> >
>
> Yes!
>
> > I think the situation can be greatly improved by reviewing the
> > categorisation of logged events and where necessary re-categorise then
> > such that INFO, WARN and ERROR logging would be sufficient for an
> 'operational' admin.
> >
> > I think a phased approach where the default logging level remains at
> > DEBUG while re-categorisation occurs would mean that nothing
> > materially changes until we are happy with the categorisations. Then
> > we can default the logging level to INFO.
> >
>
> I created a issue for this a while ago:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8645
>
> Short: Yes. Just change this where needed.
>
> Wido
>
> >
> >
> > Thoughts everyone?
> >
> >
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > Regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>



-- 
Daan

Re: [GitHub] cloudstack pull request: [CLOUDSTACK-9003] Resource Naming Policie...

[Daan Hoogland]

On Thu, Apr 14, 2016 at 4:14 PM, ProjectMoon  wrote:

> Github user ProjectMoon commented on the pull request:
>
> https://github.com/apache/cloudstack/pull/1492#issuecomment-209963503
>
> @DaanHoogland Do you have any kind of integration tests in mind?
>
​I could imagine a policy that keeps a static counter and name a resource
bla- and then checks if the next created resource has the
right name for each newly created resource; bla-?​


>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>



-- 
Daan

Re: [discuss] CloudStack logging

[Daan Hoogland]

On Thu, Apr 14, 2016 at 3:41 PM, Will Stevens 
wrote:

> Is there an easy way to do that Daan, or is it a tedious task you just have
> to power through?
>
​It is hard work, mostly tedious, sometimes hilarious and most definitely ​

​devops!​ It certainly wouldn't classify as development.




-- 
Daan

Re: Feature proposal: Resource naming policies

[Daan Hoogland]

sounds usefull for companies that for instance want to enforce uuid in name
or include some user string in it, same would be true for networks. look
forward to your design.

On Thu, Apr 14, 2016 at 1:40 PM, Jeff Hair  wrote:

> Yesterday, we submitted this pull request:
> https://github.com/apache/cloudstack/pull/1492
>
> This originally grew out of making the VirtualMachineName class non-static
> (original PR is mentioned in the above link). We're presenting this as a
> refactoring of the existing code to enable more extensibility and
> flexibility, make unit testing easier, and unify the way CloudStack
> generates resource names.
>
> There is an associated JIRA ticket at CLOUDSTACK-9003. I will be writing up
> a design document for the CS wiki in the next few days.
>
> jburwell wanted me to open a discussion on the developer list about the PR
> and how it is implemented:
>
> There is now a ResourceNamingPolicyManager and a bunch of
> ResourceNamingPolicies. The manager exposes a method to get a policy for a
> type of resource, and the naming policies generate UUIDs + resource names.
>
> The default naming policies generate names exactly the same way as they are
> created now. This is in a new module called default-naming-policies. By
> excluding this module and loading our own naming policies, we gain the
> ability to change how names are generated.
>



-- 
Daan

Re: [discuss] CloudStack logging

[Daan Hoogland]

I largely agree with just one sneer to the operators amongst us: the level
can be set on a per package and even class basis. So you can work through
disabling anoying logging step by step. Makes sense to keep looking at the
source in the meanwhile to make sure sensible diagnostics remains available.

On Thu, Apr 14, 2016 at 2:49 PM, Paul Angus 
wrote:

> Hi All
>
> I think that we can all agree that CloudStack logs are very difficult to
> read, especially for operational staff.
>
> I believe that the primary reason for this is that a large amount of what
> should be INFO level events are categorised as DEBUG.  The logging
> therefore must be set at DEBUG for the logs to capture these events.  By
> defaulting the logging to DEBUG we include a lot of detail which is
> counter-productive when using the logs to diagnose operational issues.
>
> I think the situation can be greatly improved by reviewing the
> categorisation of logged events and where necessary re-categorise then such
> that INFO, WARN and ERROR logging would be sufficient for an 'operational'
> admin.
>
> I think a phased approach where the default logging level remains at DEBUG
> while re-categorisation occurs would mean that nothing materially changes
> until we are happy with the categorisations. Then we can default the
> logging level to INFO.
>
>
>
> Thoughts everyone?
>
>
>
>
> Kind regards,
>
> Paul Angus
>
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>



-- 
Daan

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Daan Hoogland]

Mike, did the iso copy process not complete as expected. Sound like they
are a remanence of some task ending in an exception. Probably a silently
ignored one ;|

On Thu, Apr 14, 2016 at 2:49 AM, Tutkowski, Mike 
wrote:

> Just an FYI, but when I kicked off my first VM in this cloud, the VR
> happened to get deployed to XenServer-6.5-3 (which was one of my XenServer
> hosts that had an un-expected shared SR pointing at secondary storage
> beforehand).
>
> Once the process of copying the system template down to local storage
> completed, the shared SR pointing at secondary storage went away (as you
> would expect).
>
> This leaves me now with one un-expected shared SR pointing at secondary
> storage on XenServer-6.5-1.
>
> 
> From: Tutkowski, Mike 
> Sent: Wednesday, April 13, 2016 5:10 PM
> To: dev@cloudstack.apache.org
> Subject: Strange XenServer SR behavior when deploying system VMs in Basic
> Zone on 4.9
>
> Hi,
>
>
> Has anyone recently observed the following behavior:
>
>
> http://imgur.com/8ALJmWb
>
>
> As you can see in the image, I have three 6.5 XenServer hosts in a
> resource pool.
>
>
> I just used them when creating a basic zone and the system VMs were
> deployed just fine. However, there are SRs pointing to secondary storage on
> my XenServer-6.5-1 and XenServer-6.5-3 hosts still (there used to be one on
> my XenServer-6.5-2 host, but it went away once the system VMs started up on
> that host).
>
>
> Thoughts?
>
>
> Thanks,
>
> Mike
>



-- 
Daan

instances in test vpc without router

[Daan Hoogland]

@swill and @remibergsma

I saw this in the test
```
[dahn@blimbing ~]$ for i in 1 2 ; do ssh kvm$i virsh list; done
Warning: Permanently added 'kvm1,192.168.22.21' (ECDSA) to the list of
known hosts.
 IdName   State

 2 s-2-VM running
 3 v-1-VM running

Warning: Permanently added 'kvm2,192.168.22.22' (ECDSA) to the list of
known hosts.
 IdName   State

 10i-6-14-VM  running

```

It is still running but it doesn't promise success. You guys have seen this
as well? it seems the test kills the routers before it completes. talking
about the test_vpc_redundant of course.

-- 
Daan

Re: Introduction

[Daan Hoogland]

> 'new
> ​***'
>

​very welcome Rashmi, I hope you will feel comfortable in our snug little
community.​



-- 
Daan

Volunteers wanted: Masters Thesis on False Alarms in Test Failures

[Daan Hoogland]

People, Do we have enough meat on the bones to see this through?

On Fri, Apr 8, 2016 at 9:26 AM, Kevin van den Bekerom <
k.vandenbeke...@sig.eu> wrote:

> Hi Daan,
>
> I have a set of JIRA issue IDs from the authors (and can generate an
> updated list). These issues are Test Bugs. However, what is more
> interesting are the causes of these False Positives. To determine what
> category the Test Bug belongs to requires looking into the JIRA issue,
> comments, patches, etc.
>
> I only have 3 months to finish my Thesis. If I want to categorise  each
> issue myself I question the validity of my research for I can not gain
> extensive knowledge and understanding of the code in my limited time period.
>
> The original authors did this categorisation process themselves, investing
> 400 hours categorising roughly 550 Test Bugs (among many Apache Projects).
> However, I believe that with knowledge of the project, and an initial list
> of categories (constructing the categories took time as well!) this process
> can be cut in time significantly.
>
> I believe it should take a developer of the cloudstack project not more
> than 15 minutes to categorise one issue.
>
> If I have a set of categorised issues I can then look into common patterns
> among these issues. For that I need as much data I can get.
>
> I hope this clarifies. Please let me know if you (and hopefully more
> Cloudstack devs!) are willing to categorise a couple of issues. A few
> issues per week per person will come a long way :)
>
> Regards,
> Kevin
>
> > On 07 Apr 2016, at 20:56, Daan Hoogland  wrote:
> >
> > Kevin, what you intent to do sound promising. I think you are on your own
> > in collecting data but by the sound of it you allready have a list of 110
> > name/question pairs, do you? If not, how do you intent to do the
> collection
> > of the data you require?
> >
> > On Thu, Apr 7, 2016 at 4:04 PM, Kevin van den Bekerom <
> > k.vandenbeke...@sig.eu> wrote:
> >
> >> Dear Developers of the Apache Accumulo project,
> >>
> >>
> >>
> >> My name is Kevin van den Bekerom and I am currently doing my Master's
> >> research on the topic of false alarms in test code. I would like to ask
> the
> >> input of the Cloudstack development team categorizing test code bugs.
> >>
> >>
> >>
> >> My research is based on a recent paper by Arash et al. (
> >> http://salt.ece.ubc.ca/publications/docs/icsme15.pdf). They conducted
> an
> >> empirical study, categorizing "test code bugs" in Apache software
> projects,
> >> e.g. semantic, flaky, environmental, etc. A "test code bug" is a failing
> >> test, where the System Under Test is correct, but the test code is
> >> incorrect. To identify test code bugs they looked at issues in JIRA, and
> >> checked if the fixing commit was only in the test code. Only fixed
> issues
> >> were counted and categorised.
> >>
> >>
> >>
> >> My goal is to replicate their results using a different approach, i.e.
> ask
> >> developers that were involved in the issue and/or fix how they would
> >> categorize it.  For the Cloudstack project they counted 111 test code
> bugs.
> >> Insight into false positives can therefore be very relevant for your
> >> project. Note that they only sampled a number of identified test code
> bugs
> >> for individual inspection (30 for the Accumulo project).
> >>
> >>
> >> I would like to ask the Cloudstack team’s participation in categorizing
> the
> >> various test code bugs. I will provide a list of JIRA IDs which are
> >> identified as test code bugs and an initial list of categories to aid in
> >> the categorization process. In my belief, the developers that worked on
> the
> >> issue are the one's that are most capable of categorizing the issue.
> Please
> >> let me know if this project looks interesting to you and if you are
> willing
> >> to help me out.
> >>
> >>
> >>
> >> As a next step I will look for common patterns in identified test code
> bugs
> >> and my aim is to extent static source code analysis techniques to be
> also
> >> suited to find test code bugs. I am of course very happy to share my
> >> findings with the team.
> >>
> >>
> >>
> >> Hope to hear from you!
> >>
> >>
> >>
> >> With kind regards,
> >>
> >> Kevin van den Bekerom
> >> --
> >> *Kevin van den Bekerom* | Intern
> >>
> >> +31 6 21 33 93 85 | kvandenbeke...@sig.eu
> >> Software Improvement Group | www.sig.eu
> >>
> >
> >
> >
> > --
> > Daan
>
>


-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

For those interested: Fred and I have some adjustments for Fedora and as
Cloudstack we need to remain at java 1.7 for now while the SBP guys are
ahead of us at 1.8.

On Thu, Apr 7, 2016 at 10:30 PM, Remi Bergsma 
wrote:

> Great to see more and more people use the bubbles!
>
> Setting up:
> https://github.com/MissionCriticalCloud/bubble-blueprint
>
> Using:
> https://github.com/MissionCriticalCloud/bubble-toolkit
>
> Happy testing :-)
>
> Regards, Remi
>
> > On 07 Apr 2016, at 19:56, Will Stevens  wrote:
> >
> > If you want me to verify things in your env, you can send me a tmate
> > <https://tmate.io/> and I can have a look.
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Apr 7, 2016 at 1:54 PM, Daan Hoogland 
> > wrote:
> >
> >> yes, makes perfect sense. I skipped 1326 for now, I just tried to build
> >> 1436 it fails in the rpm build fase. I am now going to try that ui
> thing to
> >> build confidence in my test environment.
> >>
> >> On Thu, Apr 7, 2016 at 7:49 PM, Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> >>
> >>> Sure it makes.
> >>>
> >>>
> >>> On Thu, Apr 7, 2016 at 2:47 PM, Will Stevens 
> >>> wrote:
> >>>
> >>>> Yes, if the PR is ONLY a test and does not touch any other code then
> we
> >>> can
> >>>> only run that test.  I agree with you.
> >>>>
> >>>> If any code is changed outside the test, I always run the full suite.
> >>> Make
> >>>> sense?
> >>>>
> >>>> *Will STEVENS*
> >>>> Lead Developer
> >>>>
> >>>> *CloudOps* *| *Cloud Solutions Experts
> >>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >>>> w cloudops.com *|* tw @CloudOps_
> >>>>
> >>>> On Thu, Apr 7, 2016 at 1:41 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> running a new test in an environment should pass but should not
> >> require
> >>>> all
> >>>>> other test being re-validated. SO what is the point of running all
> >>>> others?
> >>>>> I am not saying we shouldn't regularly run all tests but in this case
> >>> it
> >>>>> adds no value AFAICT.
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 7, 2016 at 7:35 PM, Will Stevens 
> >>>>> wrote:
> >>>>>
> >>>>>> Yes, I want to run tests against the tests.  I have found issues in
> >>>> some
> >>>>> of
> >>>>>> the tests not working as expected, so I add the test to the run and
> >>> run
> >>>>>> them.  I think it is worth it because then we know the test is
> >> valid
> >>>>>> later.  I would rather have the author fix the test now if there
> >> are
> >>>>>> problems than having to work through it later.
> >>>>>>
> >>>>>> I am going to be doing a big push on getting testing cleaned up, so
> >>>> when
> >>>>> I
> >>>>>> start going through all the tests and validating them, I want to
> >>> reduce
> >>>>> the
> >>>>>> amount of work I have to do, so validating the tests at source
> >> makes
> >>>>> sense.
> >>>>>> :)
> >>>>>>
> >>>>>> *Will STEVENS*
> >>>>>> Lead Developer
> >>>>>>
> >>>>>> *CloudOps* *| *Cloud Solutions Experts
> >>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >>>>>> w cloudops.com *|* tw @CloudOps_
> >>>>>>
> >>>>>> On Thu, Apr 7, 2016 at 1:30 PM, Daan Hoogland <
> >>> daan.hoogl...@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> 1326 is just a test. it does not touch production code. Do we run
> >>>>>>> regression tests against such PRs. seems a waste to me.
> >>>>>>>
> >>>>>>> On Thu, Apr 7, 2016 at 7:27 PM, Daan Hoogland <
> >>>> daan.hoogl...@gmail.com
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Apr 7, 2016 at 7:26 PM, Daan Hoogland <
> >>>>> daan.hoogl...@gmail.com
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 1326 - master (*pending CI)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ​starting​
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Daan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Daan
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Daan
> >>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>
> >>
> >>
> >> --
> >> Daan
> >>
>



-- 
Daan

Re: Masters Thesis on False Alarms in Test Failures

[Daan Hoogland]

Kevin, what you intent to do sound promising. I think you are on your own
in collecting data but by the sound of it you allready have a list of 110
name/question pairs, do you? If not, how do you intent to do the collection
of the data you require?

On Thu, Apr 7, 2016 at 4:04 PM, Kevin van den Bekerom <
k.vandenbeke...@sig.eu> wrote:

> Dear Developers of the Apache Accumulo project,
>
>
>
> My name is Kevin van den Bekerom and I am currently doing my Master's
> research on the topic of false alarms in test code. I would like to ask the
> input of the Cloudstack development team categorizing test code bugs.
>
>
>
> My research is based on a recent paper by Arash et al. (
> http://salt.ece.ubc.ca/publications/docs/icsme15.pdf). They conducted an
> empirical study, categorizing "test code bugs" in Apache software projects,
> e.g. semantic, flaky, environmental, etc. A "test code bug" is a failing
> test, where the System Under Test is correct, but the test code is
> incorrect. To identify test code bugs they looked at issues in JIRA, and
> checked if the fixing commit was only in the test code. Only fixed issues
> were counted and categorised.
>
>
>
> My goal is to replicate their results using a different approach, i.e. ask
> developers that were involved in the issue and/or fix how they would
> categorize it.  For the Cloudstack project they counted 111 test code bugs.
> Insight into false positives can therefore be very relevant for your
> project. Note that they only sampled a number of identified test code bugs
> for individual inspection (30 for the Accumulo project).
>
>
> I would like to ask the Cloudstack team’s participation in categorizing the
> various test code bugs. I will provide a list of JIRA IDs which are
> identified as test code bugs and an initial list of categories to aid in
> the categorization process. In my belief, the developers that worked on the
> issue are the one's that are most capable of categorizing the issue. Please
> let me know if this project looks interesting to you and if you are willing
> to help me out.
>
>
>
> As a next step I will look for common patterns in identified test code bugs
> and my aim is to extent static source code analysis techniques to be also
> suited to find test code bugs. I am of course very happy to share my
> findings with the team.
>
>
>
> Hope to hear from you!
>
>
>
> With kind regards,
>
> Kevin van den Bekerom
> --
> *Kevin van den Bekerom* | Intern
>
> +31 6 21 33 93 85 | kvandenbeke...@sig.eu
> Software Improvement Group | www.sig.eu
>



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

yes, makes perfect sense. I skipped 1326 for now, I just tried to build
1436 it fails in the rpm build fase. I am now going to try that ui thing to
build confidence in my test environment.

On Thu, Apr 7, 2016 at 7:49 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Sure it makes.
>
>
> On Thu, Apr 7, 2016 at 2:47 PM, Will Stevens 
> wrote:
>
> > Yes, if the PR is ONLY a test and does not touch any other code then we
> can
> > only run that test.  I agree with you.
> >
> > If any code is changed outside the test, I always run the full suite.
> Make
> > sense?
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Apr 7, 2016 at 1:41 PM, Daan Hoogland 
> > wrote:
> >
> > > running a new test in an environment should pass but should not require
> > all
> > > other test being re-validated. SO what is the point of running all
> > others?
> > > I am not saying we shouldn't regularly run all tests but in this case
> it
> > > adds no value AFAICT.
> > >
> > >
> > > On Thu, Apr 7, 2016 at 7:35 PM, Will Stevens 
> > > wrote:
> > >
> > > > Yes, I want to run tests against the tests.  I have found issues in
> > some
> > > of
> > > > the tests not working as expected, so I add the test to the run and
> run
> > > > them.  I think it is worth it because then we know the test is valid
> > > > later.  I would rather have the author fix the test now if there are
> > > > problems than having to work through it later.
> > > >
> > > > I am going to be doing a big push on getting testing cleaned up, so
> > when
> > > I
> > > > start going through all the tests and validating them, I want to
> reduce
> > > the
> > > > amount of work I have to do, so validating the tests at source makes
> > > sense.
> > > >  :)
> > > >
> > > > *Will STEVENS*
> > > > Lead Developer
> > > >
> > > > *CloudOps* *| *Cloud Solutions Experts
> > > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > > > w cloudops.com *|* tw @CloudOps_
> > > >
> > > > On Thu, Apr 7, 2016 at 1:30 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > 1326 is just a test. it does not touch production code. Do we run
> > > > > regression tests against such PRs. seems a waste to me.
> > > > >
> > > > > On Thu, Apr 7, 2016 at 7:27 PM, Daan Hoogland <
> > daan.hoogl...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > On Thu, Apr 7, 2016 at 7:26 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> 1326 - master (*pending CI)
> > > > > >
> > > > > >
> > > > > > ​starting​
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Daan
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daan
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

running a new test in an environment should pass but should not require all
other test being re-validated. SO what is the point of running all others?
I am not saying we shouldn't regularly run all tests but in this case it
adds no value AFAICT.


On Thu, Apr 7, 2016 at 7:35 PM, Will Stevens  wrote:

> Yes, I want to run tests against the tests.  I have found issues in some of
> the tests not working as expected, so I add the test to the run and run
> them.  I think it is worth it because then we know the test is valid
> later.  I would rather have the author fix the test now if there are
> problems than having to work through it later.
>
> I am going to be doing a big push on getting testing cleaned up, so when I
> start going through all the tests and validating them, I want to reduce the
> amount of work I have to do, so validating the tests at source makes sense.
>  :)
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Thu, Apr 7, 2016 at 1:30 PM, Daan Hoogland 
> wrote:
>
> > 1326 is just a test. it does not touch production code. Do we run
> > regression tests against such PRs. seems a waste to me.
> >
> > On Thu, Apr 7, 2016 at 7:27 PM, Daan Hoogland 
> > wrote:
> >
> > >
> > > On Thu, Apr 7, 2016 at 7:26 PM, Daan Hoogland  >
> > > wrote:
> > >
> > >> 1326 - master (*pending CI)
> > >
> > >
> > > ​starting​
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

1326 is just a test. it does not touch production code. Do we run
regression tests against such PRs. seems a waste to me.

On Thu, Apr 7, 2016 at 7:27 PM, Daan Hoogland 
wrote:

>
> On Thu, Apr 7, 2016 at 7:26 PM, Daan Hoogland 
> wrote:
>
>> 1326 - master (*pending CI)
>
>
> ​starting​
>
>
>
> --
> Daan
>



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

On Thu, Apr 7, 2016 at 7:26 PM, Daan Hoogland 
wrote:

> 1326 - master (*pending CI)


​starting​



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

i just finished redoing 1459 but the first 5 tests failed so i aborted and
am looking for a new target

On Thu, Apr 7, 2016 at 7:24 PM, Will Stevens  wrote:

> Thanks Daan.  I really wish I had the ability to label PRs because that
> would make things SO much easier.
>
> I have these 3 pending CI, all of which need changes the the '
> helper_scripts/cloudstack/run_marvin_router_tests.sh' because they are PRs
> on tests, so we have to explicitly add the test to the CI run.
>
> 1455 - master (*pending CI)
> 1326 - master (*pending CI)
> 1436 - master (*pending CI)
>
> if you can start with them, that would be helpful because I can not test
> them in parallel with other CI runs because I have two stacks in the same
> bubble, so they are using the same '/data/share/' directory so changes to
> the 'run_marvin_router_tests.sh' file will be seen by both of my stacks.
> If you have any problems either Fred or I can get you sorted.  Fred has
> been a superstar helping me get setup.  :)
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Thu, Apr 7, 2016 at 1:00 PM, Daan Hoogland 
> wrote:
>
> > will, Fred Neubauer just helped me finalize my test environment on a
> fedora
> > laptop. I will be chipping away at the pile as well. hopefully at a rate
> of
> > one per day. I would like your directions as to which I can pick. of
> course
> > I can go my own way but double work is a shame.
> >
> > On Thu, Apr 7, 2016 at 6:48 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Hi Will, thanks for such a great job.
> > > I was going over the PRs we have in our merge list; I did a walk
> through
> > > till page 5, the others one I believe will require more work and some
> of
> > > the folks that have opened them, are a little bit off the community
> > lately.
> > > I found the following to be of some interest to be added in ACs 4.9
> (they
> > > are not ordered by any type of priority):
> > >
> > >- https://github.com/apache/cloudstack/pull/1441
> > >- https://github.com/apache/cloudstack/pull/1428
> > >- https://github.com/apache/cloudstack/pull/1423
> > >- https://github.com/apache/cloudstack/pull/1459
> > >- https://github.com/apache/cloudstack/pull/1457
> > >- https://github.com/apache/cloudstack/pull/1450
> > >
> > >
> > >
> > > On Thu, Apr 7, 2016 at 1:15 PM, Will Stevens  >
> > > wrote:
> > >
> > > > I know this is not how this usually works, but I need to crowd source
> > > some
> > > > info to be more effective.
> > > >
> > > > I am slowly getting things rolling for the 4.9 release.  My CI is
> > > chugging
> > > > away and I have a queue of PRs to get tested, so I will be getting
> > > through
> > > > them as quickly as I can.  I have finally gotten to where I have a
> > > > relatively steady stream of merges going in and I am working through
> > > final
> > > > logistics on a whole bunch.
> > > >
> > > > I would like some help prioritizing PRs that we feel MUST get into
> 4.9.
> > > > There are almost 200 PRs open right now so it is not realistic for me
> > to
> > > > expect to get them all into the 4.9 release simply due to the number
> of
> > > CI
> > > > hours needed.
> > > >
> > > > If you know of PRs that you think are important to get in, please
> reply
> > > > with a link to the Github PR so I can get them into my active list.
> > > >
> > > > One more thing...
> > > >
> > > > If you have any extra hardware available that is not currently being
> > used
> > > > and you are willing to help with the CI effort, please email me and I
> > > will
> > > > get you setup so you can contribute to testing.  I would like to try
> to
> > > get
> > > > a distributed network of CI environments working to better test the
> ACS
> > > > code base, so even if you only have the hardware free for 2 weeks, we
> > can
> > > > make use of it.  I can help you get the hardware up and running ready
> > for
> > > > testing in a couple hours.
> > > >
> > > > Thanks you for the support...
> > > >
> > > > Will
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: PRs for 4.9 Release

[Daan Hoogland]

will, Fred Neubauer just helped me finalize my test environment on a fedora
laptop. I will be chipping away at the pile as well. hopefully at a rate of
one per day. I would like your directions as to which I can pick. of course
I can go my own way but double work is a shame.

On Thu, Apr 7, 2016 at 6:48 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Hi Will, thanks for such a great job.
> I was going over the PRs we have in our merge list; I did a walk through
> till page 5, the others one I believe will require more work and some of
> the folks that have opened them, are a little bit off the community lately.
> I found the following to be of some interest to be added in ACs 4.9 (they
> are not ordered by any type of priority):
>
>- https://github.com/apache/cloudstack/pull/1441
>- https://github.com/apache/cloudstack/pull/1428
>- https://github.com/apache/cloudstack/pull/1423
>- https://github.com/apache/cloudstack/pull/1459
>- https://github.com/apache/cloudstack/pull/1457
>- https://github.com/apache/cloudstack/pull/1450
>
>
>
> On Thu, Apr 7, 2016 at 1:15 PM, Will Stevens 
> wrote:
>
> > I know this is not how this usually works, but I need to crowd source
> some
> > info to be more effective.
> >
> > I am slowly getting things rolling for the 4.9 release.  My CI is
> chugging
> > away and I have a queue of PRs to get tested, so I will be getting
> through
> > them as quickly as I can.  I have finally gotten to where I have a
> > relatively steady stream of merges going in and I am working through
> final
> > logistics on a whole bunch.
> >
> > I would like some help prioritizing PRs that we feel MUST get into 4.9.
> > There are almost 200 PRs open right now so it is not realistic for me to
> > expect to get them all into the 4.9 release simply due to the number of
> CI
> > hours needed.
> >
> > If you know of PRs that you think are important to get in, please reply
> > with a link to the Github PR so I can get them into my active list.
> >
> > One more thing...
> >
> > If you have any extra hardware available that is not currently being used
> > and you are willing to help with the CI effort, please email me and I
> will
> > get you setup so you can contribute to testing.  I would like to try to
> get
> > a distributed network of CI environments working to better test the ACS
> > code base, so even if you only have the hardware free for 2 weeks, we can
> > make use of it.  I can help you get the hardware up and running ready for
> > testing in a couple hours.
> >
> > Thanks you for the support...
> >
> > Will
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: [ACP Doctor] What is it?

[Daan Hoogland]

except that there is no link on that page to the scripts

On Thu, Apr 7, 2016 at 6:32 AM, ilya  wrote:

> Wow, a whole one page site dedicated to this endeavor :)
>
> On 4/6/16 9:22 PM, Will Stevens wrote:
> > FYI, It does still seem to be freely available:  http://ccpdoctor.com/
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Apr 7, 2016 at 12:11 AM, ilya 
> wrote:
> >
> >> Thanks for explanation Ian and Will.
> >>
> >> Much appreciated.
> >>
> >> On 4/5/16 8:33 PM, Ian Rae wrote:
> >>> I don't believe this is freely available, rather is a tool Citrix
> >> developed
> >>> for helping troubleshoot CCP customer deployments. I would imagine that
> >>> Accelerite owns this tool now and it is likely available if you are an
> >> ACP
> >>> customer, but not necessarily for ACS users.
> >>>
> >>> Probably best for Accelerite to comment.
> >>>
> >>> On Tuesday, 5 April 2016, Will Stevens  wrote:
> >>>
>  It used to be CCP Doctor and it is not in ACS from my understanding.
> >> It is
>  a set of scripts that will do basic validation of a CloudStack setup.
> >> It
>  does things like verify the system VMs are running and the
> connectivity
> >> is
>  working between all of the systems.  It also does some checking to
> make
>  sure the versions of software is correct and checks some things in the
> >> DB
>  as well.  It also collects a whole crap ton of logs and database dumps
> >> (i
>  think) and zips them up for easy transfer to support so they can get a
>  solid feel for your setup.
> 
>  It also has 'suggestions' for things you can do to fix different
> >> aspects of
>  your setup.  Things like setting 'ulimit' to 'unlimited' and will give
> >> you
>  the command to run.  It also lets you pass a 'fix' flag and it will
>  automagically make all the changes for you.  I am too paranoid to have
>  actually used the fix flag because I was always using this in
> production
>  environments and I am a little too risk averse to let a script do
> >> anything
>  for me (unless I wrote it).
> 
>  Does that answer your question?  It should be freely available and you
>  should be able to run it against ACS, so you should be able to try it
>  out...
> 
>  It is a pretty useful tool to be honest.  Especially if you are
>  troubleshooting an environment you didn't setup.
> 
>  *Will STEVENS*
>  Lead Developer
> 
>  *CloudOps* *| *Cloud Solutions Experts
>  420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>  w cloudops.com *|* tw @CloudOps_
> 
>  On Tue, Apr 5, 2016 at 5:28 PM, ilya   > wrote:
> 
> > Saw ACP Doctor in CCP release notes from Accelerite.
> >
> > Curious what it is, is it integrated into cloudstack or collection of
> > shell scripts?
> >
> > Thanks
> > ilya
> >
> 
> >>>
> >>>
> >>
> >
>



-- 
Daan

Re: Jenkins on PRs

[Daan Hoogland]

basically this means you have to ask the submitter, Will

On Wed, Apr 6, 2016 at 10:43 PM, Will Stevens  wrote:

> ok, thanks...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, Apr 6, 2016 at 4:37 PM, Daan Hoogland 
> wrote:
>
> > strangely the timeout wasn't reached on those jobs. I upped the timeout
> > anyway. let's see what happens.
> >
> > On Wed, Apr 6, 2016 at 10:30 PM, Daan Hoogland 
> > wrote:
> >
> > > you are right, there are three of those in the preserved history. I
> will
> > > look at the timeout configuration for the job.
> > >
> > > On Wed, Apr 6, 2016 at 10:28 PM, Will Stevens 
> > > wrote:
> > >
> > >> I have been seeing it fail more often than usual with "timeout"
> errors.
> > >>
> > >> For example, this PR: https://github.com/apache/cloudstack/pull/1461
> > >>
> > >> With this run:
> > >> https://builds.apache.org/job/cloudstack-pr-analysis/719/console
> > >>
> > >> *Will STEVENS*
> > >> Lead Developer
> > >>
> > >> *CloudOps* *| *Cloud Solutions Experts
> > >> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > >> w cloudops.com *|* tw @CloudOps_
> > >>
> > >> On Wed, Apr 6, 2016 at 4:17 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > >> wrote:
> > >>
> > >> > I've seen this one before:
> > >> >
> > >> > Tests in error:
> > >> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedNonSG:79
> > >> > NoSuchMethod ...
> > >> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedSG:102
> > >> > NoSuchMethod or...
> > >> >
> >  SecondaryStorageManagerTest.getDefaultNetworkForAdvancedWrongZoneType
> > >> > ?  Unexp...
> > >> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicNonSG:124
> > >> > NoSuchMethod or...
> > >> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicSG:147
> > >> > NoSuchMethod org.a...
> > >> >
>  SecondaryStorageManagerTest.getDefaultNetworkForBasicSGWrongZoneType
> > >> > ?  Unexpe...
> > >> >
> > >> >
> > >> > it has been a reason of failure in more then one.
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Apr 6, 2016 at 10:13 PM, Daan Hoogland <
> > daan.hoogl...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> > > looking at the history in [1] this is not true. most are
> succeeding.
> > >> > >
> > >> > >
> > >> > > [1]
> https://builds.apache.org/view/All/job/cloudstack-pr-analysis/
> > >> > >
> > >> > > On Wed, Apr 6, 2016 at 8:40 PM, Will Stevens <
> > >> williamstev...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > >> Hey All,
> > >> > >> Anyone know what is going on with Jenkins?  It seems to be
> failing
> > >> for
> > >> > >> most
> > >> > >> PRs.  It seems to be timing out, but I am not a Jenkins wizard...
> > >> > >>
> > >> > >> Cheers,
> > >> > >>
> > >> > >> Will
> > >> > >>
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Daan
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Daan
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: Jenkins on PRs

[Daan Hoogland]

strangely the timeout wasn't reached on those jobs. I upped the timeout
anyway. let's see what happens.

On Wed, Apr 6, 2016 at 10:30 PM, Daan Hoogland 
wrote:

> you are right, there are three of those in the preserved history. I will
> look at the timeout configuration for the job.
>
> On Wed, Apr 6, 2016 at 10:28 PM, Will Stevens 
> wrote:
>
>> I have been seeing it fail more often than usual with "timeout" errors.
>>
>> For example, this PR: https://github.com/apache/cloudstack/pull/1461
>>
>> With this run:
>> https://builds.apache.org/job/cloudstack-pr-analysis/719/console
>>
>> *Will STEVENS*
>> Lead Developer
>>
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>>
>> On Wed, Apr 6, 2016 at 4:17 PM, Daan Hoogland 
>> wrote:
>>
>> > I've seen this one before:
>> >
>> > Tests in error:
>> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedNonSG:79
>> > NoSuchMethod ...
>> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedSG:102
>> > NoSuchMethod or...
>> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedWrongZoneType
>> > ?  Unexp...
>> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicNonSG:124
>> > NoSuchMethod or...
>> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicSG:147
>> > NoSuchMethod org.a...
>> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicSGWrongZoneType
>> > ?  Unexpe...
>> >
>> >
>> > it has been a reason of failure in more then one.
>> >
>> >
>> >
>> > On Wed, Apr 6, 2016 at 10:13 PM, Daan Hoogland > >
>> > wrote:
>> >
>> > > looking at the history in [1] this is not true. most are succeeding.
>> > >
>> > >
>> > > [1] https://builds.apache.org/view/All/job/cloudstack-pr-analysis/
>> > >
>> > > On Wed, Apr 6, 2016 at 8:40 PM, Will Stevens <
>> williamstev...@gmail.com>
>> > > wrote:
>> > >
>> > >> Hey All,
>> > >> Anyone know what is going on with Jenkins?  It seems to be failing
>> for
>> > >> most
>> > >> PRs.  It seems to be timing out, but I am not a Jenkins wizard...
>> > >>
>> > >> Cheers,
>> > >>
>> > >> Will
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Daan
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: Jenkins on PRs

[Daan Hoogland]

you are right, there are three of those in the preserved history. I will
look at the timeout configuration for the job.

On Wed, Apr 6, 2016 at 10:28 PM, Will Stevens  wrote:

> I have been seeing it fail more often than usual with "timeout" errors.
>
> For example, this PR: https://github.com/apache/cloudstack/pull/1461
>
> With this run:
> https://builds.apache.org/job/cloudstack-pr-analysis/719/console
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, Apr 6, 2016 at 4:17 PM, Daan Hoogland 
> wrote:
>
> > I've seen this one before:
> >
> > Tests in error:
> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedNonSG:79
> > NoSuchMethod ...
> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedSG:102
> > NoSuchMethod or...
> >   SecondaryStorageManagerTest.getDefaultNetworkForAdvancedWrongZoneType
> > ?  Unexp...
> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicNonSG:124
> > NoSuchMethod or...
> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicSG:147
> > NoSuchMethod org.a...
> >   SecondaryStorageManagerTest.getDefaultNetworkForBasicSGWrongZoneType
> > ?  Unexpe...
> >
> >
> > it has been a reason of failure in more then one.
> >
> >
> >
> > On Wed, Apr 6, 2016 at 10:13 PM, Daan Hoogland 
> > wrote:
> >
> > > looking at the history in [1] this is not true. most are succeeding.
> > >
> > >
> > > [1] https://builds.apache.org/view/All/job/cloudstack-pr-analysis/
> > >
> > > On Wed, Apr 6, 2016 at 8:40 PM, Will Stevens  >
> > > wrote:
> > >
> > >> Hey All,
> > >> Anyone know what is going on with Jenkins?  It seems to be failing for
> > >> most
> > >> PRs.  It seems to be timing out, but I am not a Jenkins wizard...
> > >>
> > >> Cheers,
> > >>
> > >> Will
> > >>
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Re: Jenkins on PRs

[Daan Hoogland]

I've seen this one before:

Tests in error:
  SecondaryStorageManagerTest.getDefaultNetworkForAdvancedNonSG:79
NoSuchMethod ...
  SecondaryStorageManagerTest.getDefaultNetworkForAdvancedSG:102
NoSuchMethod or...
  SecondaryStorageManagerTest.getDefaultNetworkForAdvancedWrongZoneType
?  Unexp...
  SecondaryStorageManagerTest.getDefaultNetworkForBasicNonSG:124
NoSuchMethod or...
  SecondaryStorageManagerTest.getDefaultNetworkForBasicSG:147
NoSuchMethod org.a...
  SecondaryStorageManagerTest.getDefaultNetworkForBasicSGWrongZoneType
?  Unexpe...


it has been a reason of failure in more then one.



On Wed, Apr 6, 2016 at 10:13 PM, Daan Hoogland 
wrote:

> looking at the history in [1] this is not true. most are succeeding.
>
>
> [1] https://builds.apache.org/view/All/job/cloudstack-pr-analysis/
>
> On Wed, Apr 6, 2016 at 8:40 PM, Will Stevens 
> wrote:
>
>> Hey All,
>> Anyone know what is going on with Jenkins?  It seems to be failing for
>> most
>> PRs.  It seems to be timing out, but I am not a Jenkins wizard...
>>
>> Cheers,
>>
>> Will
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: Jenkins on PRs

[Daan Hoogland]

looking at the history in [1] this is not true. most are succeeding.


[1] https://builds.apache.org/view/All/job/cloudstack-pr-analysis/

On Wed, Apr 6, 2016 at 8:40 PM, Will Stevens 
wrote:

> Hey All,
> Anyone know what is going on with Jenkins?  It seems to be failing for most
> PRs.  It seems to be timing out, but I am not a Jenkins wizard...
>
> Cheers,
>
> Will
>



-- 
Daan

Re: GPG signing commits on Github

[Daan Hoogland]

On Wed, Apr 6, 2016 at 6:58 PM, Will Stevens  wrote:

> but we have to work with the ASF


​so we can not go there tomorrow but maybe the day after. Both we and the
foundation​ want signed commits so in the end we can be using github for
this as well. As long as there is no commit access to github this
functionality is not for us, so this discussion is future dreams anyhow.



-- 
Daan

Re: GPG signing commits on Github

[Daan Hoogland]

On Wed, Apr 6, 2016 at 5:37 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Sorry, but I did not understand. We do not have commit access to Github,
> right?
>
​I think we are talking about the new to be cloudstack organisation, right
@Will?

​


>
> On Wed, Apr 6, 2016 at 12:35 PM, Daan Hoogland 
> wrote:
>
>> hm, no ;) We can control access to the organisation right? so we can
>> close it for committers that don't have a valid key. We just need to think
>> of a procedure for checking and registration.
>>
>> On Wed, Apr 6, 2016 at 5:33 PM, Will Stevens 
>> wrote:
>>
>>> Yes, I agree with both of you.  Maybe I am not being clear.  My point is
>>> only that we can't allow commit access on Github because then we can not
>>> limit it to only valid committers who COULD commit.  Is that clearer?
>>>
>>> *Will STEVENS*
>>> Lead Developer
>>>
>>> *CloudOps* *| *Cloud Solutions Experts
>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> w cloudops.com *|* tw @CloudOps_
>>>
>>> On Wed, Apr 6, 2016 at 11:07 AM, Rafael Weingärtner <
>>> rafaelweingart...@gmail.com> wrote:
>>>
>>> > I agree with Daan.
>>> >
>>> > On Wed, Apr 6, 2016 at 11:42 AM, Daan Hoogland <
>>> daan.hoogl...@gmail.com>
>>> > wrote:
>>> >
>>> >> Will, we only need to be sure about the key's of committers. Only
>>> merge
>>> >> commits we need to be sure of the signature and the merger needs to be
>>> >> verify the code. He can not assure that the origin of the code is
>>> >> authentic
>>> >> but he can at least assure that the code is unchanged since
>>> contribution
>>> >> when it is signed. I don't think we need more.
>>> >>
>>> >> On Wed, Apr 6, 2016 at 4:33 PM, Will Stevens 
>>> >> wrote:
>>> >>
>>> >> > Ok, that is half.  But how do we verify that a Github user has a
>>> GPG key
>>> >> > that is matching what is registered in the ASF?  Just because you
>>> have a
>>> >> > GPG key does not mean you are an ASF committer, so the check would
>>> have
>>> >> to
>>> >> > be made to verify the GPG is registered to an ASF committer before
>>> they
>>> >> > would be allowed to actually commit via Github.  How would this be
>>> >> resolved?
>>> >> >
>>> >> > *Will STEVENS*
>>> >> > Lead Developer
>>> >> >
>>> >> > *CloudOps* *| *Cloud Solutions Experts
>>> >> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>>> >> > w cloudops.com *|* tw @CloudOps_
>>> >> >
>>> >> > On Wed, Apr 6, 2016 at 10:09 AM, Rafael Weingärtner <
>>> >> > rafaelweingart...@gmail.com> wrote:
>>> >> >
>>> >> >> There is a way to do that. When you become a committer, you can
>>> >> register a
>>> >> >> key at [1], then that key (public key) is loaded to [2]. The key is
>>> >> >> associated with the committer’s login. For instance, this is my
>>> public
>>> >> key
>>> >> >> [3].
>>> >> >>
>>> >> >> [1] id.apache.org
>>> >> >> [2] https://people.apache.org/keys/committer/
>>> >> >> [3] https://people.apache.org/keys/committer/rafael.asc
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Apr 6, 2016 at 11:04 AM, Will Stevens <
>>> wstev...@cloudops.com>
>>> >> >> wrote:
>>> >> >>
>>> >> >> > I don't think it is quite this simple.  There would have to be a
>>> way
>>> >> for
>>> >> >> > the GPG key to be associated with a specific ASF identity and I
>>> don't
>>> >> >> think
>>> >> >> > that is in place at this time.  Also, there would have to be
>>> >> >> verification
>>> >> >> > that the person who is committing has a GPG key AND that they
>>> are a
>>> >> >> > committer in ASF and have an identity there.  I think there are
>>> more
>>> >> >> moving
>>> >> >> > parts he

Re: GPG signing commits on Github

[Daan Hoogland]

hm, no ;) We can control access to the organisation right? so we can close
it for committers that don't have a valid key. We just need to think of a
procedure for checking and registration.

On Wed, Apr 6, 2016 at 5:33 PM, Will Stevens  wrote:

> Yes, I agree with both of you.  Maybe I am not being clear.  My point is
> only that we can't allow commit access on Github because then we can not
> limit it to only valid committers who COULD commit.  Is that clearer?
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, Apr 6, 2016 at 11:07 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I agree with Daan.
> >
> > On Wed, Apr 6, 2016 at 11:42 AM, Daan Hoogland 
> > wrote:
> >
> >> Will, we only need to be sure about the key's of committers. Only merge
> >> commits we need to be sure of the signature and the merger needs to be
> >> verify the code. He can not assure that the origin of the code is
> >> authentic
> >> but he can at least assure that the code is unchanged since contribution
> >> when it is signed. I don't think we need more.
> >>
> >> On Wed, Apr 6, 2016 at 4:33 PM, Will Stevens 
> >> wrote:
> >>
> >> > Ok, that is half.  But how do we verify that a Github user has a GPG
> key
> >> > that is matching what is registered in the ASF?  Just because you
> have a
> >> > GPG key does not mean you are an ASF committer, so the check would
> have
> >> to
> >> > be made to verify the GPG is registered to an ASF committer before
> they
> >> > would be allowed to actually commit via Github.  How would this be
> >> resolved?
> >> >
> >> > *Will STEVENS*
> >> > Lead Developer
> >> >
> >> > *CloudOps* *| *Cloud Solutions Experts
> >> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >> > w cloudops.com *|* tw @CloudOps_
> >> >
> >> > On Wed, Apr 6, 2016 at 10:09 AM, Rafael Weingärtner <
> >> > rafaelweingart...@gmail.com> wrote:
> >> >
> >> >> There is a way to do that. When you become a committer, you can
> >> register a
> >> >> key at [1], then that key (public key) is loaded to [2]. The key is
> >> >> associated with the committer’s login. For instance, this is my
> public
> >> key
> >> >> [3].
> >> >>
> >> >> [1] id.apache.org
> >> >> [2] https://people.apache.org/keys/committer/
> >> >> [3] https://people.apache.org/keys/committer/rafael.asc
> >> >>
> >> >>
> >> >> On Wed, Apr 6, 2016 at 11:04 AM, Will Stevens  >
> >> >> wrote:
> >> >>
> >> >> > I don't think it is quite this simple.  There would have to be a
> way
> >> for
> >> >> > the GPG key to be associated with a specific ASF identity and I
> don't
> >> >> think
> >> >> > that is in place at this time.  Also, there would have to be
> >> >> verification
> >> >> > that the person who is committing has a GPG key AND that they are a
> >> >> > committer in ASF and have an identity there.  I think there are
> more
> >> >> moving
> >> >> > parts here than meet the eye, but we can definitely continue the
> >> >> discussion
> >> >> > and see where it can lead.
> >> >> >
> >> >> > *Will STEVENS*
> >> >> > Lead Developer
> >> >> >
> >> >> > *CloudOps* *| *Cloud Solutions Experts
> >> >> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >> >> > w cloudops.com *|* tw @CloudOps_
> >> >> >
> >> >> > On Wed, Apr 6, 2016 at 5:00 AM, Wido den Hollander  >
> >> >> wrote:
> >> >> >
> >> >> > >
> >> >> > > > Op 6 april 2016 om 10:50 schreef Daan Hoogland <
> >> >> > daan.hoogl...@gmail.com
> >> >> > > >:
> >> >> > > >
> >> >> > > >
> >> >> > > > Good reading for the Wednesday morning;) yes I think we need to
> >> go
> >> >> > there
> >> >> > > > and maybe even ask

Re: Cwiki access

[Daan Hoogland]

On Wed, Apr 6, 2016 at 1:51 PM, Kris Sterckx  wrote:

> krissterckx


​is in​



-- 
Daan

Re: GPG signing commits on Github

[Daan Hoogland]

Will, we only need to be sure about the key's of committers. Only merge
commits we need to be sure of the signature and the merger needs to be
verify the code. He can not assure that the origin of the code is authentic
but he can at least assure that the code is unchanged since contribution
when it is signed. I don't think we need more.

On Wed, Apr 6, 2016 at 4:33 PM, Will Stevens  wrote:

> Ok, that is half.  But how do we verify that a Github user has a GPG key
> that is matching what is registered in the ASF?  Just because you have a
> GPG key does not mean you are an ASF committer, so the check would have to
> be made to verify the GPG is registered to an ASF committer before they
> would be allowed to actually commit via Github.  How would this be resolved?
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, Apr 6, 2016 at 10:09 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> There is a way to do that. When you become a committer, you can register a
>> key at [1], then that key (public key) is loaded to [2]. The key is
>> associated with the committer’s login. For instance, this is my public key
>> [3].
>>
>> [1] id.apache.org
>> [2] https://people.apache.org/keys/committer/
>> [3] https://people.apache.org/keys/committer/rafael.asc
>>
>>
>> On Wed, Apr 6, 2016 at 11:04 AM, Will Stevens 
>> wrote:
>>
>> > I don't think it is quite this simple.  There would have to be a way for
>> > the GPG key to be associated with a specific ASF identity and I don't
>> think
>> > that is in place at this time.  Also, there would have to be
>> verification
>> > that the person who is committing has a GPG key AND that they are a
>> > committer in ASF and have an identity there.  I think there are more
>> moving
>> > parts here than meet the eye, but we can definitely continue the
>> discussion
>> > and see where it can lead.
>> >
>> > *Will STEVENS*
>> > Lead Developer
>> >
>> > *CloudOps* *| *Cloud Solutions Experts
>> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> > w cloudops.com *|* tw @CloudOps_
>> >
>> > On Wed, Apr 6, 2016 at 5:00 AM, Wido den Hollander 
>> wrote:
>> >
>> > >
>> > > > Op 6 april 2016 om 10:50 schreef Daan Hoogland <
>> > daan.hoogl...@gmail.com
>> > > >:
>> > > >
>> > > >
>> > > > Good reading for the Wednesday morning;) yes I think we need to go
>> > there
>> > > > and maybe even ask it of our contributors.
>> > > >
>> > >
>> > > It might please the ASF since we can now prove who made the commit.
>> If we
>> > > ask
>> > > all committers to upload their public key and sign their commits we
>> can
>> > > check
>> > > this.
>> > >
>> > > For Pull Requests we can probably also add a hook/check which verifies
>> > if a
>> > > signature is present.
>> > >
>> > > Wido
>> > >
>> > > > On Wed, Apr 6, 2016 at 9:28 AM, Wido den Hollander 
>> > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > Github just added [0] support for verifying GPG signatures of Git
>> > > commits
>> > > > > to the
>> > > > > web interface.
>> > > > >
>> > > > > Under the settings page [1] you can now add your public GPG key so
>> > > Github
>> > > > > can
>> > > > > verify it.
>> > > > >
>> > > > > It's rather simple:
>> > > > >
>> > > > > $ gpg --armor --export w...@widodh.nl
>> > > > >
>> > > > > That gave me my public key which I could export.
>> > > > >
>> > > > > Git already supports signing [2] commits with your key.
>> > > > >
>> > > > > This makes me wonder, is this something we want to enforce? To me
>> it
>> > > seems
>> > > > > like
>> > > > > a good thing to have.
>> > > > >
>> > > > > Wido
>> > > > >
>> > > > > [0]: https://github.com/blog/2144-gpg-signature-verification
>> > > > > [1]: https://github.com/settings/keys
>> > > > > [2]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Daan
>> > >
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>


-- 
Daan

Re: GPG signing commits on Github

[Daan Hoogland]

On Wed, Apr 6, 2016 at 11:00 AM, Wido den Hollander  wrote:

>
> > Op 6 april 2016 om 10:50 schreef Daan Hoogland  >:
> >
> >
> > Good reading for the Wednesday morning;) yes I think we need to go there
> > and maybe even ask it of our contributors.
> >
>
> It might please the ASF since we can now prove who made the commit. If we
> ask
> all committers to upload their public key and sign their commits we can
> check
> this.
>
> For Pull Requests we can probably also add a hook/check which verifies if a
> signature is present.
>
​and revoke/allow committer acces​
​s to the organisation based on it​

​...

life is great.
​

>
> Wido
>
> > On Wed, Apr 6, 2016 at 9:28 AM, Wido den Hollander 
> wrote:
> >
> > > Hi,
> > >
> > > Github just added [0] support for verifying GPG signatures of Git
> commits
> > > to the
> > > web interface.
> > >
> > > Under the settings page [1] you can now add your public GPG key so
> Github
> > > can
> > > verify it.
> > >
> > > It's rather simple:
> > >
> > > $ gpg --armor --export w...@widodh.nl
> > >
> > > That gave me my public key which I could export.
> > >
> > > Git already supports signing [2] commits with your key.
> > >
> > > This makes me wonder, is this something we want to enforce? To me it
> seems
> > > like
> > > a good thing to have.
> > >
> > > Wido
> > >
> > > [0]: https://github.com/blog/2144-gpg-signature-verification
> > > [1]: https://github.com/settings/keys
> > > [2]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
> > >
> >
> >
> >
> > --
> > Daan
>



-- 
Daan

Re: GPG signing commits on Github

[Daan Hoogland]

Good reading for the Wednesday morning;) yes I think we need to go there
and maybe even ask it of our contributors.

On Wed, Apr 6, 2016 at 9:28 AM, Wido den Hollander  wrote:

> Hi,
>
> Github just added [0] support for verifying GPG signatures of Git commits
> to the
> web interface.
>
> Under the settings page [1] you can now add your public GPG key so Github
> can
> verify it.
>
> It's rather simple:
>
> $ gpg --armor --export w...@widodh.nl
>
> That gave me my public key which I could export.
>
> Git already supports signing [2] commits with your key.
>
> This makes me wonder, is this something we want to enforce? To me it seems
> like
> a good thing to have.
>
> Wido
>
> [0]: https://github.com/blog/2144-gpg-signature-verification
> [1]: https://github.com/settings/keys
> [2]: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
>



-- 
Daan

jenkins restart

[Daan Hoogland]

sorry for not giving prior notice. I am updating plugins on
jenkins.buildacloud.org. It will restart.

-- 
Daan

Re: [QUESTION] baremetal router

[Daan Hoogland]

thakns Hari, I'll make a small pr for putting the baremetal-vr.py under a
condition.

On Tue, Apr 5, 2016 at 11:10 AM, Harikrishna Patnala <
harikrishna.patn...@accelerite.com> wrote:

> Hi Daan,
>
> Yes, this should run only in Virtual Router. Instead of moving it to
> existing “if” block, better to have a seperate check only for normal
> router, since we don’t support baremetal deployment in VPC.
>
> Regarding the later question, with the current implementation I don’t
> think we can distinguish whether PXE service enabled on the router or not,
> or we can also initiate this agent on VR from management server using
> sshCmdHelper just before deploying the baremetal instance.
>
> Regards,
> Harikrishna
>
>
> On 30-Mar-2016, at 5:26 pm, Daan Hoogland  wrote:
>
> > People,
> >
> > in the following code the baremetal-vr.py configuration script is started
> > unconditionally, this means it will be started on ssvm and cpvm as well.
> > but also on virtual routervms;
> >
> >
> > CMDLINE=$(cat /var/cache/cloud/cmdline)
> > router=$(echo "$CMDLINE" | grep -o  type=router)
> > vpcrouter=$(echo "$CMDLINE" | grep -o  type=vpcrouter)
> >
> > if [ "$router" != "" ] ||  [ "$vpcrouter" != "" ]
> > then
> >   echo 100 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
> >   echo 100 > /proc/sys/net/netfilter/nf_conntrack_max
> >   echo 100 > /proc/sys/net/nf_conntrack_max
> > fi
> >
> > python /opt/cloud/bin/baremetal-vr.py &
> >
> >
> > Does it make sense to at least move it inside the if block above so it is
> > only started on routers?
> > Or does anybody know how to distinguish that we are running on baremetal
> > and guard for that condition?
> >
> > --
> > Daan
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>



-- 
Daan

monday morning reading

[Daan Hoogland]

H, for those interested in how we get to improve, here is something I
stumbled upon on reddit [1]

I must admit I think most of us are already working as described but
still,... it touches on some of the pitfalls we have been tripping in as a
project as well.

​[1] : https://10kloc.wordpress.com/2016/04/03/effective-code-reviews/​

-- 
Daan

Re: Permissions issues on cwiki with my login credentials

[Daan Hoogland]

On Fri, Apr 1, 2016 at 7:50 AM, Shweta Agarwal <
shweta.agarw...@accelerite.com> wrote:

> shwetaag


​is added​



-- 
Daan

Re: Build failed in Jenkins: cloudstack-rat-master #7108

[Daan Hoogland]

Rafael, I think you need to ask infra.

On Thu, Mar 31, 2016 at 11:21 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Could someone with access to those VMs check the problem?
> It seems that there is an envrioment misconfiguraiton
>
> -- Forwarded message --
> From: Apache Jenkins Server 
> Date: Thu, Mar 31, 2016 at 5:24 PM
> Subject: Build failed in Jenkins: cloudstack-rat-master #7108
> To: cloudstack-comm...@cloudstack.apache.org, rafaelweingart...@gmail.com
>
>
> See 
>
> --
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on jenkins-test-1bb (jenkins-cloud-4GB cloud-slave Ubuntu
> ubuntu jenkins-cloud-8GB) in workspace <
> https://builds.apache.org/job/cloudstack-rat-master/ws/>
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url
> https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=10
> Fetching upstream changes from
> https://git-wip-us.apache.org/repos/asf/cloudstack.git
>  > git --version # timeout=10
>  > git -c core.askpass=true fetch --tags --progress
> https://git-wip-us.apache.org/repos/asf/cloudstack.git
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse origin/master^{commit} # timeout=10
> Checking out Revision 24565000f44e8642c125612d43b11a1fb3f619da
> (origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 24565000f44e8642c125612d43b11a1fb3f619da
>  > git rev-list 24565000f44e8642c125612d43b11a1fb3f619da # timeout=10
> [cloudstack-rat-master] $
>
> /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/bin/mvn
> --projects=org.apache.cloudstack:cloudstack
> org.apache.rat:apache-rat-plugin:0.10:check
> Error: JAVA_HOME is not defined correctly.
>   We cannot execute /home/jenkins/tools/java/latest1.6/bin/java
> Build step 'Invoke top-level Maven targets' marked build as failure
> Archiving artifacts
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

[QUESTION] baremetal router

[Daan Hoogland]

People,

in the following code the baremetal-vr.py configuration script is started
unconditionally, this means it will be started on ssvm and cpvm as well.
but also on virtual routervms;


CMDLINE=$(cat /var/cache/cloud/cmdline)
router=$(echo "$CMDLINE" | grep -o  type=router)
vpcrouter=$(echo "$CMDLINE" | grep -o  type=vpcrouter)

if [ "$router" != "" ] ||  [ "$vpcrouter" != "" ]
then
   echo 100 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
   echo 100 > /proc/sys/net/netfilter/nf_conntrack_max
   echo 100 > /proc/sys/net/nf_conntrack_max
fi

python /opt/cloud/bin/baremetal-vr.py &


Does it make sense to at least move it inside the if block above so it is
only started on routers?
Or does anybody know how to distinguish that we are running on baremetal
and guard for that condition?

-- 
Daan

Re: [SSL CERTS] Importing ROOT and INTERMEDIATE certs for SSVM

[Daan Hoogland]

Ilya, to my knowledge the certificate won't be saved on file. It will be
loaded from the command coming from the MS in the agent directly. Why are
you looking to update the ssvm? I thought these are only used in the
consoleproxy.

On Tue, Mar 29, 2016 at 12:17 AM, ilya  wrote:

> I'm having difficulty getting ROOT and INTERMEDIATE certificates to show
> up in SSVM java keystore.
>
>
> I've followed the procedure on
>
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/systemvm.html?highlight=pkcs
>
> and
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replace+realhostip.com+with+Your+Own+Domain+Name
>
> But after restart of SSVM and MS - the keystore still has default Go
> Daddy certs.
>
> Would any know how to troubleshoot it?
>
> Also, one thing to note, i'm not uploading the actual wild card cert -
> is its against security policy. It will be impossible for me to get a
> wildcard cert.
>
> Regards
> ilya
>



-- 
Daan

Re: [DISCUSS] Request for comments: Dynamic Role Based API Access Checker for CloudStack

[Daan Hoogland]

you know you are great, right?

On Fri, Mar 25, 2016 at 2:10 PM, Rohit Yadav 
wrote:

> Hi Daan,
>
> Thanks for the comments.
>
> Yes, I looked into it but the IAM-services related work started by some of
> our former colleagues was not in a good shape to be picked up, it also
> introduced resource level fine-grain ACLs that would have required a lot of
> effort to both implement and test thoroughly.
>
> The proposed solution is not the final solution to the rbac problem, but
> aims to solve for role/account management issues for operators while
> ensuring strict backward compatibility, an upgrade path from static based
> system to a db-backed dynamic system and allows scope for future
> improvements.
>
> To share some progress, the feature implementation so far looks promising
> and I'm trying to nail down the edges around upgrade process.
> I'm also investing a lot of time of marvin tests to ensure high quality
> delivery of this feature.
>
> Regards.
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Friday, March 25, 2016 12:55 PM
> To: dev 
> Cc: us...@cloudstack.apache.org
> Subject: Re: [DISCUSS] Request for comments: Dynamic Role Based API Access
> Checker for CloudStack
>
> Rohit, I had a first glance and it looks promising; +1 You have been
> thourough on the fs. One question that comes to mind is whatever happened
> to the role base access That Min and Pradhi(not sure if I remeber her name
> correctly) where implementing for 4.4. It failed then because the work was
> taking much more effort then estimated but it was pushed to git.wip-us. Did
> you look at thaat work?
>
> On Wed, Mar 23, 2016 at 6:04 PM, Rohit Yadav 
> wrote:
>
> > Hi all,
> >
> > I want to propose a new feature for CloudStack, dynamic role-based API
> > access checker. This feature will allow us to migrate rules define in
> > commands.properties file to database, while role management (such as
> > creating/editing roles, adding/removing rules) won't require
> > restarting management server(s).
> >
> > Please find more details in the FS here:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Ba
> > sed+API+Access+Checker+for+CloudStack
> >
> > I look forward to your comments, suggestions and questions. Thanks.
> >
> > Regards,
> > Rohit Yadav
> >
> > Regards,
> >
> > Rohit Yadav
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> >
>
>
>
> --
> Daan
>



-- 
Daan

Re: [DISCUSS] Request for comments: Dynamic Role Based API Access Checker for CloudStack

[Daan Hoogland]

Rohit, I had a first glance and it looks promising; +1 You have been
thourough on the fs. One question that comes to mind is whatever happened
to the role base access That Min and Pradhi(not sure if I remeber her name
correctly) where implementing for 4.4. It failed then because the work was
taking much more effort then estimated but it was pushed to git.wip-us. Did
you look at thaat work?

On Wed, Mar 23, 2016 at 6:04 PM, Rohit Yadav 
wrote:

> Hi all,
>
> I want to propose a new feature for CloudStack, dynamic role-based API
> access checker. This feature will allow us to migrate rules define in
> commands.properties file to database, while role management (such as
> creating/editing roles, adding/removing rules) won't require restarting
> management server(s).
>
> Please find more details in the FS here:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack
>
> I look forward to your comments, suggestions and questions. Thanks.
>
> Regards,
> Rohit Yadav
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>



-- 
Daan

Re: introduction

[Daan Hoogland]

welcome back Murali, good luck.

On Wed, Mar 23, 2016 at 12:50 PM, Murali Reddy 
wrote:

> All,
>
> Just wanted to let the community know that I have decided to work on
> Apache CloudStack again. I have taken up a position at ShapeBlue, so you
> will be seeing me around @dev and @users. For the new members of the
> community and others who I have not interacted with, here is small self
> introduction. I started my journey with CloudStack, in late 2010 as
> cloud.com employee. Later spent 4 years till late 2014 working on various
> CloudStack features (EIP, GSLB, NAAS, NetScaler integration, native SDN
> controller, distributed virtual router, event bus to name few). I was
> working on NFV solution on OpenStack over a year. I am excited to join back
> the community, looking forward to interact with you.
>
> Thanks,
> Murali
>



-- 
Daan

Re: [GitHub] cloudstack pull request: CLOUDSTACK-8958: release dedicated ip ran...

[Daan Hoogland]

Bharat et al,

>From this report,  I find it difficult to get a feel for the quality of the
pr. Clearly some of the failures are not related to this PR but are some
related? Can you give some guidance as to how to read the report?

Biligual auto correct use.  Read at your own risico
Op 22 mrt. 2016 12:23 PM schreef "bvbharatk" :

> Github user bvbharatk commented on the pull request:
>
> https://github.com/apache/cloudstack/pull/1357#issuecomment-199767590
>
> ### ACS CI BVT Run
>  **Sumarry:**
>  Build Number 118
>  Hypervisor xenserver
>  NetworkType Advanced
>  Passed=105
>  Failed=13
>  Skipped=4
>
> **The follwing tests have known issues**
> test_03_rvpc_privategw_static_routes
> ContextSuite context=TestDeployVM>:setup
> test_01_primary_storage_iscsi
> test_04_change_offering_small
> test_07_list_default_iso
> test_04_extract_template
> test_01_test_vm_volume_snapshot
> test_04_extract_Iso
> test_02_vpc_privategw_static_routes
> test02_internallb_haproxy_stats_on_all_interfaces
> test_vpc_remote_access_vpn
> ContextSuite context=TestNiciraContoller>:setup
> test_vpc_site2site_vpn
> test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
> test_dedicateGuestVlanRange
>
> _Link to logs Folder (search by build_no):_
> https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0
>
>
> **Failed tests:**
> * integration.smoke.test_privategw_acl.TestPrivateGwACL
>
>  * test_01_vpc_privategw_acl Failing since 5 runs
>
>
> **Skipped tests:**
> test_vm_nic_adapter_vmxnet3
> test_deploy_vgpu_enabled_vm
> test_06_copy_template
> test_06_copy_iso
>
> **Passed test suits:**
> integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData
>
> integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
> integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
> integration.smoke.test_over_provisioning.TestUpdateOverProvision
> integration.smoke.test_global_settings.TestUpdateConfigWithScope
> integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange
> integration.smoke.test_scale_vm.TestScaleVm
> integration.smoke.test_service_offerings.TestCreateServiceOffering
> integration.smoke.test_loadbalance.TestLoadBalance
> integration.smoke.test_routers.TestRouterServices
> integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot
> integration.smoke.test_snapshots.TestSnapshotRootDisk
>
> integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
> integration.smoke.test_network.TestDeleteAccount
> integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
> integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
> integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
> integration.smoke.test_multipleips_per_nic.TestDeployVM
> integration.smoke.test_regions.TestRegions
> integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
> integration.smoke.test_network_acl.TestNetworkACL
> integration.smoke.test_pvlan.TestPVLAN
> integration.smoke.test_volumes.TestCreateVolume
> integration.smoke.test_ssvm.TestSSVMs
> integration.smoke.test_nic.TestNic
> integration.smoke.test_deploy_vm_root_resize.TestDeployVM
> integration.smoke.test_resource_detail.TestResourceDetail
> integration.smoke.test_secondary_storage.TestSecStorageServices
> integration.smoke.test_vm_life_cycle.TestDeployVM
> integration.smoke.test_disk_offerings.TestCreateDiskOffering
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'

[Daan Hoogland]

Makes sense Shane if we can have that role shared amongst several people of
the PMC, not just one as you suggest.

On Mon, Mar 21, 2016 at 2:41 AM, Shane Curcuru  wrote:

> Will Stevens wrote earlier:
> ... snip...
> > *Proposal:*
> > Transfer ownership of the 'apache/cloudstack' mirrored repository out of
> > the 'apache' github organization into the 'apache-cloudstack' github
> > organization (which I have already setup and started inviting users to).
> > Both members of the ACS community and the ASF board will have 'owner'
> > permissions on this new organization.  This will allow for permissions to
> > be applied specifically to the 'apache-cloudstack' organization and not
> > have to be applied to the entire 'apache' organization.
>
> This sounds like a great solution for this community.  It also sounds
> like there will be plenty of details to work out with the infra team to
> ensure all the normal ASF git tooling still works seamlessly, both for
> users as well as for our core infrastructure (like backups, email commit
> hooks, etc.)
>
> One minor change: the appropriate people in the ASF Infra team need to
> have owner permissions for the repo, along with someone from the PMC.
> That is, the ASF *as an organization* needs to have owner permissions
> both for maintenance and brand ownership, and the infra team is the
> group who handles that for the ASF (the board delegates operations to
> the President, who delegates server and repo maintenance to the infra
> team members).
>
> Make sense?  Good luck!
>
> - Shane
>



-- 
Daan

Re: Issue: CLOUDSTACK-9255 Unable to start VM DomainRouter due to error in finalizeStart

[Daan Hoogland]

Boris closed it,

@Boris why?

On Fri, Mar 18, 2016 at 12:14 PM, Remi Bergsma 
wrote:

> Hi,
>
> This issue has been resolved some time ago but unfortunately the PR hasn’t
> been merged nor tested yet.
>
> https://github.com/apache/cloudstack/pull/1400
>
> This PR makes it like 50-60 times faster, because it first generates all
> iptables commands and then loads them once.
>
> We run this in production for weeks already. Not sure why the PR is
> closed, it simply works.
>
> Regards,
> Remi
>
>
> From: martin kolly  martin.ko...@senselan.ch>>
> Reply-To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Date: Friday 18 March 2016 at 11:58
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Subject: Issue: CLOUDSTACK-9255 Unable to start VM DomainRouter due to
> error in finalizeStart
>
> Hi All
>
> We are facing the same issue as reported by Milamber (Ticket 9255)
> https://issues.apache.org/jira/browse/CLOUDSTACK-9255. When deploying a
> couple of VMs or Port Forwarding's the re-deployment of the router with
> cleanup fails.
>
> We found that iptables configuration takes a lot of time, this eventually
> leads to a timeout on the management server "Unable to start VM
> DomainRouter due to error in finalizeStart, not retrying"
>
> Environment:
> - Cloudstack 4.8
> - KVM (local storage)
> - hosts/mgr on Ubuntu 14.04
>
> We tested with a simple set of four forwarding rules, here the setup:
>
> root@r-96-VM:~# cat /etc/cloudstack/forwardingrules.json
> {
> "185.20.146.56": [
> {
> "internal_ip": "10.100.1.95",
> "internal_ports": "22:22",
> "protocol": "tcp",
> "public_ip": "185.20.146.56",
> "public_ports": "22:22",
> "type": "forward"
> }
> ],
> "185.20.146.79": [
> {
> "internal_ip": "10.100.1.42",
> "internal_ports": "22:22",
> "protocol": "tcp",
> "public_ip": "185.20.146.79",
> "public_ports": "22:22",
> "type": "forward"
> },
> {
> "internal_ip": "10.100.1.42",
> "internal_ports": "8443:8443",
> "protocol": "tcp",
> "public_ip": "185.20.146.79",
> "public_ports": "8443:8443",
> "type": "forward"
> },
> {
> "internal_ip": "10.100.1.42",
> "internal_ports": "53:53",
> "protocol": "udp",
> "public_ip": "185.20.146.79",
> "public_ports": "53:53",
> "type": "forward"
> }
> ],
> "id": "forwardingrules"
>
> The definition for every port forwarding seems to take at ~1.5 seconds.
>
> python /opt/cloud/bin/configure.py.timed
> /etc/cloudstack/forwardingrules.json
>
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j
> DNAT --to-destination 10.100.1.42:22
> time : 0.000965118408203
> -A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 22 -j
> DNAT --to-destination 10.100.1.42:22
> time : 0.395485162735
> -A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 22 -j DNAT
> --to-destination 10.100.1.42:22
> time : 0.395533084869
> -j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d
> 10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 22
> time : 1.16180706024
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j
> MARK --set-xmark 0x2/0x
> time : 1.16329216957
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -m
> state --state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask
> 0x
> time : 1.16407108307
> -A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 22 -m state --state
> NEW,ESTABLISHED -j ACCEPT
> Total time for creating Policy : 1.53959512711
> --
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j
> DNAT --to-destination 10.100.1.42:8443
> time : 0.000781059265137
> -A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 8443 -j
> DNAT --to-destination 10.100.1.42:8443
> time : 0.378201007843
> -A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 8443 -j DNAT
> --to-destination 10.100.1.42:8443
> time : 0.37822508812
> -j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d
> 10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 8443
> time : 1.14627504349
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j
> MARK --set-xmark 0x2/0x
> time : 1.1477329731
> -A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -m
> state --state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask
> 0x
> time : 1.14850592613
> -A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 8443 -m state --state
> NEW,ESTABLISHED -j ACCEPT
> Total time for creating Policy : 1.52321791649
> --

Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

[Daan Hoogland]

Ok Jim, it seems we are on one line here. Sorry to bother but I wanted to
make sure. In my understanding the moving was only about the part already
on github. I'll hold my peace for a while unless we are actually talking
about the technical implementation of a convenient developer workflow again
;)



On Sat, Mar 19, 2016 at 8:35 PM, Jim Jagielski  wrote:

> As Sam indicated, there was a lot of hush-and-rush about all
> this, with little communicated and much assumed. It appears that
> now things are more well known and the matters are being
> addressed. But for the record, yes, there was the impression
> and (mis)understanding that "moving" to GH was indeed what
> was desired and "demanded".
>
> My post was in direct response to Sebastien's query, as was hopefully
> indicated by including that paragraph in my post.
>
> > On Mar 19, 2016, at 3:09 PM, Daan Hoogland 
> wrote:
> >
> > On Sat, Mar 19, 2016 at 7:50 PM, Jim Jagielski  wrote:
> >
> >>
> >>> On Mar 19, 2016, at 2:12 PM, sebgoa  wrote:
> >>>
> >>>
> >>> Personally I have always thought that this is a very serious issue and
> >> trend in open source projects and that ASF (and the board in particular)
> >> should try to proactively address. What is the future of ASF in a GitHub
> >> world ? Can an ASF project live outside of ASF infra, especially in a
> Cloud
> >> world ? Sadly I never saw any clear proactivity from the board.
> >>>
> >>
> >> I can answer this by asking you one question: What value, if
> >> any, do you see the ASF providing to Cloudstack?
> >>
> >> I will avoid the very Mom-like retort: "If all your friends were
> >> going to jump off a roof, would you too?"  :) :)
> >>
> >> Real Open Source collaboration, and community, is more than
> >> just developer workflow. Hopefully, one day people will
> >> remember that... The ASF, however, will never forget it.
> >>
> >> Meanwhile, I still boggle at people who paint Microsoft as
> >> (still) enemies of Open Source, yet bend over backwards to
> >> portray Github as true, passionate open source liberators.
> >> People passionate about open source are seriously pushing
> >> that projects be hosted on a single-vendor, closed-source,
> >> proprietary environment. If that vendor's name was "Microsoft"
> >> or "Oracle" people would be loosing their sh*t; because it's
> >> called "Github" well, that's OK then.
> >>
> >> Kinds of reminds me, as a libertarian, as those people who
> >> are willing to give up some (real) rights and liberties
> >> for some (perceived) additional security.
> >>
> >> I'm not saying that GH isn't useful, but it's not the holy
> >> grail, nor is it a workflow and platform that we should
> >> be encouraging the next-gen of developers to swallow hook,
> >> line and sinker.
> >
> >
> > ​Jim, you sound like someone gave you the impression that they didn't
> want
> > ​the wip-us repo to be the primary source of cloudstack code any more. I
> > wonder who and how? I do not care if IBM, Oracle or Microsoft would host
> > mirrors or clones or forks or whatever. On the contrary, it would be an
> > honour. I am also very pleased to be able to have a fork on github.
> Besides
> > all that, how would you plea that the Apache foundation isn't trying to
> > bind 'em all with a single repository like all the commercial
> governments,
> > as well? As a libertarian I don't trust 'not for profit' any more then
> any
> > other business objective. The writing above is yet another sound from the
> > board that makes me believe there is discontent and I don't understand.
> >
> >
> > --
> > ​​
> >
> > Daan
>
>


-- 
Daan

Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

[Daan Hoogland]

On Sat, Mar 19, 2016 at 7:50 PM, Jim Jagielski  wrote:

>
> > On Mar 19, 2016, at 2:12 PM, sebgoa  wrote:
> >
> >
> > Personally I have always thought that this is a very serious issue and
> trend in open source projects and that ASF (and the board in particular)
> should try to proactively address. What is the future of ASF in a GitHub
> world ? Can an ASF project live outside of ASF infra, especially in a Cloud
> world ? Sadly I never saw any clear proactivity from the board.
> >
>
> I can answer this by asking you one question: What value, if
> any, do you see the ASF providing to Cloudstack?
>
> I will avoid the very Mom-like retort: "If all your friends were
> going to jump off a roof, would you too?"  :) :)
>
> Real Open Source collaboration, and community, is more than
> just developer workflow. Hopefully, one day people will
> remember that... The ASF, however, will never forget it.
>
> Meanwhile, I still boggle at people who paint Microsoft as
> (still) enemies of Open Source, yet bend over backwards to
> portray Github as true, passionate open source liberators.
> People passionate about open source are seriously pushing
> that projects be hosted on a single-vendor, closed-source,
> proprietary environment. If that vendor's name was "Microsoft"
> or "Oracle" people would be loosing their sh*t; because it's
> called "Github" well, that's OK then.
>
> Kinds of reminds me, as a libertarian, as those people who
> are willing to give up some (real) rights and liberties
> for some (perceived) additional security.
>
> I'm not saying that GH isn't useful, but it's not the holy
> grail, nor is it a workflow and platform that we should
> be encouraging the next-gen of developers to swallow hook,
> line and sinker.


​Jim, you sound like someone gave you the impression that they didn't want
​the wip-us repo to be the primary source of cloudstack code any more. I
wonder who and how? I do not care if IBM, Oracle or Microsoft would host
mirrors or clones or forks or whatever. On the contrary, it would be an
honour. I am also very pleased to be able to have a fork on github. Besides
all that, how would you plea that the Apache foundation isn't trying to
bind 'em all with a single repository like all the commercial governments,
as well? As a libertarian I don't trust 'not for profit' any more then any
other business objective. The writing above is yet another sound from the
board that makes me believe there is discontent and I don't understand.


-- 
​​

Daan