cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radhika Puthiyetath <radhika.puthiyet...@citrix.com>
Subject RE: [VOTE] Release Apache CloudStack 4.2.1
Date Sat, 16 Nov 2013 13:42:11 GMT
Could someone please file a documentation bug on this issue ?

-----Original Message-----
From: Marcus Sorensen [mailto:shadowsor@gmail.com] 
Sent: Saturday, November 16, 2013 5:49 AM
To: dev@cloudstack.apache.org
Cc: Radhika Puthiyetath
Subject: Re: [VOTE] Release Apache CloudStack 4.2.1

As long as we document the router reboot requirement in the release notes, yes, I'm +1.

On a side note, we have an upgradeRouterScripts API call (in our
plugin) that just scps the new systemvm tar up to a given router and extracts it, which allows
us to avoid reboots, but we've been leary of pushing it as a feature because we only use it
on things that we know don't need service restarts (this new savepassword.sh is a good example).
In other words it's not really end-user friendly. We should put something like this on the
list for improvements next time around, if we can come up with a way to reinitialize the cloud-early
init service.

On Fri, Nov 15, 2013 at 4:30 PM, Animesh Chaturvedi <animesh.chaturvedi@citrix.com>
wrote:
>
>
> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Thursday, November 14, 2013 11:42 PM
> To: dev@cloudstack.apache.org
> Cc: Radhika Puthiyetath
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.1
>
> Ok, that may be my fault as I've got various 4.2.0 systems built from testing various
RCs. I just chose one and tried to upgrade it. Thanks for clearing that up.
>
> Animesh> So Marcus this is not a -1 then right?
>
> On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
wrote:
>> Marcus,
>>
>>   I am trying to understand the upgrade issue that you are facing.
>> It seems there were changes during various rounds of RC that we had 
>> for
>> 4.2.0 .
>> The fix that you have mentioned in the email actually got introduced 
>> in the 4.2 GA.
>> So someone upgrading to 4.2 GA will not have that constraint on the 
>> vpc_service_map table.
>>
>>  Just for clarity this does not affect the upgrade from 4.2 GA to 4.2.1.
>> If you have any doubts please specify those with clarity so these it 
>> can get rectified at the earliest.
>>
>> David,
>>   I think it is still not a ³-1².
>>
>> -abhi
>>
>> On 15/11/13 10:40 am, "Marcus Sorensen" <shadowsor@gmail.com> wrote:
>>
>>>Yes, I'd say that upgrade from 4.2.0 to 4.2.1 needs to work.
>>>On Nov 14, 2013 5:58 PM, "David Nalley" <david@gnsa.us> wrote:
>>>
>>>> Marcus:
>>>>
>>>> Is this is a -1?
>>>>
>>>> I don't have any legal concerns, and the release builds and tests 
>>>> for me (though I haven't tried VPC).  I am somewhat concerned about 
>>>> what appears to be drifting away from adhering to semver. (features 
>>>> appear to have made it into the 4.2.1 release that weren't in 
>>>> 4.2.0) and I am also concerned about sys vm update fatigue, 
>>>> especially given the problems we had in 4.2.0 around sysvm updates.
>>>>
>>>> --David
>>>>
>>>> On Thu, Nov 14, 2013 at 1:08 PM, Marcus Sorensen 
>>>> <shadowsor@gmail.com>
>>>> wrote:
>>>> > Yeah, I understand that 4.2.0 had a lot of post-release work needed.
>>>> >
>>>> > We are unable to create VPNs.  This is reported second hand from 
>>>> > one of my admins. He seems to think that it was caused by the 
>>>> > following, which added a for loop inside a for loop. The error is:
>>>> >
>>>>
>>>>'com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationEx
>>>>c
>>>>epti
>>>>on:
>>>> > Duplicate entry '146-Lb' for key 'vpc_id'
>>>> >
>>>> > We did the following to fix it, something should be added to the 
>>>> > sql
>>>> upgrade.
>>>> > mysql -D cloud -t -e 'alter table vpc_service_map drop key 
>>>> > vpc_id, add unique key vpc_id (vpc_id,service,provider)'
>>>> >
>>>> >
>>>> > commit 9050cfad3da673370d6ad1ed7570e31314069996
>>>> >
>>>> >     CLOUDSTACK-4704: 41-42 db upgrade - populate vpc_service_map 
>>>> > table with the services/providers supported by VPC
>>>> >
>>>> >
>>>> >      @Override
>>>> >      @DB
>>>> > -    public void persistVpcServiceProviders(long vpcId, Map<String,
>>>> > String> serviceProviderMap) {
>>>> > +    public void persistVpcServiceProviders(long vpcId, 
>>>> > + Map<String,
>>>> > List<String>> serviceProviderMap) {
>>>> >          Transaction txn = Transaction.currentTxn();
>>>> >          txn.start();
>>>> >          for (String service : serviceProviderMap.keySet()) {
>>>> > -            VpcServiceMapVO serviceMap = new VpcServiceMapVO(vpcId,
>>>> > Network.Service.getService(service),
>>>> > Network.Provider.getProvider(serviceProviderMap.get(service)));
>>>> > -            _vpcSvcMap.persist(serviceMap);
>>>> > +            for (String provider : serviceProviderMap.get(service))
{
>>>> > +                VpcServiceMapVO serviceMap = new
>>>> > VpcServiceMapVO(vpcId, Network.Service.getService(service),
>>>> > Network.Provider.getProvider(provider));
>>>> > +                _vpcSvcMap.persist(serviceMap);
>>>> > +            }
>>>> >          }
>>>> >          txn.commit();
>>>> >      }
>>>> >
>>>> >
>>>> > On Thu, Nov 14, 2013 at 9:40 AM, Daan Hoogland
>>>><daan.hoogland@gmail.com>
>>>> wrote:
>>>> >> +1 binding (I had not been clear on this in this thread it 
>>>> >> +seems)
>>>> >>
>>>> >> On Thu, Nov 14, 2013 at 6:05 AM, Abhinandan Prateek 
>>>> >> <Abhinandan.Prateek@citrix.com> wrote:
>>>> >>> Marcus,
>>>> >>>
>>>> >>>   Just summarising your concerns so that they can be followed
upon:
>>>> >>> 1. Due to a VR script change a restart of VR is required. This
>>>>should
>>>> be
>>>> >>> noted down in upgrade instructions in RN. (Radhika to note)
2.
>>>> >>> For a maintenance release we should limit the scope to only
>>>> blockers. I
>>>> >>> guess what is done is done probably for better as the main 
>>>> >>> release
>>>>had
>>>> so
>>>> >>> many new features that a whole lot fixes were expected in the
>>>> maintenance
>>>> >>> release. But again for further maintenance releases scope 
>>>> >>> should be restricted to important fixes.
>>>> >>>
>>>> >>> Any other thing that has been missed ?
>>>> >>>
>>>> >>> -abhi
>>>> >>>
>>>> >>>
>>>> >>> On 14/11/13 12:06 am, "Marcus Sorensen" <shadowsor@gmail.com>
wrote:
>>>> >>>
>>>> >>>>I'm unable to deploy virtual machines after upgrading an

>>>> >>>>existing
>>>> >>>>4.2.0 to this release.
>>>> >>>>
>>>> >>>>It looks like the file savepassword.sh was added at the end
of
>>>>October
>>>> >>>>as a virtual router script. This would likely mean that people

>>>> >>>>upgrading to 4.2.1 will need to upgrade/redeploy their routers.
>>>> >>>>I
>>>>can
>>>> >>>>verify that deploy works if I reboot the router.
>>>> >>>>
>>>> >>>>Looking over the current state of 4.2, I'm actually pretty

>>>> >>>>surprised at how much has changed. I'm seeing lots of 
>>>> >>>>whitespace fixes,
>>>>changes
>>>> >>>>to interfaces, etc. My impression was that we'd only commit

>>>> >>>>fixes
>>>>for
>>>> >>>>blocker bugs once a release has gone production, only touching

>>>> >>>>it if we had to. This went pretty well with 4.1, I thought,
but 
>>>> >>>>everything was going through the RM that round.
>>>> >>>>
>>>> >>>>2013-11-13 11:25:24,917 DEBUG
>>>> >>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>> >>>>(agentRequest-Handler-2:null) Executing:
>>>> >>>>/usr/share/cloudstack-common/scripts/network/domr/router_proxy.
>>>> >>>>s h savepassword.sh 169.254.1.163 -v 10.2.4.116 -p 
>>>> >>>>fnirq_cnffjbeq
>>>> >>>>
>>>> >>>>2013-11-13 11:25:25,000 DEBUG
>>>> >>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>> >>>>(agentRequest-Handler-2:null) Exit value is 127
>>>> >>>>
>>>> >>>>2013-11-13 11:25:25,001 DEBUG
>>>> >>>>[resource.virtualnetwork.VirtualRoutingResource]
>>>> >>>>(agentRequest-Handler-2:null) bash: /opt/cloud/bin/savepassword.sh:
>>>>No
>>>> >>>>such file or directory
>>>> >>>>
>>>> >>>>2013-11-13 11:25:25,002 DEBUG [cloud.agent.Agent]
>>>> >>>>(agentRequest-Handler-2:null) Seq 21-289734823:  { Ans: ,
MgmtId:
>>>> >>>>90520732090445, via: 21, Ver: v1, Flags: 110, 
>>>> >>>>[{"com.cloud.agent.api.Answer":{"result":false,"details":"Unabl
>>>> >>>>e
>>>> >>>>to save password to
>>>>
>>>>
>>>>>>>>DomR.","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"
>>>>>>>>deta
>>>>>>>>ils":
>>>> >>>>"Stopped
>>>> >>>>by previous failure","wait":0}}] }
>>>> >>>>
>>>> >>>>On Wed, Nov 13, 2013 at 10:26 AM, Chip Childers <
>>>> chipchilders@apache.org>
>>>> >>>>wrote:
>>>> >>>>> On Tue, Nov 12, 2013 at 10:52 AM, Abhinandan Prateek

>>>> >>>>> <Abhinandan.Prateek@citrix.com> wrote:
>>>> >>>>>>
>>>> >>>>>>    This vote is to approve the current RC build
for 4.2.1
>>>> maintenance
>>>> >>>>>>release.
>>>> >>>>>> For this particular release various upgrade paths
have been
>>>>tested
>>>> >>>>>>apart from regression tests and BVTs.
>>>> >>>>>> Around 175 bugs have been fixed some new features
added (see
>>>> CHANGES).
>>>> >>>>>>
>>>> >>>>>> Following are the particulars for this release:
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog
>>>> ;
>>>> h=re
>>>> >>>>>>fs/heads/4.2
>>>> >>>>>> commit: 0b9eadaf14513f5c72de672963b0e2f12ee7206f
>>>> >>>>>>
>>>> >>>>>> List of changes:
>>>> >>>>>>
>>>> >>>>>>
>>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_pla
>>>> i
>>>> n;f=
>>>> >>>>>>CHANGES;hb=4.2.1
>>>> >>>>>>
>>>> >>>>>> Source release revision 3492 (checksums and signatures
are
>>>>available
>>>> >>>>>>at the same location):
>>>> >>>>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>>>> >>>>>>
>>>> >>>>>> PGP release keys (signed using RSA Key ID = 42443AA1):
>>>> >>>>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>>> >>>>>>
>>>> >>>>>> Vote will be open for 72 hours (until 11/15 End
of day PST).
>>>> >>>>>>
>>>> >>>>>> 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)
>>>> >>>>>
>>>> >>>>> +1 (binding)
>>>> >>>>>
>>>> >>>>> I only performed very rudimentary functional testing,
but the 
>>>> >>>>> artifact's look legit.
>>>> >>>>>
>>>> >>>>> Thanks for doing this Abhi!
>>>> >>>
>>>>
>>

Mime
View raw message