[GitHub] cloudstack issue #1815: Fix docker image build for cloudstack-management

[sebgoa]

Github user sebgoa commented on the issue:

https://github.com/apache/cloudstack/pull/1815
  
LGTM

but really the database should be outside the mgt server container and we 
should not be using supervisord.


---
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: Migrating CloudStack content from download.cloud.com

[sebgoa]

> On Mar 30, 2016, at 7:36 AM, Raja Pullela  wrote:
> 
> Just to summarize... and to close this thread for now,  
> 
> 1) short term - we will move the content to cloudstack.apt-get.eu
> 2) long term - can someone from PMC or Cloudstack Apache Infra help find out 
> the details on how to all the cloustack (downloads - software, sys templates 
> etc) content hosted on 'download.cloudstack.org'  or something similar.
> 

Can you start a separate thread on this last item, I don’t understand what you 
mean by it

> Best,
> Raja
> Senior Manager, Product Development
> Accelerite,  
> 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> Phone: 1-408-216-7010,  www.accelerite.com, @accelerite 
> 
> -Original Message-
> From: Paul Angus [mailto:paul.an...@shapeblue.com] 
> Sent: Monday, March 28, 2016 1:38 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Migrating CloudStack content from download.cloud.com
> 
> If someone can figure out a community/ASF acceptable way of the ACS community 
> owning a suitable vendor-neutral domain name, within the community we have 
> enough resources to physically host it (including the space donated by BT via 
> ShapeBlue).
> 
> 
> 
> Regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Saturday, March 26, 2016 4:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Migrating CloudStack content from download.cloud.com
> 
> One of the issues as far as I know is that as Apache CloudStack we have to be 
> strict with what we distribute. Meaning, we won't be able to push noredist 
> stuff, which is a pity.
> 
> Erik
> 
> Den lørdag 26. mars 2016 skrev Ian Rae  følgende:
> 
>> Does Apache provide such hosting services? It seems that the Apache 
>> infrastructure is very restrictive, perhaps we should ask whether they 
>> can provide reliable hosting for templates and other downloads.
>> 
>> If Apache is ruled out as an option I recommend we have the community 
>> contribute the hosting (happy to volunteer) but the URL should be a 
>> community URL and not specific to a commercial vendor. It should 
>> probably be mirrored geographically as well.
>> 
>> Ian
>> 
>> On Saturday, 26 March 2016, Ian Duffy >
>> wrote:
>> 
>>> I could be completely wrong here, but wasn't there some specific 
>>> closed source citrix magic added to the templates at 
>>> downloads.cloud.com that
>> was
>>> Cloud Platform specific?
>>> 
>>> Ideally, this stuff should be hosted on an Apache Cloudstack 
>>> infrastructure or atleast the main community source ( 
>>> cloudstack.apt-get.eu, shapeblue repo, etc.).
>>> 
>>> On 25 March 2016 at 15:00, Sebastien Goasguen > 
>>> > wrote:
>>> 
 
> On Mar 25, 2016, at 10:24 AM, Raja Pullela <
>>> raja.pull...@accelerite.com  >
 wrote:
> 
> @Sebastien,  thanks for the feedback.  please note that the goal 
> of
>>> this
 exercise was not to impact any users during this migration and 
 hence
>> the
 efforts to place the content at a location where we could move it to.
 Since Wido is ok with hosting the content on 
 'cloudstack.apt-get.eu',
>> it
 is even better.  I will work with Wido on the next steps.
> 
 
 Ok cool.
 
 We had other threads about avoiding company specific URL in docs. 
 So
>>> let’s
 definitely avoid that.
 
 
> @Ilya,  'cloud.com' is not getting transferred.
> 
> Best,
> Raja
> Senior Manager, Product Development Accelerite, 
> www.accelerite.com
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com 
>> ]
> Sent: Friday, March 25, 2016 1:57 PM
> To: dev@cloudstack.apache.org  
> Subject: Re: Migrating CloudStack content from 
> download.cloud.com
> 
 
 Citrix has been hosting   "download.cloud.com"  for  quite  some
 time  now
 and  it holds  the  System Templates for all the releases and
>> some
 tools.
 Going forward,  this  content  needs  to  be  moved  from
 "download.cloud.com".So, we will be moving  this content  to
 "cloudstack.accelerite.com".I  will also be  updating  the
 links in the
 documentation  to reflect
> 
> Raja, I am going to give this a strong -1
> 
> We talked about these sorts of things before and it is not
>> appropriate.
> 
> 
> 
 these  changes and will provide an update  once the  content 
 move is complete.
 
 @Wido, if you could also copy this content to 
 "cloudstack.apt-get.eu"  that will be great.  I can provide 
 

Re: External fork of Cloudstack

[sebgoa]

> 
> What would you be able to do if the git-dual experiment were expanded to 
> CloudStack that you couldn't do with the proposal above?  I suggest that you 
> take full advantage of the fact that people are now listening.
> 

Thanks for chiming in Sam,

Could you give us a summary of the Whimsy experiment ? (keeping in mind that 
most folks on dev@ are not members, did not listen on board@ ML or did not dig 
through ML archives).

-What are you doing ?
-For what reasons ?
-Why is it a challenge for ASF ?


> 
> How can I help?  I'd like to bring this proposal back to the board for wider 
> review so that nothing important is missed.  If there are issues that come 
> up, I will help flatten them.
> 

Thanks for being open and offering to help.
Indeed let’s figure this out.

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

[sebgoa]

> On Mar 17, 2016, at 6:15 PM, Daan Hoogland  wrote:
> 
> On Thu, Mar 17, 2016 at 5:51 PM, Chris Mattmann  wrote:
> 
>> As to forks being against Apache
>> policy, forks are not, however forks that use the Apache e.g.,
>> namespace, that have the Apache logo, that use the Apache name for
>> the project *are* against Apache policy. If it’s a fork, it needs
>> a new name, it
>> ​...
>> 
> 
> ​I am afraid the name cloudstack is open for use by anyone! Apache
> CloudStack is not and that we can act upon.​ I am not sure about the
> cloudstack specific apache logo but of course it can not use the feather.
> 
> 

No Daan, “cloudstack” is a trademark of the ASF.

> -- 
> Daan

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

[sebgoa]

> On Mar 19, 2016, at 3:59 PM, Sam Ruby  wrote:
> 
> The initial action (creating the fork) was not clearly done by the PMC
> as a whole, that is now being rectified by a retroactive vote being
> taken.  Even that I wouldn't suggest be done any differently: many
> parts of the ASF prefer a Commit then Review (CTR).  Under normal
> circumstances, a vote would not be necessary.
> 

To be transparent and avoid any hint at back door conversations (which are 
sadly too often alluded too). Let me highlight a few historical steps:

- We switched to GitHub PR almost a year ago and stopped using RB.
- Through fall Remi and co worked on a new commit workflow to speed releases, 
their productivity was “damaged” by lack of github access, namely: -no labels, 
no ability to close PR, no access to issues, no access to triggers/hooks.
- Remi reached out to VP infra (David) couple times I believe and a discussion 
in Dublin (~Oct).
-Through our PMC project report (written by me as VP and LGTM’d by the PMC), I 
made several mention of our intent to use Github (and docker Hub) more 
efficiently. I even said that if we where getting early access to the “Whimsy 
experiment” we would quickly VOTE in our community to decide on such a move.
- I never got any replies or comments (even though I mentioned that lack of 
github access was putting our community at risk of fragmentation).
- Wido reached out to Github back in december when he saw there was already a 
cloudstack org ( not sure who created it and controlled it actually.)
- Schuberg forked and created cosmic in feb sometime.
- Finally last week, I took unilateral decision to click ‘fork’ on 
apache/cloudstack and put a copy in cloudstack/cloudstack , thinking this would 
kick the tires and would give us a playground to start experimenting with CI 
taking advantage of full control of github settings.

As a member of ASF I had witnessed several threads around the use of GitHub and 
there are clearly strong feelings on the issue. I tried to participate in those 
threads and even demoed with another member that we could clearly guarantee 
provenance by signing all commits with ASF issued GPG keys, but that was not 
even acknowledged. 

Moving to Github (in some fashion) is indeed problematic to the ASF and a fully 
independent open source project. We end up depending on a vendor for hosting 
our repo and this puts us at risk if Github were to go bonkers. We can argue 
about such a risk, and we can also raise examples of other vendor/proprietary 
software being used/depended on by ASF projects (JIRA, Slack…). It also “moves” 
the community. While we are on the dev@ and other ML, the issue that we may 
move the community to Github and give the impression that project is not at ASF 
project is real. But to be honest there is already such confusion in OSS with 
projects on ASF v2 license being perceived by most as ASF projects.

Personally I have always thought that this is a very serious issue and trend in 
open source projects and that ASF (and the board in particular) should try to 
proactively address. What is the future of ASF in a GitHub world ? Can an ASF 
project live outside of ASF infra, especially in a Cloud world ? Sadly I never 
saw any clear proactivity from the board.

Hence yes, as my last action as VP I clicked on “fork”, and now I hope we will 
move forward, and get the board to proactively do something.

-Sebastien

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

[sebgoa]

+1

Note:
———

To be honest I never contemplated this move. Somehow it never occurred to me as 
a possibility.
But if the board and infra would let use move the mirror of the apache 
canonical repo to apache-cloudstack/cloudstack
then I think we would be all set.

> On Mar 19, 2016, at 5:14 PM, Patrick Dube  wrote:
> 
> +1
> 
> On Sat, Mar 19, 2016 at 9:37 AM, Daan Hoogland 
> wrote:
> 
>> +1 (binding as I saw others mention that. I doubt this is of any concern in
>> such a technical decision)
>> 
>> On Sat, Mar 19, 2016 at 12:40 PM, Will Stevens 
>> wrote:
>> 
>>> Thank you for this information, this is very helpful.
>>> On Mar 19, 2016 5:29 AM, "Rene Moser"  wrote:
>>> 
 On 03/18/2016 11:44 PM, Will Stevens wrote:
 
> *Proposal:*
> Transfer ownership of the 'apache/cloudstack' mirrored repository out
>>> of
> the 'apache' github organization into the 'apache-cloudstack' github
> organization (which I have already setup and started inviting users
>>> to).
> Both members of the ACS community and the ASF board will have 'owner'
> permissions on this new organization.  This will allow for
>> permissions
>>> to
> be applied specifically to the 'apache-cloudstack' organization and
>> not
> have to be applied to the entire 'apache' organization.
> 
> By transferring ownership, all of the PRs will be copied to the new
> repository and redirects will be created on github from
 'apache/cloudstack'
> to 'apache-cloudstack/cloudstack'.
 
 We might also have to involve github support here.
 
 The apache top level projects github projects have a special setting
 made by github internals that these projects are mirrored from
 git://git.apache.org/cloudstack.git.
 
 I am not sure how this will behave after the technical organization
>> move.
 
 Maybe they can disable this and before the organization move, they can
 create a  new mirrored repo in apache/cloudstack. That would also be
 great for consistency.
 
 
 
 
>>> 
>> 
>> 
>> 
>> --
>> Daan
>> 

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

[sebgoa]

> On Mar 17, 2016, at 5:16 PM, Mattmann, Chris A (3980) 
>  wrote:
> 
> Hi Mike,
> 
> Thank you. What you describe effectively below is going to
> implicitly switch the “canonical” repo in my opinion of the
> 
> repository to cloudstack/cloudstack. Merges that happen there,
> conversation that happens there on PRs and issues, labels, etc.,
> will be captured there and likely at increased pace and velocity,
> leaving the folks wanting to participate in the Apache Cloudstack
> project who aren’t part of cloudstack/cloudstack at a disadvantage.

That statement is very strange to me.

Membership in a github organization just sets privileges. Anyone can 
participate.
Just like we currently have people with karma on wiki and jira or committers 
and non committers.

What is disadvantageous is not being able to use the tools we want to use.

> 
> Thanks for speaking up and looking forward to more discussion.
> 
> Cheers,
> Chris
> 
> 
> -Original Message-
> From: "Tutkowski, Mike" 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Thursday, March 17, 2016 at 9:03 AM
> To: "dev@cloudstack.apache.org" 
> Subject: Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull
> request: Is the project attempting a fork on Githu...)
> 
>> As far as I understand, cloudstack/cloudstack is only being proposed to
>> help with developer workflow and CI.
>> 
>> To my understanding, all code that goes in there will end up back in the
>> canonical ASF CloudStack repo (and, as such, be mirrored to
>> apache/cloudstack).
>> 
>> This is simply a workaround to help solve developer workflow and CI
>> issues that we couldn't due to lack of privileges on the current repo.
>> 
>> I do not believe anyone on the PMC is talking about forking CloudStack
>> and going off in a different direction.
>> 
>> From: Chris Mattmann 
>> Sent: Thursday, March 17, 2016 9:52 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: External fork of Cloudstack (was Re: [GitHub] cloudstack
>> pull request: Is the project attempting a fork on Githu...)
>> 
>> Hi Sebastien,
>> 
>> 
>> [..]
 
 Hi Sebastien,
 
 Thanks for your reply and yes, I am a member of the ASF board.
 
 The thing is, there was already some discussion of this at the
 ASF board meeting that happened yesterday. I can tell you that
 there were more than a few board members that were a bit concerned
 at the prospect of Apache Cloudstack forking and starting a new
 GitHub organization, so I’m here now to discuss.
>>> 
>>> We are not forking. In the sense that the canonical repo is at the ASF
>>> and mirrored on apache/cloudstack.
>> 
>> OK, good though based on the rest of your replies, I actually see
>> the opposite being said. Also “we” is the relative word here, which
>> I’ll get back to later in this message.
>> 
>>> 
>>> The cloudstack org on github existed and was empty, one of us contacted
>>> github and we got the “control” of it.
>>> 
 
 I’m sorry that you are unhappy with the lack of access to GitHub
 facilities, however I’m confused, the ASF does provide mirroring,
 active GitHub issue,
>>> 
>>> As far as I know we cannot use github issues.
>>> [..snip..]
>>> To close PRs you need to make a commit.
>> [..snip..]
>>> Be able to use labels
>>> Be able to setup our own triggers/hooks
>> 
>> David Nalley can speak to this as I’m not sure if you can or
>> cannot or if infra@ is providing this. Thanks for stating this.
>> 
>>> 
>>> 
 PMC desires and if so can you state that? I remember seeing a request
 that you wanted the ability to close pull requests and to be part of
 the experiment going on with the Whimsy PMC -
>>> 
>>> Indeed, and I (we) never heard back.
>> 
>> Right - that’s probably b/c it wasn’t discussed with the board
>> until our last meeting which just happened yesterday. It’s
>> my reading of the tea leaves that the experiment, while considered
>> going in the right direction with Whimsy, is not open to other
>> PMCs. It’s possible that we may as a board decide that further
>> response is needed, but until that happens or if that doesn’t happen
>> you can take my response until then.
>> 
>>> [..snip..]
>> 
>>> 
 The other thing is - is the new Cloudstack GitHub organization the
 result of a subset of the PMC going off and doing this -
>>> 
>>> I am not sure why you say subset. Let’s try to avoid polemics.
>> 
>> I’m not trying to attack.
>> 
>> I asked a simple question - how many/who in the Apache CloudStack PMC
>> is intent on using this new Cloudstack GitHub organization? Not an
>> attack, a question that I still don’t have an answer to.
>> 
>> I also wanted to gauge whether there are others on the PMC that will
>> speak up. I’ll continue waiting to hear more about that.
>> 
>>> [..snip..]
>>> Again, this is not 

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

[sebgoa]

> On Mar 17, 2016, at 3:07 PM, Chris Mattmann  wrote:
> 
> Hi Sebastien,
> 
> Thanks for your reply and yes, I am a member of the ASF board.
> 
> The thing is, there was already some discussion of this at the
> ASF board meeting that happened yesterday. I can tell you that
> there were more than a few board members that were a bit concerned
> at the prospect of Apache Cloudstack forking and starting a new
> GitHub organization, so I’m here now to discuss.

We are not forking. In the sense that the canonical repo is at the ASF and 
mirrored on apache/cloudstack.

The cloudstack org on github existed and was empty, one of us contacted github 
and we got the “control” of it.

> 
> I’m sorry that you are unhappy with the lack of access to GitHub
> facilities, however I’m confused, the ASF does provide mirroring,
> active GitHub issue,

As far as I know we cannot use github issues.

> comment, etc, sync, the ability to close PRs,

To close PRs you need to make a commit.

> etc. Is there something specific not in that list that the CloudStack

Be able to use labels
Be able to setup our own triggers/hooks 

> PMC desires and if so can you state that? I remember seeing a request
> that you wanted the ability to close pull requests and to be part of
> the experiment going on with the Whimsy PMC -

Indeed, and I (we) never heard back.

> is that what you are
> talking about?
> 

In part yes.

Github has become a tool that a large number of committers are now using on a 
day to day.

I (and I will let others say what they think), loose time not being able to use 
Github for CloudStack.
And as a volunteer I have little free time to do this, so I would like to use 
tools that increase my productivity.

> The other thing is - is the new Cloudstack GitHub organization the
> result of a subset of the PMC going off and doing this -

I am not sure why you say subset. Let’s try to avoid polemics.

> or was this
> actually discussed by the PMC somewhere - apologies if I missed the
> thread. I am now subscribed to dev@cloudstack.a.o and I can also go
> back and search the archives.
> 
> The ASF builds communities. There is an Apache Cloudstack
> community that has been approved by the board and that has been growing
> here at the ASF. Also the ASF cares about names and trademarks and
> branding, etc. If some set of the PMC don’t want to work on Apache
> Cloudstack and then go off and start a fork etc., then the ASF Cloudstack
> PMC and project still exist and go on, so that is something to think
> about and also something for the board and trademarks@, etc., to think
> about since the name will be in conflict and that can’t happen, etc.
> 

Again, this is not about leaving the ASF. This is about accessing productive 
tools and making use of them to their fullest.

> Finally, as for the Apache Cloudstack PMC - for the PMC the policy of
> the ASF is that the canonical repository at the moment is on ASF hardware.

And we would like the ASF to reconsider this.

> There are not any approved policies for external forks being the canonical
> repo, especially those in another GitHub organization not managed by the
> ASF. There is an experiment in the Apache Whimsy PMC to experiment with
> GitHub as the canonical repo for an apache/* org project. That is still an
> experiment and not widely offered by ASF infra to all PMCs.
> 

Are other projects than Whimsy being allowed to experiment ?

This is exactly what we would like to do at this stage.

> Given the above I’d like discussion from the Cloudstack PMC and more than
> just one or two of you. Let’s figure this out.
> 

And just to clarify, you are acting here as “the board” ? Meaning the board 
asked you to get on dev@ and talk with our community after seeing our report ?
I am asking because the PMC has not received an official response from the 
board based on our report (and annexed interim report).

> Thanks,
> Chris
> 
> 
> 
> 
> -Original Message-
> From: Sebastien Goasguen 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Thursday, March 17, 2016 at 3:15 AM
> To: "dev@cloudstack.apache.org" 
> Subject: Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull
> request: Is the project attempting a fork on Githu...)
> 
>> Hi Chris, 
>> 
>> We have never met but i recognize your name from members only ASF threads.
>> 
>> For the benefit of others on this list it is useful to mention that you
>> are a member of the ASF board.
>> 
>> The PMC has filed its quarterly report  for march, as well as an interim
>> report about a month ago. The interim report was acknowledged by Sam Ruby
>> couple days ago only.
>> 
>> I am assuming that the board will discuss it at its monthly meeting and
>> that we will hear from the board then.
>> 
>> Other than that the discussions are active on dev@ , but roughly we feel
>> that we are being hurt by lack of access to github facilities.
>> 

Re: External fork of Cloudstack

[sebgoa]

> On Mar 18, 2016, at 6:30 PM, Sam Ruby  wrote:
> 
> 
> I'm more concerned that the page is indistinguishable from a fork, and
> gives no indication of official status.  That may be OK for a work in
> progress, but isn't ideal as a final solution.  I'll share that I've
> heard (second and third hand) reports of people who only have heard of
> there being an "external fork", and have drawn incorrect conclusions
> from that.  I think we need to be careful about how this is explained,
> as perceptions matter.

I have updated the organization description and added our website and dev@ 
address.

> 
> By contrast, if you go to:
> 
> https://github.com/apache/whimsy
> 
> What you will see in place of "Mirror of xxx" is "Apache Whimsy".  I
> grant you that it is a small thing, 

We can easily change “Mirror of Apache CloudStack” to “Apache CloudStack”.

But I think lots of people will get upset as it will really mean that this is a 
move away from ASF infra.
Or maybe I missing your point.

Re: ACS CI BVT RUN: xenserver: Pr_number: 1417

[sebgoa]

Bharat, that’s great, thanks for this

But…

Since this is the first results like this sent to the list, can you explain 
what we are looking at.
What hardware this is running on, what configuration of cloudstack…

And I very much would like for these results to be sent as comments to the PR 
discussion,
if it cannot be done we need to push ASF infra to make it happen



> On Feb 25, 2016, at 6:27 AM, Bharat Kumar  wrote:
> 
> 
> On 24-Feb-2016, at 10:24 PM, 
> jenkins-...@citrix.com wrote:
> 
> [http://jenkins-ccp.citrix.com/static/e59dfe28/images/32x32/red.gif]BUILD 
> FAILURE
> Build Start Date:   Wed Feb 24 06:29:34 2016
> Git Repo Url:   https://github.com/apache/cloudstack.git
> Git Commit Id:  9d89229942436d98f4897d8030f95bb8702bf
> Git Branch Info:1417
> Hyper Visor Info:   xenserver
> Build No:   11
> Health Report
> W   Description Score
> [http://jenkins-ccp.citrix.com//static/d7293164/images/16x16/health-00to19.png]
>  Build stability: All recent builds failed.  0
> [http://jenkins-ccp.citrix.com//static/d7293164/images/16x16/health-80plus.png]
>  Test Result: 22 tests failing out of a total of 142 tests.  84
> 
> 
> Changes
> No Changes
> 
> 
> Test Result
> Package Failed  Passed  Skipped Total
> < tt=""><>  2   0   0   2
> :teardown
> :setup
> integration.smoke.test_affinity_groups  0   1   0   1
> integration.smoke.test_affinity_groups_projects 0   1   0   1
> integration.smoke.test_deploy_vgpu_enabled_vm   0   0   1   1
> integration.smoke.test_deploy_vm_iso0   1   0   1
> integration.smoke.test_deploy_vm_root_resize0   3   0   3
> integration.smoke.test_deploy_vm_with_userdata  0   2   0   2
> integration.smoke.test_deploy_vms_with_varied_deploymentplanners0 
>   3   0   3
> integration.smoke.test_disk_offerings   0   5   0   5
> integration.smoke.test_global_settings  0   1   0   1
> integration.smoke.test_guest_vlan_range 1   0   0   1
> integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange.test_dedicateGuestVlanRange
> integration.smoke.test_internal_lb  0   4   0   4
> integration.smoke.test_iso  2   4   1   7
> integration.smoke.test_iso.TestISO.test_04_extract_Iso
> integration.smoke.test_iso.TestISO.test_07_list_default_iso
> integration.smoke.test_loadbalance  0   3   0   3
> integration.smoke.test_multipleips_per_nic  0   1   0   1
> integration.smoke.test_network  0   10  0   10
> integration.smoke.test_network_acl  0   1   0   1
> integration.smoke.test_nic  0   1   0   1
> integration.smoke.test_nic_adapter_type 0   0   1   1
> integration.smoke.test_non_contigiousvlan   0   1   0   1
> integration.smoke.test_over_provisioning0   1   0   1
> integration.smoke.test_password_server  1   0   0   1
> integration.smoke.test_password_server.TestIsolatedNetworksPasswdServer.test_isolate_network_password_server
> integration.smoke.test_portable_publicip0   2   0   2
> integration.smoke.test_primary_storage  1   1   0   2
> integration.smoke.test_primary_storage.TestPrimaryStorageServices.test_01_primary_storage_iscsi
> integration.smoke.test_privategw_acl3   1   0   4
> integration.smoke.test_privategw_acl.TestPrivateGwACL.test_02_vpc_privategw_static_routes
> integration.smoke.test_privategw_acl.TestPrivateGwACL.test_03_vpc_privategw_restart_vpc_cleanup
> integration.smoke.test_privategw_acl.TestPrivateGwACL.test_04_rvpc_privategw_static_routes
> integration.smoke.test_public_ip_range  0   1   0   1
> integration.smoke.test_pvlan0   1   0   1
> integration.smoke.test_regions  0   1   0   1
> integration.smoke.test_reset_vm_on_reboot   0   1   0   1
> integration.smoke.test_resource_detail  0   1   0   1
> integration.smoke.test_router_dhcphosts 1   0   0   1
> integration.smoke.test_router_dhcphosts.TestRouterDHCPHosts.test_router_dhcphosts
> integration.smoke.test_routers  0   9   0   9
> integration.smoke.test_routers_iptables_default_policy  0   2   0 
>   2
> integration.smoke.test_routers_network_ops  3   2   0   5
> integration.smoke.test_routers_network_ops.TestIsolatedNetworks.test_01_isolate_network_FW_PF_default_routes_egress_true
> integration.smoke.test_routers_network_ops.TestRedundantIsolateNetworks.test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true
> 

Re: [Proposal] Concerning open PRs

[sebgoa]

> On Feb 18, 2016, at 8:38 AM, Wilder Rodrigues  
> wrote:
> 
> Hi all,
> 
> 
> It’s been a long time, but the Wolverine is not dead yet. ;)
> 
> Currently we have 175 opened PRs, which we all agree to be a lot, given the 
> fact that few people, if any, are testing/merging them. I have been a bit off 
> the radar, but from next week I will start helping to get some of those PRs 
> tested and, hopefully, merged.
> 
> In order to get the community working as an unit, I would like to propose the 
> following:
> 
> * One should only create a PR after testing an existing PR.
>  - By testing I mean… testing. Not just looking into it and saying “LGTM”. 
> Manual tests should also count, with screenshots attached to the PR.
> 
> That will make those with test environment pitch in and help, and in addition 
> might also decrease the frenzy for creating PRs which occasionally won’t be 
> tested within a month time - or longer.
> 
> For others not creating PRs that often, like me, we should help testing at 
> least 1 PR per week.
> 
> Being a bit more blunt now, if a PR is created but the person does not 
> contribute with testing an existing one, the new PR should be closed.
> 
> What do you think?
> 

That sounds too extreme to my taste.

Bottom line, folks who submit PR need to stay on top of them and address 
comments.

But then we need to have that CI in place

-sebastien

> Cheers,
> Wilder

Re: disable github notifications ?

[sebgoa]

I don't know exactly what to do,

but I believe Rene left the list because it was too noisy, …that's not good.

On Jan 27, 2016, at 4:10 PM, Giles Sirett <giles.sir...@shapeblue.com> wrote:

> Is there any other way of doing it ? (i.e can we get a summary of the 
> comments sent to the list)
> 
> I filter out the GH notifications (because I too find them noisy) but then 
> often miss discussions that happen as GH comments
> 
> In theory, we have the rule "if it happens, it happens on dev@", I feel may 
> of the conversations on GH really should be somehow shown on dev@
> 
> 
> Kind Regards
> Giles
> 
> 
> 
>   
> Giles Sirett
> CEO,   ShapeBlue
> d:+44  20 3603 0541 | s: +44 203 603 0540   |  m: +44 7961112055
> e:giles.sir...@shapeblue.com | t:   |  w: 
> www.shapeblue.com
> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
> 
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue 
> Services India LLP is a company incorporated in India and is operated under 
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
> incorporated in Brasil and is operated under license from Shape Blue Ltd. 
> ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa 
> and is traded under license from Shape Blue Ltd. ShapeBlue is a registered 
> trademark.
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error.
> 
> 
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com] 
> Sent: 28 January 2016 00:00
> To: dev@cloudstack.apache.org
> Subject: disable github notifications ?
> 
> Hi folks,
> 
> Shall we disable github notifications to dev@ ?
> 
> It has become quite noisy.
> 
> On the other end you see all the comments fly by...
> 
> -sebastien
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build | CSForge – rapid IaaS deployment framework
> CloudStack Consulting | CloudStack Software Engineering
> CloudStack Infrastructure Support | CloudStack Bootcamp Training Courses

disable github notifications ?

[sebgoa]

Hi folks,

Shall we disable github notifications to dev@ ?

It has become quite noisy.

On the other end you see all the comments fly by...

-sebastien

Re: [DISCUSS] Move to Github

[sebgoa]

On Jan 11, 2016, at 10:51 AM, Rene Moser  wrote:

> Hi Sebastien
> 
> On 01/11/2016 09:53 AM, Sebastien Goasguen wrote:
>> Part 3:
>> 
>> 
>> To me the main issue for us is that our current privileges on GitHub prevent 
>> us from building more productive CI workflow and makes the life of the RM 
>> more difficult (cannot use labels, cannot use issues, cannot configured 
>> triggers/hooks etc). ...
> 
> Out of curiosity, it seems the main problem is that we are using the
> apache account of github.

indeed

> 
> Why don't we create an own one?
> 
> e.g. github.com/cloudstackdev
> 

we do have github.com/cloudstack already

> --> PR merge on  github.com/cloudstackdev
> --> hook to jenkins job pushing it to git http://git.apache.org
> --> will be mirrored to https://github.com/apache/cloudstack
> 
> Did I miss anything why this would not be possible?
> 

this is exactly what "moving to github" would mean.

if we agree to do this, we then need to work with infra and the board to make 
sure everything is ok in terms of provenance and that it does not "break" our 
ASF "commitment"

> The only thing would be that we can not push to http://git.apache.org
> directly anymore.
> 
> Regards
> René

Re: Minor releases!

[sebgoa]

On Jan 7, 2016, at 5:27 PM, Remi Bergsma  wrote:

> 
> On 07/01/16 17:22, "Rene Moser"  wrote:
>> No, it is not the pace. You can do as many major as often as you want
>> but if one uses this major, how long will it get minors? We have no clue.
>> 
>> I understand your point completely while my argument is that I have to
>> plan releases year by year.
>> 
>> Under this condition I'd take the LTS of the releases, the most stable
>> one even its 2 years old, (I have to maintain it for a year), not the
>> latest one, for sure not a .0 release.
>> 
>> With that mindset, there is no version for me right now.
> 
> I see your point. To me this is not a sustainable model, but if you want to 
> keep doing this the only option I see is finding a RM for your specific 
> release.
> 
> And as a matter of fact, 4.7.0 == 4.6.2 so that .0 might be the best .0 
> release we ever had. Don’t underestimate the change that was made. Releases 
> now build on top of each other, while that was never the case. 
> 
> Anyway, I cannot and don’t want to convince you. We want something different 
> and that is fine. What I do want to know is what others want. Because if the 
> majority wants what you are asking for, we should do that. 
> 

Remi, I think Rene might have a point, that while things are clear for you, the 
fact that 4.7.0 == 4.6.2 may be lost on other folks that are used to the old 
ways.

Maybe we need a picture or something...

> Regards,
> Remi

Re: Minor releases!

[sebgoa]

see inline
On Jan 7, 2016, at 3:39 PM, Nux!  wrote:

> Hi,
> 
> 
>> So, yes, monthly releases can be done and the quality is better than before.
>> Actually, I think we should go much faster. Whenever a PR is merged that 
>> fixes
>> your issue, it should be possible to deploy it right away. It’s a change in
>> mindset.
> 
>> 
>> 
>> Let me know!
> 
> Ok, so first of all I am letting you know that I appreciate your efforts very 
> much and can't thank you enough for your being RM. 
> Also a lot of thanks to other SBP staff, PCExtreme, Leaseweb & Shapeblue and 
> others for all their work; sometimes I just feel like a scavenger, 
> "profiting" from their work. :)
> Keep up the good job!
> 

+1000

CloudStack is in its best shape ever indeed due to the hard work from Remi, 
Wilder, Daan, Rajani, Wido and a few others that I am missing.

It is also in its best shape ever because we moved from developing on master 
and GA'ing a release branch over several months.

We know have a stable master that also has the latest features and fixes.

> Secondly, my own problem with the current velocity is that it does generate 
> fatigue.
> Everything must be tested all the time, eyes must be on git and on the 
> mailing list. 
> 

The way I see it we completed the first phase of a big change for us. We 
changed our release process.

This has led us to this amazing place:

Today we can release production ready CloudStack *at any time* in 72 hours (the 
time to close a vote), it's terrific.

The other side of the coin is that we can release so often we need to change 
our mindset and doing so be mindful of folks that are used to the old release 
pattern.

Clearly we cannot keep maintaining all release branches, we used to say that we 
would maintain the last two major and the last minor.

Yet folks (like Rene) may like a pattern of just minor and very infrequent 
major. While folks like Remi want continuous deployment.

So at the cost of sounding a bit "fatherly" we indeed need to discuss this a 
bit. I mentioned it after 4.6, and communicate clearly to everyone how this 
works.

Keeping in mind that we don't want to abandon anyone and we want everybody to 
be able to upgrade easily.



> And this is how it should be, really, but it can become a problem or at least 
> disappointing when people fail to engage as much as we'd want.
> We need to be aware the community is indeed small, the users might be many 
> but few get involved in development (people still don't get "open source") 
> and not many of us have the luxury of 
> working with Cloudstack every day and have it be the main subject.
> There are days when I don't even get to think about it, let alone do anything 
> about it, I work some very busy shifts dealing with random things.
> 
> I think people in my situation - or worse - might feel uncomfortable with a 
> fast pace, they might feel left behind and sometimes it's just not easy to 
> keep up. 
> I know how heavy it feels to run a mission critical cloud and have no idea 
> whether you'll be able to pull the next upgrade off.
> The idea of longer term support through many minor versions can sound very 
> appealing and make people feel cosy. RedHat is exploiting exactly this with 
> their RHEL, for example.
> 
> Having said that, I would not go back to the old ways. I think we're on a 
> good track here and we just need to test more, especially automate said 
> testing more, in environments as close to production as we can. This my 2016 
> resolution. :-)

+1000 here.

We are on a great track. Let's keep refining our process, complete the second 
phase which is proper CI ,  agree on how to move forward and communicate on 
which releases are maintained and for how long.

> 
> My 2 pence
> 
> Lucian

Re: BVT Report for the week of 1/5

[sebgoa]

On Jan 5, 2016, at 11:13 AM, Raja Pullela  wrote:

> Happy New Year to all!
> 
> Please see the BVT report
> KVM Basic  - 97.1%
> XS Basic - 94.0%
> KVM Adv - 85.8% - action item on me to add configurations for the new tests 
> to run
> XS Adv - 79.1% - action item on me to add configurations for the new tests to 
> run
> 
> Failed Tests - same tests from last BVT report.  Hope to fix the 
> configurations for the new Tests  around next week or so.
> 
> Also, looking to export the test data including logs to a website which is 
> accessible to everyone.  Hope to accomplish it this month?

google doc spreadsheet ?

> 
> Please let me know if you have any questions,
> Raja
> 

4.7 release notes

[sebgoa]

There are no release notes for 4.7 …?

I merged the new docs and website, but the link for RN break.

[DISCUSS] Move to Github

[sebgoa]

Hi folks,

Apologies for a week end email couple days before christmas, but this needs to 
get out.

Late October I started thread [1] about moving our repo to GitHub, I would like 
to re-open this discussion.

Now that we have stabilized master and release 4.6.0, 4.6.1, 4.6.2 and 4.7.0 we 
need to think about the next steps.

To me Git and GitHub has become an essential tool to any software development, 
not using it to its full potential is hurting us.

Just as an example I would like to point you to [2], this a PR I made to 
Kubernetes (a container orchestrator), it literally added 14 characters in a 
json file.
This was really a very minor change.

The PR automatically triggered 3 bots which created 7 labels, it ran end to end 
testss, Jenkins jobs and triggered third part builds.
It was automatically merged.

This is just an example of things that we could build with proper access to 
Github.

Currently we don't have that access and we don't have the privileges to do what 
we should be doing in terms of CI.

There are on-going discussion at the board level of the ASF to see if a project 
purely hosted on GitHub could be an ASF project.
The biggest issue there is independence to vendor tools (yes github is a 
vendor) and provenance of the commits.
The ASF committership and release process guarantees that the source of commits 
and hence the history of the code is well known at all times.

Bottom line:

I would like us to use Github and hence I would like us to request to the ASF 
infra and board that CloudStack be allowed to move to GitHub.
For this to happen of course, we need a consensus decision.

Thanks and merry christmas,


[1] http://markmail.org/thread/inwfcsbqlqmfddhh
[2] https://github.com/kubernetes/kubernetes/pull/18823

Re: 4.7.0 vote passed -> freeze is over

[sebgoa]

Releases branches should only be written to by RMs.



On Dec 18, 2015, at 11:22 AM, Daan Hoogland  wrote:

> Committers, please keep in mind our quality standards when executing your
> liberty to merge.
> 
> -- 
> Daan

Re: 4.7.0 vote passed -> freeze is over

[sebgoa]

On Dec 18, 2015, at 11:44 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:

> Sebastien,
> 
> On Fri, Dec 18, 2015 at 11:36 AM, sebgoa <run...@gmail.com> wrote:
> 
>> Releases branches should only be written to by RMs.
>> 
> ​Knowing how you feel about the process you mean 'master' as much as older
> branches, right?
> 
> I would not want to be responsible for the growing number of PRs as RM.
> (the main reason I will quit this job). At the release of 4.7 the number of
> open PRs grew instead of shrunk. That could be a good sign if it coincided
> with the growth of our development community but it doesn't.
> ​ ​
> Our present way of working can not be maintained without people
> volunteering 1 fte.​
> 

Mostly agree.

Just wish we could let Christmas pass by without breaking all the good work you 
guys did.
Then "sit down" and work on our next steps:

- automated CI
- use of github


> 
> On Dec 18, 2015, at 11:22 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>> 
>>> Committers, please keep in mind our quality standards when executing your
>>> liberty to merge.
>>> 
>>> --
>>> Daan
>> 
>> 
> 
> 
> -- 
> Daan

Re: Feedback of my Phd work in Cloudstack Project

[sebgoa]

On Dec 10, 2015, at 12:31 AM, Igor Wiese  wrote:

> Hi, Cloudstack Community.
> 
> My name is Igor Wiese, phd Student from Brazil. In my research, I am
> investigating two important questions: What makes two files change
> together? Can we predict when they are going to co-change again?
> 
> I've tried to investigate this question on the Cloudstack project. I've
> collected data from issue reports, discussions and commits and using some
> machine learning techniques to build a prediction model.
> 
> I collected a total of 141 commits in which a pair of files changed
> together and could correctly predict 60% commits.


Hi Igor, why 141 commits ? Is that the only commits you found with only a pair 
for changes ?

My gut feeling is that you could check the entire history of the CloudStack 
repo (~5 years worth of data) and work on different type of tuples.

141 commits seems like a really small dataset.

-Sebastien

> These were the most
> useful information for predicting co-changes of files:
> 
> - sum of number of lines of code added, modified and removed,
> 
> - number of words used to describe and discuss the issues,
> 
> - number of comments in each issue,
> 
> - median value of closeness, a social network measure obtained from issue
> comments, and
> 
> - median value of constraint, a social network measure obtained from issue
> comments.
> 
> To illustrate, consider the following example from our analysis. For
> release 4.4, the files "cloud/hypervisor/XenServerGuru.java" and
> "cloud/hypervisor/guru/VMwareGuru.java " changed together in 3 commits. In
> another 2 commits, only the first file changed, but not the second.
> Collecting contextual information for each commit made to first file in the
> previous release (4.3), we were able to predict all 3 commits in which both
> files changed together in release 4.4, and we only issued 0 false
> positives. For this pair of files, the most important contextual
> information was the number of lines of code added, removed and modified in
> each commit,the number of comments in each issue, and social network
> measures (closeness, density, constraint, hierarchy) obtained from issue
> comments.
> 
> - Do these results surprise you? Can you think in any explanation for the
> results?
> 
> - Do you think that our rate of prediction is good enough to be used for
> building tool support for the software community?
> 
> - Do you have any suggestion on what can be done to improve the change
> recommendation?
> 
> You can visit our webpage to inspect the results in details:
> http://flosscoach.com/index.php/17-cochanges/67-cloudstack
> 
> All the best,
> Igor Wiese
> Phd Candidate

Re: Feature freeze ACS 4.7 next Monday

[sebgoa]

Hate to be a pain, but could you make sure to keep the exact list of Features 
merged, so that the Release notes are accurate ?

thanks

On Dec 4, 2015, at 11:58 PM, Remi Bergsma  wrote:

> Hi all,
> 
> Next Monday we'll feature freeze for our upcoming 4.7 release. We looked 
> through all open Pull Requests and below is our "whish list" to get in 4.7. 
> Feel free to nominate any other changes that should go in 4.7. No guarantees, 
> there is limited time so only PRs that we actively work on will make it.
> 
> The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will have a 
> nice Christmas present ;-)
> 
> Please help us review these PRs. Most have already had some review and when 
> we can reach 2xLGTM we can include them in 4.7 on time and make another great 
> release.
> 
> Happy testing and reviewing!
> 
> Regards,
> Daan & Remi
> 
> 
> Features & Fixes PRs:
> 
> Quota
> https://github.com/apache/cloudstack/pull/768
> 
> Logging enhancement
> https://github.com/apache/cloudstack/pull/1167
> 
> VMware diskcontrollers
> https://github.com/apache/cloudstack/pull/1132
> 
> ACS allows to create isolated networks with invalid gateway ip
> https://github.com/apache/cloudstack/pull/1125
> 
> Update nic IP address of stopped vm
> https://github.com/apache/cloudstack/pull/1086
> 
> Hypervisor changes to support UserData for Nuage VSP
> https://github.com/apache/cloudstack/pull/1142
> 
> Support shared networking in NiciraNVP Plugin
> https://github.com/apache/cloudstack/pull/1094
> 
> Strongswan vpn feature
> https://github.com/apache/cloudstack/pull/872
> 
> VM Snapshotting implementation for KVM
> https://github.com/apache/cloudstack/pull/977
> 
> Redundant VPC improvement
> (PR will follow over the weekend)
> 
> 
> UI PRs:
> 
> [UI] fix bug: Cannot delete SSH keypairs in projects
> https://github.com/apache/cloudstack/pull/1154
> 
> UI icon over VM snapshot to deploy user instance
> https://github.com/apache/cloudstack/pull/1150
> 
> Newly added project is not showing in the drop down until the browser is 
> refreshed
> https://github.com/apache/cloudstack/pull/1082

Re: Feature freeze ACS 4.7 next Monday

[sebgoa]

On Dec 7, 2015, at 9:56 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:

> Rohit, Sebastien,
> 
> I think we do not need to hurry any issues. work on 4.8 will start in
> January or february at the latest.


I don't want to hurry anything, I want to be able to have release notes that 
describe *all* the features added.

Check the 4.6 release notes, I am sure we did more than this, but since dev 
more often than not don't care much about the RN, the features are not 
publicized.



> 
> On Mon, Dec 7, 2015 at 8:55 AM, sebgoa <run...@gmail.com> wrote:
> 
>> Hate to be a pain, but could you make sure to keep the exact list of
>> Features merged, so that the Release notes are accurate ?
>> 
>> thanks
>> 
>> On Dec 4, 2015, at 11:58 PM, Remi Bergsma <rberg...@schubergphilis.com>
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Next Monday we'll feature freeze for our upcoming 4.7 release. We looked
>> through all open Pull Requests and below is our "whish list" to get in 4.7.
>> Feel free to nominate any other changes that should go in 4.7. No
>> guarantees, there is limited time so only PRs that we actively work on will
>> make it.
>>> 
>>> The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will
>> have a nice Christmas present ;-)
>>> 
>>> Please help us review these PRs. Most have already had some review and
>> when we can reach 2xLGTM we can include them in 4.7 on time and make
>> another great release.
>>> 
>>> Happy testing and reviewing!
>>> 
>>> Regards,
>>> Daan & Remi
>>> 
>>> 
>>> Features & Fixes PRs:
>>> 
>>> Quota
>>> https://github.com/apache/cloudstack/pull/768
>>> 
>>> Logging enhancement
>>> https://github.com/apache/cloudstack/pull/1167
>>> 
>>> VMware diskcontrollers
>>> https://github.com/apache/cloudstack/pull/1132
>>> 
>>> ACS allows to create isolated networks with invalid gateway ip
>>> https://github.com/apache/cloudstack/pull/1125
>>> 
>>> Update nic IP address of stopped vm
>>> https://github.com/apache/cloudstack/pull/1086
>>> 
>>> Hypervisor changes to support UserData for Nuage VSP
>>> https://github.com/apache/cloudstack/pull/1142
>>> 
>>> Support shared networking in NiciraNVP Plugin
>>> https://github.com/apache/cloudstack/pull/1094
>>> 
>>> Strongswan vpn feature
>>> https://github.com/apache/cloudstack/pull/872
>>> 
>>> VM Snapshotting implementation for KVM
>>> https://github.com/apache/cloudstack/pull/977
>>> 
>>> Redundant VPC improvement
>>> (PR will follow over the weekend)
>>> 
>>> 
>>> UI PRs:
>>> 
>>> [UI] fix bug: Cannot delete SSH keypairs in projects
>>> https://github.com/apache/cloudstack/pull/1154
>>> 
>>> UI icon over VM snapshot to deploy user instance
>>> https://github.com/apache/cloudstack/pull/1150
>>> 
>>> Newly added project is not showing in the drop down until the browser is
>> refreshed
>>> https://github.com/apache/cloudstack/pull/1082
>> 
>> 
> 
> 
> -- 
> Daan

Re: Feature freeze ACS 4.7 next Monday

[sebgoa]

The rn repo contains a script that polls JIRA for a release filter and 
generates the tables of issues fixed:

https://github.com/apache/cloudstack-docs-rn/blob/master/utils/jira.py

but we are not tracking the ones that really are *features*….

small detail that would be nice to sort out.

On Dec 7, 2015, at 12:01 PM, Remi Bergsma <rberg...@schubergphilis.com> wrote:

> Hi Seb,
> 
> Now that we merge everything and have a smaller scope, it should be easier to 
> get the list of pull requests that got in since 4.6.
> 
> Quick attempt:
> 
> git log --pretty=oneline --abbrev-commit upstream/4.6..master | grep Merge | 
> grep -v release | grep -v 4\.6 | awk {'print $5'} | sed s/\#//g | sort -n
> 
> 801
> 834
> 840
> 841
> 850
> 929
> 935
> 937
> 942
> 943
> 944
> 1007
> 1013
> 1018
> 1019
> 1021
> 1035
> 1038
> 1049
> 1051
> 1057
> 1065
> 1068
> 1069
> 1071
> 1083
> 1084
> 1086
> 1092
> 1100
> 1102
> 1107
> 1108
> 1110
> 1118
> 1122
> 1128
> 1129
> 1137
> 1139
> 1140
> 1143
> 1167
> 1172
> 1173
> 
> If we make a script that gets this output and queries Github, we can get a 
> list of the PR titles. Then we need to make sure those titles are any good ;-)
> 
> 
> Regards,
> Remi
> 
> 
> 
> 
> On 07/12/15 10:13, "sebgoa" <run...@gmail.com> wrote:
> 
>> 
>> On Dec 7, 2015, at 9:56 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>> 
>>> Rohit, Sebastien,
>>> 
>>> I think we do not need to hurry any issues. work on 4.8 will start in
>>> January or february at the latest.
>> 
>> 
>> I don't want to hurry anything, I want to be able to have release notes that 
>> describe *all* the features added.
>> 
>> Check the 4.6 release notes, I am sure we did more than this, but since dev 
>> more often than not don't care much about the RN, the features are not 
>> publicized.
>> 
>> 
>> 
>>> 
>>> On Mon, Dec 7, 2015 at 8:55 AM, sebgoa <run...@gmail.com> wrote:
>>> 
>>>> Hate to be a pain, but could you make sure to keep the exact list of
>>>> Features merged, so that the Release notes are accurate ?
>>>> 
>>>> thanks
>>>> 
>>>> On Dec 4, 2015, at 11:58 PM, Remi Bergsma <rberg...@schubergphilis.com>
>>>> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Next Monday we'll feature freeze for our upcoming 4.7 release. We looked
>>>> through all open Pull Requests and below is our "whish list" to get in 4.7.
>>>> Feel free to nominate any other changes that should go in 4.7. No
>>>> guarantees, there is limited time so only PRs that we actively work on will
>>>> make it.
>>>>> 
>>>>> The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will
>>>> have a nice Christmas present ;-)
>>>>> 
>>>>> Please help us review these PRs. Most have already had some review and
>>>> when we can reach 2xLGTM we can include them in 4.7 on time and make
>>>> another great release.
>>>>> 
>>>>> Happy testing and reviewing!
>>>>> 
>>>>> Regards,
>>>>> Daan & Remi
>>>>> 
>>>>> 
>>>>> Features & Fixes PRs:
>>>>> 
>>>>> Quota
>>>>> https://github.com/apache/cloudstack/pull/768
>>>>> 
>>>>> Logging enhancement
>>>>> https://github.com/apache/cloudstack/pull/1167
>>>>> 
>>>>> VMware diskcontrollers
>>>>> https://github.com/apache/cloudstack/pull/1132
>>>>> 
>>>>> ACS allows to create isolated networks with invalid gateway ip
>>>>> https://github.com/apache/cloudstack/pull/1125
>>>>> 
>>>>> Update nic IP address of stopped vm
>>>>> https://github.com/apache/cloudstack/pull/1086
>>>>> 
>>>>> Hypervisor changes to support UserData for Nuage VSP
>>>>> https://github.com/apache/cloudstack/pull/1142
>>>>> 
>>>>> Support shared networking in NiciraNVP Plugin
>>>>> https://github.com/apache/cloudstack/pull/1094
>>>>> 
>>>>> Strongswan vpn feature
>>>>> https://github.com/apache/cloudstack/pull/872
>>>>> 
>>>>> VM Snapshotting implementation for KVM
>>>>> https://github.com/apache/cloudstack/pull/977
>>>>> 
>>>>> Redundant VPC improvement
>>>>> (PR will follow over the weekend)
>>>>> 
>>>>> 
>>>>> UI PRs:
>>>>> 
>>>>> [UI] fix bug: Cannot delete SSH keypairs in projects
>>>>> https://github.com/apache/cloudstack/pull/1154
>>>>> 
>>>>> UI icon over VM snapshot to deploy user instance
>>>>> https://github.com/apache/cloudstack/pull/1150
>>>>> 
>>>>> Newly added project is not showing in the drop down until the browser is
>>>> refreshed
>>>>> https://github.com/apache/cloudstack/pull/1082
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Daan
>> 

Re: What SDN are you using?

[sebgoa]

On Nov 29, 2015, at 8:19 PM, Simon Weller  wrote:

> Nux,
> 
> The two most deployed SDN solutions are Vmware NSX-MH (Nicara) and Nuage VSP 
> (Alcatel-Lucent).  Neither are cheap!
> We've been evaluating whether we're going to run a POC on Nuage, as it does 
> have some very cool features including service chaining.
> Most of the other SDN plugins within CS are either very alpha, or haven't 
> received any updates in quite a while. 
> I polled the dev list list a few months back and it didn't appear anyone on 
> the lists were running (or willing to talk about) Big Switch, Midonet or 
> Stratosphere.

Midonet and Stratosphere are pretty much abandoned.
So is the open contrail driver.

Big Switch should work as it was updated recently and should be in 4.6 (let me 
cc KC Wange who did the refactor recently).

The opendaylight and native GRE have always been beta, and you are correct that 
they have not received much attention.

> I know someone built the start of a plugin for Open Daylight, but it hasn't 
> seen any development since then. We even reached out to Midonet, offering to 
> pay for support and they told us to install Openstack ;-)
> 
> We have the native KVM VXLAN implementation running in our lab and it seems 
> to work very well. We went 100% 10/40GB using open platform switches and 
> Cumulus linux.

Good to know.

> 
> Our main interest in SDN is to provide more advanced traffic steering and 
> security features later.
> 
> - Si
> 
> 
> 
> 
> 
> 
> From: Nux! 
> Sent: Sunday, November 29, 2015 12:56 PM
> To: Cloudstack Users List
> Cc: dev
> Subject: What SDN are you using?
> 
> Hello,
> 
> So besides the folks using Nicira, can anyone recommend any other SDN thing 
> or should I stay with v(x)lans?
> I'm kind of removed from this side of things since my deployments tend to be 
> with Security Grups in a single or few VLANs, any suggestions welcome, 
> preferably free/foss.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: Package Repositories

[sebgoa]

Hi folks, we need to resolve this.

1-But I have to start with one comment:
Apache open office releases binaries, users don't compile from source. So it is 
possible within ASF to officially release binaries.

2-We have several initiatives around repos, apt-get.eu (Wido), shapeblue repos, 
Nux mirrors and image templates.
Seems everyone agrees we need a tag team to coordinate all of it and offer a 
unified front.

3-This unified front is great, but it won't happen this week, it will take time 
and dedication.

4-The small issue we are facing is about 3 lines in an HTML file on our 
website. Pierre-Luc and I had a chat Friday, in one of his comments on the PR 
he suggested that we list 3 categories:

- source
- community repo
- 3-rd party repo

I am +1 with this, why ?

-source is a no brainer
- community repo (apt-get) because that's our defacto pkg repo even though we 
don't vote on packages. There was not vote to say these were our community repo 
but that's a fact. Several people have access to the machine and can make 
updates etc...
- 3rd party, allows us to list vendor pkg repo. The more vendors provide 
CloudStack the better. I see it a bit like the "books" discussions we had 
couple years ago. We do not endorse them, but we should promote them.

In our docs however, we should not be referencing 3rd party repos, and any URLs 
should be cloudstack project specific.

Can you please reply with your vote on these 3 categories. I think it's a 
compromise that helps us move forward.

-sebastien



On Nov 27, 2015, at 10:41 AM, Daan Hoogland  wrote:

> On Fri, Nov 27, 2015 at 10:38 AM, Paul Angus 
> wrote:
> 
>> Doesn't that meant that we'll have to vote on the source and the packaged
>> rpms/debs otherwise they we have no official community standing. ?
>> 
> ​I am not sure how we can give them official standing yet but we are the
> apache foundation​, so we vote on source. I would say we vote on the
> packaging software from a different repo then the core+plugins and
> automatically update a repo from that one. The repo will not be endorsed
> but the way it is filled will be.
> 
> my €0,02 of future dreams
> 
> 
> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: 27 November 2015 09:36
>> To: dev 
>> Subject: Re: Package Repositories
>> 
>> On Fri, Nov 27, 2015 at 9:58 AM, Paul Angus 
>> wrote:
>> 
>>> So. My understanding is that to make the packages in the repo 'official'
>>> they must be voted on.  -- would we make the packages what we vote on,
>>> rather that the source code (bearing in mind you can't separate the
>>> packaging in that case).   IMHO, it'll make testing a whole lot simpler
>> for
>>> folks if there is just no requirement to build from source.
>>> 
>> 
>> ​We will not stop voting on the source! Any vote on -, or otherwise
>> handling of packages is a separate thing.​
>> 
> 
> 
> -- 
> Daan

Re: Package Repositories

[sebgoa]

On Nov 30, 2015, at 4:39 PM, Nux!  wrote:

> BTW, if these bits are "no redistribute", why are we distributing them?

This is really a case of evolution and expectation.

When Wido started this, these pkgs were not sanctioned by the *project*, hence 
non-official release pkgs and not voted on.

This is still the case.

We called this pkg repo the "community" repo because they are maintained by 
community members but not sanctioned by a vote by the project and hence to this 
point, not official ASF releases.

These are convenience pkgs.

It seems that it might be the time to work on figuring out how to offer 
official pkg, meaning sanctioned by a vote on dev@.

Until we establish this process and actually do a release, this repo remains a 
community repo (which does not imply that they are official pkg).

The only difference I make between apt-get.eu and shapeblue repo is that the 
apt-get has folks from different affiliation with access to the machine. Even 
though the shapeblue repo is also maintained by committers.

This discussion is all good for the project, so let's not try to create any 
type of conflict here.

Now that we have a second pkg repo to list on the download page this is forcing 
us to (re) think what deem a "community" repo and most possibly work towards 
official pkgs.

To re-iterate my take on this, we are going to have a period of time where we 
still have the community repo (called like this historically) + shapeblue repo 
until we potentially unify them of list them with a proper term.

This is why I proposed:

1-source release (official)
2-community repo (non-official)
3-third party (non-official, with single affiliation of people who have access).

** We just need a simple, acceptable naming for the download page for a 
transitory period **

Ps: certainly things could get a bit more complicated if people outside 
shapeblue had access to this repo.

> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Monday, 30 November, 2015 15:28:24
>> Subject: Re: Package Repositories
> 
>> On Mon, Nov 30, 2015 at 3:38 PM, Wido den Hollander  wrote:
>> 
 Paul, as far as releases I know, package on cloudstack.apt-get.eu
>>> include
 noredis libraries.
 
>>> 
>>> The debs don't I think. I never checked the RPMs.
>> 
>> 
>> ​Any RPMs I uploaded do. Those are mostly the 4.4 ones (not sure but I
>> think the 4.3 ones as well).​
>> 
>> 
>> 
>> --
>> Daan

Re: Package Repositories

[sebgoa]

On Nov 30, 2015, at 11:28 AM, Paul Angus <paul.an...@shapeblue.com> wrote:

> Sebastien,
> 
> Can you confirm that users can expect to find the noredist build of the rpms 
> and debs at apt-get.eu ?
> 

I don't know

What I understood from Rohit, is that the "shapeblue" repo also contains pkgs 
that are hot-fixed and have features back ported.
In that sense it is quite a different repo than apt-get which only has pkg for 
each release.


> 
> 
>   
> Paul Angus
> VP Technology  ,   ShapeBlue Ltd
> s:02036170528   |  t: @cloudyangus  |  m: +44 
> 7711418784
> e:paul.an...@shapeblue.com  |  w: www.shapeblue.com
>53 Chandos Place, Covent Garden, London WC2N 4HS. UK
> 
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue 
> Services India LLP is a company incorporated in India and is operated under 
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
> incorporated in Brasil and is operated under license from Shape Blue Ltd. 
> ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa 
> and is traded under license from Shape Blue Ltd. ShapeBlue is a registered 
> trademark.
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error.
> 
> 
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 30 November 2015 10:24
> To: dev <dev@cloudstack.apache.org>
> Subject: Re: Package Repositories
> 
> +1 all the way, sebastien
> 
> On Mon, Nov 30, 2015 at 11:20 AM, Nux! <n...@li.nux.ro> wrote:
> 
> > +1 your categories.
> >
> > Also +1 for the unified thing under cloudstack.apache.org domain.
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> > > From: "sebgoa" <run...@gmail.com>
> > > To: dev@cloudstack.apache.org
> > > Sent: Monday, 30 November, 2015 10:08:59
> > > Subject: Re: Package Repositories
> >
> > > Hi folks, we need to resolve this.
> > >
> > > 1-But I have to start with one comment:
> > > Apache open office releases binaries, users don't compile from source.
> > So it is
> > > possible within ASF to officially release binaries.
> > >
> > > 2-We have several initiatives around repos, apt-get.eu (Wido),
> > shapeblue repos,
> > > Nux mirrors and image templates.
> > > Seems everyone agrees we need a tag team to coordinate all of it and
> > offer a
> > > unified front.
> > >
> > > 3-This unified front is great, but it won't happen this week, it
> > > will
> > take time
> > > and dedication.
> > >
> > > 4-The small issue we are facing is about 3 lines in an HTML file on
> > > our
> > website.
> > > Pierre-Luc and I had a chat Friday, in one of his comments on the PR
> > > he suggested that we list 3 categories:
> > >
> > > - source
> > > - community repo
> > > - 3-rd party repo
> > >
> > > I am +1 with this, why ?
> > >
> > > -source is a no brainer
> > > - community repo (apt-get) because that's our defacto pkg repo even
> > though we
> > > don't vote on packages. There was not vote to say these were our
> > community repo
> > > but that's a fact. Several people have access to the machine and can
> > > make updates etc...
> > > - 3rd party, allows us to list vendor pkg repo. The more vendors
> > > provide CloudStack the better. I see it a bit like the "books"
> > > discussions we had couple years ago. We do not endorse them, but we 
> > > should promote them.
> > >
> > > In our docs however, we should not be referencing 3rd party repos,
> > > and
> > any URLs
> > > should be cloudstack project specific.
> > >
> > > Can you please reply with your vote on these 3 categories. I think
> > > it's a compromise that helps us move forward.
> > >
> > > -sebastien
> > >
> > >
>

Re: Package Repositories

[sebgoa]

On Nov 30, 2015, at 11:28 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote:

> 
>> On 30-Nov-2015, at 3:38 PM, sebgoa <run...@gmail.com> wrote:
>> 
>> - source
>> - community repo
>> - 3-rd party repo
>> 
>> I am +1 with this, why ?
>> 
>> -source is a no brainer
>> - community repo (apt-get) because that's our defacto pkg repo even though 
>> we don't vote on packages. There was not vote to say these were our 
>> community repo but that's a fact. Several people have access to the machine 
>> and can make updates etc...
>> - 3rd party, allows us to list vendor pkg repo. The more vendors provide 
>> CloudStack the better. I see it a bit like the "books" discussions we had 
>> couple years ago. We do not endorse them, but we should promote them.
> 
> +1 on possibly doing official packages and hosting in future.
> 
> -1 on the listings, community repo is 3rd party repo too. With my PMC hat on 
> - just because several people from the community are maintaining it should 
> not make it blessed unless they are officially voted. Even if half the 
> community were to maintain an unofficial repository, it would still be a 3rd 
> party repo.
> 
> We should write them like this:
> 
> - source
> - 3rd party repo (not endorsed by Apache)
> 

big -1 on this, that would be even more confusing.

The community repos stand out from any other repos because:

- there are part of the installation docs, and 
- because they have been maintained for several years now.
- they are non-affiliated

The fact that we don't vote on them is really a technicality that we never 
addressed (lacked of time, lack of clear policy etc).

if we can't resolve this then I will be in favor of just listing source 
downloads.


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

Re: 4.7 status update

[sebgoa]

On Nov 27, 2015, at 7:23 PM, Remi Bergsma  wrote:

> Hi all,
> 
> The next version of Apache CloudStack will be built on top of 4.6 and 
> released from the stable master branch. In the past weeks we’ve added several 
> PRs on master with new features:
> 
>  *   Upgrade to latest AWS S3 SDK
>  *   List api’s preformance improvement
>  *   UI improvement and metrics views
>  *   Nicira plugin update
>  *   Nuage plugin update

+ quota ?

>  *   and a bunch of bug fixes and code quality improvements
> 
> Keep these dates in mind:
> 
> Mon Dec  7: 4.7.0 Feature freeze
> Mon Dec 14: 4.7.0 RC1
> 
> This means we’ve about 10 days until we freeze for 4.7. Please review PRs to 
> get them in on time. Maybe even send new PRs. But we do need reviewers ;-)
> 
> It will be a great release again!
> 
> Regards,
> Remi
> 

Re: [NOTICE] people.apache.org web space is moving to home.apache.org

[sebgoa]

Talluri,

Can you answer Ian's comment below ?

-sebastien

On Nov 28, 2015, at 3:03 AM, Ian Duffy <i...@ianduffy.ie> wrote:

> What are the legal implications of any of hosting that
> licensed/copyrighted/paid-for material if any?
> 
> windows7.vhd
> RHEL6-64bit.ova
> RHEL764bitwithtools.vhd
> 79211594-1d4a-4dee-ae6c-c5c315ded2be.vhd which appears to be windows 8
> 
> On 25 November 2015 at 18:44, Srikanteswararao talluri <
> talluri.w...@gmail.com> wrote:
> 
>> Moved all the following references in the test code to
>> https://home.apache.org/~talluri/ .  github PR
>> https://github.com/apache/cloudstack/pull/1123
>> 
>> http://people.apache.org/~tsp/cloud-set-guest-password
>> 
>> http://people.apache.org/~tsp/dummy.iso
>> 
>> "http://people.apache.org/~sanjeev/centos63.ova;,
>> 
>> "http://people.apache.org/~sanjeev/windows7.vhd;,
>> 
>> "http://people.apache.org/~sanjeev/new-test-win.ova;,
>> 
>> "http://people.apache.org/~sanjeev/Rhel6-64bit.ova;,
>> 
>> "http://people.apache.org/~sanjeev/ttylinux_pv.vhd.bz2;,
>> 
>> "http://people.apache.org/~sanjeev/RHEL764bitwithtools.vhd;,
>> 
>> "
>> http://people.apache.org/~sanjeev/79211594-1d4a-4dee-ae6c-c5c315ded2be.vhd
>> ",
>> 
>> "http://people.apache.org/~sanjeev/rajani-thin-volume.vhd;,
>> 
>> "http://people.apache.org/~sanjeev/CentOS5.5(64bit)-vmware-autoscale.ova",
>> 
>> "http://people.apache.org/~sanjeev/rajani-thin-volume.qcow2;,
>> 
>> "http://people.apache.org/~sanjeev/centos56-x86_64.vhd.bz2;,
>> 
>> "http://people.apache.org/~sanjeev/CentOS5.3-x86_64.ova;
>> 
>> "
>> http://people.apache.org/~sanjeev/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2
>> "
>> 
>> "url": "http://people.apache.org/~sanjeev/CentOS-6.3-x86_64-bin-DVD1.iso;
>> 
>> "
>> http://people.apache.org/~sanjeev/systemvm64template-2014-09-30-4.3-vmware.ova
>> ",
>> 
>> 
>> Thanks,
>> 
>> ~Talluri
>> 
>> 
>> On Wed, Nov 25, 2015 at 8:28 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>> 
>>> You are right, Sebastien. @Rajani, do you have an idea on the volume of
>>> work, here?
>>> 
>>> On Wed, Nov 25, 2015 at 2:10 PM, sebgoa <run...@gmail.com> wrote:
>>> 
>>>> 
>>>> On Nov 25, 2015, at 2:07 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>>>> wrote:
>>>> 
>>>>> are those refs expecting particular content returned? (it will be
>>>>> redirected)
>>>>> 
>>>> 
>>>> the way I read the email, it will be redirected but would give a 404 if
>>>> you don't move the data yourself :)
>>>> 
>>>>> On Wed, Nov 25, 2015 at 1:40 PM, Rajani Karuturi <raj...@apache.org>
>>>> wrote:
>>>>> 
>>>>>> We have references to people.apache.org in our testdata.
>>>>>> 
>>>>>> ~Rajani
>>>>>> 
>>>>>> On Wed, Nov 25, 2015 at 5:50 PM, Daniel Gruno <humbed...@apache.org
>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi folks,
>>>>>>> as the subject says, people.apache.org is being decommissioned
>> soon,
>>>> and
>>>>>>> personal web space is being moved to a new home, aptly named
>>>>>>> home.apache.org ( https://home.apache.org/ )
>>>>>>> 
>>>>>>> IMPORTANT:
>>>>>>> If you have things on people.apache.org that you would like to
>>> retain,
>>>>>>> please make a copy of it and move it to home.apache.org. (note,
>> you
>>>> will
>>>>>>> have to make a folder called 'public_html' there, for items to show
>>> up
>>>>>>> under https://home.apache.org/~yourID/ ).
>>>>>>> 
>>>>>>> We will _NOT_ be moving your data for you. There is simply too much
>>> old
>>>>>>> junk data on minotaur (the current people.apache.org machine) for
>> it
>>>> to
>>>>>>> make sense to rsync it across, so we have made the decision that
>>> moving
>>>>>>> data is up to each individual committer.
>>>>>>> 
>>>>>>> The new host, home.apache.org, will ONLY be for web space, you
>> will
>>>> not
>>>>>>> have shell access to the machine (but you can copy data to it using
>>>> SFTP
>>>>>>> and your SSH key). Access to modify LDAP records (for project
>> chairs)
>>>>>>> will be moved to a separate host when the time comes.
>>>>>>> 
>>>>>>> There will be a 3 month grace period to move your data across.
>> After
>>>>>>> this time span (March 1st, 2016), minotaur will no longer serve up
>>>>>>> personal web space, and visits to people.apache.org will be
>>> redirected
>>>>>>> to home.apache.org.
>>>>>>> 
>>>>>>> With regards,
>>>>>>> Daniel on behalf of the Apache Infrastructure Team.
>>>>>>> 
>>>>>>> PS: All replies to this should go to infrastruct...@apache.org
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Daan
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Daan
>>> 
>> 

Re: Package Repositories

[sebgoa]

On Nov 26, 2015, at 7:52 AM, John Burwell  wrote:

> All,
> 
> A conversation emerged on a PR [1] regarding how package repositories should 
> listed on the downloads page [2].  This PR was prompted by a change on the 
> page which removed reference to the ShapeBlue repositories.

Let me touch base with Pierre-Luc to see what happened. It seems he removed it, 
but he is also the one who added it in the first place.

>  The PR proposes listing all "3rd-Party Distributions" in a separate section 
> in the same manner as the Apache Cassandra [3] project — clearly stating that 
> the package repositories are not endorsed by the community.  Objections were 
> raised that the apt-get.eu repository is a “blessed” 
> community repository, and therefore, not a third party repository.  To the 
> best of my knowledge (and my ability to search the mailing list archives), I 
> can not find a vote that changed the project deliverables to include 
> distribution packages or a particular repository for them.

There was no vote on this, and we should not get down that path of arguing 
about whether apt-get.eu is blessed or not.

Very early when CloudStack arrived at apache, Wido started hosting packages and 
has kept doing it, on his own time on his own budget. He has been kind enough 
to give access to the server to a few of us and can give access to people who 
request it.

Hence this evolved as the "community repo".

However since we only vote on source, we do not vote on packages and we should 
not say that this "community repo" is a blessed repo (there is a bit of grey 
area here).

We have always said that this is a community maintained repo in contrary to an 
official ASF repo.


>  Furthermore, the vote for 4.6.0 was only for the source deliverable — not 
> distribution packages.  As such the packages contained in the 
> apt-get.eu repository are no more “blessed” or endorsed 
> than any other packages distributed by other parties.
> 

They are not blessed (as voted on), but have grown organically to be maintained 
by several folks with different affiliations.

> In my opinion, favoring one 3rd-party repository over another is detrimental 
> to the community.  We should either list all maintained 3rd-party package 
> repositories or we should list none at all.   By maintained, I mean a 
> repository that meets the following criteria:
> 
>  *   All contained packages are built from project release tags
>  *   The packages contained in the repository are up-to-date with latest 
> release tags
> 
> The only variations in the packages across “maintained” repositories should 
> be the plugins from the CloudStack source tree included in the package.  In 
> order to be listed on the downloads page, a repository must meet this 
> definition and provide a brief description of the repository’s purpose.
> 
> Some on the PR discussion asked about the purpose and composition of the 
> packages in the ShapeBlue repository.  The packages in the ShapeBlue 
> repository are noredist builds of community release tags.  

Remembering when Rohit started this, (as he happened to be at my house couple 
times during that timeframe), the idea that triggered this was to start build 
packages for every commit, not just releases. As well as starting to offer 
packages that contained hot fixes.

> They contain no additional patches or changes.  

> This repository was created to provide users with an convenient/familiar way 
> to install the noredist build of a release.
> 
> Finally, as I have stated elsewhere, I think the project should build 
> distribution packages signed by the project and distributed from official 
> package repositories.  However, we must come to a consensus as community this 
> change in deliverables and work out a variety of issues (e.g. supported 
> platforms, repository management, signing, etc) to ensure that users receive 
> well-tested, community voted packages.  Finally, it seems like there will be 
> a role for 3rd-party repositories now and in the future.  Listing all 
> available 3rd-party repos as I propose would be convenient for users, and 
> ensure fairness to all contributors.
> 
> Thanks,
> -John
> 
> [1]: https://github.com/apache/cloudstack-www/pull/20
> [2]: http://cloudstack.apache.org/downloads.html
> [3]: http://cassandra.apache.org/download/
> 

All in all, as was mentioned by Pierre Luc on the PR, I do not see a problem 
with listing (on the www download page):

* Official source
* Community maintained repo (not voted but maintained by more than single 
vendor)
* Third party repo

In the rest of the documentation however, I don't think we should be using 
vendor specific URLs.

The only risk with this is the user "confusion" question:

- What is different between the repos ?
- Which one should I use ?
- I used a third party repo, I have a problem who can help me ?




> ---
> John Burwell (@john_burwell)
> VP of Software 

main docs not on 4.6

[sebgoa]

looking at this:
http://docs.cloudstack.apache.org/en/latest/#

it's still on 4.5

there are no changes to it for 4.6, but it's confusing because there is no 4.6 
tag, …..and a 4.5 ref in the header…

Re: [NOTICE] people.apache.org web space is moving to home.apache.org

[sebgoa]

On Nov 25, 2015, at 2:07 PM, Daan Hoogland  wrote:

> are those refs expecting particular content returned? (it will be
> redirected)
> 

the way I read the email, it will be redirected but would give a 404 if you 
don't move the data yourself :)

> On Wed, Nov 25, 2015 at 1:40 PM, Rajani Karuturi  wrote:
> 
>> We have references to people.apache.org in our testdata.
>> 
>> ~Rajani
>> 
>> On Wed, Nov 25, 2015 at 5:50 PM, Daniel Gruno 
>> wrote:
>> 
>>> Hi folks,
>>> as the subject says, people.apache.org is being decommissioned soon, and
>>> personal web space is being moved to a new home, aptly named
>>> home.apache.org ( https://home.apache.org/ )
>>> 
>>> IMPORTANT:
>>> If you have things on people.apache.org that you would like to retain,
>>> please make a copy of it and move it to home.apache.org. (note, you will
>>> have to make a folder called 'public_html' there, for items to show up
>>> under https://home.apache.org/~yourID/ ).
>>> 
>>> We will _NOT_ be moving your data for you. There is simply too much old
>>> junk data on minotaur (the current people.apache.org machine) for it to
>>> make sense to rsync it across, so we have made the decision that moving
>>> data is up to each individual committer.
>>> 
>>> The new host, home.apache.org, will ONLY be for web space, you will not
>>> have shell access to the machine (but you can copy data to it using SFTP
>>> and your SSH key). Access to modify LDAP records (for project chairs)
>>> will be moved to a separate host when the time comes.
>>> 
>>> There will be a 3 month grace period to move your data across. After
>>> this time span (March 1st, 2016), minotaur will no longer serve up
>>> personal web space, and visits to people.apache.org will be redirected
>>> to home.apache.org.
>>> 
>>> With regards,
>>> Daniel on behalf of the Apache Infrastructure Team.
>>> 
>>> PS: All replies to this should go to infrastruct...@apache.org
>>> 
>> 
> 
> 
> 
> -- 
> Daan

Re: [VOTE] Apache CloudStack 4.6.0

[sebgoa]

On Nov 7, 2015, at 2:33 PM, Remi Bergsma  wrote:

> As requested by Boris, I’ll extend the vote until the end of today CET 
> (instead of 4pm CET), that’s 8 extra hours.
> 
> Anyone else actively testing?

I was waiting for Pierre Luc to push the RC to docker hub to at least test the 
simulator.
Also I wanted to run the RAT..

had not time yet, unlikely to happen until monday or tuesday.

I would be keen to keep the vote open, or cancel it if there are anythings that 
pop upped.

> 
> Regards,
> Remi
> 
> From: Remi Bergsma 
> >
> Date: Wednesday 4 November 2015 15:55
> To: "dev@cloudstack.apache.org" 
> >
> Subject: [VOTE] Apache CloudStack 4.6.0
> 
> Hi all,
> 
> I've created a 4.6.0 release candidate, with the following artifacts up for a 
> vote:
> 
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=4.6.0-RC20151104T1522
> 
> Commit: b0ebe68e375432b28eef031ab62ccd5831234c77
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.6.0/
> 
> PGP release keys (signed using A47DDC4F):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Vote will be open for at least 72 hours.
> 
> For sanity in tallying the vote, can PMC members please be sure to indicate 
> "(binding)" with their vote?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 

Re: BVT report - 10/22

[sebgoa]

I presume simulator runs are still 100% ?

On Oct 22, 2015, at 4:01 PM, Raja Pullela  wrote:

> Hi,
> 
> Following is the latest BVT report - 10/22
> Xen Basic :  94.0%
> KVM Basic: 97.1%  - glad to see the reboot ssvm/cpvm are fixed
> Xen Adv: 91.9% - test_internal_lb and test_network needs code fixes, possibly!
> KVM Adv: 93.6% - glad to see the reboot ssvm/cpvm are fixed  - 
> test_internal_lb and test_network needs code fixes, possibly!
> 
> Test cases failing:
> Xen Basic:
> 
> * 
> integration.smoke.test_vm_snapshots.TestSnapshots.test_01_test_vm_volume_snapshot
>  // Test case issue createsnapshot failed, due to: errorCode: 431, 
> errorText:Volume snapshot is not allowed
> 
> * 
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>   // Error to be investigated - SSH failed for virtual machine: 
> 192.168.175.23 - SSH connection has Failed. Waited 600s
> 
> * 
> integration.smoke.test_volumes.TestVolumes.test_02_attach_volume
>   // Error to be investigated - SSH failed for VM: 192.168.175.19 - SSH 
> connection has Failed. Waited 600s
> 
> * 
> integration.smoke.test_iso.TestISO.test_07_list_default_iso
>   // Test case issue - looking for an ISO that does not exist.
> KVM Basic:
> 
> * 
> integration.smoke.test_iso.TestISO.test_07_list_default_iso
>  // Test case issue - looking for an ISO that does not exist.
> 
> * 
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>  // Error to be investigated - SSH failed for virtual machine: 192.168.175.23 
> - SSH connection has Failed. Waited 600s
> 
> KVM Adv:  please note BLANK means I see a bunch of spaces in the error 
> message.  Can someone rerun these tests.
> 
> * 
> integration.smoke.test_internal_lb.TestInternalLb.test02_internallb_haproxy_stats_on_all_interfaces
>   // Issue to be investigated -
> 
> * 
> integration.smoke.test_internal_lb.TestInternalLb.test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
>   // Issue to be investigated
> 
> * 
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_1_static_nat_rule
>   // Error: IP address is BLANK not removed from VR even after disabling 
> statin NAT
> 
> * 
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_2_nat_rule
>   // Error: IP address is BLANK not removed from VR even after disabling 
> statin NAT
> 
> * 
> integration.smoke.test_network.TestRouterRules.test_network_rules_acquired_public_ip_3_Load_Balancer_Rule
>  // Error: IP address is BLANK not removed from VR even after disabling 
> statin NAT
> 
> * 
> 

Re: BVT report 10/1

[sebgoa]

Hi Boris,

See below the latest BVT run from Raja.

Could you run all tests under smoke folder on your physical KVM setup (master 
branch), and help analyze some of the failures ?

thanks,

-sebastien


On Oct 1, 2015, at 2:22 PM, Raja Pullela <raja.pull...@citrix.com> wrote:

> Sebastien, Yes, I trying to debug all the KVM issues currently - but not able 
> to root cause what the issue is?
> 
> Can anyone please run these tests on a KVM setup and report if it is 
> working/not working for you?  
> 
> Thanks,
> Raja
>   
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com] 
> Sent: Thursday, October 1, 2015 5:46 PM
> To: dev@cloudstack.apache.org
> Subject: Re: BVT report 10/1
> 
> Raja,
> 
> Is anyone on your side looking at those test_ssvm failures ?
> 
> On Oct 1, 2015, at 1:20 PM, Raja Pullela <raja.pull...@citrix.com> wrote:
> 
>> Blockers - as open in ACS JIRA:
>> 
>> -  CloudStack-8927 /
>> 
>> -  CloudStack-8924 / Test case failure.  Waiting for PR-900/902 to 
>> be merged.
>> 
>> -  CloudStack-8923 /
>> 
>> -  CloudStack-8915 /
>> 
>> -  CloudStack-8876 /
>> 
>> -  CloudStack-8697 / related to test case failure: 
>> integration.smoke.test_internal_lb.TestInternalLb.test_internallb
>> 
>> BVT report - 10/1 -
>> Summary:  Runs same as earlier run on 09/29 - merging PRs 900/902 will help 
>> get Simulator Basic and XS Basic to 100%.
>> Hope Rajani or Remi can push these PRs!
>> 
>> 
>> -  Simulator Basic - 97.6%, 1 test failed
>> 
>> -  Simulator Adv - 100%
>> 
>> -  XS Basic - 98.5%, 1 test failed
>> 
>> -  XS Adv - 94.5%, 4 tests failed
>> 
>> -  KVM Basic - 94.2%, 6 tests failed
>> 
>> -  KVM Adv - 92.6%, 8 tests failed
>> 
>> Test case failures:  No change from earlier report, waiting for couple of 
>> PRs to be merged
>> 
>> -  Simulator Basic
>> 
>> o   
>> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>>  //Failure: CloudStack-8924
>> 
>> -  XS Basic
>> 
>> o   
>> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>>  //Failure: CloudStack-8924
>> 
>> -  KVM Basic
>> o
>> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>>   //Failure: SSH failed for VM
>> ointegration.smoke.test_volumes.TestVolumes.test_02_attach_volume  
>> //Failure: Root cause is TBD
>> ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm  //Failure: 
>> Root cause is TBD
>> 
>> o   integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm  //Failure: 
>> Root cause is TBD
>> 
>> -  XS Adv
>> 
>> o:setup  // 
>> Failure: Test Setup.  Asked if Miguel can put conditional code to skip the 
>> test; assuming that this is passing in his Env.
>> 
>> o
>> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>>  //Failure: CloudStack-8924
>> 
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>>  //Failure: SSH failed for VM
>> 
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>>   //Failure: SSH failed for VM
>> 
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
>>   //Failure: SSH failed for VM
>> 
>> o   integration.smoke.test_internal_lb.TestInternalLb.test_internallb 
>> //Failure: CloudStack-8697
>> 
>> -  KVM Adv
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>>  //Failure: SSH failed for VM
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>>  //Failure: SSH failed for VM
>> o
>> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb
>>  //Failure: SSH failed for VM
>> o:setup  // 
>> Failure: Test Setup.  Asked if Miguel can put conditional code to skip the 
>> test; assuming that this is passing in his Env.
>> o
>> integration.smoke.test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk
>>   //Failure: Failed to create snapshot due to an internal error
>> o
>> integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm<http://ccp-tests.xenrt.xs.citrite.net/jenkins/job/Hollywood-BVT-Multi/CLOUDSTACK_CONFIG=AdvKVM/176/testReport/junit/integration.smoke.test_ssvm/TestSSVMs/test_08_reboot_cpvm/>
>>  //Failure: Root cause is TBD
>> ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm //Failure: 
>> Root cause is TBD
>> ointegration.smoke.test_internal_lb.TestInternalLb.test_internallb 
>> //Failure: CloudStack-8697
>> -end---
> 

Re: BVT report 10/1

[sebgoa]

Raja,

Is anyone on your side looking at those test_ssvm failures ?

On Oct 1, 2015, at 1:20 PM, Raja Pullela  wrote:

> Blockers - as open in ACS JIRA:
> 
> -  CloudStack-8927 /
> 
> -  CloudStack-8924 / Test case failure.  Waiting for PR-900/902 to be 
> merged.
> 
> -  CloudStack-8923 /
> 
> -  CloudStack-8915 /
> 
> -  CloudStack-8876 /
> 
> -  CloudStack-8697 / related to test case failure: 
> integration.smoke.test_internal_lb.TestInternalLb.test_internallb
> 
> BVT report - 10/1 -
> Summary:  Runs same as earlier run on 09/29 - merging PRs 900/902 will help 
> get Simulator Basic and XS Basic to 100%.
> Hope Rajani or Remi can push these PRs!
> 
> 
> -  Simulator Basic - 97.6%, 1 test failed
> 
> -  Simulator Adv - 100%
> 
> -  XS Basic - 98.5%, 1 test failed
> 
> -  XS Adv - 94.5%, 4 tests failed
> 
> -  KVM Basic - 94.2%, 6 tests failed
> 
> -  KVM Adv - 92.6%, 8 tests failed
> 
> Test case failures:  No change from earlier report, waiting for couple of PRs 
> to be merged
> 
> -  Simulator Basic
> 
> o   
> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>  //Failure: CloudStack-8924
> 
> -  XS Basic
> 
> o   
> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>  //Failure: CloudStack-8924
> 
> -  KVM Basic
> o
> integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
>   //Failure: SSH failed for VM
> ointegration.smoke.test_volumes.TestVolumes.test_02_attach_volume  
> //Failure: Root cause is TBD
> ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm  //Failure: 
> Root cause is TBD
> 
> o   integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm  //Failure: 
> Root cause is TBD
> 
> -  XS Adv
> 
> o:setup  // Failure: 
> Test Setup.  Asked if Miguel can put conditional code to skip the test; 
> assuming that this is passing in his Env.
> 
> o
> integration.smoke.test_scale_vm.TestScaleVm.test_02_scale_vm_without_hypervisor_specifics
>  //Failure: CloudStack-8924
> 
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>  //Failure: SSH failed for VM
> 
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>   //Failure: SSH failed for VM
> 
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb 
>  //Failure: SSH failed for VM
> 
> o   integration.smoke.test_internal_lb.TestInternalLb.test_internallb 
> //Failure: CloudStack-8697
> 
> -  KVM Adv
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_01_create_lb_rule_src_nat
>  //Failure: SSH failed for VM
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_02_create_lb_rule_non_nat
>  //Failure: SSH failed for VM
> o
> integration.smoke.test_loadbalance.TestLoadBalance.test_assign_and_removal_lb 
> //Failure: SSH failed for VM
> o:setup  // Failure: 
> Test Setup.  Asked if Miguel can put conditional code to skip the test; 
> assuming that this is passing in his Env.
> o
> integration.smoke.test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk
>   //Failure: Failed to create snapshot due to an internal error
> o
> integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm
>  //Failure: Root cause is TBD
> ointegration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm //Failure: 
> Root cause is TBD
> ointegration.smoke.test_internal_lb.TestInternalLb.test_internallb 
> //Failure: CloudStack-8697
> -end---

Re: test_nicira_controller.py is failing on all Advzone - XS, KVM

[sebgoa]

I am not aware of anyone except Schuberg that uses the nicira (NSX) cloudstack 
integration.

And since Miguel wrote the test, I am comfortable doing what he suggests and 
not run it as part of the standard tests for a release.

-sebastien

On Oct 1, 2015, at 12:57 PM, Miguel Ferreira  
wrote:

> Can’t we not run the test if we do not wish to do so?
> 
> \ Miguel Ferreira
>   mferre...@schubergphilis.com
> 
> 
> 
> 
> On 01 Oct 2015, at 12:11, Koushik Das 
> > wrote:
> 
> Can't we output a proper message (missing OR incorrect config) while skipping 
> the test?
> 
> On 01-Oct-2015, at 2:56 PM, Miguel Ferreira 
> > wrote:
> 
> Hi Raja,
> 
> I don’t agree with what you propose.
> I do understand your intention is to be able to run all tests and skip the 
> ones you don’t have a config for.
> However, I also see the other side of that coin, when someone actually wants 
> to run the tests but makes a mistake in the config and the tests get skipped.
> 
> I think the test should fail if the config is not right, or otherwise be 
> excluded if the indentation is to not run them.
> 
> Cheers,
> \ Miguel Ferreira
> mferre...@schubergphilis.com
> 
> 
> 
> 
> On 30 Sep 2015, at 19:40, Raja Pullela 
> >
>  wrote:
> 
> Hi Miguel,
> 
> Can you please add some checking in the setup method for the configuration 
> parameters and if it is not available, can you skip this test?
> 
> Raja
> 
> -Original Message-
> From: Raja Pullela [mailto:raja.pull...@citrix.com]
> Sent: Wednesday, September 30, 2015 5:52 PM
> To: Miguel Ferreira 
> >
> Cc: dev 
> >
> Subject: RE: test_nicira_controller.py is failing on all Advzone - XS, KVM
> 
> thanks Miguel !
> 
> From: Miguel Ferreira [mailto:mferre...@schubergphilis.com]
> Sent: Wednesday, September 30, 2015 3:01 PM
> To: Raja Pullela 
> >
> Cc: dev 
> >
> Subject: Re: test_nicira_controller.py is failing on all Advzone - XS, KVM
> 
> Hi Raja,
> 
> That test needs a NSX cluster. With that in place, the configuration used to 
> run the test must define a section called NiciraNvp, and that section should 
> have an array os hosts with that name (see line 46 of the test).
> In a Marvin config that materializes in something like this:
> "niciraNvp": {
> 
> "hosts": [ "nsxcon1.cloud.lan", "nsxcon2.cloud.lan" ]
> }
> 
> Furthermore, you need to have a zone configured to use NSX and that requires 
> more work.
> You can find a full Marvin config for it here: 
> https://github.com/schubergphilis/MCT-shared/blob/master/marvin/mct-zone1-kvm1-NVP.cfg
> In that same git repo there are config files for deploying a NSX cluster 
> (https://github.com/schubergphilis/MCT-shared/blob/master/deploy/cloud/nsx_cluster.conf).
> However, we have not yet fully automated all the steps needed to get the 
> cluster up and running (ie. setting up the cluster internals, and adding a 
> more controllers to the cluster).
> I can help you with that if you need.
> 
> Cheers,
> \ Miguel Ferreira
> mferre...@schubergphilis.com
> 
> 
> 
> On 30 Sep 2015, at 09:05, Raja Pullela 
> >
>  wrote:
> 
> Hi Miguel or someone's familiar with this test,
> 
> Can you please provide documentation around how to get these tests running ?
> BTW - looks like this is a new test that was added on Aug 25th 2015.
> 
> Thanks,
> Raja
> 
> === TestName: None | Status : EXCEPTION === ERROR
> 
> ==
> ERROR: test suite for  'integration.smoke.test_nicira_controller.TestNiciraContoller'>
> --
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 209, in run
> self.setUp()
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 292, in 
> setUp
> self.setupContext(ancestor)
> File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 315, in 
> setupContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in 
> try_run
> return func()
> File 

[DOCS] Remove all docbook reference

[sebgoa]

Doc folks,

I removed all docbook references in:
https://github.com/apache/cloudstack-docs

If we need we can always get back to a previous commit...

-Sebastien

[CCC] Docker Challenge, Raspberry Pi to win.

[sebgoa]

Hi folks (apologies for cross-posting),

I am running out of time to do it myself so I would like to issue everyone a 
challenge.

Create a docker-compose file that:

* Starts the mgt server in a container
* Starts a mysql container to act as mgt server db
* Starts the usage server in a container
* Starts the ec2stack container
* Starts the KVM agent in a container

The compose file is to be run on a Ubuntu or CentOS server with KVM and Docker 
installed.
Some containers may use host networking and be privileged.
You can use the official cloudstack images in the docker hub or build your own.
If you build your own I want to see all Dockerfiles in a pull request to 
cloudstack repo.

The result should be a working single-node CloudStack deployment started with a 
single command:

$ docker-compose up -d

To win:  1 Raspberry Pi to the first person to demonstrate it live at CCC.
1 Raspberry Pi to the first blog post tweeted that points to 
all files necessary for the deployment.
Free beers or club sodas for the night.

This is not a Joke :)
I have the Raspberry Pi in my bag.

1 week to go…Go 

-Sebastien

Re: Blameless post mortem

[sebgoa]

Remi, thanks for the detailed post-mortem, it's a good read and great learning.
I hope everyone reads it.

The one thing to emphasize is that we now have a very visible way to get code 
into master, we have folks investing time to provide review (great), we need 
the submitters to make due diligence and answer all comments in the reviews.

In another project i work on, nothing can be added to the code without unit 
tests. I think we could go down the route of asking for new integration tests 
and unit tests for anything. If not, the PR does not get merged. But let's 
digest your post-mortem and we can discuss after 4.6.0.

I see that you reverted one commit that was not made by you, that's great.

Let's focus on the blockers now, everything else can wait.

The big bonus of doing what we are doing is that once 4.6.0 is out, we can 
merge PRs again (assuming they are properly rebased and tested) and we can 
release 4.6.1 really quickly after.

-sebastien

On Sep 25, 2015, at 9:51 PM, Remi Bergsma  wrote:

> Hi all,
> 
> This mail is intended to be blameless. We need to learn something from it. 
> That's why I left out who exactly did what because it’s not relevant. There 
> are multiple examples but it's about the why. Let's learn from this without 
> blaming anyone.
> 
> We know we need automated testing. We have integration tests, but we are 
> unable to run all of them on any Pull Request we receive. If we would have 
> that in place, it'd be much easier to spot errors, regression and so on. It'd 
> also be more rewarding to write more tests.
> 
> Unfortunately we're not there yet. So, we need to do something else instead 
> until we get there. If we do nothing, we know we have many issues because a 
> master that breaks on a regular basis is the most frustrating things. We said 
> we'd use Pull Requests with at least two humans to review and give their OK 
> for a Pull Request. In the form of LGTM: Looks Good To Me. Ok, so the LGTMs 
> are there because we have no automated testing. Keep that in mind. You are 
> supposed to replace automated testing until it's there.
> 
> Since we do this, master got a lot more stable. But every now and then we 
> still have issues. Let's look at how we do manual reviews. Again, this is not 
> to blame anyone. It's to open our eyes and make us realise what we're doing 
> and what results we get out of that.
> 
> 
> Example Pull Request #784: 
> Title: CLOUDSTACK-8799 fixed the default routes
> 
> That's nice, it has a Jira id and a short description (as it should be).
> 
> The first person comes along and makes a comment:
> "There was also an issue with VPC VRs" ... "Have you seen this issue? Does 
> your change affects the VPC VR (single/redundant)?"
> 
> Actually a good question. Unfortunaly there comes no answer. After a 
> reminder, it was promised to do tests against VPC networks. Great!
> 
> The Jenkins builds both succeed and also Travis is green. But how much value 
> does this have? They have the impression to do automated testing, and 
> although you could argue they do, it's far from complete. If it breaks, you 
> know you have an issue. But it doesn’t work the other way around.
> 
> Back to our example PR. In the mean time, another commit gets pushed to it: 
> "CLOUDSTACK-8799 fixed for vpc networks." But if you look at the Jira issue, 
> you see it is about redundant virtual routers. The non-VPC ones. So this is 
> vague at best. But a reviewer gives a LGTM because the person could create a 
> VPC. That doesn't have anything to do with the problem being fixed in this PR 
> nor with the comments made earlier. But, at least the person said what he did 
> and we should all do that. What nobody knew back then, was that this broke 
> the default route on VPCs.
> 
> Then something strange happens: the two commits from the PR end up on master 
> as direct commits. With just one LGTM and no verification from the person 
> commenting about the linked issue. This happened on Friday September 11th. 
> 
> That day 21 commits came in, from 7 Pull Request and unfortunately also from 
> some direct commits. We noticed the direct commits and notified the list 
> (http://cloudstack.markmail.org/message/srmszloyipkxml36). As a lot came in 
> at the same time, it was decided not to revert them. Looking back, we should 
> have done it.
> 
> From this point on, VPCs were broken as they wouldn't get a default route. 
> So, no public internet access from VMs in VPC tiers, no VPNs working, etc. 
> This was mentioned to the list on Thursday September 15th, after some chats 
> and debugging going on over the weekend 
> (http://cloudstack.markmail.org/message/73ulpu4p75ex24tc)
> 
> Here we are, master is broken functionality wise and new Pull Requests come 
> in to fix blockers. But we cannot ever test their proper working, because 
> VPCs are broken in master and so also in the PRs branched off of it. With or 
> without change in the PR. 
> 
> It starts 

[RESULT][VOTE] Apache CloudStack EC2stack 0.8.0

[sebgoa]

Hi all,

After 72 hours, the vote for CloudStack EC2stack 0.8.0  *passes* with
4 PMC + 1 votes

+1 (PMC / binding)
* Rajani
* Rohit
* Sebastien (implicit)
* David

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to give 
the mirrors time to catch up.

Re: [VOTE] Release Apache CloudStack EC2stack 0.8.0

[sebgoa]

On Sep 1, 2015, at 9:17 AM, Rajani Karuturi  wrote:

> Where did you give cloudstack apikey and secret?
> Did you give AWS keys both at AWS configure and ec2-register?

yes you need to do both…

$ aws configure ….> give your keys
$ ec2stack-register ….> give your keys

That step is a bit clumsy right now

> 
> ~Rajani
> 
> 
> 
> On 01-Sep-2015, at 10:16 am, Rohit Yadav 
> > wrote:
> 
> 
> On 28-Aug-2015, at 4:34 pm, Rajani Karuturi 
> > wrote:
> 
> $ ec2stack-register http://localhost:5000 cs_api_key 
> cs_secret_key
> $ aws ec2 describe-images --endpoint=http://localhost:5000
> # it gave the below error message
> # Unable to locate credentials. You can configure credentials by running "aws 
> configure”.
> $ aws configure # gave AWS api and secret key
> $ aws ec2 describe-images --endpoint=http://localhost:5000
> # this is the output I see
> # localhost - - [28/Aug/2015 16:25:24] "POST / HTTP/1.1" 401 -
> # ‘RequestID’
> 
> Something went wrong with registering the user, use this to register the 
> apikey/secretkey:
> 
> curl -d AWSSecretKey=yoursecretkey -d AWSAccessKeyId=yourapikey -d 
> Action=RegisterSecretKey http://localhost:5000
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> 
> 
> 
> 
> M. +91 88 262 30892 | 
> rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.
> 

[EVENT] CCC Dublin Oct 8-9

[sebgoa]

CloudStack collab Dublin Oct 8-9 is coming up fast,

http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe

Register for this exciting event.

See you all there,

Cheers,

-Sebastien

Re: [VOTE] Release Apache CloudStack EC2stack 0.8.0

[sebgoa]

On Aug 26, 2015, at 7:08 PM, David Nalley da...@gnsa.us wrote:

 +1 (binding)
 
 sigs and hashes look good.
 builds fine
 no binaries present.
 A few files seem to be missing license headers, but I don't think it's
 a blocker.
 License and NOTICE appear to be correct.
 
 I wish we pointed to the cloudstack docker hub account rather than the
 runseb account, but don't think it's a blocker for release
 

missed that, now fixed.

 --David
 
 On Wed, Aug 26, 2015 at 5:25 AM, sebgoa run...@gmail.com wrote:
 Hi All,
 
 I've created a 0.8.0 release of EC2stack, with the following artifacts up 
 for a vote:
 
 Git Branch and Commit SH:
 https://git-wip-us.apache.org/repos/asf?p=cloudstack-ec2stack.git
 
 Commit: a61d7c01129dfe4c31515a48e0f6b4a53436c208
 
 There are no code changes from the time the code was donated to the ASF, 
 only license headers and a Dockerfile.
 
 Source release (checksums and signatures are available at the same
 location):
 https://dist.apache.org/repos/dist/dev/cloudstack/ec2stack-0.8.0/
 
 PGP release keys (signed using 8F89EB84):
 https://dist.apache.org/repos/dist/release/cloudstack/KEYS
 
 For testing functionality you might consider using the Docker image:
 docker pull cloudstack/cloudstack-ec2stack
 
 Do remember that the official release artifact is the source code, which 
 needs to contain proper licensing and proper signatures.
 
 Vote will be open for 72 hours.
 
 For sanity in tallying the vote, can PMC members please be sure to indicate 
 (binding) with their vote?
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

[VOTE] Release Apache CloudStack EC2stack 0.8.0

[sebgoa]

Hi All,

I've created a 0.8.0 release of EC2stack, with the following artifacts up for a 
vote:

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack-ec2stack.git

Commit: a61d7c01129dfe4c31515a48e0f6b4a53436c208

There are no code changes from the time the code was donated to the ASF, only 
license headers and a Dockerfile.

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

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

For testing functionality you might consider using the Docker image:
docker pull cloudstack/cloudstack-ec2stack

Do remember that the official release artifact is the source code, which needs 
to contain proper licensing and proper signatures.

Vote will be open for 72 hours.

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

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

Re: review wanted

[sebgoa]

On Aug 25, 2015, at 12:41 AM, Rafael Weingärtner rafaelweingart...@gmail.com 
wrote:

 Hi Daan,
 I think that we should do a proper introduction.
 It might seem kind of odd to some people that a bunch of folks suddenly
 started working for free.
 
 Our first PR was done a while ago:
 https://github.com/apache/cloudstack/pull/560. Then we did
 https://github.com/apache/cloudstack/pull/700, and the last one was the
 https://github.com/apache/cloudstack/pull/714, that is still in the review
 process.
 
 Until now you know Pedro (PR 714) and Critofolini (PR 700), but we are a
 team of five. We work under the same project and the improvements/clean ups
 that we have been doing to the ACS is a way we found to improve our
 knowledge of the software that we are using.
 
 I am a Ph. D. candidate, researching/developing autonomic models that can
 be used to manage and optimize a cloud computing environment that provide
 infrastructure as a service. We have done an extensive work comparing and
 discussing cloud computing orchestration platforms that are most widely
 used. CloudStack was the orchestration tool chosen to develop my proposals,
 in order to test and validate them.
 
 I have several undergrad students working with me; none of them had real
 experience developing java web applications, the PRs we are creating is the
 way we found to teach them some Java developing skills, while getting to
 know a little better of ACS core and architecture. At the same time we are
 contributing to the software we use.
 
 The team that works with me and you will probably see creating more PRs is
 the following:
 
   - Gabriel Beims Bräscher
   - Pedro Henrique Pereira Martins
   - Lucas Berri Cristofolini
   - Alexandre Santana
 
 
 All of them are Computer Science student. They all are developing their
 graduation projects within my thesis.  Sadly, some of the things we are
 doing here and that we have already prototyped, we cannot commit to the ACS
 community (at least not yet); hence it is part of a thesis project.
 However, once we start publishing papers, I think you will like what we
 have been working on.
 
 Hope we can keep up the good work and keep learning with you all guys from
 the ACS community.
 Waiting to hear the feedbacks on PR 714 ;)
 
 

Hi Rafael, thanks a lot for the introduction. That's exactly the type of 
commitment that the community needs.

We will look out for PRs from this group and hopefully will benefit from your 
thesis work at a latter date.

Welcome,

-sebastien


 On Sat, Aug 22, 2015 at 1:10 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
 
 everybody, I will LGTM PR #714 [1] and I would like to have more then one
 extra pair of eyes this time. Some group of folks, I know there is at
 least
 three of them, have decided to invest in cleaning some code in CS and I
 think their work deserves full attention. they worked on refactoring some
 of the CitrixResourceBase hierarchy [2] and now they are busy on the
 ComponentLifecycleBase
 hierarchy.
 
 Please have a look,
 
 [1] https://github.com/apache/cloudstack/pull/714
 [2] https://github.com/apache/cloudstack/pull/700
 
 --
 Daan
 
 
 
 
 --
 Rafael Weingärtner

Re: Release EC2stack 1.0.0

[sebgoa]

On Aug 13, 2015, at 12:00 AM, Ian Duffy i...@ianduffy.ie wrote:

 Hey Sebastien,
 
 Thank you for doing this.
 
 If there's any small jobs I can help out let me know, I'm allowed to work
 on this type of stuff again once Friday the 14th passes.
 

we are missing a few badges in the readme. I think we had coveralls at one 
point and that fury thing…not sure what that is.

 On Wednesday, August 12, 2015, sebgoa run...@gmail.com wrote:
 
 
 On Aug 12, 2015, at 12:31 PM, sebgoa run...@gmail.com javascript:;
 wrote:
 
 Hi folks,
 
 I am working towards making a release of EC2stack.
 Since it was given to our project we have not made an official release.
 
 I just added a few documentation files, added license headers, notice
 files, copied over the release script from cloud monkey.
 Plus a few other odds and ins.
 
 I don't plan to do any changes to the actual code for now, but I would
 like to make a 1.0.0 release and then start patching.
 
 How do people feel about this ?
 Has anyone used it lately with 4.5.x releases ?
 
 finally, any help to get the Travis runs working again would be good,
 matter of changing the links I think.
 
 
 FWIW, I fixed the Travis build , we are green :)
 
 https://github.com/apache/cloudstack-ec2stack
 
 feedback welcome, otherwise I will just cut a release and send a vote
 thread.
 
 cheers,
 
 -Sebastien
 
 

Re: Release EC2stack 1.0.0

[sebgoa]

On Aug 12, 2015, at 12:31 PM, sebgoa run...@gmail.com wrote:

 Hi folks,
 
 I am working towards making a release of EC2stack.
 Since it was given to our project we have not made an official release.
 
 I just added a few documentation files, added license headers, notice files, 
 copied over the release script from cloud monkey.
 Plus a few other odds and ins.
 
 I don't plan to do any changes to the actual code for now, but I would like 
 to make a 1.0.0 release and then start patching.
 
 How do people feel about this ?
 Has anyone used it lately with 4.5.x releases ?
 
 finally, any help to get the Travis runs working again would be good, matter 
 of changing the links I think.
 

FWIW, I fixed the Travis build , we are green :)

https://github.com/apache/cloudstack-ec2stack

 feedback welcome, otherwise I will just cut a release and send a vote thread.
 
 cheers,
 
 -Sebastien

Re: Ec2stack not working with current aws cli

[sebgoa]

On Aug 10, 2015, at 11:25 PM, Carlos Reátegui car...@reategui.com wrote:

 
 
 Can you make a PR that updates the README with this config option…
 
 Done. 
 

thanks merged

 
 
 thanks
 
 On Aug 6, 2015, at 3:07 AM, Carlos Reategui create...@gmail.com wrote:
 
 BTW I figured out how to force the cli to send v2.  It would still be nice
 to update Ec2Stack though:
 
 aws configure set profile.your profile name.ec2.signature_version v2
 
 
 Or for your default profile:
 
 
 aws configure set default.ec2.signature_version v2
 
 
 The above will update your ~/.aws/config file.
 
 
 
 
 On Wed, Aug 5, 2015 at 5:49 PM, Carlos Reategui create...@gmail.com wrote:
 
 Hi,
 I am having trouble with the current aws cli.  Ec2stack is expecting AWS
 signature version 2 but the current aws cli uses v4.
 
 Do I file a JIRA in under cloudstack?  I did not see an ec2stack component.
 
 Here is a wireshark capture:
 
 POST / HTTP/1.1
 Host: localhost:5000
 Accept-Encoding: identity
 Content-Length: 40
 Content-Type: application/x-www-form-urlencoded
 X-Amz-Date: 20150806T002150Z
 Authorization: AWS4-HMAC-SHA256
 Credential=x/20150806//ec2/aws4_request,
 SignedHeaders=host;user-agent;x-amz-date, Signature=xx
 User-Agent: aws-cli/1.7.42 Python/2.7.6 Darwin/14.4.0
 
 Action=DescribeImagesVersion=2015-04-15
 
 HTTP/1.0 400 BAD REQUEST
 Content-Type: application/xml
 Content-Length: 314
 Server: Werkzeug/0.10.4 Python/2.7.3
 Date: Thu, 06 Aug 2015 00:21:50 GMT
 
 ?xml version=1.0 encoding=UTF-8?
 Response
 
 
 Errors
 Error
 CodeMissingParameter/Code
 MessageThe request must contain the parameter
 SignatureVersion/Message
 /Error
 /Errors
 
 
 
  RequestId21ba5526-3bd1-11e5-abbc-d4ae52927e09/RequestId
 
 /Response
 
 
 

Re: [BLOCKER][4.6] New AWS SDK in master breaks S3 uploads

[sebgoa]

On Jul 17, 2015, at 10:53 AM, Wido den Hollander w...@widodh.nl wrote:

 Hi,
 
 Issue: https://issues.apache.org/jira/browse/CLOUDSTACK-8640
 
 I encountered this by using the AWS SDK under 4.5 (homebrew).
 
 4.5 uses the 1.3.22 SDK, but master uses 1.9.8 and that breaks S3 uploads.
 
 AWS SDK 1.3.22 is old, very old, but 1.9.8 is also rather old.
 
 The new SDK throws different Event Types and we can't simply fix a
 else statement since I tried and it failed.
 
 The S3TemplateDownloader was written in 2013, but imho it is a poor
 implementation which is rather buggy.
 
 It will need some work to get it working with the new AWS SDK however.
 
 Amazon in the meantime also started to switch to the new V4 Signature
 for Authorization, but that isn't supported yet by projects like Ceph's
 RADOS Gateway and probably by other S3 providers.
 
 So this seems like a blocker for 4.6, since we would ship a broken S3
 implementation we know about.
 
 We can revert to the 1.3.22 AWS SDK, but I don't know the reasoning
 behind the switch to the 1.9.8 SDK.
 
 This was done in fac7bfc5d503aa25a82a684f7ec545197d255fb2 by Rohit, but
 I'm not sure if it was properly tested.
 
 The best route would be to fix the S3TemplateDownloader, I agree, but
 that would take a lot more time.

I we talked about it for the roadmap, and Francois Gaudreault is also 
interested to get this better supported.

If you can edit the roadmap with the bug ID that would help, at least to track 
it down.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap

thanks

 
 Wido

Re: [Discuss] separate ML for PR and build notification?

[sebgoa]

On Jul 13, 2015, at 12:55 PM, Wido den Hollander w...@widodh.nl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 
 On 13-07-15 10:11, Rene Moser wrote:
 Hey
 
 Since we rebuild our communication stack (slack, irc, ML, ...) I
 would bring up some discussion about the noise in the dev ML.
 
 I like to be in dev ML but I am not that interested in
 notifications about builds on PR, PR comments, and Jenkins builds.
 
 I am suggest to make a seprate ML for those who really want it.
 
 Any thoughts?
 
 
 The reasoning behind it is that this way all devs get the messages.
 But honestly, I'm not to happy either with it.
 
 I actually have a filter on it since I want to read the messages on a
 mobile device as well and all those posts pollute my inbox.
 
 But we also want these messages to be seen and resolved, but it's a
 difficult one.

I think we should be patient with this, and see how we are dealing with the PRs…

My gut feeling is to wait till september and asses then, whether we need to 
route these somewhere else.

Personnaly , I like seeing it on dev@, I filter JIRA and end up not checking 
the issues that often..

 
 Wido
 
 Yours René
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQIcBAEBAgAGBQJVo5kNAAoJEAGbWC3bPspCFNoQAJ9ix/mQxLHc7Wq4VRwU4ZwA
 4KbXL2VHO0/H0S2Kbf0cMC6sn1tkVq4eKpRMZTEvIz4jlDtMYbtyoYEtLXl67ae4
 EmyakOeLeXDIKZA20qDUzxqTi+R6zcWhLKaEM2scq445Bhw/9MjDNvPfIBNTXvCk
 Sgcq/LyxYZU61y3rFvc6Rx2jokHCFR34phYPMFrhp2BE5flZmSFp+q3ith0B508e
 LNVNCoOtyVZT3ZQuLafHulIb1mIm1qh0cFbtSUkWXxsN4z311AxZaDbmMSnXtlyX
 ksyyB7jJ6h/ImI+WwB9r12KOIbs0jeCYFSpY4gMv1jetMApvPrV+szOn2+xAFlds
 qgClTsTfa6aEv1xHIOqBjY4IHxtOvc70n1MAr/e5Q6MJpE/Mx2ncF79FqPnlqFrw
 Xhp11exgAYl/a6bkQ3ALkYXxrJFAd20UEK6iD5tPzSvgavNuYI+QkqzVs7bwC+Kn
 BhJ2cq+p4x8qk8UfzAO8rS1yEtjqrqFpYtRduhmpsR7kdVJmTYkryyQpvhfrVwde
 AR3Tzl+kF18+DR8GDUgmRtpnmNCNaTqVvygkBNr2M2b9TaCyKd56dxd8t+f2StQw
 D7QF9kGNF96DS/wSUwAXCnPCH0KluJFxAV8y5ewYwGznmlc8sVQ6ohyhV6eiZcBi
 AtjGlXKrCaLrPVm28PV+
 =5hwi
 -END PGP SIGNATURE-

Re: [DISCUSS] Release principles for Apache CloudStack

[sebgoa]

Finally read the thread,

It seems to me that a way forward is to have Remi and Rajani RM 4.6 (which is 
currently master).

The two of them can discuss and start RMing 4.6  (PR merge etc) and then we can 
iterate on the wiki release scenario.

@Remi @Rajani, would that work for you and you ready to get started ?

-sebastien


On Jul 10, 2015, at 8:17 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 I hate to be as opiniated as I am but here it comes ;)
 
 On Fri, Jul 10, 2015 at 7:39 PM, Rohit Yadav rohit.ya...@shapeblue.com
 wrote:
 
 While I like the ideas generally [1], some concerns and observations
 that I wish could be considered;
 
 - active contributor crunch:
 
 we don’t have large number of active people working towards testing,
 fixing bugs and release, and reviewing/merging PRs on *master*; this
 affects the agility of any process or workflow we want to put in, or expect
 resolution in a certain window (3-5 days etc.);
 
 ​This is a very valid concern. We are a large community but not in any way
 big enough. One approach is to let no backporting of bugfixes happen! it
 sound contrary to some of your points but I think it is actually a
 mitigation (see below).
 ​
 
 
 - diverse interests:
 
 our user-base may not necessarily want to upgrade to newer version of
 CloudStack even if they can proved to be quite stable; in-fact commercially
 some of us are paid to maintain stable branches and support users who are
 still on 4.2/4.3/4.4/4.5 etc; based on my experience, a typical enterprise
 users usually stick with a version (that works for them) for at least 6
 months, while smb user or in-house consumers are quite agile who may
 upgrade as quickly as when new releases are made;
 
 ​User do go for bug fixes and are not concerned with any backwards
 compatible changes to functionality. If we guard against those, point
 releases are replaced by the minors and people can be as 'sticky' as they
 want. In the end it is a matter of naming and discipline. Of course we need
 to sell our policy.
 ​
 
 
 - diverse branching/merging workflow usage and understanding:
 
 the bugfix workflow may not be acceptable (to go on master first), a lot
 of people have their own way of branching/merging in their organisations
 that affect how they do it in the the project
 
 ​I do not think it is. If you want something fixed you should fix it on the
 oldest version it needs fixing on. No backporting at all. this only
 mystifies our git tree and ​
 
 ​prohibits good administration. Bug-fixes can be merged forward and whether
 anyone has one of infinite other possible​ release management schemes
 internally should not influence the way they work on this project.
 
 
 - waiting time on new changes:
 
 since we don’t have large number of active testers and developers who
 can fix bugs rapidly, freezing master and doing the release may take a lot
 of time (unless if we can put a hard deadline or have some schedule to
 support that?), in which case new features and refactoring work will have
 to lay hanging (and some rebase/code-rework may be needed later when they
 are merged, when master is open)
 
 ​lso very valid. No freeze, just release candidates would be a solution to
 that. One point in time is proposed as candidate and voted on. if it goes
 it goes, if it doesn't there will be new chances in the near future. We do
 depend on good quality control on master for this.
 ​
 
 
 
 - release risk:
 
 after a release x.y.0 is made and since master can receive new features,
 refactoring work; the next x.y.1 can potentially add more regressions due
 to those new features and refactoring/re-architectural work
 
 ​I don't agree here; any x.y.1 will be on a branch other then master.​
 
 
 
 
 - release maintenance and support demands:
 
 historically there has been an assumed or known stable release that is
 fairly tested in the wild and has built trust due to usage by users
 (through meetups, users ML, customer interactions etc), in the past those
 versions were 4.2.1 then 4.3.1/4.3.2, now based on my experience the last
 stable release is 4.5.1
 
 ​You know we don't agree on 4.4 vs 4.5 and I don't want to fight that fight
 here and now but how is this a concern either way? Any minor can have point
 releases following it if needed.
 ​
 
 
 
  [1]
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
 
 On 02-Jul-2015, at 5:16 pm, Remi Bergsma r...@remi.nl wrote:
 
 Hi all,
 
 We already agreed contributions should always go via a PR and require two
 LGTM’s before we merge. Let me propose the next step on how I think we
 should do release management for 4.6 and on.
 
 I talked to several people over the past weeks and wrote this wiki article:
 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudSta
 ck 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack
 
 
 If you like this way of working, I volunteer 

Re: Introducing Boris Schrijver

[sebgoa]

On Jul 8, 2015, at 5:08 PM, Wido den Hollander w...@widodh.nl wrote:

 Hi all,
 
 As you might know, we at PCextreme are using CloudStack for our public
 cloud offering and have been looking for a CloudStack dev for a long time.
 
 We found one; so let me introduce Boris Schrijver.
 
 Boris will be our fulltime CloudStack developer with no other purpose
 then making CloudStack better :)
 
 CloudStack is a Apache project, so it will be Boris contributing to
 CloudStack and NOT PCextreme as a company. He might become a committer
 one day, who knows.
 
 Today is his first day, so it will take a bit before you'll see the
 first PR coming in.
 

Welcome Boris, great to have you on-board

 Wido
 

Re: [PROPOSAL] Commit to master through PR only

[sebgoa]

On Jul 3, 2015, at 12:01 PM, Wilder Rodrigues wrodrig...@schubergphilis.com 
wrote:

 Hi John,
 
 If you look at the discrete operations wearing a hat of a Project Manager, 
 you won’t care… neither would I. However, from a Software Engineer 
 perspective, as much as the other people contributing with the Java code, I 
 do care and it really makes reviewing the PR easier.
 

The PR should not be squashed until it's reviewed and accepted.

I am only arguing for squashing it when it is accepted and before merge.

For now, I would love for us to focus on the 2 LGTM and green tests (as much as 
we can get them green). We can fine tune later.


-sebastien


 As a consumer of my change (project manager hat again), you should be looking 
 for Design Documents. Those will for sure show the motivation behind the 
 changes in a higher level.
 
 Concerning the 5k lines classes, I have found a few of them and they haven 
 been refactored accordingly. Have a look at the Virtual Router, 
 Citrix/LibVirt resource classes, those were cleaned as much as they could. 
 The example I gave was simple and should not be used in such a way, Think of 
 it as a 100 lines class instead, perhaps it will help.
 
 I’m feeling inclined to send my next PR with squashed commits to see if it 
 will get reviewed properly and in an easy way.
 
 Cheers,
 Wilder 
 
 
 On 02 Jul 2015, at 20:35, John Burwell john.burw...@shapeblue.com wrote:
 
 Wilder,
 
 In the grand scheme of the entire project history (e.g. reading git log), 
 why do I care about these discrete operations?   In six months (or long), I 
 (as the consumer of your change) want to know what motivated this change 
 which is completely lost in those two commits.  I have found this advice [1] 
 for commit messages combined with squashing commits to a topic (e.g. defect 
 ticket, feature, enhancement ticket, etc) yields a git history that 
 incredible value over the long term in a projects with a lot of developers 
 making many changes.
 
 Thanks,
 -John
 
 P.S. As an aside, if you encounter a 5000 class, I would encourage you to 
 decompose it rather than reformat the file.
 
 [1]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
 
 ---
 John Burwell (@john_burwell)
 VP of Software Engineering, ShapeBlue
 (571) 403-2411 | +44 20 3603 0542
 http://www.shapeblue.com
 
 
 
 On Jul 2, 2015, at 2:43 AM, Wilder Rodrigues 
 wrodrig...@schubergphilis.com wrote:
 
 Sateesh and Rajesh,
 
 It seems you were the only guys who +1 the squash idea. Could you please 
 share with us what benefits you think squashing commits will bring?
 
 I wil give you the simplest example that could come to my mind to encourage 
 no squash:
 
 * I open a Java class with 5 thousand lines. The first thing I do is format 
 the code and commit the change.
 * I go back to the class and apply the fix, let’s say, a 3 lines change, 
 then I commit the change again.
 
 Now, think about the PR. It will contain 2 commits: 1 with the formatting 
 changes only; and a second commit with 3 lines change.
 
 Would you like to see it quashed and all messed up? It would be very 
 difficult to review.
 
 That’s just a simple example.
 
 Cheers,
 Wilder
 
 On 02 Jul 2015, at 07:22, Rajesh Battala rajesh.batt...@citrix.com wrote:
 
 +1 for squashing commit
 
 -Original Message-
 From: John Burwell [mailto:john.burw...@shapeblue.com]
 Sent: Thursday, July 2, 2015 12:14 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [PROPOSAL] Commit to master through PR only
 
 All,
 
 I think we should stick to 2 votes per PR.  Defining types of PRs becomes 
 difficult bordering on the arbitrary — adding a process complexity and the 
 potential to start debating if a particular PR is one type or another.
 
 I agree regarding the fast forward, and feel that all PRs should squashed 
 down to one commit.  Ultimately, intermediate commits that seem 
 informative in a feature branch become noise in a history as large as 
 CloudStack’s.
 
 To enforce the policy and ensure that PRs are merged in an orderly and 
 correct manner (i.e. one at time), I think we should consider adopting a 
 tool such as bors [1] to verify that the merge passes all tests and then 
 performs the merge. It would some minor modification to require two votes, 
 but I doubt that would take much effort to implement.  If there is 
 interest, I would happy to make those changes for the project.
 
 Thanks,
 -John
 
 [1]: https://github.com/graydon/bors
 
 ---
 John Burwell (@john_burwell)
 VP of Software Engineering, ShapeBlue
 (571) 403-2411 | +44 20 3603 0542
 http://www.shapeblue.com
 
 
 
 On Jul 1, 2015, at 1:48 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
 
 Hi,
 
 On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen run...@gmail.com wrote:
 
 A few of us are in Amsterdam at DevOps days. We are chatting about 
 release management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].
 
 However to get 

Re: [ACS4.5] status

[sebgoa]

On Jul 7, 2015, at 8:17 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 I haven't heard of this in a few days. Does anyone keep track of 4.5
 releasebility at the moment? I would like to move on to 4.6:) So can
 we make a release candidate for 4.5.2 yet?

if you think it needs to be done, just do it


 
 -- 
 Daan

Re: resource leaks exception to the 2LGTM rule

[sebgoa]

On Jul 7, 2015, at 12:10 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 I will not do it in one commit, if we insist on a PR i will do 73 commits
 in one PR.
 

are you automating those commits ?

I would not mind scanning through them and giving green light. and in that case 
squash might be good :)

 On Tue, Jul 7, 2015 at 12:04 PM, Rohit Yadav rohit.ya...@shapeblue.com
 wrote:
 
 
 On 07-Jul-2015, at 3:29 pm, Daan Hoogland daan.hoogl...@gmail.com wrote:
 
 I want permission to go ahead and address these issues and not create
 one huge or 73 small PRs. Can I?
 
 
 One huge commit would be fine, testing/merging 73 small PRs is going to
 be some work.
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 
 
 
 
 M. +91 88 262 30892 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Build
 http://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment framework http://shapeblue.com/csforge/
 CloudStack Consulting http://shapeblue.com/cloudstack-consultancy/
 CloudStack Software Engineering
 http://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure Support
 http://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training Courses
 http://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended
 solely for the use of the individual to whom it is addressed. Any views or
 opinions expressed are solely those of the author and do not necessarily
 represent those of Shape Blue Ltd or related companies. If you are not the
 intended recipient of this email, you must neither take any action based
 upon its contents, nor copy or show it to anyone. Please contact the sender
 if you believe you have received this email in error. Shape Blue Ltd is a
 company incorporated in England  Wales. ShapeBlue Services India LLP is a
 company incorporated in India and is operated under license from Shape Blue
 Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
 and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
 a company registered by The Republic of South Africa and is traded under
 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
 
 
 
 
 -- 
 Daan

Re: IRC and Slack

[sebgoa]

I think we are all in agreement here, so let's move on with:

-consolidate #cloudstack and #cloudstack-dev (who can do that ? )
-let's try to be more present on IRC (that's for everyone )
-let's try to setup some slack/IRC proxy so that folks who are using Slack 
right now can make the IRC folks benefit from their conversation. ( I think 
Remi said he would test something out)

-sebastien


On Jul 4, 2015, at 6:27 PM, Remi Bergsma r...@remi.nl wrote:

 John,
 
 All we did was quickly setup as POC to test it out with some folks. I never 
 said it should replace anything in its current state.
 
 Regards, Remi
 
 
 
 On 04 Jul 2015, at 16:32 , John Burwell john.burw...@shapeblue.com wrote:
 
 Remi,
 
 The fact that a chat channel is limited to those with an @apache.org account 
 and requires knowing who to ask for invitation runs counter the Apache Way.  
 Chat channels should be open and discoverable by all.
 
 I am with Nux, -1 for anything like Hipchat, Slack, etc.  If some folks 
 prefer Slack or Hipchat.  I have no issue with those that wish to run their 
 own IRC gateways to these services.  However, I believe the official means 
 endorsed by the community should be Freenode.
 
 Thanks,
 -John
 
 ---
 John Burwell (@john_burwell)
 VP of Software Engineering, ShapeBlue
 (571) 403-2411 | +44 20 3603 0542
 http://www.shapeblue.com
 
 
 
 On Jul 3, 2015, at 4:17 AM, Remi Bergsma r...@remi.nl wrote:
 
 I setup a proof-of-concept a while back to test it: 
 http://cloudstackdev.slack.com. There currently are around 30 people, 
 mostly dev from this list.
 
 Anyone with an @apache.org account can sign-up and anyone else could ask 
 me, Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we 
 setup some other structure for this later on. If you want to be admin, just 
 ping me.
 
 Regards,
 Remi
 
 
 On 3 jul. 2015, at 10:10, Erik Weber terbol...@gmail.com wrote:
 
 On Fri, Jul 3, 2015 at 9:27 AM, sebgoa run...@gmail.com wrote:
 
 Some great ideas in there.
 
 I am +1 for:
 
 -consolidate #cloudstack-dev and #cloudstack
 -move bots to #cloudstack-announce
 -Remi's idea to publish slack message to #cloudstack (and vice versa).
 -the idea to use something like discourse or stack overflow etc…
 
 Somebody wants to take this on :)
 
 
 
 +1 :-)
 
 Is this slack available already? If so, how do I get an invitation?
 
 --
 Erik
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Shape Blue Ltd or related companies. If you are not the 
 intended recipient of this email, you must neither take any action based 
 upon its contents, nor copy or show it to anyone. Please contact the sender 
 if you believe you have received this email in error. Shape Blue Ltd is a 
 company incorporated in England  Wales. ShapeBlue Services India LLP is a 
 company incorporated in India and is operated under license from Shape Blue 
 Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
 and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a 
 company registered by The Republic of South Africa and is traded under 
 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
 

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 2, 2015, at 4:58 PM, Remi Bergsma r...@remi.nl wrote:

 Bug fixing in older releases is actually a lot of work. For security related 
 issues we could maybe do it. 
 
 Personally, I prefer to have a fast release cycle and smooth (tested) upgrade 
 paths over 2-year LTS release cycle. It's more agile. As a bonus, people get 
 the new features. 
 
 The more people do upgrades that work (tm) the more confident they are. I'd 
 really want to show that upgrades work so well that we need no LTS. 
 
 But there might be other reasons people have where LTS would help. Please 
 share!
 
 Regards, Remi 

I think we got in a situation with 4.4 that called for us to keep maintaining 
4.3….and even after 4.5 was released. Because 4.3 was seen as a good release.

Now that we have 4.4 and 4.5.2 etc, I don't think we will have the cycles to 
maintain that many release branches.

The big issue is upgrade path, 

IMHO our LTS strategy is to have master as a release branch itself, adopt good 
practice to merge to master, have great upgrades and no regressions.

Ultimately we should divert our efforts to master.

So I am +1 with Remi on this.

 
 
 On 02 Jul 2015, at 16:25, Rene Moser m...@renemoser.net wrote:
 
 Maybe a little bit off topic to the new release process, therefor a new
 thread...
 
 speaking about releases. I just thought about supporting LTS releases.
 
 This would mean someone or we make a commitment to add bug fixes
 (only) for a specified time. e.g. 2 years for a release or until the
 next LTS release?
 
 Would this something anyone would be interested in?
 
 Yours
 René

Re: IRC and Slack

[sebgoa]

Some great ideas in there.

I am +1 for:

-consolidate #cloudstack-dev and #cloudstack
-move bots to #cloudstack-announce
-Remi's idea to publish slack message to #cloudstack (and vice versa).
-the idea to use something like discourse or stack overflow etc…

Somebody wants to take this on :)



On Jul 2, 2015, at 11:13 PM, Nux! n...@li.nux.ro wrote:

 Hi,
 
 Our IRC channels seem to be dead, indeed, at least for user support 
 purposes. IRC is pretty established and works great for many projects, it 
 just requires people active then and there.
 
 Probably any form of chat will have the same fate no matter how trendy and 
 personally -1 for anything like slack, hipchat etc.
 
 Perhaps a forum might be more user friendly than mailing lists? Discourse ( 
 http://try.discourse.org/ ) looks pretty nice and feature-rich (login with 
 github, facebook etc etc).
 
 My 2 cents
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 - Original Message -
 From: Sebastien Goasguen run...@gmail.com
 To: dev@cloudstack.apache.org
 Sent: Thursday, 2 July, 2015 09:39:31
 Subject: IRC and Slack
 
 Hi folks,
 
 IRC has been mostly deserted for a while now. But there are still folks 
 hanging
 out there with unanswered questions.
 
 I also know of several slack channels on cloudstack.
 
 We need to take a decision here. Shall we officially abandon IRC and out a
 notice there that points towards Slack.
 
 If we do, how do we invite everyone to the slack channel ?
 
 -Sebastien

Re: [DISCUSS] Release principles for Apache CloudStack

[sebgoa]

On Jul 3, 2015, at 9:06 AM, Raja Pullela raja.pull...@citrix.com wrote:

 Remi, 
 
 couple of questions on the branching part - when we take the Feature PR and 
 Feature is back in Master, feel like we are potentially destabilizing Master 
 ?   I know, currently we push changes to master even before anything is 
 tested fully - agree, we are now running the Travis test before a checkin - 
 however, I feel those are not sufficient ?  
 
 IMHO - we should take a release branch open it up for PR/checkins and once 
 the testing is done the branch gets into Master - we take RC from the master 
 and release it.  That way no one checkins to master and constantly tested 
 changes get into/merged to master.  
 
 I remember seeing similar changes proposed by few folks... I have been little 
 out of touch on those changes.
 

Basically yes, we should not merge untested, unfinished features in master.

 best,
 Raja
 -Original Message-
 From: Rajani Karuturi [mailto:raj...@apache.org] 
 Sent: Friday, July 3, 2015 8:00 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [DISCUSS] Release principles for Apache CloudStack
 
 I do not agree to backporting aka cherry picking. I prefer forward 
 merges(tofu scale) 4.4 to 4.5 to master etc.
 That way, none of the changes will be missed and git branch --contains gives 
 a nice view of where all the changes went.
 
 
 On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma r...@remi.nl wrote:
 
 Hi Daan,
 
 Indeed. I prefer committing to master first, as it will ensure everything 
 ends up there (unless some specific use cases). Currently, we have the risk 
 of forgetting to include a fix to a release branch back to master.
 
 When we reverse it, some bug fix that should end up in the x.y branch, is 
 committed to master, then also applied (or reimplemented) to x.y. If you then 
 only take one of the two steps, there is no issue as it will be in master 
 only (and people will notice). In the other situation, when we accept a PR to 
 x.y and forget to merge back, we possibly introduce regression bugs.
 
 I will update the diagram and wiki later tonight.
 
 While reviewing PRs, let’s be alert to see PRs not pointed towards master and 
 at least discuss it.
 
 Regards,
 Remi
 
 
 On 2 jul. 2015, at 16:54, Daan Hoogland daan.hoogl...@gmail.com
 javascript:; wrote:
 
 On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma r...@remi.nl 
 javascript:;
 wrote:
 Since the goal is a stable master, I’d say the bug fix should go to
 master first.
 
 
 Remi, this means that merge back of the branch makes no sense anymore.
 
 --
 Daan
 
 
 
 --
 -
 Sent from Windows Phone
 ~Rajani

Re: IRC and Slack

[sebgoa]

On Jul 3, 2015, at 10:17 AM, Remi Bergsma r...@remi.nl wrote:

 I setup a proof-of-concept a while back to test it: 
 http://cloudstackdev.slack.com. There currently are around 30 people, mostly 
 dev from this list.
 
 Anyone with an @apache.org account can sign-up and anyone else could ask me, 
 Daan, Rohit, Wilder or Funs for an invite (for now). I can imagine we setup 
 some other structure for this later on. If you want to be admin, just ping me.
 
 Regards,
 Remi
 

any chance you can try that IRC/Slack integration pointing to #cloudstack ?

 
 On 3 jul. 2015, at 10:10, Erik Weber terbol...@gmail.com wrote:
 
 On Fri, Jul 3, 2015 at 9:27 AM, sebgoa run...@gmail.com wrote:
 
 Some great ideas in there.
 
 I am +1 for:
 
 -consolidate #cloudstack-dev and #cloudstack
 -move bots to #cloudstack-announce
 -Remi's idea to publish slack message to #cloudstack (and vice versa).
 -the idea to use something like discourse or stack overflow etc…
 
 Somebody wants to take this on :)
 
 
 
 +1 :-)
 
 Is this slack available already? If so, how do I get an invitation?
 
 -- 
 Erik
 

Re: [PROPOSAL] Commit to master through PR only

[sebgoa]

On Jul 2, 2015, at 8:43 AM, Wilder Rodrigues wrodrig...@schubergphilis.com 
wrote:

 Sateesh and Rajesh,
 
 It seems you were the only guys who +1 the squash idea. Could you please 
 share with us what benefits you think squashing commits will bring? 
 
 I wil give you the simplest example that could come to my mind to encourage 
 no squash:
 
 * I open a Java class with 5 thousand lines. The first thing I do is format 
 the code and commit the change.
 * I go back to the class and apply the fix, let’s say, a 3 lines change, then 
 I commit the change again.
 

In our overall effort, I think squashing discussion is lower priority. Agreeing 
to do PR reviews with 2 LGTM before merge is already a very big step in 
stabilizing master and helping with releases.

that should be our higher priority.

That said, I work on libcloud as well. It is a much smaller project. But there 
we squash before committing on master. There can be several commits in the PR, 
because one will surely amend the PR based on review. But once it's accepted, 
it gets merged as a single commit.

You all know I am not a hard core dev guy like some of you Java gurus.

The benefit I see in squashing is that in your release branch (master), one 
functionality is encapsulated in a single commit. You don't need to look 
through 10-20 commits whose messages seem   unrelated. You might be able to run 
some git magic to get all of it, but when I look a the basic commit history, 
things are right there in front of me.

Now if I want to create a bug fix release, and I choose to cherry-pick that 
very thing. I cherry pick one commit, and that's it.

So IMHO, the history of the commit should be in the PR review, not on the 
master git history.

I dream for a day with a super clean master commit history of only merges/PR, 
with JIRA bug ID.

-sebastien


 Now, think about the PR. It will contain 2 commits: 1 with the formatting 
 changes only; and a second commit with 3 lines change.
 
 Would you like to see it quashed and all messed up? It would be very 
 difficult to review.
 
 That’s just a simple example.
 
 Cheers,
 Wilder 
 
 On 02 Jul 2015, at 07:22, Rajesh Battala rajesh.batt...@citrix.com wrote:
 
 +1 for squashing commit
 
 -Original Message-
 From: John Burwell [mailto:john.burw...@shapeblue.com] 
 Sent: Thursday, July 2, 2015 12:14 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [PROPOSAL] Commit to master through PR only
 
 All,
 
 I think we should stick to 2 votes per PR.  Defining types of PRs becomes 
 difficult bordering on the arbitrary — adding a process complexity and the 
 potential to start debating if a particular PR is one type or another.
 
 I agree regarding the fast forward, and feel that all PRs should squashed 
 down to one commit.  Ultimately, intermediate commits that seem informative 
 in a feature branch become noise in a history as large as CloudStack’s.
 
 To enforce the policy and ensure that PRs are merged in an orderly and 
 correct manner (i.e. one at time), I think we should consider adopting a 
 tool such as bors [1] to verify that the merge passes all tests and then 
 performs the merge. It would some minor modification to require two votes, 
 but I doubt that would take much effort to implement.  If there is interest, 
 I would happy to make those changes for the project.
 
 Thanks,
 -John
 
 [1]: https://github.com/graydon/bors
 
 ---
 John Burwell (@john_burwell)
 VP of Software Engineering, ShapeBlue
 (571) 403-2411 | +44 20 3603 0542
 http://www.shapeblue.com
 
 
 
 On Jul 1, 2015, at 1:48 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
 
 Hi,
 
 On 25-Jun-2015, at 4:38 pm, Sebastien Goasguen run...@gmail.com wrote:
 
 A few of us are in Amsterdam at DevOps days. We are chatting about release 
 management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].
 
 However to get started on the right track. I would like to propose the 
 following easy step:
 
 Starting Monday June 29th (next monday):
 
 - Only commit through PR will land on master (after a minimum of 2 LGTM 
 and green Travis results)
 - Direct commit will be reverted
 - Any committer can merge the PR.
 
 +1
 
 I’ve been trying to help close PRs, it was difficult at first but then I 
 found some tooling to help me do that. I think it’s certainly do-able 
 without investing a lot of effort to do it, perhaps can done everyday or 
 every few days in a week.
 
 Some suggestions and comments to improve PR reviewing/merging:
 
 - Let's merge the PR commits in a fast forward way instead of doing a 
 branch merge that introduces frivolous merge commits. This is one approach 
 to do quickly and painlessly:
 
 http://blog.remibergsma.com/2015/05/24/accepting-pull-requests-the-easy-way/
 
 - Let’s try to send PR around on one issue or one broad issue, or against a 
 JIRA ticket; but avoid unrelated sub-systems etc
 
 - If there are not many changes (say less than 100-200 lines were changed), 

Re: [DISCUSS] LTS releases?

[sebgoa]

On Jul 3, 2015, at 11:13 AM, Rene Moser m...@renemoser.net wrote:

 Sebastien,
 
 So wouldn't it be nice to make clear which release is still supported
 and which release is not?
 
 On 03.07.2015 09:20, sebgoa wrote:
 
 I think we got in a situation with 4.4 that called for us to keep 
 maintaining 4.3….and even after 4.5 was released. Because 4.3 was seen as a 
 good release.
 
 Your are saying 4.3 is a good release, shouldn't it be maintained a bit
 longer?
 
 So currently we have:
 
 main 4.5.x
 stable: 4.4.x
 legacy: 4.3.x
 deprecated: 4.2.0
 
 When 4.6 is released, what should a release be dropped? 4.4.x?
 
 main: 4.6.0
 stable: 4.5.x
 legacy: 4.3.x
 
 What is your plan about this?

What is *our* plan :)

We used to only maintain the last two major releases.

We diverged from that model when 4.5.0 came out and that we still wanted to 
maintain 4.3 because 4.3 was working so well for people.

My personal preference would be to get into a rolling release model, where we 
maintain only the last major release.
This is why making master stable and the base for all our releases is so 
important.

Users should get into a model where they continuously upgrade/deploy and don't 
get stuck on a unmaintained branch with forks that prevents upgrade.

When users face an issue, we patch and release, then they upgrade always to the 
latest version.

That's the ideal world :)

 
 Yours
 René
 

Re: [PROPOSAL] Quota management service for cloudstack

[sebgoa]

On Jun 26, 2015, at 1:32 PM, Abhinandan Prateek 
abhinandan.prat...@shapeblue.com wrote:

 Team,
 
   Would like to enhance usage server to provide quota management service to 
 cloudstack.
 This will provide better control on resource usage; and a common denomination 
 to measure resource usage.
 This will be an optional service that can be enabled or disabled as required 
 by the operator.
 
 The detailed discussion is in functional specs here [2]. The corresponding 
 jira ticket is [1].
 
 Please vote so that a decision to include it or not can be taken.
 
 [1] https://issues.apache.org/jira/browse/CLOUDSTACK-8592
 [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
 

Can you add this to the roadmap wiki page…

thanks

 
 Regards,
 -abhi
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Shape Blue Ltd or related companies. If you are not the 
 intended recipient of this email, you must neither take any action based upon 
 its contents, nor copy or show it to anyone. Please contact the sender if you 
 believe you have received this email in error. Shape Blue Ltd is a company 
 incorporated in England  Wales. ShapeBlue Services India LLP is a company 
 incorporated in India and is operated under license from Shape Blue Ltd. 
 Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
 operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
 registered by The Republic of South Africa and is traded under license from 
 Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [PROPOSAL] Commit to master through PR only

[sebgoa]

On Jul 1, 2015, at 9:35 AM, Wilder Rodrigues wrodrig...@schubergphilis.com 
wrote:

 Nice!
 
 I spent couple of hours this morning to review a few PRs.
 
 But we still have too many of them and not many people reviewing/testing, 
 which makes the process a bit slow.
 

I expect this week to get slow. It's July 4th week end in the US.

And it's a new process.

IMHO there is no problem in being a little slow and having a back log of PRs as 
long as it make releasing faster.

And it will motivate everyone to review.

 From the guys who usually review PRs, who is currently on holidays?
 
 Cheers,
 Wilder
 
 
 On 29 Jun 2015, at 11:27, sebgoa run...@gmail.com wrote:
 
 Ok we are on,
 
 Starting today, commit to master through PR only.
 2 LGTM needed for merge.
 If Travis fails, we can still merge given a good explanation of why (since 
 travis has issues once in a while).
 
 I will keep an eye on commit, at least once a day, and ping the list if I 
 see a commit that went in without a PR.
 
 thanks, let's give this a shot, goal being of course to stabilize master for 
 4.6.
 
 Everyone should start testing master as if it were a release branch now.
 
 -sebastien
 
 
 On Jun 28, 2015, at 9:17 AM, Remi Bergsma r...@remi.nl wrote:
 
 Let’s do it!
 
 Starting tomorrow we’ll commit to master through PR only (as described 
 below), and we’ll evaluate this at Sept 30, 2015. 
 
 I’ll put a reminder in my schedule to start the thread.
 
 Regards,
 Remi
 
 On 26 jun. 2015, at 23:10, Daan Hoogland daan.hoogl...@gmail.com wrote:
 
 date := 2015-09-30 ???
 
 On Fri, Jun 26, 2015 at 9:54 PM, David Nalley da...@gnsa.us wrote:
 On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen run...@gmail.com 
 wrote:
 Folks,
 
 A few of us are in Amsterdam at DevOps days. We are chatting about 
 release management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].
 
 However to get started on the right track. I would like to propose the 
 following easy step:
 
 Starting Monday June 29th (next monday):
 
 - Only commit through PR will land on master (after a minimum of 2 LGTM 
 and green Travis results)
 - Direct commit will be reverted
 - Any committer can merge the PR.
 
 Goal being to start having a new practice -everything through PR for 
 everyone- which is an easy way to gate our own commits building up to a 
 PR.
 
 There is no tooling involved, just human agreement.
 
 cheers,
 
 -Sebastien
 
 In general, +1
 I think we should set a time, say a month or two out, to review how
 well it has worked, and what we need to tweak to make things better. I
 think we should be explicit with this so that we can say 'On $date'
 we'll start a thread to talk about what has and hasn't worked and how
 we can improve this.
 
 --David
 
 
 
 -- 
 Daan
 
 
 

Roadmap

[sebgoa]

Hi,

A note to everyone about the roadmap.

We need to get going on this, add description to items already there, link to 
JIRA and offer to contribute:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap

Please chime in,

thanks,


-sebastien

Re: [PROPOSAL] Commit to master through PR only

[sebgoa]

Ok we are on,

Starting today, commit to master through PR only.
2 LGTM needed for merge.
If Travis fails, we can still merge given a good explanation of why (since 
travis has issues once in a while).

I will keep an eye on commit, at least once a day, and ping the list if I see a 
commit that went in without a PR.

thanks, let's give this a shot, goal being of course to stabilize master for 
4.6.

Everyone should start testing master as if it were a release branch now.

-sebastien


On Jun 28, 2015, at 9:17 AM, Remi Bergsma r...@remi.nl wrote:

 Let’s do it!
 
 Starting tomorrow we’ll commit to master through PR only (as described 
 below), and we’ll evaluate this at Sept 30, 2015. 
 
 I’ll put a reminder in my schedule to start the thread.
 
 Regards,
 Remi
 
 On 26 jun. 2015, at 23:10, Daan Hoogland daan.hoogl...@gmail.com wrote:
 
 date := 2015-09-30 ???
 
 On Fri, Jun 26, 2015 at 9:54 PM, David Nalley da...@gnsa.us wrote:
 On Thu, Jun 25, 2015 at 10:38 AM, Sebastien Goasguen run...@gmail.com 
 wrote:
 Folks,
 
 A few of us are in Amsterdam at DevOps days. We are chatting about release 
 management procedure.
 Remi is working on a set of principles that he will put on the wiki to 
 start a [DISCUSS].
 
 However to get started on the right track. I would like to propose the 
 following easy step:
 
 Starting Monday June 29th (next monday):
 
 - Only commit through PR will land on master (after a minimum of 2 LGTM 
 and green Travis results)
 - Direct commit will be reverted
 - Any committer can merge the PR.
 
 Goal being to start having a new practice -everything through PR for 
 everyone- which is an easy way to gate our own commits building up to a PR.
 
 There is no tooling involved, just human agreement.
 
 cheers,
 
 -Sebastien
 
 In general, +1
 I think we should set a time, say a month or two out, to review how
 well it has worked, and what we need to tweak to make things better. I
 think we should be explicit with this so that we can say 'On $date'
 we'll start a thread to talk about what has and hasn't worked and how
 we can improve this.
 
 --David
 
 
 
 -- 
 Daan
 

Re: 4.6

[sebgoa]

On Jun 22, 2015, at 2:21 PM, Rafael Fonseca rsafons...@gmail.com wrote:

 Hi guys,
 
 I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
 week, it would be nice to get it into 4.6.0, since it's quite a change in
 functional packaging to do it in a minor like 4.6.1 (documentation wise and
 stuff), and i guess 4.7.0 is still far down the road.

Rafael, let me copy Pierre-Yves who talked about this new packaging.

I don't think we should try to put it in 4.6.0, it's too big of change, and 
should really be part of a larger discussion on re-packaging/re-architecture of 
several things.

Hopefully Pyr can chime in.

-sebastien

 Want to hold off on 4.6.0 until that is chopped to pieces and made easy to
 review? Should be able to do it in a couple of days.
 I will also remove the mysql bit for now so there are no conflicting
 opinions, will revisit that issue further down the road.. as someone very
 well versed in Apache licensing explained to me (thanks Leo), we can get
 that done, just not by default and provide a switch to include that
 functionality so that third party rpm/deb distributors (non-Apache) can use
 that. This will also require some classpath changes based on that switch,
 so will think about it later.
 Everyone in agreement with this? I'm sure quite a few people have been
 waiting on it for sometime, so would be nice to include in this release imo
 :)
 
 Cheers,
 Rafael
 
 On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen f...@barred.org wrote:
 
 Hi Seb,
 
 Great way of wording it, and I completely agree! You should be able to
 pick up master and roll it out into production and keep running with it!
 
 Cheers,
 
 Funs
 
 On 11 Jun 2015, at 23:43, Sebastien Goasguen run...@gmail.com wrote:
 
 
 On Jun 11, 2015, at 6:43 PM, John Burwell john.burw...@shapeblue.com
 wrote:
 
 All,
 
 Why are we averse to cutting a release stabilization branch?  In the
 past, we have cut release stabilization branches to ensure that the flow
 contributions was not interrupted.
 
 I disagree.
 
 We have cut branches that way because that’s how Citrix delivers
 software. It develops on master, cuts a branch and put a QA team to work to
 stabilize and make a release.
 
 I believe it’s a broken model for an open source community made of
 mostly volunteers. We don’t have the luxury to QA a release branch and
 loose that effort (because it does not go back to master).
 
 In addition, this process has led to many regression, because there
 is/was a disconnect between the Qa team and the guys developing on master.
 Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
 branch but don’t port it in master.
 
 That’s why we have talked about this at length for almost a year now,
 alas without resolution ( I thought we had, but your email indicates
 otherwise, too bad you did not chime in earlier).
 
 I am advocating for us to stabilize master and gate master. So that
 whenever we release we can do it starting from a stabilized branch. Instead
 of having to reinvest time in lengthy QA.
 
 I want us to be able to release at anytime, when we feel like it and as
 soon as someone says I want this fix/feature that was just merged in
 master. Right no we cannot do that.
 
 So yes call me crazy, I want the developers to take it onto themselves
 to keep their forks in sync with master, develop on their fork. And I want
 master to be the release branch. We will be able to build up a release
 through PR from devs with limited merge conflicts. So that we reach a point
 where master is QA at all time and we don’t loose any investment made in QA.
 
 
 For committers, it is not a big deal since they can manage their
 branches in the cloudstack repo.  However, for non-committers, this freeze
 could cause unnecessary frustration and discourage further contributions.
 
 A freeze means only the RMs will commit on master. any PR from anyone
 welcome and let the discussions happen on whether to merge or not…no
 frustration.
 
 
 
 Thanks,
 -John
 
 
 From: sebgoa run...@gmail.com
 Sent: Wednesday, June 10, 2015 6:33 AM
 To: dev@cloudstack.apache.org
 Subject: Re: 4.6
 
 On Jun 8, 2015, at 11:45 PM, Remi Bergsma r...@remi.nl wrote:
 
 Hi,
 
 I can jump in and work with Rohit and Daan to make 4.6 happen.
 
 +1 for the QA on master. It would be best if we could then all focus
 on stabilizing 4.6 aka master and wait with refactor stuff and new features
 until 4.6 is out, which is the start of 4.7.
 
 On the other hand, building new features in the mean time isn't a big
 issue, as rebasing to a master that gets more stable every day is much
 easier than it is today I'd say. You just cannot merge new stuff until 4.6
 is out.
 
 Let's write down some guidelines and see if this approach makes sense.
 
 
 Maybe that's something that you can do at the meetup today and bring it
 back to the list as a proposal ?
 
 When I talk about freeze I am thinking just letting the RMs commit

Re: 4.6

[sebgoa]

On Jun 22, 2015, at 2:55 PM, Rafael Fonseca rsafons...@gmail.com wrote:

 Hi Sebastien, thx for following up so quickly :)
 
 It's because it's a big change that i think it should be done in a major
 release an not a minor,

We all agree on this. Such as change is for a major release.

The question is 4.6 or 4.7 ...


 nevertheless it will be up to the community to
 decide if we should ship it in 4.6.0 of wait for a long time to have this
 in.
 
 I've been waiting a long time for that larger discussion, the currently
 open PR is already the second proposal to improve packaging and the
 previous one was open for over a month.. so i wonder how long it will take
 to let everyone take advantage of it, since the code is all ready to
 ship... if anyone can see a reason or a fix that might not be what they
 want, i can just amend whatever quickly... but other than the mysql issue,
 i don't know what would conflict with anyone's interest.. though feel free
 to show me otherwise :)
 
 Like i said on the PR, this is still not all the changes i'd like to make
 to get a cleaner packaging config, but whatever aesthetical or maintainer
 helpfulness is still needed to be done, can be done later along the path,
 while providing the functionality earlier to everyone. Even if we
 eventually decide to go for a completely different packaging structure like
 using a proper makefile or something like that, most of the cleanup done in
 this PR will just make that switch easier ;)
 
 For me it will just be a few hours of work to chop it all into pieces and
 explain what each bit does, so just let me know if i should focus on this
 straight away or leave it for later and focus on some more needed fixes not
 related to packaging that everyone should agree to get into releases ASAP.
 

We need to start testing master (a.k.a) 4.6 , identify blockers through testing 
and see what needs to get fixed.
I have not had the time to check JIRA, to see if it's already with a 4.6 
release and if we already have 4.6 blockers.


 Looking forward for Pyr's input on this :)
 

Since he is the one who mentioned this feature, I am hoping he can comment soon 
on it.

-sebastien

 
 On Mon, Jun 22, 2015 at 2:28 PM, sebgoa run...@gmail.com wrote:
 
 
 On Jun 22, 2015, at 2:21 PM, Rafael Fonseca rsafons...@gmail.com wrote:
 
 Hi guys,
 
 I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
 week, it would be nice to get it into 4.6.0, since it's quite a change in
 functional packaging to do it in a minor like 4.6.1 (documentation wise
 and
 stuff), and i guess 4.7.0 is still far down the road.
 
 Rafael, let me copy Pierre-Yves who talked about this new packaging.
 
 I don't think we should try to put it in 4.6.0, it's too big of change,
 and should really be part of a larger discussion on
 re-packaging/re-architecture of several things.
 
 Hopefully Pyr can chime in.
 
 -sebastien
 
 Want to hold off on 4.6.0 until that is chopped to pieces and made easy
 to
 review? Should be able to do it in a couple of days.
 I will also remove the mysql bit for now so there are no conflicting
 opinions, will revisit that issue further down the road.. as someone very
 well versed in Apache licensing explained to me (thanks Leo), we can get
 that done, just not by default and provide a switch to include that
 functionality so that third party rpm/deb distributors (non-Apache) can
 use
 that. This will also require some classpath changes based on that switch,
 so will think about it later.
 Everyone in agreement with this? I'm sure quite a few people have been
 waiting on it for sometime, so would be nice to include in this release
 imo
 :)
 
 Cheers,
 Rafael
 
 On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen f...@barred.org wrote:
 
 Hi Seb,
 
 Great way of wording it, and I completely agree! You should be able to
 pick up master and roll it out into production and keep running with it!
 
 Cheers,
 
 Funs
 
 On 11 Jun 2015, at 23:43, Sebastien Goasguen run...@gmail.com wrote:
 
 
 On Jun 11, 2015, at 6:43 PM, John Burwell john.burw...@shapeblue.com
 
 wrote:
 
 All,
 
 Why are we averse to cutting a release stabilization branch?  In the
 past, we have cut release stabilization branches to ensure that the flow
 contributions was not interrupted.
 
 I disagree.
 
 We have cut branches that way because that’s how Citrix delivers
 software. It develops on master, cuts a branch and put a QA team to
 work to
 stabilize and make a release.
 
 I believe it’s a broken model for an open source community made of
 mostly volunteers. We don’t have the luxury to QA a release branch and
 loose that effort (because it does not go back to master).
 
 In addition, this process has led to many regression, because there
 is/was a disconnect between the Qa team and the guys developing on
 master.
 Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
 branch but don’t port it in master.
 
 That’s why we have talked about this at length for almost

Re: CloudStack Ansible Role

[sebgoa]

On Jun 17, 2015, at 10:18 PM, Milamber milam...@apache.org wrote:

 Hello,
 
 Great idea. I can help.
 
 I already created a playbook for CS+Ubuntu+KVM
 https://github.com/milamberspace/ansible-cloudstack-ubuntu-aio
 
 Some parts can be got from this playbook.
 
 Milamber
 

You (rene) Milamber and Paul, should be able to get something really nice here.

thanks for doing this, exactly the type of stuff we need.

-sebastien

 On 17/06/2015 13:01, Rene Moser wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi
 
 Paul Angus aleady did some efforts of covering installation of
 CloudStack using Ansible in the docs
 http://docs.cloudstack.apache.org/en/master/ansible.html Thanks!
 
 But there are some issues with styling, it has some parts in it which
 are deprecated and the doc might not be the best place for pasting a
 playbook because users have to copy and paste it.
 
 I thought it makes perfectly sense to create a complete, best practice,
 fully tested Ansible role for installing CloudStack.
 
 I created the skeleton in my GitHub account
 https://github.com/resmg/ansible-role-cloudstack.
 
 Role features:
 - --
 - - No hard coupled dependency to other roles (DB installation will be
 optional opt-out to let users use their special roles for galera
 clusters and so forth)
 - - Install and upgrade CloudStack environments(ACS management, DB, KVM
 hosts, XEN hosts, ...)
 - - Fully tested
 - - Debian, Ubuntu and CentOS
 - - Apache License (of course)
 
 Goals:
 - --
 The role can be used in production for managing CloudStack installation
 as well as for testing installations and upgrades.
 
 You will also be able to create docker boxes with help of Ansible's
 docker module and this role.
 
 Further in Ansible 2.0, there are already 16 Ansible CloudStack modules
 for accessing the API. So a fully configured CloudStack environment just
 using Ansible is not far away. This would let us to make deep
 integration testing just a command and few playbooks away.
 
 
 Further:
 - 
 It would be nice if this role would be under the apache GitHub
 namespace to be able to also put it under the apache namespace in
 https://galaxy.ansible.com/ (role index). But we will look into this,
 when it is ready.
 
 Yours
 René
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJVgW/DAAoJEIMGllvm1jMdVRgP/jdX+RVLEWsUvwCQQvuEVU90
 DPCOiMHbeNhXYYCpg27ajqp+RJ9midSb9BHMFT9ZIY9V/J8Mo0AmraoBaWpM5jjB
 YmP3RBBHAt6hLjOQ3NFwS6HUnturYRJEZeyvZIppE38bZLT9dPdpH45/knQisQN/
 j18+3PDu+LfK18v1QCPcUzfE4lOn8VLao5IPQhavkzbTpGLaypWjL4FyKNx8Xt4b
 yEmcwmPMmdFGwDuT27fT1Zsifoq9WLRC1Bz2fYZmHRxtklRtWd8KSMmHXPeAQzf7
 0Dgjto5qwjUSBwYRkI3WCcHnvi6yyqmTmIoWpGjBCshO+9miCtw9JsC4nOxmhjR8
 sZve9T9wwu/wIUS0dXIyLI1fkPIeCMzU5fu44aOz8+IAFWtNPcbjF6wyWWhuTD4Y
 78ThJN3mdhJHiFZfKWdZG20SF/h2m2SWutABjdmSjGOLqT4vms8nqMO6ykkE9rBs
 CFmaiop73jNQ7fbfepUZZAUOTjSu9yWyAQjJzDWJQx8Z5J1yngINywLXYOPBpPU9
 sRxODUjQ+b5Eh1AVyTAtg2Vp5B1TxG2xIILx/gY2XGJqG5eA36qrLTW0DLbkbJgH
 G8akdF2BX/6N2bUOc947fatJ7m4X3dDta8CrhjwtJ+c4eIJGv1jjFCu9Rh+zSGRY
 IWgQdqIIJ8NSajhGM8B4
 =Ni6B
 -END PGP SIGNATURE-
 
 

Re: devopsdays amsterdam

[sebgoa]

I am coming over.


On Jun 17, 2015, at 1:54 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 H,
 
 Who are going, next week?
 
 -- 
 Daan

Re: Third party VR / L2 support

[sebgoa]

On Jun 12, 2015, at 11:13 AM, Christian christ...@bt.net wrote:

 Thank you all for your views and comments. I agree with everything said
 when it is positioned under today’s business-as-usual cloud compute.
 Perhaps I should put some context around my thoughts.
 
 NFV is coming and the world is looking to deliver solid cloud networking
 solutions over the next couple of years. 90% of what I am hearing in this
 area revolves around OpenStack. I’m trying to put the case forward for
 using CloudStack.
 
 Yes, I can use sheer force of will to bend CloudStack into shape. I can
 ignore its insistence on using IP addresses for everything and tap
 straight into VLANs. I can also use kludges to suppress the virtual router
 and remove unwelcome DHCP services. However, I have to declare that I am
 doing these things when I present the case for CloudStack and this weakens
 my argument.
 
 There are some quick wins here that would help greatly in positioning
 CloudStack as a contender for running virtualised network appliances.
 Having a checkbox that flags a virtual network as Layer 2 (no IP
 addresses) would be one of them. Officially supporting a ‘No virtual
 router’ option within a Network Offering would be another.
 

Christian, I totally agree with you.
I was on the OPNFV mailing list couple months back and openstack was the only 
game in town.

So how do we get those quick wins going ?
Do you have code to make it happen and are looking for guidance to put them in 
the source ?
If you have to code for it, I can show you how to contribute it.

Or are you looking for other devs to do it ?

A starting point might be to describe those quick wins in a bit more details on 
the wiki as a Feature request:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home

If you create an account I can give you the writes to create a page.

Let's keep this conversation going.

thanks,

-sebastien

 I appreciate that offering third-party virtual routers as an alternative
 is not so straightforward, although this seems to be gaining more support
 than the ‘quick wins’. Maybe I am underestimating the development effort
 involved with the L2 asks?
 
 Cheers
 -Christian
 
 
 On 12/06/2015 05:57, Koushik Das koushik@citrix.com wrote:
 
 Agree to what Funs mentioned. The current network service model is
 flexible, there is option to select a provider for a given service by
 means of network offering.
 About using 3rd party VR, there are 2 possibilities:
 - Fully replace the existing VR with 3rd party VR
 - Both co-exist and complement each other
 
 CS manages the lifecycle of VR. For 3rd party (especially virtual
 appliances), it needs to be decided what is the best way to manage
 lifecycle. If CS is able to manage the lifecycle then it can be similar
 to existing VR (spinning up instances when required). If managed
 externally, then a pre-created pool of appliances needs to be registered
 from CS and used.
 
 -Koushik
 
 -Original Message-
 From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs
 Kessen
 Sent: Tuesday, June 09, 2015 3:26 PM
 To: dev@cloudstack.apache.org
 Subject: Re: Third party VR / L2 support
 
 Hi Christian and Paul,
 
 I agree that the VR/VPC construct could do with some improvements, the
 biggest being that it should actually be api driven and allow for more
 flexible networking/services combined with scale out itself (we’re
 looking into this actually). All of these things bring along their own
 problems and should be tackled piece by piece, if we’d want to be
 efficient we should first blot out the API and then start pushing
 services in, which is difficult at the speed it is moving at.
 
 The driver model in Cloudstack already supports the decoupling of
 services via network service providers (plugins) and ties in with the
 way the “network service offerings work with service capabilities and
 supported services. At SBP we use NSX-mh for the service
 “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port
 Forwarding” to this for NSX if we want to, but decided to leave that in
 the VR back then as these services were rather new in NSX. My point being
 that you can already mix and match things and are not stuck with the
 VR/VPC, and you can actually use devices on that level if need be, if you
 create the service offerings for them.
 At the moment anyone can already create a plugin that exposes a single
 functionality or multiple, and expose that as a service that is offered,
 examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX
 and Nuage. I’m not saying it’s simple or easy, but if you know the API of
 what you want to integrate with you can.
 The construction of the plugin module has its own unique challenges, and
 I agree with John Burwell (Shape Blue) and Paul that we need to change
 the way this all hangs together if we want more flexibility and ease of
 integration in the future.
 
 BGP is brought in for use with IPv6,  the first code for that has 

Re: 4.6

[sebgoa]

On Jun 8, 2015, at 11:45 PM, Remi Bergsma r...@remi.nl wrote:

 Hi,
 
 I can jump in and work with Rohit and Daan to make 4.6 happen.
 
 +1 for the QA on master. It would be best if we could then all focus on 
 stabilizing 4.6 aka master and wait with refactor stuff and new features 
 until 4.6 is out, which is the start of 4.7. 
 
 On the other hand, building new features in the mean time isn't a big issue, 
 as rebasing to a master that gets more stable every day is much easier than 
 it is today I'd say. You just cannot merge new stuff until 4.6 is out. 
 
 Let's write down some guidelines and see if this approach makes sense. 
 

Maybe that's something that you can do at the meetup today and bring it back to 
the list as a proposal ?

When I talk about freeze I am thinking just letting the RMs commit on master, 
everyone who wants something in 4.6 should submit a PR.



 Regards, Remi 
 
 On 08 Jun 2015, at 21:43, Sebastien Goasguen run...@gmail.com wrote:
 
 Folks,
 
 We need to freeze 4.6 asap.
 
 I originally agreed to RM 4.6 and Daan also stepped up.
 
 But I would like to work on doing a release of ec2stack and gcestack, so I 
 will step down from 4.6 RM.
 
 Anybody wants to jump in.
 
 There is already a ton of things in 4.6 and we need to release.
 
 Ideally we also need to QA directly on master, so that we can build 4.7 on 
 top of a stable release.
 
 
 -sebastien

[UPDATE] 2015 progress

[sebgoa]

Hi folks,

Couple months ago I shared a few thoughts for 2015 [1], things that we could do 
to make our project even greater.
There has been good progress, so I would like to share a few updates.

1- Review board.
We are no longer using review board, all code contributions should now come as 
github pull requests.
This is proving to be very successful. We have closed 248 pull requests and 
have 12 currently open.
This does not count the commits that come in directly into the source.
Let's keep it coming.

2- AWSAPI
We removed the AWSAPI code that was in our source. It consisted of a lot of 
auto-generated code and increased
our number of lines of code quite a bit. This is going to make our build and 
our packaging easier.

3- ec2stack and gcestack
Those two packages are now official CloudStack subproject. They are hosted on 
Apache git infrastructure and mirrored on github [2][3].
We are accepting pull requests the same way than our standard source.
These are python packages, and represent a good entry point for Python 
programmers.
Next is to actually do an official release of these two API interfaces.

4-Ansible
The ansible cloudstack module from Rene Moser is being merged in as a core 
Ansible module.
Expect it in Ansible 2.0

5-New docs theme
Our documentation has a new documentation theme [4] thanks to Pierre-Luc Dion.
There is still a lot to do here, see [1] for low hanging fruits in this area.

6-CloudStack days
Our CloudStack days kicked off in Austin.
The Tokyo day will be on June 2nd [5] and the schedule should be up shortly.
The call for papers are open for Seattle [6] on August 20th and Dublin on 
October 8-9 [7]
We also have a London meet up this week [11] and in June we will have one in 
Amsterdam.
The Dublin event will be a two day event with an off-site hackathon.
Submit your talks early so we can plan a great program.
Sponsor so we can have a great conference.
Register so we can all meet face to face.

7-Website
The website has been moved to git, instead of the old svn based apache content 
management system.
It is mirrored on github [8] and we can accept pull requests for modification.
The website now uses middleman for build system.
There is also tons to do there, we should come up with a new slick modern 
design.

In terms of code, 4.5.1 has been released [10] which contains some great 
plugins like Nuage SDN, SAML 2.0 and Globo DNS.

With Apache getting more resources from TravisCI, we are now able to run more 
integration tests for every commit and we are going to try a new release 
process for 4.6.
We all continue to strive to make CloudStack even more rock solid than it is 
now, and making it a snap to release our code. So do chime in on the 
dev@cloudstack.apache.org if you want to help with hardening and extending 
CloudStack.

If you are not a developer, do have a look at [1], a lot of those items fall in 
the JFDI [9] category. Finishing up some of those will greatly help the +2000 
people on these lists.

Personally I see all this as great progress and focus, let's keep it up.

Cheers,

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/2015+Plan
[2] https://github.com/apache/cloudstack-ec2stack
[3] https://github.com/apache/cloudstack-gcestack
[4] http://docs.cloudstack.apache.org
[5] http://events.linuxfoundation.org/events/cloudstack-tokyo
[6] http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp
[7] 
http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe
[8] https://github.com/apache/cloudstack-www
[9] http://www.urbandictionary.com/define.php?term=JFDI
[10] 
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.1/
[11] 
http://www.eventbrite.co.uk/e/cloudstack-european-user-group-tickets-16282793273?aff=erelexporg


-Sebastien Goasguen
VP Apache CloudStack

Re: [DISCUSS] 4.6 release management

[sebgoa]

On May 13, 2015, at 6:07 PM, David Nalley da...@gnsa.us wrote:

 On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
 wrodrig...@schubergphilis.com wrote:
 Hi guys,
 
 I hope that’s not too late to react on this one.
 
 Having 6 RMs seems a bit too much for me. For PRs containing a few lines of 
 code, just bug fixes or changing maven files, python, sh, etc it might be 
 simple and quick. However, if we get a PR with +30 commits and 10k lines 
 added, it gets really difficult to get the community to test/review the PR. 
 So, for 2 people to go over it is already taking too long to get the code 
 imagine, now imagine 4 or 6.
 
 Rohit has done an excellent job in looking into the PRs, commenting on them 
 and some times testing as well. But there are things that cannot simply get 
 him, or perhaps other guys, to test properly a PR; having time and 
 environment as the main reasons.
 
 I would say that in case we have a PR that contains:
 
 1. Documentation on the Apache CS Wiki
 2. Unit Tests (a lot of them, minimum 70% for the code changed)
 3. Marvin Test Results report - test_routers, test_vpc_routers, 
 test_vm_life_cycle, test_account, at least.
 
 Should be given priority and get less RMs involved in order to speed up our 
 development/release processes. Unless, of course, the people would have time 
 to look into the PR immediately.
 
 What do you think?
 
 Cheers,
 Wilder
 
 
 
 I like this.
 We have to live by our tests. So enforcing good coverage, and gating
 on good results makes sense to me.
 No human can reliably eyeball all of this.
 
 --David

I don't think we are saying anything different to this.

Any PR should pass the Travis tests (…and there should be more tests).
Review should not allow anything that does not have unit test either.
For new features, they should come with documentation patches as well.

bottom line, I don't think we disagree. Or maybe I missing something.

-sebastien

Re: [WWW] Website now managed via Git

[sebgoa]

On May 13, 2015, at 9:37 AM, Jan-Arve Nygård jan.arve.nyg...@gmail.com wrote:

 I created a PR to add committers that fell out of the list during the move.
 I'm not sure if you want non committers to build with middleman and then do
 a PR so i just created a PR against the source for the next build until
 instructions are ready.
 

Merged.

Thanks a lot.

Feel free to improve the site ….it needs love :)


 2015-05-12 12:48 GMT+02:00 Rohit Yadav rohit.ya...@shapeblue.com:
 
 
 On 12-May-2015, at 12:15 pm, Erik Weber terbol...@gmail.com wrote:
 
 No problem, I read it in the README :-)
 
 I should do that too ;)
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +91 88 262 30892 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Build
 http://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software Engineering
 http://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure Support
 http://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training Courses
 http://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended
 solely for the use of the individual to whom it is addressed. Any views or
 opinions expressed are solely those of the author and do not necessarily
 represent those of Shape Blue Ltd or related companies. If you are not the
 intended recipient of this email, you must neither take any action based
 upon its contents, nor copy or show it to anyone. Please contact the sender
 if you believe you have received this email in error. Shape Blue Ltd is a
 company incorporated in England  Wales. ShapeBlue Services India LLP is a
 company incorporated in India and is operated under license from Shape Blue
 Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
 and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
 a company registered by The Republic of South Africa and is traded under
 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
 

docker machine driver for cloudstack

[sebgoa]

Folks,

The exoscale driver was recently merged in Docker machine.

There is an oustdanding pull request for a more generic cloudstack driver:

https://github.com/docker/machine/pull/425#issuecomment-101440493

Sander who originally made the PR has no cycles right now to finish it.

So that's an open door for someone to step in, write some Go and get cloudstack 
supported in Docker machine.

Exciting stuff….

-Sebastien

[WWW] Website now managed via Git

[sebgoa]

Hi folks,

Our website is now managed via Git.
The build is now using Middleman [1] instead of the Apache CMS.

The source of truth for the site is at:

https://git-wip-us.apache.org/repos/asf?p=cloudstack-www.git;a=summary

It is mirrored on GitHub like all our other repos and we can accept pull 
request as well:

https://github.com/apache/cloudstack-www

FAQ:
-

1- Why middleman ?
Because it took me 30 minutes to move from the Apache CMS to a successful 
middleman build.

2- What's left to do ?
-Improve README for build instructions
-Put all license headers where they should be
-Improve file tree. I put everything flat
-Put in github PR instructions
-delete the wiki page [2]
-work on new Web design.

3-How can I help ?
-Clone via GitHub
-Work on your changes and submit a github pull request

[1] https://middlemanapp.com
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Managing+the+Apache+CloudStack+Web+Site

-Sebastien

Re: API guide link getting an error...

[sebgoa]

same issue that Abhi reported,

fixed


On May 12, 2015, at 9:26 AM, Raja Pullela raja.pull...@citrix.com wrote:

 Hi,
 
 Not found error is seen for the link - 
 http://cloudstack.apache.org/docs/api/
 I do know that the documentation has moved to 
 http://docs.cloudstack.apache.org/en/master/index.html
 but the API guide references are pointing to the link mentioned above which 
 is getting an error.
 
 Raja

Re: [DISCUSS] 4.6 release management

[sebgoa]

On May 6, 2015, at 10:59 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 I can have a look at the merge of 4.5.1 and am willing to be one of the
 RMs, not to be the RM!
 

I can RM as well. 

How about we lock down master on wednesday ?
From that point forward we only take PR into master -either you or me- all 
other direct commits to master will be reverted 


-sebastien



 Op wo 6 mei 2015 om 09:47 schreef sebgoa run...@gmail.com:
 
 So no -1 on this.
 
 Do we have volunteers to RM 4.6 on the master branch ?
 
 I propose to set a date asap, tag master and tell everyone that starting
 from that tag all commits to master except from RM will be reverted.
 
 will need to make sure that all of 4.5.1 is in master
 
 -sebastien
 
 
 On May 1, 2015, at 1:19 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
 
 Let's not do more quality improvement proces but just improve quality. If
 anybody want to add to the pages on the wiki, you're welkom but nobody
 did
 for long time. +1 for the present state of Sebastien's views on things.
 We
 can refine at any time.
 
 Op vr 1 mei 2015 om 09:55 schreef sebgoa run...@gmail.com:
 
 
 On May 1, 2015, at 12:52 AM, Pierre-Luc Dion pdion...@apache.org
 wrote:
 
 Hi,
 
 In my mind it was kind of making more sense to start by keeping 4.6
 into
 a
 separate branch, enforce pull-requests and deploy the CI. smaller step
 but
 faster result, and from there, once we get stable with the CI
 
 I hear you.
 
 But we have waited for way too long for better CI. I see great efforts
 in
 that direction.
 But I personally do not want to wait any longer to make a move.
 
 We do open source, we should have fun, take risks, move fast, fail fast,
 recover etc….
 
 so let's JFDI
 
 and git flow;
 move into master, do fastest releases cycle. If we consider we can do
 all
 that starting in 4.6, I'm all for it!
 
 
 Is there really a difference between creating a 4.6 and doing what you
 say, and tagging master (start) and doing it on master leading to 4.6
 release ?
 
 Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
 can improve a bit on the QA then we win.
 Plus I think a different commit model will help a lot in quality.
 
 
 Marcus: are you preparing a proposal on this? wiki page? I can help
 
 
 We can do this proposal on email..and once we have consensus write it up
 for archive in the wiki.
 If we move to the wiki now, this effort is going to die.
 
 Seb: doesn't the vote would confirm the consensus?
 
 
 if we have consensus no need for vote.
 
 Raja:  do we have any documentation somewhere on how to use, contribute
 to
 the smoke test? that could be our start for the CI tests?
 
 
 Cheers
 
 
 On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen run...@gmail.com
 wrote:
 
 
 On Apr 29, 2015, at 9:49 PM, Marcus shadow...@gmail.com wrote:
 
 After reviewing the history as mentioned by Daan, unless we propose
 and vote on a newer workflow model I think the best we can do is to
 simply be more strict about commits to master. They all need to be
 merges that have been tested against master before merge. This will
 in
 theory make master more stable, but doesn't really change the
 workflow
 we've already agreed upon and have been working under (although
 bugfixes sometimes were not coming in from branches, and
 cherry-picked
 bugfixes from branches will need to go into a branch first, tested
 against master, and merged to master). We can essentially set a date
 and do that any time, with some advance notice that direct commits
 will be reverted.
 
 Yes +1.
 
 -Set a date
 -Tag master for reference
 -Find a volunteer or two to RM master
 -automatic revert on master if not from RM
 -all commits to master come from PR, need clear review and green tests
 -harden master (basic QA process), release 4.6 as a tag on master
 -all features and fixes need to be made on branches or forks and onus
 is
 on devs to rebase to master
 -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
 4.4,
 etc)
 -from there forward only maintain a linear release through master
 
 Feel free to add, tweak
 
 PS: No need to vote if we have consensus. Taking a clue from ASF
 members,
 votes should be avoided at all cost, they mean that we do not have
 clear
 consensus.
 
 
 
 On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen 
 run...@gmail.com
 
 wrote:
 
 On Apr 18, 2015, at 8:36 AM, Marcus shadow...@gmail.com wrote:
 
 Have they diverged that much? Due to cherry-picking, I guess.
 Otherwise you should be able to do it cleanly.
 
 There's a good opportunity to do this next release. Instead of
 creating a release branch, we freeze master and start creating dev
 branches.
 
 +1
 
 This just amounts to treating master now like a release branch.
 Getting
 back to PL suggestion, that means
 that any commit to master would be through a PR or MERGE request on
 the
 ML. Anything else will be reverted by the RM.
 
 Marcus, do you feel like writing down a little process for this and
 some

Re: [DISCUSS] 4.5.1 announcement draft

[sebgoa]

Rohit, looks good to me

On May 11, 2015, at 9:03 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote:

 Hi all,
 
 If the following announcement (draft) is alright, I would like to send it out 
 later today or tomorrow. Please review, thanks.
 
 Sally - can you too please have a look. Thanks.
 
 On 08-May-2015, at 4:37 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote:
 
 # Draft starts 
 
 Apache CloudStack is open source software designed to deploy and manage 
 large networks of virtual machines, as a highly available, highly scalable 
 Infrastructure as a Service (IaaS) cloud computing platform. CloudStack is 
 used by a number of service providers to offer public cloud services, and by 
 many companies to provide an on-premises (private) cloud offering, or as 
 part of a hybrid cloud solution. CloudStack became an Apache Top-level 
 Project (TLP) in March 2013.
 
 The Apache CloudStack project is pleased to announce the 4.5.1 release of 
 the CloudStack, the cloud orchestration platform. The 4.5.1 release contains 
 more than 500 bug fixes since the 4.4 release and represents over six months 
 of work from the Apache CloudStack community with new and improved features.
 
 # Documentation
 
 What’s new in CloudStack 4.5:
 http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.1/about.html
 
 The 4.5.1 release notes includes full list of corrected issues as well as 
 upgrade instructions from previous versions of Apache CloudStack. Please see 
 the Release Notes for a full list of corrected issues and upgrade 
 instructions:
 
 http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.5.1/
 
 The official installation, administration and API documentation for each 
 release are available on our Documentation Page.
 
 http://docs.cloudstack.apache.org/
 
 # Downloads
 
 The official source code for the 4.5.1 release can be downloaded from our 
 Downloads Page.
 
 http://cloudstack.apache.org/downloads.html
 
 # Availability and Oversight
 
 As with all Apache products, Apache CloudStack v4.5.1 is released under the 
 Apache License v2.0, and is overseen by a self-selected team of active 
 contributors to the project. A Project Management Committee (PMC) guides the 
 Project’s day-to-day operations, including community development and product 
 releases. For documentation and to learn how to join and contribute to the 
 Apache CloudStack community please visit our website: 
 http://cloudstack.apache.org
 
 For additional marketing or communications information, please contact the 
 marketing mailing list: market...@cloudstack.apache.org
 
 Join members of the Apache CloudStack community at the CloudStack 
 Collaboration Conference, taking place 8-9 October 2015 in Dublin, Ireland. 
 For more information, visit 
 http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe
 
 # About The Apache Software Foundation (ASF)
 
 Established in 1999, the all-volunteer Foundation oversees more than one 
 hundred and seventy leading Open Source projects, including Apache HTTP 
 Server --the world's most popular Web server software. Through the ASF's 
 meritocratic process known as The Apache Way, more than 400 individual 
 Members and 3,500 Committers successfully collaborate to develop freely 
 available enterprise-grade software, benefiting millions of users worldwide: 
 thousands of software solutions are distributed under the Apache License; 
 and the community actively participates in ASF mailing lists, mentoring 
 initiatives, and ApacheCon, the Foundation's official user conference, 
 trainings, and expo. The ASF is a US 501(c)(3) charitable organization, 
 funded by individual donations and corporate sponsors including Budget 
 Direct, Citrix, Cloudera, Comcast, Facebook, Google, Hortonworks, HP, 
 Huawei, IBM, InMotion Hosting, Matt Mullenweg, Microsoft, Pivotal, Produban, 
 WANdisco, and Yahoo.
 
 For more information, visit http://www.apache.org/ or follow @TheASF on 
 Twitter.
 
 Apache, CloudStack, Apache CloudStack, and ApacheCon are trademarks 
 of The Apache Software Foundation. All other brands and trademarks are the 
 property of their respective owners.
 
  Draft ends #
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +91 88 262 30892 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and 

[ANNOUNCE] New Committer Marco Sinhoreli

[sebgoa]

It seems we forgot to announce that Marco was made a committer, my sincere 
apologies
-

The Project Management Committee (PMC) for Apache CloudStack
has asked Marco Sinhoreli  to become a committer and we are pleased to
announce that he has accepted.

Marco has done an outstanding job building the CloudStack community in Brazil.

Parabéns por um trabalho bem feito e espero que você vai continuar a apoiar a 
comunidade da maneira que você tem feito até agora.

Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch
submission process. Whether contributions are development-related or
otherwise, it is a recognition of a contributor's participation in the
project and commitment to the project and the Apache Way.

Please join me in congratulating Marco !

--Sebastien Goasguen
on behalf of the CloudStack PMC



O Comité de Gestão do Projeto (PMC) para Apache CloudStack
pediu Marco Sinhoreli para se tornar um committer e temos o prazer de
anunciar que ele aceitou.

Marco tem feito um trabalho notável construção da comunidade CloudStack no 
Brasil.

Parabéns Por Um Trabalho Bem Feito e espero Que Voce vai continuar 'uma APOIAR 
a Comunidade da Maneira Que rápido Você tem Feito Até ágora.

Sendo um committer permite que muitos colaboradores a contribuir mais
autonomamente. Para os desenvolvedores, torna-se mais fácil de submeter as 
alterações e
elimina a necessidade de ter contribuições avaliação via o patch
processo de submissão. Se as contribuições são relacionadas com desenvolvimento 
ou
caso contrário, é um reconhecimento da participação de um contribuinte no
projeto e compromisso com o projeto eo Caminho Apache.

Por favor, se juntar a mim para parabenizar Marco

--Sebastien Goasguen
em nome da CloudStack PMC



项目管理委员会（PMC）为Apache的CloudStack
已要求马可Sinhoreli变成提交，我们很高兴地
宣布，他已经接受了。

马可已经做了出色的工作在建设社区的CloudStack在巴西。

在工作祝贺做得好，希望您能继续支持社区，你目前所做的方式。

作为一个提交允许许多贡献者作出更大的贡献
自主。对于开发人员来说，它可以更容易地提交更改和
消除了需要具有贡献经由补丁审查
提交过程。是否捐款是发展相关或
否则，它是一种认可，在一个贡献者的参与
项目与承诺项目和Apache的方式。

请和我一起祝贺马可

--Sebastien Goasguen
代PMC的CloudStack的



ApacheのCloudStackのためのプロジェクト管理委員会（PMC）
コミッタになるためにマルコSinhoreliに尋ねた、私たちはに満足しているしています
彼が承認したことを発表しました。

マルコは、ブラジルのCloudStackのコミュニティを構築する優れた仕事をしています。

仕事おめでとうはよくやった、あなたがこれまで行ってきた方法でコミュニティを支援していきます願っています。

コミッターであることは多くの貢献者が多くを貢献することができます
自律的。開発者にとっては、それはそれが簡単に変更を提出することになり、
パッチ経由の口コミ貢献を持ってする必要がなくなります
提出プロセス。貢献は、開発に関連しているかどうか
それ以外の場合は、中の寄稿者の参加の認識があります
プロジェクトとプロジェクトとApacheの道へのコミットメント。

マルコの祝福の中で私に参加してください

--Sebastien Goasguen
CloudStackのPMCの代わりに

Re: Publishing on website?

[sebgoa]

On May 11, 2015, at 6:29 PM, Sebastien Goasguen run...@gmail.com wrote:

 
 On May 11, 2015, at 4:59 PM, David Nalley da...@gnsa.us wrote:
 
 So - you can now have git based websites [1]
 
 Those websites will publish as soon as something hits the git repo in
 the proper branch. Note, that it won't build for you, like GH does -
 but presumably you are using middleman to build - so build locally,
 commit changes and woot, you published.
 
 [1] https://blogs.apache.org/infra/entry/git_based_websites_available
 
 
 David, I will buy you one month supply of club soda for this email :)
 
 Thank you, this is christmas. 
 
 I submitted a ticket to migrate, will update everyone once its done.


For the impatient:

https://git-wip-us.apache.org/repos/asf/cloudstack-www.git

More tomorrow, once github mirroring has synced.

but BTW it's live now…no more apache CMS and SVN….time for a beer !


 
 On Mon, May 11, 2015 at 8:28 AM, Sebastien Goasguen run...@gmail.com wrote:
 
 On May 11, 2015, at 2:08 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote:
 
 Hi all,
 
 How do I publish changes on our project website, cloudstack.apache.org? I 
 pushed changes on gh-pages already, the cms.apache.org/cloudstack checkout 
 looks older. Any additional build steps to make it live?
 
 
 I replied to u privately but for the benefit of everyone:
 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Managing+the+Apache+CloudStack+Web+Site
 
 -the gh-pages is a WIP, it cannot be used for cloudstack due to SSL certs 
 etc, I need to circle back with David on this.
 -But the html pages that are there are built with middleman which I did put 
 in svn
 https://svn.apache.org/repos/asf/cloudstack/site/middleman/
 
 *but* the middleman site is not yet what is used for the production site. 
 So you need to check out:
 
 https://svn.apache.org/repos/asf/cloudstack/site/trunk/
 
 This is the source of truth and follow the wiki to make changes.
 
 Ideally of course, we would use middleman and a webhoook to automatically 
 push the built pages to github and host everything there…but...
 
 Any help welcome !
 
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +91 88 262 30892 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  
 Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Shape Blue Ltd or related companies. If you are not the 
 intended recipient of this email, you must neither take any action based 
 upon its contents, nor copy or show it to anyone. Please contact the 
 sender if you believe you have received this email in error. Shape Blue 
 Ltd is a company incorporated in England  Wales. ShapeBlue Services India 
 LLP is a company incorporated in India and is operated under license from 
 Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
 incorporated in Brasil and is operated under license from Shape Blue Ltd. 
 ShapeBlue SA Pty Ltd is a company registered by The Republic of South 
 Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a 
 registered trademark.
 
 

Re: [DISCUSS] 4.6 release management

[sebgoa]

So no -1 on this.

Do we have volunteers to RM 4.6 on the master branch ?

I propose to set a date asap, tag master and tell everyone that starting from 
that tag all commits to master except from RM will be reverted.

will need to make sure that all of 4.5.1 is in master 

-sebastien


On May 1, 2015, at 1:19 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:

 Let's not do more quality improvement proces but just improve quality. If
 anybody want to add to the pages on the wiki, you're welkom but nobody did
 for long time. +1 for the present state of Sebastien's views on things. We
 can refine at any time.
 
 Op vr 1 mei 2015 om 09:55 schreef sebgoa run...@gmail.com:
 
 
 On May 1, 2015, at 12:52 AM, Pierre-Luc Dion pdion...@apache.org wrote:
 
 Hi,
 
 In my mind it was kind of making more sense to start by keeping 4.6 into
 a
 separate branch, enforce pull-requests and deploy the CI. smaller step
 but
 faster result, and from there, once we get stable with the CI
 
 I hear you.
 
 But we have waited for way too long for better CI. I see great efforts in
 that direction.
 But I personally do not want to wait any longer to make a move.
 
 We do open source, we should have fun, take risks, move fast, fail fast,
 recover etc….
 
 so let's JFDI
 
 and git flow;
 move into master, do fastest releases cycle. If we consider we can do all
 that starting in 4.6, I'm all for it!
 
 
 Is there really a difference between creating a 4.6 and doing what you
 say, and tagging master (start) and doing it on master leading to 4.6
 release ?
 
 Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
 can improve a bit on the QA then we win.
 Plus I think a different commit model will help a lot in quality.
 
 
 Marcus: are you preparing a proposal on this? wiki page? I can help
 
 
 We can do this proposal on email..and once we have consensus write it up
 for archive in the wiki.
 If we move to the wiki now, this effort is going to die.
 
 Seb: doesn't the vote would confirm the consensus?
 
 
 if we have consensus no need for vote.
 
 Raja:  do we have any documentation somewhere on how to use, contribute
 to
 the smoke test? that could be our start for the CI tests?
 
 
 Cheers
 
 
 On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen run...@gmail.com
 wrote:
 
 
 On Apr 29, 2015, at 9:49 PM, Marcus shadow...@gmail.com wrote:
 
 After reviewing the history as mentioned by Daan, unless we propose
 and vote on a newer workflow model I think the best we can do is to
 simply be more strict about commits to master. They all need to be
 merges that have been tested against master before merge. This will in
 theory make master more stable, but doesn't really change the workflow
 we've already agreed upon and have been working under (although
 bugfixes sometimes were not coming in from branches, and cherry-picked
 bugfixes from branches will need to go into a branch first, tested
 against master, and merged to master). We can essentially set a date
 and do that any time, with some advance notice that direct commits
 will be reverted.
 
 Yes +1.
 
 -Set a date
 -Tag master for reference
 -Find a volunteer or two to RM master
 -automatic revert on master if not from RM
 -all commits to master come from PR, need clear review and green tests
 -harden master (basic QA process), release 4.6 as a tag on master
 -all features and fixes need to be made on branches or forks and onus is
 on devs to rebase to master
 -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
 4.4,
 etc)
 -from there forward only maintain a linear release through master
 
 Feel free to add, tweak
 
 PS: No need to vote if we have consensus. Taking a clue from ASF
 members,
 votes should be avoided at all cost, they mean that we do not have clear
 consensus.
 
 
 
 On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen run...@gmail.com
 
 wrote:
 
 On Apr 18, 2015, at 8:36 AM, Marcus shadow...@gmail.com wrote:
 
 Have they diverged that much? Due to cherry-picking, I guess.
 Otherwise you should be able to do it cleanly.
 
 There's a good opportunity to do this next release. Instead of
 creating a release branch, we freeze master and start creating dev
 branches.
 
 +1
 
 This just amounts to treating master now like a release branch.
 Getting
 back to PL suggestion, that means
 that any commit to master would be through a PR or MERGE request on
 the
 ML. Anything else will be reverted by the RM.
 
 Marcus, do you feel like writing down a little process for this and
 some dates that we can target.
 It would be nice to do this for 4.6.
 
 
 On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland 
 daan.hoogl...@gmail.com wrote:
 We heavily invested in code now on master. Not looking forward to
 backporting that.
 
 mobile dev with bilingual spelling checker used (read at your own
 risk)
 Op 17 apr. 2015 21:02 schreef Marcus shadow...@gmail.com:
 
 Well, would we just swap the last release branch with master?
 Master
 is the dev branch

Re: [VOTE] Apache Cloudstack 4.5.1

[sebgoa]

On May 6, 2015, at 9:38 AM, Vadim Kimlaychuk vadim.kimlayc...@elion.ee wrote:

 Hi,
 
   I am sorry for not being authorized to vote for release,


Everyone can VOTE on a release, you don't need to be a committer. 
The entire community can vote and chime in on the VOTE threads and help test
This is very important .

 but it seems VPC is not working at 4.5.1.  I have 4.5-RC20150407T1726 at 
 production and using VPC is very limited. I am not able to use 2 NICs from 
 different tiers  at the same VM.  Look for detatiled problem desctiption at 
 user list under subject VPC usage scenario
 

Did you report bugs ? 

 Regards,
 
 Vadim.
 
 -Original Message-
 From: Geoff Higginbottom [mailto:geoff.higginbot...@shapeblue.com] 
 Sent: Wednesday, May 06, 2015 10:21 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [VOTE] Apache Cloudstack 4.5.1
 
 I¹m a -0 for now (testing still  on going)
 
 I have upgraded a 4.3.1 Adv XenServer build, and a 4.4.2 Adv XenServer build. 
  In both cases the upgrade was successful, all System VMs and VRs upgraded 
 OK, however I was not able to create any new VRs or System VMs.
 
 We are still analysing the logs and this may well turn out to be a -1, but it 
 could simply be an issue with the system vm template etc hence the -0 for now
 
 Still need to test a local storage build, and a Basic with Security Groups 
 build, in for a busy week!
 
 Regards
 
 Geoff Higginbottom
 CTO / Cloud Architect
 
 D: +44 20 3603 0542 tel:+442036030542 | S: +44 20 3603 0540 
 tel:+442036030540 | M: +447968161581 tel:+447968161581
 
 geoff.higginbot...@shapeblue.com | www.shapeblue.com 
 htp://www.shapeblue.com/ | Twitter:@cloudstackguru 
 https://twitter.com/#!/cloudstackguru
 
 ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS 
 x-apple-data-detectors://5
 
 
 
 
 On 06/05/2015 05:57, Marcus shadow...@gmail.com wrote:
 
 +1 (binding)
 On May 5, 2015 10:26 AM, David Nalley da...@gnsa.us wrote:
 
 Thanks for running with this Rohit.
 
 +1 (binding)
 
 On Mon, May 4, 2015 at 7:20 AM, Rohit Yadav bhais...@apache.org wrote:
 Hi All,
 
 I've created a 4.5.1 release, with the following artifacts up for a
 vote:
 
 Git Branch and Commit SH:
 
 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
 ref
 s/heads/4.5
 Commit: 0eb4eb23701f0c6fec8bd5461cd9aa9f92c9576d
 
 List of changes:
 
 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;
 f=C
 HANGES.md;hb=4.5
 https://github.com/apache/cloudstack/commits/4.5-RC20150504T1217
 
 Source release (checksums and signatures are available at the same
 location):
 https://dist.apache.org/repos/dist/dev/cloudstack/4.5.1/
 
 PGP release keys (signed using 0EE3D884):
 https://dist.apache.org/repos/dist/release/cloudstack/KEYS
 
 Vote will be open for 72 hours.
 
 For sanity in tallying the vote, can PMC members please be sure to 
 indicate (binding) with their vote?
 
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 For convenience of testing, you may use the following repositories 
 and location to download systemvm templates:
 
 http://packages.shapeblue.com/cloudstack/testing/
 http://packages.shapeblue.com/systemvmtemplate/4.5/
 
 Regards.
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Shape Blue Ltd or related companies. If you are not the 
 intended recipient of this email, you must neither take any action based upon 
 its contents, nor copy or show it to anyone. Please contact the sender if you 
 believe you have received this email in error. Shape Blue Ltd is a company 
 incorporated in England  Wales. ShapeBlue Services India LLP is a company 
 incorporated in India and is operated under license from Shape Blue Ltd. 
 Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
 operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
 registered by The Republic of South Africa and is traded under license from 
 Shape Blue Ltd. ShapeBlue is a registered trademark.

[DONE] IP clearance for ec2stack and gstack has passed

[sebgoa]

Folks,

Git repos have been created and the github mirrors are in place.
ec2stack and gcestack are now official CloudStack subproject

https://github.com/apache/cloudstack-ec2stack
https://github.com/apache/cloudstack-gcestack

We just need to create two releases for these.
Note that while ec2stack should still work, I know that gcestack may need some 
dev work to get it up to speed with the latest GCE API.

These are Python apps, so Python lovers should feel free and super excited to 
be able to contribute to CloudStack via those sub projects.

Have at it, Energize !!!

-sebastien

On May 3, 2015, at 3:05 AM, Ian Duffy i...@ianduffy.ie wrote:

 Awesome! Great to her Sebastien.
 
 On 2 May 2015 at 23:00, Rohit Yadav rohit.ya...@shapeblue.com wrote:
 That’s good news. The other day I was trying to setup ec2stack for someone 
 and its users were skeptic in using ec2stack because it was not a ACS 
 (sub)project (yet), now hopefully they will have more assurance!
 
 On 02-May-2015, at 6:02 pm, Sebastien Goasguen run...@gmail.com wrote:
 
 The vote for IP clearance of ec2stack and gstack has passed.
 
 I create INFRA tickets to create git repo within our TLP to host those two 
 subproject (ala cloudmonkey).
 
 I will let you know when the code is dropped
 
 -sebastien
 
 Regards,
 Rohit Yadav
 Software Architect, ShapeBlue
 M. +91 88 262 30892 | rohit.ya...@shapeblue.com
 Blog: bhaisaab.org | Twitter: @_bhaisaab
 
 
 
 Find out more about ShapeBlue and our range of CloudStack related services
 
 IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
 CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
 CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
 CloudStack Software 
 Engineeringhttp://shapeblue.com/cloudstack-software-engineering/
 CloudStack Infrastructure 
 Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
 CloudStack Bootcamp Training 
 Courseshttp://shapeblue.com/cloudstack-training/
 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Shape Blue Ltd or related companies. If you are not the 
 intended recipient of this email, you must neither take any action based 
 upon its contents, nor copy or show it to anyone. Please contact the sender 
 if you believe you have received this email in error. Shape Blue Ltd is a 
 company incorporated in England  Wales. ShapeBlue Services India LLP is a 
 company incorporated in India and is operated under license from Shape Blue 
 Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
 and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a 
 company registered by The Republic of South Africa and is traded under 
 license from Shape Blue Ltd. ShapeBlue is a registered trademark.

[44/50] [abbrv] cloudstack-gcestack git commit: Remove unnecessary print

[sebgoa]

Remove unnecessary print


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/dcf0afc0
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/dcf0afc0
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/dcf0afc0

Branch: refs/heads/master
Commit: dcf0afc0f6c61596fc5fea3cd6023018341265fc
Parents: 8f36cd1
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Sun Jul 27 21:52:19 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Sun Jul 27 21:52:19 2014 +0100

--
 gstack/oauth2provider.py | 1 -
 1 file changed, 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/dcf0afc0/gstack/oauth2provider.py
--
diff --git a/gstack/oauth2provider.py b/gstack/oauth2provider.py
index 8eb166f..0c4a980 100644
--- a/gstack/oauth2provider.py
+++ b/gstack/oauth2provider.py
@@ -148,7 +148,6 @@ class CloudstackResourceProvider(ResourceProvider):
 return request.headers.get('Authorization')
 
 def validate_access_token(self, access_token, authorization):
-print 'pp'
 found_access_token = AccessToken.query.get(access_token)
 if found_access_token is not None and found_access_token.data != 
'false':
 access_token_data = json.loads(found_access_token.data)

[28/50] [abbrv] cloudstack-gcestack git commit: Improve test coverage, clean operations

[sebgoa]

Improve test coverage, clean operations


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/08757591
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/08757591
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/08757591

Branch: refs/heads/master
Commit: 08757591255f8209fed8a00423fd93e31cbbcb7e
Parents: d0cb4ff
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Mon Jun 23 21:31:03 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Mon Jun 23 21:31:03 2014 +0100

--
 gstack/__init__.py   |   1 +
 gstack/configure.py  |   6 +-
 gstack/controllers/instances.py  |  12 +--
 gstack/controllers/operations.py | 104 ++
 setup.py |  41 +-
 tests/data/destroy_vm_async_pending.json |  14 
 tests/operations_tests.py|  20 +
 tests/settings.py|   1 -
 8 files changed, 103 insertions(+), 96 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/08757591/gstack/__init__.py
--
diff --git a/gstack/__init__.py b/gstack/__init__.py
index c4e0c6e..0624553 100644
--- a/gstack/__init__.py
+++ b/gstack/__init__.py
@@ -75,6 +75,7 @@ def _config_from_config_profile(config_file, profile):
 
 def configure_app(settings=None):
 app.config['DATA'] = os.path.abspath(os.path.dirname(__file__)) + '/data'
+app.config['PATH'] = 'compute/v1/projects/'
 
 db.init_app(app)
 

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/08757591/gstack/configure.py
--
diff --git a/gstack/configure.py b/gstack/configure.py
index d67cf73..242e901 100644
--- a/gstack/configure.py
+++ b/gstack/configure.py
@@ -19,16 +19,16 @@
 
 import os
 import argparse
-import ConfigParser
 
 from alembic import command
+from ConfigParser import SafeConfigParser
 from alembic.config import Config as AlembicConfig
 
 
 def main():
 config_folder = _create_config_folder()
-_create_config_file(config_folder)
 _create_database()
+_create_config_file(config_folder)
 
 
 def _create_config_folder():
@@ -66,7 +66,7 @@ def _generate_args():
 
 
 def _modify_config_profile(config_file, profile):
-config = ConfigParser.SafeConfigParser()
+config = SafeConfigParser()
 config.read(config_file)
 
 if not config.has_section(profile):

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/08757591/gstack/controllers/instances.py
--
diff --git a/gstack/controllers/instances.py b/gstack/controllers/instances.py
index 7ea1139..4694b14 100755
--- a/gstack/controllers/instances.py
+++ b/gstack/controllers/instances.py
@@ -184,13 +184,11 @@ def addinstance(authorization, projectid, zone):
 return errors.resource_not_found(func_route)
 
 else:
-populated_response = operations.create_response(
+return helpers.create_response(operations.create_async_response(
 projectid=projectid,
 
operationid=deployment_result['deployvirtualmachineresponse']['jobid'],
 authorization=authorization
-)
-
-return helpers.create_response(data=populated_response)
+))
 
 
 
@app.route('/compute/v1/projects/projectid/zones/zone/instances/instance',
 methods=['DELETE'])
@@ -209,10 +207,8 @@ def deleteinstance(projectid, authorization, zone, 
instance):
 authorization.client_secret
 )
 
-populated_response = operations.create_response(
+return helpers.create_response(operations.create_async_response(
 projectid=projectid,
 operationid=deletion_result['destroyvirtualmachineresponse']['jobid'],
 authorization=authorization
-)
-
-return helpers.create_response(data=populated_response)
+))

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/08757591/gstack/controllers/operations.py
--
diff --git a/gstack/controllers/operations.py b/gstack/controllers/operations.py
index 048595d..361c277 100644
--- a/gstack/controllers/operations.py
+++ b/gstack/controllers/operations.py
@@ -38,34 +38,35 @@ def _get_async_result(authorization, args):
 return cloudstack_response
 
 
-def _delete_instance_response(async_result, projectid):
-populated_response = {
-'kind': 'compute#operation',
-'insertTime': async_result['created'],
-'operationType': 'delete',
-'name': async_result['jobid'],
-'startTime': async_result['created'],
-   

[30/50] [abbrv] cloudstack-gcestack git commit: Update readme instructions

[sebgoa]

Update readme instructions


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/a33d4665
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/a33d4665
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/a33d4665

Branch: refs/heads/master
Commit: a33d46653c320c0e0ea155516729f3703c209f02
Parents: 0441dd2
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Tue Jun 24 18:39:01 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Tue Jun 24 18:39:01 2014 +0100

--
 README.rst   | 46 +--
 gstack/__init__.py   |  4 +--
 gstack/controllers/operations.py |  1 -
 3 files changed, 29 insertions(+), 22 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/a33d4665/README.rst
--
diff --git a/README.rst b/README.rst
index addd1ef..cf50727 100644
--- a/README.rst
+++ b/README.rst
@@ -53,33 +53,36 @@ It is written in Python, using `Flask 
http://flask.pocoo.org/`_ to expose a GC
 
 
 Installation
-#
+
 
 Developers
-___
+__
 
 Clone the repository
 
-  git clone https://github.com/NOPping/gstack.git
+$ git clone https://github.com/NOPping/gstack.git
 
 Install the package
 
-python ./setup.py install
+$ python ./setup.py install
 
 Users
 _
 
 Users can grab the package from Pypi
 
-pip install gstack
+$ pip install gstack
 
 Configuration
 #
 
 Before running `gstack` you must configure it. To do so run
 
-gstack-configure
+$ gstack-configure
+
+You can configure a profile of your choice with the optional ``-p`` flag
 
+$ gstack-configure -p testprofile
 
 And enter your configuration information as prompted. 
 
@@ -93,8 +96,15 @@ This is far from ideal and we opened a feature request with 
google to pass the `
 
 Start gstack:
 
-gstack
+$ gstack
+
+You can launch ``gstack`` using a configuration profile created earlier using 
the optional ``-p`` or ``--profile`` flag
+
+$ gstack -p testprofile
 
+You can start ``gstack`` in debug mode using the optional ``-d`` or 
``--debug`` flag
+
+$ gstack -d True
 
 Create a cached parameters file for gcutil:
 
@@ -123,7 +133,7 @@ Create a cached parameters file for gcutil:
 gcutil will issue auth requests to the local Flask application, get an OAuth 
token and then issue requests to the CloudStack endpoint you specified when 
cofiguring gstack. 
 
 Usage
-##
+#
 
 You can start issuing standard gcutil commands.
 
@@ -137,7 +147,7 @@ Sandbox-simulator UP   None scheduled
 ==     
 
 Running The Tests
-##
+#
 
 To run the included tests the following software is required:
 
@@ -153,37 +163,37 @@ To run the included tests the following software is 
required:
 
 These can be installed via the Python Package Index:
 
-   pip install pep8 pylint nose mock coverage
+   $ pip install pep8 pylint nose mock coverage
 
 Tests can be executed from the root of the code base as follows:
 
 Style Check
 ___
 
-   pep8 --ignore=E501 *.py gstack
+   $ pep8 --ignore=E501 *.py gstack
 
 Lint
 
 
-   pylint --rcfile=pylint.rc *.py gstack
+   $ pylint --rcfile=pylint.rc *.py gstack
 
 Unit Tests
-___
+__
 
-   nosetests --with-coverage  --cover-erase --cover-package=gstack --cover-html
+   $ nosetests --with-coverage  --cover-erase --cover-package=gstack 
--cover-html
 
 A HTML base coverage report will be placed in ./cover
 
 Trouble shooting
-#
+
 
 CertificateHostnameMismatch
-
+___
 
 - Ensure that the addresses you entered for ``authorization_uri_base``, 
``api_host`` and ``auth_host_name`` are the exact same as the address you 
binded ``gstack`` to earlier when configuring with ``gstack-configure``.
 
 Authentication/authorization issues
-
+___
 
 - Clean up your gcutil authentication information ``rm -rf ~/.gcutil_auth``.
 - Ensure that you set your ``client_id`` and ``client_secret`` in 
``gcutil/lib/google_compute_engine/gcutil/auth_helper.py``.
@@ -191,7 +201,7 @@ 
 
 
 Apache CloudStack
-##
+#
 
 For more information about CloudStack check the official `website 
http://cloudstack.apache.org`_
 

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/a33d4665/gstack/__init__.py
--
diff --git a/gstack/__init__.py b/gstack/__init__.py
index 

[31/50] [abbrv] cloudstack-gcestack git commit: Update README usage instructions

[sebgoa]

Update README usage instructions


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/d4126d5e
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/d4126d5e
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/d4126d5e

Branch: refs/heads/master
Commit: d4126d5e83b7266c12a0c096fb35cae26fa905f0
Parents: a33d466
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Tue Jun 24 18:47:11 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Tue Jun 24 18:47:11 2014 +0100

--
 README.rst | 44 +---
 1 file changed, 25 insertions(+), 19 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/d4126d5e/README.rst
--
diff --git a/README.rst b/README.rst
index cf50727..f4d90a6 100644
--- a/README.rst
+++ b/README.rst
@@ -1,6 +1,6 @@
-
+==
 GSTACK
-
+==
 
 A Google Compute Engine Interface For Cloudstack
 
@@ -76,15 +76,17 @@ Users can grab the package from Pypi
 Configuration
 #
 
-Before running `gstack` you must configure it. To do so run
+Before running gstack you must configure it. To do so run
 
 $ gstack-configure
 
-You can configure a profile of your choice with the optional ``-p`` flag
+You can configure a profile of your choice with the optional ``-p`` or 
``--profile`` flag
 
-$ gstack-configure -p testprofile
+$ gstack-configure -p exampleprofile
 
-And enter your configuration information as prompted. 
+If you don't specify a profile, ``gstack-configure`` will default to 
``initial``
+
+Enter your configuration information as prompted.
 
 Install the stand alone `gcutil 
https://developers.google.com/compute/docs/gcutil/#gcutilupgrade/`_
 
@@ -94,18 +96,6 @@ At this stage your CloudStack apikey and secretkey need to 
be entered in the gcu
 
 This is far from ideal and we opened a feature request with google to pass the 
``client_id`` and ``client_secret`` as options to gcutil, hopefully future 
release of gcutil will allow us to do so.
 
-Start gstack:
-
-$ gstack
-
-You can launch ``gstack`` using a configuration profile created earlier using 
the optional ``-p`` or ``--profile`` flag
-
-$ gstack -p testprofile
-
-You can start ``gstack`` in debug mode using the optional ``-d`` or 
``--debug`` flag
-
-$ gstack -d True
-
 Create a cached parameters file for gcutil:
 
 - Make a flagfile to store required flags, something like ``~/.gcutil_params``
@@ -130,12 +120,28 @@ Create a cached parameters file for gcutil:
 
 `--nocheck_for_new_version`
 
+`--permit_root_ssh`
+
 gcutil will issue auth requests to the local Flask application, get an OAuth 
token and then issue requests to the CloudStack endpoint you specified when 
cofiguring gstack. 
 
 Usage
 #
 
-You can start issuing standard gcutil commands.
+Start gstack:
+
+$ gstack
+
+You can launch gstack using a configuration profile created earlier using the 
optional ``-p`` or ``--profile`` flag
+
+$ gstack -p exampleprofile
+
+If you don't specify a profile, gstack will default to ``initial``
+
+You can start gstack in debug mode using the optional ``-d`` or ``--debug`` 
flag
+
+$ gstack -d True
+
+You can now start issuing standard gcutil commands to gstack.
 
 $ ./gcutil --flag_file=~/.gcutil_params 
--project=brogan...@darrenbrogan.ie listzones
 

[34/50] [abbrv] cloudstack-gcestack git commit: Bump version

[sebgoa]

Bump version


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/e91551e5
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/e91551e5
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/e91551e5

Branch: refs/heads/master
Commit: e91551e50d4e699ae4914ec58956c588fe7af426
Parents: 8f69655
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Tue Jun 24 19:27:36 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Tue Jun 24 19:27:36 2014 +0100

--
 HISTORY.rst | 22 --
 setup.py|  2 +-
 2 files changed, 21 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/e91551e5/HISTORY.rst
--
diff --git a/HISTORY.rst b/HISTORY.rst
index dd215f0..9859946 100644
--- a/HISTORY.rst
+++ b/HISTORY.rst
@@ -1,5 +1,23 @@
 History
-
+===
+
+1.0.0 (24-06-14)
+
+
+* Extract database out of application folder, move into config folder
+* Upgrade database with alembic config
+* Major refactor in controllers, remove repeated code
+* Add support for configuration profiles
+
+`$ gstack-configure --profile exampleprofile`
+`$ gstack --profile exampleprofile`
+
+* Give user the ability to debug app
+
+`$ gstack --debug True`
+
+* Add unittests
+* Improve coverage of response attributes
 
 0.1.0 (29-05-14)
 
@@ -22,6 +40,6 @@ __
 
 
 0.0.1 (24-9-2013)
-__
+_
 
 * gcloud conception

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/e91551e5/setup.py
--
diff --git a/setup.py b/setup.py
index 9d659e2..e577c23 100755
--- a/setup.py
+++ b/setup.py
@@ -27,7 +27,7 @@ except ImportError:
 raise RuntimeError(
 python setuptools is required to build gstack)
 
-VERSION = '0.1.0'
+VERSION = '1.0.0'
 
 import os
 

[38/50] [abbrv] cloudstack-gcestack git commit: Update README.rst

[sebgoa]

Update README.rst

Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/48b3b31c
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/48b3b31c
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/48b3b31c

Branch: refs/heads/master
Commit: 48b3b31c87fc4511e9883494a2107043def25e4a
Parents: d225502
Author: Darren darrenbro...@hotmail.com
Authored: Wed Jun 25 19:33:36 2014 +0100
Committer: Darren darrenbro...@hotmail.com
Committed: Wed Jun 25 19:33:36 2014 +0100

--
 README.rst | 1 +
 1 file changed, 1 insertion(+)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/48b3b31c/README.rst
--
diff --git a/README.rst b/README.rst
index 59c154b..96e2f3b 100644
--- a/README.rst
+++ b/README.rst
@@ -13,6 +13,7 @@ A Google Compute Engine Interface For Cloudstack
:target: https://coveralls.io/r/NOPping/gstack
 
 Description
+===
 
 Apache Cloudstack is open source software designed to deploy and manage large 
networks of virtual machines, as highly available, highly scalable 
Infrastructure as a Service(laaS) cloud computing platform. Apache Cloudstack 
is used by a number of service providers to offer public cloud services, and by 
many companies to provide an on-premises (private) cloud offering.
 

[43/50] [abbrv] cloudstack-gcestack git commit: Upgrade database definition

[sebgoa]

Upgrade database definition


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/8f36cd1b
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/8f36cd1b
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/8f36cd1b

Branch: refs/heads/master
Commit: 8f36cd1b5696dab1b91842e1ad21ebf0af5bd2f6
Parents: 4219ecc
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Sun Jul 27 21:34:01 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Sun Jul 27 21:34:01 2014 +0100

--
 gstack/configure.py  |  4 ++--
 gstack/oauth2provider.py |  1 +
 migrations/versions/25c3e5241cd0_.py | 35 +++
 migrations/versions/76bb287a37d_.py  | 24 ++---
 pylint.rc|  2 +-
 pyoauth2/tests/test_integration.py   |  5 ++---
 6 files changed, 53 insertions(+), 18 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/8f36cd1b/gstack/configure.py
--
diff --git a/gstack/configure.py b/gstack/configure.py
index f528122..2bcf4bb 100644
--- a/gstack/configure.py
+++ b/gstack/configure.py
@@ -28,7 +28,7 @@ from alembic.config import Config as AlembicConfig
 def main():
 config_folder = _create_config_folder()
 _create_config_file(config_folder)
-_create_database()
+_upgrade_database()
 
 
 def _create_config_folder():
@@ -113,7 +113,7 @@ def _read_in_config_attribute_or_use_default(message, 
default):
 return attribute
 
 
-def _create_database():
+def _upgrade_database():
 directory = os.path.join(os.path.dirname(__file__), '../migrations')
 database_config = AlembicConfig(os.path.join(
 directory,

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/8f36cd1b/gstack/oauth2provider.py
--
diff --git a/gstack/oauth2provider.py b/gstack/oauth2provider.py
index 0c4a980..8eb166f 100644
--- a/gstack/oauth2provider.py
+++ b/gstack/oauth2provider.py
@@ -148,6 +148,7 @@ class CloudstackResourceProvider(ResourceProvider):
 return request.headers.get('Authorization')
 
 def validate_access_token(self, access_token, authorization):
+print 'pp'
 found_access_token = AccessToken.query.get(access_token)
 if found_access_token is not None and found_access_token.data != 
'false':
 access_token_data = json.loads(found_access_token.data)

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/8f36cd1b/migrations/versions/25c3e5241cd0_.py
--
diff --git a/migrations/versions/25c3e5241cd0_.py 
b/migrations/versions/25c3e5241cd0_.py
new file mode 100644
index 000..b330147
--- /dev/null
+++ b/migrations/versions/25c3e5241cd0_.py
@@ -0,0 +1,35 @@
+empty message
+
+Revision ID: 25c3e5241cd0
+Revises: 76bb287a37d
+Create Date: 2014-07-27 16:19:12.634404
+
+
+
+# revision identifiers, used by Alembic.
+revision = '25c3e5241cd0'
+down_revision = '76bb287a37d'
+
+from alembic import op
+import sqlalchemy as sa
+
+
+def upgrade():
+op.add_column('accesstoken',
+sa.Column(
+'id_token',
+sa.String(length=1000),
+nullable=True
+)
+)
+
+op.add_column('refreshtoken',
+sa.Column(
+'id_token',
+sa.String(length=1000),
+nullable=True
+)
+)
+
+def downgrade():
+pass

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/8f36cd1b/migrations/versions/76bb287a37d_.py
--
diff --git a/migrations/versions/76bb287a37d_.py 
b/migrations/versions/76bb287a37d_.py
index 4353642..efc9887 100644
--- a/migrations/versions/76bb287a37d_.py
+++ b/migrations/versions/76bb287a37d_.py
@@ -16,7 +16,10 @@ import sqlalchemy as sa
 
 def upgrade():
 op.create_table('accesstoken',
-sa.Column('access_token', sa.String(length=255), nullable=False),
+sa.Column(
+'access_token',
+sa.String(length=255),
+nullable=False),
 sa.Column(
 'client_id',
 sa.String(length=255),
@@ -26,10 +29,6 @@ def upgrade():
 sa.String(length=10),
 nullable=True),
 sa.Column(
-'id_token',
-sa.String(length=1000),
-nullable=True),
-sa.Column(
 'data',
 sa.String(length=500),
 nullable=True),
@@ -37,7 +36,9 @@ def upgrade():
 sa.UniqueConstraint('client_id')
 )
 op.create_table('client',
-sa.Column('client_id', 

[39/50] [abbrv] cloudstack-gcestack git commit: Update README.rst

[sebgoa]

Update README.rst

Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/2bcb234c
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/2bcb234c
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/2bcb234c

Branch: refs/heads/master
Commit: 2bcb234c95dd0a7f486e0bc8373a0af007114b94
Parents: 48b3b31
Author: Darren darrenbro...@hotmail.com
Authored: Thu Jun 26 19:45:55 2014 +0100
Committer: Darren darrenbro...@hotmail.com
Committed: Thu Jun 26 19:45:55 2014 +0100

--
 README.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/2bcb234c/README.rst
--
diff --git a/README.rst b/README.rst
index 96e2f3b..7c1d4ce 100644
--- a/README.rst
+++ b/README.rst
@@ -13,7 +13,7 @@ A Google Compute Engine Interface For Cloudstack
:target: https://coveralls.io/r/NOPping/gstack
 
 Description
-===
+---
 
 Apache Cloudstack is open source software designed to deploy and manage large 
networks of virtual machines, as highly available, highly scalable 
Infrastructure as a Service(laaS) cloud computing platform. Apache Cloudstack 
is used by a number of service providers to offer public cloud services, and by 
many companies to provide an on-premises (private) cloud offering.
 
@@ -24,6 +24,6 @@ Google Compute Engine is the Infrastructure as a Service 
(IaaS) component of Goo
 Bridging Apache Cloudstack with existing public cloud providers APIs is needed 
in order to help users work across clouds. Our project’s aim is to create an 
application that will sit above the Apache Cloudstack API. The application will 
take in common Google Compute Engine requests, execute the necessary Cloudstack 
Calls and parse the responses as required. This would allow utilities created 
for the Google Compute Engine API to be used against Apache Cloudstack. 
 
 Usage
-=
+-
 
 Please see the project wiki for usage instructions 
(`https://github.com/NOPping/gstack/wiki`_)

[24/50] [abbrv] cloudstack-gcestack git commit: Merge branch 'master' of github.com:NOPping/gstack into refactor

[sebgoa]

Merge branch 'master' of github.com:NOPping/gstack into refactor


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/60ee7e46
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/60ee7e46
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/60ee7e46

Branch: refs/heads/master
Commit: 60ee7e4609ba0eda545954046fa11c89c3fdb861
Parents: f3f68cd 40d7a7d
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Fri Jun 20 20:33:30 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Fri Jun 20 20:33:30 2014 +0100

--
 HISTORY.rst | 2 +-
 README.rst  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
--

[04/50] [abbrv] cloudstack-gcestack git commit: Begin refactoring process, messy template usage

[sebgoa]

Begin refactoring process, messy template usage


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/5bb67d51
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/5bb67d51
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/5bb67d51

Branch: refs/heads/master
Commit: 5bb67d516e5acf9c9e141f2e76e249a4fd8c945b
Parents: 853231f
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Wed Jun 11 21:48:18 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Wed Jun 11 21:48:18 2014 +0100

--
 gstack/controllers/__init__.py | 11 +--
 gstack/controllers/disks.py| 20 +++--
 gstack/controllers/helper.py   | 51 -
 gstack/controllers/images.py   | 32 +
 gstack/controllers/index.py|  8 +++---
 gstack/controllers/instances.py| 22 +++---
 gstack/controllers/machine_type.py | 18 ++--
 gstack/controllers/networks.py | 16 ++-
 gstack/controllers/operations.py   | 16 +--
 gstack/controllers/project.py  |  8 --
 gstack/controllers/regions.py  |  7 +++--
 gstack/controllers/zones.py| 10 ---
 gstack/helpers.py  | 38 
 gstack/templates/images.json   | 13 +
 gstack/templates/response.json |  6 
 setup.py   | 13 -
 16 files changed, 167 insertions(+), 122 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/5bb67d51/gstack/controllers/__init__.py
--
diff --git a/gstack/controllers/__init__.py b/gstack/controllers/__init__.py
index 47e309d..13e35e8 100644
--- a/gstack/controllers/__init__.py
+++ b/gstack/controllers/__init__.py
@@ -20,5 +20,12 @@
 import os
 import glob
 
-__all__ = [os.path.basename(
-f)[:-3] for f in glob.glob(os.path.dirname(__file__) + '/*.py')]
+__all__ = [os.path.basename(f)[:-3] for f in 
glob.glob(os.path.dirname(__file__) + '/*.py')]
+
+
+def filter_by_name(data, name):
+for item in data:
+if item['name'] == name:
+return item
+
+return None

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/5bb67d51/gstack/controllers/disks.py
--
diff --git a/gstack/controllers/disks.py b/gstack/controllers/disks.py
index 0743a48..888507e 100644
--- a/gstack/controllers/disks.py
+++ b/gstack/controllers/disks.py
@@ -21,7 +21,9 @@ import urllib
 from flask import request, url_for
 from gstack import app, authentication
 from gstack.services import requester
-from gstack.controllers import zones, helper, errors
+from gstack import helpers
+from gstack import controllers
+from gstack.controllers import zones, errors
 
 
 def _get_disks(authorization, args=None):
@@ -47,7 +49,7 @@ def get_disk_by_name(authorization, disk):
 )
 
 if disk_list['listvolumesresponse']:
-response = helper.filter_by_name(
+response = controllers.filter_by_name(
 data=disk_list['listvolumesresponse']['volume'],
 name=disk
 )
@@ -66,7 +68,7 @@ def _cloudstack_volume_to_gce(cloudstack_response, projectid, 
zone):
 response['description'] = cloudstack_response['name']
 response['sizeGb'] = cloudstack_response['size']
 
-response['selfLink'] = urllib.unquote_plus(helper.get_root_url() + url_for(
+response['selfLink'] = urllib.unquote_plus(helpers.get_root_url() + 
url_for(
 'getmachinetype',
 projectid=projectid,
 machinetype=cloudstack_response['name'],
@@ -88,7 +90,7 @@ def aggregatedlistdisks(projectid, authorization):
 zone_list = zones.get_zone_names(authorization=authorization)
 
 disk = None
-filter = helper.get_filter(request.args)
+filter = helpers.get_filter(request.args)
 
 if 'name' in filter:
 disk = filter['name']
@@ -130,14 +132,14 @@ def aggregatedlistdisks(projectid, authorization):
 'items': items
 }
 
-return helper.create_response(data=populated_response)
+return helpers.create_response(data=populated_response)
 
 
 @app.route('/compute/v1/projects/projectid/zones/zone/disks', 
methods=['GET'])
 @authentication.required
 def listdisks(projectid, authorization, zone):
 disk = None
-filter = helper.get_filter(request.args)
+filter = helpers.get_filter(request.args)
 
 if 'name' in filter:
 disk = filter['name']
@@ -150,7 +152,7 @@ def listdisks(projectid, authorization, zone):
 args={'keyword': disk}
 )
 if disk_list['listvolumesresponse']:
-disk = helper.filter_by_name(
+disk = 

[42/50] [abbrv] cloudstack-gcestack git commit: Finish support for updated gcloud

[sebgoa]

Finish support for updated gcloud


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/commit/4219ecc2
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/tree/4219ecc2
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/diff/4219ecc2

Branch: refs/heads/master
Commit: 4219ecc23d63b44a6040004b8bb8d6a59b213fe8
Parents: 34c685d
Author: BroganD1993 darrenbro...@hotmail.com
Authored: Fri Jul 25 20:23:19 2014 +0100
Committer: BroganD1993 darrenbro...@hotmail.com
Committed: Fri Jul 25 20:23:19 2014 +0100

--
 gstack/controllers/OAuth2.py|  1 +
 gstack/models/accesstoken.py|  6 ++-
 gstack/models/refreshtoken.py   |  4 +-
 gstack/oauth2provider.py|  6 +--
 migrations/versions/76bb287a37d_.py | 14 --
 pyoauth2/provider.py| 75 +---
 6 files changed, 33 insertions(+), 73 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/4219ecc2/gstack/controllers/OAuth2.py
--
diff --git a/gstack/controllers/OAuth2.py b/gstack/controllers/OAuth2.py
index b655e59..19218c4 100644
--- a/gstack/controllers/OAuth2.py
+++ b/gstack/controllers/OAuth2.py
@@ -47,4 +47,5 @@ def token():
 res = make_response(response.text, response.status_code)
 for k, v in response.headers.iteritems():
 res.headers[k] = v
+
 return res

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/4219ecc2/gstack/models/accesstoken.py
--
diff --git a/gstack/models/accesstoken.py b/gstack/models/accesstoken.py
index cb4d159..5eb7363 100644
--- a/gstack/models/accesstoken.py
+++ b/gstack/models/accesstoken.py
@@ -24,11 +24,13 @@ class AccessToken(db.Model):
 __tablename__ = 'accesstoken'
 access_token = db.Column(db.String(100), primary_key=True, unique=True)
 client_id = db.Column(db.String(100), unique=True)
-expires_in = db.Column(db.Integer)
+expires_in = db.Column(db.String(10))
+id_token = db.Column(db.String(1000))
 data = db.Column(db.String(500))
 
-def __init__(self, access_token, client_id, expires_in, data):
+def __init__(self, access_token, client_id, expires_in, id_token, data):
 self.access_token = access_token
 self.client_id = client_id
 self.expires_in = expires_in
+self.id_token = id_token
 self.data = data

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/4219ecc2/gstack/models/refreshtoken.py
--
diff --git a/gstack/models/refreshtoken.py b/gstack/models/refreshtoken.py
index 9b8bab0..3a08831 100644
--- a/gstack/models/refreshtoken.py
+++ b/gstack/models/refreshtoken.py
@@ -25,8 +25,10 @@ class RefreshToken(db.Model):
 refresh_token = db.Column(db.String(100), primary_key=True, unique=True)
 client_id = db.Column(db.String(100), unique=True)
 data = db.Column(db.String(500))
+id_token = db.Column(db.String(1000))
 
-def __init__(self, refresh_token, client_id, data):
+def __init__(self, refresh_token, client_id, id_token, data):
 self.refresh_token = refresh_token
 self.client_id = client_id
 self.data = data
+self.id_token = id_token

http://git-wip-us.apache.org/repos/asf/cloudstack-gcestack/blob/4219ecc2/gstack/oauth2provider.py
--
diff --git a/gstack/oauth2provider.py b/gstack/oauth2provider.py
index 9a64e87..0c4a980 100644
--- a/gstack/oauth2provider.py
+++ b/gstack/oauth2provider.py
@@ -78,7 +78,7 @@ class CloudstackAuthorizationProvider(AuthorizationProvider):
 return
 
 def persist_token_information(self, client_id, scope, access_token, 
token_type,
-  expires_in, refresh_token, data):
+  expires_in, refresh_token, id_token, data):
 client = Client.query.get(client_id)
 if client is not None:
 existing_access_token = AccessToken.query.filter_by(
@@ -92,7 +92,7 @@ class CloudstackAuthorizationProvider(AuthorizationProvider):
 else:
 db.session.add(
 AccessToken(
-access_token, client_id, expires_in, json.dumps(data)
+access_token, client_id, expires_in, id_token, 
json.dumps(data)
 )
 )
 
@@ -101,7 +101,7 @@ class 
CloudstackAuthorizationProvider(AuthorizationProvider):
 existing_refresh_token.data = json.dumps(data)
 else:
 db.session.add(
-