=== thumper-gym is now known as thumper-hacking
=== thumper-hacking is now known as thumper
=== _mup__ is now known as _mup_
[06:01] <ehw> hey, stokes, you awake?
[06:01] <ehw> doh
=== axw_ is now known as axw
[07:53] <mramm> anybody about?
[07:54] <wallyworld_> mramm: hi
[07:54] <mramm> I wanted to bounce some HA ideas off of folks
[07:54] <axw> I'm here.. haven't been looking at HA tho
[07:54] <mramm> that mailing list thread seems to like a lot of heat
[07:54] <mramm> I'm just trying to think about how we spell it for users
[07:55] <mramm> not about how we implement it ;)
[07:55] <wallyworld_> i think there's 2 common ideas - the ensure-has thing and the concept of juju services - db, api etc
[07:56] <wallyworld_> seems the juju add-unit juju:db thing is popular
[07:56] <wallyworld_> and fits with how people like to think about it
[07:58] <TheMue> imho an important part of the story is to tell the user, that we talk about juju ha, not of ha for their services
[07:58] <TheMue> those are two different stories
[07:58] <mramm> wallyworld_: I think that is sort of complicate to call these things units
[07:58] <TheMue> morning btw
[07:58] <mramm> they will be special units
[07:59] <mramm> there aren't charms for them
[07:59] <mramm> they can't have subordinates
[07:59] <mramm> they don't have hooks
[07:59] <mramm> removing them kills everything
[07:59] <TheMue> mramm: exact. they may share the same base technology, but the semantics is a different one
[08:00] <wallyworld_> true. i think folks liked to think of the juju:services in terms of units that could be added to
[08:00]  * TheMue prefers a number of ha-... commands
[08:00] <axw> sorry mramm missed your hangout thing - want to take it there, or keep chatting here?
[08:00] <wallyworld_> so the add-unit paradigm could be used
[08:00] <mramm> I'm all for spelling it add-unit juju:db someday -- but starting out that way is crazy
[08:01] <mramm> wallyworld_: I like that idea too
[08:01] <mramm> though I think we have a good way to go before we get there
[08:01] <wallyworld_> yeah
[08:01] <wallyworld_> i also like the ensure-ha idea to set up a ha scenario
[08:01] <mramm> so what do we do in the short term that still makes sense in the long term?
[08:01] <TheMue> wallyworld_: +1
[08:01] <wallyworld_> and then use add-unit <service> to maintain it
[08:02] <TheMue> mramm: the underlying logic and the command interface to the user are different things
[08:02] <wallyworld_> my opinion is do ensure-ha N where N >=3 to set up a workale ha scenario
[08:02] <mramm> TheMue: right
[08:02] <TheMue> mramm: imho the enable-ha still can use the idea of core units
[08:02] <wallyworld_> then add stuff to allow users to add to the initial set up
[08:02] <TheMue> eh, services
[08:02] <mramm> we don't have "units"
[08:03] <mramm> and making state server stuff into units is complicated
[08:03] <mramm> and by that I mean enabling them to act like units to users
[08:03] <mramm> anyway, if anybody wants to chat about this via voice: https://plus.google.com/hangouts/_/76cpimd6r4dqrb52sh0b8h3jg0?hl=en
[08:07] <rogpeppe> mornin' all
[08:32] <noodles775> Anyone around able to look at a charm-helpers MP (some ansible support): https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
[09:37] <mramm> so the result of the google hangout was that I sent an e-mail, and while I'm not 100% sure we've got the exact spelling of everything worked out we agreed on a proposed command line syntax for HA
[09:37] <mramm> (those in the meeting already know, and those not in the meeting can see the results in the juju-dev mailing list)
[10:42] <wallyworld_> mgz: wallyword + friday evening  + alcohol = no standup
[10:43] <wallyworld_> + 2 women also
[10:44] <dimitern> :) \o/
[10:48] <dimitern> mgz, rogpeppe, TheMue: standup?
[10:51] <dimitern> mgz, ping
[11:48] <TheMue> tschakka, first try already looks better
[11:57]  * TheMue => lunch
=== andreas__ is now known as ahasenack
=== gary_poster|away is now known as gary_poster
[14:33] <rogpeppe> lunch
[18:04] <rogpeppe> i'm done. happy weekends all.
[19:44] <ahasenack> hi, does someone know of the top of his/her head how juju gets the private-address value?
[19:44] <ahasenack> is it something like "hostname -f"?
[19:56] <natefinch> ahasenack: it's different per provider, but mostly it comes from provider metadata
[19:57] <ahasenack> natefinch: in the case of maas, do you know? I'm going over the code, but kind of getting lost
[19:57] <ahasenack> I found this
[19:57] <ahasenack> func (info *machineInfo) load() error {
[19:57] <ahasenack>     return utils.ReadYaml(_MAASInstanceFilename, info)
[19:57] <ahasenack> }
[19:57] <ahasenack> and now I'm chasing down that that instance filename is
[19:58] <natefinch> ahasenack: you're a few "go to definition" clicks ahead of me, looks like
[19:59] <ahasenack> there is provider/maas/environprovider.go
[19:59] <ahasenack> where I found func (maasEnvironProvider) hostname() (string, error) {
[19:59] <ahasenack>     info := machineInfo{}
[19:59] <ahasenack>     return info.Hostname, nil
[19:59] <ahasenack> looks like I want that info.Hostname bit
[19:59] <natefinch> ahasenack: yeah, I  got there.  I see this:
[19:59] <natefinch> var _MAASInstanceFilename = environs.DataDir + "/MAASmachine.txt"
[20:00] <natefinch> so, /var/lib/juju/MAASmachine.txt
[20:00] <ahasenack> where, on the unit?
[20:00] <ahasenack> presto!
[20:00] <ahasenack> root@k8q9m:/var/lib/juju# cat MAASmachine.txt
[20:00] <ahasenack> hostname: k8q9m.maaslocal
[20:00] <ahasenack> natefinch: thanks :)
[20:00] <ahasenack> now, what populates that, the provider?
[20:02] <natefinch> ahasenack: trying to figure that out
[20:05] <natefinch> ahasenack: yeah, it looks like it gets it during StartInstance
[20:05] <natefinch> ahasenack:  mi.maasObject.GetField("hostname")