RE: CloudStack LTS EOL date?
I'm pleased that we got there. I'll update the wiki accordingly Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Rene Moser [mailto:m...@renemoser.net] Sent: 27 November 2017 18:05 To: dev@cloudstack.apache.org Subject: Re: CloudStack LTS EOL date? Hi Paul On 11/27/2017 06:27 PM, Paul Angus wrote: > Hi Rene, > > note: I'm only stating what the original intent was when LTS was originally > proposed. I'm not trying to dictate what we must do now or in the future. > > ... The LTS scheme was designed when there was a release coming out every one > or two months, and these releases were effectively only receiving fixes for a > month or two. > > To answer your questions (taking into account the note above)- 4.9 was an LTS > version, which meant that there would be a 4.9.1, 4.9.2..4.9.6... for a > period of 2 years. > 4.9.x was the latest 'version' at the beginning of 2017. > Unfortunately, it was also the latest version in the middle of 2017. So in > mid-2017 we took the latest version (4.9 again) and said that we would > continue backporting fix for that version for 2 years from mid 2017. This is absolutely fine, we are on the same page. > Some variant of your proposal "6 months after next LTS release (minimum 18 > months)." would also work. > I think something like "supported for a minimum of 6 months after next LTS > release or a total period of 24 months, whichever is greater" suits what you > are saying? That would definitely make things more clear to users. Regards René
Re: CloudStack LTS EOL date?
"supported for a minimum of 6 months after next LTS release or a total period of 24 months, whichever is greater" Do you mean: "supported for a minimum of 6 months after next LTS release or minimum of 24 months after initial release, whichever is greater" The web site should be updated to reflect the current policy and kept up to date as the policy changes. New users do not have the benefit of all of this discussion so they go by what the web site says and make their judgments about stability and support based on what it says. It will be unusual for users to object to an extension of LTS if the initial commitment needs altering. Ron On 27/11/2017 12:27 PM, Paul Angus wrote: Hi Rene, note: I'm only stating what the original intent was when LTS was originally proposed. I'm not trying to dictate what we must do now or in the future. ... The LTS scheme was designed when there was a release coming out every one or two months, and these releases were effectively only receiving fixes for a month or two. To answer your questions (taking into account the note above)- 4.9 was an LTS version, which meant that there would be a 4.9.1, 4.9.2..4.9.6... for a period of 2 years. 4.9.x was the latest 'version' at the beginning of 2017. Unfortunately, it was also the latest version in the middle of 2017. So in mid-2017 we took the latest version (4.9 again) and said that we would continue backporting fix for that version for 2 years from mid 2017. Some variant of your proposal "6 months after next LTS release (minimum 18 months)." would also work. I think something like "supported for a minimum of 6 months after next LTS release or a total period of 24 months, whichever is greater" suits what you are saying? Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Rene Moser [mailto:m...@renemoser.net] Sent: 27 November 2017 09:52 To: dev@cloudstack.apache.org Subject: Re: CloudStack LTS EOL date? Hi Paul On 11/22/2017 05:39 PM, Paul Angus wrote: HI All, The current LTS cycle is based on having an LTS release twice a year (at the time of design, ACS releases were coming out monthly). So, twice a year (nominally, January and July) we take the then current version of CloudStack, and declare that an LTS version, for which would we would then backport fixes for a period of up to 2 years. Thereby giving end users a version of CloudStack which would receive bug fixes for an extended period. This year however, the current version in January was the same as the current version in July, therefore 4.9 became the 'July' LTS as well as January LTS and therefore 4.9 will be supported until summer 2019 (hence the 4.9.3 release) I and a number of my colleagues remain committed to continue to support 'LTS' releases in this fashion (there just wasn't anything really to 'announce' in July), which may be why people think that nothing is happening. With 2 LTS releases a year (6 months apart), 'next LTS +6 months' would only be 12 months from release. Which I think is really too short a period for the majority of enterprises. Although we haven't written it this way, the current scheme gives a EOL of 'next LTS + 18 months'. So, I'm in favour of leaving things as they are. The wiki page looks like it needs updating to be clearer (I'm happy to do that) Does the release of an LTS include minor releases, is a release of 4.9.x an "LTS" release? Or is a 4.x an LTS release. My understanding was, that 4.x are new "releases". My concerns are, we can not guarantee 2 LTS releases per year, can we? Predicting the future is hard and we should have a more "relative" sentence how long we support it. In my opition, there should be an overlapping of support time for at east 6 monnths (that is why I added +6 months). What would it cost to change the support time of an LTS like: "6 months after next LTS release (minimum 18 months)." Regards René -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: CloudStack LTS EOL date?
Hi Paul On 11/27/2017 06:27 PM, Paul Angus wrote: > Hi Rene, > > note: I'm only stating what the original intent was when LTS was originally > proposed. I'm not trying to dictate what we must do now or in the future. > > ... The LTS scheme was designed when there was a release coming out every one > or two months, and these releases were effectively only receiving fixes for a > month or two. > > To answer your questions (taking into account the note above)- 4.9 was an LTS > version, which meant that there would be a 4.9.1, 4.9.2..4.9.6... for a > period of 2 years. > 4.9.x was the latest 'version' at the beginning of 2017. > Unfortunately, it was also the latest version in the middle of 2017. So in > mid-2017 we took the latest version (4.9 again) and said that we would > continue backporting fix for that version for 2 years from mid 2017. This is absolutely fine, we are on the same page. > Some variant of your proposal "6 months after next LTS release (minimum 18 > months)." would also work. > I think something like "supported for a minimum of 6 months after next LTS > release or a total period of 24 months, whichever is greater" suits what you > are saying? That would definitely make things more clear to users. Regards René
RE: CloudStack LTS EOL date?
Hi Rene, note: I'm only stating what the original intent was when LTS was originally proposed. I'm not trying to dictate what we must do now or in the future. ... The LTS scheme was designed when there was a release coming out every one or two months, and these releases were effectively only receiving fixes for a month or two. To answer your questions (taking into account the note above)- 4.9 was an LTS version, which meant that there would be a 4.9.1, 4.9.2..4.9.6... for a period of 2 years. 4.9.x was the latest 'version' at the beginning of 2017. Unfortunately, it was also the latest version in the middle of 2017. So in mid-2017 we took the latest version (4.9 again) and said that we would continue backporting fix for that version for 2 years from mid 2017. Some variant of your proposal "6 months after next LTS release (minimum 18 months)." would also work. I think something like "supported for a minimum of 6 months after next LTS release or a total period of 24 months, whichever is greater" suits what you are saying? Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Rene Moser [mailto:m...@renemoser.net] Sent: 27 November 2017 09:52 To: dev@cloudstack.apache.org Subject: Re: CloudStack LTS EOL date? Hi Paul On 11/22/2017 05:39 PM, Paul Angus wrote: > HI All, > > The current LTS cycle is based on having an LTS release twice a year (at the > time of design, ACS releases were coming out monthly). > > So, twice a year (nominally, January and July) we take the then current > version of CloudStack, and declare that an LTS version, for which would we > would then backport fixes for a period of up to 2 years. Thereby giving end > users a version of CloudStack which would receive bug fixes for an extended > period. > > This year however, the current version in January was the same as the > current version in July, therefore 4.9 became the 'July' LTS as well > as January LTS and therefore 4.9 will be supported until summer 2019 > (hence the 4.9.3 release) > > I and a number of my colleagues remain committed to continue to support 'LTS' > releases in this fashion (there just wasn't anything really to 'announce' in > July), which may be why people think that nothing is happening. > > With 2 LTS releases a year (6 months apart), 'next LTS +6 months' would only > be 12 months from release. Which I think is really too short a period for > the majority of enterprises. Although we haven't written it this way, the > current scheme gives a EOL of 'next LTS + 18 months'. > > So, I'm in favour of leaving things as they are. The wiki page looks like > it needs updating to be clearer (I'm happy to do that) Does the release of an LTS include minor releases, is a release of 4.9.x an "LTS" release? Or is a 4.x an LTS release. My understanding was, that 4.x are new "releases". My concerns are, we can not guarantee 2 LTS releases per year, can we? Predicting the future is hard and we should have a more "relative" sentence how long we support it. In my opition, there should be an overlapping of support time for at east 6 monnths (that is why I added +6 months). What would it cost to change the support time of an LTS like: "6 months after next LTS release (minimum 18 months)." Regards René
Where is the vm root password published?
Hello, I know that the vm root password is temporarily stored somewhere in the system. I need to find it out for accessing the console of some instances created programmatically. Where do I look? Cheers, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Issue with Opensaml and Self-Signed Certificates
Hi, When I use Opensaml on 4.10 with the self-signed certificates I get the following error, though the configuration for the opensaml and ssl is proper. It works fine if I debug and supply the password of the keystore in KeyStoreBuilder class, which is in not-yet-commons-ssl.jar. Has anyone faced this issue, I tried with different versions of opensaml but nothing worked. Found similar issue on SO at [1], but none of them helped. java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. at sun.security.util.DerInputStream.getLength(DerInputStream.java:561) at sun.security.util.DerValue.init(DerValue.java:365) at sun.security.util.DerValue.(DerValue.java:320) at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914) at java.security.KeyStore.load(KeyStore.java:1445) at org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450) at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:416) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:207) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:160) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:165) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:170) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:83) at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:359) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:201) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:176) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:150) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.addIdpToMap(SAML2AuthManagerImpl.java:293) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.discoverAndAddIdp(SAML2AuthManagerImpl.java:323) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.access$200(SAML2AuthManagerImpl.java:92) at org.apache.cloudstack.saml.SAML2AuthManagerImpl$MetadataRefreshTask.run(SAML2AuthManagerImpl.java:349) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. at sun.security.util.DerInputStream.getLength(DerInputStream.java:561) at sun.security.util.DerValue.init(DerValue.java:365) at sun.security.util.DerValue.(DerValue.java:320) at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914) at java.security.KeyStore.load(KeyStore.java:1445) at org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450) at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:416) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:207) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:160) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:165) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:170) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:83) at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:359) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:201) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:176) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:150) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.addIdpToMap(SAML2AuthManagerImpl.java:293) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.discoverAndAddIdp(SAML2AuthManagerImpl.java:323) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.access$200(SAML2AuthManagerImpl.java:92) at org.apache.cloudstack.saml.SAML2AuthManagerImpl$MetadataRefreshTask.run(SAML2AuthManagerImpl.java:349) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) java.security.KeyStoreException: failed to extract any certificates or private keys - maybe bad password? at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:436) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:207) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:160) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:165) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:170) at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:83) at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:359) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:201) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:176) at org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:150) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.addIdpToMap(SAML2AuthManagerImpl.java:293) at org.apache.cloudstack.saml.SAML2AuthManagerImpl.discoverAndAddIdp(SAML2AuthManagerImpl.java:323) at
Re: CloudStack LTS EOL date?
Hi Paul On 11/22/2017 05:39 PM, Paul Angus wrote: > HI All, > > The current LTS cycle is based on having an LTS release twice a year (at the > time of design, ACS releases were coming out monthly). > > So, twice a year (nominally, January and July) we take the then current > version of CloudStack, and declare that an LTS version, for which would we > would then backport fixes for a period of up to 2 years. Thereby giving end > users a version of CloudStack which would receive bug fixes for an extended > period. > > This year however, the current version in January was the same as the current > version in July, therefore 4.9 became the 'July' LTS as well as January LTS > and therefore 4.9 will be supported until summer 2019 (hence the 4.9.3 > release) > > I and a number of my colleagues remain committed to continue to support 'LTS' > releases in this fashion (there just wasn't anything really to 'announce' in > July), which may be why people think that nothing is happening. > > With 2 LTS releases a year (6 months apart), 'next LTS +6 months' would only > be 12 months from release. Which I think is really too short a period for > the majority of enterprises. Although we haven't written it this way, the > current scheme gives a EOL of 'next LTS + 18 months'. > > So, I'm in favour of leaving things as they are. The wiki page looks like > it needs updating to be clearer (I'm happy to do that) Does the release of an LTS include minor releases, is a release of 4.9.x an "LTS" release? Or is a 4.x an LTS release. My understanding was, that 4.x are new "releases". My concerns are, we can not guarantee 2 LTS releases per year, can we? Predicting the future is hard and we should have a more "relative" sentence how long we support it. In my opition, there should be an overlapping of support time for at east 6 monnths (that is why I added +6 months). What would it cost to change the support time of an LTS like: "6 months after next LTS release (minimum 18 months)." Regards René
