cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: networks and isolation/broadcast
Date Thu, 02 Jan 2014 07:14:23 GMT
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.tutkowski@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.tutkowski@solidfire.com> wrote:
>
>> OK, thanks!
>>
>>
>> On Wed, Jan 1, 2014 at 10:32 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>>
>>> git blame will show you the commit and committer.
>>>
>>> On Wed, Jan 1, 2014 at 10:19 PM, Mike Tutkowski
>>> <mike.tutkowski@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 <shadowsor@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.tutkowski@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.tutkowski@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 <
>>> shadowsor@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.tutkowski@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 <
>>> shadowsor@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 <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>
>>> >> >>> > > > *™*
>>> >> >>> > >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > --
>>> >> >>> > *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>
>>> >> >>> > *™*
>>> >> >>> >
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> *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>
>>> >> >> *™*
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > *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>
>>> >> > *™*
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > *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>
>>> > *™*
>>>
>>
>>
>>
>> --
>> *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>
>> *™*
>>
>
>
>
> --
> *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>
> *™*
>



-- 
*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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message