date:20160912

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1671
  
@mike-tutkowski I started our internal CI run on this to run the smoke test 
suite. It will post the results here.


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell Thanks for the info on bylaws. Its not the first time we are 
discussing on how we are operating since 4.6. I understood that this is never 
going to conclude in any other way and I gave 
up(http://sethgodin.typepad.com/seths_blog/2016/08/putting-falsifiability-to-work.html)
 
Since 4.6, we are operating in a certain way and I do believe we should 
atleast conclude that discussion that anyone can commit(Thats my opinion and I 
am not looking for an argument here).

regarding the CI and @blueorangatan, the last time I checked, there is no 
proof there for me to believe what it says is right.  I cant access the 
system(atleast the logs). The success rate(of it starting) is also very low for 
the PRs I tried. I understand its your internal CI and I appreciate the 
efforts. But, its not reliable yet.
signing off


---
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.
---

[GitHub] cloudstack issue #1560: CLOUDSTACK-9386: DS template copies don’t get dele...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1560
  
@serg38 the git-pr script is not working properly for me.  I will debug 
further tomorrow.

@rafaelweingartner do you mind doing the merge honors?


---
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.
---

[GitHub] cloudstack issue #1651: Marvin Tests: fix expected return string for success...

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1651
  
@PaulAngus @jburwell Can we squash commits and merge this one? This will 
allow us to include 5 more integration test results for other PRs


---
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.
---

[GitHub] cloudstack issue #1661: Export UUID for zone creation event completion.

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1661
  
LGTM for the code review


---
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: [DISCUSS] Replacing the VR

At this point, I think we are still throwing around ideas.  If you have
links to more options you think we should have on the table, please add
them to the discussion.  :)

*Will STEVENS*
Lead Developer

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

On Mon, Sep 12, 2016 at 6:30 PM, Marty Godsey  wrote:

> Have we thought of other SDx routers such as pfsense? Its licensed under
> the BSD license and is well maintained.
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: Monday, September 12, 2016 6:16 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> You have probably looked into this more than I have Rene.
>
> I am not sure there existed a time when the VR was ever "great".  In my
> eyes, the core ACS dev team should not be building and managing its own
> VR.  I feel like that is a liability because the subset of developers who
> are proficient in networking is quite small.  That means we could be at
> risk of losing the majority of our "experts" with a few people changing
> their $dayjob.  It feels safer to work with an existing technology which
> has its own development community focused on doing that piece well.
> Obviously this has its own drawbacks, but in general, we need the VR
> implementation to be built by dedicated network engineers and not jack of
> all trade developers.  No offense to current company...
>
> I agree with your list of what you would like to see.  Rock solid and not
> over complicated is key.  That being said, if it ONLY handles what ACS
> needs today, then WE have to be the ones to develop any changes.  For
> example; we need IPv6, VXLAN support, etc...  My point is that if we only
> focus on what we need today, then we end up building everything we need for
> the future and I think we end up back where we are now down the road...
>
> I love everything you are saying, just not sure I want us building and
> maintaining it all...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> @CloudOps_
>
> On Mon, Sep 12, 2016 at 5:47 PM, Rene Moser  wrote:
>
> > Hi
> >
> > On 09/12/2016 10:20 PM, Will Stevens wrote:
> > > *Disclaimer:* This is a thought experiment and should be treated as
> such.
> > > Please weigh in with the good and bad of this idea...
> > >
> > > A couple of us have been discussing the idea of potentially
> > > replacing the ACS VR with the VyOS [1] (Open Source Vyatta VM).
> > > There may be a license issue because I think it is licensed under
> > > GPL, but for the sake of discussion, let's assume we can overcome any
> license issues.
> >
> > VyOS is Debian based, much like the current VR. As long as it is not
> > shipped with CloudStack, all fine.
> >
> > > I have spent some time recently with the VyOS and I have to admit, I
> > > was pretty impressed.  It is simple and intuitive and it gives you a
> > > lot more options for auditing the configuration etc...
> >
> > I had the same "crazy" thoughts when I heard about VyOS the first time.
> >
> > When I looked at VyOS, the release cycle were not very frequent and
> > the current stable release is still based on Debian 6 (EOL [1] since
> > 02.16)
> >
> > However to me, it doesn't matter if it's VyOS or CloudLinux, or
> > another solution.
> >
> > The question is more like what is wrong with the current VR and how
> > can we make the VR great again. Things I would like to see:
> >
> > - VR must have a "clean", programmable, documented, API, supporting
> > batch processing.
> > - VR must be rock solid (minimal shell) state of the art, up to date,
> > but small (Only contain things CloudStack needs, not more)
> > - VR must be scale well (...) and support stateful HA
> > - VR must be easy to upgrade (security) without downtimes.
> >
> > Christmas is soon... ;)
> >
> > René
> >
> > [1] https://www.debian.org/News/2016/20160212
> >
> >
>

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1602
  
Just realized I hadn't re-reviewed.  LGTM for code.


---
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: [DISCUSS] Replacing the VR

2016-09-12 Thread Marty Godsey

Have we thought of other SDx routers such as pfsense? Its licensed under the 
BSD license and is well maintained.

-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: Monday, September 12, 2016 6:16 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR

You have probably looked into this more than I have Rene.

I am not sure there existed a time when the VR was ever "great".  In my eyes, 
the core ACS dev team should not be building and managing its own VR.  I feel 
like that is a liability because the subset of developers who are proficient in 
networking is quite small.  That means we could be at risk of losing the 
majority of our "experts" with a few people changing their $dayjob.  It feels 
safer to work with an existing technology which has its own development 
community focused on doing that piece well.
Obviously this has its own drawbacks, but in general, we need the VR 
implementation to be built by dedicated network engineers and not jack of all 
trade developers.  No offense to current company...

I agree with your list of what you would like to see.  Rock solid and not over 
complicated is key.  That being said, if it ONLY handles what ACS needs today, 
then WE have to be the ones to develop any changes.  For example; we need IPv6, 
VXLAN support, etc...  My point is that if we only focus on what we need today, 
then we end up building everything we need for the future and I think we end up 
back where we are now down the road...

I love everything you are saying, just not sure I want us building and 
maintaining it all...

*Will STEVENS*
Lead Developer

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

On Mon, Sep 12, 2016 at 5:47 PM, Rene Moser  wrote:

> Hi
>
> On 09/12/2016 10:20 PM, Will Stevens wrote:
> > *Disclaimer:* This is a thought experiment and should be treated as such.
> > Please weigh in with the good and bad of this idea...
> >
> > A couple of us have been discussing the idea of potentially 
> > replacing the ACS VR with the VyOS [1] (Open Source Vyatta VM).  
> > There may be a license issue because I think it is licensed under 
> > GPL, but for the sake of discussion, let's assume we can overcome any 
> > license issues.
>
> VyOS is Debian based, much like the current VR. As long as it is not 
> shipped with CloudStack, all fine.
>
> > I have spent some time recently with the VyOS and I have to admit, I 
> > was pretty impressed.  It is simple and intuitive and it gives you a 
> > lot more options for auditing the configuration etc...
>
> I had the same "crazy" thoughts when I heard about VyOS the first time.
>
> When I looked at VyOS, the release cycle were not very frequent and 
> the current stable release is still based on Debian 6 (EOL [1] since 
> 02.16)
>
> However to me, it doesn't matter if it's VyOS or CloudLinux, or 
> another solution.
>
> The question is more like what is wrong with the current VR and how 
> can we make the VR great again. Things I would like to see:
>
> - VR must have a "clean", programmable, documented, API, supporting 
> batch processing.
> - VR must be rock solid (minimal shell) state of the art, up to date, 
> but small (Only contain things CloudStack needs, not more)
> - VR must be scale well (...) and support stateful HA
> - VR must be easy to upgrade (security) without downtimes.
>
> Christmas is soon... ;)
>
> René
>
> [1] https://www.debian.org/News/2016/20160212
>
>

[GitHub] cloudstack issue #1560: CLOUDSTACK-9386: DS template copies don’t get dele...

2016-09-12 Thread rafaelweingartner

Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1560
  
@serg38 great work.
It seems that we already have reviewed this one, and executed tests.
I will merge this PR tomorrow if no one objects.


---
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: [DISCUSS] Replacing the VR

You have probably looked into this more than I have Rene.

I am not sure there existed a time when the VR was ever "great".  In my
eyes, the core ACS dev team should not be building and managing its own
VR.  I feel like that is a liability because the subset of developers who
are proficient in networking is quite small.  That means we could be at
risk of losing the majority of our "experts" with a few people changing
their $dayjob.  It feels safer to work with an existing technology which
has its own development community focused on doing that piece well.
Obviously this has its own drawbacks, but in general, we need the VR
implementation to be built by dedicated network engineers and not jack of
all trade developers.  No offense to current company...

I agree with your list of what you would like to see.  Rock solid and not
over complicated is key.  That being said, if it ONLY handles what ACS
needs today, then WE have to be the ones to develop any changes.  For
example; we need IPv6, VXLAN support, etc...  My point is that if we only
focus on what we need today, then we end up building everything we need for
the future and I think we end up back where we are now down the road...

I love everything you are saying, just not sure I want us building and
maintaining it all...

*Will STEVENS*
Lead Developer

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

On Mon, Sep 12, 2016 at 5:47 PM, Rene Moser  wrote:

> Hi
>
> On 09/12/2016 10:20 PM, Will Stevens wrote:
> > *Disclaimer:* This is a thought experiment and should be treated as such.
> > Please weigh in with the good and bad of this idea...
> >
> > A couple of us have been discussing the idea of potentially replacing the
> > ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
> > issue because I think it is licensed under GPL, but for the sake of
> > discussion, let's assume we can overcome any license issues.
>
> VyOS is Debian based, much like the current VR. As long as it is not
> shipped with CloudStack, all fine.
>
> > I have spent some time recently with the VyOS and I have to admit, I was
> > pretty impressed.  It is simple and intuitive and it gives you a lot more
> > options for auditing the configuration etc...
>
> I had the same "crazy" thoughts when I heard about VyOS the first time.
>
> When I looked at VyOS, the release cycle were not very frequent and the
> current stable release is still based on Debian 6 (EOL [1] since 02.16)
>
> However to me, it doesn't matter if it's VyOS or CloudLinux, or another
> solution.
>
> The question is more like what is wrong with the current VR and how can
> we make the VR great again. Things I would like to see:
>
> - VR must have a "clean", programmable, documented, API, supporting
> batch processing.
> - VR must be rock solid (minimal shell) state of the art, up to date,
> but small (Only contain things CloudStack needs, not more)
> - VR must be scale well (...) and support stateful HA
> - VR must be easy to upgrade (security) without downtimes.
>
> Christmas is soon... ;)
>
> René
>
> [1] https://www.debian.org/News/2016/20160212
>
>

Re: [DISCUSS] Replacing the VR

2016-09-12 Thread Rene Moser

Hi

On 09/12/2016 10:20 PM, Will Stevens wrote:
> *Disclaimer:* This is a thought experiment and should be treated as such.
> Please weigh in with the good and bad of this idea...
> 
> A couple of us have been discussing the idea of potentially replacing the
> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
> issue because I think it is licensed under GPL, but for the sake of
> discussion, let's assume we can overcome any license issues.

VyOS is Debian based, much like the current VR. As long as it is not
shipped with CloudStack, all fine.

> I have spent some time recently with the VyOS and I have to admit, I was
> pretty impressed.  It is simple and intuitive and it gives you a lot more
> options for auditing the configuration etc...

I had the same "crazy" thoughts when I heard about VyOS the first time.

When I looked at VyOS, the release cycle were not very frequent and the
current stable release is still based on Debian 6 (EOL [1] since 02.16)

However to me, it doesn't matter if it's VyOS or CloudLinux, or another
solution.

The question is more like what is wrong with the current VR and how can
we make the VR great again. Things I would like to see:

- VR must have a "clean", programmable, documented, API, supporting
batch processing.
- VR must be rock solid (minimal shell) state of the art, up to date,
but small (Only contain things CloudStack needs, not more)
- VR must be scale well (...) and support stateful HA
- VR must be easy to upgrade (security) without downtimes.

Christmas is soon... ;)

René

[1] https://www.debian.org/News/2016/20160212

Re: [DISCUSS] Replacing the VR

2016-09-12 Thread Syed Ahmed

John,

When you say to decompose the services to multiple containers? Where do you
envision the containers be running? Surely, they must be running in some VM
running on top of the hypervisor otherwise you would not be able to support
all hypervisors. Now the question is, does each individual service require
its own VM? Could you elaborate this further?

Thanks,
-Syed

On Mon, Sep 12, 2016 at 4:52 PM, Will Stevens  wrote:

> Those are fair points John.  I was going down the thought process of "if we
> have a VR, let's use an existing proven technology and not build our own".
>
> I think ACS needs an easy-to-use, out-of-the box default which anyone can
> use without having to think too much about it.  It would be great if it was
> also implemented using a composition of distinct parts, but my initial goal
> was to solve for a drop in replacement.
>
> Let's broaden the discussion to include the potential of introducing
> composable pieces.  If we are rewriting all of this, it would make sense to
> consider that at the same time.  The one thing that I think could be
> challenging if we do that is the backwards compatibility of the plugin
> implementations for the current hardware appliances because the plugin
> hooks may have to change.
>
> Let's keep the conversation going...  :P
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Mon, Sep 12, 2016 at 4:35 PM, John Burwell 
> wrote:
>
> > Will,
> >
> > I agree that we need to replace the VR, but I am not convinced that
> > continuing with the notion of a monolithic application model is a best
> > direction.  The problem with the current model is that it lacks
> > flexibility.  Some users only need to deploy DHCP and DNS across a zone
> > where others need a much wider range of services at the pod or cluster
> > level.  With the monolithic appliance, we are forced to build to the
> lowest
> > common denominator.
> >
> > I would like to see the VR’s functions disambiguated likely into
> > containers (Zones/LXC-style rather than requiring the Docker/rkt
> runtime).
> > With this subdivision, we could then adopt the service chain model and
> > allow users to compose networks services to better fit their use cases.
> >
> > My thinking is that if we are going to through the (continuing) pain of
> > another VR replacement, we should take the opportunity to re-evaluate the
> > entire model.
> >
> > Thanks,
> > -John
> >
> > >
> > john.burw...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> > On Sep 12, 2016, at 4:20 PM, Will Stevens 
> > wrote:
> > >
> > > *Disclaimer:* This is a thought experiment and should be treated as
> such.
> > > Please weigh in with the good and bad of this idea...
> > >
> > > A couple of us have been discussing the idea of potentially replacing
> the
> > > ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a
> license
> > > issue because I think it is licensed under GPL, but for the sake of
> > > discussion, let's assume we can overcome any license issues.
> > >
> > > I have spent some time recently with the VyOS and I have to admit, I
> was
> > > pretty impressed.  It is simple and intuitive and it gives you a lot
> more
> > > options for auditing the configuration etc...
> > >
> > > Items of potential interest:
> > > - Clean up our current VR script spaghetti to a simpler more auditable
> > > configuration workflow.
> > > - Gives a cleaner path for IPv6 support.
> > > - Handles VPN configuration via the same configuration interface.
> > > - Support for OSPF & BGP.
> > > - VPN support through OpenVPN & StrongSwan.
> > > - Easily supports HA (redundant routers) through VRRP.
> > > - VXLAN support.
> > > - Transaction based changes to the VR with rollback on error.
> > >
> > > Items that could be difficult to solve:
> > > - Userdata password reset workflow and implementation.
> > > - Upgrade process.
> > >
> > > The VyOS is not the only option if we were to consider this approach.
> > > Another option, which I don't know as well, would be CloudRouter (AGPL
> > > license) [2] which is purely API driven.
> > >
> > > Anyway, would love to hear your thoughts...
> > >
> > > Will
> > >
> > > [1] https://vyos.io/
> > > [2] https://cloudrouter.org/
> >
> >
>

Re: [DISCUSS] Replacing the VR

Those are fair points John.  I was going down the thought process of "if we
have a VR, let's use an existing proven technology and not build our own".

I think ACS needs an easy-to-use, out-of-the box default which anyone can
use without having to think too much about it.  It would be great if it was
also implemented using a composition of distinct parts, but my initial goal
was to solve for a drop in replacement.

Let's broaden the discussion to include the potential of introducing
composable pieces.  If we are rewriting all of this, it would make sense to
consider that at the same time.  The one thing that I think could be
challenging if we do that is the backwards compatibility of the plugin
implementations for the current hardware appliances because the plugin
hooks may have to change.

Let's keep the conversation going...  :P

*Will STEVENS*
Lead Developer

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

On Mon, Sep 12, 2016 at 4:35 PM, John Burwell 
wrote:

> Will,
>
> I agree that we need to replace the VR, but I am not convinced that
> continuing with the notion of a monolithic application model is a best
> direction.  The problem with the current model is that it lacks
> flexibility.  Some users only need to deploy DHCP and DNS across a zone
> where others need a much wider range of services at the pod or cluster
> level.  With the monolithic appliance, we are forced to build to the lowest
> common denominator.
>
> I would like to see the VR’s functions disambiguated likely into
> containers (Zones/LXC-style rather than requiring the Docker/rkt runtime).
> With this subdivision, we could then adopt the service chain model and
> allow users to compose networks services to better fit their use cases.
>
> My thinking is that if we are going to through the (continuing) pain of
> another VR replacement, we should take the opportunity to re-evaluate the
> entire model.
>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Sep 12, 2016, at 4:20 PM, Will Stevens 
> wrote:
> >
> > *Disclaimer:* This is a thought experiment and should be treated as such.
> > Please weigh in with the good and bad of this idea...
> >
> > A couple of us have been discussing the idea of potentially replacing the
> > ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
> > issue because I think it is licensed under GPL, but for the sake of
> > discussion, let's assume we can overcome any license issues.
> >
> > I have spent some time recently with the VyOS and I have to admit, I was
> > pretty impressed.  It is simple and intuitive and it gives you a lot more
> > options for auditing the configuration etc...
> >
> > Items of potential interest:
> > - Clean up our current VR script spaghetti to a simpler more auditable
> > configuration workflow.
> > - Gives a cleaner path for IPv6 support.
> > - Handles VPN configuration via the same configuration interface.
> > - Support for OSPF & BGP.
> > - VPN support through OpenVPN & StrongSwan.
> > - Easily supports HA (redundant routers) through VRRP.
> > - VXLAN support.
> > - Transaction based changes to the VR with rollback on error.
> >
> > Items that could be difficult to solve:
> > - Userdata password reset workflow and implementation.
> > - Upgrade process.
> >
> > The VyOS is not the only option if we were to consider this approach.
> > Another option, which I don't know as well, would be CloudRouter (AGPL
> > license) [2] which is purely API driven.
> >
> > Anyway, would love to hear your thoughts...
> >
> > Will
> >
> > [1] https://vyos.io/
> > [2] https://cloudrouter.org/
>
>

Re: [DISCUSS] Replacing the VR

2016-09-12 Thread John Burwell

Will,

Typo.  “application model” was meant to be “appliance model”.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
  
 

On Sep 12, 2016, at 4:35 PM, John Burwell  wrote:
> 
> Will,
> 
> I agree that we need to replace the VR, but I am not convinced that 
> continuing with the notion of a monolithic application model is a best 
> direction.  The problem with the current model is that it lacks flexibility.  
> Some users only need to deploy DHCP and DNS across a zone where others need a 
> much wider range of services at the pod or cluster level.  With the 
> monolithic appliance, we are forced to build to the lowest common denominator.
> 
> I would like to see the VR’s functions disambiguated likely into containers 
> (Zones/LXC-style rather than requiring the Docker/rkt runtime).  With this 
> subdivision, we could then adopt the service chain model and allow users to 
> compose networks services to better fit their use cases.
> 
> My thinking is that if we are going to through the (continuing) pain of 
> another VR replacement, we should take the opportunity to re-evaluate the 
> entire model.
> 
> Thanks,
> -John
> 
>> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
> 
> On Sep 12, 2016, at 4:20 PM, Will Stevens  wrote:
>> 
>> *Disclaimer:* This is a thought experiment and should be treated as such.
>> Please weigh in with the good and bad of this idea...
>> 
>> A couple of us have been discussing the idea of potentially replacing the
>> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
>> issue because I think it is licensed under GPL, but for the sake of
>> discussion, let's assume we can overcome any license issues.
>> 
>> I have spent some time recently with the VyOS and I have to admit, I was
>> pretty impressed.  It is simple and intuitive and it gives you a lot more
>> options for auditing the configuration etc...
>> 
>> Items of potential interest:
>> - Clean up our current VR script spaghetti to a simpler more auditable
>> configuration workflow.
>> - Gives a cleaner path for IPv6 support.
>> - Handles VPN configuration via the same configuration interface.
>> - Support for OSPF & BGP.
>> - VPN support through OpenVPN & StrongSwan.
>> - Easily supports HA (redundant routers) through VRRP.
>> - VXLAN support.
>> - Transaction based changes to the VR with rollback on error.
>> 
>> Items that could be difficult to solve:
>> - Userdata password reset workflow and implementation.
>> - Upgrade process.
>> 
>> The VyOS is not the only option if we were to consider this approach.
>> Another option, which I don't know as well, would be CloudRouter (AGPL
>> license) [2] which is purely API driven.
>> 
>> Anyway, would love to hear your thoughts...
>> 
>> Will
>> 
>> [1] https://vyos.io/
>> [2] https://cloudrouter.org/
>

Re: [DISCUSS] Replacing the VR

2016-09-12 Thread John Burwell

Will,

I agree that we need to replace the VR, but I am not convinced that continuing 
with the notion of a monolithic application model is a best direction.  The 
problem with the current model is that it lacks flexibility.  Some users only 
need to deploy DHCP and DNS across a zone where others need a much wider range 
of services at the pod or cluster level.  With the monolithic appliance, we are 
forced to build to the lowest common denominator.

I would like to see the VR’s functions disambiguated likely into containers 
(Zones/LXC-style rather than requiring the Docker/rkt runtime).  With this 
subdivision, we could then adopt the service chain model and allow users to 
compose networks services to better fit their use cases.

My thinking is that if we are going to through the (continuing) pain of another 
VR replacement, we should take the opportunity to re-evaluate the entire model.

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

On Sep 12, 2016, at 4:20 PM, Will Stevens  wrote:
> 
> *Disclaimer:* This is a thought experiment and should be treated as such.
> Please weigh in with the good and bad of this idea...
> 
> A couple of us have been discussing the idea of potentially replacing the
> ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
> issue because I think it is licensed under GPL, but for the sake of
> discussion, let's assume we can overcome any license issues.
> 
> I have spent some time recently with the VyOS and I have to admit, I was
> pretty impressed.  It is simple and intuitive and it gives you a lot more
> options for auditing the configuration etc...
> 
> Items of potential interest:
> - Clean up our current VR script spaghetti to a simpler more auditable
> configuration workflow.
> - Gives a cleaner path for IPv6 support.
> - Handles VPN configuration via the same configuration interface.
> - Support for OSPF & BGP.
> - VPN support through OpenVPN & StrongSwan.
> - Easily supports HA (redundant routers) through VRRP.
> - VXLAN support.
> - Transaction based changes to the VR with rollback on error.
> 
> Items that could be difficult to solve:
> - Userdata password reset workflow and implementation.
> - Upgrade process.
> 
> The VyOS is not the only option if we were to consider this approach.
> Another option, which I don't know as well, would be CloudRouter (AGPL
> license) [2] which is purely API driven.
> 
> Anyway, would love to hear your thoughts...
> 
> Will
> 
> [1] https://vyos.io/
> [2] https://cloudrouter.org/

[GitHub] cloudstack issue #1560: CLOUDSTACK-9386: DS template copies don’t get dele...

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1560
  
@rafaelweingartner @jburwell @karuturi Integration tests passed after merge 
conflict resolution

test DeployVM in anti-affinity groups for project ... === TestName: 
test_DeployVmAntiAffinityGroup_in_project | Status : SUCCESS ===
test DeployVM in anti-affinity groups ... === TestName: 
test_DeployVmAntiAffinityGroup | Status : SUCCESS ===
Test Deploy Virtual Machine ... SKIP: Skipping test because suitable 
hypervisor/host notpresent
Test Deploy Virtual Machine from ISO ... === TestName: 
test_deploy_vm_from_iso | Status : SUCCESS ===
Test deploy virtual machine with root resize ... === TestName: 
test_00_deploy_vm_root_resize | Status : SUCCESS ===
Test proper failure to deploy virtual machine with rootdisksize of 0 ... 
=== TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
Test proper failure to deploy virtual machine with rootdisksize less than 
template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
SUCCESS ===
Test to deploy vm with a first fit offering ... === TestName: 
test_deployvm_firstfit | Status : SUCCESS ===
Test deploy VMs using user concentrated planner ... === TestName: 
test_deployvm_userconcentrated | Status : SUCCESS ===
Test deploy VMs using user dispersion planner ... === TestName: 
test_deployvm_userdispersing | Status : SUCCESS ===
Test userdata as GET, size > 2k ... === TestName: test_deployvm_userdata | 
Status : SUCCESS ===
Test userdata as POST, size > 2k ... === TestName: 
test_deployvm_userdata_post | Status : SUCCESS ===
Test to create disk offering ... === TestName: test_01_create_disk_offering 
| Status : SUCCESS ===
Test to create  a sparse type disk offering ... === TestName: 
test_02_create_sparse_type_disk_offering | Status : SUCCESS ===
Test to create  a sparse type disk offering ... === TestName: 
test_04_create_fat_type_disk_offering | Status : SUCCESS ===
Test to update existing disk offering ... === TestName: 
test_02_edit_disk_offering | Status : SUCCESS ===
Test to delete disk offering ... === TestName: test_03_delete_disk_offering 
| Status : SUCCESS ===
Test to ensure 4 default roles cannot be deleted ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Test to check role, role permissions and account life cycles ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test for role-rule enforcement in case of multiple mgmt servers ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test to ensure role in use cannot be deleted ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests normal lifecycle operations for roles ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests that default four roles exist ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests role update when role is in use by an account ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests concurrent order updation of role permission ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests creation of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests deletion of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests listing of default role's permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests order updation of role permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
test update configuration setting at zone level scope ... === TestName: 
test_UpdateConfigParamWithScope | Status : SUCCESS ===
Test guest vlan range dedication ... === TestName: 
test_dedicateGuestVlanRange | Status : SUCCESS ===
Test create public & private ISO ... === TestName: test_01_create_iso | 
Status : SUCCESS ===
Test Edit ISO ... === TestName: test_02_edit_iso | Status : SUCCESS ===
Test delete ISO ... === TestName: test_03_delete_iso | Status : SUCCESS ===
Test for extract ISO ... === TestName: test_04_extract_Iso | Status : 
SUCCESS ===
Update & Test for ISO permissions ... === TestName: test_05_iso_permissions 
| Status : SUCCESS ===
Test for copy ISO from one zone to another ... SKIP: Not enough zones 
available to perform copy template
Test delete ISO ... === TestName: test_07_list_default_iso | Status : 
SUCCESS ===
Test listing Volumes using 'ids' parameter ... === TestName: 
test_01_list_volumes | Status : SUCCESS ===
Test listing Templates using 'ids' parameter ... === TestName: 
test_02_list_templates | Status : SUCCESS ===
Test listing

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1602
  
@karuturi @jburwell @rafaelweingartner Please disregard. We are still 
running tests for this PR


---
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.
---

[DISCUSS] Replacing the VR

*Disclaimer:* This is a thought experiment and should be treated as such.
Please weigh in with the good and bad of this idea...

A couple of us have been discussing the idea of potentially replacing the
ACS VR with the VyOS [1] (Open Source Vyatta VM).  There may be a license
issue because I think it is licensed under GPL, but for the sake of
discussion, let's assume we can overcome any license issues.

I have spent some time recently with the VyOS and I have to admit, I was
pretty impressed.  It is simple and intuitive and it gives you a lot more
options for auditing the configuration etc...

Items of potential interest:
- Clean up our current VR script spaghetti to a simpler more auditable
configuration workflow.
- Gives a cleaner path for IPv6 support.
- Handles VPN configuration via the same configuration interface.
- Support for OSPF & BGP.
- VPN support through OpenVPN & StrongSwan.
- Easily supports HA (redundant routers) through VRRP.
- VXLAN support.
- Transaction based changes to the VR with rollback on error.

Items that could be difficult to solve:
- Userdata password reset workflow and implementation.
- Upgrade process.

The VyOS is not the only option if we were to consider this approach.
Another option, which I don't know as well, would be CloudRouter (AGPL
license) [2] which is purely API driven.

Anyway, would love to hear your thoughts...

Will

[1] https://vyos.io/
[2] https://cloudrouter.org/

Re: [GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

2016-09-12 Thread Sergey Levitskiy

@jburwell This looks like an awesome system which will improve ACS stability 
big time. Let me know if we can assist in any way. 

On 9/12/16, 12:42 PM, "John Burwell"  wrote:

Sergey,

We are working on a full automated build pipeline that will test against a 
wide range of configurations.  Ideally, the pipeline will work as follows:

 1. PR is submitted -> the PR is built, unit tested, and run through 
static analysis.  Smoke tests are run on a matrix of configurations
 2. The PR is reviewed by two or more committers
 3. When a PR commit receives two or more LGTMs and no -1s, it is 
enqueued to be merged to the target branch
 4. When it’s PR’s turn to be merged, it merged against the target 
release branch and rebuilt (unit tests + static analysis), packaged, and tested 
(smoke test + a set of component tests) on a matrix of configurations
 5. If the PR needs to be forward merged, it is enqueued for the next 
branch and Step 4 is re-executed

In this system, only one PR would be actively merged at a time.  Steps 4 
and 5 are repeated until the PR is merged to master.  This process not only 
ensures that the PR is adequately reviewed and tested, and it also detects 
introduced by merges of adjacent PRs.  blueorganatan is first step in the 
process which provides a way for indicate that a PR is ready for the next step.

We are working towards such a system, but, obviously, there are a lot of 
pieces we need to refine/develop and integrate.  I am working up a release 
management roadmap to capture these ideas in more detail which I hope publish 
in the near future,

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

On Sep 12, 2016, at 3:29 PM, Sergey Levitskiy 
 wrote:
> 
> @swill @jburwell From my, non-committer, point of view introducing fully 
automated test system integrated with PR submission and leveraging complete 
list of supported hypervisors is the key to stability. I really like 
blueorangutain idea and if this can be brought back and also cover full set of 
integration tests along with packaging that would be awesome. When we develop 
PR unfortunately we can only test it only with a certain set of hypervisors and 
network configs so although giving test LGTM it doesn’t cover all possible 
integration points. I believe most other test results people execute manually 
and post on PRs are the same.
> 
> 
> On 9/12/16, 11:38 AM, "jburwell"  wrote:
> Even 
>Github user jburwell commented on the issue:
> 
>https://github.com/apache/cloudstack/pull/1658
> 
>@swill where hardware are being varies by PR.  In some cases, we 
have people running them in their labs and reporting results.  Other cases, 
it's blueorangatan going through ShapeBlue Jenkins + trillian.  But yes, PRs 
are getting tested on hardware.
> 
>(Sadly, we are still recovering from a dead storage array, so 
blueorangatan has been out of commission for a little bit),
> 
> 
>---
>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: [GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

2016-09-12 Thread John Burwell

Sergey,

We are working on a full automated build pipeline that will test against a wide 
range of configurations.  Ideally, the pipeline will work as follows:

 1. PR is submitted -> the PR is built, unit tested, and run through static 
analysis.  Smoke tests are run on a matrix of configurations
 2. The PR is reviewed by two or more committers
 3. When a PR commit receives two or more LGTMs and no -1s, it is enqueued 
to be merged to the target branch
 4. When it’s PR’s turn to be merged, it merged against the target release 
branch and rebuilt (unit tests + static analysis), packaged, and tested (smoke 
test + a set of component tests) on a matrix of configurations
 5. If the PR needs to be forward merged, it is enqueued for the next 
branch and Step 4 is re-executed

In this system, only one PR would be actively merged at a time.  Steps 4 and 5 
are repeated until the PR is merged to master.  This process not only ensures 
that the PR is adequately reviewed and tested, and it also detects introduced 
by merges of adjacent PRs.  blueorganatan is first step in the process which 
provides a way for indicate that a PR is ready for the next step.

We are working towards such a system, but, obviously, there are a lot of pieces 
we need to refine/develop and integrate.  I am working up a release management 
roadmap to capture these ideas in more detail which I hope publish in the near 
future,

Thanks,
-John

> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

On Sep 12, 2016, at 3:29 PM, Sergey Levitskiy  
wrote:
> 
> @swill @jburwell From my, non-committer, point of view introducing fully 
> automated test system integrated with PR submission and leveraging complete 
> list of supported hypervisors is the key to stability. I really like 
> blueorangutain idea and if this can be brought back and also cover full set 
> of integration tests along with packaging that would be awesome. When we 
> develop PR unfortunately we can only test it only with a certain set of 
> hypervisors and network configs so although giving test LGTM it doesn’t cover 
> all possible integration points. I believe most other test results people 
> execute manually and post on PRs are the same.
> 
> 
> On 9/12/16, 11:38 AM, "jburwell"  wrote:
> Even 
>Github user jburwell commented on the issue:
> 
>https://github.com/apache/cloudstack/pull/1658
> 
>@swill where hardware are being varies by PR.  In some cases, we have 
> people running them in their labs and reporting results.  Other cases, it's 
> blueorangatan going through ShapeBlue Jenkins + trillian.  But yes, PRs are 
> getting tested on hardware.
> 
>(Sadly, we are still recovering from a dead storage array, so 
> blueorangatan has been out of commission for a little bit),
> 
> 
>---
>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: Merging PRs

Thanks for this John.

Maybe link to the release schedule as well so people know when branches
will expect to be frozen as well.

*Will STEVENS*
Lead Developer

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

On Mon, Sep 12, 2016 at 3:15 PM, John Burwell 
wrote:

> All,
>
> There appears to be some confusion around who can merge a PR and when it
> should occur.  Section 2.3 of bylaws [1] are very clear, any committer may
> commit code to any branch.  As a community, we have agreed that
> non-security contributions should be submitted as a PR, and that a PR must
> meet the following criteria in order to be merged to a release branch:
>
> * At least code review LGTM
> * At least test LGTM
> * No -1s
>
> There have also been questions about what qualifies as a test LGTM.  Code
> reviewers should expect either new or updated Marvin test cases that verify
> the issue being addressed by the PR.  For my reviews, I consider a valid
> test LGTM to have the following characteristics:
>
>* All smoke tests run against hardware.  Ideally, against all 3
> hypervisors when the change is core.
>* A set of additional component tests that cover the the functionality
> that has been modified including tests added for the change
>
> When a PR meets this criteria, any committer may merge a PR using the
> process described in the this wiki topic [2].  As a release manager, I
> regularly check merges to release branches ensure that they meet this
> threshold.  If I find a non-security merge that does not meet this
> criteria, I will roll it back and work with the contributors involved to
> merged it once the threshold has been met.
>
> I plan to update the release section of the wiki in the near future to
> clarify these points to remove crufty/duplicative information.  I apologize
> for the confusion, and hope this email clarifies the merge process until I
> complete the wiki update.
>
> Thanks,
> -John
>
> [1]: https://cloudstack.apache.org/bylaws.html
> [2]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Release+principles+for+Apache+CloudStack+4.6+and+up#
> ReleaseprinciplesforApacheCloudStack4.6andup-HowtomergeaPullRequest?
>
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: [GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

2016-09-12 Thread Sergey Levitskiy

@swill @jburwell From my, non-committer, point of view introducing fully 
automated test system integrated with PR submission and leveraging complete 
list of supported hypervisors is the key to stability. I really like 
blueorangutain idea and if this can be brought back and also cover full set of 
integration tests along with packaging that would be awesome. When we develop 
PR unfortunately we can only test it only with a certain set of hypervisors and 
network configs so although giving test LGTM it doesn’t cover all possible 
integration points. I believe most other test results people execute manually 
and post on PRs are the same.


On 9/12/16, 11:38 AM, "jburwell"  wrote:
 Even 
Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill where hardware are being varies by PR.  In some cases, we have 
people running them in their labs and reporting results.  Other cases, it's 
blueorangatan going through ShapeBlue Jenkins + trillian.  But yes, PRs are 
getting tested on hardware.

(Sadly, we are still recovering from a dead storage array, so 
blueorangatan has been out of commission for a little bit),


---
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: CS 4.9 NIO Selector wait time PR-1601

2016-09-12 Thread martin kolly


We could fix the issue by generating new pairs of ssh keys. Here the
procedure we applied:

1) Stop Management Server

2) Delete SSH Keys in mysql Database:
delete from configuration  where name = "ssh.publickey" ;
delete from configuration  where name = "ssh.privatekey" ;

3) Delete the SSH Keys
rm /var/lib/cloudstack/management/.ssh/id_rsa.pub
rm /var/lib/cloudstack/management/.ssh/id_rsa

4) Start the Management Server
- SSH Keys are generated and mysql entries inserted

# grep  ssh-keygen /var/log/cloudstack/management/management-server.log
2016-09-12 20:47:40,000 DEBUG [c.c.u.s.Script] (main:null) (logid:)
Executing: /bin/bash -c if [ -f
/var/lib/cloudstack/management/.ssh/id_rsa ]; then rm -f
/var/lib/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N ''
-f /var/lib/cloudstack/management/.ssh/id_rsa -q
2016-09-12 20:54:23,835 DEBUG [c.c.u.s.Script] (main:null) (logid:)
Executing: /bin/bash -c if [ -f
/var/lib/cloudstack/management/.ssh/id_rsa ]; then rm -f
/var/lib/cloudstack/management/.ssh/id_rsa; fi; ssh-keygen -t rsa -N ''
-f /var/lib/cloudstack/management/.ssh/id_rsa -q

Now works like a charm!

thanks and regards
martin


On 09/12/2016 04:22 PM, martin kolly wrote:
> Hi Rohit
>
> Finally we had some time to dig deeper into this issue. The /bin/bash
> issue was a typo on our side, sorry!
>
> System VM was destroyed/recreated several times.
>
> But something with the ssh keys is still wrong. The KVM is still
> asking for the pass phrase when ssh into system vms.
>
> *# Management Server*
> mysql> select * from configuration where name = "ssh.publickey" \G;
> *** 1. row ***
>  category: Hidden
>  instance: DEFAULT
> component: management-server
>  name: ssh.publickey
> value:
> XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a
>   description: Public key for the entire CloudStack
> default_value: NULL
>   updated: NULL
> scope: NULL
>is_dynamic: 0
> 1 row in set (0.00 sec)
>
> mysql> select * from configuration where name = "ssh.privatekey" \G;
> *** 1. row ***
>  category: Hidden
>  instance: DEFAULT
> component: management-server
>  name: ssh.privatekey
> value:
> j+Z5ckPXUq7lwo2L4OYaaiDOA/fdUpadX3h7E/DA1rwPRSz967eckCbRRpCtCWxfQjtAgPNfLgGIQHX4K7o9yF9DBXG0ESXoECyrRAOTmfZdvdSZceRGd9TYcjwCAn4s8GKGQRKeQSQLL8Pusc/PmYLISIomkOHhZB3lp1bfniKC6uf6RwhRFNfX38ZeqVhRNgagK2hxOo67Ev7uUX1NIUWw/ROq/RC7bG58DD1uhUOX5Bm5wVMSmf3Pv7s/z2t7ZGcX8YMnW
> .
> 
> 
> 
> /uPooWhUQpcG8Q8APvfEKMp0BVJATh4Gk4qkgnR4CHyefUYCDHmWZnpuCj1ra7Kn5LV7AdWG1+C7bl7hSmpxE8StLfEwe72zuPJsI86LekxhJJpsorjvSFYklJhGizSs4uuyRP2Dqayx1qFkFJe26AiWb86ld2gQ2Vwj3ozgHX2OMp60jQM8ZVM9VuroOEmiOZ5gkfhFFIf5Y78WcZU2ScSCAHVavNAIsfX+i01iNxwnXtrmrA9ctlZGuZZRR3TklAXQz4M69SFFYuo5e7OsJ2/Tr9K7AhUHA8kwR+BxPLFGRlJpyhmLUuPartDKRBAp2BwU1XsFiIs8Y6pn9wkRJaeeDdpUt9zPCYMHaHtXQvFMe+d96J4HMPvfLgGnd55Hz7GKsglX9su7XpuAqzkuPM5u6GY5LLAtXUOqE2Wm855sLRW1kbHnX8pAfIe9wQbfUQ9wsfCh66w1duce0vyuj4A7A8HC4V8+U2qXjwMIhLpfO5phfUy4drlUzBzx9ZMK+JUYP6kszj61M09psoYggUBXMYCfg6oWJSjA8=
>   description: Private key for the entire CloudStack
> default_value: NULL
>   updated: NULL
> scope: NULL
>is_dynamic: 0
> 1 row in set (0.00 sec)
>
> *# Secondary Storage VM (note that the key is equal to the management
> server database entry ssh.publickey)*
> root@s-252-VM:~# cat /root/.ssh/authorized_keys
> XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a
>
> root@s-252-VM:~# ifconfig eth0
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:00:18 
>   inet addr:169.254.0.24  Bcast:169.254.255.255  Mask:255.255.0.0
>
> *#KVM Hosts*
> root@kvm704:~/.ssh# cat /root/.ssh/id_rsa.pub.cloud
>

There appears to be some confusion around who can merge a PR and when it should
occur. Section 2.3 of bylaws [1] are very clear, any committer may commit code
to any branch. As a community, we have agreed that non-security contributions
should be submitted as a PR, and that a PR must meet the following criteria in
order to be merged to a release branch:

* At least code review LGTM
* At least test LGTM
* No -1s

There have also been questions about what qualifies as a test LGTM. Code
reviewers should expect either new or updated Marvin test cases that verify the
issue being addressed by the PR. For my reviews, I consider a valid test LGTM
to have the following characteristics:

* All smoke tests run against hardware. Ideally, against all 3 hypervisors
when the change is core.
* A set of additional component tests that cover the the functionality that
has been modified including tests added for the change

When a PR meets this criteria, any committer may merge a PR using the process
described in the this wiki topic [2]. As a release manager, I regularly check
merges to release branches ensure that they meet this threshold. If I find a
non-security merge that does not meet this criteria, I will roll it back and
work with the contributors involved to merged it once the threshold has been
met.

I plan to update the release section of the wiki in the near future to clarify
these points to remove crufty/duplicative information. I apologize for the
confusion, and hope this email clarifies the merge process until I complete the
wiki update.

Thanks,
-John

[1]: https://cloudstack.apache.org/bylaws.html
[2]:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-HowtomergeaPullRequest?

john.burw...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

[GitHub] cloudstack pull request #1658: Added an additional JSON diff output to the A...

2016-09-12 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1658


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell ok cool.  I will try to start getting my CI run against master 
every week to help make sure that master is happy.  Hopefully that will help as 
well.  :)

Alright, I think we have side barred this PR enough.  I am going to merge 
it...


---
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.
---

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1602
  
@karuturi @jburwell @rafaelweingartner Can you check if this PR can be 
merged? 


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill where hardware are being varies by PR.  In some cases, we have 
people running them in their labs and reporting results.  Other cases, it's 
blueorangatan going through ShapeBlue Jenkins + trillian.  But yes, PRs are 
getting tested on hardware.

(Sadly, we are still recovering from a dead storage array, so blueorangatan 
has been out of commission for a little bit),


---
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.
---

[GitHub] cloudstack issue #1602: CLOUDSTACK-9422: Granular 'vmware.create.full.clone'...

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1602
  
LGTM for testing

[root@ussarlabcsmgt41 MarvinLogs]# cat 
/tmp//MarvinLogs/test_volumes_CP3Z7R/results.txt
test DeployVM in anti-affinity groups for project ... === TestName: 
test_DeployVmAntiAffinityGroup_in_project | Status : SUCCESS ===
ok
test DeployVM in anti-affinity groups ... === TestName: 
test_DeployVmAntiAffinityGroup | Status : SUCCESS ===
ok
Test Deploy Virtual Machine ... SKIP: Skipping test because suitable 
hypervisor/host notpresent
Test Deploy Virtual Machine from ISO ... === TestName: 
test_deploy_vm_from_iso | Status : SUCCESS ===
ok
Test deploy virtual machine with root resize ... === TestName: 
test_00_deploy_vm_root_resize | Status : SUCCESS ===
ok
Test proper failure to deploy virtual machine with rootdisksize of 0 ... 
=== TestName: test_01_deploy_vm_root_resize | Status : SUCCESS ===
ok
Test proper failure to deploy virtual machine with rootdisksize less than 
template size ... === TestName: test_02_deploy_vm_root_resize | Status : 
SUCCESS ===
ok
Test to deploy vm with a first fit offering ... === TestName: 
test_deployvm_firstfit | Status : SUCCESS ===
ok
Test deploy VMs using user concentrated planner ... === TestName: 
test_deployvm_userconcentrated | Status : SUCCESS ===
ok
Test deploy VMs using user dispersion planner ... === TestName: 
test_deployvm_userdispersing | Status : SUCCESS ===
ok
Test userdata as GET, size > 2k ... === TestName: test_deployvm_userdata | 
Status : SUCCESS ===
ok
Test userdata as POST, size > 2k ... === TestName: 
test_deployvm_userdata_post | Status : SUCCESS ===
ok
Test to create disk offering ... === TestName: test_01_create_disk_offering 
| Status : SUCCESS ===
ok
Test to create  a sparse type disk offering ... === TestName: 
test_02_create_sparse_type_disk_offering | Status : SUCCESS ===
ok
Test to create  a sparse type disk offering ... === TestName: 
test_04_create_fat_type_disk_offering | Status : SUCCESS ===
ok
Test to update existing disk offering ... === TestName: 
test_02_edit_disk_offering | Status : SUCCESS ===
ok
Test to delete disk offering ... === TestName: test_03_delete_disk_offering 
| Status : SUCCESS ===
ok
Test to ensure 4 default roles cannot be deleted ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Test to check role, role permissions and account life cycles ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test for role-rule enforcement in case of multiple mgmt servers ... SKIP: 
Dynamic Role-Based API checker not enabled, skipping test
Test to ensure role in use cannot be deleted ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests normal lifecycle operations for roles ... SKIP: Dynamic Role-Based 
API checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests that default four roles exist ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests role update ... SKIP: Dynamic Role-Based API checker not enabled, 
skipping test
Tests role update when role is in use by an account ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests concurrent order updation of role permission ... SKIP: Dynamic 
Role-Based API checker not enabled, skipping test
Tests creation of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests deletion of role permission ... SKIP: Dynamic Role-Based API checker 
not enabled, skipping test
Tests listing of default role's permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
Tests order updation of role permission ... SKIP: Dynamic Role-Based API 
checker not enabled, skipping test
test update configuration setting at zone level scope ... === TestName: 
test_UpdateConfigParamWithScope | Status : SUCCESS ===
ok
Test guest vlan range dedication ... === TestName: 
test_dedicateGuestVlanRange | Status : SUCCESS ===
ok
Test create public & private ISO ... === TestName: test_01_create_iso | 
Status : SUCCESS ===
ok
Test Edit ISO ... === TestName: test_02_edit_iso | Status : SUCCESS ===
ok
Test delete ISO ... === TestName: test_03_delete_iso | Status : SUCCESS ===
ok
Test for extract ISO ... === TestName: test_04_extract_Iso | Status : 
SUCCESS ===
ok
Update & Test for ISO permissions ... === TestName: test_05_iso_permissions 
| Status : SUCCESS ===
ok
Test for copy ISO from one zone to another ... SKIP: Not enough zones 
available to perform copy template
Test delete ISO ... === TestName: test_07_list_default_iso | Status : 
SUCCESS ===
ok
Test listing Volumes using 'ids' parameter ... === TestName:

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell ok cool.  I didn't realize that we had Marvin tests running 
against hardware to validate the PRs.  Is it just Travis using the simulator or 
do we have real hardware CI being run?  Is this being done with Trillian?


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill other than verifying that the proper review has been done and a 
reasonable set of Marvin test cases have been run on the appropriate platforms, 
what else are you expecting?  


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell I feel like we are not discussing the same thing.  I understand 
where you are coming from regarding the operational merging of PRs and I don't 
disagree with you.  2 LGTM with a 1 test and it gets merged (by someone)...

What I am trying to understand is how we are maintaining the stability of 
master.  Just because two people give it a LGTM and Travis is green does not 
mean that it does not break something.  There were a lot of PRs in 4.9 where 
Travis was green and CI still caught problems.  I am trying to understand how 
we are currently ensuring the master branch stays stable...


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill the RM is still maintaining the stability of master.  I check that 
all non-security merges meet the criteria we have laid out.  If/when I find one 
that does not, I will roll it back, and work with the contributors to address 
the deficiencies.  The value of the process to which we have agreed is not who 
performs the merge operation, but the 2 LGTM threshold.

By definition, committers co-equals in the community.  What makes @karuturi 
or myself any more capable/qualified committers to assess a PR and merge it?  
We simply volunteered to do help marshall releases.  We have PRs that have 
languished simply waiting for one of us to have time to run a script when any 
other committer could have done it.  If there are committers that you (or 
anyone else) feels have not fulfilled the trust they have been imparted, there 
are mechanisms for addressing those issues via PMC.  Rather than restricting 
the flow of work, let's address those types of issues individually as the 
Apache Way is designed.


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell since 4.6 we have effectively had the RM merge everything.  I am 
not saying that is required, or even specified anywhere, but the reason we have 
been doing that was because the RM was actively maintaining the stability of 
master.  Regardless of who is merging what, my question stands.  How are we 
validating the stability of master right now?  All the other details are 
basically irrelevant, this is the single most important question...


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill we never had a policy that only release managers could merge.  Remi 
was active that he typically merged PRs before anyone else had a chance.  The 
[release 
principles|https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up]
 to which we agreed only said that a PR needed 1 code review LGTM, 1 test LGTM, 
and no -1s.  It also lays out how it should be done.  Nowhere in that document 
does it restrict who can perform a PR merge.  To take away that privilege 
requires a change to the bylaws.  Personally, I don't recall a vote where I 
gave my rights as a committer.


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell we have not been operating that way since 4.6 for a reason.  I 
understand it is that way in the bylaws, but the bylaws are not currently 
written to protect the stability of master.  How are we protecting the 
stability of master right now???  If we are not protecting the stability of 
master, then a free-for-all is a liability to the project, regardless of what 
the bylaws say.


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@karuturi there is no discussion to be had.  According to our bylaws, 
committers have the right to commit to any branch.  Period.  Full stop.  If you 
would like to change it, propose a change to the bylaws.


---
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.
---

[GitHub] cloudstack pull request #1624: Fixes regarding VOLUME_DELETE events resultin...

2016-09-12 Thread nnesic

Github user nnesic commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1624#discussion_r78407479
  
--- Diff: server/src/com/cloud/user/AccountManagerImpl.java ---
@@ -761,6 +774,17 @@ protected boolean cleanupAccount(AccountVO account, 
long callerUserId, Account c
 s_logger.error("Unable to expunge vm: " + vm.getId());
 accountCleanupNeeded = true;
 }
+else if 
(!vm.getState().equals(VirtualMachine.State.Destroyed)) {
+// We have to emit the event here because the state 
listener is ignoring root volume deletions,
+// assuming that the UserVMManager is responsible for 
emitting the usage event for them when
--- End diff --

The reason why the delete events for the root volume are not handled by the 
state listener is that the root volumes don't get destroyed until the VM is 
expunged. Because of this, if we rely on the state listener to emit the event, 
the timestamp on the event will not reflect the actual time when the user 
requested and expects the volume to be destroyed. 

For now, I would not move the logic for handling these events out of 
UserVMManager. However, thinking about this again, I agree that it would be 
better not to scatter this event emitting further. Instead, I am working adding 
a call to vmMgr.destroy during the cleanup of the account (right now the 
manager is taking a shortcut, and expunging machines directly). Does that sound 
better?


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@karuturi no worries, I know the comment was not related to this specific 
PR and is related to the larger topic of how we are currently handling merge 
policy.

I have been a bit MIA for the last few weeks, so I have not kept up on this 
conversation.  I am currently unclear on what our merge policy is right now, 
which is why I am asking.  I know that as a CloudStack committer, I have the 
right to commit, but the free-for-all commit policy is also what made master 
unstable until 4.6.  I am not sure what checks and balances we have in place to 
guarantee the stability of master right now.  I hope we are not counting only 
on Travis since there were many cases when I was RM where Travis showed green, 
but bubble would catch problems...

I don't mind holding off on merging this if we would like to discuss a bit 
more in this issue...


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@swill sorry to hijack. This is not a -1 for you to commit. Please go 
ahead. I just want to make it clear that we as a community never concluded on 
that discussion. But, given how things are going in the project, I guess I dont 
mind either way.


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell & @karuturi please advise.  This PR should be ready to be 
merged...


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
@jburwell we didnt conclude on that discussion. Its not the policy as of 
now. 


---
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.
---

[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
I rebased against the current master.  I will merge this as soon as the 
status comes back green...


---
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: CS 4.9 NIO Selector wait time PR-1601

2016-09-12 Thread martin kolly

Hi Rohit

Finally we had some time to dig deeper into this issue. The /bin/bash
issue was a typo on our side, sorry!

System VM was destroyed/recreated several times.

But something with the ssh keys is still wrong. The KVM is still asking
for the pass phrase when ssh into system vms.

*# Management Server*
mysql> select * from configuration where name = "ssh.publickey" \G;
*** 1. row ***
 category: Hidden
 instance: DEFAULT
component: management-server
 name: ssh.publickey
value:
XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a
  description: Public key for the entire CloudStack
default_value: NULL
  updated: NULL
scope: NULL
   is_dynamic: 0
1 row in set (0.00 sec)

mysql> select * from configuration where name = "ssh.privatekey" \G;
*** 1. row ***
 category: Hidden
 instance: DEFAULT
component: management-server
 name: ssh.privatekey
value:
j+Z5ckPXUq7lwo2L4OYaaiDOA/fdUpadX3h7E/DA1rwPRSz967eckCbRRpCtCWxfQjtAgPNfLgGIQHX4K7o9yF9DBXG0ESXoECyrRAOTmfZdvdSZceRGd9TYcjwCAn4s8GKGQRKeQSQLL8Pusc/PmYLISIomkOHhZB3lp1bfniKC6uf6RwhRFNfX38ZeqVhRNgagK2hxOo67Ev7uUX1NIUWw/ROq/RC7bG58DD1uhUOX5Bm5wVMSmf3Pv7s/z2t7ZGcX8YMnW
.



/uPooWhUQpcG8Q8APvfEKMp0BVJATh4Gk4qkgnR4CHyefUYCDHmWZnpuCj1ra7Kn5LV7AdWG1+C7bl7hSmpxE8StLfEwe72zuPJsI86LekxhJJpsorjvSFYklJhGizSs4uuyRP2Dqayx1qFkFJe26AiWb86ld2gQ2Vwj3ozgHX2OMp60jQM8ZVM9VuroOEmiOZ5gkfhFFIf5Y78WcZU2ScSCAHVavNAIsfX+i01iNxwnXtrmrA9ctlZGuZZRR3TklAXQz4M69SFFYuo5e7OsJ2/Tr9K7AhUHA8kwR+BxPLFGRlJpyhmLUuPartDKRBAp2BwU1XsFiIs8Y6pn9wkRJaeeDdpUt9zPCYMHaHtXQvFMe+d96J4HMPvfLgGnd55Hz7GKsglX9su7XpuAqzkuPM5u6GY5LLAtXUOqE2Wm855sLRW1kbHnX8pAfIe9wQbfUQ9wsfCh66w1duce0vyuj4A7A8HC4V8+U2qXjwMIhLpfO5phfUy4drlUzBzx9ZMK+JUYP6kszj61M09psoYggUBXMYCfg6oWJSjA8=
  description: Private key for the entire CloudStack
default_value: NULL
  updated: NULL
scope: NULL
   is_dynamic: 0
1 row in set (0.00 sec)

*# Secondary Storage VM (note that the key is equal to the management
server database entry ssh.publickey)*
root@s-252-VM:~# cat /root/.ssh/authorized_keys
XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5a

root@s-252-VM:~# ifconfig eth0
eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:00:18 
  inet addr:169.254.0.24  Bcast:169.254.255.255  Mask:255.255.0.0

*#KVM Hosts*
root@kvm704:~/.ssh# cat /root/.ssh/id_rsa.pub.cloud
XiVYy4PpuS4nKoQZRsj+3VQr0dxXFt+s15ZVXiIbaacJ5RsLwlSEO75kbPaL7pDAhyZbcCtC3ICSDUAeJysZ958cTVrl390Lk0UtRoLOUKlNIuOEVzdJpZDmsrm90ZK+OYMaHKf2cVz3xekZv/BS5Kpr2dnieUNZlQlgCXgldwENNZ7+MSlPRLiJ+7/SEBtfn9VTUkXvedhbBtIh3fxexOR/xN+zGRTyotlYANxiypklrlZp6/364JfXoeQviE6aVzsVDboALW+ov6gFj8ziO7vhoUN9M6rJohGnPawjgMCBasVCjWqoFaezKlf/0vEDf3NkKOoi1kqvSDGOumCFyQ7+9BOBq8qdqnP3i4e4aJ3vLdVWlRKRaUps08xOP8+j36L9lrO0YAkGXH+bAQXzQMqIFLvjRGX+zOnEikRQ2Zv0JJSlAvftF13BQrTt1SV/ttDa0qo7fzqF1WUijZb/PcKLGUeC30U9kG4JLmrHcuaoe43I08qkGJEofUetZGQLIYhsUqXiVSflGEGfJTWJgMGKAVbGUF5aroot@kvm704

root@kvm704:~/.ssh# ssh -p 3922 -q -o StrictHostKeyChecking=no -i
/root/.ssh/id_rsa.cloud root@169.254.0.24
Enter passphrase for key '/root/.ssh/id_rsa.cloud':

*# Router which was not redeployed *
root@r-191-VM:~# cat .ssh/authorized_keys
ssh-rsa
B3NzaC1yc2EDAQABAAABAQDoZcfuh/R2i/n69hFBJEfKKtTQQAs7iOIC9PxFUWrFONk9m4R8Atj8o5wLyHflhe10iMHUJTGH84/J4min1r7zU4xGqzOBR3CKuz6dowmC+IQ38iyJfTOC9L1eIl8AebmKNwSSgjS6nc6sK13iFpgr8mSIr7ExcXPxYgWNgbQAm/HvLVc8Ivf2FZR8f26i3EyjsLVKpHoyvVMeVdoAHBdQB/NiUslAz2fz3cPXxVSxpZobd7iy/uJNVK1CHvqhGYLrXym9cjfM0BOUhN80NN9SvAiyj9D7PHiwcDBzMSSPljxwF6rPY7BXHq+7AVvzVPTJYEuBVQllYn1RrjCS/Fdr
cloud@cloudstack

If we understand correctly the public and private key are encrypted in
the management database. Based on the Source Code
master# ag ssh.publickey
server/src/com/cloud/server/ConfigurationServerImpl.java
761:"VALUES ('Hidden','DEFAULT',
'management-server','ssh.publickey', '"
+*DBEncryptionUtil.encrypt(publicKey)* +
855:String

[GitHub] cloudstack issue #872: Strongswan vpn feature

2016-09-12 Thread kiwiflyer

Github user kiwiflyer commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
Yeah, I think this one is dead unless it gets reworked into a new PR. We 
might be able to help a bit on this one as well.


---
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.
---

[GitHub] cloudstack issue #872: Strongswan vpn feature

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/872
  
Given the lack of response, I am guessing I should just clone the work from 
this PR into my own branch and open a new PR once I have everything working...


---
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: System VM's are getting stuck in starting mode

2016-09-12 Thread Tutkowski, Mike

Thanks

Yeah, I wasn't sure if you just experienced it on reboot or if sometimes when 
setting up your cloud you encountered this issue, as well (like 9144).

From: ned dogg 
Sent: Monday, September 12, 2016 6:08 AM
To: dev@cloudstack.apache.org
Subject: Re: System VM's are getting stuck in starting mode

Hi Mike and thank you for the reply. Sorry but this issue is not similar
 to mine, I already gave you the one which looks similar :
https://issues.apache.org/jira/browse/CLOUDSTACK-7936

On Sun, Sep 11, 2016 at 5:28 AM, Tutkowski, Mike 
wrote:

> Is your issue similar to this one?
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9144
> 
> From: ned dogg 
> Sent: Saturday, September 10, 2016 1:24 PM
> To: dev@cloudstack.apache.org
> Subject: System VM's are getting stuck in starting mode
>
> Hi Everybody,
>
> I'm a newbie on cloudstack. I started playing with this technology. For
> that I install both the management -server and the agent. I was able to
> install and start them properly but I unable to create any instance. When I
> click on instance the menu then I  click on add instance and next, I have
> no templates that is presented to me. Thus I stuck at this level. I don't
> know what to do.
>
> I think that this issue is because my System VM get stuck an the starting
> mode. After some googling, I discovered that this is a know issue
> https://issues.apache.org/jira/browse/CLOUDSTACK-7936. But this issue is
> for cloudstack 4.4.1 but I'm using cloudstack 4.6. I was asking myself if
> this issue is also common on cloudstack 4.6?
>
> Please any help will be welcoming.
> Thanks.
>

[GitHub] cloudstack issue #798: CLOUDSTACK-8830 - [Vmware] VM snapshot fails for 12 m...

2016-09-12 Thread rafaelweingartner

Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/798
  
@nvazquez I have the impression that @maneesha-p is not working with ACS 
anymore.

I guess you can go ahead and proper code this changes into a PR to be 
merged into master. If you need any assistance, just give me a heads up.
When you create your PR you can add the following to your commit message: 
This closes #798

Then, when your PR gets merged, this one will also be closed.



---
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: System VM's are getting stuck in starting mode

2016-09-12 Thread Simon Weller

ok, so your SSVM is just cycling constantly, correct?


Can you pull the logs from 
/var/log/cloudstack/management/management-server.log? Also, please turn on 
debug on logging on your hosts (sed -i 's/INFO/DEBUG/g' 
/etc/cloudstack/agent/log4j-cloud.xml) and restart your agents. Please grab 
those logs as well and post then to pastebin.


- Si





From: ned dogg 
Sent: Monday, September 12, 2016 7:11 AM
To: dev@cloudstack.apache.org
Subject: Re: System VM's are getting stuck in starting mode

Hi Simon,

I use Ubuntu 14.04 with cloudstack 4.6 installed. And I'm using a KVM
hypervisor. I also set up a basic zone.

On Sat, Sep 10, 2016 at 9:46 PM, Simon Weller  wrote:

> Hi,
>
> Can you tell us more about your environment?
>
> What hypervisor are you using? Is this a basic or advanced zone?
>
>
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: ned dogg [neddog...@gmail.com]
> Received: Saturday, 10 Sep 2016, 2:24PM
> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> Subject: System VM's are getting stuck in starting mode
>
> Hi Everybody,
>
> I'm a newbie on cloudstack. I started playing with this technology. For
> that I install both the management -server and the agent. I was able to
> install and start them properly but I unable to create any instance. When I
> click on instance the menu then I  click on add instance and next, I have
> no templates that is presented to me. Thus I stuck at this level. I don't
> know what to do.
>
> I think that this issue is because my System VM get stuck an the starting
> mode. After some googling, I discovered that this is a know issue
> https://issues.apache.org/jira/browse/CLOUDSTACK-7936. But this issue is
[CLOUDSTACK-7936] System VM's are getting stuck in 
...
issues.apache.org
CloudStack; CLOUDSTACK-7936; System VM's are getting stuck in starting mode 
after Hypervisor reboot



> for cloudstack 4.4.1 but I'm using cloudstack 4.6. I was asking myself if
> this issue is also common on cloudstack 4.6?
>
> Please any help will be welcoming.
> Thanks.
>

[GitHub] cloudstack issue #1651: Marvin Tests: fix expected return string for success...

2016-09-12 Thread rafaelweingartner

Github user rafaelweingartner commented on the issue:

https://github.com/apache/cloudstack/pull/1651
  
@jburwell me too ;)
I like the idea of a single commit with a commit message of 80 characters, 
and then a paragraph description, bullets or both that describe the whole work 
that has been done here.


---
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: System VM's are getting stuck in starting mode

2016-09-12 Thread ned dogg

Hi Simon,

I use Ubuntu 14.04 with cloudstack 4.6 installed. And I'm using a KVM
hypervisor. I also set up a basic zone.

On Sat, Sep 10, 2016 at 9:46 PM, Simon Weller  wrote:

> Hi,
>
> Can you tell us more about your environment?
>
> What hypervisor are you using? Is this a basic or advanced zone?
>
>
>
> Simon Weller/ENA
> (615) 312-6068
>
> -Original Message-
> From: ned dogg [neddog...@gmail.com]
> Received: Saturday, 10 Sep 2016, 2:24PM
> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> Subject: System VM's are getting stuck in starting mode
>
> Hi Everybody,
>
> I'm a newbie on cloudstack. I started playing with this technology. For
> that I install both the management -server and the agent. I was able to
> install and start them properly but I unable to create any instance. When I
> click on instance the menu then I  click on add instance and next, I have
> no templates that is presented to me. Thus I stuck at this level. I don't
> know what to do.
>
> I think that this issue is because my System VM get stuck an the starting
> mode. After some googling, I discovered that this is a know issue
> https://issues.apache.org/jira/browse/CLOUDSTACK-7936. But this issue is
> for cloudstack 4.4.1 but I'm using cloudstack 4.6. I was asking myself if
> this issue is also common on cloudstack 4.6?
>
> Please any help will be welcoming.
> Thanks.
>

[GitHub] cloudstack pull request #866: CLOUDSTACK-8751 minimise downtime of network w...

2016-09-12 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/866


---
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.
---

[GitHub] cloudstack issue #866: CLOUDSTACK-8751 minimise downtime of network when net...

2016-09-12 Thread abhinandanprateek

Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/866
  
@bvbharatk thanks for the update if possible file a jira ticket for this 
issue.

 I just want to note that this has nothing to do with current PR which 
looks good.


---
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.
---

[GitHub] cloudstack issue #866: CLOUDSTACK-8751 minimise downtime of network when net...

2016-09-12 Thread bvbharatk

Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/866
  
@abhinandanprateek 
Hi Abhi, 
This test is failing because of test case clean up issues. Blow are the log 
messages from marvin 
Job failed: {jobprocstatus : 0, created : u'2016-09-12T07:06:55-0400', cmd 
: u'org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd', 
userid : u'050d9020-78cd-11e6-a70e-00163e174325', jobstatus : 2, jobid : 
u'992cfb19-2b76-47f0-89ae-9d700c46b3bf', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 431, errortext : u'physicalnetwork 200 has 
allocated vnets in the range 731-732'}, accountid : 
u'050d5cc2-78cd-11e6-a70e-00163e174325'}


---
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.
---

[GitHub] cloudstack issue #866: CLOUDSTACK-8751 minimise downtime of network when net...

2016-09-12 Thread abhinandanprateek

Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/866
  
@karuturi Do we know why test_non_contigiousvlan.py is failing ?


---
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.
---

[GitHub] cloudstack issue #866: CLOUDSTACK-8751 minimise downtime of network when net...