Yeah, this does appear to be a bug. I re-ran the attempted creation of my CloudStack cloud with a different XenServer host and was left in the same state (NPE).
I plan to try this with KVM tomorrow (er, later today, I guess). On Wed, Jan 1, 2014 at 11:10 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Looks like Daan added the method: > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=utils/src/com/cloud/utils/net/NetUtils.java;h=a315b935495469648a0a82a25c39c9c53f0226f6;hp=11a483c3f7e420056dce7893a86946de5c40e244;hb=94abbb1367bc817bae98f369e78679f0ddb7727f;hpb=6897984970df1455fa1ee0490157758ccfb68cff > > > On Wed, Jan 1, 2014 at 10:33 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> OK, thanks! >> >> >> On Wed, Jan 1, 2014 at 10:32 PM, Marcus Sorensen <shadow...@gmail.com>wrote: >> >>> git blame will show you the commit and committer. >>> >>> On Wed, Jan 1, 2014 at 10:19 PM, Mike Tutkowski >>> <mike.tutkow...@solidfire.com> wrote: >>> > Yeah, but I wasn't sure of the coder's intend and if your replacement >>> code >>> > meet their expectations, so I didn't change it. I was hoping someone >>> would >>> > claim the code and chime in. :) >>> > >>> > >>> > On Wed, Jan 1, 2014 at 10:16 PM, Marcus Sorensen <shadow...@gmail.com >>> >wrote: >>> > >>> >> Yeah, it would be clearer if they were checked separately: >>> >> >>> >> if (one == null || one.isEmpty()) { >>> >> return true; >>> >> } else if ( other == null || other.isEmpty()) [ >>> >> return true; >>> >> } >>> >> >>> >> or something like that. >>> >> >>> >> On Wed, Jan 1, 2014 at 10:00 PM, Mike Tutkowski >>> >> <mike.tutkow...@solidfire.com> wrote: >>> >> > I should say this check doesn't have to catch it...it might, but it >>> >> doesn't >>> >> > have to (depends on the value of one). >>> >> > >>> >> > >>> >> > On Wed, Jan 1, 2014 at 9:59 PM, Mike Tutkowski < >>> >> mike.tutkow...@solidfire.com >>> >> >> wrote: >>> >> > >>> >> >> Yeah, in my case I'm just setting up a basic zone with a XenServer >>> host. >>> >> >> >>> >> >> The code in NetUtils checks for null or "" on the variable in >>> question >>> >> >> that's passed in. However, in a certain case, null for that >>> variable can >>> >> >> slip by and lead to a NPE. >>> >> >> >>> >> >> if ((one == null || one.equals("")) >>> >> >> >>> >> >> && >>> >> >> >>> >> >> (other == null || other.equals(""))) >>> >> >> >>> >> >> { >>> >> >> >>> >> >> return true; >>> >> >> >>> >> >> } >>> >> >> >>> >> >> if other == null, this will not catch it and it can throw a NPE >>> later. >>> >> >> >>> >> >> >>> >> >> On Wed, Jan 1, 2014 at 9:51 PM, Marcus Sorensen < >>> shadow...@gmail.com >>> >> >wrote: >>> >> >> >>> >> >>> You can do "git blame (file)" and it will show you each line and >>> the >>> >> >>> commit. You can also do a git log on the file. The issue may not >>> be as >>> >> >>> obvious as that, though, there may be something totally unrelated >>> >> causing >>> >> >>> that object to end up null in this code. Or it may be specific to >>> your >>> >> >>> setup, some obscure bug nobody else is hitting. >>> >> >>> On Jan 1, 2014 4:22 PM, "Mike Tutkowski" < >>> mike.tutkow...@solidfire.com >>> >> > >>> >> >>> wrote: >>> >> >>> >>> >> >>> > This is in 4.3. >>> >> >>> > >>> >> >>> > I know the file is NetUtils, but I'm not sure in Git how to >>> look at >>> >> the >>> >> >>> > history of a particular file like I could do in SVN. >>> >> >>> > >>> >> >>> > >>> >> >>> > On Wed, Jan 1, 2014 at 3:55 PM, Marcus Sorensen < >>> shadow...@gmail.com >>> >> > >>> >> >>> > wrote: >>> >> >>> > >>> >> >>> > > Which branch? I see these in master, you can check out the >>> commit >>> >> just >>> >> >>> > > before these and see if it helps: >>> >> >>> > > >>> >> >>> > > commit b477e4e830597100f0c0171dd8e56f4033bd07aa >>> >> >>> > > Author: Daan Hoogland <dhoogl...@schubergphilis.com> >>> >> >>> > > Date: Tue Dec 31 12:52:51 2013 +0100 >>> >> >>> > > >>> >> >>> > > some xtra cases >>> >> >>> > > >>> >> >>> > > commit 2cf356e047e26977c1d294fafc57e986c04fc5f4 >>> >> >>> > > Author: Daan Hoogland <dhoogl...@schubergphilis.com> >>> >> >>> > > Date: Tue Dec 31 12:25:17 2013 +0100 >>> >> >>> > > >>> >> >>> > > isSameIsolationId >>> >> >>> > > >>> >> >>> > > commit 04570eefed9a0ee1eca1fd700ed5732ba67150ce >>> >> >>> > > Author: Daan Hoogland <d...@onecht.net> >>> >> >>> > > Date: Fri Dec 20 16:47:58 2013 +0100 >>> >> >>> > > >>> >> >>> > > check vlans and other isolation types >>> >> >>> > > >>> >> >>> > > commit d50517e931e68daef6735bd18273499fee0d4649 >>> >> >>> > > Author: Sateesh Chodapuneedi <sate...@apache.org> >>> >> >>> > > Date: Tue Dec 31 07:16:35 2013 +0530 >>> >> >>> > > >>> >> >>> > > I also have a commit just after these, but it was pretty >>> minor and >>> >> >>> > > only to KVM agent code. >>> >> >>> > > >>> >> >>> > > On Wed, Jan 1, 2014 at 3:27 PM, Mike Tutkowski >>> >> >>> > > <mike.tutkow...@solidfire.com> wrote: >>> >> >>> > > > Hey guys, >>> >> >>> > > > >>> >> >>> > > > The NPE I saw last night was related to "isolation id." Is >>> it >>> >> >>> possible >>> >> >>> > > this >>> >> >>> > > > NPE is related to something new that was put that you are >>> talking >>> >> >>> about >>> >> >>> > > > here? >>> >> >>> > > > >>> >> >>> > > > Thank! >>> >> >>> > > > >>> >> >>> > > > ERROR [c.c.a.ApiServer] (1583467451@qtp-185135566-2 >>> :ctx-ae5d80b2 >>> >> >>> > > > ctx-5c12c4d9) unhandled exception executing api command: >>> >> >>> > > createVlanIpRange >>> >> >>> > > > java.lang.NullPointerException >>> >> >>> > > > at >>> >> >>> > >>> com.cloud.utils.net.NetUtils.isSameIsolationId(NetUtils.java:1419) >>> >> >>> > > > at com.cloud.configuration.ConfigurationManagerImpl. >>> >> >>> > > > >>> createVlanAndPublicIpRange(ConfigurationManagerImpl.java:2474) >>> >> >>> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >> Method) >>> >> >>> > > > at sun.reflect.NativeMethodAccessorImpl.invoke( >>> >> >>> > > > NativeMethodAccessorImpl.java:57) >>> >> >>> > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke( >>> >> >>> > > > DelegatingMethodAccessorImpl.java:43) >>> >> >>> > > > at java.lang.reflect.Method.invoke(Method.java:616) >>> >> >>> > > > at org.springframework.aop.support.AopUtils. >>> >> >>> > > > invokeJoinpointUsingReflection(AopUtils.java:317) >>> >> >>> > > > at >>> >> org.springframework.aop.framework.ReflectiveMethodInvocation. >>> >> >>> > > > invokeJoinpoint(ReflectiveMethodInvocation.java:183) >>> >> >>> > > > at >>> >> >>> > > >>> >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >> >>> > > > ReflectiveMethodInvocation.java:150) >>> >> >>> > > > at com.cloud.event.ActionEventInterceptor.invoke( >>> >> >>> > > > ActionEventInterceptor.java:50) >>> >> >>> > > > at >>> >> >>> > > >>> >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >> >>> > > > ReflectiveMethodInvocation.java:161) >>> >> >>> > > > at >>> >> >>> org.springframework.aop.interceptor.ExposeInvocationInterceptor. >>> >> >>> > > > invoke(ExposeInvocationInterceptor.java:91) >>> >> >>> > > > at >>> >> >>> > > >>> >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>> >> >>> > > > ReflectiveMethodInvocation.java:172) >>> >> >>> > > > at org.springframework.aop.framework.JdkDynamicAopProxy. >>> >> >>> > > > invoke(JdkDynamicAopProxy.java:204) >>> >> >>> > > > at sun.proxy.$Proxy96.createVlanAndPublicIpRange(Unknown >>> >> Source) >>> >> >>> > > > at org.apache.cloudstack.api.command.admin.vlan. >>> >> >>> > > > CreateVlanIpRangeCmd.execute(CreateVlanIpRangeCmd.java:211) >>> >> >>> > > > at >>> >> com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) >>> >> >>> > > > at >>> com.cloud.api.ApiServer.queueCommand(ApiServer.java:530) >>> >> >>> > > > at >>> com.cloud.api.ApiServer.handleRequest(ApiServer.java:373) >>> >> >>> > > > at >>> >> >>> > > >>> >> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) >>> >> >>> > > > at >>> com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) >>> >> >>> > > > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) >>> >> >>> > > > at org.apache.cloudstack.managed.context.impl. >>> >> >>> > > > DefaultManagedContext$1.call(DefaultManagedContext.java:56) >>> >> >>> > > > at >>> >> >>> > >>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext. >>> >> >>> > > > callWithContext(DefaultManagedContext.java:103) >>> >> >>> > > > at >>> >> >>> > >>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext. >>> >> >>> > > > runWithContext(DefaultManagedContext.java:53) >>> >> >>> > > > at >>> >> com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111) >>> >> >>> > > > >>> >> >>> > > > >>> >> >>> > > > On Wed, Jan 1, 2014 at 2:33 PM, Marcus Sorensen < >>> >> >>> shadow...@gmail.com> >>> >> >>> > > wrote: >>> >> >>> > > > >>> >> >>> > > >> That's just it. The isolation type *is* provided when >>> creating >>> >> >>> > > >> physical network. If I create a physical network with >>> isolation >>> >> >>> type >>> >> >>> > > >> 'VXLAN', and then add traffic type of 'Public', it doesn't >>> obey >>> >> it. >>> >> >>> > > >> There's physical_networks and networks, when the zone is >>> >> created, >>> >> >>> an >>> >> >>> > > >> entry goes in network that is Public/Vlan, hardcoded. The >>> Public >>> >> >>> > > >> traffic type uses this, regardless of what the >>> physical_network >>> >> its >>> >> >>> > > >> being added to says. So if we updated the the public >>> network >>> >> table >>> >> >>> row >>> >> >>> > > >> with the correct isolation method for that physical >>> network we >>> >> are >>> >> >>> > > >> adding traffic type to when we add the public traffic >>> type, that >>> >> >>> would >>> >> >>> > > >> work. It's worth noting that a zone can only have one >>> physical >>> >> >>> network >>> >> >>> > > >> with traffic type of public. >>> >> >>> > > >> >>> >> >>> > > >> On Wed, Jan 1, 2014 at 12:37 PM, Daan Hoogland < >>> >> >>> > daan.hoogl...@gmail.com >>> >> >>> > > > >>> >> >>> > > >> wrote: >>> >> >>> > > >> >> While I've got your attention, what's the deal with >>> isolation >>> >> >>> > method >>> >> >>> > > vs >>> >> >>> > > >> broadcast method? These are always set to the same thing >>> as far >>> >> as >>> >> >>> > I've >>> >> >>> > > >> seen. >>> >> >>> > > >> > >>> >> >>> > > >> > I've been asking this but haven't found the answer yet. >>> There >>> >> is >>> >> >>> an >>> >> >>> > > >> > overlap but both have some extra values the other hasn't. >>> >> >>> > > >> > >>> >> >>> > > >> > I don't like either of your solutions but haven't got a >>> good >>> >> >>> > > >> > alternative. Best would be to be able to set the >>> isolation >>> >> type >>> >> >>> on >>> >> >>> > > >> > each physical network on creation. The wizard and zone >>> >> creation >>> >> >>> api >>> >> >>> > > >> > command would have to be extended and allow for vlan as >>> >> default. >>> >> >>> > > >> > >>> >> >>> > > >> > regards, >>> >> >>> > > >> > >>> >> >>> > > >> > On Wed, Jan 1, 2014 at 8:53 AM, Marcus Sorensen < >>> >> >>> > shadow...@gmail.com> >>> >> >>> > > >> wrote: >>> >> >>> > > >> >> I suppose the answer might be to update the network >>> with the >>> >> >>> proper >>> >> >>> > > >> >> isolation method when the traffic type is added. Look >>> up the >>> >> >>> > physical >>> >> >>> > > >> >> network's isolation method, grab network object for the >>> >> public >>> >> >>> > > network, >>> >> >>> > > >> and >>> >> >>> > > >> >> set the right isolation. >>> >> >>> > > >> >> On Jan 1, 2014 12:46 AM, "Marcus Sorensen" < >>> >> shadow...@gmail.com >>> >> >>> > >>> >> >>> > > wrote: >>> >> >>> > > >> >> >>> >> >>> > > >> >>> I ran into an issue today that I'm still trying to >>> wrap my >>> >> >>> head >>> >> >>> > > >> >>> around, and I wanted to bounce this off of you guys. I >>> have >>> >> a >>> >> >>> > > physical >>> >> >>> > > >> >>> network whose isolation method is set to 'VXLAN' >>> (v4.3+). I >>> >> >>> add my >>> >> >>> > > >> >>> Public traffic type to it. I'd assume that nics >>> generated >>> >> for >>> >> >>> > public >>> >> >>> > > >> >>> traffic would have the standard vxlan:// URI for >>> isolation >>> >> >>> URI >>> >> >>> > and >>> >> >>> > > >> >>> broadcast URI, but they just have a vlan://. Digging >>> into >>> >> it, >>> >> >>> it >>> >> >>> > > seems >>> >> >>> > > >> >>> that public traffic is hard-coded to >>> >> BroadcastDomainType.Vlan. >>> >> >>> I >>> >> >>> > > fixed >>> >> >>> > > >> >>> this fairly easily for my testing, there were only a >>> few >>> >> >>> places to >>> >> >>> > > >> >>> fix, by pulling the BroadcastDomainType from the >>> network >>> >> object >>> >> >>> > > rather >>> >> >>> > > >> >>> than hardcoding it, but that found another problem. >>> This >>> >> only >>> >> >>> > works >>> >> >>> > > if >>> >> >>> > > >> >>> I change the broadcast type in the 'networks' mysql >>> table by >>> >> >>> hand, >>> >> >>> > > as >>> >> >>> > > >> >>> during zone deployment the public network creation is >>> also >>> >> >>> > > hard-coded >>> >> >>> > > >> >>> to vlan. >>> >> >>> > > >> >>> >>> >> >>> > > >> >>> I'm not sure how to go about fixing this, since the >>> >> Public, >>> >> >>> > > Control, >>> >> >>> > > >> >>> Management networks are created upon zone deployment, >>> (see >>> >> >>> > > >> >>> createDefaultSystemNetworks). The immediate thing that >>> >> jumped >>> >> >>> out >>> >> >>> > > was >>> >> >>> > > >> >>> a config variable for public isolation method, set >>> prior to >>> >> >>> zone >>> >> >>> > > >> >>> deployment, or perhaps even one that overrides what's >>> in the >>> >> >>> > table. >>> >> >>> > > >> >>> >>> >> >>> > > >> >>> While I've got your attention, what's the deal with >>> >> isolation >>> >> >>> > > method >>> >> >>> > > >> >>> vs broadcast method? These are always set to the same >>> thing >>> >> as >>> >> >>> far >>> >> >>> > > as >>> >> >>> > > >> >>> I've seen. >>> >> >>> > > >> >>> >>> >> >>> > > >> >>> >> >>> > > > >>> >> >>> > > > >>> >> >>> > > > >>> >> >>> > > > -- >>> >> >>> > > > *Mike Tutkowski* >>> >> >>> > > > *Senior CloudStack Developer, SolidFire Inc.* >>> >> >>> > > > e: mike.tutkow...@solidfire.com >>> >> >>> > > > o: 303.746.7302 >>> >> >>> > > > Advancing the way the world uses the >>> >> >>> > > > cloud<http://solidfire.com/solution/overview/?video=play> >>> >> >>> > > > *™* >>> >> >>> > > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > -- >>> >> >>> > *Mike Tutkowski* >>> >> >>> > *Senior CloudStack Developer, SolidFire Inc.* >>> >> >>> > e: mike.tutkow...@solidfire.com >>> >> >>> > o: 303.746.7302 >>> >> >>> > Advancing the way the world uses the >>> >> >>> > cloud<http://solidfire.com/solution/overview/?video=play> >>> >> >>> > *™* >>> >> >>> > >>> >> >>> >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> *Mike Tutkowski* >>> >> >> *Senior CloudStack Developer, SolidFire Inc.* >>> >> >> e: mike.tutkow...@solidfire.com >>> >> >> o: 303.746.7302 >>> >> >> Advancing the way the world uses the cloud< >>> >> http://solidfire.com/solution/overview/?video=play> >>> >> >> *™* >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > *Mike Tutkowski* >>> >> > *Senior CloudStack Developer, SolidFire Inc.* >>> >> > e: mike.tutkow...@solidfire.com >>> >> > o: 303.746.7302 >>> >> > Advancing the way the world uses the >>> >> > cloud<http://solidfire.com/solution/overview/?video=play> >>> >> > *™* >>> >> >>> > >>> > >>> > >>> > -- >>> > *Mike Tutkowski* >>> > *Senior CloudStack Developer, SolidFire Inc.* >>> > e: mike.tutkow...@solidfire.com >>> > o: 303.746.7302 >>> > Advancing the way the world uses the >>> > cloud<http://solidfire.com/solution/overview/?video=play> >>> > *™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *™* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
