You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Remi Bergsma <re...@remi.nl> on 2015/06/01 06:41:40 UTC
Re: [VOTE] release candidate 4.4.4
Hi Milamber,
I think it is new in 4.4.4, backported from master but Daan can confirm.
4.4.1 refers to the system vm template version and not per se to CloudStack 4.4.1. There is no reason to upgrade it so it can stay at 4.4.1 again as the upgrade procedure is much easier and faster without upgrading systemvms.
It is a great feature because it allows to upgrade the systemvm template regardless of CloudStack version. Handy when there's a new glibc/shellshock alike issue.
But it should work transparently and not bug users. Will work with Daan today to fix it.
Same could be going on in 4.5 branch, will check that too.
Regards, Remi
Sent from my iPhone
> On 31 May 2015, at 19:50, Milamber <mi...@apache.org> wrote:
>
> Hello Remi,
>
> Ok thanks.
> I execute this SQL request below, and now it's works.
>
>
> INSERT INTO `cloud`.`configuration`(`category`, `instance`, `component`, `name`, `value`, `description`, `default_value`, `updated`, `scope`, `is_dynamic`) VALUES('Advanced', 'DEFAULT', 'management-server', 'minreq.sysvmtemplate.version', '4.4.1', 'The minimal version for the systemvm', '4.4.1', NULL, NULL, 0);
>
>
> If I understand well, this "bug"/missing entry in database exists since 4.4.2?
>
>
> @Daan, Probably it would be better to fix this before the 4.4.4 release?
>
>
> Milamber
>
>
>> On 31/05/2015 17:07, Remi Bergsma wrote:
>> Hi Milamber,
>>
>> It is a global setting, although it appears not to be present in the cloud.configuration table by default (so you cannot find it). If you insert it, it works.
>>
>> I also played with the upgrade and did insert the setting, since at work we had changed the minimal version to a non standard 4.4.2 during a patch round. So I knew it wouldn't work out of the box for me.
>>
>> @daan: We might want to set the setting by default to 4.4.1 (in db) so upgrades work out-of-the-box and you can control it from the global settings pane. This may also need some attention in the docs. What do you think?
>>
>> Regards, Remi
>>
>>> On 31 May 2015, at 17:36, Milamber <mi...@apache.org> wrote:
>>>
>>> Hello Rohit,
>>>
>>>> On 31/05/2015 11:57, Rohit Yadav wrote:
>>>> +1 (binding)
>>>>
>>>> Here’s a test repository you can use for convenience built out of this tag/RC:
>>>> http://packages.shapeblue.com/cloudstack/testing/
>>>>
>>>> Deployed Basic Zone with/without SG, tested vm lifecycle.
>>>>
>>>> The VM deployment failed for me as minreq.sysvmtemplate.version global setting was set to 4.4.4, and I was using 4.4.1 template.
>>> Me too, all my tests failed because VR must be updated. I've past some hours to find why (test with different systemvmtemplate file, re-install, etc.)
>>>
>>>> After setting this to 4.4.1, all normal vm lifecycle worked for me.
>>> Where ? directly in ./engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java ?
>>>
>>> I don't find the minreq.sysvmtemplate.version key in the Global Settings view.
>>>
>>> Milamber
>>>
>>>
>>>> We need to document this in the docs, the systemvmtemplate build for 4.4 has been failing which might need to be fixed if we want 4.4.4 template:http://jenkins.buildacloud.org/view/4.4/
>>>>
>>>>> On 29-May-2015, at 8:10 pm, Daan Hoogland<da...@gmail.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I've created a 4.4.4 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/
>>>>> <https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323>4.4-RC20150529T2004
>>>>> Commit: 7d2320cd1d27842fae73c7f43ef422da354f9999
>>>>>
>>>>> List of changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>>>>>
>>>>> Source release (checksums and signatures are available at the same
>>>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>>>>>
>>>>> PGP release keys (signed using
>>>>> AA4736F3):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)
>>>> Regards,
>>>> Rohit Yadav
>>>> Software Architect, ShapeBlue
>>>> M. +91 88 262 30892 |rohit.yadav@shapeblue.com
>>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>>
>>>>
>>>>
>>>> Find out more about ShapeBlue and our range of CloudStack related services
>>>>
>>>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>>> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>>>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>>>> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>>>>
>>>> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
>
Re: [VOTE] release candidate 4.4.4
Posted by Milamber <mi...@apache.org>.
On 01/06/2015 06:40, Rohit Yadav wrote:
> Hi,
>
> Looks like MinVRVersionCK (minreq.sysvmtemplate.version) setting is a ConfigKey, I’m not sure about 4.4 but on 4.5/master it creates an entry in configuration table if unavailable.
On my fresh CS 4.5.1 installation, the minreq.sysvmtemplate.version key
doesn't exists in the database. (My CS 4.5.1 works fine)
> If upgrading from 4.4.2/4.4.1 to 4.4.4 does not create this we can either add it in the upgrade path or add in the release/upgrade notes. I think the default version of MinVRVersionCK for 4.4 should be 4.4.0 to use any 4.4 template.
Yes agree.
>
> I guess since it’s configuration related issue IMO there is no need to call off the RC voting, unless of course we find a regression or blocker.
>
>> On 01-Jun-2015, at 6:41 am, Remi Bergsma <re...@remi.nl> wrote:
>>
>> Hi Milamber,
>>
>> I think it is new in 4.4.4, backported from master but Daan can confirm.
>>
>> 4.4.1 refers to the system vm template version and not per se to CloudStack 4.4.1. There is no reason to upgrade it so it can stay at 4.4.1 again as the upgrade procedure is much easier and faster without upgrading systemvms.
>>
>> It is a great feature because it allows to upgrade the systemvm template regardless of CloudStack version. Handy when there's a new glibc/shellshock alike issue.
>>
>> But it should work transparently and not bug users. Will work with Daan today to fix it.
>>
>> Same could be going on in 4.5 branch, will check that too.
>>
>> Regards, Remi
>>
>> Sent from my iPhone
>>
>>> On 31 May 2015, at 19:50, Milamber <mi...@apache.org> wrote:
>>>
>>> Hello Remi,
>>>
>>> Ok thanks.
>>> I execute this SQL request below, and now it's works.
>>>
>>>
>>> INSERT INTO `cloud`.`configuration`(`category`, `instance`, `component`, `name`, `value`, `description`, `default_value`, `updated`, `scope`, `is_dynamic`) VALUES('Advanced', 'DEFAULT', 'management-server', 'minreq.sysvmtemplate.version', '4.4.1', 'The minimal version for the systemvm', '4.4.1', NULL, NULL, 0);
>>>
>>>
>>> If I understand well, this "bug"/missing entry in database exists since 4.4.2?
>>>
>>>
>>> @Daan, Probably it would be better to fix this before the 4.4.4 release?
>>>
>>>
>>> Milamber
>>>
>>>
>>>> On 31/05/2015 17:07, Remi Bergsma wrote:
>>>> Hi Milamber,
>>>>
>>>> It is a global setting, although it appears not to be present in the cloud.configuration table by default (so you cannot find it). If you insert it, it works.
>>>>
>>>> I also played with the upgrade and did insert the setting, since at work we had changed the minimal version to a non standard 4.4.2 during a patch round. So I knew it wouldn't work out of the box for me.
>>>>
>>>> @daan: We might want to set the setting by default to 4.4.1 (in db) so upgrades work out-of-the-box and you can control it from the global settings pane. This may also need some attention in the docs. What do you think?
>>>>
>>>> Regards, Remi
>>>>
>>>>> On 31 May 2015, at 17:36, Milamber <mi...@apache.org> wrote:
>>>>>
>>>>> Hello Rohit,
>>>>>
>>>>>> On 31/05/2015 11:57, Rohit Yadav wrote:
>>>>>> +1 (binding)
>>>>>>
>>>>>> Here’s a test repository you can use for convenience built out of this tag/RC:
>>>>>> http://packages.shapeblue.com/cloudstack/testing/
>>>>>>
>>>>>> Deployed Basic Zone with/without SG, tested vm lifecycle.
>>>>>>
>>>>>> The VM deployment failed for me as minreq.sysvmtemplate.version global setting was set to 4.4.4, and I was using 4.4.1 template.
>>>>> Me too, all my tests failed because VR must be updated. I've past some hours to find why (test with different systemvmtemplate file, re-install, etc.)
>>>>>
>>>>>> After setting this to 4.4.1, all normal vm lifecycle worked for me.
>>>>> Where ? directly in ./engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java ?
>>>>>
>>>>> I don't find the minreq.sysvmtemplate.version key in the Global Settings view.
>>>>>
>>>>> Milamber
>>>>>
>>>>>
>>>>>> We need to document this in the docs, the systemvmtemplate build for 4.4 has been failing which might need to be fixed if we want 4.4.4 template:http://jenkins.buildacloud.org/view/4.4/
>>>>>>
>>>>>>> On 29-May-2015, at 8:10 pm, Daan Hoogland<da...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I've created a 4.4.4 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/
>>>>>>> <https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323>4.4-RC20150529T2004
>>>>>>> Commit: 7d2320cd1d27842fae73c7f43ef422da354f9999
>>>>>>>
>>>>>>> List of changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>>>>>>>
>>>>>>> Source release (checksums and signatures are available at the same
>>>>>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>>>>>>>
>>>>>>> PGP release keys (signed using
>>>>>>> AA4736F3):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)
>>>>>> Regards,
>>>>>> Rohit Yadav
>>>>>> Software Architect, ShapeBlue
>>>>>> M. +91 88 262 30892 |rohit.yadav@shapeblue.com
>>>>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>>>>
>>>>>>
>>>>>>
>>>>>> Find out more about ShapeBlue and our range of CloudStack related services
>>>>>>
>>>>>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>>>>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>>>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>>>>> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>>>>>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>>>>>> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>>>>>>
>>>>>> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [VOTE] release candidate 4.4.4
Posted by Milamber <mi...@apache.org>.
Hello Daan,
No objections. And thanks for the new RC.
Milamber
On 01/06/2015 12:17, Daan Hoogland wrote:
> If no objections I will reset the default to 4.4.1 (the lowest required
> version) include Rafaels pr for kvm/centos packaging and create a new rc.
>
> Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <da...@gmail.com>:
>
>> So we will have to include an update in every release and we will probably
>> forget about that pretty soon.
>>
>> Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
>>
>>> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
>>> for 4.5.x etc. This is also close to what was hard-coded before.
>>>
>>> Regards,
>>> Remi
>>>
>>>
>>> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
>>>
>>>> Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
>>> must
>>>> be an operator decision to set the MinVRVersion if it must be higher. It
>>>> will always be an upgrade matter and any seeded template should be
>>> accepted
>>>> as per the installation notes. Of course the other side of the issue is
>>>> whether a version will work at all. The operator can create a version of
>>>> the template with their own versioning scheme, however. I should be
>>> writing
>>>> all this in another {DISCUSS]-thread.
>>>>
>>>> cancelling the RC to add code for Bruno's requirement.
>>>>
>>>> Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
>>>>
>>>>> Please note: I my case, there isn't an upgrade, I have the issue with
>>>>> 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
>>>>> 4.4-RC20150529T2004)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 01/06/2015 07:22, Erik Weber wrote:
>>>>>> If it means that all upgrades are unable to do VR related tasks (
>>>>> starting
>>>>>> VMs for one.. ), I'd call that regression and redo.
>>>>>> Relying on all our users to do manual fixing just because we don't
>>> want
>>>>> to
>>>>>> call off the RC is bad IMHO.
>>>>>>
>>>>>>
>>>>>
Re: [VOTE] release candidate 4.4.4
Posted by Rafael Fonseca <rs...@gmail.com>.
No prob Daan :)
Like it said, it still needs some testing before merging as is into the
code base.
If you don't care much about that security issue (the risk of a XSS attack
to get your sessionkey, for which the attacker would also need network
access to your server, which he normally wouldn't if you took minimum care
of securing it :) ), this patch restores old behavior to use cookies for
session persistence:
(just did this now and didn't test, but there should be no issues)
(you can also take a backup of cloudStack.js just in case ;) )
cat << 'EOF' > patch.file
*** ui/scripts/cloudStack.js 2015-06-01 15:41:54.986000000 +0200
--- /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
2015-06-01 15:41:51.410000000 +0200
***************
*** 117,131 ****
}
return cookieValue;
};
! unBoxCookieValue('sessionkey');
! // if sessionkey cookie exists use this to set
g_sessionKey
! // and destroy sessionkey cookie
! if ($.cookie('sessionkey')) {
! g_sessionKey = $.cookie('sessionkey');
! $.cookie('sessionkey', null);
! } else {
! g_sessionKey = unBoxCookieValue('JSESSIONID');
! }
g_role = unBoxCookieValue('role');
g_userid = unBoxCookieValue('userid');
g_domainid = unBoxCookieValue('domainid');
--- 117,123 ----
}
return cookieValue;
};
! g_sessionKey = unBoxCookieValue('sessionkey');
g_role = unBoxCookieValue('role');
g_userid = unBoxCookieValue('userid');
g_domainid = unBoxCookieValue('domainid');
***************
*** 234,239 ****
--- 226,234 ----
g_timezone = loginresponse.timezone;
g_userfullname = loginresponse.firstname + ' ' +
loginresponse.lastname;
+ $.cookie('sessionKey', g_sessionKey, {
+ expires: 1
+ });
$.cookie('username', g_username, {
expires: 1
});
EOF
patch /usr/share/cloudstack-management/webapps/client/scripts/cloudStack.js
-i patch.file
On Mon, Jun 1, 2015 at 3:41 PM, Daan Hoogland <da...@gmail.com>
wrote:
> Andrija, Rafael, I took a few minutes to look at it. It doesn't apply even
> after some simple tinkering. Hope you will once forgive me for not taking
> this in the next RC. baking it now
>
> Op ma 1 jun. 2015 om 15:22 schreef Andrija Panic <andrija.panic@gmail.com
> >:
>
> > :) please do - send the patch.
> >
> > Thanks Rafael
> >
> > On 1 June 2015 at 15:16, Rafael Fonseca <rs...@gmail.com> wrote:
> >
> > > Hi Andrija,
> > >
> > > The first fix i had proposed might not have been a problem, besides the
> > > security issue.
> > > I have now updated the PR to fix the security issue, but tests for
> other
> > > authentication methods must be performed before a merge.
> > > I think Rohit is looking into testing the SAML plugin with it, if it's
> > ok i
> > > guess it can be merged, if not, it will still have to be made
> compatible
> > > with those auth plugins.
> > > If you'd like i can give you a small patch to fix session management in
> > > your environment, you can patch in place after installation, so easy to
> > do
> > > :)
> > >
> > >
> > >
> > > On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic <andrija.panic@gmail.com
> >
> > > wrote:
> > >
> > > > Daan, Rafael,
> > > >
> > > > what about Rafael's https://github.com/apache/cloudstack/pull/308 -
> it
> > > > need
> > > > to be reviewsed by security time - fine, but can we merge this, and
> > undo
> > > > alter, if necessary ?
> > > >
> > > > On 1 June 2015 at 14:26, Rafael Fonseca <rs...@gmail.com>
> wrote:
> > > >
> > > > > Hey Daan,
> > > > > I've also created a PR for fixing a couple of deb packaging issues
> > for
> > > > 4.4
> > > > > Have a look here:
> > > > > https://github.com/apache/cloudstack/pull/339
> > > > >
> > > > >
> > > > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Sounds reasonable to me.
> > > > > >
> > > > > > --
> > > > > > Erik
> > > > > >
> > > > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> > > daan.hoogland@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > > > required
> > > > > > > version) include Rafaels pr for kvm/centos packaging and
> create a
> > > new
> > > > > rc.
> > > > > > >
> > > > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > > > daan.hoogland@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > So we will have to include an update in every release and we
> > will
> > > > > > > probably
> > > > > > > > forget about that pretty soon.
> > > > > > > >
> > > > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <
> remi@remi.nl
> > >:
> > > > > > > >
> > > > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x
> > release,
> > > > and
> > > > > > > 4.5.0
> > > > > > > >> for 4.5.x etc. This is also close to what was hard-coded
> > before.
> > > > > > > >>
> > > > > > > >> Regards,
> > > > > > > >> Remi
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> > > daan.hoogland@gmail.com
> > > > >:
> > > > > > > >>
> > > > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for
> > my
> > > > > part,
> > > > > > it
> > > > > > > >> must
> > > > > > > >> > be an operator decision to set the MinVRVersion if it must
> > be
> > > > > > higher.
> > > > > > > It
> > > > > > > >> > will always be an upgrade matter and any seeded template
> > > should
> > > > be
> > > > > > > >> accepted
> > > > > > > >> > as per the installation notes. Of course the other side of
> > the
> > > > > issue
> > > > > > > is
> > > > > > > >> > whether a version will work at all. The operator can
> create
> > a
> > > > > > version
> > > > > > > of
> > > > > > > >> > the template with their own versioning scheme, however. I
> > > should
> > > > > be
> > > > > > > >> writing
> > > > > > > >> > all this in another {DISCUSS]-thread.
> > > > > > > >> >
> > > > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > > > >> >
> > > > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > > > milamber@apache.org
> > > > > >:
> > > > > > > >> >
> > > > > > > >> > >
> > > > > > > >> > > Please note: I my case, there isn't an upgrade, I have
> the
> > > > issue
> > > > > > > with
> > > > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from
> > git
> > > > tag
> > > > > > > >> > > 4.4-RC20150529T2004)
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > > > >> > > > If it means that all upgrades are unable to do VR
> > related
> > > > > tasks
> > > > > > (
> > > > > > > >> > > starting
> > > > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > > > >> > > > Relying on all our users to do manual fixing just
> > because
> > > we
> > > > > > don't
> > > > > > > >> want
> > > > > > > >> > > to
> > > > > > > >> > > > call off the RC is bad IMHO.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Andrija Panić
> > > >
> > >
> >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
Andrija, Rafael, I took a few minutes to look at it. It doesn't apply even
after some simple tinkering. Hope you will once forgive me for not taking
this in the next RC. baking it now
Op ma 1 jun. 2015 om 15:22 schreef Andrija Panic <an...@gmail.com>:
> :) please do - send the patch.
>
> Thanks Rafael
>
> On 1 June 2015 at 15:16, Rafael Fonseca <rs...@gmail.com> wrote:
>
> > Hi Andrija,
> >
> > The first fix i had proposed might not have been a problem, besides the
> > security issue.
> > I have now updated the PR to fix the security issue, but tests for other
> > authentication methods must be performed before a merge.
> > I think Rohit is looking into testing the SAML plugin with it, if it's
> ok i
> > guess it can be merged, if not, it will still have to be made compatible
> > with those auth plugins.
> > If you'd like i can give you a small patch to fix session management in
> > your environment, you can patch in place after installation, so easy to
> do
> > :)
> >
> >
> >
> > On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic <an...@gmail.com>
> > wrote:
> >
> > > Daan, Rafael,
> > >
> > > what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> > > need
> > > to be reviewsed by security time - fine, but can we merge this, and
> undo
> > > alter, if necessary ?
> > >
> > > On 1 June 2015 at 14:26, Rafael Fonseca <rs...@gmail.com> wrote:
> > >
> > > > Hey Daan,
> > > > I've also created a PR for fixing a couple of deb packaging issues
> for
> > > 4.4
> > > > Have a look here:
> > > > https://github.com/apache/cloudstack/pull/339
> > > >
> > > >
> > > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com>
> > wrote:
> > > >
> > > > > Sounds reasonable to me.
> > > > >
> > > > > --
> > > > > Erik
> > > > >
> > > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> > daan.hoogland@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > > required
> > > > > > version) include Rafaels pr for kvm/centos packaging and create a
> > new
> > > > rc.
> > > > > >
> > > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > > daan.hoogland@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > So we will have to include an update in every release and we
> will
> > > > > > probably
> > > > > > > forget about that pretty soon.
> > > > > > >
> > > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <remi@remi.nl
> >:
> > > > > > >
> > > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x
> release,
> > > and
> > > > > > 4.5.0
> > > > > > >> for 4.5.x etc. This is also close to what was hard-coded
> before.
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >> Remi
> > > > > > >>
> > > > > > >>
> > > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> > daan.hoogland@gmail.com
> > > >:
> > > > > > >>
> > > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for
> my
> > > > part,
> > > > > it
> > > > > > >> must
> > > > > > >> > be an operator decision to set the MinVRVersion if it must
> be
> > > > > higher.
> > > > > > It
> > > > > > >> > will always be an upgrade matter and any seeded template
> > should
> > > be
> > > > > > >> accepted
> > > > > > >> > as per the installation notes. Of course the other side of
> the
> > > > issue
> > > > > > is
> > > > > > >> > whether a version will work at all. The operator can create
> a
> > > > > version
> > > > > > of
> > > > > > >> > the template with their own versioning scheme, however. I
> > should
> > > > be
> > > > > > >> writing
> > > > > > >> > all this in another {DISCUSS]-thread.
> > > > > > >> >
> > > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > > >> >
> > > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > > milamber@apache.org
> > > > >:
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> > > issue
> > > > > > with
> > > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from
> git
> > > tag
> > > > > > >> > > 4.4-RC20150529T2004)
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > > >> > > > If it means that all upgrades are unable to do VR
> related
> > > > tasks
> > > > > (
> > > > > > >> > > starting
> > > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > > >> > > > Relying on all our users to do manual fixing just
> because
> > we
> > > > > don't
> > > > > > >> want
> > > > > > >> > > to
> > > > > > >> > > > call off the RC is bad IMHO.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
>
>
>
> --
>
> Andrija Panić
>
Re: [VOTE] release candidate 4.4.4
Posted by Andrija Panic <an...@gmail.com>.
:) please do - send the patch.
Thanks Rafael
On 1 June 2015 at 15:16, Rafael Fonseca <rs...@gmail.com> wrote:
> Hi Andrija,
>
> The first fix i had proposed might not have been a problem, besides the
> security issue.
> I have now updated the PR to fix the security issue, but tests for other
> authentication methods must be performed before a merge.
> I think Rohit is looking into testing the SAML plugin with it, if it's ok i
> guess it can be merged, if not, it will still have to be made compatible
> with those auth plugins.
> If you'd like i can give you a small patch to fix session management in
> your environment, you can patch in place after installation, so easy to do
> :)
>
>
>
> On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic <an...@gmail.com>
> wrote:
>
> > Daan, Rafael,
> >
> > what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> > need
> > to be reviewsed by security time - fine, but can we merge this, and undo
> > alter, if necessary ?
> >
> > On 1 June 2015 at 14:26, Rafael Fonseca <rs...@gmail.com> wrote:
> >
> > > Hey Daan,
> > > I've also created a PR for fixing a couple of deb packaging issues for
> > 4.4
> > > Have a look here:
> > > https://github.com/apache/cloudstack/pull/339
> > >
> > >
> > > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com>
> wrote:
> > >
> > > > Sounds reasonable to me.
> > > >
> > > > --
> > > > Erik
> > > >
> > > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <
> daan.hoogland@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > If no objections I will reset the default to 4.4.1 (the lowest
> > required
> > > > > version) include Rafaels pr for kvm/centos packaging and create a
> new
> > > rc.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > > daan.hoogland@gmail.com
> > > > > >:
> > > > >
> > > > > > So we will have to include an update in every release and we will
> > > > > probably
> > > > > > forget about that pretty soon.
> > > > > >
> > > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > > > > >
> > > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> > and
> > > > > 4.5.0
> > > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > > >>
> > > > > >> Regards,
> > > > > >> Remi
> > > > > >>
> > > > > >>
> > > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <
> daan.hoogland@gmail.com
> > >:
> > > > > >>
> > > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > > part,
> > > > it
> > > > > >> must
> > > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > > higher.
> > > > > It
> > > > > >> > will always be an upgrade matter and any seeded template
> should
> > be
> > > > > >> accepted
> > > > > >> > as per the installation notes. Of course the other side of the
> > > issue
> > > > > is
> > > > > >> > whether a version will work at all. The operator can create a
> > > > version
> > > > > of
> > > > > >> > the template with their own versioning scheme, however. I
> should
> > > be
> > > > > >> writing
> > > > > >> > all this in another {DISCUSS]-thread.
> > > > > >> >
> > > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > > >> >
> > > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> > milamber@apache.org
> > > >:
> > > > > >> >
> > > > > >> > >
> > > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> > issue
> > > > > with
> > > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> > tag
> > > > > >> > > 4.4-RC20150529T2004)
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > > >> > > > If it means that all upgrades are unable to do VR related
> > > tasks
> > > > (
> > > > > >> > > starting
> > > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > > >> > > > Relying on all our users to do manual fixing just because
> we
> > > > don't
> > > > > >> want
> > > > > >> > > to
> > > > > >> > > > call off the RC is bad IMHO.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
--
Andrija Panić
Re: [VOTE] release candidate 4.4.4
Posted by Rafael Fonseca <rs...@gmail.com>.
Hi Andrija,
The first fix i had proposed might not have been a problem, besides the
security issue.
I have now updated the PR to fix the security issue, but tests for other
authentication methods must be performed before a merge.
I think Rohit is looking into testing the SAML plugin with it, if it's ok i
guess it can be merged, if not, it will still have to be made compatible
with those auth plugins.
If you'd like i can give you a small patch to fix session management in
your environment, you can patch in place after installation, so easy to do
:)
On Mon, Jun 1, 2015 at 2:34 PM, Andrija Panic <an...@gmail.com>
wrote:
> Daan, Rafael,
>
> what about Rafael's https://github.com/apache/cloudstack/pull/308 - it
> need
> to be reviewsed by security time - fine, but can we merge this, and undo
> alter, if necessary ?
>
> On 1 June 2015 at 14:26, Rafael Fonseca <rs...@gmail.com> wrote:
>
> > Hey Daan,
> > I've also created a PR for fixing a couple of deb packaging issues for
> 4.4
> > Have a look here:
> > https://github.com/apache/cloudstack/pull/339
> >
> >
> > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com> wrote:
> >
> > > Sounds reasonable to me.
> > >
> > > --
> > > Erik
> > >
> > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <daan.hoogland@gmail.com
> >
> > > wrote:
> > >
> > > > If no objections I will reset the default to 4.4.1 (the lowest
> required
> > > > version) include Rafaels pr for kvm/centos packaging and create a new
> > rc.
> > > >
> > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > daan.hoogland@gmail.com
> > > > >:
> > > >
> > > > > So we will have to include an update in every release and we will
> > > > probably
> > > > > forget about that pretty soon.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > > > >
> > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> and
> > > > 4.5.0
> > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > >>
> > > > >> Regards,
> > > > >> Remi
> > > > >>
> > > > >>
> > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <daan.hoogland@gmail.com
> >:
> > > > >>
> > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > part,
> > > it
> > > > >> must
> > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > higher.
> > > > It
> > > > >> > will always be an upgrade matter and any seeded template should
> be
> > > > >> accepted
> > > > >> > as per the installation notes. Of course the other side of the
> > issue
> > > > is
> > > > >> > whether a version will work at all. The operator can create a
> > > version
> > > > of
> > > > >> > the template with their own versioning scheme, however. I should
> > be
> > > > >> writing
> > > > >> > all this in another {DISCUSS]-thread.
> > > > >> >
> > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > >> >
> > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> milamber@apache.org
> > >:
> > > > >> >
> > > > >> > >
> > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> issue
> > > > with
> > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> tag
> > > > >> > > 4.4-RC20150529T2004)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > >> > > > If it means that all upgrades are unable to do VR related
> > tasks
> > > (
> > > > >> > > starting
> > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > >> > > > Relying on all our users to do manual fixing just because we
> > > don't
> > > > >> want
> > > > >> > > to
> > > > >> > > > call off the RC is bad IMHO.
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
>
>
> --
>
> Andrija Panić
>
Re: [VOTE] release candidate 4.4.4
Posted by Andrija Panic <an...@gmail.com>.
Daan, Rafael,
what about Rafael's https://github.com/apache/cloudstack/pull/308 - it need
to be reviewsed by security time - fine, but can we merge this, and undo
alter, if necessary ?
On 1 June 2015 at 14:26, Rafael Fonseca <rs...@gmail.com> wrote:
> Hey Daan,
> I've also created a PR for fixing a couple of deb packaging issues for 4.4
> Have a look here:
> https://github.com/apache/cloudstack/pull/339
>
>
> On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com> wrote:
>
> > Sounds reasonable to me.
> >
> > --
> > Erik
> >
> > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <da...@gmail.com>
> > wrote:
> >
> > > If no objections I will reset the default to 4.4.1 (the lowest required
> > > version) include Rafaels pr for kvm/centos packaging and create a new
> rc.
> > >
> > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > daan.hoogland@gmail.com
> > > >:
> > >
> > > > So we will have to include an update in every release and we will
> > > probably
> > > > forget about that pretty soon.
> > > >
> > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > > >
> > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > > 4.5.0
> > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > >>
> > > >> Regards,
> > > >> Remi
> > > >>
> > > >>
> > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
> > > >>
> > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> part,
> > it
> > > >> must
> > > >> > be an operator decision to set the MinVRVersion if it must be
> > higher.
> > > It
> > > >> > will always be an upgrade matter and any seeded template should be
> > > >> accepted
> > > >> > as per the installation notes. Of course the other side of the
> issue
> > > is
> > > >> > whether a version will work at all. The operator can create a
> > version
> > > of
> > > >> > the template with their own versioning scheme, however. I should
> be
> > > >> writing
> > > >> > all this in another {DISCUSS]-thread.
> > > >> >
> > > >> > cancelling the RC to add code for Bruno's requirement.
> > > >> >
> > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <milamber@apache.org
> >:
> > > >> >
> > > >> > >
> > > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > > with
> > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > > >> > > 4.4-RC20150529T2004)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > >> > > > If it means that all upgrades are unable to do VR related
> tasks
> > (
> > > >> > > starting
> > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > >> > > > Relying on all our users to do manual fixing just because we
> > don't
> > > >> want
> > > >> > > to
> > > >> > > > call off the RC is bad IMHO.
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
--
Andrija Panić
Re: [VOTE] release candidate 4.4.4
Posted by Rafael Fonseca <rs...@gmail.com>.
This will fix the deb tests on jenkins permanently :)
The packaging always needed a manual update in deb/changelog after a change
in pom.xml version. If this step was forgotten or skipped, it would break.
Fixed for now and forever hopefully :)
On Mon, Jun 1, 2015 at 3:07 PM, Daan Hoogland <da...@gmail.com>
wrote:
> Op ma 1 jun. 2015 om 14:37 schreef Erik Weber <te...@gmail.com>:
>
> > Do we have travis jobs to test packaging?
> >
> No, not in travis. in jenkins for rpm, yes. for deb, I think these are
> broken for a while now.
>
>
> >
> > --
> > Erik
> >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
Op ma 1 jun. 2015 om 14:37 schreef Erik Weber <te...@gmail.com>:
> Do we have travis jobs to test packaging?
>
No, not in travis. in jenkins for rpm, yes. for deb, I think these are
broken for a while now.
>
> --
> Erik
>
>
Re: [VOTE] release candidate 4.4.4
Posted by Erik Weber <te...@gmail.com>.
Do we have travis jobs to test packaging?
--
Erik
On Mon, Jun 1, 2015 at 2:32 PM, Daan Hoogland <da...@gmail.com>
wrote:
> I noticed, will look at travis and merge
>
> Op ma 1 jun. 2015 om 14:27 schreef Rafael Fonseca <rs...@gmail.com>:
>
> > Hey Daan,
> > I've also created a PR for fixing a couple of deb packaging issues for
> 4.4
> > Have a look here:
> > https://github.com/apache/cloudstack/pull/339
> >
> >
> > On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com> wrote:
> >
> > > Sounds reasonable to me.
> > >
> > > --
> > > Erik
> > >
> > > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <daan.hoogland@gmail.com
> >
> > > wrote:
> > >
> > > > If no objections I will reset the default to 4.4.1 (the lowest
> required
> > > > version) include Rafaels pr for kvm/centos packaging and create a new
> > rc.
> > > >
> > > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > > daan.hoogland@gmail.com
> > > > >:
> > > >
> > > > > So we will have to include an update in every release and we will
> > > > probably
> > > > > forget about that pretty soon.
> > > > >
> > > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > > > >
> > > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release,
> and
> > > > 4.5.0
> > > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > > >>
> > > > >> Regards,
> > > > >> Remi
> > > > >>
> > > > >>
> > > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <daan.hoogland@gmail.com
> >:
> > > > >>
> > > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> > part,
> > > it
> > > > >> must
> > > > >> > be an operator decision to set the MinVRVersion if it must be
> > > higher.
> > > > It
> > > > >> > will always be an upgrade matter and any seeded template should
> be
> > > > >> accepted
> > > > >> > as per the installation notes. Of course the other side of the
> > issue
> > > > is
> > > > >> > whether a version will work at all. The operator can create a
> > > version
> > > > of
> > > > >> > the template with their own versioning scheme, however. I should
> > be
> > > > >> writing
> > > > >> > all this in another {DISCUSS]-thread.
> > > > >> >
> > > > >> > cancelling the RC to add code for Bruno's requirement.
> > > > >> >
> > > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <
> milamber@apache.org
> > >:
> > > > >> >
> > > > >> > >
> > > > >> > > Please note: I my case, there isn't an upgrade, I have the
> issue
> > > > with
> > > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git
> tag
> > > > >> > > 4.4-RC20150529T2004)
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > >> > > > If it means that all upgrades are unable to do VR related
> > tasks
> > > (
> > > > >> > > starting
> > > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > > >> > > > Relying on all our users to do manual fixing just because we
> > > don't
> > > > >> want
> > > > >> > > to
> > > > >> > > > call off the RC is bad IMHO.
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
I noticed, will look at travis and merge
Op ma 1 jun. 2015 om 14:27 schreef Rafael Fonseca <rs...@gmail.com>:
> Hey Daan,
> I've also created a PR for fixing a couple of deb packaging issues for 4.4
> Have a look here:
> https://github.com/apache/cloudstack/pull/339
>
>
> On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com> wrote:
>
> > Sounds reasonable to me.
> >
> > --
> > Erik
> >
> > On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <da...@gmail.com>
> > wrote:
> >
> > > If no objections I will reset the default to 4.4.1 (the lowest required
> > > version) include Rafaels pr for kvm/centos packaging and create a new
> rc.
> > >
> > > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> > daan.hoogland@gmail.com
> > > >:
> > >
> > > > So we will have to include an update in every release and we will
> > > probably
> > > > forget about that pretty soon.
> > > >
> > > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > > >
> > > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > > 4.5.0
> > > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > > >>
> > > >> Regards,
> > > >> Remi
> > > >>
> > > >>
> > > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
> > > >>
> > > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my
> part,
> > it
> > > >> must
> > > >> > be an operator decision to set the MinVRVersion if it must be
> > higher.
> > > It
> > > >> > will always be an upgrade matter and any seeded template should be
> > > >> accepted
> > > >> > as per the installation notes. Of course the other side of the
> issue
> > > is
> > > >> > whether a version will work at all. The operator can create a
> > version
> > > of
> > > >> > the template with their own versioning scheme, however. I should
> be
> > > >> writing
> > > >> > all this in another {DISCUSS]-thread.
> > > >> >
> > > >> > cancelling the RC to add code for Bruno's requirement.
> > > >> >
> > > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <milamber@apache.org
> >:
> > > >> >
> > > >> > >
> > > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > > with
> > > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > > >> > > 4.4-RC20150529T2004)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > >> > > > If it means that all upgrades are unable to do VR related
> tasks
> > (
> > > >> > > starting
> > > >> > > > VMs for one.. ), I'd call that regression and redo.
> > > >> > > > Relying on all our users to do manual fixing just because we
> > don't
> > > >> want
> > > >> > > to
> > > >> > > > call off the RC is bad IMHO.
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Rafael Fonseca <rs...@gmail.com>.
Hey Daan,
I've also created a PR for fixing a couple of deb packaging issues for 4.4
Have a look here:
https://github.com/apache/cloudstack/pull/339
On Mon, Jun 1, 2015 at 2:02 PM, Erik Weber <te...@gmail.com> wrote:
> Sounds reasonable to me.
>
> --
> Erik
>
> On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > If no objections I will reset the default to 4.4.1 (the lowest required
> > version) include Rafaels pr for kvm/centos packaging and create a new rc.
> >
> > Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <
> daan.hoogland@gmail.com
> > >:
> >
> > > So we will have to include an update in every release and we will
> > probably
> > > forget about that pretty soon.
> > >
> > > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> > >
> > >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> > 4.5.0
> > >> for 4.5.x etc. This is also close to what was hard-coded before.
> > >>
> > >> Regards,
> > >> Remi
> > >>
> > >>
> > >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
> > >>
> > >> > Guess we'll be making a new rc. The value can be 0.0.0 for my part,
> it
> > >> must
> > >> > be an operator decision to set the MinVRVersion if it must be
> higher.
> > It
> > >> > will always be an upgrade matter and any seeded template should be
> > >> accepted
> > >> > as per the installation notes. Of course the other side of the issue
> > is
> > >> > whether a version will work at all. The operator can create a
> version
> > of
> > >> > the template with their own versioning scheme, however. I should be
> > >> writing
> > >> > all this in another {DISCUSS]-thread.
> > >> >
> > >> > cancelling the RC to add code for Bruno's requirement.
> > >> >
> > >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
> > >> >
> > >> > >
> > >> > > Please note: I my case, there isn't an upgrade, I have the issue
> > with
> > >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > >> > > 4.4-RC20150529T2004)
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On 01/06/2015 07:22, Erik Weber wrote:
> > >> > > > If it means that all upgrades are unable to do VR related tasks
> (
> > >> > > starting
> > >> > > > VMs for one.. ), I'd call that regression and redo.
> > >> > > > Relying on all our users to do manual fixing just because we
> don't
> > >> want
> > >> > > to
> > >> > > > call off the RC is bad IMHO.
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Erik Weber <te...@gmail.com>.
Sounds reasonable to me.
--
Erik
On Mon, Jun 1, 2015 at 1:17 PM, Daan Hoogland <da...@gmail.com>
wrote:
> If no objections I will reset the default to 4.4.1 (the lowest required
> version) include Rafaels pr for kvm/centos packaging and create a new rc.
>
> Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <daan.hoogland@gmail.com
> >:
>
> > So we will have to include an update in every release and we will
> probably
> > forget about that pretty soon.
> >
> > Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> >
> >> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and
> 4.5.0
> >> for 4.5.x etc. This is also close to what was hard-coded before.
> >>
> >> Regards,
> >> Remi
> >>
> >>
> >> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
> >>
> >> > Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
> >> must
> >> > be an operator decision to set the MinVRVersion if it must be higher.
> It
> >> > will always be an upgrade matter and any seeded template should be
> >> accepted
> >> > as per the installation notes. Of course the other side of the issue
> is
> >> > whether a version will work at all. The operator can create a version
> of
> >> > the template with their own versioning scheme, however. I should be
> >> writing
> >> > all this in another {DISCUSS]-thread.
> >> >
> >> > cancelling the RC to add code for Bruno's requirement.
> >> >
> >> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
> >> >
> >> > >
> >> > > Please note: I my case, there isn't an upgrade, I have the issue
> with
> >> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> >> > > 4.4-RC20150529T2004)
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On 01/06/2015 07:22, Erik Weber wrote:
> >> > > > If it means that all upgrades are unable to do VR related tasks (
> >> > > starting
> >> > > > VMs for one.. ), I'd call that regression and redo.
> >> > > > Relying on all our users to do manual fixing just because we don't
> >> want
> >> > > to
> >> > > > call off the RC is bad IMHO.
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
If no objections I will reset the default to 4.4.1 (the lowest required
version) include Rafaels pr for kvm/centos packaging and create a new rc.
Op ma 1 jun. 2015 om 11:54 schreef Daan Hoogland <da...@gmail.com>:
> So we will have to include an update in every release and we will probably
> forget about that pretty soon.
>
> Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
>
>> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
>> for 4.5.x etc. This is also close to what was hard-coded before.
>>
>> Regards,
>> Remi
>>
>>
>> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
>>
>> > Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
>> must
>> > be an operator decision to set the MinVRVersion if it must be higher. It
>> > will always be an upgrade matter and any seeded template should be
>> accepted
>> > as per the installation notes. Of course the other side of the issue is
>> > whether a version will work at all. The operator can create a version of
>> > the template with their own versioning scheme, however. I should be
>> writing
>> > all this in another {DISCUSS]-thread.
>> >
>> > cancelling the RC to add code for Bruno's requirement.
>> >
>> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
>> >
>> > >
>> > > Please note: I my case, there isn't an upgrade, I have the issue with
>> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
>> > > 4.4-RC20150529T2004)
>> > >
>> > >
>> > >
>> > >
>> > > On 01/06/2015 07:22, Erik Weber wrote:
>> > > > If it means that all upgrades are unable to do VR related tasks (
>> > > starting
>> > > > VMs for one.. ), I'd call that regression and redo.
>> > > > Relying on all our users to do manual fixing just because we don't
>> want
>> > > to
>> > > > call off the RC is bad IMHO.
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
So we will have to include an update in every release and we will probably
forget about that pretty soon.
Op ma 1 jun. 2015 om 11:49 schreef Remi Bergsma <re...@remi.nl>:
> I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
> for 4.5.x etc. This is also close to what was hard-coded before.
>
> Regards,
> Remi
>
>
> 2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
>
> > Guess we'll be making a new rc. The value can be 0.0.0 for my part, it
> must
> > be an operator decision to set the MinVRVersion if it must be higher. It
> > will always be an upgrade matter and any seeded template should be
> accepted
> > as per the installation notes. Of course the other side of the issue is
> > whether a version will work at all. The operator can create a version of
> > the template with their own versioning scheme, however. I should be
> writing
> > all this in another {DISCUSS]-thread.
> >
> > cancelling the RC to add code for Bruno's requirement.
> >
> > Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
> >
> > >
> > > Please note: I my case, there isn't an upgrade, I have the issue with
> > > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > > 4.4-RC20150529T2004)
> > >
> > >
> > >
> > >
> > > On 01/06/2015 07:22, Erik Weber wrote:
> > > > If it means that all upgrades are unable to do VR related tasks (
> > > starting
> > > > VMs for one.. ), I'd call that regression and redo.
> > > > Relying on all our users to do manual fixing just because we don't
> want
> > > to
> > > > call off the RC is bad IMHO.
> > > >
> > > >
> > >
> > >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Remi Bergsma <re...@remi.nl>.
I'd say, as a default: 4.4.0 will be nice for any 4.4.x release, and 4.5.0
for 4.5.x etc. This is also close to what was hard-coded before.
Regards,
Remi
2015-06-01 11:33 GMT+02:00 Daan Hoogland <da...@gmail.com>:
> Guess we'll be making a new rc. The value can be 0.0.0 for my part, it must
> be an operator decision to set the MinVRVersion if it must be higher. It
> will always be an upgrade matter and any seeded template should be accepted
> as per the installation notes. Of course the other side of the issue is
> whether a version will work at all. The operator can create a version of
> the template with their own versioning scheme, however. I should be writing
> all this in another {DISCUSS]-thread.
>
> cancelling the RC to add code for Bruno's requirement.
>
> Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
>
> >
> > Please note: I my case, there isn't an upgrade, I have the issue with
> > 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> > 4.4-RC20150529T2004)
> >
> >
> >
> >
> > On 01/06/2015 07:22, Erik Weber wrote:
> > > If it means that all upgrades are unable to do VR related tasks (
> > starting
> > > VMs for one.. ), I'd call that regression and redo.
> > > Relying on all our users to do manual fixing just because we don't want
> > to
> > > call off the RC is bad IMHO.
> > >
> > >
> >
> >
>
Re: [VOTE] release candidate 4.4.4
Posted by Daan Hoogland <da...@gmail.com>.
Guess we'll be making a new rc. The value can be 0.0.0 for my part, it must
be an operator decision to set the MinVRVersion if it must be higher. It
will always be an upgrade matter and any seeded template should be accepted
as per the installation notes. Of course the other side of the issue is
whether a version will work at all. The operator can create a version of
the template with their own versioning scheme, however. I should be writing
all this in another {DISCUSS]-thread.
cancelling the RC to add code for Bruno's requirement.
Op ma 1 jun. 2015 om 08:35 schreef Milamber <mi...@apache.org>:
>
> Please note: I my case, there isn't an upgrade, I have the issue with
> 4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
> 4.4-RC20150529T2004)
>
>
>
>
> On 01/06/2015 07:22, Erik Weber wrote:
> > If it means that all upgrades are unable to do VR related tasks (
> starting
> > VMs for one.. ), I'd call that regression and redo.
> > Relying on all our users to do manual fixing just because we don't want
> to
> > call off the RC is bad IMHO.
> >
> >
>
>
Re: [VOTE] release candidate 4.4.4
Posted by Milamber <mi...@apache.org>.
Please note: I my case, there isn't an upgrade, I have the issue with
4.4.3 or 4.4.4 fresh installation (out of the box, from git tag
4.4-RC20150529T2004)
On 01/06/2015 07:22, Erik Weber wrote:
> If it means that all upgrades are unable to do VR related tasks ( starting
> VMs for one.. ), I'd call that regression and redo.
> Relying on all our users to do manual fixing just because we don't want to
> call off the RC is bad IMHO.
>
>
Re: [VOTE] release candidate 4.4.4
Posted by Erik Weber <te...@gmail.com>.
If it means that all upgrades are unable to do VR related tasks ( starting
VMs for one.. ), I'd call that regression and redo.
Relying on all our users to do manual fixing just because we don't want to
call off the RC is bad IMHO.
--
Erik
On Mon, Jun 1, 2015 at 7:40 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:
> Hi,
>
> Looks like MinVRVersionCK (minreq.sysvmtemplate.version) setting is a
> ConfigKey, I’m not sure about 4.4 but on 4.5/master it creates an entry in
> configuration table if unavailable. If upgrading from 4.4.2/4.4.1 to 4.4.4
> does not create this we can either add it in the upgrade path or add in the
> release/upgrade notes. I think the default version of MinVRVersionCK for
> 4.4 should be 4.4.0 to use any 4.4 template.
>
> I guess since it’s configuration related issue IMO there is no need to
> call off the RC voting, unless of course we find a regression or blocker.
>
> > On 01-Jun-2015, at 6:41 am, Remi Bergsma <re...@remi.nl> wrote:
> >
> > Hi Milamber,
> >
> > I think it is new in 4.4.4, backported from master but Daan can confirm.
> >
> > 4.4.1 refers to the system vm template version and not per se to
> CloudStack 4.4.1. There is no reason to upgrade it so it can stay at 4.4.1
> again as the upgrade procedure is much easier and faster without upgrading
> systemvms.
> >
> > It is a great feature because it allows to upgrade the systemvm template
> regardless of CloudStack version. Handy when there's a new glibc/shellshock
> alike issue.
> >
> > But it should work transparently and not bug users. Will work with Daan
> today to fix it.
> >
> > Same could be going on in 4.5 branch, will check that too.
> >
> > Regards, Remi
> >
> > Sent from my iPhone
> >
> >> On 31 May 2015, at 19:50, Milamber <mi...@apache.org> wrote:
> >>
> >> Hello Remi,
> >>
> >> Ok thanks.
> >> I execute this SQL request below, and now it's works.
> >>
> >>
> >> INSERT INTO `cloud`.`configuration`(`category`, `instance`,
> `component`, `name`, `value`, `description`, `default_value`, `updated`,
> `scope`, `is_dynamic`) VALUES('Advanced', 'DEFAULT', 'management-server',
> 'minreq.sysvmtemplate.version', '4.4.1', 'The minimal version for the
> systemvm', '4.4.1', NULL, NULL, 0);
> >>
> >>
> >> If I understand well, this "bug"/missing entry in database exists since
> 4.4.2?
> >>
> >>
> >> @Daan, Probably it would be better to fix this before the 4.4.4 release?
> >>
> >>
> >> Milamber
> >>
> >>
> >>> On 31/05/2015 17:07, Remi Bergsma wrote:
> >>> Hi Milamber,
> >>>
> >>> It is a global setting, although it appears not to be present in the
> cloud.configuration table by default (so you cannot find it). If you insert
> it, it works.
> >>>
> >>> I also played with the upgrade and did insert the setting, since at
> work we had changed the minimal version to a non standard 4.4.2 during a
> patch round. So I knew it wouldn't work out of the box for me.
> >>>
> >>> @daan: We might want to set the setting by default to 4.4.1 (in db) so
> upgrades work out-of-the-box and you can control it from the global
> settings pane. This may also need some attention in the docs. What do you
> think?
> >>>
> >>> Regards, Remi
> >>>
> >>>> On 31 May 2015, at 17:36, Milamber <mi...@apache.org> wrote:
> >>>>
> >>>> Hello Rohit,
> >>>>
> >>>>> On 31/05/2015 11:57, Rohit Yadav wrote:
> >>>>> +1 (binding)
> >>>>>
> >>>>> Here’s a test repository you can use for convenience built out of
> this tag/RC:
> >>>>> http://packages.shapeblue.com/cloudstack/testing/
> >>>>>
> >>>>> Deployed Basic Zone with/without SG, tested vm lifecycle.
> >>>>>
> >>>>> The VM deployment failed for me as minreq.sysvmtemplate.version
> global setting was set to 4.4.4, and I was using 4.4.1 template.
> >>>> Me too, all my tests failed because VR must be updated. I've past
> some hours to find why (test with different systemvmtemplate file,
> re-install, etc.)
> >>>>
> >>>>> After setting this to 4.4.1, all normal vm lifecycle worked for me.
> >>>> Where ? directly in
> ./engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java
> ?
> >>>>
> >>>> I don't find the minreq.sysvmtemplate.version key in the Global
> Settings view.
> >>>>
> >>>> Milamber
> >>>>
> >>>>
> >>>>> We need to document this in the docs, the systemvmtemplate build for
> 4.4 has been failing which might need to be fixed if we want 4.4.4 template:
> http://jenkins.buildacloud.org/view/4.4/
> >>>>>
> >>>>>> On 29-May-2015, at 8:10 pm, Daan Hoogland<da...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I've created a 4.4.4 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/
> >>>>>> <
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323
> >4.4-RC20150529T2004
> >>>>>> Commit: 7d2320cd1d27842fae73c7f43ef422da354f9999
> >>>>>>
> >>>>>> List of changes:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
> >>>>>>
> >>>>>> Source release (checksums and signatures are available at the same
> >>>>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
> >>>>>>
> >>>>>> PGP release keys (signed using
> >>>>>> AA4736F3):
> 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)
> >>>>> Regards,
> >>>>> Rohit Yadav
> >>>>> Software Architect, ShapeBlue
> >>>>> M. +91 88 262 30892 |rohit.yadav@shapeblue.com
> >>>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >>>>>
> >>>>>
> >>>>>
> >>>>> Find out more about ShapeBlue and our range of CloudStack related
> services
> >>>>>
> >>>>> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> >>>>> CSForge – rapid IaaS deployment framework<
> http://shapeblue.com/csforge/>
> >>>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> >>>>> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> >>>>> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> >>>>> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
> >>>>>
> >>>>> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed. Any
> views or opinions expressed are solely those of the author and do not
> necessarily represent those of Shape Blue Ltd or related companies. If you
> are not the intended recipient of this email, you must neither take any
> action based upon its contents, nor copy or show it to anyone. Please
> contact the sender if you believe you have received this email in error.
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> >>
> >>
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
Re: [VOTE] release candidate 4.4.4
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi,
Looks like MinVRVersionCK (minreq.sysvmtemplate.version) setting is a ConfigKey, I’m not sure about 4.4 but on 4.5/master it creates an entry in configuration table if unavailable. If upgrading from 4.4.2/4.4.1 to 4.4.4 does not create this we can either add it in the upgrade path or add in the release/upgrade notes. I think the default version of MinVRVersionCK for 4.4 should be 4.4.0 to use any 4.4 template.
I guess since it’s configuration related issue IMO there is no need to call off the RC voting, unless of course we find a regression or blocker.
> On 01-Jun-2015, at 6:41 am, Remi Bergsma <re...@remi.nl> wrote:
>
> Hi Milamber,
>
> I think it is new in 4.4.4, backported from master but Daan can confirm.
>
> 4.4.1 refers to the system vm template version and not per se to CloudStack 4.4.1. There is no reason to upgrade it so it can stay at 4.4.1 again as the upgrade procedure is much easier and faster without upgrading systemvms.
>
> It is a great feature because it allows to upgrade the systemvm template regardless of CloudStack version. Handy when there's a new glibc/shellshock alike issue.
>
> But it should work transparently and not bug users. Will work with Daan today to fix it.
>
> Same could be going on in 4.5 branch, will check that too.
>
> Regards, Remi
>
> Sent from my iPhone
>
>> On 31 May 2015, at 19:50, Milamber <mi...@apache.org> wrote:
>>
>> Hello Remi,
>>
>> Ok thanks.
>> I execute this SQL request below, and now it's works.
>>
>>
>> INSERT INTO `cloud`.`configuration`(`category`, `instance`, `component`, `name`, `value`, `description`, `default_value`, `updated`, `scope`, `is_dynamic`) VALUES('Advanced', 'DEFAULT', 'management-server', 'minreq.sysvmtemplate.version', '4.4.1', 'The minimal version for the systemvm', '4.4.1', NULL, NULL, 0);
>>
>>
>> If I understand well, this "bug"/missing entry in database exists since 4.4.2?
>>
>>
>> @Daan, Probably it would be better to fix this before the 4.4.4 release?
>>
>>
>> Milamber
>>
>>
>>> On 31/05/2015 17:07, Remi Bergsma wrote:
>>> Hi Milamber,
>>>
>>> It is a global setting, although it appears not to be present in the cloud.configuration table by default (so you cannot find it). If you insert it, it works.
>>>
>>> I also played with the upgrade and did insert the setting, since at work we had changed the minimal version to a non standard 4.4.2 during a patch round. So I knew it wouldn't work out of the box for me.
>>>
>>> @daan: We might want to set the setting by default to 4.4.1 (in db) so upgrades work out-of-the-box and you can control it from the global settings pane. This may also need some attention in the docs. What do you think?
>>>
>>> Regards, Remi
>>>
>>>> On 31 May 2015, at 17:36, Milamber <mi...@apache.org> wrote:
>>>>
>>>> Hello Rohit,
>>>>
>>>>> On 31/05/2015 11:57, Rohit Yadav wrote:
>>>>> +1 (binding)
>>>>>
>>>>> Here’s a test repository you can use for convenience built out of this tag/RC:
>>>>> http://packages.shapeblue.com/cloudstack/testing/
>>>>>
>>>>> Deployed Basic Zone with/without SG, tested vm lifecycle.
>>>>>
>>>>> The VM deployment failed for me as minreq.sysvmtemplate.version global setting was set to 4.4.4, and I was using 4.4.1 template.
>>>> Me too, all my tests failed because VR must be updated. I've past some hours to find why (test with different systemvmtemplate file, re-install, etc.)
>>>>
>>>>> After setting this to 4.4.1, all normal vm lifecycle worked for me.
>>>> Where ? directly in ./engine/api/src/org/apache/cloudstack/engine/orchestration/service/NetworkOrchestrationService.java ?
>>>>
>>>> I don't find the minreq.sysvmtemplate.version key in the Global Settings view.
>>>>
>>>> Milamber
>>>>
>>>>
>>>>> We need to document this in the docs, the systemvmtemplate build for 4.4 has been failing which might need to be fixed if we want 4.4.4 template:http://jenkins.buildacloud.org/view/4.4/
>>>>>
>>>>>> On 29-May-2015, at 8:10 pm, Daan Hoogland<da...@gmail.com> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I've created a 4.4.4 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/
>>>>>> <https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20150526T2323>4.4-RC20150529T2004
>>>>>> Commit: 7d2320cd1d27842fae73c7f43ef422da354f9999
>>>>>>
>>>>>> List of changes:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/tags/4.4.4
>>>>>>
>>>>>> Source release (checksums and signatures are available at the same
>>>>>> location):https://dist.apache.org/repos/dist/dev/cloudstack/4.4.4/
>>>>>>
>>>>>> PGP release keys (signed using
>>>>>> AA4736F3):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)
>>>>> Regards,
>>>>> Rohit Yadav
>>>>> Software Architect, ShapeBlue
>>>>> M. +91 88 262 30892 |rohit.yadav@shapeblue.com
>>>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>>>
>>>>>
>>>>>
>>>>> Find out more about ShapeBlue and our range of CloudStack related services
>>>>>
>>>>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>>>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>>>> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>>>>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>>>>> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>>>>>
>>>>> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>
>>
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.