date:20160319

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

2016-03-19 Thread Sateesh Chodapuneedi

+1
I'd second that. Move to apache-cloudstack make sense.

Regards,
Sateesh Chodapuneedi
Chief Product Engineer, CloudPlatform Development, Accelerite.
Off: +91 80 6772 1329 | EMail: sateesh.chodapune...@accelerite.com
www.accelerite.com


> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
> Sent: Saturday, March 19, 2016 9:05 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Move 'apache/cloudstack' -> 'apache-
> cloudstack/cloudstack'
>
> +1
> 
> From: ilya 
> Sent: Friday, March 18, 2016 9:23 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Move 'apache/cloudstack' -> 'apache-
> cloudstack/cloudstack'
>
> +1 Binding.
>
> I dont see anything wrong with this approach especially if it helps to solve 
> our
> backlog issue.
>
> On 3/18/16 3:44 PM, Will Stevens wrote:
> > We are discussing this proposal in 3 or 4 threads, so I will not try
> > to recap everything.  Instead I will try to give a brief overview of
> > the problem and a proposal for solving it.
> >
> > *Problem:*
> > The Apache CloudStack community needs additional github permissions in
> > order to integrate CI for the purpose of maintaining code quality.
> > The ASF does not have enough granular control via the 'apache' github
> > organization to give the 'apache/cloudstack' repository the needed
> permissions.
> >
> > *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'.
> >
> > The developer workflow and commit workflow will remain unchanged.  The
> > canonical ASF repository (git://git.apache.org/cloudstack.git) will
> > remain the source of truth and commits will be made to that repository.
> >
> > Please ask if anything is unclear or needs to be better defined in
> > order for you to cast a vote.
> >



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

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

2016-03-19 Thread Sebastien Goasguen

> On Mar 18, 2016, at 8:01 AM, Daan Hoogland  wrote:
> 
> On Thu, Mar 17, 2016 at 6:23 PM, sebgoa  wrote:
> 
>> “cloudstack” is a trademark of the ASF.
> 
> 
> ok, good. I thought is was refused on the grounds of being to generic a
> term.
> 
> 

something too check with VP brand. AFAIK, Cloudstack is a tradermark of ASF but 
not registered (because it’s too broad).

which potentially means anyone could take it..I know ASF was reluctant to pay 
$5k to finish the legal stuff at some point.

> 
> -- 
> Daan

Acs-management fencing VMs, on agent unavailable

2016-03-19 Thread Andrija Panic

Hi guys,

we had some strange (I would say...) happening last night.

We have 2 node keepalived "cluster" with haproxy providing
agent-to-management-server connections.

We did some LB maintance, so we restarted keepalived (VIP moved to another
haproxy node...), so there was I would say 2-3 sec network downtime betwen
management server and agents.

Management server freaked out, and started Fencing bunch of VMs and VRs...

Any explanation on some time limit that when exceded, management will start
stopping VMs ?

WE did this previously with no consequences as far as I remember...

How are we supposed to more "properly" do LB maintance so management server
doesnt go wild ?

Thanks for any input!

-- 

Andrija Panić

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

2016-03-19 Thread Ian Rae

Agreed Mike, there may be confusion generated by the concurrent MCC
fork by SBP but that is not related to the Apache CloudStack developer
workflow improvements being discussed.

On Thu, Mar 17, 2016 at 12:03 PM, Tutkowski, Mike
 wrote:
> 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 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.
>
> Put bluntly, the decision is no, and it is in the hands of the ASF Infra@
> and based on
> discussions I’ve seen on public lists there and on board@ and part of the
> board
> meeting yesterday, Infra@ is not opening up the Whimsy experiment to other
> PMCs
> as of yet. They aren’t ready to declare an SLA; they aren’t ready for
> potential
> other PMCs to ask to use it too and for others to start thinking that
> capability
> is anything near operational. David Nalley can fill in more.
>
>>
>>> 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 ?
>
> Not at this time.

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread srikanteswartalluri

Github user srikanteswartalluri commented on the pull request:

https://github.com/apache/cloudstack/pull/1431#issuecomment-197927026
  
sure. 


---
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: External fork of Cloudstack

2016-03-19 Thread Sam Ruby

On Fri, Mar 18, 2016 at 1:44 PM, Will Stevens  wrote:
>
> I think we are on the same page.  I think we just need to start ironing out
> the actual logistical and technical details for how to move forward.

+1

- Sam Ruby

[GitHub] cloudstack pull request: CLOUDSTACK-9265 cleanup around httpclient...

2016-03-19 Thread bvbharatk

Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1385#issuecomment-197459214
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 103
 Hypervisor xenserver
 NetworkType Advanced
 Passed=103
 Failed=16
 Skipped=4

**The follwing tests have known issues**
test_vpc_remote_access_vpn
test_vpc_site2site_vpn
test_01_test_vm_volume_snapshot
test_02_vpc_privategw_static_routes
test_03_rvpc_privategw_static_routes
test_04_change_offering_small
ContextSuite context=TestNiciraContoller>:setup
test_01_primary_storage_iscsi
test02_internallb_haproxy_stats_on_all_interfaces
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
ContextSuite context=TestDeployVM>:setup
test_04_extract_template
test_04_extract_Iso
test_07_list_default_iso


_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange

 * test_dedicateGuestVlanRange Failing since 3 runs

 * ContextSuite context=TestDedicateGuestVlanRange>:teardown Failing since 
2 runs

* :setup Failed

* integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork

 * test_extendPhysicalNetworkVlan Failed


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_volumes.TestCreateVolume
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


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

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[GitHub] cloudstack pull request: Is the project attempting a fork on Githu...

2016-03-19 Thread chrismattmann

Github user chrismattmann closed the pull request at:

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


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Chris Mattmann

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.

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, comment, etc, sync, the ability to close PRs,
etc. Is there something specific not in that list that the CloudStack
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 - is that what you are
talking about?

The other thing is - is the new Cloudstack GitHub organization the
result of a subset of the PMC going off and doing this - 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.

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

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.

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.
>
>Best,
>
>-Sebastien
>
>> On 17 Mar 2016, at 00:04, Chris Mattmann  wrote:
>> 
>> Hi,
>> 
>> Sorry about my crude way of filing a PR for this, but I heard
>> information about the Apache Cloudstack PMC actively
>> discussing managing the project with GitHub as the primary source
>> in a different organization than the github.com/apache/ org.
>> 
>> Can someone clarify this for me? Clearly wearing my board hat,
>> this is not something we allow for any of our ASF projects.
>> 
>> Cheers,
>> Chris “board hat on” Mattmann
>> 
>> 
>>

Re: github organisation cloudstack

2016-03-19 Thread Will Stevens

Please be advised this conversation is continuing in a thread titled: Re:
External fork of Cloudstack

Mailing list link:
http://markmail.org/message/53ct2mma4x4jm6s2?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Re:+External+fork+of+Cloudstack

Please come join the conversation in that thread...

*Will STEVENS*
Lead Developer

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

On Wed, Mar 16, 2016 at 3:59 PM, Will Stevens  wrote:

> The copying existing PRs would be for the purpose of running CI against it
> in the context of being able to automate what happens next given the
> result.
>
> I am going to be putting time into fixing marvin tests and also merging in
> any fixes to marvin to try to get the CI runs as bulletproof as possible.
> I agree this is the first step towards being able to move forward with
> being able to automate anything.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Wed, Mar 16, 2016 at 3:55 PM, Sebastien Goasguen 
> wrote:
>
>> Will,
>>
>> I think you are putting the carriage before the horse, sort of speak.
>>
>> I would suggest you make a dummy PR to cloudstack/cloudstack (just one,
>> let’s not talk about migration or anything like that).
>>
>> then you can use this as a playground to see how you could improve our CI…
>>
>> The main idea being that we have control of this fork and can test the
>> hell out of it and github integration capability.
>>
>> for instance, I can create auto-builds of Docker images now, something I
>> can’t do with apache/cloudstack…
>>
>> I think it is way too early to worry/think about moving existing PR there.
>>
>> -sebastien
>>
>> > On Mar 16, 2016, at 8:46 PM, Will Stevens 
>> wrote:
>> >
>> > If we use this I think it's main purpose should be to facilitate CI and
>> > integration testing of the apache/cloudstack repo.
>> >
>> > The first hurdle in using this repo for CI work is the fact that none of
>> > the open PRs from apache/cloudstack are available in the
>> > cloudstack/cloudstack repo.  If we are only using it for CI, that is
>> not a
>> > major problem because we can copy the PRs we care about from the
>> > apache/cloudstack to the cloudstack/cloudstack repo programmatically.  I
>> > have already built a POC script and have successfully been able to copy
>> a
>> > pull request from one repository to a different fork of the same repo.
>> >
>> > Some things to note when doing this (which probably won't be an issue
>> if we
>> > only use it for CI):
>> > - The PR number in cloudstack/cloudstack will not reflect the PR number
>> > from apache/cloudstack.  The apache/cloudstack PR number, author, etc
>> could
>> > be added to the body of the PR so we can easily navigate back to the
>> > apache/cloudstack PR if we want to.
>> > - The new PR in cloudstack/cloudstack will be owned by the person who
>> runs
>> > the copy pull request tool because it is their access token that is
>> used to
>> > create the new pull request.  Again, if this is only used for CI, thats
>> not
>> > a major problem as we can reference the original author in the issue
>> body
>> > for the PR when we copy it.
>> > - None of the comments will be copied over with the PR when we copy it.
>> > This again, probably is not a deal breaker if we are only using it for
>> CI.
>> > We could potentially loop through the original PR comments and add them
>> to
>> > the copy, but I am not sure that is worth it.  Again, they would all be
>> > owned by the person who runs the tool, but we could again put the
>> author in
>> > the body.
>> >
>> > With this in mind, here are some of my ideas.
>> >
>> > We start by manually picking "mergeable" PRs that have at least 2 LGTM
>> > votes and copying them to the cloudstack/cloudstack repo.  We then use
>> the
>> > hooks in Github to automatically runCI against that PR in the
>> > cloudstack/cloudstack repo.  If the CI passes, then the code is
>> > automatically merged into master and the official Apache repo is
>> updated.
>> > If it fails, the PR in cloudstack/cloudstack is updated with the status
>> of
>> > the CI run and the details.  A comment is then pushed to the
>> > apache/cloudstack PR referencing the cloudstack/cloudstack PR and the CI
>> > status for that PR.
>> >
>> > There are obviously many other potential ways to do something similar,
>> but
>> > these are some of my original thoughts.  We could also have it so that
>> the
>> > master is not automatically merged into the official master after the
>> PR is
>> > merged.  We could also have a nightly CI run against master and if that
>> > passes, then and only then is the master pushed to the official apache
>> > master.
>> >
>> > Anyway, let the discussions continue.
>> >
>> > BTW, apache has taken notice that we have created the cloudstack org:
>> > https://github.com/apache/cloudstack/pu

[IMPORTANT] Huge Github PR Backlog

2016-03-19 Thread ilya

Hi Folks,

What can we do about PR backlog in GitHub? As we all know, it will be
very difficult to merge the changes - as things will get out of sync.

Feedback is welcome,

Thanks,
ilya

[GitHub] cloudstack pull request: CLOUDSTACK-9142 Migrate VM changes xmlDes...

2016-03-19 Thread bhaisaab

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

https://github.com/apache/cloudstack/pull/1348#discussion_r56420080
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtMigrateCommandWrapper.java
 ---
@@ -190,4 +195,27 @@ Use VIR_DOMAIN_XML_SECURE (value = 1) prior to v1.0.0.
 
 return new MigrateAnswer(command, result == null, result, null);
 }
-}
\ No newline at end of file
+
+/**
+ * This function assumes an qemu machine description containing a 
single graphics element like
+ * 
+ *   
+ * 
+ * @param xmlDesc the qemu xml description
+ * @param target the ip address to migrate to
+ * @return the new xmlDesc
+ */
+String replaceIpForVNCInDescFile(String xmlDesc, final String target) {
+final int begin = xmlDesc.indexOf(GRAPHICS_ELEM_START);
--- End diff --

While this should work for most cases, the code is not defensive. For 
example, it will fail for multiple graphics nodes or if there are any 
whitespaces between closing brackets. Consider using a dom parser.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9297 - Reworked logic in Stora...

2016-03-19 Thread rafaelweingartner

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1441#issuecomment-197935023
  
@mike-tutkowski thanks for the improvements on PR title and description. 
I understand the point of throwing an exception and I really like that 
approach.

About the suggested change on âcanHandleâ method, I still did not see 
the need to use the enum. If you were using more than 2 values as its returns, 
it would be something I would understand; but you only use two values that 
could be represented as a âtrueâ or âfalseâ.

Could you elaborate a little bit more?
I also did not understand this sentence:
âI see returning true as your revert was successful and returning false 
as it failed (but it was OK for you to ask us to revert because canHandle 
properly told you that you could do so)â





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

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

2016-03-19 Thread Koushik Das

+1 for the move to apache-cloudstack/cloudstack

From: Will Stevens 
Sent: Saturday, March 19, 2016 4:14 AM
To: dev@cloudstack.apache.org
Subject: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'

We are discussing this proposal in 3 or 4 threads, so I will not try to
recap everything.  Instead I will try to give a brief overview of the
problem and a proposal for solving it.

*Problem:*
The Apache CloudStack community needs additional github permissions in
order to integrate CI for the purpose of maintaining code quality.  The ASF
does not have enough granular control via the 'apache' github organization
to give the 'apache/cloudstack' repository the needed permissions.

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

The developer workflow and commit workflow will remain unchanged.  The
canonical ASF repository (git://git.apache.org/cloudstack.git) will remain
the source of truth and commits will be made to that repository.

Please ask if anything is unclear or needs to be better defined in order
for you to cast a vote.

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

[GitHub] cloudstack pull request: CLOUDSTACK-9297: delete snapshot without ...

2016-03-19 Thread mike-tutkowski

Github user mike-tutkowski commented on the pull request:

https://github.com/apache/cloudstack/pull/1441#issuecomment-197375495
  
Thanks, @ustcweizhou!


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

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread srikanteswartalluri

Github user srikanteswartalluri commented on the pull request:

https://github.com/apache/cloudstack/pull/1431#issuecomment-197904292
  
@swill Yes, PR is ready to be merged. Do you see any problem with that?


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

Build failed in Jenkins: build-master-slowbuild #3481

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.751s]
[INFO] Apache CloudStack . SUCCESS [2.120s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.792s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.264s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.979s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.107s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.734s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.139s]
[INFO] Apache CloudStack API . SUCCESS [1:51.288s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [18.102s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [32.037s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.085s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.705s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.606s]
[INFO] Apache CloudStack Core  SUCCESS [1:22.287s]
[INFO] Apache CloudStack Agents .. SUCCESS [37.103s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.055s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.561s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:06.521s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [41.585s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.502s]
[INFO] Apache CloudStack Server .. SUCCESS [4:15.077s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.644s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.370s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.905s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.075s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.464s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.076s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.281s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.038s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.524s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.646s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [23.778s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.132s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.296s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.327s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.962s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.388s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.350s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[36.033s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.812s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [24.136s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.981s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[17.248s]
[INFO] Apache Cloud

Build failed in Jenkins: build-master-slowbuild #3489

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.948s]
[INFO] Apache CloudStack . SUCCESS [3.273s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.126s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.406s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.401s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.104s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.341s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.904s]
[INFO] Apache CloudStack API . SUCCESS [1:48.422s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.212s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [30.493s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.086s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [26.991s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.743s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.745s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.018s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.823s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.920s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.300s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [39.976s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.207s]
[INFO] Apache CloudStack Server .. SUCCESS [4:11.293s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.735s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.778s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.494s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.080s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.446s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.495s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [50.682s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [29.761s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.264s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [25.329s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [21.045s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.052s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.382s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.344s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.952s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.421s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.262s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[37.722s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.167s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.052s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.129s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.707s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: OSPF: adding dynamically routing capabili...

2016-03-19 Thread eriweb

Github user eriweb commented on the pull request:

https://github.com/apache/cloudstack/pull/1371#issuecomment-198256679
  
Would you mind running a broader test suite to verify that there are no 
regressions?


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

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/1431#issuecomment-197903262
  
I am not going to revert this merge at this time, but please ping me if you 
feel the PR is ready to be merged into master.  Thx...


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Daan Hoogland

On Thu, Mar 17, 2016 at 6:23 PM, sebgoa  wrote:

> “cloudstack” is a trademark of the ASF.


ok, good. I thought is was refused on the grounds of being to generic a
term.



-- 
Daan

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

2016-03-19 Thread martin kolly


Hi All

We are facing the same issue as reported by Milamber (Ticket 9255) 
https://issues.apache.org/jira/browse/CLOUDSTACK-9255. When deploying a 
couple of VMs or Port Forwarding's the re-deployment of the router with 
cleanup fails.


We found that iptables configuration takes a lot of time, this 
eventually leads to a timeout on the management server "Unable to start 
VM DomainRouter due to error in finalizeStart, not retrying"


Environment:
- Cloudstack 4.8
- KVM (local storage)
- hosts/mgr on Ubuntu 14.04

We tested with a simple set of four forwarding rules, here the setup:

root@r-96-VM:~# cat /etc/cloudstack/forwardingrules.json
{
"185.20.146.56": [
{
"internal_ip": "10.100.1.95",
"internal_ports": "22:22",
"protocol": "tcp",
"public_ip": "185.20.146.56",
"public_ports": "22:22",
"type": "forward"
}
],
"185.20.146.79": [
{
"internal_ip": "10.100.1.42",
"internal_ports": "22:22",
"protocol": "tcp",
"public_ip": "185.20.146.79",
"public_ports": "22:22",
"type": "forward"
},
{
"internal_ip": "10.100.1.42",
"internal_ports": "8443:8443",
"protocol": "tcp",
"public_ip": "185.20.146.79",
"public_ports": "8443:8443",
"type": "forward"
},
{
"internal_ip": "10.100.1.42",
"internal_ports": "53:53",
"protocol": "udp",
"public_ip": "185.20.146.79",
"public_ports": "53:53",
"type": "forward"
}
],
"id": "forwardingrules"

The definition for every port forwarding seems to take at ~1.5 seconds.

python /opt/cloud/bin/configure.py.timed 
/etc/cloudstack/forwardingrules.json


-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j 
DNAT --to-destination 10.100.1.42:22

time : 0.000965118408203
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 22 -j 
DNAT --to-destination 10.100.1.42:22

time : 0.395485162735
-A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 22 -j DNAT 
--to-destination 10.100.1.42:22

time : 0.395533084869
-j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d 
10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 22

time : 1.16180706024
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j 
MARK --set-xmark 0x2/0x

time : 1.16329216957
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -m 
state --state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask 
0x

time : 1.16407108307
-A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 22 -m state --state 
NEW,ESTABLISHED -j ACCEPT

Total time for creating Policy : 1.53959512711
--
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j 
DNAT --to-destination 10.100.1.42:8443

time : 0.000781059265137
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 8443 -j 
DNAT --to-destination 10.100.1.42:8443

time : 0.378201007843
-A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 8443 -j DNAT 
--to-destination 10.100.1.42:8443

time : 0.37822508812
-j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d 
10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 8443

time : 1.14627504349
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j 
MARK --set-xmark 0x2/0x

time : 1.1477329731
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -m 
state --state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask 
0x

time : 1.14850592613
-A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 8443 -m state --state 
NEW,ESTABLISHED -j ACCEPT

Total time for creating Policy : 1.52321791649
--
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p udp -m udp --dport 53 -j 
DNAT --to-destination 10.100.1.42:53

time : 0.000754117965698
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p udp -m udp --dport 53 -j 
DNAT --to-destination 10.100.1.42:53

time : 0.383729934692
-A OUTPUT -d 185.20.146.79/32 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.100.1.42:53

time : 0.383754968643
-j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d 
10.100.1.42/32 -o eth0 -p udp -m udp --dport 53

time : 1.14376091957
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p udp -m udp --dport 53 -j 
MARK --set-xmark 0x2/0x

time : 1.14526605606
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p udp -m udp --dport 53 -m 
state --state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask 
0x

time : 1.14599299431
-A FORWARD -i eth2 -o eth0 -p udp -m udp --dport 53 -m state --state 
NEW,ESTABLISHED -j ACCEPT

Total time for creating Policy : 1.52742600441
--
-A PREROUTING -d 185.20.146.56/32 -i eth2 -p tcp -m tcp --dport 22 -j 
DNA

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread swill

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

https://github.com/apache/cloudstack/pull/780#discussion_r56506811
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -3115,6 +3125,9 @@ public VmStatsEntry getVmStat(final Connect conn, 
final String vmName) throws Li
 newStat._bytesRead = bytes_rd;
 newStat._bytesWrote = bytes_wr;
 newStat._timestamp = now;
+newStat._intmemfree = mems[0].getValue();
--- End diff --

Is this guaranteed to have a result?  This looks like it is prime to 
introduce a Null Pointer Exception...


---
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: Issue: CLOUDSTACK-9255 Unable to start VM DomainRouter due to error in finalizeStart

2016-03-19 Thread Remi Bergsma

Hi,

This issue has been resolved some time ago but unfortunately the PR hasn’t been 
merged nor tested yet.

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

This PR makes it like 50-60 times faster, because it first generates all 
iptables commands and then loads them once.

We run this in production for weeks already. Not sure why the PR is closed, it 
simply works.

Regards,
Remi


From: martin kolly mailto:martin.ko...@senselan.ch>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Friday 18 March 2016 at 11:58
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Issue: CLOUDSTACK-9255 Unable to start VM DomainRouter due to error in 
finalizeStart

Hi All

We are facing the same issue as reported by Milamber (Ticket 9255) 
https://issues.apache.org/jira/browse/CLOUDSTACK-9255. When deploying a couple 
of VMs or Port Forwarding's the re-deployment of the router with cleanup fails.

We found that iptables configuration takes a lot of time, this eventually leads 
to a timeout on the management server "Unable to start VM DomainRouter due to 
error in finalizeStart, not retrying"

Environment:
- Cloudstack 4.8
- KVM (local storage)
- hosts/mgr on Ubuntu 14.04

We tested with a simple set of four forwarding rules, here the setup:

root@r-96-VM:~# cat /etc/cloudstack/forwardingrules.json
{
"185.20.146.56": [
{
"internal_ip": "10.100.1.95",
"internal_ports": "22:22",
"protocol": "tcp",
"public_ip": "185.20.146.56",
"public_ports": "22:22",
"type": "forward"
}
],
"185.20.146.79": [
{
"internal_ip": "10.100.1.42",
"internal_ports": "22:22",
"protocol": "tcp",
"public_ip": "185.20.146.79",
"public_ports": "22:22",
"type": "forward"
},
{
"internal_ip": "10.100.1.42",
"internal_ports": "8443:8443",
"protocol": "tcp",
"public_ip": "185.20.146.79",
"public_ports": "8443:8443",
"type": "forward"
},
{
"internal_ip": "10.100.1.42",
"internal_ports": "53:53",
"protocol": "udp",
"public_ip": "185.20.146.79",
"public_ports": "53:53",
"type": "forward"
}
],
"id": "forwardingrules"

The definition for every port forwarding seems to take at ~1.5 seconds.

python /opt/cloud/bin/configure.py.timed /etc/cloudstack/forwardingrules.json

-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j DNAT 
--to-destination 10.100.1.42:22
time : 0.000965118408203
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 22 -j DNAT 
--to-destination 10.100.1.42:22
time : 0.395485162735
-A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 22 -j DNAT --to-destination 
10.100.1.42:22
time : 0.395533084869
-j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d 
10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 22
time : 1.16180706024
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -j MARK 
--set-xmark 0x2/0x
time : 1.16329216957
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 22 -m state 
--state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask 0x
time : 1.16407108307
-A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 22 -m state --state 
NEW,ESTABLISHED -j ACCEPT
Total time for creating Policy : 1.53959512711
--
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j DNAT 
--to-destination 10.100.1.42:8443
time : 0.000781059265137
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p tcp -m tcp --dport 8443 -j DNAT 
--to-destination 10.100.1.42:8443
time : 0.378201007843
-A OUTPUT -d 185.20.146.79/32 -p tcp -m tcp --dport 8443 -j DNAT 
--to-destination 10.100.1.42:8443
time : 0.37822508812
-j SNAT --to-source 10.100.1.1 -A POSTROUTING -s 10.100.1.0/24 -d 
10.100.1.42/32 -o eth0 -p tcp -m tcp --dport 8443
time : 1.14627504349
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -j MARK 
--set-xmark 0x2/0x
time : 1.1477329731
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p tcp -m tcp --dport 8443 -m state 
--state NEW -j CONNMARK --save-mark --nfmask 0x --ctmask 0x
time : 1.14850592613
-A FORWARD -i eth2 -o eth0 -p tcp -m tcp --dport 8443 -m state --state 
NEW,ESTABLISHED -j ACCEPT
Total time for creating Policy : 1.52321791649
--
-A PREROUTING -d 185.20.146.79/32 -i eth2 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.100.1.42:53
time : 0.000754117965698
-A PREROUTING -d 185.20.146.79/32 -i eth0 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.100.1.42:53
time : 0.383729934692
-A OUTPUT -d 185.20.146.79/32 -p udp -m udp --dport 53 -j DNAT

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-197893296
  
should we revert this merge in favor of fixing these issues?


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

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread srikanteswartalluri

Github user srikanteswartalluri commented on the pull request:

https://github.com/apache/cloudstack/pull/1431#issuecomment-197905351
  
If the concern is jenkins build, I mentioned that they are not related to 
these integration test code but they are junit tests.


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

Re: github organisation cloudstack

2016-03-19 Thread Will Stevens

The copying existing PRs would be for the purpose of running CI against it
in the context of being able to automate what happens next given the
result.

I am going to be putting time into fixing marvin tests and also merging in
any fixes to marvin to try to get the CI runs as bulletproof as possible.
I agree this is the first step towards being able to move forward with
being able to automate anything.

*Will STEVENS*
Lead Developer

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

On Wed, Mar 16, 2016 at 3:55 PM, Sebastien Goasguen 
wrote:

> Will,
>
> I think you are putting the carriage before the horse, sort of speak.
>
> I would suggest you make a dummy PR to cloudstack/cloudstack (just one,
> let’s not talk about migration or anything like that).
>
> then you can use this as a playground to see how you could improve our CI…
>
> The main idea being that we have control of this fork and can test the
> hell out of it and github integration capability.
>
> for instance, I can create auto-builds of Docker images now, something I
> can’t do with apache/cloudstack…
>
> I think it is way too early to worry/think about moving existing PR there.
>
> -sebastien
>
> > On Mar 16, 2016, at 8:46 PM, Will Stevens  wrote:
> >
> > If we use this I think it's main purpose should be to facilitate CI and
> > integration testing of the apache/cloudstack repo.
> >
> > The first hurdle in using this repo for CI work is the fact that none of
> > the open PRs from apache/cloudstack are available in the
> > cloudstack/cloudstack repo.  If we are only using it for CI, that is not
> a
> > major problem because we can copy the PRs we care about from the
> > apache/cloudstack to the cloudstack/cloudstack repo programmatically.  I
> > have already built a POC script and have successfully been able to copy a
> > pull request from one repository to a different fork of the same repo.
> >
> > Some things to note when doing this (which probably won't be an issue if
> we
> > only use it for CI):
> > - The PR number in cloudstack/cloudstack will not reflect the PR number
> > from apache/cloudstack.  The apache/cloudstack PR number, author, etc
> could
> > be added to the body of the PR so we can easily navigate back to the
> > apache/cloudstack PR if we want to.
> > - The new PR in cloudstack/cloudstack will be owned by the person who
> runs
> > the copy pull request tool because it is their access token that is used
> to
> > create the new pull request.  Again, if this is only used for CI, thats
> not
> > a major problem as we can reference the original author in the issue body
> > for the PR when we copy it.
> > - None of the comments will be copied over with the PR when we copy it.
> > This again, probably is not a deal breaker if we are only using it for
> CI.
> > We could potentially loop through the original PR comments and add them
> to
> > the copy, but I am not sure that is worth it.  Again, they would all be
> > owned by the person who runs the tool, but we could again put the author
> in
> > the body.
> >
> > With this in mind, here are some of my ideas.
> >
> > We start by manually picking "mergeable" PRs that have at least 2 LGTM
> > votes and copying them to the cloudstack/cloudstack repo.  We then use
> the
> > hooks in Github to automatically runCI against that PR in the
> > cloudstack/cloudstack repo.  If the CI passes, then the code is
> > automatically merged into master and the official Apache repo is updated.
> > If it fails, the PR in cloudstack/cloudstack is updated with the status
> of
> > the CI run and the details.  A comment is then pushed to the
> > apache/cloudstack PR referencing the cloudstack/cloudstack PR and the CI
> > status for that PR.
> >
> > There are obviously many other potential ways to do something similar,
> but
> > these are some of my original thoughts.  We could also have it so that
> the
> > master is not automatically merged into the official master after the PR
> is
> > merged.  We could also have a nightly CI run against master and if that
> > passes, then and only then is the master pushed to the official apache
> > master.
> >
> > Anyway, let the discussions continue.
> >
> > BTW, apache has taken notice that we have created the cloudstack org:
> > https://github.com/apache/cloudstack/pull/1442
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Wed, Mar 16, 2016 at 4:13 AM, Erik Weber  wrote:
> >
> >> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> >> wrote:
> >>
> >>> devs,
> >>>
> >>> There is a github organisation called cloudstack, to which we have more
> >>> control then to the apache/cloudstack repo on github. We need to decide
> >> as
> >>> community what to do with it.
> >>>
> >>> What are we going to do in this new organisation?
> >>>
> >>
>

[GitHub] cloudstack pull request: CLOUDSTACK-9304: Add nuagevsp userdata te...

2016-03-19 Thread chinu2909

Github user chinu2909 commented on the pull request:

https://github.com/apache/cloudstack/pull/1431#issuecomment-197539050
  
LGTM based on the test results

test_01_UserDataPasswordReset 
(nuagevsp.test_nuage_password_reset.TestNuagePasswordReset) ... === TestName: 
test_01_UserDataPasswordReset | Status : SUCCESS ===
ok
Test Basic VPC Network Functionality with NuageVsp network Plugin ... === 
TestName: test_nuage_vpc_network | Status : SUCCESS ===
ok
Test NuageVsp network plugin with basic Isolated Network functionality ... 
=== TestName: test_nuage_vsp | Status : SUCCESS ===
ok

--
Ran 3 tests in 2477.667s

OK


[runinfo.txt](https://github.com/apache/cloudstack/files/176856/runinfo.txt)
[results.txt](https://github.com/apache/cloudstack/files/176859/results.txt)











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

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-197917819
  
@ustcweizhou the point is more that there are things in this PR that I am 
not comfortable with and as the 4.9 RM, I need to be comfortable with the code 
that goes into master.


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

[GitHub] cloudstack pull request: [Bug-Id: CLOUDSTACK-9306]Replace testdata...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/1436#issuecomment-197551390
  
I will test this as soon as my CI is up and running.  If anyone else has 
had a chance to test this and can post the results I will merge it right away.  
Thx...


---
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: [IMPORTANT] Huge Github PR Backlog

2016-03-19 Thread Remi Bergsma

PRs needs to be tested obviously, that is the current impediment. The moment 
you test a PR, you get current master and merge the PR and test that result. 
Once it’s OK, merge it to master and take next one, etc. I wouldn’t start 
rebasing, as you’ll have a lot of work and will need to keep doing that. Git is 
pretty good in merging stuff so it will work quite often. Or else result in 
some PRs not being able to merge due to conflicts. Those need to be resolved.

Another thing: I would say 50% (if not more) is never going to be merged 
because they’re too old, abandoned, broken, etc.

Regards,
Remi

On 17/03/16 22:10, "Simon Weller"  wrote:

>If we ask for each PR to be rebased with master, we need to commit as a team 
>to actually working through them rapidly, as obviously rebasing is significant 
>work in a lot of cases.
>
>Just my 2 cents.
>
>- Si
>
>
>
>
>
>From: ilya 
>Sent: Thursday, March 17, 2016 4:06 PM
>To: dev@cloudstack.apache.org
>Subject: [IMPORTANT] Huge Github PR Backlog
>
>Hi Folks,
>
>What can we do about PR backlog in GitHub? As we all know, it will be
>very difficult to merge the changes - as things will get out of sync.
>
>Feedback is welcome,
>
>Thanks,
>ilya

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

2016-03-19 Thread Rene Moser

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.

Re: [POLL] Interest for EU based event/collab

2016-03-19 Thread Erik Weber

Hi Giles,

Berlin is great!

Has there been any discussions about a specific date yet? Personally I have
some vacation plans in that time frame (not that it should matter for the
event).

I agree that combing the efforts we have is a good thing, I am hoping for
something bigger than a traditional UG at some point as it is hard to
defend the costs for a 3-4 hour event.

-- 
Erik



On Wed, Mar 16, 2016 at 4:22 PM, Giles Sirett 
wrote:

> Erik
>
> I've responded to your survey (don’t know how useful my response will be,
> I've said "yes" to everything)
>
>
> One idea: we have a quarterly meeting of the Cloudstack EU UG.
> We got 50 along to the last one. It’s a different audience to the usual
> CCC attendees (more users than devs)
>
> For the next one (early June), we're planning on having it in Berlin
>
> Andre and the folks from BitGroup are taking the lead on it
>
> It would seem perfectly logical to me to combine anything we (i.e. the
> community) do with one of these UG's - gain more critical mass more quickly
> and make it more attractive to potential sponsors
>
> I'm not sure how far down the path Andre et al are with logistics and
> whether the idea of making this into a bigger thing would scare him, but it
> may be worth you two syncing on this
>
> We only have these meetings quarterly, the one after June would clash with
> Brasil so likely not to happen
>
>
>
> Kind Regards
> Giles
>
>
>
> [image: ShapeBlue] 
> Giles Sirett
> CEO ,  ShapeBlue
> d:  *+44  20 3603 0541 | s: +44 203 603 0540*
> <+44%20%2020%203603%200541%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> *+44 7961112055* <+44%207961112055>
> 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: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 16 March 2016 13:20
> To: dev ; us...@cloudstack.apache.org
> Subject: [POLL] Interest for EU based event/collab
>
> [Cross posted to users@ and dev@]
>
> As you may be aware, a conference has been announced in Brazil later this
> year.
>
> I guess there are more than me having a hard time travelling that far and
> long, so I would like to check the interest for an EU based event.
>
> Unless someone comes up with a big money jar it won't be as fancy as the
> previous ones.
>
> If you could fill out this poll[1] and/or respond to this email, that
> would be great.
>
> [1] https://no.surveymonkey.com/r/CX3K5T3
>
>
> --
> Erik
> 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 
>

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread rafaelweingartner

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-197932674
  
@swill, I understand your position; as you, I also think that there was 
room for improvements in this PR (especially to avoid possible runtime 
exception). However, reverting a PR is always something complicated. I believe 
we should wait to hear feedback from others, before taking any decision.


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

Build failed in Jenkins: build-master-jdk18 #491

2016-03-19 Thread jenkins

See 

Changes:

[maneesha.papireddygari] CLOUDSTACK-8800 : Improved the listVirtualMachines API 
call to include

--
[...truncated 425 lines...]
Tests run: 10, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.551 sec - in 
com.cloud.utils.ScriptTest
Running com.cloud.utils.log.CglibThrowableRendererTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.229 sec - in 
com.cloud.utils.log.CglibThrowableRendererTest
Running com.cloud.utils.UuidUtilsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec - in 
com.cloud.utils.UuidUtilsTest
Running com.cloud.utils.crypto.RSAHelperTest
2016-03-17 08:17:40,694 INFO  [utils.crypt.RSAHelper] (main:) [ignored]error 
during public key encryption: Unsupported format
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.645 sec - in 
com.cloud.utils.crypto.RSAHelperTest
Running com.cloud.utils.crypto.EncryptionSecretKeyCheckerTest
2016-03-17 08:17:40,803 DEBUG [utils.crypt.EncryptionSecretKeyChecker] (main:) 
Encryption Type: null
2016-03-17 08:17:40,803 DEBUG [utils.crypt.EncryptionSecretKeyChecker] (main:) 
Encryption Type: file
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec - in 
com.cloud.utils.crypto.EncryptionSecretKeyCheckerTest
Running com.cloud.utils.PropertiesUtilsTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec - in 
com.cloud.utils.PropertiesUtilsTest
Running com.cloud.utils.exception.ExceptionUtilTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
com.cloud.utils.exception.ExceptionUtilTest
Running com.cloud.utils.storage.QCOW2UtilsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in 
com.cloud.utils.storage.QCOW2UtilsTest
Running com.cloud.utils.encoding.UrlEncoderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
com.cloud.utils.encoding.UrlEncoderTest
Running com.cloud.utils.UriUtilsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec - in 
com.cloud.utils.UriUtilsTest
Running com.cloud.utils.HttpUtilsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.097 sec - in 
com.cloud.utils.HttpUtilsTest
Running com.cloud.utils.backoff.impl.ConstantTimeBackoffTest
2016-03-17 08:17:41,102 INFO  [backoff.impl.ConstantTimeBackoff] (Thread-1:) 
Thread Thread-1 interrupted while waiting for retry
2016-03-17 08:17:41,205 DEBUG [backoff.impl.ConstantTimeBackoffTest] (main:) 
thread started
2016-03-17 08:17:41,205 DEBUG [backoff.impl.ConstantTimeBackoffTest] 
(Thread-2:) before
2016-03-17 08:17:41,307 DEBUG [backoff.impl.ConstantTimeBackoffTest] (main:) 
testing wakeup
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.301 sec - in 
com.cloud.utils.backoff.impl.ConstantTimeBackoffTest
Running com.cloud.utils.ProcessUtilTest
2016-03-17 08:17:41,307 INFO  [backoff.impl.ConstantTimeBackoff] (Thread-2:) 
Thread Thread-2 interrupted while waiting for retry
2016-03-17 08:17:41,307 DEBUG [backoff.impl.ConstantTimeBackoffTest] 
(Thread-2:) after
2016-03-17 08:17:41,313 DEBUG [cloud.utils.ProcessUtil] (main:) 
environment.properties could not be opened
2016-03-17 08:17:41,318 DEBUG [cloud.utils.ProcessUtil] (main:) 
environment.properties could not be opened
2016-03-17 08:17:41,319 DEBUG [cloud.utils.ProcessUtil] (main:) Executing: bash 
-c ps -p 123456 
2016-03-17 08:17:41,383 DEBUG [cloud.utils.ProcessUtil] (main:) Exit value is 1
2016-03-17 08:17:41,383 DEBUG [cloud.utils.ProcessUtil] (main:)   PID TTY   
   TIME CMD
2016-03-17 08:17:41,384 DEBUG [cloud.utils.ProcessUtil] (main:) Executing: bash 
-c echo $PPID 
2016-03-17 08:17:41,387 DEBUG [cloud.utils.ProcessUtil] (main:) Execution is 
successful.
2016-03-17 08:17:41,399 DEBUG [cloud.utils.ProcessUtil] (main:) 
environment.properties could not be opened
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 sec - in 
com.cloud.utils.ProcessUtilTest
Running com.cloud.utils.PasswordGeneratorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
com.cloud.utils.PasswordGeneratorTest
Running com.cloud.utils.rest.HttpUriRequestBuilderTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec - in 
com.cloud.utils.rest.HttpUriRequestBuilderTest
Running com.cloud.utils.rest.HttpStatusCodeHelperTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in 
com.cloud.utils.rest.HttpStatusCodeHelperTest
Running com.cloud.utils.rest.RESTServiceConnectorTest
2016-03-17 08:17:41,686 DEBUG [utils.rest.RESTServiceConnector] (main:) 
Executing retrieve object on /somepath
2016-03-17 08:17:41,686 DEBUG [utils.rest.BasicRestClient] (main:) Executig GET 
request on https://localhost:443/somepath
2016-03-17 08:17:41,696 DEBUG [utils.rest.RESTServiceConnector] (main:) 
Executed request: GET /

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread rafaelweingartner

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

https://github.com/apache/cloudstack/pull/780#discussion_r56508389
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -3026,11 +3031,16 @@ public VmStatsEntry getVmStat(final Connect conn, 
final String vmName) throws Li
 try {
 dm = getDomain(conn, vmName);
 final DomainInfo info = dm.getInfo();
+final MemoryStatistic[] mems = dm.memoryStats(NUMMEMSTATS);
  //number of memory statistics required.
 
 final VmStatsEntry stats = new VmStatsEntry();
+
 stats.setNumCPUs(info.nrVirtCpu);
 stats.setEntityType("vm");
 
+stats.setMemoryKBs(info.maxMem);
+stats.setTargetMemoryKBs(info.memory);
+stats.setIntFreeMemoryKBs((double) mems[0].getValue());
--- End diff --

the same problem pointed out by @swill at line 3128, may happen here.


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

Re: External fork of Cloudstack

2016-03-19 Thread Sam Ruby


On Fri, Mar 18, 2016 at 4:37 AM, Will Stevens  wrote:


I may be thinking too far outside the box, but hear me out as this is
likely the best way to satisfy everyone's requirements.

Recap: The community needs additional github permissions in order to
integrate CI in order to maintain code quality.  The ASF does not have
enough granular control via github to give permissions on the
apache/cloudstack repository without giving the permissions across the
entire github apache org, which they are presently not comfortable with.

What if we did the following:
- Setup the 'cloudstack' github org so both the ASF and the community have
'owner' role representation.
- The apache/cloudstack repo is transferred to the cloudstack/cloudstack
repo.  This will move all of the PRs and everything over to the
cloudstack/cloudstack repo and will also setup redirection from
apache/cloudstack to cloudstack/cloudstack.
- This allows for the ASF and the community to work together to establish
the github permissions which make the most sense for the cloudstack project
without being bound by its implications on other projects.
- The official ASF repo would still be the source of truth and the
cloudstack/cloudstack repo would be a mirror of it.  There are probably
some details in this that we will need to address to make sure everything
is consistent with the ASF requirements.
- There will only be one cloudstack repository on which to contribute as a
community member, so there will be no confusion introduced and there will
be no segmentation of the community.
- The cloudstack/cloudstack repo would still be an official ASF project, so
no need for rebranding or worrying about the unpleasant logistics of a
"fork".

I am sure I have not thought through all the details and I am sure there
are some gotchas that we have to sort out, but I think this is a real
viable stepping stone towards being able to satisfy both parties
requirements while keeping the community strong and headed in the same
direction.

What do you all think?


+1

I'm pleased to see this being discussed on the dev list; and I'm ashamed 
that the board hasn't been more responsive.  Suffice it to say that this 
issue now has the board's attention.


On one hand, I'm a bit concerned that things are moving too quickly; and 
on the other hand I feel that it is time to rip the bandage off.  So I 
would like to simultaneously encourage you (collectively) to think 
further outside of the box, and yet not be too impatient despite the 
previous lack of response.  I'm the one that pushed through the approval 
of the Whimsy experiment, and I'm willing to help here.


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.


Be aware that perception matters.  If you go to 
https://github.com/cloudstack/cloudstack, you will see in small print 
"forked from apache/cloudstack" and then in slightly larger font "Mirror 
of Apache Cloudstack".  There should be an edit link on the latter for 
the owners of the organization, I'd like to discuss what should be there.


I personally believe that the ASF has a demonstrable interest in being 
able to establish provenance, but I don't believe that taking over 
control of the ability of projects to set up Travis and other 
integrations is a necessary consequence of that.  But overall I agree 
that if granularity of control for a single GitHub organization is an 
issue, then having multiple GitHub organizations needs to be explored as 
an option.


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.


- Sam Ruby

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

2016-03-19 Thread Nux!

+1 (binding)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Will Stevens" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 18 March, 2016 22:44:45
> Subject: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'

> We are discussing this proposal in 3 or 4 threads, so I will not try to
> recap everything.  Instead I will try to give a brief overview of the
> problem and a proposal for solving it.
> 
> *Problem:*
> The Apache CloudStack community needs additional github permissions in
> order to integrate CI for the purpose of maintaining code quality.  The ASF
> does not have enough granular control via the 'apache' github organization
> to give the 'apache/cloudstack' repository the needed permissions.
> 
> *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'.
> 
> The developer workflow and commit workflow will remain unchanged.  The
> canonical ASF repository (git://git.apache.org/cloudstack.git) will remain
> the source of truth and commits will be made to that repository.
> 
> Please ask if anything is unclear or needs to be better defined in order
> for you to cast a vote.

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

2016-03-19 Thread Wido den Hollander

+1 (binding)

> Op 18 mrt. 2016 om 23:44 heeft Will Stevens  het 
> volgende geschreven:
> 
> We are discussing this proposal in 3 or 4 threads, so I will not try to
> recap everything.  Instead I will try to give a brief overview of the
> problem and a proposal for solving it.
> 
> *Problem:*
> The Apache CloudStack community needs additional github permissions in
> order to integrate CI for the purpose of maintaining code quality.  The ASF
> does not have enough granular control via the 'apache' github organization
> to give the 'apache/cloudstack' repository the needed permissions.
> 
> *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'.
> 
> The developer workflow and commit workflow will remain unchanged.  The
> canonical ASF repository (git://git.apache.org/cloudstack.git) will remain
> the source of truth and commits will be made to that repository.
> 
> Please ask if anything is unclear or needs to be better defined in order
> for you to cast a vote.

[GitHub] cloudstack pull request: CLOUDSTACK-9297: delete snapshot without ...

2016-03-19 Thread mike-tutkowski

Github user mike-tutkowski commented on the pull request:

https://github.com/apache/cloudstack/pull/1441#issuecomment-197929660
  
Hi @rafaelweingartner Thanks for the comments.

Just wanted to point out that if the revertSnapshot method is invoked, then 
that is actually a failure of the canHandle method to inform the calling code 
to not call the revertSnapshot method, so that's why the decision was made to 
throw an exception.

I see returning true as your revert was successful and returning false as 
it failed (but it was OK for you to ask us to revert because canHandle properly 
told you that you could do so).


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Mattmann, Chris A (3980)

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.

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 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.
>
>Put bluntly, the decision is no, and it is in the hands of the ASF Infra@
>and based on
>discussions I’ve seen on public lists there and on board@ and part of the
>board
>meeting yesterday, Infra@ is not opening up the Whimsy experiment to other
>PMCs
>as of yet. They aren’t ready to declare an SLA; they aren’t ready for
>potential
>other PMCs to ask to use it too and for others to start thinking that
>capab

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

2016-03-19 Thread Daan Hoogland

Chris,

I don't see how cloudstack/cloudstack can be a problem to the foudation
except for the PMC as they will be left with managing keeping it in sync.

I also don't see how a fork can be against apache policy as anyone is
allowed to fork the software at any time. We as PMC are no exception
(wisdom left out of the equation)

thirdly, As for the concern on whether these moves are done by 'part of the
PMC' or not: I think I can savely say I am one of the proponent of keeping
as much under the foundation umbrella as possible but I have hear no sounds
of anybody opposing the ongoing experiments.

I am happy to see board member mixing in our discussions from time to time.
Trying not to sound like I am complaining now, I wouldn't complain if it
happened a bit more often. BTW I have had problems adding an issue to
cloudstack/cloudstack as well, but I guess that's me not being a github
guru.

On Thu, Mar 17, 2016 at 5:33 PM, Tutkowski, Mike 
wrote:

> I see your concern, Chris.
>
> Yes, the community will continue to discuss. Hopefully others will join in
> with their views.
> 
> From: Mattmann, Chris A (3980) 
> Sent: Thursday, March 17, 2016 10:16 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 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.
>
> 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 d

Re: [IMPORTANT] Huge Github PR Backlog

2016-03-19 Thread Jeff Hair

Sometimes they might seem old, but when interaction just sort of... stops,
it can be hard to keep track of what is going on with the PRs. Currently we
have 6 or 7 open PRs that no one has commented on or looked at in months.
Two were recently updated with integration test results at least. One is
missing a unit test that I still need to write, but the others are (were)
ready to go. Every few weeks I go and rebase them and then they sit there
for a few more weeks. Rinse, repeat it seems like...

What scope is needed for the testing? Is the plan to use some CI then
manually test, in addition to the unit tests? Or are in some cases unit
tests good enough?

On Thu, Mar 17, 2016 at 9:18 PM, Remi Bergsma 
wrote:

> PRs needs to be tested obviously, that is the current impediment. The
> moment you test a PR, you get current master and merge the PR and test that
> result. Once it’s OK, merge it to master and take next one, etc. I wouldn’t
> start rebasing, as you’ll have a lot of work and will need to keep doing
> that. Git is pretty good in merging stuff so it will work quite often. Or
> else result in some PRs not being able to merge due to conflicts. Those
> need to be resolved.
>
> Another thing: I would say 50% (if not more) is never going to be merged
> because they’re too old, abandoned, broken, etc.
>
> Regards,
> Remi
>
>
>
>
>
> On 17/03/16 22:10, "Simon Weller"  wrote:
>
> >If we ask for each PR to be rebased with master, we need to commit as a
> team to actually working through them rapidly, as obviously rebasing is
> significant work in a lot of cases.
> >
> >Just my 2 cents.
> >
> >- Si
> >
> >
> >
> >
> >
> >From: ilya 
> >Sent: Thursday, March 17, 2016 4:06 PM
> >To: dev@cloudstack.apache.org
> >Subject: [IMPORTANT] Huge Github PR Backlog
> >
> >Hi Folks,
> >
> >What can we do about PR backlog in GitHub? As we all know, it will be
> >very difficult to merge the changes - as things will get out of sync.
> >
> >Feedback is welcome,
> >
> >Thanks,
> >ilya
>

[GitHub] cloudstack pull request: CLOUDSTACK-9003 Make VirtualMachineName i...

2016-03-19 Thread ProjectMoon

Github user ProjectMoon closed the pull request at:

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


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

[GitHub] cloudstack pull request: CLOUDSTACK-9298: Improve performance of r...

2016-03-19 Thread rafaelweingartner

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1425#issuecomment-198519031
  
@nvazquez that is great. I can give an LGTM now.


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

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-197939345
  
@rafaelweingartner I don't mind waiting a bit, but runtime exceptions need 
to be taken seriously.  As the 4.9 RM, it is my responsibility to make sure 
this type of stuff is sorted out BEFORE it gets merged into master.  I welcome 
others to give feedback, but I would recommend that we do a `git revert` on 
this merge and at the very least code defensively around the runtime exceptions.


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

[GitHub] cloudstack pull request: Is the project attempting a fork on Githu...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/1442#issuecomment-197892304
  
@chrismattmann would you mind closing this PR since we can't and we don't 
need extra clutter in here.  Thx.


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Daan Hoogland

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.

-- 
Daan

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

2016-03-19 Thread Ahmad Emneina

+BCC: David Nalley for possible guidance.

Apache infra stated that 'The VP' dictated the policy to not allow
'repo:status' across the board for projects. Has anyone tried to engage the
VP, in order to get them to have a closer look at this policy? It appears
to be no way to exploit that function maliciously... so hopefully they
could allow for this to be enabled.

$0.02

On Thu, Mar 17, 2016 at 4:46 PM, Erik Weber  wrote:

> On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann 
> wrote:
>
> >
> > >> 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.
> >
> >
> This is not the result of people getting together and saying 'hey, we
> should fork and work somewhere else, that'd be fun!', but rather
> 'hey, we are currently unable to do what we need to do, and none of our
> attempts of getting assistance have resulted in anything. what can we do?'.
>
> On January 27th 2016, Schuberg Philis (SBP), a company with many CloudStack
> contributors/committers/pmcs, announced that they are 'jumping ship,
> forking the code and going their own way'.  (that's my wording, not theirs)
>
> Take a look at our git commit history before and after that date. Notice
> anything?
> Most, if not all, are trivial commits to fix typos, simple mistakes etc.
> and not code changes.
>
> This may be rude to everyone else, but the fact is that after 4.5 SBP
> (there are a few exceptions) has done more or less everything when it comes
> to testing code and gatekeeping the code base. And they did a very good job
> at it.
> Frankly I am surprised they even coped with it that long.
>
> Apache CloudStack now has a fork (Cosmic), that's not bound by ASF policies
> and it's lack of progress when it comes to providing the tools necessary.
>
> When (or if -- with their own governing they don't have to call it a
> specific version) SBP release an official version of Cosmic, it would
> surprise me if not a lot of CloudStack users would atleast try it out.
> I am pretty sure that I am going to.
>
> And wha-bang, there (potentially) goes your community, because there
> already is a better option out there.
>
>
>
> > 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.
> >
> >
> The answer would most likely be 'anyone and everyone'.
> Contrary to what you might believe, this is being done to /help/
> CloudStack, not hurt it. Atleast that is my intention by participating.
>
> In case you are unfamiliar with Apache CloudStack, it is a beast.
> Unlike many typical ASF projects you cannot just unpack the tarball, run
> 'make test', wait a few minutes and have it properly tested.
> Testing Apache CloudStack requires a broad variety of physical hardware,
> network appliances, storage solutions and least but most importantly pretty
> much every hypervisor that is being used out there.
>
> A subset of the test tasks we have take multiple hours to run and only
> tests a small fraction of the total codebase.
>
> Pre 4.6, the Apache CloudStack community had a little to loose discipline
> on committing to the codebase.
> Testing was optional, and hardly done.
>
> We had multiple versions that had major flaws in them, discovered right
> after release as people tried to use it -- even for the most basic
> operations.
>
> For the 4.6 release we decided that from now on, every commit would have to
> be looked through by two different persons, saying they approve it, and
> tested by a minimum of one.
>
> And it worked, the voting process improved, we released rapidly and with
> far less issues than previously (no software is bug free after all).
>
> As mentioned, we require that code changes (be it improvements, fixes or
> new features) are tested before they are allowed to be committed.
>
> Which means that anyone wanting to interact (with code) have to do it
> theirselves at the moment, and that is _NOT_ an easy task.
> Which again means that no matter how good your intention is, your PR is not
> going be merged.
> What kind of Community treatment is that?
>
>
> The way I see it there is only one solution to this -- we need better
> testing, and to automate that we need more access to GitHub.
>
> There are two ways to do that;
> 1) By being granted certain permissions to the apache/cloudstack
> repository.
> 2) By doing it somewhere else where we have those permissions.
>
> Will Stevens asked infra [1] for a small subset of permissions -- none of
> which should be any real risk for disasters, and got rejected.
> That rules out option #1.
>
> This turned out to be a long, and emotional email, please don't take any
> grunts personally -- they are not meant to be.
>
> [1] https://issues.apache.org/jira/browse/INFRA-11429
>
>
> --
> Erik
>

Re: External fork of Cloudstack

2016-03-19 Thread Will Stevens

Hi Sam.  Thank you very much for joining the conversation.  We look forward
to working with you and appreciate your guidance on the matter.

Just a quick note regarding my suggestion and the 'perception' concern you
raised.  I am actually proposing that we do an ownership transfer of the
'apache/cloudstack' repo to the 'cloudstack/cloudstack' repo.  This means
that it will not be a fork of 'apache/cloudstack' because if you tried to
access that repo it would redirect to 'cloudstack/cloudstack', it will only
show the "Mirror of Apache CloudStack".

Other benefits of this is that all the PRs (180+) will automatically be
moved to the 'cloudstack/cloudstack' repo making it easier for everyone
involved to understand where people are expected to open PRs.

I will review what is being done with Whimsy to get a better idea how that
project is being handled.

Thanks again for joining this conversation...

*Will STEVENS*
Lead Developer

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

On Fri, Mar 18, 2016 at 11:27 AM, Sam Ruby  wrote:

> On Fri, Mar 18, 2016 at 4:37 AM, Will Stevens 
> wrote:
>
>>
>> I may be thinking too far outside the box, but hear me out as this is
>> likely the best way to satisfy everyone's requirements.
>>
>> Recap: The community needs additional github permissions in order to
>> integrate CI in order to maintain code quality.  The ASF does not have
>> enough granular control via github to give permissions on the
>> apache/cloudstack repository without giving the permissions across the
>> entire github apache org, which they are presently not comfortable with.
>>
>> What if we did the following:
>> - Setup the 'cloudstack' github org so both the ASF and the community have
>> 'owner' role representation.
>> - The apache/cloudstack repo is transferred to the cloudstack/cloudstack
>> repo.  This will move all of the PRs and everything over to the
>> cloudstack/cloudstack repo and will also setup redirection from
>> apache/cloudstack to cloudstack/cloudstack.
>> - This allows for the ASF and the community to work together to establish
>> the github permissions which make the most sense for the cloudstack
>> project
>> without being bound by its implications on other projects.
>> - The official ASF repo would still be the source of truth and the
>> cloudstack/cloudstack repo would be a mirror of it.  There are probably
>> some details in this that we will need to address to make sure everything
>> is consistent with the ASF requirements.
>> - There will only be one cloudstack repository on which to contribute as a
>> community member, so there will be no confusion introduced and there will
>> be no segmentation of the community.
>> - The cloudstack/cloudstack repo would still be an official ASF project,
>> so
>> no need for rebranding or worrying about the unpleasant logistics of a
>> "fork".
>>
>> I am sure I have not thought through all the details and I am sure there
>> are some gotchas that we have to sort out, but I think this is a real
>> viable stepping stone towards being able to satisfy both parties
>> requirements while keeping the community strong and headed in the same
>> direction.
>>
>> What do you all think?
>>
>
> +1
>
> I'm pleased to see this being discussed on the dev list; and I'm ashamed
> that the board hasn't been more responsive.  Suffice it to say that this
> issue now has the board's attention.
>
> On one hand, I'm a bit concerned that things are moving too quickly; and
> on the other hand I feel that it is time to rip the bandage off.  So I
> would like to simultaneously encourage you (collectively) to think further
> outside of the box, and yet not be too impatient despite the previous lack
> of response.  I'm the one that pushed through the approval of the Whimsy
> experiment, and I'm willing to help here.
>
> 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.
>
> Be aware that perception matters.  If you go to
> https://github.com/cloudstack/cloudstack, you will see in small print
> "forked from apache/cloudstack" and then in slightly larger font "Mirror of
> Apache Cloudstack".  There should be an edit link on the latter for the
> owners of the organization, I'd like to discuss what should be there.
>
> I personally believe that the ASF has a demonstrable interest in being
> able to establish provenance, but I don't believe that taking over control
> of the ability of projects to set up Travis and other integrations is a
> necessary consequence of that.  But overall I agree that if granularity of
> control for a single GitHub organization is an issue, then having multiple
> GitHub organizations needs to be explored as an option.
>
> How can I help?  I'd like to bring this proposal back to the board for
> wider review so that nothing

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

2016-03-19 Thread Paul Angus

+1 Sounds like a plan.

Paul Angus
VP Technology   ,   ShapeBlue

t:  @cloudyangus

e:  paul.an...@shapeblue.com|  
w:  www.shapeblue.com

From: John Burwell [mailto:john.burw...@shapeblue.com]
Sent: Friday, March 18, 2016 1:32 PM
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...)

All,

+1 to Will’s proposal/approach. All we are really talking about is rehoming the 
apache/cloudstack repository mirror to cloudstack/cloudstack. The canonical 
repository would remain the official Apache git repository hosted on Apache 
owned hardware. Therefore, we would maintain our current PR merge process [1] 
that merges the PR branch locally and pushes it to the Apache git repository. 
If re-home the Github mirror, I think it should remain read-only mirror where 
we have the ability to grant privileges to our CI system to close PRs.

I would also add that currently, the cloudstack organization is owned by 
individuals who happen to be Apache CloudStack PMC members and committers. In 
my opinion, in order for it to work in the long term, we would need a 
governance policy that transferred ownership to our PMC or Apache Infra. Our 
interest is not the create a fork, but provide our community with the ability 
to exploit an extremely powerful tool for collaboration and source management.

Finally, I believing having a dedicated cloudstack Github organization may be a 
means to expand the community. Currently, we have no place to easily host 
subprojects (e.g. cloudmonkey, marvin, etc). With a dedicated organization, we 
could consider inviting other complementary projects such configuration 
management recipes/playbooks and language clients to place their repos in the 
cloudstack organization. For users, they would have a central, community 
sponsored place to find all things cloudstack and we further improve our 
collaboration with the authors/maintainers of these projects.

In short, I think Will lays out the approach very clearly. There is **no** 
intention or action to fork Apache CloudStack. Instead, we simply want to 
re-home apache/cloudstack repository mirror to cloudstack/cloudstack without 
changing any other processes. Most importantly, this change can be made without 
compromising the provenance of the codebase because, as we do today, commits 
would only occur on the Apache git repo.

Thanks,
-John

[1]: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655

>

[ShapeBlue]

John Burwell

ShapeBlue

d:

+44 (20) 3603 0542 | s: +1 (571) 403-2411 

e:

john.burw...@shapeblue.com | t: 

 |

w:

www.shapeblue.com

a:

53 Chandos Place, Covent Garden London WC2N 4HS UK

[cid:image6929de.png@d359d3b7.49a57074]

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.

On Mar 18, 2016, at 3:40 AM, Sebastien Goasguen 
mailto:run...@gmail.com>> wrote:
>
> Top posting because keeping track is going to be hard.
>
>
> Remi and I have talked several times with David about GitHub access and so 
> far the answer has been no.
>
> There are several issues in my understanding:
>
> - apache on github is one single org, so if you get some write permission in 
> the org then you could potentially harm other projects. that means that ASF 
> needs to figure out how to use github teams to map our projects inside a 
> single org (follow me…). They appear to be working on it, but no ETA on when 
> this will happen.
>
> - location of the canonical repo. This in large a legal issue. If CloudStack 
> were sued at some point, can we prove without doubt who made the commit. 
> Until now, ASF has the canonical repo on its own hardware which means all 
> sorts of logs including push logs. Some folks at the ASF think that with a 
> project on github they would not get the same level of guaranteed provenance. 
> ( I have tr

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

2016-03-19 Thread Sebastien Goasguen

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.

Best,

-Sebastien

> On 17 Mar 2016, at 00:04, Chris Mattmann  wrote:
> 
> Hi,
> 
> Sorry about my crude way of filing a PR for this, but I heard
> information about the Apache Cloudstack PMC actively
> discussing managing the project with GitHub as the primary source
> in a different organization than the github.com/apache/ org.
> 
> Can someone clarify this for me? Clearly wearing my board hat,
> this is not something we allow for any of our ASF projects.
> 
> Cheers,
> Chris “board hat on” Mattmann
> 
> 
>

[GitHub] cloudstack pull request: CLOUDSTACK-9285 - Agent throws an excepti...

2016-03-19 Thread kiwiflyer

Github user kiwiflyer commented on the pull request:

https://github.com/apache/cloudstack/pull/1429#issuecomment-198513018
  
Closing this PR, as this issue has been address more cleanly in my other PR 
against 4.7 - https://github.com/apache/cloudstack/pull/1430


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

Build failed in Jenkins: build-master-slowbuild #3484

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.838s]
[INFO] Apache CloudStack . SUCCESS [3.485s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.060s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.245s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.984s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.103s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.988s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [26.876s]
[INFO] Apache CloudStack API . SUCCESS [1:50.032s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [17.589s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.601s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.091s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.357s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.876s]
[INFO] Apache CloudStack Core  SUCCESS [1:20.260s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.979s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.259s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.353s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.547s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.647s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [26.240s]
[INFO] Apache CloudStack Server .. SUCCESS [4:14.837s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [37.219s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.517s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.781s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.067s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.434s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.082s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.208s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.462s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.810s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [21.898s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [23.383s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.020s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.655s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.996s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.965s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.265s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.028s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[36.521s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [18.184s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.846s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.792s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.753s]
[INFO] Apache Cloud

[GitHub] cloudstack pull request: CLOUDSTACK-9297 - Reworked logic in Stora...

2016-03-19 Thread rafaelweingartner

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1441#issuecomment-197970382
  
Ok @mike-tutkowski, now I believe I understand a little bit more of the 
code.

You are reusing a method that already exist and returns the 
StrategyPriority (you did not create that method to suffice your code). I was 
misled by the name of the method, when I first saw it, I thought that the 
method was used solely to check if it can or cannot proceed with the snapshot 
when in fact it is used to do much more.

I believe "getSnapshotStrategy" would be a more suitable name.

Now that I understand what we have there, I am ok with that conditional as 
it
 is.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9297 - Reworked logic in Stora...

2016-03-19 Thread rafaelweingartner

Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/1441#issuecomment-197948544
  
I understand that your point that some other classes can overwrite that 
method and may return other elements of the enum. However, I do not see 
anything else in the code that used the âcanHandleâ method return that uses 
the returned value. I mean, it is used in the ârevertSnapshotâ method at 
line 285, but it only checks if the return is equal to 
âStrategyPriority.CANT_HANDLEâ and then throws an exception if it is. To 
me, that is the same as if the method were returning a boolean value.


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

[GitHub] cloudstack pull request: CLOUDSTACK-9283: add pid to java argument...

2016-03-19 Thread ustcweizhou

Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1409#issuecomment-197771350
  
LGTM
works fine in our internal version.




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

[GitHub] cloudstack pull request: CLOUDSTACK-8830 : VM snapshot creation fa...

2016-03-19 Thread bvbharatk

Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1377#issuecomment-197828321
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 106
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=14
 Skipped=4

**The follwing tests have known issues**
test_vpc_remote_access_vpn
test_vpc_site2site_vpn
test_01_test_vm_volume_snapshot
test_02_vpc_privategw_static_routes
test_03_rvpc_privategw_static_routes
test_04_change_offering_small
ContextSuite context=TestNiciraContoller>:setup
test_01_primary_storage_iscsi
test02_internallb_haproxy_stats_on_all_interfaces
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
ContextSuite context=TestDeployVM>:setup
test_04_extract_template
test_04_extract_Iso
test_07_list_default_iso


_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* integration.smoke.test_privategw_acl.TestPrivateGwACL

 * test_01_vpc_privategw_acl Failing since 2 runs

* integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange

 * test_dedicateGuestVlanRange Failing since 6 runs


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot
integration.smoke.test_snapshots.TestSnapshotRootDisk

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_volumes.TestCreateVolume
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


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

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

2016-03-19 Thread Will Stevens

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

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

2016-03-19 Thread Daan Hoogland

On Fri, Mar 18, 2016 at 4:37 AM, Will Stevens  wrote:

> I may be thinking too far outside the box, but hear me out as this is
> likely the best way to satisfy everyone's requirements.
>
> Recap: The community needs additional github permissions in order to
> integrate CI in order to maintain code quality.  The ASF does not have
> enough granular control via github to give permissions on the
> apache/cloudstack repository without giving the permissions across the
> entire github apache org, which they are presently not comfortable with.
>
> What if we did the following:
> - Setup the 'cloudstack' github org so both the ASF and the community have
> 'owner' role representation.
> - The apache/cloudstack repo is transferred to the cloudstack/cloudstack
> repo.  This will move all of the PRs and everything over to the
> cloudstack/cloudstack repo and will also setup redirection from
> apache/cloudstack to cloudstack/cloudstack.
> - This allows for the ASF and the community to work together to establish
> the github permissions which make the most sense for the cloudstack project
> without being bound by its implications on other projects.
> - The official ASF repo would still be the source of truth and the
> cloudstack/cloudstack repo would be a mirror of it.  There are probably
> some details in this that we will need to address to make sure everything
> is consistent with the ASF requirements.
> - There will only be one cloudstack repository on which to contribute as a
> community member, so there will be no confusion introduced and there will
> be no segmentation of the community.
> - The cloudstack/cloudstack repo would still be an official ASF project, so
> no need for rebranding or worrying about the unpleasant logistics of a
> "fork".
>
> I am sure I have not thought through all the details and I am sure there
> are some gotchas that we have to sort out, but I think this is a real
> viable stepping stone towards being able to satisfy both parties
> requirements while keeping the community strong and headed in the same
> direction.
>
> What do you all think?

Will, I think it makes sense for the foundation to have a github
organisation per project, which is basically what you are saying. An
alternative might be sub- or nested organisations which I am sure, is a
thing the people at github must have thought about at some time. If
foundation policy at all allows for this we must.



-- 
Daan

Re: External fork of Cloudstack

2016-03-19 Thread Sam Ruby

On Fri, Mar 18, 2016 at 1:09 PM, Will Stevens  wrote:
> Hi Sam.  Thank you very much for joining the conversation.  We look forward
> to working with you and appreciate your guidance on the matter.
>
> Just a quick note regarding my suggestion and the 'perception' concern you
> raised.  I am actually proposing that we do an ownership transfer of the
> 'apache/cloudstack' repo to the 'cloudstack/cloudstack' repo.  This means
> that it will not be a fork of 'apache/cloudstack' because if you tried to
> access that repo it would redirect to 'cloudstack/cloudstack', it will only
> show the "Mirror of Apache CloudStack".
>
> Other benefits of this is that all the PRs (180+) will automatically be
> moved to the 'cloudstack/cloudstack' repo making it easier for everyone
> involved to understand where people are expected to open PRs.

I may have been unclear.  I think we are talking about two separate things.

Regarding the "organization" (the first cloudstack in
cloudstack/cloudstack), if there is a technical means to grant you the
access you should have to control your repository(-ies), then staying
in apache would arguably be better; but so far that avenue has been
explored and looks to be a dead end.  So moving to a separate
organization makes sense.  I think I would prefer that organization to
be apache-cloudstack for reasons that I am about to get to, but I'm
not stuck on that.

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.

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, and there is technically nothing
wrong with what is there now; but I claim that we can and should do
better.  From a perception perspective, it is the difference between
individuals on the CloudStack PMC leaving the ASF, and the ASF
expanding support for repositories hosted on GitHub.  I'd like to
pursue the latter, and if there are any obstacles (technical or
otherwise) would like help flatten those issues.

- Sam Ruby

> I will review what is being done with Whimsy to get a better idea how that
> project is being handled.
>
> Thanks again for joining this conversation...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Fri, Mar 18, 2016 at 11:27 AM, Sam Ruby  wrote:
>
>> On Fri, Mar 18, 2016 at 4:37 AM, Will Stevens 
>> wrote:
>>
>>>
>>> I may be thinking too far outside the box, but hear me out as this is
>>> likely the best way to satisfy everyone's requirements.
>>>
>>> Recap: The community needs additional github permissions in order to
>>> integrate CI in order to maintain code quality.  The ASF does not have
>>> enough granular control via github to give permissions on the
>>> apache/cloudstack repository without giving the permissions across the
>>> entire github apache org, which they are presently not comfortable with.
>>>
>>> What if we did the following:
>>> - Setup the 'cloudstack' github org so both the ASF and the community have
>>> 'owner' role representation.
>>> - The apache/cloudstack repo is transferred to the cloudstack/cloudstack
>>> repo.  This will move all of the PRs and everything over to the
>>> cloudstack/cloudstack repo and will also setup redirection from
>>> apache/cloudstack to cloudstack/cloudstack.
>>> - This allows for the ASF and the community to work together to establish
>>> the github permissions which make the most sense for the cloudstack
>>> project
>>> without being bound by its implications on other projects.
>>> - The official ASF repo would still be the source of truth and the
>>> cloudstack/cloudstack repo would be a mirror of it.  There are probably
>>> some details in this that we will need to address to make sure everything
>>> is consistent with the ASF requirements.
>>> - There will only be one cloudstack repository on which to contribute as a
>>> community member, so there will be no confusion introduced and there will
>>> be no segmentation of the community.
>>> - The cloudstack/cloudstack repo would still be an official ASF project,
>>> so
>>> no need for rebranding or worrying about the unpleasant logistics of a
>>> "fork".
>>>
>>> I am sure I have not thought through all the details and I am sure there
>>> are some gotchas that we have to sort out, but I think this is a real
>>> viable stepping stone towards being able to satisfy both parties
>>> requirements while keeping the community strong and headed in the same
>>> direction.
>>>
>>> What do you all th

Build failed in Jenkins: build-master-slowbuild #3483

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.769s]
[INFO] Apache CloudStack . SUCCESS [2.068s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.774s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [18.558s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:32.155s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.104s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.882s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [28.382s]
[INFO] Apache CloudStack API . SUCCESS [1:47.563s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [17.492s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.551s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.084s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.181s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [23.993s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.880s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.089s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [37.081s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.191s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.724s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.849s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.045s]
[INFO] Apache CloudStack Server .. SUCCESS [4:13.110s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [36.585s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.843s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:22.467s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.074s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.442s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.907s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [47.222s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.408s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [26.435s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [31.805s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [22.653s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.530s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.952s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [7.500s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.966s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.560s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.310s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.578s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.277s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.540s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [14.730s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.501s]
[INFO] Apache Cloud

Re: [PROPOSAL] Minimum Viable CI Integration

2016-03-19 Thread Bharat Kumar

Hi Remi,

I have moved most of the failing tests to known issues, and modified the 
reports accordingly. Now we should see only the passed test suits.
When we see a failed test in multiple runs we can move it to known issues and 
start fixing them.

Thanks,
Bharat.

On 15-Mar-2016, at 4:36 PM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>> wrote:

Hi Bharat

I’d say remove the tests that fail, to get a report with only tests that pass.

Regards,
Remi

From: Bharat Kumar 
mailto:bharat.ku...@accelerite.com>>
Date: Tuesday 15 March 2016 at 10:40
To: Remi Bergsma 
mailto:rberg...@schubergphilis.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Bharat Kumar 
mailto:bharat.ku...@accelerite.com>>
Subject: Re: [PROPOSAL] Minimum Viable CI Integration

Hi Remi,

Thanks for the inputs.

I agree with you, May be i need to modify the CI report and not report if any 
of the known issues fail.  We can still have the known_issues header to track 
what needs to be fixed.

Thanks,
Bharat.


On 15-Mar-2016, at 1:26 PM, Remi Bergsma 
mailto:rberg...@schubergphilis.com>> wrote:

Hi Bharat,

I’d suggest removing all tests that fail for some reason, not being an error in 
the PR. This will result in a smaller set of tests that “always pass”. Once a 
test doesn’t pass anymore, we know the PR has an issue. Then your CI system 
provides value.

Right now, there are so many failures that soon people don’t even care to look 
at it. Once we have a stable set that works, we can start fixing tests and 
1-by-1 add them to the mix.

Just my $0.02

Regards,
Remi



On 15/03/16 07:06, "Bharat Kumar" 
mailto:bharat.ku...@accelerite.com>> wrote:

Hi Paul,

I totally agree with you. For now we should ignore the tests which fail all the 
time while we try to address them.

Now that we have a CI in place we need go and fix issues with the tests.

I have tried to identify a few of them and have  mentioned them in the known 
issues part of the CI test result.

Some of the test cases are not generic enough to run on different CIs. For 
example the test_vpc_vpn.py
hardcodes the test data in the test itself, which is not a good thing. 
Generally this kind of data is added the the test_data.py file and is reused .
This gives us a chance to modify it to suit the needs of the a particular CI.

So for fixing these issues we need test data to identify the issue. Each of the 
CI run gives these details, the test run info, test results and the management 
server logs( via the drop box link in the report).
With this info any one in the community can access this data and start fixing 
them. This way we can progressively track and improve the health of the release.

So i think we should continue posting these results, so that people can analyse 
the result and come back with inputs related to incorrect test cases.

—Thanks
Bharat.


On 15-Mar-2016, at 1:24 AM, Paul Angus 
mailto:paul.an...@shapeblue.com>>
 wrote:

Cool. Thanks Will.

@Bharat - the work that you're trying to do is great, but until the Marvin 
tests have been gone through and 'fixed' the information being put into PRs is 
misleading.

No one knows why these failures are occurring, and it's very likely giving both 
false positives and false negatives.
You should probably hold off altogether or isolate the good tests and only run 
them.

I plan to set up a wiki page (or two) with all of the tests listed, their 
purpose and other info such as if there are known to work (or not) when they 
were last checked. You're welcome to make a start on it if you wish.

For example (false negative):
--
nosetests --with-marvin --marvin-config=/tmp/te2.cfg --hypervisor=KVM -a 
tags=advanced,required_hardware=true 
integration/component/test_acl_isolatednetwork.py
2016-01-30 07:36:30,488 - DEBUG - Parsing Test data successful
2016-01-30 07:36:30,488 - DEBUG - Payload: {'account': 'admin', 'command': 
'listUsers', 'response': 'json'}
2016-01-30 07:36:30,488 - DEBUG - Sending GET Cmd : listUsers===
2016-01-30 07:36:30,521 - DEBUG - Response : [{username : u'admin', account : 
u'admin', domainid : u'4895ddbe-bfac-11e5-be38-06a910012727', firstname : 
u'admin', created : u'2016-01-20T19:33:19+', lastname : u'cloud', apikey : 
u'oiD-zcjZw7dsPq8yrjarls3sCtHV0E8FQYRpNXlmEx0ssJ1fKFuCySYL4vLHVmlLA5E3PF7_hSnTND_eSRyK_A',
 domain : u'ROOT', secretkey : 
u'gLz6lDVFch6ayBAB-8SMZ-RPiOgJTEVJmNgnAMdv36O6eMUKUN6R-Q-3ZtYJUH84jye-5q6Qpxf5WOtSuG8WtA',
 iscallerchilddomain : False, state : u'enabled', accounttype : 1, id : 
u'a8b21230-bfac-11e5-be38-06a910012727', isdefault : True, accountid : 
u'a8b2063c-bfac-11e5-be38-06a910012727'}]
2016-01-30 07:36:30,521 - DEBUG -  Test Client Creation Successful 
---

Nothing actually happens ?!
Same with test_acl_listvm.py

Example(false positive-failure is in marvin test code):
-

[GitHub] cloudstack pull request: Is the project attempting a fork on Githu...

2016-03-19 Thread runseb

Github user runseb commented on the pull request:

https://github.com/apache/cloudstack/pull/1442#issuecomment-197508210
  
@chrismattmann how about you send email to private@ before sending some 
dummy PR.
thank you


---
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: Build failed in Jenkins: build-master-slowbuild #3368

2016-03-19 Thread Raja Pullela

Daan, Will,

I have tested Daan's original PR-1427, and it looks good.  I am running into a 
build issue with the 1438 - nothing related to the checkin.  Hope to resolve it 
later this weekend or on Monday.

Best,
Raja


-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: Thursday, March 17, 2016 2:19 AM
To: dev@cloudstack.apache.org
Subject: Re: Build failed in Jenkins: build-master-slowbuild #3368

@Raja.  Actually, maybe test this one since it includes the same change as 
Daan's, but also includes a couple more changes.

I think only one of these should be merged.

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

*Will STEVENS*
Lead Developer

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

On Wed, Mar 16, 2016 at 4:42 PM, Will Stevens  wrote:

> @Raja, did you have a chance to test this?
>
> https://github.com/apache/cloudstack/pull/1427
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw 
> @CloudOps_
>
> On Wed, Mar 2, 2016 at 2:00 PM, Daan Hoogland 
> 
> wrote:
>
>> thanks Raja
>>
>> On Wed, Mar 2, 2016 at 7:48 PM, Raja Pullela 
>> > >
>> wrote:
>>
>> > Daan, I will try to test this out..
>> >
>> > -Original Message-
>> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> > Sent: Wednesday, March 2, 2016 11:57 PM
>> > To: dev 
>> > Subject: Fwd: Build failed in Jenkins: build-master-slowbuild #3368
>> >
>> > People, these were irritating me. I wrote a quick fix [1].
>> >
>> > Anyone feels like running a test on it?
>> >
>> > [1] https://github.com/apache/cloudstack/pull/1427
>> >
>> > -- Forwarded message --
>> > From: 
>> > Date: Wed, Mar 2, 2016 at 4:09 PM
>> > Subject: Build failed in Jenkins: build-master-slowbuild #3368
>> > To: dev@cloudstack.apache.org, nicolas.m.vazq...@gmail.com, 
>> > priti.sa...@clogeny.com, nitin.mahar...@gmail.com,
>> nicovazque...@gmail.com
>> >
>> >
>> > See 
>> > 
>> >
>> > --
>> > [...truncated 28679 lines...]
>> > [INFO]
>> > [INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ 
>> > cloud-quickcloud --- [INFO] [INFO] <<< 
>> > findbugs-maven-plugin:3.0.1:check
>> > (cloudstack-findbugs) @ cloud-quickcloud <<< [INFO] [INFO] --- 
>> > findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @
>> cloud-quickcloud
>> > --- [INFO] [INFO] --- cobertura-maven-plugin:2.6:instrument
>> (default-cli) @
>> > cloud-quickcloud --- [WARNING] No files to instrument.
>> > [INFO] NOT adding cobertura ser file to attached artifacts list.
>> > [INFO]
>> > [INFO] --- maven-resources-plugin:2.5:testResources
>> > (default-testResources) @ cloud-quickcloud --- [debug] execute 
>> > contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> > [INFO] skip non existing resourceDirectory <
>> >
>> http://jenkins.buildacloud.org/job/build-master-slowbuild/ws/quickclo
>> ud/src/test/resources
>> > >
>> > [INFO] Copying 3 resources
>> > [INFO] Copying 3 resources
>> > [INFO]
>> > [INFO] --- maven-compiler-plugin:3.2:testCompile 
>> > (default-testCompile) @ cloud-quickcloud --- [INFO] No sources to 
>> > compile [INFO] [INFO] --- maven-surefire-plugin:2.18.1:test 
>> > (default-test) @ cloud-quickcloud --- [INFO] [INFO] <<< 
>> > cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
>> > cloud-quickcloud <<< [INFO] [INFO] ---
>> cobertura-maven-plugin:2.6:cobertura
>> > (default-cli) @ cloud-quickcloud --- [INFO]
>> > ---
>> > -
>> > [INFO] Reactor Summary:
>> > [INFO]
>> > [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration 
>> > SUCCESS [1.742s] [INFO] Apache CloudStack
>> .
>> > SUCCESS [2.087s] [INFO] Apache CloudStack Maven Conventions Parent
>> 
>> > SUCCESS [0.775s] [INFO] Apache CloudStack Framework - Managed 
>> > Context
>> .
>> > SUCCESS [19.383s] [INFO] Apache CloudStack Utils 
>> > ... SUCCESS [1:30.165s] [INFO] Apache 
>> > CloudStack Framework ... SUCCESS [0.105s] 
>> > [INFO] Apache
>> CloudStack
>> > Framework - Event Notification .. SUCCESS [54.117s] [INFO] Apache 
>> > CloudStack Framework - Configuration ... SUCCESS [28.191s] 
>> > [INFO] Apache CloudStack API . SUCCESS 
>> > [1:50.059s] [INFO] Apache CloudStack Framework - REST 
>> >  SUCCESS [17.530s] [INFO] Apache CloudStack Framework - 
>> > IPC .
>> > SUCCESS [29.621s] [INFO] Apache CloudStack Cloud Engine 
>> >  SUCCESS [0.096s] [INFO] Apache CloudStack 
>> > Cloud
>> Engine
>> > API  SUCCESS [28.469s] [INFO] Apache CloudStack
>> Framework -
>> > Security .

Re: External fork of Cloudstack

2016-03-19 Thread Chris Mattmann

FYI, I am supportive of the below as well and willing to help where
I can.

Cheers,
Chris



-Original Message-
From:  on behalf of Sam Ruby 
Reply-To: "dev@cloudstack.apache.org" 
Date: Friday, March 18, 2016 at 10:52 AM
To: "dev@cloudstack.apache.org" 
Subject: Re: External fork of Cloudstack

>On Fri, Mar 18, 2016 at 1:44 PM, Will Stevens 
>wrote:
>>
>> I think we are on the same page.  I think we just need to start ironing
>>out
>> the actual logistical and technical details for how to move forward.
>
>+1
>
>- Sam Ruby

Re: External fork of Cloudstack

2016-03-19 Thread 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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Chris Mattmann

Hi Will,

Cloudstack is more than just the code and its mirroring. It’s the
community and the ability for those to participate. The issues that
occur at cloudstack/cloudstack will not be mirrored to the ASF; the
convo won’t be mirrored, and least of all the people and their belief
in the branding of cloudstack/cloudstack as the “canonical” repo for
apache/cloudstack is what I’m talking about. If someone told me,
oh you can do X, Y, Z GitHub stuff at cloudstack/cloustack, and that’s
where all the automated testing, liveliness is, all the people working
on it, that’s basically by definition a fork, and a moving/shifting
of the community.

There isn’t really any other way to describe it.

As for your question about mirroring apache/cloudstack to
cloudstack/cloudstack I don’t believe we support that currently.

Cheers,
Chris


-Original Message-
From:  on behalf of Will Stevens

Reply-To: "dev@cloudstack.apache.org" 
Date: Thursday, March 17, 2016 at 9:31 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...)

>I am not sure I understand how people wanting to participate with Apache
>Cloudstack would ever be at a disadvantage, it would still all be the same
>code base.  The changes in cloudstack/cloudstack would get pushed to the
>ASF repo and would then get mirrored to the apache/cloudstack repo, so
>they
>would all be in sync.
>
>Out of curiosity, is it possible to have ASF mirror to apache/cloudstack
>(as it currently does) and then have apache/cloudstack mirror to
>cloudstack/cloudstack?  This way to can guarantee that the ASF repo is the
>canonical repo, while also being able to take advantage of an improved dev
>workflow and the integration of distributed CI environments.
>
>
>
>*Will STEVENS*
>Lead Developer
>
>*CloudOps* *| *Cloud Solutions Experts
>420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>w cloudops.com *|* tw @CloudOps_
>
>On Thu, Mar 17, 2016 at 12:16 PM, Mattmann, Chris A (3980) <
>chris.a.mattm...@jpl.nasa.gov> 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.
>>
>> 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 k

Build failed in Jenkins: build-master-slowbuild #3485

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[2.781s]
[INFO] Apache CloudStack . SUCCESS [3.197s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.087s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [19.625s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:30.461s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.103s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [55.112s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [27.474s]
[INFO] Apache CloudStack API . SUCCESS [1:48.729s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.218s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.714s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.098s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.457s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.736s]
[INFO] Apache CloudStack Core  SUCCESS [1:21.460s]
[INFO] Apache CloudStack Agents .. SUCCESS [35.890s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.865s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.073s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.340s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.132s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.238s]
[INFO] Apache CloudStack Server .. SUCCESS [4:13.226s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [38.040s]
[INFO] Apache CloudStack Usage Server  SUCCESS [43.792s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.267s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.068s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.462s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [53.699s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [47.879s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.590s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [27.109s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [32.123s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.983s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.328s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.249s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.039s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.956s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.629s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.513s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[36.162s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.060s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.327s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [16.192s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.566s]
[INFO] Apache Cloud

[GitHub] cloudstack-docs-admin pull request: OSPF: WIP formatting documenta...

2016-03-19 Thread GabrielBrascher

Github user GabrielBrascher commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/36#issuecomment-198702503
  
Hi @agneya2001, could you please consider the following suggestions?
- Line 1453, change from "debian" to "Debian";
- at lines 1476 and 1480, change from "Dhcp, Dns" to "DHCP, DNS"; also, 
modify from "A example" to "An example";
- there are some lines with "Ospf" or "ospf", I would choose to keep with 
"OSPF".

Thanks.


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

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

2016-03-19 Thread Daan Hoogland

+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

2016-03-19 Thread Daan Hoogland

Hm, Will let's use a vote thread for voting. My brain is old and rigid and
needs the clarity of it. Just to be clear, are we keeping the cloudstack
organisation for experimenting and we do the move to apache-cloudstack? I
am not sure if github has a policy on naming of organisations so It would
be wise to keep cloudstack around in our control.

On Fri, Mar 18, 2016 at 11:58 PM, Will Stevens 
wrote:

> I already created a vote thread in the dev@ mailing list. I wanted to try
> to get consensus in the community as well. Please feel free to comment and
> such in that thread. Having ASF board members participating in that thread
> will be valuable.
>
> Thanks. :)
> On Mar 18, 2016 6:54 PM, "Chris Mattmann"  wrote:
>
> > Will all of your actions below sound like a sound plan to me.
> > Consider this the discuss thread. Get feedback for 24-48 hours,
> > then VOTE, then proceed :-)
> >
> > Cheers,
> > Chris
> >
> >
> >
> > -Original Message-
> > From:  on behalf of Will Stevens
> > 
> > Reply-To: "dev@cloudstack.apache.org" 
> > Date: Friday, March 18, 2016 at 3:30 PM
> > To: "dev@cloudstack.apache.org" 
> > Subject: Re: External fork of Cloudstack
> >
> > >Hey All,
> > >I am going to try to keep moving this forward, and as such, I have
> created
> > >the 'apache-cloudstack' organization in github.  I have invited everyone
> > >who is in the current 'cloudstack' organization as owners as well as Sam
> > >and Chris (also as owners).
> > >
> > >I think using this github org is probably the right one to use moving
> > >forward with this proposal since it better reflects what the org
> > >represents.
> > >
> > >Sam and Chris, I would like to get your suggestions for how we should
> plan
> > >to move forward since I think there is probably going to be more
> logistics
> > >and details to work through on your (ASF board) side of things.
> > >
> > >To reiterate, I think the best and most seamless approach will be to
> > >actually transfer ownership of the 'apache/cloudstack' repo to the
> > >'apache-cloudstack' org to be represented as
> > >'apache-cloudstack/cloudstack'.  This will move all of the PRs and will
> > >also setup redirection of requests from 'apache/cloudstack' to
> > >'apache-cloudstack/cloudstack' which is really important for all
> existing
> > >links etc...
> > >
> > >I also think we should also consider deleting the
> 'cloudstack/cloudstack'
> > >repository unless anyone is actively using it for testing in order to
> > >reduce confusion on the topic.
> > >
> > >I will create a VOTE thread so the community, and the participating ASF
> > >board members, can officially sign off on the proposal and give
> feedback.
> > >
> > >Cheers,
> > >
> > >*Will STEVENS*
> > >Lead Developer
> > >
> > >*CloudOps* *| *Cloud Solutions Experts
> > >420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > >w cloudops.com *|* tw @CloudOps_
> > >
> > >On Fri, Mar 18, 2016 at 2:48 PM, Sam Ruby 
> wrote:
> > >
> > >> On Fri, Mar 18, 2016 at 2:39 PM, sebgoa  wrote:
> > >> >
> > >> >> 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.
> > >>
> > >> Suggestion for now: “Mirror of Apache CloudStack for testing purposes
> > >> only”.
> > >>
> > >> While what is there now is technically correct, it is incomplete.  In
> > >> particular it can, and has, caused confusion.  Based on Will's
> > >> comments earlier in this thread, I believe that my suggestion is an
> > >> accurate portrayal of the current status, otherwise please substitute
> > >> a more accurate description.  (the subtext here: I am not an ASF
> > >> Director stepping in and demanding change, so please don't take
> > >> anything I say as an edict, I'm simply participating in the
> > >> conversation).
> > >>
> > >> Longer term, this may very well be "Apache CloudStack" in the same
> > >> sense that the github whimsy reposito

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

2016-03-19 Thread Daan Hoogland

On Fri, Mar 18, 2016 at 8:24 PM, Jim Jagielski  wrote:

> That sounds like a cop-out to me related to what's really going
> on.
>

Jim, I am not a native english speaker and this remark has no meaning to
me. It sounds somewhat hostile, can you explain what you mean? 



-- 
Daan

Re: External fork of Cloudstack

2016-03-19 Thread Will Stevens

I see you found the vote thread. Thanks for voting. :)

For now I think it is best that we try to avoid using the cloudstack org
for anything in order to mitigate confusion and try to get everyone on the
same page. We are charting new territory here, so removing as many
unnecessary distractions and causes for cloudy perception of what we are
trying to achieve is paramount IMO.

I personally think we should remove the cloudstack/cloudstack repo at this
point as I think it is more of a liability in this process than anything.
On Mar 19, 2016 9:45 AM, "Daan Hoogland"  wrote:

> Hm, Will let's use a vote thread for voting. My brain is old and rigid and
> needs the clarity of it. Just to be clear, are we keeping the cloudstack
> organisation for experimenting and we do the move to apache-cloudstack? I
> am not sure if github has a policy on naming of organisations so It would
> be wise to keep cloudstack around in our control.
>
> On Fri, Mar 18, 2016 at 11:58 PM, Will Stevens 
> wrote:
>
> > I already created a vote thread in the dev@ mailing list. I wanted to
> try
> > to get consensus in the community as well. Please feel free to comment
> and
> > such in that thread. Having ASF board members participating in that
> thread
> > will be valuable.
> >
> > Thanks. :)
> > On Mar 18, 2016 6:54 PM, "Chris Mattmann"  wrote:
> >
> > > Will all of your actions below sound like a sound plan to me.
> > > Consider this the discuss thread. Get feedback for 24-48 hours,
> > > then VOTE, then proceed :-)
> > >
> > > Cheers,
> > > Chris
> > >
> > >
> > >
> > > -Original Message-
> > > From:  on behalf of Will Stevens
> > > 
> > > Reply-To: "dev@cloudstack.apache.org" 
> > > Date: Friday, March 18, 2016 at 3:30 PM
> > > To: "dev@cloudstack.apache.org" 
> > > Subject: Re: External fork of Cloudstack
> > >
> > > >Hey All,
> > > >I am going to try to keep moving this forward, and as such, I have
> > created
> > > >the 'apache-cloudstack' organization in github.  I have invited
> everyone
> > > >who is in the current 'cloudstack' organization as owners as well as
> Sam
> > > >and Chris (also as owners).
> > > >
> > > >I think using this github org is probably the right one to use moving
> > > >forward with this proposal since it better reflects what the org
> > > >represents.
> > > >
> > > >Sam and Chris, I would like to get your suggestions for how we should
> > plan
> > > >to move forward since I think there is probably going to be more
> > logistics
> > > >and details to work through on your (ASF board) side of things.
> > > >
> > > >To reiterate, I think the best and most seamless approach will be to
> > > >actually transfer ownership of the 'apache/cloudstack' repo to the
> > > >'apache-cloudstack' org to be represented as
> > > >'apache-cloudstack/cloudstack'.  This will move all of the PRs and
> will
> > > >also setup redirection of requests from 'apache/cloudstack' to
> > > >'apache-cloudstack/cloudstack' which is really important for all
> > existing
> > > >links etc...
> > > >
> > > >I also think we should also consider deleting the
> > 'cloudstack/cloudstack'
> > > >repository unless anyone is actively using it for testing in order to
> > > >reduce confusion on the topic.
> > > >
> > > >I will create a VOTE thread so the community, and the participating
> ASF
> > > >board members, can officially sign off on the proposal and give
> > feedback.
> > > >
> > > >Cheers,
> > > >
> > > >*Will STEVENS*
> > > >Lead Developer
> > > >
> > > >*CloudOps* *| *Cloud Solutions Experts
> > > >420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > > >w cloudops.com *|* tw @CloudOps_
> > > >
> > > >On Fri, Mar 18, 2016 at 2:48 PM, Sam Ruby 
> > wrote:
> > > >
> > > >> On Fri, Mar 18, 2016 at 2:39 PM, sebgoa  wrote:
> > > >> >
> > > >> >> 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
> > > >> thi

Re: External fork of Cloudstack

2016-03-19 Thread Daan Hoogland

On Sat, Mar 19, 2016 at 2:54 PM, Will Stevens 
wrote:

> I see you found the vote thread. Thanks for voting. :)
>
> For now I think it is best that we try to avoid using the cloudstack org
> for anything in order to mitigate confusion and try to get everyone on the
> same page. We are charting new territory here, so removing as many
> unnecessary distractions and causes for cloudy perception of what we are
> trying to achieve is paramount IMO.
>
of course



>
> I personally think we should remove the cloudstack/cloudstack repo at this
> point as I think it is more of a liability in this process than anything.
>
yes, but only the repository and not the organisation

Re: github organisation cloudstack

2016-03-19 Thread Daan Hoogland

Will,

On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens  wrote:

> Please be advised this conversation is continuing in a thread titled: Re:
> External fork of Cloudstack
>
> Mailing list link:
>
> http://markmail.org/message/53ct2mma4x4jm6s2?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Re:+External+fork+of+Cloudstack

I liked my/this title of the thread better. The fork is not meant to be
external. It is meant to be the canonical source to file change requests
and - proposals against isn't it?

of course this is only secondary to the fact that it was 'my' title ;)

>
>
> Please come join the conversation in that thread...
>
please

--
Daan

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

2016-03-19 Thread Sam Ruby

On Sat, Mar 19, 2016 at 9:50 AM, Daan Hoogland  wrote:
> On Fri, Mar 18, 2016 at 8:24 PM, Jim Jagielski  wrote:
>
>> That sounds like a cop-out to me related to what's really going
>> on.
>
> Jim, I am not a native english speaker and this remark has no meaning to
> me. It sounds somewhat hostile, can you explain what you mean?

I think there was a misunderstanding and history involved, and I'm
working to clean that up.

The history involved is not unique to CloudStack.  It often comes up
when large projects or large companies are involved.  I work for a
large company (IBM), and often when IBM contemplates donating a
project to the ASF, the people involved are referred to me.  The most
extreme example I recall was when a high level executive told me he
wanted to take a project to Apache, but wanted a different license, to
be able to control who got commit access, and to run the project on
different hardware.  My response was simply: "then you don't want to
come to the ASF".

Here we had the CloudStack PMC make a reasonable request to ASF
infrastructure team (i.e., for more granular permissions), and were
not only told no, but that their request was placed on the back
burner.  I'm not proud of that response.  A technical solution to the
problem was developed (kudos!) and a proof of concept was deployed
(cool!).  Unfortunately, the proof of concept was poorly communicated,
and many (not just Jim!) saw this as an unfriendly act.  And to be
very clear, the optics were very bad: within 5 days of opening a JIRA
that was rejected, the CloudStack team looked like they were
unilaterally moving off of the ASF provided GitHub repository.

I don't think that there are any easy answers.  In particular, I don't
think that projects should ever have to simply take no for an answer.
And the fact that the board didn't provide a response to the top issue
listed in the December board report, and didn't reply to the attempt
to provide an out-of-cycle report last month didn't help.

Despite this clear failure of the board, I would suggest that the
CloudStack team alert the board before taking such an action again.

- Sam Ruby

Re: [POLL] Interest for EU based event/collab

2016-03-19 Thread Pierre-Luc Dion

Hi guys, we've been quiet lately, but we want to organize a collab event in
Canada, our target dates are June 2 and 3. We just cleared some
questionning regarding the planning and now ready to go forward.

Could an european one be postpone?

Il start a new thread in the mailing list...
On Mar 16, 2016 3:58 PM, "Erik Weber"  wrote:

> I appreciate the offer but plan on spending the days dipping in a pool
> somewhere in Greece at that time.
>
> However, I do hope that the event is successful, and that there might
> become a wish for a later event (Winter? b).
> That is still far ahead and something we can pick up later though.
>
> --
> Erik
>
>
>
> On Wed, Mar 16, 2016 at 8:54 PM, Walter, André 
> wrote:
>
>> Hi Erik,
>>
>>
>>
>> we are heading for 16th of June from 13:00 -17:30 CET (I am working
>> together with Steve to finalize the speakers/agenda) and you are more than
>> welcome J.
>>
>>
>>
>> Best regards.
>> Andre
>>
>>
>>
>> *Von:* Erik Weber [mailto:terbol...@gmail.com]
>> *Gesendet:* Mittwoch, 16. März 2016 20:51
>> *An:* Giles Sirett
>> *Cc:* dev@cloudstack.apache.org; Walter, André; Steve Roles
>> *Betreff:* Re: [POLL] Interest for EU based event/collab
>>
>>
>>
>> Hi Giles,
>>
>> Berlin is great!
>>
>> Has there been any discussions about a specific date yet? Personally I
>> have some vacation plans in that time frame (not that it should matter for
>> the event).
>>
>> I agree that combing the efforts we have is a good thing, I am hoping for
>> something bigger than a traditional UG at some point as it is hard to
>> defend the costs for a 3-4 hour event.
>>
>> --
>>
>> Erik
>>
>>
>>
>>
>>
>> On Wed, Mar 16, 2016 at 4:22 PM, Giles Sirett 
>> wrote:
>>
>> Erik
>>
>> I've responded to your survey (don’t know how useful my response will be,
>> I've said "yes" to everything)
>>
>>
>> One idea: we have a quarterly meeting of the Cloudstack EU UG.
>> We got 50 along to the last one. It’s a different audience to the usual
>> CCC attendees (more users than devs)
>>
>> For the next one (early June), we're planning on having it in Berlin
>>
>> Andre and the folks from BitGroup are taking the lead on it
>>
>> It would seem perfectly logical to me to combine anything we (i.e. the
>> community) do with one of these UG's - gain more critical mass more quickly
>> and make it more attractive to potential sponsors
>>
>> I'm not sure how far down the path Andre et al are with logistics and
>> whether the idea of making this into a bigger thing would scare him, but it
>> may be worth you two syncing on this
>>
>> We only have these meetings quarterly, the one after June would clash
>> with Brasil so likely not to happen
>>
>>
>>
>> Kind Regards
>> Giles
>>
>>
>>
>> [image: ShapeBlue] 
>>
>> *Giles Sirett*
>>
>> *CEO*
>>
>> *, *
>>
>> *ShapeBlue*
>>
>> *d: *
>>
>> *+44  20 3603 0541 | s: +44 203 603 0540*
>> <+44%20%2020%203603%200541%20%7C%20s:%20+44%20203%20603%200540>
>>
>>  |
>>
>> *m: *
>>
>> *+44 7961112055* <+44%207961112055>
>>
>> *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: Erik Weber [mailto:terbol...@gmail.com]
>> Sent: 16 March 2016 13:20
>> To: dev ; us...@cloudstack.apache.org
>> Subject: [POLL] Interest for EU based event/collab
>>
>> [Cross posted to users@ and dev@]
>>
>> As you may be aware, a conference has been announced in Brazil later this
>> year.
>>
>> I guess there are more than me having a hard time travelling that far and
>> long, so I would like to check the interest for an EU based event.
>>
>> Unless someone comes up with a big money jar it won't be as fancy as the
>> previous ones.
>>
>> If you could fill out this poll[1] and/or respond to this email, that
>> would be great.
>>
>> [1] https://no.surveymonkey.com/r/CX3K5T3
>>
>>
>> --
>> Erik
>>
>> Find out more about ShapeBlue

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread rafaelweingartner

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

https://github.com/apache/cloudstack/pull/780#discussion_r56509710
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -3332,7 +3332,14 @@ public PowerState getVmState(final Connection conn, 
final String vmName) {
 
vmStatsAnswer.setDiskReadKBs(vmStatsAnswer.getDiskReadKBs() + 
getDataAverage(dataNode, col, numRows) / 1000);
 } else if (param.matches("vbd_.*_write")) {
 
vmStatsAnswer.setDiskWriteKBs(vmStatsAnswer.getDiskWriteKBs() + 
getDataAverage(dataNode, col, numRows) / 1000);
+} else if (param.contains("memory_internal_free")) {
--- End diff --

I know you just followed the way the code was written here before, but this 
âif/else/if/elseâ¦â¦â structure is too big; I believe to introduce some 
changes like this here; it would be much appreciated a refactoring. I do not 
mean a huge refactoring, only the extraction of this if/else structure to a 
method and then using some other clever way to do these checks and to retrieve 
the values. 


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread Tutkowski, Mike

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

Put bluntly, the decision is no, and it is in the hands of the ASF Infra@
and based on
discussions I’ve seen on public lists there and on board@ and part of the
board
meeting yesterday, Infra@ is not opening up the Whimsy experiment to other
PMCs
as of yet. They aren’t ready to declare an SLA; they aren’t ready for
potential
other PMCs to ask to use it too and for others to start thinking that
capability
is anything near operational. David Nalley can fill in more.

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

Not at this time.

>[..snip..]
>>
>
>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).

I am one of 9 Directors, but I believe if you’d like to test the waters
that
I have support of other boa

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

2016-03-19 Thread Chris Mattmann

OK, last comment for a bit, sorry for the top post, going to try
and mix 2 replies in 1 email.

To Sebastien:

It’s more than just permissions - it’s where people *go to* and
*believe* that the community making the code is at. In all of your
statements, that community will be cloudstack/cloudstack by virtue
of all the whiz-bang things you all will have access to there
provided by GitHub, but not managed by Apache. I can easily see a
situation where the activity shifts to there b/c of all the control
those that manage cloudstack/cloudstack will have. Realize that
control is outside of the ASF purview which is set up to ensure
that the *community* is at the ASF on ASF hardware and that people
aren’t disadvantaged when e.g., they come to the project mailing
list (at Apache) and that they can pick up and know what’s going
on. I’m telling you that AFAIK, if you go off on cloudstack/cloudstack
and do a ton of work there, it will not go to the ASF list, and
further, those that appear on the ASF CloudStack list will have
access to, but will be most likely far behind of, what’s actually
went on. They can see what *went on*, but not participate in it as
*it’s going on* if our core message to them is *this community is
at Apache, you can go to the dev list, figure out what’s going on,
participate there as it’s happening*.

To Daan:

Thanks for your email. It’s not just the PMC that is the community
of Apache CloudStack. It’s those members that aren’t PMC yet or
committer, or people that want to jump on the dev list and figure
out how to contribute.  You’ve now made it harder for *them* to
participate per all my comments in this thread and you’ve now
confused *them* as to what’s the gold source or canonical repo, and
what’s not, etc. That’s the point. 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 needs to be managed in a different way and it’s *not*
an Apache project. Is that the road you want to go down?

Glad to see you that you are interested in keeping the project under
the Apache umbrella and I’m here trying to help and participate
since I was part of the discussion at the board meeting yesterday.

Cheers, 
Chris “no emails for a while” Mattmann

-Original Message-
From: sebgoa 
Reply-To: "dev@cloudstack.apache.org" 
Date: Thursday, March 17, 2016 at 9:43 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...)

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

[GitHub] cloudstack pull request: Emit event UUIDs on template deletion

2016-03-19 Thread bvbharatk

Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1378#issuecomment-197705664
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 105
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=14
 Skipped=4

**The follwing tests have known issues**
test_vpc_remote_access_vpn
test_vpc_site2site_vpn
test_01_test_vm_volume_snapshot
test_02_vpc_privategw_static_routes
test_03_rvpc_privategw_static_routes
test_04_change_offering_small
ContextSuite context=TestNiciraContoller>:setup
test_01_primary_storage_iscsi
test02_internallb_haproxy_stats_on_all_interfaces
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80
ContextSuite context=TestDeployVM>:setup
test_04_extract_template
test_04_extract_Iso
test_07_list_default_iso


_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* integration.smoke.test_privategw_acl.TestPrivateGwACL

 * test_01_vpc_privategw_acl Failed

* integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange

 * test_dedicateGuestVlanRange Failing since 5 runs


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot
integration.smoke.test_snapshots.TestSnapshotRootDisk

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_volumes.TestCreateVolume
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


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

[GitHub] cloudstack pull request: CLOUDSTACK-8800 : Improved the listVirtua...

2016-03-19 Thread swill

Github user swill commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-197890163
  
I see this was merged into master this morning.  Hmmm...


---
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: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

2016-03-19 Thread 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.
>> 
>> Best,
>> 
>> -Sebastien
>> 
>>> On 17 Mar 2016, at 00:04, Chris Mattmann  wrote:
>>> 
>>> Hi

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

2016-03-19 Thread Daan Hoogland

Thanks for the explanation Sam, I have to ask for your patience with me as
there is one remark in there that leaves me confused; Don't feel obligated
to answer in length but please confirm or negate my suspicion

On Sat, Mar 19, 2016 at 3:18 PM, Sam Ruby  wrote:
...


> Despite this clear failure of the board, I would suggest that the
> CloudStack team alert the board before taking such an action again.
>
> I don't see any action taken by the cloudstack team that couldn't have
been initiated by a complete outsider. I am assuming you mean the fork to
the cloudstack organisation. This organisation was created by Mark, I think
and was taken control of by our VP as a precaution to keep others from
making or using it, so I would think the board would applaud this instead
of giving us a (kind of) reprimand. So again and in order for us to not
make such a mistake again...

Can you please explain?

I am pushing this because there is clearly irritation on the side of the
board with the PMCs behaviour and vice versa and I feel, probably like you,
this is not largely but completely due to lack of communication and
transparency. Of course I might be as dumb as I feel and this might not be
the action you refer to at all.

-- 
Daan

Re: github organisation cloudstack

2016-03-19 Thread Will Stevens

I agree that your title better describes what we are trying to achieve.
On Mar 19, 2016 9:57 AM, "Daan Hoogland"  wrote:

> Will,
>
> On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens 
> wrote:
>
> > Please be advised this conversation is continuing in a thread titled: Re:
> > External fork of Cloudstack
> >
> > Mailing list link:
> >
> >
> http://markmail.org/message/53ct2mma4x4jm6s2?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Re:+External+fork+of+Cloudstack
>
> I liked my/this title of the thread better. The fork is not meant to be
> external. It is meant to be the canonical source to file change requests
> and - proposals against isn't it?
>
> of course this is only secondary to the fact that it was 'my' title ;)
> 
>
>
> >
> >
> > Please come join the conversation in that thread...
> >
> please
> 
>
> --
> Daan
>

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

2016-03-19 Thread Ian Rae

Sam,

Thanks for this context, I found it very helpful. We have an
interesting situation where no large companies are involved, and
really this is all about the needs of open source users. As you know
Apache CloudStack is highly user driven, and is perhaps thankfully off
the radar of the large industry players who have a tendency to subvert
community interests in the interest of short term gain (and good
governance comes in handy at such times, so we all understand the
value of CloudStack being part of the ASF in that sense). Apache
CloudStack also has some sophisticated reads related to CI/CD that are
perhaps not common, and therefore require special consideration.

I don’t know the Apache Foundation well enough to understand whether
the large government style bureaucracy including poor communication is
a normal thing, or whether the fact that there aren’t big players with
sophisticated lobbying capabilities involved is the reason the
community’s needs aren’t being addressed (not that I would even know
if the ASF is susceptible to that).

Trying to understand the cause behind the symptoms aside, the health
and success of the Apache CloudStack project should be in the
interests of both the ASF and CloudStack users and contributors. The
community values the governance of the ASF and the ASF should value an
engaged and motivated community, so why we are mired in such innuendo
is beyond me (conspiracy theories!). Unless some of us are actually
not here to build great open source software in the interest of users.

So this appears to be the kind of time when leadership combined with
clarity of thought and communication are important to avoid
conversation devolving into simply “people being wrong on the
internet”. I think I understand that the PMC leads the community. Who
represents the ASF leadership on this topic? I think they should be
engaged on this issue.

Ian

On Sat, Mar 19, 2016 at 10:18 AM, Sam Ruby  wrote:
> On Sat, Mar 19, 2016 at 9:50 AM, Daan Hoogland  
> wrote:
>> On Fri, Mar 18, 2016 at 8:24 PM, Jim Jagielski  wrote:
>>
>>> That sounds like a cop-out to me related to what's really going
>>> on.
>>
>> Jim, I am not a native english speaker and this remark has no meaning to
>> me. It sounds somewhat hostile, can you explain what you mean?
>
> I think there was a misunderstanding and history involved, and I'm
> working to clean that up.
>
> The history involved is not unique to CloudStack.  It often comes up
> when large projects or large companies are involved.  I work for a
> large company (IBM), and often when IBM contemplates donating a
> project to the ASF, the people involved are referred to me.  The most
> extreme example I recall was when a high level executive told me he
> wanted to take a project to Apache, but wanted a different license, to
> be able to control who got commit access, and to run the project on
> different hardware.  My response was simply: "then you don't want to
> come to the ASF".
>
> Here we had the CloudStack PMC make a reasonable request to ASF
> infrastructure team (i.e., for more granular permissions), and were
> not only told no, but that their request was placed on the back
> burner.  I'm not proud of that response.  A technical solution to the
> problem was developed (kudos!) and a proof of concept was deployed
> (cool!).  Unfortunately, the proof of concept was poorly communicated,
> and many (not just Jim!) saw this as an unfriendly act.  And to be
> very clear, the optics were very bad: within 5 days of opening a JIRA
> that was rejected, the CloudStack team looked like they were
> unilaterally moving off of the ASF provided GitHub repository.
>
> I don't think that there are any easy answers.  In particular, I don't
> think that projects should ever have to simply take no for an answer.
> And the fact that the board didn't provide a response to the top issue
> listed in the December board report, and didn't reply to the attempt
> to provide an out-of-cycle report last month didn't help.
>
> Despite this clear failure of the board, I would suggest that the
> CloudStack team alert the board before taking such an action again.
>
> - Sam Ruby

-- 
Ian Rae
CEO | PDG
c: 514.944.4008

CloudOps | Cloud Infrastructure and Networking Solutions
www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6

Re: github organisation cloudstack

2016-03-19 Thread Will Stevens

I mentioned it here since that was the thread that Sam and Chris were most
engaged in, so I wanted the people who were watching these other threads be
aware of that thread as we were getting good traction there.
On Mar 19, 2016 9:57 AM, "Daan Hoogland"  wrote:

> Will,
>
> On Fri, Mar 18, 2016 at 7:03 PM, Will Stevens 
> wrote:
>
> > Please be advised this conversation is continuing in a thread titled: Re:
> > External fork of Cloudstack
> >
> > Mailing list link:
> >
> >
> http://markmail.org/message/53ct2mma4x4jm6s2?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Re:+External+fork+of+Cloudstack
>
> I liked my/this title of the thread better. The fork is not meant to be
> external. It is meant to be the canonical source to file change requests
> and - proposals against isn't it?
>
> of course this is only secondary to the fact that it was 'my' title ;)
> 
>
>
> >
> >
> > Please come join the conversation in that thread...
> >
> please
> 
>
> --
> Daan
>

Re: External fork of Cloudstack

2016-03-19 Thread Will Stevens

Yes exactly. I don't think we should delete the org, just the repo. I think
the usage of that org is out of scope for this conversation and will likely
change based on this outcome. I think we should put that org on ice for the
time being.
On Mar 19, 2016 9:59 AM, "Daan Hoogland"  wrote:

> On Sat, Mar 19, 2016 at 2:54 PM, Will Stevens 
> wrote:
>
> > I see you found the vote thread. Thanks for voting. :)
> >
> > For now I think it is best that we try to avoid using the cloudstack org
> > for anything in order to mitigate confusion and try to get everyone on
> the
> > same page. We are charting new territory here, so removing as many
> > unnecessary distractions and causes for cloudy perception of what we are
> > trying to achieve is paramount IMO.
> >
> of course
> 
>
>
> >
> > I personally think we should remove the cloudstack/cloudstack repo at
> this
> > point as I think it is more of a liability in this process than anything.
> >
> yes, but only the repository and not the organisation
> 
>

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

2016-03-19 Thread Daan Hoogland

Please board and everybody at dev, Until the vote thread initiated by Will
no action has been taken or sactioned by the PMC, only discussions were
started. It has never been the intention of the PMC to move away from any
repository but only to add a fork to facilitate work. The misunderstanding
described by Sam below is most likely due to some of my own words in the
thread 'github organisation cloudstack' [1]

mea culpa, in the thread I started with


There is a github organisation called cloudstack, to which we have more
control then to the apache/cloudstack repo on github. We need to decide as
community what to do with it.

What are we going to do in this new organisation?
Will we let/ask Schuberg Philis to put cosmic in there?
Will be ask/let Will to run upr to it (so we don't depend on the
foundation)?
How will we sink it from/to apache or the apache github organisation?
Any other ideas/questions?

let's discuss or better,


Reading this back I can see how this can be interpreted in several ways,
I'm sorry.

[1] http://markmail.org/message/pca3j6vzojik2xyd

On Sat, Mar 19, 2016 at 3:18 PM, Sam Ruby  wrote:

> On Sat, Mar 19, 2016 at 9:50 AM, Daan Hoogland 
> wrote:
> > On Fri, Mar 18, 2016 at 8:24 PM, Jim Jagielski  wrote:
> >
> >> That sounds like a cop-out to me related to what's really going
> >> on.
> >
> > Jim, I am not a native english speaker and this remark has no meaning to
> > me. It sounds somewhat hostile, can you explain what you mean?
>
> I think there was a misunderstanding and history involved, and I'm
> working to clean that up.
>
> The history involved is not unique to CloudStack.  It often comes up
> when large projects or large companies are involved.  I work for a
> large company (IBM), and often when IBM contemplates donating a
> project to the ASF, the people involved are referred to me.  The most
> extreme example I recall was when a high level executive told me he
> wanted to take a project to Apache, but wanted a different license, to
> be able to control who got commit access, and to run the project on
> different hardware.  My response was simply: "then you don't want to
> come to the ASF".
>
> Here we had the CloudStack PMC make a reasonable request to ASF
> infrastructure team (i.e., for more granular permissions), and were
> not only told no, but that their request was placed on the back
> burner.  I'm not proud of that response.  A technical solution to the
> problem was developed (kudos!) and a proof of concept was deployed
> (cool!).  Unfortunately, the proof of concept was poorly communicated,
> and many (not just Jim!) saw this as an unfriendly act.  And to be
> very clear, the optics were very bad: within 5 days of opening a JIRA
> that was rejected, the CloudStack team looked like they were
> unilaterally moving off of the ASF provided GitHub repository.
>
> I don't think that there are any easy answers.  In particular, I don't
> think that projects should ever have to simply take no for an answer.
> And the fact that the board didn't provide a response to the top issue
> listed in the December board report, and didn't reply to the attempt
> to provide an out-of-cycle report last month didn't help.
>
> Despite this clear failure of the board, I would suggest that the
> CloudStack team alert the board before taking such an action again.
>
> - Sam Ruby
>



-- 
Daan

Re: External fork of Cloudstack

2016-03-19 Thread Daan Hoogland

+1 (maybe put/fork upr in there to prevent any cleaning from happening? ;)

On Sat, Mar 19, 2016 at 3:54 PM, Will Stevens 
wrote:

> Yes exactly. I don't think we should delete the org, just the repo. I think
> the usage of that org is out of scope for this conversation and will likely
> change based on this outcome. I think we should put that org on ice for the
> time being.
> On Mar 19, 2016 9:59 AM, "Daan Hoogland"  wrote:
>
> > On Sat, Mar 19, 2016 at 2:54 PM, Will Stevens 
> > wrote:
> >
> > > I see you found the vote thread. Thanks for voting. :)
> > >
> > > For now I think it is best that we try to avoid using the cloudstack
> org
> > > for anything in order to mitigate confusion and try to get everyone on
> > the
> > > same page. We are charting new territory here, so removing as many
> > > unnecessary distractions and causes for cloudy perception of what we
> are
> > > trying to achieve is paramount IMO.
> > >
> > of course
> > 
> >
> >
> > >
> > > I personally think we should remove the cloudstack/cloudstack repo at
> > this
> > > point as I think it is more of a liability in this process than
> anything.
> > >
> > yes, but only the repository and not the organisation
> > 
> >
>



-- 
Daan

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

2016-03-19 Thread Sam Ruby

On Sat, Mar 19, 2016 at 10:42 AM, Daan Hoogland  wrote:
> Thanks for the explanation Sam, I have to ask for your patience with me as
> there is one remark in there that leaves me confused; Don't feel obligated
> to answer in length but please confirm or negate my suspicion
>
> On Sat, Mar 19, 2016 at 3:18 PM, Sam Ruby  wrote:
> ...
>
>
>> Despite this clear failure of the board, I would suggest that the
>> CloudStack team alert the board before taking such an action again.
>>
>> I don't see any action taken by the cloudstack team that couldn't have
> been initiated by a complete outsider. I am assuming you mean the fork to
> the cloudstack organisation. This organisation was created by Mark, I think
> and was taken control of by our VP as a precaution to keep others from
> making or using it, so I would think the board would applaud this instead
> of giving us a (kind of) reprimand. So again and in order for us to not
> make such a mistake again...
>
> Can you please explain?
>
> I am pushing this because there is clearly irritation on the side of the
> board with the PMCs behaviour and vice versa and I feel, probably like you,
> this is not largely but completely due to lack of communication and
> transparency. Of course I might be as dumb as I feel and this might not be
> the action you refer to at all.

I see you posted a later email identifying one of the points of
confusion while I was composing this reply.  Cool.  Meanwhile:

I'm on the board, I'm not irritated.  At least not at CloudStack.  :-)

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.

> --
> Daan

- Sam Ruby

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

2016-03-19 Thread Sam Ruby

On Sat, Mar 19, 2016 at 10:47 AM, Ian Rae  wrote:
> Sam,
>
> Thanks for this context, I found it very helpful. We have an
> interesting situation where no large companies are involved, and
> really this is all about the needs of open source users. As you know
> Apache CloudStack is highly user driven, and is perhaps thankfully off
> the radar of the large industry players who have a tendency to subvert
> community interests in the interest of short term gain (and good
> governance comes in handy at such times, so we all understand the
> value of CloudStack being part of the ASF in that sense). Apache
> CloudStack also has some sophisticated reads related to CI/CD that are
> perhaps not common, and therefore require special consideration.
>
> I don’t know the Apache Foundation well enough to understand whether
> the large government style bureaucracy including poor communication is
> a normal thing, or whether the fact that there aren’t big players with
> sophisticated lobbying capabilities involved is the reason the
> community’s needs aren’t being addressed (not that I would even know
> if the ASF is susceptible to that).
>
> Trying to understand the cause behind the symptoms aside, the health
> and success of the Apache CloudStack project should be in the
> interests of both the ASF and CloudStack users and contributors. The
> community values the governance of the ASF and the ASF should value an
> engaged and motivated community, so why we are mired in such innuendo
> is beyond me (conspiracy theories!). Unless some of us are actually
> not here to build great open source software in the interest of users.
>
> So this appears to be the kind of time when leadership combined with
> clarity of thought and communication are important to avoid
> conversation devolving into simply “people being wrong on the
> internet”. I think I understand that the PMC leads the community. Who
> represents the ASF leadership on this topic? I think they should be
> engaged on this issue.

At the ASF, leadership is generally bottoms up.  To the extent that
you need access to a 'top", no less than three current ASF board
members have directly participated in this thread:

http://www.apache.org/foundation/board/

Whether I remain a Director or not (there are elections coming up this
week), feel free to reach out to me directly.  And I'm confident that
each and every one of the current Directors would make exactly this
same offer.

> Ian

- Sam Ruby

> On Sat, Mar 19, 2016 at 10:18 AM, Sam Ruby  wrote:
>> On Sat, Mar 19, 2016 at 9:50 AM, Daan Hoogland  
>> wrote:
>>> On Fri, Mar 18, 2016 at 8:24 PM, Jim Jagielski  wrote:
>>>
 That sounds like a cop-out to me related to what's really going
 on.
>>>
>>> Jim, I am not a native english speaker and this remark has no meaning to
>>> me. It sounds somewhat hostile, can you explain what you mean?
>>
>> I think there was a misunderstanding and history involved, and I'm
>> working to clean that up.
>>
>> The history involved is not unique to CloudStack.  It often comes up
>> when large projects or large companies are involved.  I work for a
>> large company (IBM), and often when IBM contemplates donating a
>> project to the ASF, the people involved are referred to me.  The most
>> extreme example I recall was when a high level executive told me he
>> wanted to take a project to Apache, but wanted a different license, to
>> be able to control who got commit access, and to run the project on
>> different hardware.  My response was simply: "then you don't want to
>> come to the ASF".
>>
>> Here we had the CloudStack PMC make a reasonable request to ASF
>> infrastructure team (i.e., for more granular permissions), and were
>> not only told no, but that their request was placed on the back
>> burner.  I'm not proud of that response.  A technical solution to the
>> problem was developed (kudos!) and a proof of concept was deployed
>> (cool!).  Unfortunately, the proof of concept was poorly communicated,
>> and many (not just Jim!) saw this as an unfriendly act.  And to be
>> very clear, the optics were very bad: within 5 days of opening a JIRA
>> that was rejected, the CloudStack team looked like they were
>> unilaterally moving off of the ASF provided GitHub repository.
>>
>> I don't think that there are any easy answers.  In particular, I don't
>> think that projects should ever have to simply take no for an answer.
>> And the fact that the board didn't provide a response to the top issue
>> listed in the December board report, and didn't reply to the attempt
>> to provide an out-of-cycle report last month didn't help.
>>
>> Despite this clear failure of the board, I would suggest that the
>> CloudStack team alert the board before taking such an action again.
>>
>> - Sam Ruby
>
>
>
> --
> Ian Rae
> CEO | PDG
> c: 514.944.4008
>
> CloudOps | Cloud Infrastructure and Networking Solutions
> www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6

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

2016-03-19 Thread 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 about leaving the ASF. This is about accessing
>>> productive tools and making use of them to their fullest.
>>> 
 Finally, as for th

[GitHub] cloudstack pull request: CLOUDSTACK-9289:Automation for feature de...

2016-03-19 Thread nitt10prashant

Github user nitt10prashant commented on the pull request:

https://github.com/apache/cloudstack/pull/1417#issuecomment-198314365
  
@GabrielBrascher  @sanju1010  i have removed redundant code 


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

[GitHub] cloudstack pull request: Is the project attempting a fork on Githu...

2016-03-19 Thread eriweb

Github user eriweb commented on the pull request:

https://github.com/apache/cloudstack/pull/1442#issuecomment-197510472
  
You could close it by pushing a dummy commit. But yes, I have to agree that 
sending a PR is some weird communication form!


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

Build failed in Jenkins: build-master-slowbuild #3491

2016-03-19 Thread jenkins

See 

--
[...truncated 28679 lines...]
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (findbugs) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- findbugs-maven-plugin:3.0.1:check (cloudstack-findbugs) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (default-cli) @ 
cloud-quickcloud ---
[WARNING] No files to instrument.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ cloud-quickcloud 
---
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ 
cloud-quickcloud ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[1.754s]
[INFO] Apache CloudStack . SUCCESS [2.069s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.770s]
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [18.899s]
[INFO] Apache CloudStack Utils ... SUCCESS [1:29.706s]
[INFO] Apache CloudStack Framework ... SUCCESS [0.099s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [53.916s]
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [26.846s]
[INFO] Apache CloudStack API . SUCCESS [1:51.395s]
[INFO] Apache CloudStack Framework - REST  SUCCESS [16.444s]
[INFO] Apache CloudStack Framework - IPC . SUCCESS [29.872s]
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.091s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [28.342s]
[INFO] Apache CloudStack Framework - Security  SUCCESS [24.357s]
[INFO] Apache CloudStack Core  SUCCESS [1:22.319s]
[INFO] Apache CloudStack Agents .. SUCCESS [36.307s]
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [36.736s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [14.182s]
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [2:07.152s]
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [40.634s]
[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS [25.845s]
[INFO] Apache CloudStack Server .. SUCCESS [4:12.953s]
[INFO] Apache CloudStack Framework - Quota ... SUCCESS [38.199s]
[INFO] Apache CloudStack Usage Server  SUCCESS [44.365s]
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS 
[1:21.251s]
[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.070s]
[INFO] Apache CloudStack Secondary Storage ... SUCCESS [0.431s]
[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [54.640s]
[INFO] Apache CloudStack Engine Storage Component  SUCCESS [48.730s]
[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [30.478s]
[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [25.645s]
[INFO] Apache CloudStack Engine Storage Data Motion Component  SUCCESS [30.846s]
[INFO] Apache CloudStack Engine Storage Cache Component .. SUCCESS [20.740s]
[INFO] Apache CloudStack Engine Storage Snapshot Component  SUCCESS [35.160s]
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [12.373s]
[INFO] Apache CloudStack Cloud Engine Service  SUCCESS [8.072s]
[INFO] Apache CloudStack Plugin POM .. SUCCESS [0.959s]
[INFO] Apache CloudStack Plugin - API Rate Limit . SUCCESS [26.793s]
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SUCCESS 
[23.642s]
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SUCCESS 
[35.891s]
[INFO] Apache CloudStack Plugin - API SolidFire .. SUCCESS [17.348s]
[INFO] Apache CloudStack Plugin - API Discovery .. SUCCESS [23.171s]
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SUCCESS [15.813s]
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SUCCESS 
[16.647s]
[INFO] Apache Cloud

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

2016-03-19 Thread Sebastien Goasguen

Top posting because keeping track is going to be hard.


Remi and I have talked several times with David about GitHub access and so far 
the answer has been no.

There are several issues in my understanding:

- apache on github is one single org, so if you get some write permission in 
the org then you could potentially harm other projects. that means that ASF 
needs to figure out how to use github teams to map our projects inside a single 
org (follow me…). They appear to be working on it, but no ETA on when this will 
happen.

- location of the canonical repo. This in large a legal issue. If CloudStack 
were sued at some point, can we prove without doubt who made the commit. Until 
now, ASF has the canonical repo on its own hardware which means all sorts of 
logs including push logs. Some folks at the ASF think that with a project on 
github they would not get the same level of guaranteed provenance. ( I have 
tried to argue about it, some folks don’t think it is an issue, but others do).


The bottom line for me:

-We are the ASF, the board is there for guidance but we, the communities and 
the ASF members need to tell the board what we need/want.

-I want github, I am hearing a lot of you too.

-We informed the board several times, David has known for a while that we want 
this. Other projects want it too (even though I don’t know which one).

-cloudstack/cloudstack is just an experiment for us, like the board is 
experimenting with a Whimsy project that none of us are part of. So let’s work 
on our CI in cloudstack/cloudstack (not talking about abandoning 
apache/cloudstack) and when the board comes around to do something we will be 
ready.

-Sebastien

> On Mar 18, 2016, at 4:37 AM, Will Stevens  wrote:
> 
> I may be thinking too far outside the box, but hear me out as this is
> likely the best way to satisfy everyone's requirements.
> 
> Recap: The community needs additional github permissions in order to
> integrate CI in order to maintain code quality.  The ASF does not have
> enough granular control via github to give permissions on the
> apache/cloudstack repository without giving the permissions across the
> entire github apache org, which they are presently not comfortable with.
> 
> What if we did the following:
> - Setup the 'cloudstack' github org so both the ASF and the community have
> 'owner' role representation.
> - The apache/cloudstack repo is transferred to the cloudstack/cloudstack
> repo.  This will move all of the PRs and everything over to the
> cloudstack/cloudstack repo and will also setup redirection from
> apache/cloudstack to cloudstack/cloudstack.
> - This allows for the ASF and the community to work together to establish
> the github permissions which make the most sense for the cloudstack project
> without being bound by its implications on other projects.
> - The official ASF repo would still be the source of truth and the
> cloudstack/cloudstack repo would be a mirror of it.  There are probably
> some details in this that we will need to address to make sure everything
> is consistent with the ASF requirements.
> - There will only be one cloudstack repository on which to contribute as a
> community member, so there will be no confusion introduced and there will
> be no segmentation of the community.
> - The cloudstack/cloudstack repo would still be an official ASF project, so
> no need for rebranding or worrying about the unpleasant logistics of a
> "fork".
> 
> I am sure I have not thought through all the details and I am sure there
> are some gotchas that we have to sort out, but I think this is a real
> viable stepping stone towards being able to satisfy both parties
> requirements while keeping the community strong and headed in the same
> direction.
> 
> What do you all think?
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Mar 17, 2016 at 8:44 PM, Ahmad Emneina  wrote:
> 
>> +BCC: David Nalley for possible guidance.
>> 
>> Apache infra stated that 'The VP' dictated the policy to not allow
>> 'repo:status' across the board for projects. Has anyone tried to engage the
>> VP, in order to get them to have a closer look at this policy? It appears
>> to be no way to exploit that function maliciously... so hopefully they
>> could allow for this to be enabled.
>> 
>> $0.02
>> 
>> On Thu, Mar 17, 2016 at 4:46 PM, Erik Weber  wrote:
>> 
>>> On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann 
>>> wrote:
>>> 
 
>> 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.
 
 
>>> This is not the result of people getting together and saying 'hey, we
>>> should fork and work somewhere else, that'd be fun!', but rather
>>> 'hey, we are currently unable to

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

2016-03-19 Thread Patrick Dube

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

1 2 >

1 - 100 of 177 matches

Mail list logo