[PLUG-AV] Questions about last night

[Leon Wright]

Hi Harry,

Interesting thoughts. My only concern regarding the networking is that we
should keep things nice and simple, doing routing and all those sort of
things on the master makes things complicated and difficult to
troubleshoot. The person on that station has their hands full as it is
without worrying about the network. We should decide if the 4G network will
work for us (also affordable for PLUG) and use a hardware box to do the
routing or do our best with what's available on premises. Until the issues
at the Hyatt, networking hasn't really been much of an issue as the wired
network at space cubed "Just Works". Cables across the floor aren't ideal,
but unless there are free ports we know good, that's what we should stick
with.

As for puppet, that's an awful lot of work and infrastructure to address an
issue in the stack that doesn't really exist. Most of our issues revolve
around no longer developed software that is being rewritten (but not even
close to complete from my understanding) and a connectivity standard that's
being phased out. This is where we need to focus our efforts for LCA.

Our focus for the monthly meetings should be as you've noted getting solid
kits together. Network Kit, Audio kit, Mixer kit, slave kits etc. Our speed
of setup is usually greatly hampered by a missing key item or hunting
through half a dozen boxes looking for an camera/adaptor/cable that is
missing from whatever we're trying to setup.

Leon

--
DRM 'manages access' in the same way that jail 'manages freedom.'

# cat /dev/mem | strings | grep -i cats
Damn, my RAM is full of cats... MEOW!!


On Wed, Oct 9, 2013 at 9:56 AM, Harry McNally <
harrymc at decisions-and-designs.com.au> wrote:

> Hello AV list
>
> Nick gave an overview of the outcomes of the WAIA broadcast and I'm going
> to pre-empt him this time and explain my confusion about the setup last
> night.
>
> When Nick and I looked at the systems on Monday evening (UCC) I'd asked
> whether the network issues could be avoided by running an entirely separate
> (electrically isolated) local network for the AV system with a separate
> network connection to the interwebs so any disruption to internet broadcast
> did not impact on the rest of the local network; recording and
> communication could continue if uncontrolled network connections failed.
> I'd considered that the Puppet talk was the next test of what we were
> heading to for LCA.
>
> Some work was done to confirm this was possible and Network Manager on the
> master and one camera slave was setup (with wireless initially) to confirm
> that NM was capable of this local network configuration. The plan was to
> move to ethernet local network and run that isolated system at the Puppet
> talk. I intended to get down and help Nick with that setup but got there
> late.
>
> Here's how my brain (slowly) worked with the preconception of an isolated
> local network as I attempted to assist.
>
> The decision to use the Spacecubed network was on the basis that "PLUG put
> it in and we know that it works". Unfortunately this assumption was an
> important experience from the POV of the LCA implementation that is very
> near.
>
> AV = many other decision making voices
>
> AV: "We don't want to have cables across the floor, just use the wall
> ports"
>
> Me: "Hm. Ok so we can adjust patch cables on a panel somewhere to make our
> network ... ?"
>
> AV: "No. We know this network works we don't need anything special here"
>
> Me: <looks for wall ports and finds them fully occupied>
>
> AV: "I think we can disconnect this black cable"
>
> <Spacedcubed loses it's SIP phone for a while until we agree it's probably
> best to restore the cable ...>
>
> AV: "This other cable goes to this access point"
>
> Me: "Well, I'm not sure we can disconnect the wireless either ..."
>
> AV: "It's ok there is a daisy-chain connection on the AP. Everything has
> this these days. We'll just connect to that"
>
> Me: <thinks now> Oh. I'm really am behind the times but I don't understand
> how that is going to transparently manage our isolated traffic. I'm out of
> my depth here.
>
> Further guidance meant the other camera went avslave->1GB switch->some
> office wireless router (of completely unknown config)->wall
> port->spacecubed switch (somewhere)->wall port->another switch of our own
> in the directors room->avmaster ...
>
> My pondering of this later was that the network was installed (and like
> other homilies) "network use expands to consume all wall ports (and then
> people start adding their own switches for expansion ...)". I don't agree
> that the network was in a state that was predictable and I also roundly
> condemn everyone for not being able to read either Nick's or my mind and
> know what was expected (dammit)! ;-p <- Despite this emoticon, this was
> serious deficiency on my part of not articulating the decision we had made
> in isolation which other AV people needed to either accept/reject but at
> least understand what we were trying to achieve.
>
> My observation and tentative suggestion is that at LCA/UWA if internal
> wiring is to be used (or cable runs added as needed) there will/may be wall
> ports that AV needed dedicated access to. There will/may be ports on patch
> panels that will/may need patch cables marked as part of the LCA AV network
> and rooms secured to prevent changes to those patches. There will/may be
> switches and routers that form part of the LCA network that AV may be
> required to pass traffic through. I'm assuming too that this woring must
> co-exist alonside UWA network and that they will be required to have
> isolation. There is much to do.
>
> In addition, Luke Williams talk was prescient because I wonder if the
> configuration of these systems might be better managed with Puppet rather
> than imaging so they can be trimmed down from stock Ubuntu and any network
> failover config setup is well defined and reproducable. I'd made this
> suggestion to Jason last night and that perhaps Luke could provide some
> input. It was an off the cuff email comment but I think more than ever this
> morning that it is worth consideration.
>
> Either way, I was happy to volunteer to assist with LCA AV but I am
> completely out of my depth with the performance and security that the
> networks and AV will require. I'm also happy to take instructions from an
> AV  director (including get out of the way!) and there will be others too
> who can help but (I think) we will just flap around helplessly if the
> systems are not robust.
>
> Last night felt to me like a wake up call that some quiet urgency for
> acquiring components and adding to AV robustness prior to curtain call
> LCA2014. It is easy for me to say than contribute expertise so I apologise
> if I'm actually asking others for more.
>
> My suggestion for enforcing documented equipment management into single
> "packages" or kits is a heartfelt one (sorry that is seems naff Luke). The
> equipment needs to be deployed with as much precision as you can muster and
> things going astray (as they have already) is a very simple and avoidable
> failure risk on the day.
>
> More than my 2c
> Harry
> ______________________________**_________________
> AV mailing list
> AV at plug.org.au
> http://lists.plug.org.au/**mailman/listinfo/av<http://lists.plug.org.au/mailman/listinfo/av>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/av/attachments/20131013/0689e129/attachment.html>