cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: networks and isolation/broadcast
Date Wed, 01 Jan 2014 22:55:27 GMT
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 <dhoogland@schubergphilis.com>
Date:   Tue Dec 31 12:52:51 2013 +0100

    some xtra cases

commit 2cf356e047e26977c1d294fafc57e986c04fc5f4
Author: Daan Hoogland <dhoogland@schubergphilis.com>
Date:   Tue Dec 31 12:25:17 2013 +0100

    isSameIsolationId

commit 04570eefed9a0ee1eca1fd700ed5732ba67150ce
Author: Daan Hoogland <daan@onecht.net>
Date:   Fri Dec 20 16:47:58 2013 +0100

    check vlans and other isolation types

commit d50517e931e68daef6735bd18273499fee0d4649
Author: Sateesh Chodapuneedi <sateesh@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.tutkowski@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 <shadowsor@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.hoogland@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 <shadowsor@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" <shadowsor@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*

Mime
View raw message