A beginner's adventure in Charm authoring

[Nate Finch]

On Thu, Sep 4, 2014 at 3:26 AM, John Meinel <john at arbash-meinel.com> wrote:

> ...
>>
>
>
>> Have I mentioned how much I hate YAML?  Is it possible to write the
>> config in JSON or something instead?  JSON's no picnic either, but at least
>> it doesn't care about white space.  I'd recommend TOML, but I doubt the
>> conservative dev-ops people would go for it.  Ideally we'd support all
>> three (and other formats if people wanted).
>>
>
> Well, you can trivially write it in whatever you want and just have it
> converted, right? I do feel like YAML would be more human friendly except
> it has so many caveats and different ways to do the same thing.
>

YAML is very easy to read, but *writing* it is a hassle.  And for
configuration files, the writing is the most important part.  And yes, it's
trivial to support multiple formats for the config file, we just have to
agree it's a good idea and do it :)


>
>> The docs on hook tools
>> <https://juju.ubuntu.com/docs/authors-hook-environment.html#hook-tools> is
>> missing one very important piece of information:  "hook tools are
>> executables that exist in the $PATH on the machine where the unit is
>> deployed" ... it took me a while to understand that these were actual
>> executables I could run from my hook's code and not like functions or
>> something from somewhere (where?).
>>
>> We should document where the charm files are actually deployed on disk.
>>  I ended up figuring this out from one of the screenshots of charm
>> debugging which had the path shown, but there were times when I just wanted
>> to ssh into the machine and make sure the charm was deploying the stuff I
>> thought it was deploying.
>>
>
> 'juju run --unit=charm/0 bash -i` also gets you where you want to be,
> doesn't it? And it sets the environment variables you wanted.
>

That's not exactly obvious for newbie charmers.  Just having documentation
that says "your charm will be in X directory" is pretty good.  Having a
shortcut for your above command would be nice... maybe a flag on juju ssh
or something.


> Why does the config file for juju-deploy --config need to have
>> servicename:  at the beginning of the file?  Of course it's for that
>> servicename, that's why I gave it to this deploy command.  If there's no
>> top-level value, just assume the whole thing is for this service.  This
>> took me a while to figure out... I sort of assumed the config file was just
>> an easy shorthand so I didn't have to type a bunch of stuff out on the
>> command line.
>>
>
> Its so you can have 1 config file with the configuration for multiple
> services, and Juju will pick the one you want at the time you want it. So
> you have an "everything.conf" and we grab the service you specified each
> time.
> At one point that got changed (early in the go-juju lifetime), and got
> changed back not the least for compatibility with pyjuju.
> I can certainly see the advantage of both.
>

Compatibility with pyjuju seems somewhat less than useful at this point.

I agree, supporting both is great.  That seems possible, we just have to be
a little bit smart about reading the config file.


>
>> It's really annoying to have to type the unit name for debug-hooks,
>> rather than just the service.  I don't care what unit, they're all the
>> same, right?  And if there's just one (which is most of the time when
>> you're debugging), me telling you which unit is spurious anyway... just go
>> to the only one that exists.  Also, juju debug-hooks says you're supposed
>> to give it the hook name, but it doesn't seem like that actually does
>> anything.  I can leave it off and it seems to have the exact same behavior.
>>
>>
>
> I thought if you leave it off it debugs *all* hooks and not just the one.
> So if you do "juju debug-hooks unit/0" it will pause on install and started
> and config-changed, etc.
> If you do "juju debug-hooks config-changed" then it won't break for any of
> the other hooks.
>

Ahh, ok, that makes sense.  The docs could be better about explaining that.
 Mostly, I just don't want to have to type extraneous information in some
arcane format when there's only one possible right thing to do.


>> Install is actually the hardest hook, because you can't start "juju
> debug-hooks" until you have the unit, but by that time install has already
> been run. I believe there is an open bug about this, I'm not sure what the
> result is.
>

I actually got that part, the problem is that debug-hooks just connects you
to the machine, and you have to run resolved --retry again from another
window while you're connected to re-trigger it.  You actually have to do
that for any hook.  I just expected debug-hooks to do that for me.


> "juju resolved --retry" is just bad and the current goal is to replace it
> with "juju retry".
>

Awesome.


> I believe there has also been a charmers request to be able to trigger a
> "juju retry" from within the debug-hooks session.
>

That would be ideal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140904/2d42f8f2/attachment.html>