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>
*™*
