Yeah, I'm not sure what's supposed to happen there.

I guess it's supposed to enter the Starting state and then when it gets
into the Running state is when we stop returning null (so I suppose it's
OK).

I'm just trying to figure how why my system VMs don't start. :)


On Thu, Jan 2, 2014 at 1:36 PM, Daan Hoogland <daan.hoogl...@gmail.com>wrote:

> I pushed an extra check to 4.3
>
> I'm not sure what you mean with your last post Mike.
>
>             if (proxy.getState() == VirtualMachine.State.Stopped) {
>                 _itMgr.advanceStart(proxy.getUuid(), null, null);
>                 proxy = _consoleProxyDao.findById(proxy.getId());
>             }
> maybe you are right but after the above the proxy is Starting I
> suppose so according to
>           // For VMs that are in Stopping, Starting, Migrating state,
> let client to wait by returning null
> null should be returned.
>
> no?
> Daan
>
>
> On Thu, Jan 2, 2014 at 9:09 PM, Mike Tutkowski
> <mike.tutkow...@solidfire.com> wrote:
> > I'm not that familiar with this part of the codebase, but the code in the
> > "Stopped" if block looks incorrect when it assigns to proxy instead of
> > doing a return.
> >
> > Thoughts?
> >
> >     @Override
> >
> >     public ConsoleProxyVO startProxy(long proxyVmId) {
> >
> >         try {
> >
> >             ConsoleProxyVO proxy = _consoleProxyDao.findById(proxyVmId);
> >
> >             if (proxy.getState() == VirtualMachine.State.Running) {
> >
> >                 return proxy;
> >
> >             }
> >
> >
> >             String restart =
> _configDao.getValue(Config.ConsoleProxyRestart
> > .key());
> >
> >             if (restart != null && restart.equalsIgnoreCase("false")) {
> >
> >                 return null;
> >
> >             }
> >
> >
> >             if (proxy.getState() == VirtualMachine.State.Stopped) {
> >
> >                 _itMgr.advanceStart(proxy.getUuid(), null, null);
> >
> >                 proxy = _consoleProxyDao.findById(proxy.getId());
> >
> >             }
> >
> >
> >             // For VMs that are in Stopping, Starting, Migrating state,
> let
> > client to wait by returning null
> >
> >             // as sooner or later, Starting/Migrating state will be
> > transited to Running and Stopping will be transited
> >
> >             // to
> >
> >             // Stopped to allow
> >
> >             // Starting of it
> >
> >             s_logger.warn("Console proxy is not in correct state to be
> > started: " + proxy.getState());
> >
> >             return null;
> >
> >         } catch (StorageUnavailableException e) {
> >
> >             s_logger.warn("Exception while trying to start console
> proxy",
> > e);
> >
> >             return null;
> >
> >         } catch (InsufficientCapacityException e) {
> >
> >             s_logger.warn("Exception while trying to start console
> proxy",
> > e);
> >
> >             return null;
> >
> >         } catch (ResourceUnavailableException e) {
> >
> >             s_logger.warn("Exception while trying to start console
> proxy",
> > e);
> >
> >             return null;
> >
> >         } catch (ConcurrentOperationException e) {
> >
> >             s_logger.warn("Runtime Exception while trying to start
> console
> > proxy", e);
> >
> >             return null;
> >
> >         } catch (CloudRuntimeException e) {
> >
> >             s_logger.warn("Runtime Exception while trying to start
> console
> > proxy", e);
> >
> >             return null;
> >
> >         } catch (OperationTimedoutException e) {
> >
> >             s_logger.warn("Runtime Exception while trying to start
> console
> > proxy", e);
> >
> >             return null;
> >
> >         }
> >
> >     }
> >
> >
> > On Thu, Jan 2, 2014 at 12:48 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> I did notice one issue, but I don't think it's the cause because after
> >> correcting it the system VMs still do not start.
> >>
> >> In the wizard, I said I wanted to use local storage; however, I see the
> >> system.vm.use.local.storage property was still false after my cloud was
> >> created. I changed it to true and re-started the CS MS, but now I get an
> >> exception and still no system VMs start:
> >>
> >> ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-9:ctx-5a124def)
> >> Unexpected exception
> >> java.lang.NullPointerException
> >>     at
> >>
> com.google.gson.JsonPrimitive.isPrimitiveOrString(JsonPrimitive.java:316)
> >>     at com.google.gson.JsonPrimitive.setValue(JsonPrimitive.java:97)
> >>     at com.google.gson.JsonPrimitive.<init>(JsonPrimitive.java:67)
> >>     at
> >>
> org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper$ThrowableTypeAdapter.serialize(JobSerializerHelper.java:195)
> >>     at
> >>
> org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper$ThrowableTypeAdapter.serialize(JobSerializerHelper.java:158)
> >>     at
> >>
> com.google.gson.JsonSerializationVisitor.findAndInvokeCustomSerializer(JsonSerializationVisitor.java:184)
> >>     at
> >>
> com.google.gson.JsonSerializationVisitor.visitFieldUsingCustomHandler(JsonSerializationVisitor.java:204)
> >>     at
> >>
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
> >>     at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
> >>     at
> >>
> com.google.gson.JsonSerializationContextDefault.serialize(JsonSerializationContextDefault.java:62)
> >>     at
> >>
> com.google.gson.JsonSerializationContextDefault.serialize(JsonSerializationContextDefault.java:53)
> >>     at com.google.gson.Gson.toJsonTree(Gson.java:220)
> >>     at com.google.gson.Gson.toJson(Gson.java:260)
> >>     at com.google.gson.Gson.toJson(Gson.java:240)
> >>     at
> >>
> org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.toSerializedString(JobSerializerHelper.java:65)
> >>     at
> >> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:105)
> >>     at
> >>
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522)
> >>     at
> >>
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> >>
> >>     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
> >>
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> >>     at
> >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> >>     at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> >>     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> >>     at
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> >>     at
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>     at java.lang.Thread.run(Thread.java:679)
> >>
> >>
> >>
> >> On Thu, Jan 2, 2014 at 12:40 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >>> Cool...sounds good
> >>>
> >>> Does anyone have any thoughts on the system VM issue (with them not
> >>> starting on Xen or KVM)?
> >>>
> >>> Console proxy is not in correct state to be started: Stopped
> >>>
> >>>
> >>> On Thu, Jan 2, 2014 at 12:35 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>wrote:
> >>>
> >>>> hey guys,
> >>>>
> >>>> have been sick in bed all day, sorry to react slowly. I saw your
> >>>> explanation Marcus and I should check for the case that only one of
> >>>> the two is null and return false.
> >>>> I will update and if you haven't already I will put in a fix.
> >>>>
> >>>> regards,
> >>>> Daan
> >>>>
> >>>> On Thu, Jan 2, 2014 at 8:55 AM, Marcus Sorensen <shadow...@gmail.com>
> >>>> wrote:
> >>>> > There are some other issues near that commit as well. A fix for
> >>>> > CLOUDSTACK-5502 that makes 'untagged' invalid needs to be backed
> out.
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Thu, Jan 2, 2014 at 12:14 AM, Mike Tutkowski
> >>>> > <mike.tutkow...@solidfire.com> wrote:
> >>>> >> 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>
> >>>> >> *™*
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *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>
*™*

Reply via email to