Pick up work from benji on hiding GUI charm

[Matthew Scott]

On 01/08/2013 07:53 PM, Gary Poster wrote:
> On 01/08/2013 09:10 PM, Matthew Scott wrote:
>> On 01/08/2013 03:51 PM, Gary Poster wrote:
>>> Hi all.  Benji had something important he had to deal with this
>>> afternoon for his family.  He has worked out a way that seems to work to
>>> address hiding the GUI charm in the GUI (bug 1090716).  The sketch,
>>> which hides haproxy rather than the GUI as a proof of concept, is here:
>>>
>>> http://paste.ubuntu.com/1510571/
>>>
>>> If anyone is available to bring it to completion, that would be cool.
>>>
>>> Necessary bits remaining that I know of:
>>> - verify solution
>>> - make a helper function that replaces all those one-off regexes
>>> - convert haproxy filtering to gui
>>> - at least a minimal test or two
>>>
>>> Thanks
>>>
>>> Gary
>>
>> I'd like clarification on a few things.  Ben and I brought up some
>> concerns as to this approach on IRC, but we were all busy and they
>> didn't quite resolve.
> 
> Thanks for bringing them up here, Matt.  I'll give my answers below. If
> you are concerned about any of them, I'll count on you (or others)
> discussing this further.
> 
>>
>> * In the past we've talked about hiding certain classes of services,
>>   not just juju-gui.  Does this still hold true?  If so, I suppose this
>>   is extensible to something beyond a regex on a magic string.  Should
>>   we/can we be forward-looking on this in one location, or has this
>>   been tabled?
> 
> I don't want to spend time on further abstracting this code until we
> actually want a related feature.  If we can have a clean simple change
> now that does what we want now, I vote for that.  Benji's approach looks
> like it can be made very simple and clean.
> 
> Moreover, a regex on a string, if it is abstracted into a single
> function, should be able to do the future hiding that I understand we
> might want (other juju-* things).  If not, we'll cross that bridge then.
> 
>> * This branch will also kill the /service/<hidden service>/ and all
>>   relations leading into <hidden service> too, correct?  
> 
> It kills them within the environment view.  I don't think we need more
> for our current use case of the juju-gui. If, for instance, haproxy were
> a front for the gui, that relation would be visible in the detail page,
> given the code we have so far.  Moreover, you'd be able to eventually
> find your way to an inner view of the service.  I think that's fine, at
> the moment.  It's also something we could improve incrementally from
> this position if we decided it were important.
> 
>> Or is the goal
>>   to prevent interaction with a verboten service only through the
>>   environment view?  
> 
> I think that's good enough for now, yes; see reply above.
> 
> As an aside, eventually I think we may want to be able to provide a
> control that hides and reveals the special, system-level charms like
> juju-gui.  Not now.
> 
>> If it's just the environment view, the current
>>   path should be fine (perhaps add the filter on the new
>>   updateServiceNodes as well, to prevent that work from being done on
>>   hidden nodes).
> 
> That sounds like a good idea.
> 
>> * Drawing within the DOM provides a lot of advantages for us, but a few
>>   disadvantages as well, in terms of speed and usability.  Cluttering
>>   up the DOM with hidden objects can still adversely affect usability
>>   (from a personal project:
>>   http://vis.adjectivespecies.com/microsurvey/2012/ draws hidden paths
>>   made visible when clicking the bars; profiling in Chrome places speed
>>   issues on the rendering engine rather than the JS).  I know that
>>   we've talked about thousands of units, but what's a good number of
>>   services for us to be aiming for in terms of usability, and would the
>>   potential number of hidden services be a draw on resources?
> 
> Kapil has given a ballpark of a maximum of 30 services at a time in the
> past, I believe.  The gui would only represent a single service, no
> matter how many units it represented. The iOS story may make me eat my
> words, but I don't think a single hidden service will take us down.
> 
>>
>> I think this is a fairly simple solution as it stands that would be a
>> good addition, but I just want to make sure that we don't have to
>> backtrack down the road in order to accommodate things we know about today.
> 
> Thanks, yes.
> 
> Backtracking later is OK if it is cheap, and it's even less of a worry
> if it's not clear that it will be necessary.  I think Benji's current
> approach is cheap and good for now and might also end up being a
> sufficient and reasonable path for what we need in the future.

I buy it, thanks for the clarifications.  I suppose I was under the
impression we needed to not have the service exposed at all, which had
me all sorts of worried.  This will do, and if we need to come back to
it later, we've got ideas to work from.  Thanks.

> 
> Do you buy it?
> 
> Gary
> 
>>
>> ~M
>>
>