[GitHub] cloudstack issue #1589: Fixing erraneous guest_os_hypervisor mappings

[wido]

Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1589
  
Thanks! Seem good to me.

LGTM


---
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 #1593: CLOUDSTACK-9417: Usage module refactoring

[wido]

Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1593
  
Packaging changes seem good to me. Java changes as well.

Based on the code this is LGTM to me


---
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 #1589: Fixing erraneous guest_os_hypervisor mappings

[ProjectMoon]

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

https://github.com/apache/cloudstack/pull/1589#discussion_r67349778
  
--- Diff: setup/db/db/schema-481to490.sql ---
@@ -545,3 +545,14 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(), 'VMware', '5.0', 'centos64Guest', 228, now(), 0);
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(), 'VMware', '5.1', 'centos64Guest', 228, now(), 0);
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(), 'VMware', '5.5', 'centos64Guest', 228, now(), 0);
+
+
+
--- End diff --

Maybe it would be useful to put a simple comment that explains what's going 
on in this section.


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

Documentation update

[Ron Wheeler]

I need the slides from the documentation discussion at the Montreal 
conference.



Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[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
  
Could this be reviewed for VMware please? Then I can work on extending it 
to other HVs

Thanks!


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

Failing to enable SSL/HTTPS on console proxy vm

[Nux!]

Hi,

Is there any particular voodoo involved in getting the $subject to work 
correctly on 4.8.0?
I've uploaded the Comodo wildcard cabundle, crt and key in the Infrastructure 
page, the systemvms have rebooted.
They came back fine and nothing dodgy in the logs, but when I open the console 
of a VM Firefox will say there are insecure contents loaded and will not 
display the terminal ajax thingy.
View source shoes an iframe linking http://1.2.3.4 instead of 
https://1-2-3-4.wildcarddomain.tld.

Apache HTTPD and Tomcat had no issues with these certs.

Is there something that I am missing?

Thanks


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Failing to enable SSL/HTTPS on console proxy vm

[Will Stevens]

We have been having issues with this for as long as I can remember (on both
ACS and CCP).  In order to get it to work you have to 'trust unsafe
scripts' or whatever by clicking the shield in the URL bar in the top right
(maybe that is chrome).

I don't know that there is a solution, but if there is, I am all ears...

*Will STEVENS*
Lead Developer

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

On Thu, Jun 16, 2016 at 11:54 AM, Nux!  wrote:

> Hi,
>
> Is there any particular voodoo involved in getting the $subject to work
> correctly on 4.8.0?
> I've uploaded the Comodo wildcard cabundle, crt and key in the
> Infrastructure page, the systemvms have rebooted.
> They came back fine and nothing dodgy in the logs, but when I open the
> console of a VM Firefox will say there are insecure contents loaded and
> will not display the terminal ajax thingy.
> View source shoes an iframe linking http://1.2.3.4 instead of
> https://1-2-3-4.wildcarddomain.tld.
>
> Apache HTTPD and Tomcat had no issues with these certs.
>
> Is there something that I am missing?
>
> Thanks
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: Failing to enable SSL/HTTPS on console proxy vm

[Nux!]

I have a working 4.4.1 setup with some workarounds[1], but I'm failing with 4.8.


[1] http://www.nux.ro/archive/2014/03/Run_your_own_realhostip.html

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Will Stevens" 
> To: dev@cloudstack.apache.org
> Cc: "Cloudstack Users List" 
> Sent: Thursday, 16 June, 2016 17:01:12
> Subject: Re: Failing to enable SSL/HTTPS on console proxy vm

> We have been having issues with this for as long as I can remember (on both
> ACS and CCP).  In order to get it to work you have to 'trust unsafe
> scripts' or whatever by clicking the shield in the URL bar in the top right
> (maybe that is chrome).
> 
> I don't know that there is a solution, but if there is, I am all ears...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
> On Thu, Jun 16, 2016 at 11:54 AM, Nux!  wrote:
> 
>> Hi,
>>
>> Is there any particular voodoo involved in getting the $subject to work
>> correctly on 4.8.0?
>> I've uploaded the Comodo wildcard cabundle, crt and key in the
>> Infrastructure page, the systemvms have rebooted.
>> They came back fine and nothing dodgy in the logs, but when I open the
>> console of a VM Firefox will say there are insecure contents loaded and
>> will not display the terminal ajax thingy.
>> View source shoes an iframe linking http://1.2.3.4 instead of
>> https://1-2-3-4.wildcarddomain.tld.
>>
>> Apache HTTPD and Tomcat had no issues with these certs.
>>
>> Is there something that I am missing?
>>
>> Thanks
>>
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro

Re: Failing to enable SSL/HTTPS on console proxy vm

[Nux!]

Dammit, I was missing the consoleproxy.url.domain! What an idiot ...
Works just fine now.

Will, it can be done, don't give up! :)

Thanks Andy!

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Andy Dills" 
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Sent: Thursday, 16 June, 2016 17:10:55
> Subject: Re: Failing to enable SSL/HTTPS on console proxy vm

> I have this working perfectly.
> 
> Couple of key things that are not mentioned in the
> documentation:
> 
> - You need to set consoleproxy.url.domain to *.domain.com for whatever domain
> you're using. Do this before re-uploading your SSL certificate. The SSL upload
> dialogue doesn't set this value as it should.
> 
> - You need a wildcard certificate for that domain.
> 
> Assuming you setup the proper DNS records, it should then work.
> 
> I'm open to follow up questions if anybody is struggling with this.
> 
> Thanks,
> Andy
> 
> Sent from my iPhone
> 
>> On Jun 16, 2016, at 12:01 PM, Will Stevens  wrote:
>> 
>> We have been having issues with this for as long as I can remember (on both
>> ACS and CCP).  In order to get it to work you have to 'trust unsafe
>> scripts' or whatever by clicking the shield in the URL bar in the top right
>> (maybe that is chrome).
>> 
>> I don't know that there is a solution, but if there is, I am all ears...
>> 
>> *Will STEVENS*
>> Lead Developer
>> 
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>> 
>>> On Thu, Jun 16, 2016 at 11:54 AM, Nux!  wrote:
>>> 
>>> Hi,
>>> 
>>> Is there any particular voodoo involved in getting the $subject to work
>>> correctly on 4.8.0?
>>> I've uploaded the Comodo wildcard cabundle, crt and key in the
>>> Infrastructure page, the systemvms have rebooted.
>>> They came back fine and nothing dodgy in the logs, but when I open the
>>> console of a VM Firefox will say there are insecure contents loaded and
>>> will not display the terminal ajax thingy.
>>> View source shoes an iframe linking http://1.2.3.4 instead of
>>> https://1-2-3-4.wildcarddomain.tld.
>>> 
>>> Apache HTTPD and Tomcat had no issues with these certs.
>>> 
>>> Is there something that I am missing?
>>> 
>>> Thanks
>>> 
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro

Re: Failing to enable SSL/HTTPS on console proxy vm

[Will Stevens]

That's in global settings I presume?
On Jun 16, 2016 12:19 PM, "Nux!"  wrote:

> Dammit, I was missing the consoleproxy.url.domain! What an idiot ...
> Works just fine now.
>
> Will, it can be done, don't give up! :)
>
> Thanks Andy!
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Andy Dills" 
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Sent: Thursday, 16 June, 2016 17:10:55
> > Subject: Re: Failing to enable SSL/HTTPS on console proxy vm
>
> > I have this working perfectly.
> >
> > Couple of key things that are not mentioned in the
> > documentation:
> >
> > - You need to set consoleproxy.url.domain to *.domain.com for whatever
> domain
> > you're using. Do this before re-uploading your SSL certificate. The SSL
> upload
> > dialogue doesn't set this value as it should.
> >
> > - You need a wildcard certificate for that domain.
> >
> > Assuming you setup the proper DNS records, it should then work.
> >
> > I'm open to follow up questions if anybody is struggling with this.
> >
> > Thanks,
> > Andy
> >
> > Sent from my iPhone
> >
> >> On Jun 16, 2016, at 12:01 PM, Will Stevens 
> wrote:
> >>
> >> We have been having issues with this for as long as I can remember (on
> both
> >> ACS and CCP).  In order to get it to work you have to 'trust unsafe
> >> scripts' or whatever by clicking the shield in the URL bar in the top
> right
> >> (maybe that is chrome).
> >>
> >> I don't know that there is a solution, but if there is, I am all ears...
> >>
> >> *Will STEVENS*
> >> Lead Developer
> >>
> >> *CloudOps* *| *Cloud Solutions Experts
> >> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >> w cloudops.com *|* tw @CloudOps_
> >>
> >>> On Thu, Jun 16, 2016 at 11:54 AM, Nux!  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any particular voodoo involved in getting the $subject to work
> >>> correctly on 4.8.0?
> >>> I've uploaded the Comodo wildcard cabundle, crt and key in the
> >>> Infrastructure page, the systemvms have rebooted.
> >>> They came back fine and nothing dodgy in the logs, but when I open the
> >>> console of a VM Firefox will say there are insecure contents loaded and
> >>> will not display the terminal ajax thingy.
> >>> View source shoes an iframe linking http://1.2.3.4 instead of
> >>> https://1-2-3-4.wildcarddomain.tld.
> >>>
> >>> Apache HTTPD and Tomcat had no issues with these certs.
> >>>
> >>> Is there something that I am missing?
> >>>
> >>> Thanks
> >>>
> >>>
> >>> --
> >>> Sent from the Delta quadrant using Borg technology!
> >>>
> >>> Nux!
> >>> www.nux.ro
>

[GitHub] cloudstack pull request #1594: CLOUDSTACK-9407: vm_network_map table doesnt ...

[nvazquez]

GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-9407: vm_network_map table doesnt get cleaned up properly

JIRA TICKET: https://issues.apache.org/jira/browse/CLOUDSTACK-9407

### Introduction
It was found out that in production environments `vm_network_map` table 
entries were slowly growing. It was investigated how this entries were cleaned 
up.

### Behaviour
On vm creation, vm mappings are inserted on `vm_network_map`.
On vm stop, mappings are deleted from `vm_network_map` for vm, as a result 
of the release of its nics.

### Problem
If created vm is stopped from hypervisor side (at least on vSphere in which 
we tested it), when CloudStack realizes vm is stopped it doesn't clean up 
`vm_network_table,` and, as cleanup is made during vm stop, when vm is 
eventually destroyed and expunged it won't clean up their entries in that table.

### Proposed solution
We propose to move `vm_network_map` table cleanup to expunge command 
instead of stop command.

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

$ git pull https://github.com/nvazquez/cloudstack vmnetworkmapissue

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

https://github.com/apache/cloudstack/pull/1594.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 #1594


commit d3f3fb0590f14c540493d5f27c18cea13fa092af
Author: nvazquez 
Date:   2016-06-06T14:47:45Z

CLOUDSTACK-9407: Release network resources on expunge command




---
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: Failing to enable SSL/HTTPS on console proxy vm

[Andy Dills]

I have this working perfectly.

Couple of key things that are not mentioned in the 
documentation:

- You need to set consoleproxy.url.domain to *.domain.com for whatever domain 
you're using. Do this before re-uploading your SSL certificate. The SSL upload 
dialogue doesn't set this value as it should.

- You need a wildcard certificate for that domain.

Assuming you setup the proper DNS records, it should then work.

I'm open to follow up questions if anybody is struggling with this.

Thanks,
Andy

Sent from my iPhone

> On Jun 16, 2016, at 12:01 PM, Will Stevens  wrote:
> 
> We have been having issues with this for as long as I can remember (on both
> ACS and CCP).  In order to get it to work you have to 'trust unsafe
> scripts' or whatever by clicking the shield in the URL bar in the top right
> (maybe that is chrome).
> 
> I don't know that there is a solution, but if there is, I am all ears...
> 
> *Will STEVENS*
> Lead Developer
> 
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
> 
>> On Thu, Jun 16, 2016 at 11:54 AM, Nux!  wrote:
>> 
>> Hi,
>> 
>> Is there any particular voodoo involved in getting the $subject to work
>> correctly on 4.8.0?
>> I've uploaded the Comodo wildcard cabundle, crt and key in the
>> Infrastructure page, the systemvms have rebooted.
>> They came back fine and nothing dodgy in the logs, but when I open the
>> console of a VM Firefox will say there are insecure contents loaded and
>> will not display the terminal ajax thingy.
>> View source shoes an iframe linking http://1.2.3.4 instead of
>> https://1-2-3-4.wildcarddomain.tld.
>> 
>> Apache HTTPD and Tomcat had no issues with these certs.
>> 
>> Is there something that I am missing?
>> 
>> Thanks
>> 
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 

Dead wiki page

[Ron Wheeler]

Can this page be deleted.

It is old and the links are dead.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Developer+Summit

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

CloudStack Mascot Proposals

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Mascot+Proposals

Can this page be deleted?


Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

ASF Infrastructure Migration Thoughts

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/CLOUDSTACK/ASF+Infrastructure+Migration+Thoughts


This seems to be mostly conjecture rather than history.

It is old and does not seem to have an current use.

Can it be deleted?

Ron


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

ApiXmlDocReader.java - Used by anyone???

[Will Stevens]

Hey All,
Does anyone know if this class [1] is being used anywhere (other than by
Pierre-Luc to create the release notes [2]).

The reason I ask is because I know Pierre-Luc spends a lot of time every
release manually changing the formatting from what is [3] output to RST
format so it can be displayed.

I have already built a parser to generate the 'fixed issues' piece [5] of
the release notes (will be open sourced soon).

If PL is the only person using this class I will either:
a) Modify the class to output the details in an RST format so the output
can be directly pasted into the release notes.
b) Modify the class to output structured JSON so the data can be easily
consumed by parsers.  I would then write a small script to parse the JSON
and output the RST format for the RN.

I would lean towards b) so the Java code would not have to be modified if
we changed the format of the docs to another format (like Markdown for
example).

Worst case scenario, I will just write a parser that takes that meh layout
and output a RST table for the RNs.

Thanks,

Will

[1]
https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/api/doc/ApiXmlDocReader.java
[2] https://github.com/pdion891/acs-api-commands
[3]
https://github.com/pdion891/acs-api-commands/blob/master/diff-470-480/diff.txt
[4]
https://raw.githubusercontent.com/apache/cloudstack-docs-rn/master/source/api-changes.rst
[5]
https://objects-east.cloud.ca/v1/5ef827605f884961b94881e928e7a250/swill/rn.png

Re: [DISCUSS] 5.0.0 and 6.0.0

[John Burwell]

Wido,

Please see my responses in-line below.

Thanks,
-John

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


On Jun 15, 2016, at 3:54 AM, Wido den Hollander  wrote:
> 
> You really like typing long e-mails! :)

Not particularly, no.  However, this subject is hard to make small. :(

> 
>> Op 15 juni 2016 om 2:39 schreef John Burwell :
>> 
>> 
>> All,
>> 
>> We have been discussing whether or not the next release would introduce the 
>> need to increment the major revision number from 4 to 5 (i.e. become 5.0.0). 
>>  While I think we are very close to the time to have a 5.0.0 release, I 
>> don’t think the next release will introduce any backwards compatible changes 
>> that necessitate.  However, Wido has brought two important questions — What 
>> are our goals for a 5.0.0 release? When do we think we should target its 
>> release?  I think we should address and gain consensus on these issues now 
>> rather than allow circumstances to answer them for us.
>> 
>> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, 
>> someday release when CloudStack would have a perfect architecture, build 
>> process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen 
>> into the trap of seeing 5.0.0 as some endpoint of perfection rather than an 
>> important milestone in the on-going improvement and evolution of the 
>> project.  Thinking it about is the former rather than the later, I realize 
>> that we have a legacy cruft that we need to discard in order to move forward 
>> and architectural design improvements that we must implement to address 
>> emerging infrastructure requirements.  I think we would be wise to separate 
>> these two objectives into a 5.0.0 release (cruft removal/breaking 
>> refactorings) and 6.0.0 (backwards incompatible architectural redesign).  
>> Not only do I see this approach as a risk mitigation, but also as a way to 
>> deliver improvements to users and developers as quickly as possible.
>> 
>> For 5.0.0, my thought is that we would target the following high-level 
>> objectives:
>> 
>> * Drop Java7 and adopt Java8 runtime and language features
>> * Drop support for any hypervisor versions no longer supported by their 
>> vendors or communities
>> * Drop any plugins which are no longer maintained or for which the community 
>> has no means to test
>> * Drop support for any distributions no longer supported by their vendors or 
>> communities
> 
> +1 to these points above.
> 
>> * Define an official support matrix for the project
>> * Adopt a formal policy for sunsetting support of components based on the 
>> end-of-life dates set by their vendors or communities
>> * Refactoring/cleanup of various APIs
>> * Embedded Jetty/uberjar/unified YAML file configuration
>> 
> 
> Not completely sure about a official support matrix, but I get the point.

What are your concerns?

> 
>> While I am sure there are more clean up items, the focus of the release 
>> would be to discard pieces that are in the way on further improvement.
>> 
>> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community 
>> time to build atop 5.0.0 to redesign/improve the architecture of the system.
>> 
>> I would like to see 5.0.0 released by the end of 2016 or at the beginning of 
>> 2017.  Based on the release plan I previously proposed, we would have the 
>> following releases remaining in 2016 and in early 2017: 
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 4.12 releasing on or about 18 December 2016 
>> * 4.13 release on or about 5 February 2017
>> 
>> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release 
>> described above.  It would give us sometime to plan and gain consensus 
>> around the changes in both the user and dev communities.  It would also 
>> allow the second LTS release to be based on 5.0.0 — allowing both release 
>> cycles to take advantage of the reduced support requirements and Java8 
>> language features. Based on this proposal, the releases above would change 
>> to the following:
>> 
>> * 4.10 releasing on or about 28 August 2016
>> * 4.11 releasing on or about 23 October 2016
>> * 5.0.0 releasing on or about 18 December 2016 
>> * 5.1.0 release on or about 5 February 2017
>> 
> 
> My question is mainly who is going to support all versions and maintain them. 
> Developers like to work on the newest stuff, so we get back to the LTS 
> version. Person A fixes something in 5.0 and doesn't want/like to backport it 
> to 4.X, what happens?
> 
> I'm all in favor of a 5.0 release, but we get back to the previously 
> discussed topics around a LTS and the different views on that.

The release cycle I have proposed states that the only regular releases 
maintained are the current release and the current release - 1.  Therefore, 
when 5.0.0 is released, only the 5.0.0, 4.11, and LTS-4.9.0 branches will be 
mai

Re: Release-Management Question about New API Plug-in

[John Burwell]

Mike,

Anyone can submit a PR against any branch.  If they can get 2 LGTMs for it, it 
will be merged.  After that, you could create a new 4.6 RC, and open a vote for 
it.  While there is nothing procedurally that prevents someone from following 
this process, it is unlikely that the release vote would muster interest to 
pass.

Thanks,
-John

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


On Jun 16, 2016, at 2:29 AM, Tutkowski, Mike  wrote:
> 
> OK - I can always deliver the plug-in for 4.6 directly to my customers and 
> first check it into the CloudStack repo maybe in 4.10 or later.
> 
>> On Jun 16, 2016, at 12:21 AM, Rajani Karuturi  wrote:
>> 
>> "We will only fix bugs in this release branch, no back porting of new
>> features" -
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
>> 
>> I would prefer a PR on master for 4.9+
>> 
>> 
>> 
>> ~Rajani
>> 
>> On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike 
>> wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> This is mainly a release-management question, but - of course - anyone who
>>> knows, please feel free to comment.
>>> 
>>> 
>>> I have been developing a new API plug-in for a customer. The customer is
>>> using CloudStack 4.6.
>>> 
>>> 
>>> I'd like to contribute the plug-in to our official repo, but I'm wondering
>>> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
>>> this plug-in in all subsequent releases, as well).
>>> 
>>> 
>>> Thoughts on this?
>>> 
>>> 
>>> Thanks!
>>> 
>>> Mike
>>> 

Re: 4.9+ release

[John Burwell]

Rajani,

By the rules of semantic versioning (which we follow), incrementing the major 
version should only occur if there there is a change that breaks backwards 
compatibility of the API, removes support for a integrated component, or 
otherwise reduces/removes existing functionality.  Assuming we targeting late 
August 2016 for the next release, it is a bit short notice to introduce such 
changes.  Therefore, the next release should be 4.10.

I have opened a discussion to determine if/when we should have a 5.0.0 release 
in order to provide developers and users with sufficient notice for such 
significant changes.

Thanks,
-John

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


On Jun 15, 2016, at 5:31 AM, Rajani Karuturi  wrote:
> 
> I like this discussion. But, my original question was not about what should
> the next release number be?
> 
> i was checking if anyone working on anything big and hence want the next
> release to be 5.0?
> 
> ~Rajani
> 
> 
> 
> 
> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland 
> wrote:
> 
>> maybe I should have answered here instead of the other thread :S
>> 
>> I am all with John on this. I can not judge the dates but the overall ideas
>> are spot on.
>> 
>> I now see the API weren't mentioned in this thread I think they should.
>> 
>> On Wed, Jun 15, 2016 at 1:53 AM, ilya 
>> wrote:
>> 
>>> I agree and support John's comments below.
>>> 
>>> Regards
>>> ilya
>>> 
>>> On 6/14/16 2:44 PM, John Burwell wrote:
 All,
 
 Completely agree with Daan.  Per semantic versioning, a major revision
>>> increase must introduce a backwards incompatible change in the public
>> API,
>>> removal of one of more supported devices, reduction in the list of
>>> supported distributions.  I agree that when we require Java8+, drop
>> Ubuntu
>>> 12.04 support, drop support for an old hypervisor version, etc,  we will
>>> need to increment the major revision to reflect the fact that the release
>>> is not backwards compatible.
 
 For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
>>> on either Java7 or Java8.  In particular, producing an LTS release that
>>> only supports a JVM that has been unsupported for nearly 18 months would
>>> make it DOA in many shops.
 
 It seems like it would make sense to have a 5.0.0 release that removed
>>> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
>>> Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
>>> configuration).  The focus of this release would be to reduce the
>> footprint
>>> of codebase, as well as, make a set of backwards incompatible changes
>> that
>>> further decouples plugins from core.  We would then plan for a 6.0.0 in
>>> 4Q2017 to introduce further architectural changes and API revisions.  The
>>> advantage to this approach is that it breaks up the large refactorings
>> and
>>> architectural design changes — allowing us to gain velocity by removing
>>> legacy components, reducing the risk of these changes, and providing user
>>> benefit earlier.  Based on the release plan I previously proposed we have
>>> the following releases remaining in 2016 and in early 2017:
 
 * 4.10 releasing on or about 28 August 2016
 * 4.11 releasing on or about 23 October 2016
 * 4.12 releasing on or about 18 December 2016
 * 4.13 release on or about 5 February 2017
 
 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
>> release
>>> described above.  It would give us sometime to plan and gain consensus
>>> around the changes in both the user and dev communities.  It would also
>>> allow the second LTS release to be based on 5.0.0 — allowing both release
>>> cycles to take advantage of the reduced support requirements and Java8
>>> language features. Based on this proposal, the releases above would
>> change
>>> to the following:
 
 * 4.10 releasing on or about 28 August 2016
 * 4.11 releasing on or about 23 October 2016
 * 5.0.0 releasing on or about 18 December 2016
 * 5.1.0 release on or about 5 February 2017
 
 I am in the process of moving my proposal into the wiki.  If this
>>> approach is acceptable, I will reflect it there, and open a thread to
>>> discuss 5.0.0.
 
 Thanks,
 -John
 
 
> 
 john.burw...@shapeblue.com
 www.shapeblue.com
 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
 @shapeblue
 
 
 On Jun 14, 2016, at 2:02 PM, Paul Angus 
>>> wrote:
> 
> +1 Daan.
> 
> My recollection was that major version number changes were only to be
>>> triggered by breaks in backward compatibility (API).
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> -O

Re: 4.9+ release

[John Burwell]

Marco,

As I said in the 5.0.0 thread, I believe that we need to look upon 
architectural improvement as a continuous process.  We have been stymied for 
years around an analysis paralysis that holds that we must address 
architectural issue in 5.0.0.  I believe that we need to start with remove a 
significant amount of technical debt and cruft in 5.0.0 which will lay the 
foundation for larger architectural improvements later in 2017.

Thanks,
-John

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


On Jun 15, 2016, at 7:48 AM, ma...@exoscale.ch wrote:
> 
> Hi,
> 
> From my CS starter point of view, I agree with John's comment. I would really 
> like to see the next major version with a code & architecture clean-up, 
> especially producing a code architecture in the direction of the Java9 Jigsaw 
> modularity. It would be sad not to take the next specifications into account.
> For the dates, it's good to produce periodically a new release for the 4.X 
> but I don't see how putting one on the first 5.x version can be done before 
> defining what will be it.
> 
> Marco
> 
> -- To introduce myself, I joined Exoscale a few months ago to work on CS code 
> base to suit their needs.
> 
> 
>> On 15 Jun 2016, at 11:31, Rajani Karuturi  wrote:
>> 
>> I like this discussion. But, my original question was not about what should
>> the next release number be?
>> 
>> i was checking if anyone working on anything big and hence want the next
>> release to be 5.0?
>> 
>> ~Rajani
>> 
>> 
>> 
>> 
>> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland 
>> wrote:
>> 
>>> maybe I should have answered here instead of the other thread :S
>>> 
>>> I am all with John on this. I can not judge the dates but the overall ideas
>>> are spot on.
>>> 
>>> I now see the API weren't mentioned in this thread I think they should.
>>> 
>>> On Wed, Jun 15, 2016 at 1:53 AM, ilya 
>>> wrote:
>>> 
 I agree and support John's comments below.
 
 Regards
 ilya
 
 On 6/14/16 2:44 PM, John Burwell wrote:
> All,
> 
> Completely agree with Daan.  Per semantic versioning, a major revision
 increase must introduce a backwards incompatible change in the public
>>> API,
 removal of one of more supported devices, reduction in the list of
 supported distributions.  I agree that when we require Java8+, drop
>>> Ubuntu
 12.04 support, drop support for an old hypervisor version, etc,  we will
 need to increment the major revision to reflect the fact that the release
 is not backwards compatible.
> 
> For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
 on either Java7 or Java8.  In particular, producing an LTS release that
 only supports a JVM that has been unsupported for nearly 18 months would
 make it DOA in many shops.
> 
> It seems like it would make sense to have a 5.0.0 release that removed
 support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
 Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
 configuration).  The focus of this release would be to reduce the
>>> footprint
 of codebase, as well as, make a set of backwards incompatible changes
>>> that
 further decouples plugins from core.  We would then plan for a 6.0.0 in
 4Q2017 to introduce further architectural changes and API revisions.  The
 advantage to this approach is that it breaks up the large refactorings
>>> and
 architectural design changes — allowing us to gain velocity by removing
 legacy components, reducing the risk of these changes, and providing user
 benefit earlier.  Based on the release plan I previously proposed we have
 the following releases remaining in 2016 and in early 2017:
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 4.12 releasing on or about 18 December 2016
> * 4.13 release on or about 5 February 2017
> 
> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
>>> release
 described above.  It would give us sometime to plan and gain consensus
 around the changes in both the user and dev communities.  It would also
 allow the second LTS release to be based on 5.0.0 — allowing both release
 cycles to take advantage of the reduced support requirements and Java8
 language features. Based on this proposal, the releases above would
>>> change
 to the following:
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 5.0.0 releasing on or about 18 December 2016
> * 5.1.0 release on or about 5 February 2017
> 
> I am in the process of moving my proposal into the wiki.  If this
 approach is acceptable, I will reflect it there, and open a thread to
 discuss 5.0.0.
> 
> Thanks,
> -John
> 

Re: Release-Management Question about New API Plug-in

[Tutkowski, Mike]

Sounds good, John

I think it will be easier if I just release it directly to the customer.

I can always port it to the latest CloudStack version later, if I'd like to.

> On Jun 16, 2016, at 8:46 PM, John Burwell  wrote:
> 
> Mike,
> 
> Anyone can submit a PR against any branch.  If they can get 2 LGTMs for it, 
> it will be merged.  After that, you could create a new 4.6 RC, and open a 
> vote for it.  While there is nothing procedurally that prevents someone from 
> following this process, it is unlikely that the release vote would muster 
> interest to pass.
> 
> Thanks,
> -John
> 
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 
>> On Jun 16, 2016, at 2:29 AM, Tutkowski, Mike  
>> wrote:
>> 
>> OK - I can always deliver the plug-in for 4.6 directly to my customers and 
>> first check it into the CloudStack repo maybe in 4.10 or later.
>> 
>>> On Jun 16, 2016, at 12:21 AM, Rajani Karuturi  wrote:
>>> 
>>> "We will only fix bugs in this release branch, no back porting of new
>>> features" -
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
>>> 
>>> I would prefer a PR on master for 4.9+
>>> 
>>> 
>>> 
>>> ~Rajani
>>> 
>>> On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike 
>>> wrote:
>>> 
 Hi,
 
 
 This is mainly a release-management question, but - of course - anyone who
 knows, please feel free to comment.
 
 
 I have been developing a new API plug-in for a customer. The customer is
 using CloudStack 4.6.
 
 
 I'd like to contribute the plug-in to our official repo, but I'm wondering
 if I can open a PR as far back as 4.6 (and, of course, I'd like to have
 this plug-in in all subsequent releases, as well).
 
 
 Thoughts on this?
 
 
 Thanks!
 
 Mike
> 

Re: Release-Management Question about New API Plug-in

[Will Stevens]

That is assuming the RM is willing to do that and forward merge it up to
the latest master.

Technically for 4.9, we supported merging into 4.7 and 4.8 and master.
Once 4.9 is release, the officially supported branches will be 4.8, 4.9 and
master.  Rajani is correct that ideally new features will go into master
and only bug fixes will be added to the older branches, but with an
increased release pace, this may add unintended work on PR authors if their
features don't get into the upcoming release.

Hope that helps...

*Will STEVENS*
Lead Developer

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

On Thu, Jun 16, 2016 at 10:46 PM, John Burwell 
wrote:

> Mike,
>
> Anyone can submit a PR against any branch.  If they can get 2 LGTMs for
> it, it will be merged.  After that, you could create a new 4.6 RC, and open
> a vote for it.  While there is nothing procedurally that prevents someone
> from following this process, it is unlikely that the release vote would
> muster interest to pass.
>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
> On Jun 16, 2016, at 2:29 AM, Tutkowski, Mike 
> wrote:
> >
> > OK - I can always deliver the plug-in for 4.6 directly to my customers
> and first check it into the CloudStack repo maybe in 4.10 or later.
> >
> >> On Jun 16, 2016, at 12:21 AM, Rajani Karuturi 
> wrote:
> >>
> >> "We will only fix bugs in this release branch, no back porting of new
> >> features" -
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
> >>
> >> I would prefer a PR on master for 4.9+
> >>
> >>
> >>
> >> ~Rajani
> >>
> >> On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike <
> mike.tutkow...@netapp.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> This is mainly a release-management question, but - of course - anyone
> who
> >>> knows, please feel free to comment.
> >>>
> >>>
> >>> I have been developing a new API plug-in for a customer. The customer
> is
> >>> using CloudStack 4.6.
> >>>
> >>>
> >>> I'd like to contribute the plug-in to our official repo, but I'm
> wondering
> >>> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
> >>> this plug-in in all subsequent releases, as well).
> >>>
> >>>
> >>> Thoughts on this?
> >>>
> >>>
> >>> Thanks!
> >>>
> >>> Mike
> >>>
>
>

Re: 4.9+ release

[Rajani Karuturi]

On Fri, Jun 17, 2016 at 8:20 AM, John Burwell 
wrote:

> Rajani,
>
> By the rules of semantic versioning (which we follow), incrementing the
> major version should only occur if there there is a change that breaks
> backwards compatibility of the API, removes support for a integrated
> component, or otherwise reduces/removes existing functionality.


my question was to check if anyone is working on such a change. Based on
the replies, I think its a NO.


> Assuming we targeting late August 2016 for the next release, it is a bit
> short notice to introduce such changes.  Therefore, the next release should
> be 4.10.
>
My opinions is, its never too late. Since no one is working on any such
feature, we need not get into that discussion now.

>
> I have opened a discussion to determine if/when we should have a 5.0.0
> release in order to provide developers and users with sufficient notice for
> such significant changes.
>
The challenge is to find out who is doing the hard work for such features.

Thanks,
Rajani


>
> Thanks,
> -John
>
> >
> john.burw...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>
>
> On Jun 15, 2016, at 5:31 AM, Rajani Karuturi  wrote:
> >
> > I like this discussion. But, my original question was not about what
> should
> > the next release number be?
> >
> > i was checking if anyone working on anything big and hence want the next
> > release to be 5.0?
> >
> > ~Rajani
> >
> > 
> >
> >
> > On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland  >
> > wrote:
> >
> >> maybe I should have answered here instead of the other thread :S
> >>
> >> I am all with John on this. I can not judge the dates but the overall
> ideas
> >> are spot on.
> >>
> >> I now see the API weren't mentioned in this thread I think they should.
> >>
> >> On Wed, Jun 15, 2016 at 1:53 AM, ilya 
> >> wrote:
> >>
> >>> I agree and support John's comments below.
> >>>
> >>> Regards
> >>> ilya
> >>>
> >>> On 6/14/16 2:44 PM, John Burwell wrote:
>  All,
> 
>  Completely agree with Daan.  Per semantic versioning, a major revision
> >>> increase must introduce a backwards incompatible change in the public
> >> API,
> >>> removal of one of more supported devices, reduction in the list of
> >>> supported distributions.  I agree that when we require Java8+, drop
> >> Ubuntu
> >>> 12.04 support, drop support for an old hypervisor version, etc,  we
> will
> >>> need to increment the major revision to reflect the fact that the
> release
> >>> is not backwards compatible.
> 
>  For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
> >>> on either Java7 or Java8.  In particular, producing an LTS release that
> >>> only supports a JVM that has been unsupported for nearly 18 months
> would
> >>> make it DOA in many shops.
> 
>  It seems like it would make sense to have a 5.0.0 release that removed
> >>> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
> >>> Java7, CentOS 5, etc), as well as, internal improvements (e.g.
> simplified
> >>> configuration).  The focus of this release would be to reduce the
> >> footprint
> >>> of codebase, as well as, make a set of backwards incompatible changes
> >> that
> >>> further decouples plugins from core.  We would then plan for a 6.0.0 in
> >>> 4Q2017 to introduce further architectural changes and API revisions.
> The
> >>> advantage to this approach is that it breaks up the large refactorings
> >> and
> >>> architectural design changes — allowing us to gain velocity by removing
> >>> legacy components, reducing the risk of these changes, and providing
> user
> >>> benefit earlier.  Based on the release plan I previously proposed we
> have
> >>> the following releases remaining in 2016 and in early 2017:
> 
>  * 4.10 releasing on or about 28 August 2016
>  * 4.11 releasing on or about 23 October 2016
>  * 4.12 releasing on or about 18 December 2016
>  * 4.13 release on or about 5 February 2017
> 
>  4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
> >> release
> >>> described above.  It would give us sometime to plan and gain consensus
> >>> around the changes in both the user and dev communities.  It would also
> >>> allow the second LTS release to be based on 5.0.0 — allowing both
> release
> >>> cycles to take advantage of the reduced support requirements and Java8
> >>> language features. Based on this proposal, the releases above would
> >> change
> >>> to the following:
> 
>  * 4.10 releasing on or about 28 August 2016
>  * 4.11 releasing on or about 23 October 2016
>  * 5.0.0 releasing on or about 18 December 2016
>  * 5.1.0 release on or about 5 February 2017
> 
>  I am in the process of moving my proposal into the wiki.  If this
> >>> approach is acceptable, I will reflect it there, and open a thread to
> >>> discuss 5.0.0.
> 
>  Thanks,
>  -John
> 
> >

Re: ApiXmlDocReader.java - Used by anyone???

[Rajani Karuturi]

I dont know how but, I think marvin depends on it to generate command
objects for the apis.

Here is a doc from CodeGenerator.py

Apache CloudStack- marvin python classes can be generated from the json
returned by API discovery or from the xml spec of commands generated by
the ApiDocWriter. This class provides helper methods for these uses.



~Rajani

On Fri, Jun 17, 2016 at 3:37 AM, Will Stevens 
wrote:

> Hey All,
> Does anyone know if this class [1] is being used anywhere (other than by
> Pierre-Luc to create the release notes [2]).
>
> The reason I ask is because I know Pierre-Luc spends a lot of time every
> release manually changing the formatting from what is [3] output to RST
> format so it can be displayed.
>
> I have already built a parser to generate the 'fixed issues' piece [5] of
> the release notes (will be open sourced soon).
>
> If PL is the only person using this class I will either:
> a) Modify the class to output the details in an RST format so the output
> can be directly pasted into the release notes.
> b) Modify the class to output structured JSON so the data can be easily
> consumed by parsers.  I would then write a small script to parse the JSON
> and output the RST format for the RN.
>
> I would lean towards b) so the Java code would not have to be modified if
> we changed the format of the docs to another format (like Markdown for
> example).
>
> Worst case scenario, I will just write a parser that takes that meh layout
> and output a RST table for the RNs.
>
> Thanks,
>
> Will
>
> [1]
>
> https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/api/doc/ApiXmlDocReader.java
> [2] https://github.com/pdion891/acs-api-commands
> [3]
>
> https://github.com/pdion891/acs-api-commands/blob/master/diff-470-480/diff.txt
> [4]
>
> https://raw.githubusercontent.com/apache/cloudstack-docs-rn/master/source/api-changes.rst
> [5]
>
> https://objects-east.cloud.ca/v1/5ef827605f884961b94881e928e7a250/swill/rn.png
>