On Thu, Sep 4, 2014 at 3:26 AM, John Meinel <[email protected]> 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.
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
