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.
On Fri, Nov 15, 2013 at 12:14 AM, Abhinandan Prateek
<abhinandan.prat...@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" <shadow...@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" <da...@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 <shadow...@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.MySQLIntegrityConstraintViolationExcepti
>>>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.hoogl...@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.prat...@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" <shadow...@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.sh
>>> >>>>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":"Unable 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 <
>>> chipchild...@apache.org>
>>> >>>>wrote:
>>> >>>>> On Tue, Nov 12, 2013 at 10:52 AM, Abhinandan Prateek
>>> >>>>> <abhinandan.prat...@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_plain;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!
>>> >>>
>>>
>
