[04:37] <hazmat> Sander^home, not at the moment
[04:38] <hazmat> Sander^home, the future notion is that you could preconfigure a whole set of services and relations as blueprint/stack and reuse that.
[12:41] <mariusko> Hi
[12:41] <mariusko> I have a problem with new machines staying in pending state forever (>1 day)
[12:41] <mariusko> 35: instance-id: pending
[12:42] <mariusko> The are new units to existing services
[12:42] <mariusko> They
[12:43] <melmoth> loooks like juju cannot create new vm. if you are using openstack as a backend, do check you can start new vm with nova.
[12:46] <mariusko> melmoth: it is aws
[12:47] <mariusko> I don't see the pending instances in their admin console
[12:50] <melmoth> i never used aws, but it looks like juju was not able to start a new vm.
[12:50] <melmoth> you mayt want to try to fire up a new vm manually, just to check it works, and may be use --verbose with juju, to spot error ?
[12:53] <mariusko> how do I do that? And is there somewhere I can get logs? In node 0?
[12:58] <melmoth> not sure how you do that on aws. for the logs, i use --verbose, i m not sure where to look on node 0
[13:08] <mariusko> "--verbose add-unit" gave no interesting information. The process probably happens asyncronly
[13:08] <mariusko> juju debug-log neither
[14:17] <mariusko> melmoth: hmm, now I see the problem probably. Machine 0 has: "agent-state: not-started"
[14:17] <mariusko> Then not possible to SSH into, so I guess I need to force a restart of it
[14:38] <jcastro> I've got some open questions with bounties if someone is looking to help out: http://askubuntu.com/questions/267409/could-not-internally-obtain-zookeeper-handle
[14:38] <jcastro> http://askubuntu.com/questions/267689/agent-state-pending-in-juju-node-null-public-address-associated
[14:50] <jcastro> marcoceppi: hah, new gitlab release
[14:50] <jcastro> didn't juan just promulgate your older one?
[14:58] <marcoceppi> jcastro, no someone else took it over
[14:58] <marcoceppi> They're releasing once a month now, and this new release completely drops gitolite as a dependency
[15:01] <jcastro> gotcha
[16:14] <_mup_> Bug #1158841 was filed: fails to notice (or retry) if there's an error connecting to launchpad <canonical-webops> <juju:New> < https://launchpad.net/bugs/1158841 >
[16:31] <mariusko> What to do about persistent "agent-state: not-started" on the master machine?
[17:29] <AskUbuntu> How to add Landscape monitoring to machine 0 in juju | http://askubuntu.com/q/271298
[18:09] <SpamapS> FYI, juju was just removed from Debian testing because of this FTBFS bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702791
[18:11] <SpamapS> IMO thats probably a good thing.. you don't want Debian users to be finding such an old'n busted juju for the next 2+ years
[18:18] <jcastro> I agree, I prefer to try again with 2.0
[18:19] <AskUbuntu> What to do when Juju machine 0 has got "agent-state: not-started" state | http://askubuntu.com/q/271312
[18:19] <mariusko> Ideas about the above question? My environment is completely broken now :/
[18:21] <jcastro> yeah, I think when the head node goes boom ...
[18:21] <mariusko> Then you are lost?
[18:21] <mariusko> Recreate environment is the only solution?
[18:21] <mariusko> That must absolutely not happen if Juju is going to be ready for production use
[18:22] <jcastro> yea, it's on the list to fix, as of now, the bootstrap node is not HA. :-/
[18:22] <jcastro> there may be a way to recover it though
[18:22] <jcastro> hazmat: ideas?
[18:23] <mariusko> Ssh to its IP works, but the SSH key is wrong
[18:23] <mariusko> I'm not sure which ssh key "juju ssh" uses
[18:23] <SpamapS> jcastro: his head node isn't boom
[18:23] <hazmat> SpamapS, 0.5.1 ouch..
[18:23] <SpamapS> its working fine
[18:23] <SpamapS> the machine agent just didn't start
[18:23] <SpamapS> or died
[18:23] <SpamapS> hazmat: I know
[18:23] <SpamapS> hazmat: thats how Debian rolls
[18:24] <jcastro> SpamapS: oh awesome, maybe we can recover
[18:24] <SpamapS> tho, experimental still just has 0.6 :-P
[18:24]  * SpamapS would love it if an actual juju user wanted to join the effort to maintain in Debian... :)
[18:26] <jcastro> needs to support debian as a launched OS for people to care
[18:27] <SpamapS> Juju really should get out of the game of defining everything needed to run its agent
[18:27] <SpamapS> thats why Heat is more useful to me.
[18:28] <SpamapS> the agents needed in heat are like.. 200 lines of python.
[18:28] <SpamapS> and you can emulate them w/ curl calls
[18:28]  * SpamapS lunches
[19:07] <jcastro> koolhead17: ask.openstack.org looks great dude!
[19:08] <koolhead17> jcastro, we made it finally
[19:08] <koolhead17> :D
[19:09] <koolhead17> jcastro, can we RT it from our ubuntu cloud handle :P
[19:09] <jcastro> yeah
[19:09] <jcastro> link me to your announcement please!
[19:09] <koolhead17> Am one of the mods there & would love if we get some of our hackers there
[19:09] <koolhead17> https://twitter.com/koolhead17/status/315177524005048320
[19:11] <jcastro> got it
[19:15] <koolhead17> jcastro, can we make an  internal announcement to in our list?
[19:16] <jcastro> the ubuntu server list? sure, why not!
[19:17] <koolhead17> jcastro, shoot it then. we need our folks in there too :P
[19:49] <koolhead17> jcastro, will you be at OS summit?
[19:49] <jcastro> yep
[21:18] <Catbuntu> jcastro :3
[21:33] <sarnold> https://juju.ubuntu.com/docs/subordinate-services.html#usage
[21:34] <sarnold> what happens at the "juju deploy rsyslog" point?
[21:39] <m_3> sarnold: not much... charm is looked up, validated, cached in bootstrap node... sort of "staged"... but nothing's deployed on any service units until relation-time
[21:39] <sarnold> m_3: cool, thanks :)
[21:39] <m_3> sarnold: /me wants to see that `juju deploy rsyslog --with <primary-service>`
[21:40] <m_3> sarnold: but bigger fish atm
[21:41] <sarnold> m_3: would that deploy the primary with the rsyslog already in place? or deploy the primary and then rsyslog?
[21:41] <m_3> sarnold: desired workflow for me would be `juju deploy primary && juju deploy sub --with primary`
[21:42] <sarnold> m_3: aha
[21:42] <m_3> sarnold: but either way would work... just want fewer no-op steps
[21:42] <m_3> aternatlively: `juju deploy primary --with sub1,sub2,sub3`
[21:42] <m_3> but I prefer the former
[21:42] <m_3> makes it easier to split concerns between primaries and "aspects"
[21:43] <sarnold> it's funny you mention that, I keep thinking of the (little) I've read about aspect-oriented programming every time I re-pick-up the juju documentation..
[21:44] <m_3> sarnold: yeah, the paradigm really fits with infrastructure
[21:44] <m_3> peeps focus on primary infra
[21:44] <m_3> but there's a _lot_ of work on aspects that cut across all primaries
[21:45] <m_3> backups, log aggregation, authentication, etc
[21:45] <sarnold> heh, I was just going to ask about backups, logging, updating, audit logs..
[21:45] <sarnold> firewalling? apparmor etc MAC configs?
[21:45] <m_3> sarnold: also comes up a lot in thinking about the gui... how to cull and/or slice and dice your live whiteboard of your infra
[21:46] <sarnold> m_3: ooof
[21:46] <m_3> :)
[21:46] <sarnold> m_3: I'm sure there's something beautiful there to show the layers of aspects on each service .. just good luck finding it :D
[21:46] <m_3> haha
[21:46] <m_3> yeah
[21:46] <m_3> but worth poking at over time
[21:48] <m_3> sarnold: it's interesting to consider how this concept of aspects fits into integrating juju with existing config mgmt tools
[21:48] <m_3> i.e., audit logs managed by puppet living together (orthogonally) in a juju-based infrastructure
[21:49] <m_3> but that's still open (and hard)
[21:52] <m_3> might be the only practical integration story though
[21:53] <sarnold> it mght  be the inevitable destination, but my instincts suggest it'll be herculean task to get it right
[21:53] <m_3> ack
[22:09] <AskUbuntu> openstack-dashboard login | http://askubuntu.com/q/271382
[22:53] <sarnold> there's a missing bullet point for "symlinks must be self contained within a charm" here https://juju.ubuntu.com/docs/policy.html