Re: 4.10.0 release

[Rajani Karuturi]

On Thu, Aug 4, 2016 at 11:41 PM, John Burwell 
wrote:

> Will and Rajani,
>
> I recall the motivations for the release principles well.  Their primary
> intention was to improve the testing and codify review requirements for
> commits to a release branch.  In my view, this goal does not require that
> only a few people perform merges to release branches.


We tried and tested with everybody merging and it did not workout. The
situation has not changed since then. We still have the same upgrade
issues, template issues. We did not improve the automation time. We do not
have an automated way to test a PR and report results. We even do not know
how reliable the tests are and how much they cover.

I am not in favour of doing the same mistake again without any improvements
We can try it again only when we see more CI instances reporting results
for a PR. But, until that is available(and as long as we see only RMs
running automation tests manually), I prefer few people committing. We can
increase this set to RM + few more volunteers who can run automation. But,
I am not comfortable with opening it to all. Let us go to a middle ground
first, test it and then open to all.


> We should let any committer merge a PR that has the requisite LGTMs.  I
> also believe we need to be a bit nuanced about the requirement to test
> every PR against hardware.  While most PRs require this level of testing,
> we have plenty of PRs that do not impact hardware (e.g. UI changes, code
> cleanups, etc).

code cleanups need automation runs unless its just removing commented code.
UI is the only exception. (I prefer forking it to a separate repository.
But, that is a separate story.) UI PRs require screenshots on PRs or
atleast information on where and how to see it in UI.


> I am in favor of refining the release principles to say that the test LGTM
> for any PR that impacts provisioning/management of hardware must include
> hardware tests.  As we monitor merges to master, if we find any PRs that do
> impact these functions that have not been tested against hardware then we
> will roll them back and work with the author to complete that testing.
>

monitoring branches is a difficult task. We should be able to fully trust
people who commit.


>
> Rohit is currently creating a Jenkins build pipeline that builds a PR,
> creates a test environment using Trillian, and runs the tests.  He is
> nearly finished.  When he is done, I get him to push docs to the Trillian
> repo and open a discussion on dev@.
>

This is great. If it does what it says, most of the RM job is done and
hopefully we will be able to merge more PRs and release quickly. Waiting to
see it live. Is this jenkins instance publicly accessible?


~Rajani
http://cloudplatform.accelerite.com/


>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Aug 4, 2016, at 1:29 PM, Will Stevens  wrote:
> >
> > Rajani, you have very valid points and they echo my concerns.
> >
> > I also agree that the CI (actual testing of PRs against real hardware
> > environments) is required in order for a PR to be committed.  This is
> where
> > ALL the work is for the RM in the current process.  As RM, I ended up
> with
> > 10 CI environments running in parallel in order to get testing done to at
> > least a basic level.  This type of testing MUST continue or we are at
> risk
> > of falling into old pitfalls around stability.
> >
> > John and Paul, how feasible would it be for me to setup an automated
> > process for pulling and testing PRs with Trillian?  I have environments
> > that I can test on, but I don't have the time to manage 8=10 environments
> > testing in parallel by hand.  We need get to the point where PRs are
> queued
> > and the testing of these PRs on real hardware is automated.  The manual
> > approach is not viable long term (trust me).  :)
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Aug 4, 2016 at 1:19 PM, Rajani Karuturi 
> wrote:
> >
> >> John,
> >> We understand the bylaws. But, practically we saw master in an unusable
> >> state for many months. This is not just about trust. CloudStack is so
> vast
> >> that its difficult for a single person to test all the affected areas.
> Many
> >> a times, people does not even have enough hardware/knowledge to run
> >> integration tests. Bugs which are found at a later point of time have
> very
> >> high cost. Finding that commit which broke something is very hard task.
> >> Rolling back is the easiest part of it.
> >>
> >> In an ideal world, we could just allow everyone to commit (maybe we
> could
> >> even allow non committers to commit and increase the velocity). But, it
> did
> >> not workout. which is why we have all 

[GitHub] cloudstack pull request #672: Allow VM snapshots and volume snapshots to exi...

[jburwell]

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

https://github.com/apache/cloudstack/pull/672#discussion_r73613647
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -4251,6 +4257,34 @@ public void rebootVM(final Connection conn, final VM 
vm, final String vmName) th
 }
 }
 
+protected String skipOrRemoveSR(Connection conn, SR sr) {
+if (sr == null) {
+return null;
+}
+if (s_logger.isDebugEnabled()) {
+s_logger.debug(logX(sr, "Removing SR"));
+}
+try {
+Set vdis = sr.getVDIs(conn);
+for (VDI vdi : vdis) {
+Map 
currentOperation = vdi.getCurrentOperations(conn);
+if (currentOperation == null || currentOperation.size() == 
0) {
+continue;
+}
+return null;
+}
+removeSR(conn, sr);
+return null;
+} catch (XenAPIException e) {
+s_logger.warn(logX(sr, "Unable to get current opertions " + 
e.toString()), e);
+} catch (XmlRpcException e) {
+s_logger.warn(logX(sr, "Unable to get current opertions " + 
e.getMessage()), e);
+}
+String msg = "Remove SR failed";
+s_logger.warn(msg);
+return msg;
--- End diff --

I agree with @GabrielBrascher -- there appears to be no value added by 
returning a ``String``.  Why not change the return type to ``void``?


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

[GitHub] cloudstack issue #672: Allow VM snapshots and volume snapshots to exist toge...

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/672
  
@anshul1886 could please squash the three commits and add the ticket 
reference to the commit message?


---
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 #672: Allow VM snapshots and volume snapshots to exi...

[jburwell]

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

https://github.com/apache/cloudstack/pull/672#discussion_r73613353
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -4251,6 +4257,34 @@ public void rebootVM(final Connection conn, final VM 
vm, final String vmName) th
 }
 }
 
+protected String skipOrRemoveSR(Connection conn, SR sr) {
+if (sr == null) {
+return null;
+}
+if (s_logger.isDebugEnabled()) {
+s_logger.debug(logX(sr, "Removing SR"));
+}
+try {
+Set vdis = sr.getVDIs(conn);
+for (VDI vdi : vdis) {
+Map 
currentOperation = vdi.getCurrentOperations(conn);
+if (currentOperation == null || currentOperation.size() == 
0) {
+continue;
+}
+return null;
+}
+removeSR(conn, sr);
+return null;
+} catch (XenAPIException e) {
+s_logger.warn(logX(sr, "Unable to get current opertions " + 
e.toString()), e);
+} catch (XmlRpcException e) {
--- End diff --

Please collapse these two catch blocks with a multi-catch to reduce 
duplication.  Also, why is the issue being logged to ``WARN`` and not ``ERROR``?


---
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 #672: Allow VM snapshots and volume snapshots to exi...

[jburwell]

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

https://github.com/apache/cloudstack/pull/672#discussion_r73613017
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
 ---
@@ -1402,6 +1402,12 @@ public VM createWorkingVM(final Connection conn, 
final String vmName, final Stri
 vbdr.userdevice = Long.toString(volumeTO.getDeviceId());
 vbdr.mode = Types.VbdMode.RW;
 vbdr.type = Types.VbdType.DISK;
+Long deviceId = volumeTO.getDeviceId();
+if (deviceId != null) {
+if (!isDeviceUsed(conn, vm, deviceId) || 
deviceId.longValue() > 3) {
--- End diff --

Calling ``longValue`` is unnecessary due to autoboxing.  Also, ``3`` seems 
like a magic value.  What is its significance?


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

[GitHub] cloudstack issue #669: Made the adding new keyboard language support easier

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/669
  
@anshul1886 it appears that there was a push to get this PR into 4.9, but 
@bvbharat found5 test failures and 3 skips.  What is the status of resolving 
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 issue #540: CLOUDSTACK-8415. SSVM shutdown during snapshot operat...

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/540
  
@likitha is this PR still pertinent?


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

[GitHub] cloudstack issue #384: CLOUDSTACK-8308:Adding automation testcases for Delta...

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/384
  
@pritisarap12 @remibergsma referenced PR #720 which appears to implement a 
similar set of tests.  How do the tests in this PR differ?

it also appears that the Travis build is failing.  Could you please fix the 
failure and trigger Travis to rebuild?  Finally, is there a JIRA ticket 
associated with this change?


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

[GitHub] cloudstack issue #351: This branch implements the CSV and native HA support ...

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/351
  
@anshul1886 @rhtyd it appears that there was a push to get this merged for 
the 4.9 release, but a conflict may have occurred with the Dynamic Role-based 
API Checker enhancement.  Were you able to resolve the issue?  It also appears 
that @bvbharat had 3 test failures and 3 test skips.  Where does resolution of 
these test issues stand?


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

[GitHub] cloudstack issue #1622: Adding missing bits field to TemplateResponse

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
@ProjectMoon is there a JIRA associated with this change?


---
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 #1622: Adding missing bits field to TemplateResponse

[jburwell]

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

https://github.com/apache/cloudstack/pull/1622#discussion_r73605500
  
--- Diff: api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
---
@@ -169,6 +169,10 @@
 @Param(description = "additional key/value details tied with template")
 private Map details;
 
+@SerializedName(ApiConstants.BITS)
+@Param(description="the processor bit size")
+private int bits;
--- End diff --

Why is this value represented as a number and not an enumeration?  It can't 
be any number other 32 and 64.  


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

[GitHub] cloudstack issue #1622: Adding missing bits field to TemplateResponse

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
@rhtyd Travis appears to have failed due to a missing file.  Could you 
please investigate?


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

[GitHub] cloudstack issue #1623: CLOUDSTACK-9317: Enable/disable static NAT associate...

[jburwell]

Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1623
  
@ProjectMoon have you run the ``test_redundant_router_cleanups``, 
``test_redundant_router_services``, and ``test_redundant_router_upgrades`` test 
cases for this PR?

Also, is there a JIRA ticket associated with this change?


---
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 #1623: CLOUDSTACK-9317: Enable/disable static NAT as...

[jburwell]

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

https://github.com/apache/cloudstack/pull/1623#discussion_r73604377
  
--- Diff: server/src/com/cloud/network/IpAddressManagerImpl.java ---
@@ -1698,6 +1698,22 @@ public String acquireGuestIpAddress(Network network, 
String requestedIp) {
 
 Random _rand = new Random(System.currentTimeMillis());
 
+/**
+ * Get the list of public IPs that need to be applied for a static NAT 
enable/disable operation.
+ * Manipulating only these ips prevents concurrency issues when 
disabling static nat at the same time.
+ * @param staticNats
+ * @return The list of IPs that need to be applied for the static NAT 
to work.
+ */
+public List getStaticNatSourceIps(List staticNats) {
+List userIps = new ArrayList<>();
+
+for (StaticNat snat : staticNats) {
+
userIps.add(_ipAddressDao.findById(snat.getSourceIpAddressId()));
+}
--- End diff --

Executing queries in a ``for`` loop in unnecessarily expensive.  Could you 
please refactor this ``for`` loop into a new method on ``IPAddressDao`` that 
retrieves a list of IP addresses for a list of IPs?


---
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: 4.10.0 release

[Will Stevens]

This sounds good.  I agree that not every PR needs full CI on hardware, but
I do think that every PR should have some form of verification that the
code does what it is intended to do.  So for a UI change, it should include
a screenshot (for example).

The main point of this is that we maintain stability.  We have come a long
way since 4.6.  Then we had to be a bit more draconian about this because
we were breaking the norm in order to stabilize master.  Now, with a more
ingrained Github workflow and some better CI tools, I think we can afford
to start giving back some control to the committing community.  This is of
course assuming the RMs are comfortable with that.  At the end of the day,
they are the ones who are directly impacted by this decision.

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 2:11 PM, John Burwell 
wrote:

> Will and Rajani,
>
> I recall the motivations for the release principles well.  Their primary
> intention was to improve the testing and codify review requirements for
> commits to a release branch.  In my view, this goal does not require that
> only a few people perform merges to release branches.  We should let any
> committer merge a PR that has the requisite LGTMs.  I also believe we need
> to be a bit nuanced about the requirement to test every PR against
> hardware.  While most PRs require this level of testing, we have plenty of
> PRs that do not impact hardware (e.g. UI changes, code cleanups, etc).  I
> am in favor of refining the release principles to say that the test LGTM
> for any PR that impacts provisioning/management of hardware must include
> hardware tests.  As we monitor merges to master, if we find any PRs that do
> impact these functions that have not been tested against hardware then we
> will roll them back and work with the author to complete that testing.
>
> Rohit is currently creating a Jenkins build pipeline that builds a PR,
> creates a test environment using Trillian, and runs the tests.  He is
> nearly finished.  When he is done, I get him to push docs to the Trillian
> repo and open a discussion on dev@.
>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Aug 4, 2016, at 1:29 PM, Will Stevens  wrote:
> >
> > Rajani, you have very valid points and they echo my concerns.
> >
> > I also agree that the CI (actual testing of PRs against real hardware
> > environments) is required in order for a PR to be committed.  This is
> where
> > ALL the work is for the RM in the current process.  As RM, I ended up
> with
> > 10 CI environments running in parallel in order to get testing done to at
> > least a basic level.  This type of testing MUST continue or we are at
> risk
> > of falling into old pitfalls around stability.
> >
> > John and Paul, how feasible would it be for me to setup an automated
> > process for pulling and testing PRs with Trillian?  I have environments
> > that I can test on, but I don't have the time to manage 8=10 environments
> > testing in parallel by hand.  We need get to the point where PRs are
> queued
> > and the testing of these PRs on real hardware is automated.  The manual
> > approach is not viable long term (trust me).  :)
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Aug 4, 2016 at 1:19 PM, Rajani Karuturi 
> wrote:
> >
> >> John,
> >> We understand the bylaws. But, practically we saw master in an unusable
> >> state for many months. This is not just about trust. CloudStack is so
> vast
> >> that its difficult for a single person to test all the affected areas.
> Many
> >> a times, people does not even have enough hardware/knowledge to run
> >> integration tests. Bugs which are found at a later point of time have
> very
> >> high cost. Finding that commit which broke something is very hard task.
> >> Rolling back is the easiest part of it.
> >>
> >> In an ideal world, we could just allow everyone to commit (maybe we
> could
> >> even allow non committers to commit and increase the velocity). But, it
> did
> >> not workout. which is why we have all these rules based on previous
> >> learning. For 4.6, we did not start with RM only merges. But, after many
> >> failed attempts we came to that conclusion.
> >>
> >> Watching the branches and policing is more difficult than allowing only
> a
> >> few people to commit.
> >>
> >> I do understand Rohit's concern about RM being bottleneck. The initial
> idea
> >> was we will have more than one RM(may be around 5) so that one of them
> >> would be available always. But, given the amount of time it takes to do
> the
> >> RM job, we did not get 

Re: Vmware NSX Transformers

[Nicolás Vázquez]

Hi Syed,

I've been comparing NSX 4.2 and NSX-T 1.0 and the main differences I could
find are:

   - API url base, which change from /ws.v1/ to /api/v1/, API methods also
   different, see attached Documentations
   - There's a substantial difference in logical routers, NSX-T makes
   difference between TIER-0 and TIER-1 logical routers allowing their
   creation, but that's not possible in NSX 4.2, there's a unified logical
   router option.
   - The same happens on NAT, TIER-0 and TIER-1 depending on the type of
   router in NSX-T
   - Controller cluster on NSX 4.2 had role types and usually API was
   exposed by them, not by NSX Manager. On NSX-T API is exposed by NSX
   Management Nodes

In my opinion it would be suitable to create a new plugin, but would like
to bring it into discussion. I also attach API documentation for NSX 4.2
and it newest version NSX-T 1.0 for you to compare them.
NSX 4.2 API DOC:
https://drive.google.com/open?id=0BzG1lGxO9JKpa2pmMzd3RjBIeEk
NSX-T API DOC: https://drive.google.com/open?id=0BzG1lGxO9JKpc2d2VWRBVHhzYjQ

Thanks,
Nicolas


2016-08-04 14:30 GMT-03:00 Syed Ahmed :

> Hi Nicolas,
>
> It would be preferable if you integrated that in the existing plugin. If
> there are a lot of differences between NSX and NSX-T, you could create a
> new Resource within the same plugin and based on a config decide which one
> to use. Can you share more info between the differences between NSX and
> NSX-T?
>
> Thanks,
> -Syed
>
>
> On Tue, Aug 2, 2016 at 1:31 PM, Nicolás Vázquez 
> wrote:
>
> > Hi guys,
> >
> > I would like to bring into discussion this topic. We use NSX plugin on
> > Cloudstack for network virtualization, and as NSX Transformers (NSX-T)
> was
> > released, we would like to adapt it to Cloudstack.
> >
> > What do you think it would be the best approach: create a new plugin or
> > adapt the existing plugin to support NSX-T?
> >
> > Thanks,
> > Nicolas
> >
>

Re: 4.10.0 release

[John Burwell]

Will and Rajani,

I recall the motivations for the release principles well.  Their primary 
intention was to improve the testing and codify review requirements for commits 
to a release branch.  In my view, this goal does not require that only a few 
people perform merges to release branches.  We should let any committer merge a 
PR that has the requisite LGTMs.  I also believe we need to be a bit nuanced 
about the requirement to test every PR against hardware.  While most PRs 
require this level of testing, we have plenty of PRs that do not impact 
hardware (e.g. UI changes, code cleanups, etc).  I am in favor of refining the 
release principles to say that the test LGTM for any PR that impacts 
provisioning/management of hardware must include hardware tests.  As we monitor 
merges to master, if we find any PRs that do impact these functions that have 
not been tested against hardware then we will roll them back and work with the 
author to complete that testing.

Rohit is currently creating a Jenkins build pipeline that builds a PR, creates 
a test environment using Trillian, and runs the tests.  He is nearly finished.  
When he is done, I get him to push docs to the Trillian repo and open a 
discussion on dev@.

Thanks,
-John

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

On Aug 4, 2016, at 1:29 PM, Will Stevens  wrote:
> 
> Rajani, you have very valid points and they echo my concerns.
> 
> I also agree that the CI (actual testing of PRs against real hardware
> environments) is required in order for a PR to be committed.  This is where
> ALL the work is for the RM in the current process.  As RM, I ended up with
> 10 CI environments running in parallel in order to get testing done to at
> least a basic level.  This type of testing MUST continue or we are at risk
> of falling into old pitfalls around stability.
> 
> John and Paul, how feasible would it be for me to setup an automated
> process for pulling and testing PRs with Trillian?  I have environments
> that I can test on, but I don't have the time to manage 8=10 environments
> testing in parallel by hand.  We need get to the point where PRs are queued
> and the testing of these PRs on real hardware is automated.  The manual
> approach is not viable long term (trust me).  :)
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 1:19 PM, Rajani Karuturi  wrote:
> 
>> John,
>> We understand the bylaws. But, practically we saw master in an unusable
>> state for many months. This is not just about trust. CloudStack is so vast
>> that its difficult for a single person to test all the affected areas. Many
>> a times, people does not even have enough hardware/knowledge to run
>> integration tests. Bugs which are found at a later point of time have very
>> high cost. Finding that commit which broke something is very hard task.
>> Rolling back is the easiest part of it.
>> 
>> In an ideal world, we could just allow everyone to commit (maybe we could
>> even allow non committers to commit and increase the velocity). But, it did
>> not workout. which is why we have all these rules based on previous
>> learning. For 4.6, we did not start with RM only merges. But, after many
>> failed attempts we came to that conclusion.
>> 
>> Watching the branches and policing is more difficult than allowing only a
>> few people to commit.
>> 
>> I do understand Rohit's concern about RM being bottleneck. The initial idea
>> was we will have more than one RM(may be around 5) so that one of them
>> would be available always. But, given the amount of time it takes to do the
>> RM job, we did not get enough volunteers.
>> 
>> Even now, I dont think its the RM that is the bottleneck. But, its the
>> number of people with real hardware who are willing to run integration
>> tests for the PRs. Most of the efforts of RM goes in setting up test
>> environments, running tests, bringing the results back to PR.
>> 
>> Maybe, we could follow a middle ground like this.
>> We as a community can authorize few more people to merge PRs in addition to
>> RMs.
>> 
>> How do we select these additional volunteers?
>> Any committer can just come forward and declare(in a mail to dev@) that he
>> read the release principles[1] and would like to volunteer to commit.
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>> Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>> ~Rajani
>> http://cloudplatform.accelerite.com/
>> 
>> On Thu, Aug 4, 2016 at 8:28 PM, John Burwell 
>> wrote:
>> 
>>> Rajani and Will,
>>> 
>>> It is actually not up to the release managers to make such a
>>> determination.  Our bylaws state that anyone with a commit bit can commit
>>> (or, if necessary, rollback a commit).  By 

[GitHub] cloudstack issue #1621: [CLOUDSTACK-9444] Fix a little issue from PR1610 if ...

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1621
  
Holy monkeys! Failed to build one or more CloudStack 
packages that would have been available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1621


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Holy monkeys! Failed to build one or more CloudStack packages that 
would have been available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Holy monkeys! Failed to build one or 
more CloudStack packages that would have been available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Holy monkeys! Failed to build one or more CloudStack 
packages that would have been available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Holy monkeys! Failed to build one or more CloudStack packages that would 
have been available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625.


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

[GitHub] cloudstack issue #1623: CLOUDSTACK-9317: Enable/disable static NAT associate...

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1623
  
RPM packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1623.


---
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: Vmware NSX Transformers

[Syed Ahmed]

Hi Nicolas,

It would be preferable if you integrated that in the existing plugin. If
there are a lot of differences between NSX and NSX-T, you could create a
new Resource within the same plugin and based on a config decide which one
to use. Can you share more info between the differences between NSX and
NSX-T?

Thanks,
-Syed


On Tue, Aug 2, 2016 at 1:31 PM, Nicolás Vázquez 
wrote:

> Hi guys,
>
> I would like to bring into discussion this topic. We use NSX plugin on
> Cloudstack for network virtualization, and as NSX Transformers (NSX-T) was
> released, we would like to adapt it to Cloudstack.
>
> What do you think it would be the best approach: create a new plugin or
> adapt the existing plugin to support NSX-T?
>
> Thanks,
> Nicolas
>

Re: 4.10.0 release

[Will Stevens]

Rajani, you have very valid points and they echo my concerns.

I also agree that the CI (actual testing of PRs against real hardware
environments) is required in order for a PR to be committed.  This is where
ALL the work is for the RM in the current process.  As RM, I ended up with
10 CI environments running in parallel in order to get testing done to at
least a basic level.  This type of testing MUST continue or we are at risk
of falling into old pitfalls around stability.

John and Paul, how feasible would it be for me to setup an automated
process for pulling and testing PRs with Trillian?  I have environments
that I can test on, but I don't have the time to manage 8=10 environments
testing in parallel by hand.  We need get to the point where PRs are queued
and the testing of these PRs on real hardware is automated.  The manual
approach is not viable long term (trust me).  :)

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 1:19 PM, Rajani Karuturi  wrote:

> John,
> We understand the bylaws. But, practically we saw master in an unusable
> state for many months. This is not just about trust. CloudStack is so vast
> that its difficult for a single person to test all the affected areas. Many
> a times, people does not even have enough hardware/knowledge to run
> integration tests. Bugs which are found at a later point of time have very
> high cost. Finding that commit which broke something is very hard task.
> Rolling back is the easiest part of it.
>
> In an ideal world, we could just allow everyone to commit (maybe we could
> even allow non committers to commit and increase the velocity). But, it did
> not workout. which is why we have all these rules based on previous
> learning. For 4.6, we did not start with RM only merges. But, after many
> failed attempts we came to that conclusion.
>
> Watching the branches and policing is more difficult than allowing only a
> few people to commit.
>
> I do understand Rohit's concern about RM being bottleneck. The initial idea
> was we will have more than one RM(may be around 5) so that one of them
> would be available always. But, given the amount of time it takes to do the
> RM job, we did not get enough volunteers.
>
> Even now, I dont think its the RM that is the bottleneck. But, its the
> number of people with real hardware who are willing to run integration
> tests for the PRs. Most of the efforts of RM goes in setting up test
> environments, running tests, bringing the results back to PR.
>
> Maybe, we could follow a middle ground like this.
> We as a community can authorize few more people to merge PRs in addition to
> RMs.
>
> How do we select these additional volunteers?
> Any committer can just come forward and declare(in a mail to dev@) that he
> read the release principles[1] and would like to volunteer to commit.
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Release+principles+for+Apache+CloudStack+4.6+and+up
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>
> On Thu, Aug 4, 2016 at 8:28 PM, John Burwell 
> wrote:
>
> > Rajani and Will,
> >
> > It is actually not up to the release managers to make such a
> > determination.  Our bylaws state that anyone with a commit bit can commit
> > (or, if necessary, rollback a commit).  By granting someone a commit bit,
> > we have imparted a trust that an individual will protect the integrity of
> > the codebase and work in the best interest of the community.  If someone
> > makes a mistake (which has happened), we can easily rollback a commit.
> We
> > have even decided to rollback commits after getting 2 LGTMs on a PR.
> Under
> > the Apache Way, committers are encouraged to propel a project forward.
> > Restricting merges to RMs not only restricts velocity and it also limits
> > the energy/contributions of our large committer base.
> >
> > In terms of the rules below, we have, by consensus, accepted a set of
> > release principles [1] that specify how PRs should be reviewed and
> accepted
> > for merge to master.   If the guidelines outlined in that document are
> not
> > followed, we have accepted that another committer may rollback a commit.
> > Rajani and I will be watching the release branches.  If we find commits
> > that do not conform to our accepted merge rules, we will roll them back
> and
> > work with the committer to fix the issues.
> >
> > Thanks,
> > -John
> >
> > [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> > Release+principles+for+Apache+CloudStack+4.6+and+up
> >
> > >
> > john.burw...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> > On Aug 4, 2016, at 10:17 AM, Will Stevens  wrote:
> > >
> > > I will let the RMs for this release weigh in on this, but here are my
> > > thoughts.
> 

Re: Apache Cloudstack 4.8 and XenServer 7

[Syed Ahmed]

We've discussed this and there are changes in XS7 which might break
Cloudstack. if you do end up testing this, let us know. We can try to fix
it.

-Syed


On Fri, Jul 29, 2016 at 1:53 AM, Marty Godsey  wrote:

> Should there be any issues running XS7 with CS 4.8?
>
> Regards,
> Marty Godsey
>
>

Re: 4.10.0 release

[Will Stevens]

Yes, I agree with this.

CVEs need to be handled in security@ and will be added to the branches
manually once they have been agreed upon there, so no PRs are needed for
them.

I also agree that exceptions can be made for version changes in POMs and
such because those are scripted changes which are part of the release
process.  We may want to update the Release Procedure documentation to
include some details around the commits which Rohit made (which I
highlighted earlier) as those probably fall into this type of situation as
well.  Not sure those can be scripted as part of cutting a release, but
they are related to the release process, so detailed instructions for
making those changes would be helpful to include.

In general, yes, your statements are all correct.  We may want to send out
a bit of a notice on the dev@ list to highlight this.  For the last little
while we have been having the RMs handle all of the merging of code, so we
may want to officially inform the dev community that if you have commit
access you can commit, but you need to follow these guidelines [1].  I
would even go so far as to give a summary of the process.

*Example:*
Create a GH PR with the change and get 2 LGTM (including proof of tests
passing).

Once a PR is ready, commit it with the following flow.  Let's assume the
change is for 4.8 and needs to be forward merged.

$ git fetch origin
$ git checkout 4.8
$ git rebase origin 4.8
$ git pr 
$ git log -p
$ git push origin 4.8
$ git checkout 4.9
$ git rebase origin 4.9
$ git fwd-merge 4.8
$ git log -p
$ git push origin 4.9
$ git checkout master
$ git rebase origin master
$ git fwd-merge 4.9
$ git log -p
$ git push origin master

You can decipher this workflow from the Release Principles [1] document,
but it is not nearly this clear.  I suggest we make this process more
obvious so everyone knows what they are doing if they mae commits...

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 12:17 PM, John Burwell 
wrote:

> Will,
>
> My understanding of the release principles is that all changes must have a
> PR with the exception of CVE fixes.  Since we must accept CVE fixes in
> private, the 2 LGTM rule is applied on the security@ mailing list and on
> private JIRA security ticket.  I would also say that the release commits
> (e.g. tags, change of Maven versions in the POMs, etc) could also be
> granted an exception to the rule.  Otherwise, yes, my understanding is that
> everything else requires a PR.  Do you agree with that interpretation?
>
> Thanks,
> -John
>
> P.S. I plan to consolidate the release section of the wiki shortly as we
> have a number of topics that ostensibly conflict with each other.
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Aug 4, 2016, at 12:02 PM, Will Stevens  wrote:
> >
> >> john.burw...@shapeblue.com
>
>

[GitHub] cloudstack issue #1622: Adding missing bits field to TemplateResponse

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
RPM packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1622.


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

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

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1560
  
Hi guys,

This pull request it's been opened for a while, @rafaelweingartner, 
@bvbharatk you've reviewed it before, could you give your blessing to this PR?

CC: @swill 


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

[GitHub] cloudstack issue #1542: CLOUDSTACK-9379: Support nested virtualization at VM...

[nvazquez]

Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
Hi @DaanHoogland @remibergsma @ustcweizhou,

I rebased master branch for this pull request as it's been opened for a 
while, could it be reviewed please?




---
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 #1626: [blocker] Fix systemvm template build

[jburwell]

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

https://github.com/apache/cloudstack/pull/1626#discussion_r73559749
  
--- Diff: tools/appliance/definitions/systemvmtemplate/definition.rb ---
@@ -27,15 +27,15 @@
 architectures = {
 :i386 => {
 :os_type_id => 'Debian',
-:iso_file => 'debian-7.9.0-i386-netinst.iso',
-:iso_src => 
'http://cdimage.debian.org/cdimage/archive/7.9.0/i386/iso-cd/debian-7.9.0-i386-netinst.iso',
-:iso_md5 => 'e101a11ddb31f85acef542df1a49bf57',
+:iso_file => 'debian-7.11.0-i386-netinst.iso',
+:iso_src => 
'http://cdimage.debian.org/cdimage/archive/7.11.0/i386/iso-cd/debian-7.11.0-i386-netinst.iso',
+:iso_md5 => '75055a694508f5b891038ec12d703c9e',
 },
 :amd64 => {
 :os_type_id => 'Debian_64',
-:iso_file => 'debian-7.9.0-amd64-netinst.iso',
-:iso_src => 
'http://cdimage.debian.org/cdimage/archive/7.9.0/amd64/iso-cd/debian-7.9.0-amd64-netinst.iso',
-:iso_md5 => '774d1fc8c5364e63b22242c33a89c1a3'
+:iso_file => 'debian-7.11.0-amd64-netinst.iso',
+:iso_src => 
'http://cdimage.debian.org/cdimage/archive/7.11.0/amd64/iso-cd/debian-7.11.0-amd64-netinst.iso',
+:iso_md5 => '096c1c18b44c269808bd815d58c53c8f'
--- End diff --

Would it be possible to extract these values to a properties/configuration 
file?  Separating data from code is not more hygenic, but it also reduces the 
risk of the change and makes it easier to inject new values for 
development/testing.


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

[GitHub] cloudstack issue #1626: [blocker] Fix systemvm template build

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1626
  
Can you please create a JIRA ticket for this?


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

[GitHub] cloudstack issue #1605: CLOUDSTACK-9428: Fix for CLOUDSTACK-9211 - Improve p...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1605
  
 Ping for review  --  @sateesh-chodapuneedi, @rhtyd, @koushik-das


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

[GitHub] cloudstack issue #1612: packaging: Marvin and integration-tests packages

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1612
  
Can you please create a JIRA ticket for this?


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

[GitHub] cloudstack issue #1615: CLOUDSTACK-9438: Fix for CLOUDSTACK-9252 - Make NFS ...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1615
  
 Ping for second review  --  @GabrielBrascher, @rhtyd, @wido, 
@rafaelweingartner


---
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 #1626: [blocker] Fix systemvm template build

[rhtyd]

Github user rhtyd closed the pull request at:

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


---
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 #1626: [blocker] Fix systemvm template build

[rhtyd]

GitHub user rhtyd reopened a pull request:

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

[blocker] Fix systemvm template build

Previous PR: https://github.com/apache/cloudstack/pull/1531

Fixes failing systemvmtemplate build.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack systemvmtemplate-4dot9

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1626.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1626


commit f29e997e3fe763c21888fc61e2d05f3a9af86a6e
Author: Rohit Yadav 
Date:   2016-05-04T10:51:24Z

systemvmtemplate: fix build and upgrade to debian 7.11 iso

- Update base debian iso to version 7.11
- Upgrade ruby version to 2.3.0 (latest/stable)
- Fix Gemfile
- Update README

Signed-off-by: Rohit Yadav 

commit edc0286d14b6599f06ebf3febc960cb92252
Author: Rohit Yadav 
Date:   2016-07-27T12:43:11Z

systemvm: fix openswan version

This fixes build failure

Signed-off-by: Rohit Yadav 

commit c453d10f1f65e843937c6afb62bbf828d8058d38
Author: Rohit Yadav 
Date:   2016-07-27T16:53:35Z

systemvm: remove cloud-cleanup it's not available

Signed-off-by: Rohit Yadav 




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

[GitHub] cloudstack issue #1612: packaging: Marvin and integration-tests packages

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1612
  
@rhtyd will test this tomorrow and commit


---
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: 4.10.0 release

[John Burwell]

Will,

My understanding of the release principles is that all changes must have a PR 
with the exception of CVE fixes.  Since we must accept CVE fixes in private, 
the 2 LGTM rule is applied on the security@ mailing list and on private JIRA 
security ticket.  I would also say that the release commits (e.g. tags, change 
of Maven versions in the POMs, etc) could also be granted an exception to the 
rule.  Otherwise, yes, my understanding is that everything else requires a PR.  
Do you agree with that interpretation?

Thanks,
-John

P.S. I plan to consolidate the release section of the wiki shortly as we have a 
number of topics that ostensibly conflict with each other.

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

On Aug 4, 2016, at 12:02 PM, Will Stevens  wrote:
> 
>> john.burw...@shapeblue.com

Re: 4.10.0 release

[Will Stevens]

So if a change requires 2 LGTM before it can be committed, does that not
require that a PR be created for every change in order for us to have a
forum for the LGTM consensus?

I am trying to make sure we are careful about reverting back to a
free-for-all commit strategy so we don't run into issues with the stability
of master again.

I am obviously not trying to dictate anything, but I would like us to learn
from our previous mistakes and having a clear consensus on this topic is in
all of our interests.

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 11:45 AM, John Burwell 
wrote:

> Will,
>
> My point is that Rajani and I’s opinions on this topic (or any other)
> carry no more weight than any other committer.  We have volunteered to herd
> the cats to get releases out door.
>
> What is CI?  Within our community, there are many different definitions.
> I go with the industry definition — a central system of truth that builds
> and tests every commit.  While I would love to have such a system, it does
> not currently exist across the community (accepting that Travis CI
> partially implements the concept).  Our agreed upon principles do not
> mention CI.  They only require a 2 LGTMs (at least one for code and at
> least one for test).  If we want to change it, we need to ensure we have
> consensus on both the terms and any changes to guidelines.
>
> In terms of the two commits mentioned, I will look into them and determine
> whether or not I have any issues.  However, if you (or anyone) has an issue
> with a commit, there is no need to bottleneck around the RMs.  Open a
> discussion on dev@ to clarify/resolve any issues/concerns.  In the
> unlikely event that the we cannot find consensus on issues/concerns, then
> rollback the commit.
>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Aug 4, 2016, at 11:11 AM, Will Stevens  wrote:
> >
> > I am not saying that we should not let other people commit.  I am saying
> > that we need to be clear about the process we expect them to follow.
> John,
> > yes, we have the principles that you linked, but are we enforcing them?
> >
> > For example, these two commits were made directly to master without any
> > associated PR.
> > - 546a3f8884398391760b76ddcf02e6bc1f30d642
> > - fd7273b446738c0ebfae84189502dbdcd18bfd42
> >
> > I know they are required and they should be non-destructive, but they did
> > not follow our principles and go through CI, so do we really know.  Is
> that
> > ok?
> >
> > This is my point.  If we let anyone commit (which is their right as you
> > correctly point out), we need to start enforcing our commit principles.
> I
> > think it is important to have clarity on this point ASAP so everyone is
> > comfortable with these details.
> >
> > Cheers,
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Aug 4, 2016 at 10:58 AM, John Burwell <
> john.burw...@shapeblue.com>
> > wrote:
> >
> >> Rajani and Will,
> >>
> >> It is actually not up to the release managers to make such a
> >> determination.  Our bylaws state that anyone with a commit bit can
> commit
> >> (or, if necessary, rollback a commit).  By granting someone a commit
> bit,
> >> we have imparted a trust that an individual will protect the integrity
> of
> >> the codebase and work in the best interest of the community.  If someone
> >> makes a mistake (which has happened), we can easily rollback a commit.
> We
> >> have even decided to rollback commits after getting 2 LGTMs on a PR.
> Under
> >> the Apache Way, committers are encouraged to propel a project forward.
> >> Restricting merges to RMs not only restricts velocity and it also limits
> >> the energy/contributions of our large committer base.
> >>
> >> In terms of the rules below, we have, by consensus, accepted a set of
> >> release principles [1] that specify how PRs should be reviewed and
> accepted
> >> for merge to master.   If the guidelines outlined in that document are
> not
> >> followed, we have accepted that another committer may rollback a commit.
> >> Rajani and I will be watching the release branches.  If we find commits
> >> that do not conform to our accepted merge rules, we will roll them back
> and
> >> work with the committer to fix the issues.
> >>
> >> Thanks,
> >> -John
> >>
> >> [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> >> Release+principles+for+Apache+CloudStack+4.6+and+up
> >>
> >>>
> >> john.burw...@shapeblue.com
> >> www.shapeblue.com
> >> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> >> @shapeblue
> >>
> >>
> >>
> >> On Aug 4, 2016, at 10:17 AM, Will Stevens 

Re: 4.10.0 release

[John Burwell]

Will,

My point is that Rajani and I’s opinions on this topic (or any other) carry no 
more weight than any other committer.  We have volunteered to herd the cats to 
get releases out door.

What is CI?  Within our community, there are many different definitions.  I go 
with the industry definition — a central system of truth that builds and tests 
every commit.  While I would love to have such a system, it does not currently 
exist across the community (accepting that Travis CI partially implements the 
concept).  Our agreed upon principles do not mention CI.  They only require a 2 
LGTMs (at least one for code and at least one for test).  If we want to change 
it, we need to ensure we have consensus on both the terms and any changes to 
guidelines.

In terms of the two commits mentioned, I will look into them and determine 
whether or not I have any issues.  However, if you (or anyone) has an issue 
with a commit, there is no need to bottleneck around the RMs.  Open a 
discussion on dev@ to clarify/resolve any issues/concerns.  In the unlikely 
event that the we cannot find consensus on issues/concerns, then rollback the 
commit.  

Thanks,
-John

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

On Aug 4, 2016, at 11:11 AM, Will Stevens  wrote:
> 
> I am not saying that we should not let other people commit.  I am saying
> that we need to be clear about the process we expect them to follow.  John,
> yes, we have the principles that you linked, but are we enforcing them?
> 
> For example, these two commits were made directly to master without any
> associated PR.
> - 546a3f8884398391760b76ddcf02e6bc1f30d642
> - fd7273b446738c0ebfae84189502dbdcd18bfd42
> 
> I know they are required and they should be non-destructive, but they did
> not follow our principles and go through CI, so do we really know.  Is that
> ok?
> 
> This is my point.  If we let anyone commit (which is their right as you
> correctly point out), we need to start enforcing our commit principles.  I
> think it is important to have clarity on this point ASAP so everyone is
> comfortable with these details.
> 
> Cheers,
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 10:58 AM, John Burwell 
> wrote:
> 
>> Rajani and Will,
>> 
>> It is actually not up to the release managers to make such a
>> determination.  Our bylaws state that anyone with a commit bit can commit
>> (or, if necessary, rollback a commit).  By granting someone a commit bit,
>> we have imparted a trust that an individual will protect the integrity of
>> the codebase and work in the best interest of the community.  If someone
>> makes a mistake (which has happened), we can easily rollback a commit.  We
>> have even decided to rollback commits after getting 2 LGTMs on a PR.  Under
>> the Apache Way, committers are encouraged to propel a project forward.
>> Restricting merges to RMs not only restricts velocity and it also limits
>> the energy/contributions of our large committer base.
>> 
>> In terms of the rules below, we have, by consensus, accepted a set of
>> release principles [1] that specify how PRs should be reviewed and accepted
>> for merge to master.   If the guidelines outlined in that document are not
>> followed, we have accepted that another committer may rollback a commit.
>> Rajani and I will be watching the release branches.  If we find commits
>> that do not conform to our accepted merge rules, we will roll them back and
>> work with the committer to fix the issues.
>> 
>> Thanks,
>> -John
>> 
>> [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>> Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>>> 
>> john.burw...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> On Aug 4, 2016, at 10:17 AM, Will Stevens  wrote:
>>> 
>>> I will let the RMs for this release weigh in on this, but here are my
>>> thoughts.
>>> 
>>> If we let anyone commit, I think the following rules MUST be followed:
>>> - No commits directly to the repo, which are not a merge of a GitHub Pull
>>> Request.  So every change to the repo should be through `git pr `
>> using
>>> this tool [1].  This ensures everything that gets committed goes through
>>> our CI pipeline and is verified before commit.  It also makes it easier
>> for
>>> us to be able to script the generation of release notes and correlate the
>>> commit history with other sources (GitHub, Jira, etc).  I will submit a
>> PR
>>> with tools for generating release notes based on merged GitHub PRs
>> soon...
>>> - Every PR merged into a previous branch must be forward merged to later
>>> branches.  This is done using this tool [2] in order to make sure the
>>> 

Re: [VOTE] Apache Cloudstack 4.8.2 RC1

[Will Stevens]

Link didn't get auto-created correctly, so here it is again for everyone
who is using something like gmail as a client:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=
shortlog;h=refs/heads/4.8.2-RC20160804T1130

On Thu, Aug 4, 2016 at 11:37 AM, Will Stevens 
wrote:

> Hi All,
>
> I've created a 4.8.2 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=
> shortlog;h=refs/heads/4.8.2-RC20160804T1130
> Commit: d6fdde04357625e4d2d8b5ef09aafd2a0741dc17
>
> List of changes will be produced with the release notes once the RC passes.
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.8.2/
>
> PGP release keys (signed using CB818F64):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>

[VOTE] Apache Cloudstack 4.8.2 RC1

[Will Stevens]

Hi All,

I've created a 4.8.2 release, with the following artifacts up for a vote:

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/
4.8.2-RC20160804T1130
Commit: d6fdde04357625e4d2d8b5ef09aafd2a0741dc17

List of changes will be produced with the release notes once the RC passes.

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

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

Vote will be open for 72 hours.

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

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

Re: 4.10.0 release

[Will Stevens]

I am not saying that we should not let other people commit.  I am saying
that we need to be clear about the process we expect them to follow.  John,
yes, we have the principles that you linked, but are we enforcing them?

For example, these two commits were made directly to master without any
associated PR.
- 546a3f8884398391760b76ddcf02e6bc1f30d642
- fd7273b446738c0ebfae84189502dbdcd18bfd42

I know they are required and they should be non-destructive, but they did
not follow our principles and go through CI, so do we really know.  Is that
ok?

This is my point.  If we let anyone commit (which is their right as you
correctly point out), we need to start enforcing our commit principles.  I
think it is important to have clarity on this point ASAP so everyone is
comfortable with these details.

Cheers,

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 10:58 AM, John Burwell 
wrote:

> Rajani and Will,
>
> It is actually not up to the release managers to make such a
> determination.  Our bylaws state that anyone with a commit bit can commit
> (or, if necessary, rollback a commit).  By granting someone a commit bit,
> we have imparted a trust that an individual will protect the integrity of
> the codebase and work in the best interest of the community.  If someone
> makes a mistake (which has happened), we can easily rollback a commit.  We
> have even decided to rollback commits after getting 2 LGTMs on a PR.  Under
> the Apache Way, committers are encouraged to propel a project forward.
> Restricting merges to RMs not only restricts velocity and it also limits
> the energy/contributions of our large committer base.
>
> In terms of the rules below, we have, by consensus, accepted a set of
> release principles [1] that specify how PRs should be reviewed and accepted
> for merge to master.   If the guidelines outlined in that document are not
> followed, we have accepted that another committer may rollback a commit.
> Rajani and I will be watching the release branches.  If we find commits
> that do not conform to our accepted merge rules, we will roll them back and
> work with the committer to fix the issues.
>
> Thanks,
> -John
>
> [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Release+principles+for+Apache+CloudStack+4.6+and+up
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
>
> On Aug 4, 2016, at 10:17 AM, Will Stevens  wrote:
> >
> > I will let the RMs for this release weigh in on this, but here are my
> > thoughts.
> >
> > If we let anyone commit, I think the following rules MUST be followed:
> > - No commits directly to the repo, which are not a merge of a GitHub Pull
> > Request.  So every change to the repo should be through `git pr `
> using
> > this tool [1].  This ensures everything that gets committed goes through
> > our CI pipeline and is verified before commit.  It also makes it easier
> for
> > us to be able to script the generation of release notes and correlate the
> > commit history with other sources (GitHub, Jira, etc).  I will submit a
> PR
> > with tools for generating release notes based on merged GitHub PRs
> soon...
> > - Every PR merged into a previous branch must be forward merged to later
> > branches.  This is done using this tool [2] in order to make sure the
> > commit hashes are consistent across all branches.  This is for
> auditability
> > and comparing what exists in one branch vs another.
> >
> > [1] https://github.com/apache/cloudstack/blob/master/tools/git/git-pr
> > [2] https://github.com/apache/cloudstack/blob/master/tools/
> git/git-fwd-merge
> >
> > This is my two cents anyway...
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav 
> > wrote:
> >
> >> I disagree with having only RMs to merge PRs when we're not in freeze.
> In
> >> general we've implicitly honoured this behaviour but it was never voted.
> >> Our RMs may not be as active as we want them to be, while they are
> >> historically good at writing policies but it's hard to put them in
> practice
> >> and further it's understandable that they may not be able to volunteer
> >> enough time and effort to get the PRs sorted.
> >>
> >>
> >> Over past months this and similar practices have killed our commit and
> >> development momentum, and I think it's not a healthy practice for our
> >> community to engage in further. Instead, we can have committers (and in
> >> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
> >> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
> >> against at least one and 

Re: 4.10.0 release

[John Burwell]

Rajani and Will,

It is actually not up to the release managers to make such a determination.  
Our bylaws state that anyone with a commit bit can commit (or, if necessary, 
rollback a commit).  By granting someone a commit bit, we have imparted a trust 
that an individual will protect the integrity of the codebase and work in the 
best interest of the community.  If someone makes a mistake (which has 
happened), we can easily rollback a commit.  We have even decided to rollback 
commits after getting 2 LGTMs on a PR.  Under the Apache Way, committers are 
encouraged to propel a project forward.  Restricting merges to RMs not only 
restricts velocity and it also limits the energy/contributions of our large 
committer base.

In terms of the rules below, we have, by consensus, accepted a set of release 
principles [1] that specify how PRs should be reviewed and accepted for merge 
to master.   If the guidelines outlined in that document are not followed, we 
have accepted that another committer may rollback a commit.  Rajani and I will 
be watching the release branches.  If we find commits that do not conform to 
our accepted merge rules, we will roll them back and work with the committer to 
fix the issues.

Thanks,
-John

[1]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up

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

On Aug 4, 2016, at 10:17 AM, Will Stevens  wrote:
> 
> I will let the RMs for this release weigh in on this, but here are my
> thoughts.
> 
> If we let anyone commit, I think the following rules MUST be followed:
> - No commits directly to the repo, which are not a merge of a GitHub Pull
> Request.  So every change to the repo should be through `git pr ` using
> this tool [1].  This ensures everything that gets committed goes through
> our CI pipeline and is verified before commit.  It also makes it easier for
> us to be able to script the generation of release notes and correlate the
> commit history with other sources (GitHub, Jira, etc).  I will submit a PR
> with tools for generating release notes based on merged GitHub PRs soon...
> - Every PR merged into a previous branch must be forward merged to later
> branches.  This is done using this tool [2] in order to make sure the
> commit hashes are consistent across all branches.  This is for auditability
> and comparing what exists in one branch vs another.
> 
> [1] https://github.com/apache/cloudstack/blob/master/tools/git/git-pr
> [2] https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge
> 
> This is my two cents anyway...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav 
> wrote:
> 
>> I disagree with having only RMs to merge PRs when we're not in freeze. In
>> general we've implicitly honoured this behaviour but it was never voted.
>> Our RMs may not be as active as we want them to be, while they are
>> historically good at writing policies but it's hard to put them in practice
>> and further it's understandable that they may not be able to volunteer
>> enough time and effort to get the PRs sorted.
>> 
>> 
>> Over past months this and similar practices have killed our commit and
>> development momentum, and I think it's not a healthy practice for our
>> community to engage in further. Instead, we can have committers (and in
>> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
>> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
>> against at least one and ideally all three hypervisors - KVM, Xen and
>> VMware).
>> 
>> 
>> Regards.
>> 
>> 
>> From: Rajani Karuturi 
>> Sent: 03 August 2016 13:43:54
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.10.0 release
>> 
>> ouch.. looks like my email client stripped all the new lines.
>> Re-sending from webmail
>> 
>> Hi All,
>> These are the proposed dates for 4.10 release (copied from another thread
>> by John Burwell)
>> * Development (master open to features and defect fixes): 1 August 2016 -
>> 11 September 2016
>> * Testing: 12 - 18 September 2016
>> * RC Voting: 19 - 25 September 2016
>> * Release: 26 September 2016
>> 
>> master is open for 4.10.0.
>> It still means that only PRs will be merged and they will be merged only by
>> RMs ( For 4.10.0, its John Burwell and Rajani Karuturi)
>> Every PR should have a JIRA bug ID, 1 code review and 1 test review.
>> It would help in reviewing if the contributor could put information about
>> the feature/bug and how its tested.
>> Also, please rebase any pending PRs you have to the latest master or the
>> 4.9 release branch.
>> 
>> Finally, anyone in the community can review and 

Re: 4.10.0 release

[Will Stevens]

I will let the RMs for this release weigh in on this, but here are my
thoughts.

If we let anyone commit, I think the following rules MUST be followed:
- No commits directly to the repo, which are not a merge of a GitHub Pull
Request.  So every change to the repo should be through `git pr ` using
this tool [1].  This ensures everything that gets committed goes through
our CI pipeline and is verified before commit.  It also makes it easier for
us to be able to script the generation of release notes and correlate the
commit history with other sources (GitHub, Jira, etc).  I will submit a PR
with tools for generating release notes based on merged GitHub PRs soon...
- Every PR merged into a previous branch must be forward merged to later
branches.  This is done using this tool [2] in order to make sure the
commit hashes are consistent across all branches.  This is for auditability
and comparing what exists in one branch vs another.

[1] https://github.com/apache/cloudstack/blob/master/tools/git/git-pr
[2] https://github.com/apache/cloudstack/blob/master/tools/git/git-fwd-merge

This is my two cents anyway...

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav 
wrote:

> I disagree with having only RMs to merge PRs when we're not in freeze. In
> general we've implicitly honoured this behaviour but it was never voted.
> Our RMs may not be as active as we want them to be, while they are
> historically good at writing policies but it's hard to put them in practice
> and further it's understandable that they may not be able to volunteer
> enough time and effort to get the PRs sorted.
>
>
> Over past months this and similar practices have killed our commit and
> development momentum, and I think it's not a healthy practice for our
> community to engage in further. Instead, we can have committers (and in
> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
> against at least one and ideally all three hypervisors - KVM, Xen and
> VMware).
>
>
> Regards.
>
> 
> From: Rajani Karuturi 
> Sent: 03 August 2016 13:43:54
> To: dev@cloudstack.apache.org
> Subject: Re: 4.10.0 release
>
> ouch.. looks like my email client stripped all the new lines.
> Re-sending from webmail
>
> Hi All,
> These are the proposed dates for 4.10 release (copied from another thread
> by John Burwell)
> * Development (master open to features and defect fixes): 1 August 2016 -
> 11 September 2016
> * Testing: 12 - 18 September 2016
> * RC Voting: 19 - 25 September 2016
> * Release: 26 September 2016
>
> master is open for 4.10.0.
> It still means that only PRs will be merged and they will be merged only by
> RMs ( For 4.10.0, its John Burwell and Rajani Karuturi)
> Every PR should have a JIRA bug ID, 1 code review and 1 test review.
> It would help in reviewing if the contributor could put information about
> the feature/bug and how its tested.
> Also, please rebase any pending PRs you have to the latest master or the
> 4.9 release branch.
>
> Finally, anyone in the community can review and test PRs. We currently have
> huge backlog. We need everyones help in getting them merged(especially
> running the tests)
> Looking forward for your help in merging PRs.
> Happy PR bashing!!
>
> Thanks,
>
>
>
> ~Rajani
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> On Wed, Aug 3, 2016 at 1:19 PM, Erik Weber  wrote:
>
> > A newline or two wouldn't hurt, this is pretty hard to read tbh.
> >
> > --
> > Erik
> >
> > On Wed, Aug 3, 2016 at 9:27 AM, Rajani Karuturi 
> wrote:
> >
> > > Hi All,These are the proposed dates for 4.10 release (copied from
> > > another thread by John Burwell)* Development (master open to
> > > features and defect fixes): 1 August 2016 - 11 September 2016*
> > > Testing: 12 - 18 September 2016* RC Voting: 19 - 25 September
> > > 2016* Release: 26 September 2016
> > > master is open for 4.10.0. It still means that only PRs will be
> > > merged and they will be merged only by RMs ( For 4.10.0, its John
> > > Burwell and Rajani Karuturi)Every PR should have a JIRA bug ID, 1
> > > code review and 1 test review.It would help in reviewing if the
> > > contributor could put information about the feature/bug and how
> > > its tested.Also, please rebase any pending PRs you have to the
> > > latest master or the 4.9 release branch.
> > > Finally, anyone in the community can review and test PRs. We
> > > currently have huge backlog. We need everyones help in getting
> > > them merged(especially running the tests)Looking forward for your
> > > help in merging PRs. Happy PR bashing!!
> > > Thanks,~ 

[GitHub] cloudstack issue #1607: SSVM downloader now handles redirects properly.

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1607
  
@ProjectMoon can you close/open the PR to re-kick Travis


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

[GitHub] cloudstack issue #1492: [CLOUDSTACK-9003] Resource Naming Policies

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1492
  
@ProjectMoon can you close/open the PR to re-kick Travis


---
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] Apache Cloudstack 4.9.0 RC2

[Will Stevens]

Still working through getting the release notes written.  Hopefully will
have them finished in the next day or two.

*Will STEVENS*
Lead Developer

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

On Thu, Aug 4, 2016 at 1:39 AM, ilya  wrote:

> Hi Will and Team
>
> Can someone point me to upgrade instructions if such exist.
>
> Would like to avoid learning through trial and error if possible.
>
> I will be testing upgrade and functionality of KVM & VMware Advanced
> Shared Zones from ACS4.5.2 to latest.
>
> Thanks
> ilya
>
> On 7/29/16 11:06 AM, ilya wrote:
> > Hi Will
> >
> > What Remi mentioned sounds reasonable..
> >
> > I'll be spending sometime today and next week to test out the issue
> > reported in 4.8 with VR not starting in Basic Zone - as well latest 4.9..
> >
> > i know i'm late to the party - but this is the best i could do :(
> >
> > Regards,
> > ilya
> >
> >
> >
> > On 7/29/16 9:19 AM, Will Stevens wrote:
> >> I think everything is up to date and correct now.  Please let me know if
> >> anything seems out of place (this is the first time I have done this).
> >>
> >> I will wait to do an official announcement until Monday in case anything
> >> comes up.  I will also wait to update the following things until Monday:
> >> http://cloudstack.apache.org/downloads.html and the release notes
> (cause I
> >> have to finish them).
> >>
> >> Let me know if you have questions.
> >>
> >> Should I be cutting a 4.8.1 release as well?  Not sure how that works.
> >> Remi said to do the 4.9.0 release first and then take care of the 4.8.1
> >> release after.  Ideas?
> >>
> >> *Will STEVENS*
> >> Lead Developer
> >>
> >> *CloudOps* *| *Cloud Solutions Experts
> >> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >> w cloudops.com *|* tw @CloudOps_
> >>
> >> On Fri, Jul 29, 2016 at 12:13 PM, Will Stevens 
> >> wrote:
> >>
> >>> Yep, in the process of getting the release cut.  Got side tracked by
> >>> people a few times, but I am almost finished...  I will keep you
> posted...
> >>>
> >>> *Will STEVENS*
> >>> Lead Developer
> >>>
> >>> *CloudOps* *| *Cloud Solutions Experts
> >>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >>> w cloudops.com *|* tw @CloudOps_
> >>>
> >>> On Fri, Jul 29, 2016 at 12:10 PM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> >>> wrote:
> >>>
>  Thank you Will. Please cut the 4.9 branch so it can be picked for LTS
>  release work.
> 
>  I'll publish the rpm/deb packages in the sb hosted upstream repo
> shortly.
> 
>  Regards.
> 
> 
> 
> 
>  rohit.ya...@shapeblue.com
>  www.shapeblue.com
>  53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>  @shapeblue
> 
> 
> 
>  On Fri, Jul 29, 2016 at 7:27 PM +0530, "Will Stevens" <
>  wstev...@cloudops.com> wrote:
> 
>  Sorry, I did not follow the correct format.  :P
> 
>  After 72 hours, the vote for CloudStack 4.9.0 *passes* with 6 PMC + 2
>  non-PMC votes.
> 
>  +1 (PMC / binding)
>  * Rohit Yadav
>  * Mike Tutkowski
>  * Wido den Hollander
>  * Milamber
>  * Nux!
>  * John Burwell
> 
>  +1 (non binding)
>  * Paul Angus
>  * Abhinandan Prateek
> 
>  0
>  none
> 
>  -1
>  none
> 
>  Thanks to everyone participating.
> 
>  *Will STEVENS*
>  Lead Developer
> 
>  *CloudOps* *| *Cloud Solutions Experts
>  420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>  w cloudops.com *|* tw @CloudOps_
> 
>  On Fri, Jul 29, 2016 at 9:44 AM, Will Stevens 
>  wrote:
> 
> > The vote is closed.  The RC passed with the following votes.
> >
> > +1 : 8 (including 6 binding)
> > +0 : 0
> > -1 : 0
> >
> > Thanks everyone, I will get this pushed out today...
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Fri, Jul 29, 2016 at 5:24 AM, Abhinandan Prateek <
> > abhinandan.prat...@shapeblue.com> wrote:
> >
> >> +1
> >>
> >> Did manual testing with a cluster of Xen 6.5 in advanced zone.
> >> Vm life cycle
> >> VM Snapshot, volume snapshots
> >> Volume and Template from snapshots
> >> Migration
> >> Change Password
> >> Change service offering
> >> VPC, multiple tiers, VMs, ACLs
> >>
> >> Regards,
> >> -abhi
> >>
> >>
> >>
> >>
> >>
> >> On 29/07/16, 1:43 AM, "John Burwell" 
>  wrote:
> >>
> >>> All,
> >>>
> >>> I vote +1 (binding).  We have tested 4.9.0 RC2 in the following
> >> environments:
> >>>
> >>>   • CentOS 6.8 management server 

[GitHub] cloudstack issue #1612: packaging: Marvin and integration-tests packages

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1612
  
@karuturi can we also test/merge this. This is a packaging change that only 
introduces 'cloudstack-marvin' and 'cloudstack-integration-tests' packages. The 
above package build verifies that it does not break packaging.


---
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 #1620: oobm: simply change password transactional lo...

[rhtyd]

GitHub user rhtyd reopened a pull request:

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

oobm: simply change password transactional logic

- Simplifies change password transactional logic without using pessmistic 
locks
- Adds a re-enter password field in the UI to valid ipmi/oobm password

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack 4.9-oobm-password-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1620.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1620


commit 8ac3c883cd61fa0e18498aaae4e4f519743295c4
Author: Rohit Yadav 
Date:   2016-07-11T11:36:09Z

oobm: simply change password transactional logic

- Simplifies change password transactional logic without using pessmistic 
locks
- Adds a re-enter password field in the UI to valid ipmi/oobm password

Signed-off-by: Rohit Yadav 




---
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 #1620: oobm: simply change password transactional lo...

[rhtyd]

Github user rhtyd closed the pull request at:

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


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Thanks @karuturi 


---
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 #1625: [blocker] cloudstack: fix upgrade paths to 4....

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@karuturi our Trillian job has hit an internal bug so the job died, 
nevertheless a single run could take hours against real hypervisors (we've xen, 
kvm and vmware). I'll keep you posted when we've got that fixed and the 
PR-testing pipeline fixed. Meanwhile, we can consider Travis and your test 
results.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
yup... started testing.. in progress.. will be done probably in 30 min.. 
you started automation run.. should we wait for 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.
---

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@karuturi all green now, can we merge this? /cc @jburwell 


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

[GitHub] cloudstack issue #1612: packaging: Marvin and integration-tests packages

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1612
  
Packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1612. Initiating 
automated testing with Trillian shortly.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625. Initiating 
automated testing with Trillian shortly.


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

[GitHub] cloudstack issue #1626: [blocker] Fix systemvm template build

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1626
  
SystemVM template built and available at: 
http://packages.shapeblue.com/systemvmtemplate/custom/biggervarlog/.


---
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 #1531: systemvmtemplate: fix build and upgrade to de...

[rhtyd]

Github user rhtyd closed the pull request at:

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


---
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 #1626: [blocker] Fix systemvm template build

[rhtyd]

GitHub user rhtyd opened a pull request:

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

[blocker] Fix systemvm template build

Previous PR: https://github.com/apache/cloudstack/pull/1531

Fixes failing systemvmtemplate build.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack systemvmtemplate-4dot9

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1626.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1626


commit f29e997e3fe763c21888fc61e2d05f3a9af86a6e
Author: Rohit Yadav 
Date:   2016-05-04T10:51:24Z

systemvmtemplate: fix build and upgrade to debian 7.11 iso

- Update base debian iso to version 7.11
- Upgrade ruby version to 2.3.0 (latest/stable)
- Fix Gemfile
- Update README

Signed-off-by: Rohit Yadav 

commit edc0286d14b6599f06ebf3febc960cb92252
Author: Rohit Yadav 
Date:   2016-07-27T12:43:11Z

systemvm: fix openswan version

This fixes build failure

Signed-off-by: Rohit Yadav 

commit c453d10f1f65e843937c6afb62bbf828d8058d38
Author: Rohit Yadav 
Date:   2016-07-27T16:53:35Z

systemvm: remove cloud-cleanup it's not available

Signed-off-by: Rohit Yadav 




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

[GitHub] cloudstack issue #1626: [blocker] Fix systemvm template build

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1626
  
Ping for review and merge -- @karuturi @jburwell @agneya2001 @swill @wido 
@DaanHoogland and others


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
I'm able to consistently reproduce the unit test failure on a machine with 
similar memory as Travis (~8GB RAM):

searchForExistingLoadBalancer(org.apache.cloudstack.network.lb.ApplicationLoadBalancerTest)
  Time elapsed: 2.774 sec  <<< ERROR!
java.lang.IllegalStateException: Failed to load ApplicationContext
at 
org.springframework.test.context.CacheAwareContextLoaderDelegate.loadContext(CacheAwareContextLoaderDelegate.java:103)
at 
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:122)
at 
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at 
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at 
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:284)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at 
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: 
Failed to read candidate component class: file 
[/var/jenkins/workspace/cloudstack-pr/server/target/classes/org/apache/cloudstack/network/lb/CertServiceImpl.class];
 nested exception is java.lang.OutOfMemoryError: PermGen space


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-1625. Initiating 
automated testing with Trillian shortly.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
The unit test again failed with Travis:
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.821 sec 
<<< FAILURE! - in org.apache.cloudstack.network.lb.ApplicationLoadBalancerTest




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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@karuturi on the machine which was building the rpm packages


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Where did you see the OOM error? I dont see it in travis logs 
(this is for the previous travis job) 
https://s3.amazonaws.com/archive.travis-ci.org/jobs/149684289/log.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 issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Looks like this unit test is known to consume a lot of memory: Tests run: 
1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.918 sec - in 
org.apache.cloudstack.network.lb.ApplicationLoadBalancerTest
java.lang.OutOfMemoryError: PermGen space


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@karuturi that's a bot account that will do packaging and testing for us 
soon, I was testing it :)


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@blueorangutan the link doesnt work


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Looks like this unit test failed: Tests run: 2, Failures: 0, Errors: 1, 
Skipped: 0, Time elapsed: 4.773 sec <<< FAILURE! - in 
org.apache.cloudstack.network.lb.ApplicationLoadBalancerTest

I've seen this unit test fail sometimes, any ideas?


---
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 #1625: [blocker] cloudstack: fix upgrade paths to 4....

[rhtyd]

GitHub user rhtyd reopened a pull request:

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

[blocker] cloudstack: fix upgrade paths to 4.10.0

This adds an upgrade to master since the recent 4.9 cut, adds an upgrade 
path to the new code version 4.10. Without this PR all PRs to master are 
failing due to missing upgrade path. Please merge this on priority.

Code review and Travis results should be enough to validate the changes.

/cc @karuturi @wido @ProjectMoon @abhinandanprateek 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack dbupgrade-fix-4.10

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1625.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1625


commit 546a3f8884398391760b76ddcf02e6bc1f30d642
Author: Rohit Yadav 
Date:   2016-08-04T07:33:46Z

cloudstack: fix upgrade paths to 4.10.0

Signed-off-by: Rohit Yadav 




---
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 #1625: [blocker] cloudstack: fix upgrade paths to 4....

[rhtyd]

Github user rhtyd closed the pull request at:

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


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[rhtyd]

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
@karuturi thanks, I'll have a look why it failed


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
code looks good. 
I am seeing the following travis errors
`[ERROR] Failed to execute goal on project travis-build-deps: Could not 
resolve dependencies for project org.apache.cloudstack:travis-build-deps:jar:1: 
Failure to find net.nuage.vsp:nuage-vsp-acs-client:jar:3.2.8.0 in 
http://repo1.maven.org/maven2 was cached in the local repository, resolution 
will not be reattempted until the update interval of Central has elapsed or 
updates are forced -> [Help 1]`
`[ERROR] Failed to execute goal on project cloud-developer: Could not 
resolve dependencies for project 
org.apache.cloudstack:cloud-developer:pom:4.10.0-SNAPSHOT: Could not find 
artifact org.apache.cloudstack:cloud-server:jar:4.10.0-SNAPSHOT in 
apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]`
Can you force push please?



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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
Packages built and available at: 
http://packages.shapeblue.com/cloudstack/custom/github-. Initiating automated 
testing with Trillian shortly.


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

[GitHub] cloudstack issue #1625: [blocker] cloudstack: fix upgrade paths to 4.10.0

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1625
  
testing


---
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 #1625: [blocker] cloudstack: fix upgrade paths to 4....

[rhtyd]

GitHub user rhtyd opened a pull request:

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

[blocker] cloudstack: fix upgrade paths to 4.10.0

This adds an upgrade to master since the recent 4.9 cut, adds an upgrade 
path to the new code version 4.10. Without this PR all PRs to master are 
failing due to missing upgrade path. Please merge this on priority.

Code review and Travis results should be enough to validate the changes.

/cc @karuturi @wido @ProjectMoon @abhinandanprateek 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack dbupgrade-fix-4.10

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1625.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1625


commit 546a3f8884398391760b76ddcf02e6bc1f30d642
Author: Rohit Yadav 
Date:   2016-08-04T07:33:46Z

cloudstack: fix upgrade paths to 4.10.0

Signed-off-by: Rohit Yadav 




---
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: 4.10.0 release

[Rohit Yadav]

I disagree with having only RMs to merge PRs when we're not in freeze. In 
general we've implicitly honoured this behaviour but it was never voted. Our 
RMs may not be as active as we want them to be, while they are historically 
good at writing policies but it's hard to put them in practice and further it's 
understandable that they may not be able to volunteer enough time and effort to 
get the PRs sorted.


Over past months this and similar practices have killed our commit and 
development momentum, and I think it's not a healthy practice for our community 
to engage in further. Instead, we can have committers (and in future maybe 
bots) to merge a PR if they have 2 LGTMs, no objections and test results from 
both Travis (simulator) and Bubble/BVT/Trillian (tests against at least one and 
ideally all three hypervisors - KVM, Xen and VMware).


Regards.


From: Rajani Karuturi 
Sent: 03 August 2016 13:43:54
To: dev@cloudstack.apache.org
Subject: Re: 4.10.0 release

ouch.. looks like my email client stripped all the new lines.
Re-sending from webmail

Hi All,
These are the proposed dates for 4.10 release (copied from another thread
by John Burwell)
* Development (master open to features and defect fixes): 1 August 2016 -
11 September 2016
* Testing: 12 - 18 September 2016
* RC Voting: 19 - 25 September 2016
* Release: 26 September 2016

master is open for 4.10.0.
It still means that only PRs will be merged and they will be merged only by
RMs ( For 4.10.0, its John Burwell and Rajani Karuturi)
Every PR should have a JIRA bug ID, 1 code review and 1 test review.
It would help in reviewing if the contributor could put information about
the feature/bug and how its tested.
Also, please rebase any pending PRs you have to the latest master or the
4.9 release branch.

Finally, anyone in the community can review and test PRs. We currently have
huge backlog. We need everyones help in getting them merged(especially
running the tests)
Looking forward for your help in merging PRs.
Happy PR bashing!!

Thanks,



~Rajani


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On Wed, Aug 3, 2016 at 1:19 PM, Erik Weber  wrote:

> A newline or two wouldn't hurt, this is pretty hard to read tbh.
>
> --
> Erik
>
> On Wed, Aug 3, 2016 at 9:27 AM, Rajani Karuturi  wrote:
>
> > Hi All,These are the proposed dates for 4.10 release (copied from
> > another thread by John Burwell)* Development (master open to
> > features and defect fixes): 1 August 2016 - 11 September 2016*
> > Testing: 12 - 18 September 2016* RC Voting: 19 - 25 September
> > 2016* Release: 26 September 2016
> > master is open for 4.10.0. It still means that only PRs will be
> > merged and they will be merged only by RMs ( For 4.10.0, its John
> > Burwell and Rajani Karuturi)Every PR should have a JIRA bug ID, 1
> > code review and 1 test review.It would help in reviewing if the
> > contributor could put information about the feature/bug and how
> > its tested.Also, please rebase any pending PRs you have to the
> > latest master or the 4.9 release branch.
> > Finally, anyone in the community can review and test PRs. We
> > currently have huge backlog. We need everyones help in getting
> > them merged(especially running the tests)Looking forward for your
> > help in merging PRs. Happy PR bashing!!
> > Thanks,~ Rajanihttp://cloudplatform.accelerite.com/
>