[08:32] <mrevell> Hi
[09:08] <oarcher> is there any pbs with charm store ? With every attempt, juju deploy says "Error processing 'cs:precise/glance': entry not found"
[09:09] <hazmat> mrevell, hello
[09:12] <hazmat> oarcher, it doesn't appear glance is 'blessed' in the 'official' charm namespace.. ie.. been through review... you can deploy it from the user/ppa namespace via juju deploy cs:~charmers/precise/glance
[09:15] <oarcher> thank's, hazmat . And is it true for all other charm cited here : https://help.ubuntu.com/community/UbuntuCloudInfrastructure  ? ( glance keystone nova-cloud-controller nova-compute nova-volume openstack-dashboard rabbitmq-server )
[09:16] <hazmat> oarcher, i couldn't say offhand without checking each individually, but yes that prefix will work regardless.
[09:17] <oarcher> I've got on error with the last:  $juju deploy cs:~charmers/precise/rabbitmq-server give ERROR
[09:18] <oarcher> What is strange is that lp give an error while trying to browse the code here: https://code.launchpad.net/~charmers/charms/precise/rabbitmq-server/trunk
[09:18] <hazmat> oarcher, intesting that is a bug
[09:19] <hazmat> really odd
[09:20] <oarcher> is it a bug from launchpad, or a bug from juju ?
[09:20]  * hazmat checks the charm
[09:21] <hazmat> oarcher, imo its a juju bug, trying to identify the reason atm
[09:21] <hazmat> oh.. the charm name doesn't match the charm name in its metadata
[09:21] <hazmat> still seems odd
[09:22] <hazmat> huh.. its still referencing ensemble: formula
[09:22] <hazmat> something is very wrong in denmark with this charm
[09:23] <_mup_> juju/rabbitmq-server r18 committed by kapil.thangavelu@canonical.com
[09:23] <_mup_> update metadata
[09:24] <hazmat> seems to work if its local in a dir but deploying from the charm store it looks like there is an additional sanity check
[09:26] <oarcher> seem to work in local, exept rabbitmq-server, because i c'ant get the branch. (So I've try with an old oneiric branch for rabbitmq)
[09:26] <hazmat> oarcher, ack.. that should be okay.. branch is bzr branch lp:charms/rabbitmq-server
[09:27] <hazmat> there's automation around local dir/repo pulls with charm-tools pkg
[09:27] <oarcher> ok, i've got the branch
[09:27] <hazmat> i've pushed a fix upstream, but the charm store has a delay of 1m
[09:27] <hazmat> er.. 15m
[09:28] <hazmat> bedtime... back in 6h
[09:28] <oarcher> You mean that the charm store wiil be up in 15m ?
[09:28] <hazmat> oarcher, the change i just committed will be reflected in a new charm store packaging of that charm in 15m
[09:29] <oarcher> ok, thanks. coffe time for me
[12:18]  * flepied is trying to experiment with subordinate charms without success :-(
[12:34] <fwereade_> flepied, I'm about as far from being an expert as I can be, but perhaps I can help?
[12:35] <flepied> fwereade_, is it supposed to work as documented ? or are there tricks to know ?
[12:36] <fwereade_> flepied, it *should* work as documented, but there's something that I recall being less obvious (about writing them) that I'm racking my brains about
[12:36] <fwereade_> flepied, what are you trying to do exactly?
[12:37] <flepied> just experimenting so nothing real. I took the example of rsyslog and trying to implement it
[12:39] <fwereade_> flepied, you never know: if you pastebin the config.yaml I *might* notice something
[12:41] <flepied> fwereade_, http://pastebin.com/iRgHXVCY
[12:45] <fwereade_> flepied, I think you need may need a "requires: juju-info" in there; and I'm not sure you want the provides: to be scope: container
[12:45] <fwereade_> flepied, on the basis that an rsyslog client will surely be providing the log data to an rsyslog-server somewhere, which is surely not in the same container
[12:46] <flepied> fwereade_, what is juju-info ?
[12:47] <fwereade_> flepied, it's an interface provided implicitly by all charms
[12:47] <fwereade_> flepied, https://juju.ubuntu.com/docs/drafts/implicit-relations.html
[12:47] <flepied> fwereade_, I had a requires previously for the remote rsyslog connection but I removed it to see if it was causing troubles
[12:49] <flepied> fwereade_, ok I'll try with juju-info
[12:49] <fwereade_> flepied, gl, let me know how it goes :)
[12:58] <flepied> fwereade_, still the same: it creates a real vm not a subordinates. perhaps it doesn't work in local (lxc) ?
[13:00] <fwereade_> flepied, hmm, sorry, I missed something else: you need "subordinate: true" at the top level
[13:00] <flepied> oh
[13:01] <fwereade_> flepied, scope:container is still meaningful for non-subordinates so they can communicate with subordinates
[13:01] <flepied> I didn't see this in the doc, sorry
[13:01] <fwereade_> flepied, for example, declaring a logging-directory interface (which is ofc only meaningful to something that can see the directory by virtue of being in the container)
[13:02] <fwereade_> flepied, haha no worries, I didn't spot it in your charm ;p
[13:02] <fwereade_> flepied, and nor did I spot it while rereading the docs just now :)
[13:02] <flepied> I'll try it with it and tell you
[13:02] <fwereade_> flepied, we should probably have a subordinate example charm really
[13:03] <fwereade_> flepied, gl again :)
[13:33] <fwereade_> flepied, any joy?
[13:35] <flepied> fwereade_, sorry I was in meeting, I try asap
[13:35] <fwereade_> flepied, np at all, no rush; just wanted to check you weren't silently cursing us ;p
[13:37] <flepied> fwereade_, much better now ! thx !
[13:37] <fwereade_> flepied, awesome :D
[13:38] <fwereade_> flepied, a pleasure
[15:08] <flepied> fwereade_, I have another pb now the subordinates got attached to the 2 sides while I want it to be attached only on one side. it makes my rsylog server sending logs to itself in a loop :-(
[15:09] <fwereade_> heya flepied
[15:09] <fwereade_> flepied, would you pastebin me the config please?
[15:09] <fwereade_> flepied, config*s* I guess ;)
[15:11] <flepied> fwereade_, http://pastebin.com/7k9nm6j1
[15:14] <flepied> fwereade_, I wanted to remove line 14 but I have an error if I do it
[15:14] <fwereade_> flepied, hmm, would you pastebin me a transcript of what you deployed as well please?
[15:15] <flepied> fwereade_, you mean juju status output ?
[15:15] <fwereade_> flepeid, that would probably cover everything I need, yeah :)
[15:17] <flepied> fwereade_, http://pastebin.com/YMWRuYYD
[15:18] <flepied> in fact I don't want a subordinates between rsyslog-server and rsyslog-client and I get one...
[15:18] <fwereade_> flepied, yeah, it does look like it's all tied to line 14, what was the error?
[15:22] <flepied> fwereade_, labeled subordinate but lacking scope:container `requires` relation',
[15:24] <fwereade_> flepied, aha, yes, I think the provides/requires are the wrong way round
[15:24] <fwereade_> flepied, switch them in rsyslog-client and propagate the changes through the others
[15:25] <flepied> fwereade_, ok I try
[15:25] <m_3> fwereade_: yeah, we're working on that
[15:26] <fwereade_> m_3, awesome :)
[15:26] <m_3> flepied: so looking at your metadata files, I'm seeing more explicit relations that I would expect just offhand
[15:26]  * m_3 checking out the raw charms
[15:27] <fwereade_> flepied, listen to this man, he knows more about writing charms than I ever will probably ;)
[15:27] <flepied> fwereade_, ok :)
[15:27] <m_3> fwereade_: dunno man... I'm thinking the opposite actually :)
[15:28] <fwereade_> m_3, I'm good at some things, but writing charms? I'd concede before we even started :)
[15:28] <m_3> flepied: one point of subordinates were that we didn't wanna specify _every_ possible subordinate relation in each charm (every charm in the repo would have logger, monitor, nfs-client, etc)
[15:29] <flepied> m_3, yes I understand, I just wanted to experiment
[15:30] <m_3> flepied: I'm looking for a good example of it running... I know clint's got a few
[15:31] <m_3> he's probably at the airport today though
[15:31] <flepied> m_3, don't worry that's not a big deal
[15:31] <flepied> just learning
[15:31] <m_3> flepied: me too!
[15:33] <m_3> flepied: perhaps remove 'logging' from haproxy as a start, then I'm wondering about the "container" scope in the rsyslog-client's syslog-server relation
[15:34] <flepied> m_3: yes that's what I tried first but I got an error if I remove it
[15:35] <m_3> flepied: I found clint's versions...
[15:35] <m_3> https://code.launchpad.net/~clint-fewbar/charms/precise/rsyslog-forwarder/trunk
[15:35] <m_3> and
[15:36] <m_3> https://code.launchpad.net/~clint-fewbar/charms/precise/rsyslog/trunk
[15:36] <m_3> it's using the 'juju-info' sort of anonymous relation
[15:37] <m_3> rsyslog-forwarder's README shows usage
[15:37] <m_3> I think this is one of the first real subordinates anywhere in the repo... nothing in the store yet
[15:39] <flepied> m_3, there is no scope: container in the syslog relation. that's what I wanted to do
[15:40] <m_3> flepied: so you want haproxy/rsyslog-client on one instance... then rsyslog-server also on the same instance or on a dedicated rsyslog-server instance?
[15:41] <flepied> rsyslog-server on a dedicated instance
[15:41] <flepied> I wanted to implement a central log server
[15:42] <m_3> flepied: ok, then I think that this setup should do that
[15:42] <flepied> yes I will try his files
[15:44] <m_3> the "aggregator" relation (using the "syslog" interface) is the rsyslog-forwarder talking to the rsyslog server on another machine... this is an ordinary juju relation
[15:44] <marcoceppi> m_3: I don't understand the juju-info interface
[15:44] <marcoceppi> err, relation
[15:44] <m_3> the scope:container relation is the "juju-info" one that's getting the rsyslog-forwarder talking to haproxy locally
[15:45] <m_3> marcoceppi: I haven't caught up on all the docs, but I think it's juju's version of an anonymous interface that's used when a subordinate is glommed onto a primary service
[15:45] <m_3> as far as I understand
[15:46] <marcoceppi> m_3: but how does the sub-ordinate know which service to attach to? it just does juju deploy "subordinate" from what I see
[15:47] <m_3> marcoceppi: I think there's only a single primary possible on a given service unit... then it talks 'juju-info' with any attached subordinates
[15:47]  * m_3 has gotta rtfm about it this weekend
[15:48] <marcoceppi> as do I, I'd like to setup a wordpress site -> wordpress -> nginx subordinate chain thing soon
[15:48] <m_3> I gotta get the charmtester as jenkins-master talking to jenkins-slave with subordinate charmtester
[15:50] <m_3> marcoceppi: pretty sure the thinking was that I just can't glom on subs to a primary... they've got to be _related_ as far as juju is concerned... juju-info is that "internal" relation
[15:50] <marcoceppi> so, when you deploy...it doesn't actually do anything until  you relate it?
[15:51] <fwereade_> marcoceppi, that's right
[15:51] <m_3> marcoceppi: I doubt any info goes over that relation... or that we can even hook against it
[15:51] <marcoceppi> OH, there's this key in the metadata: subordinate: true
[15:51] <marcoceppi> I was like OMG HOW DOES JUJU KNOW?!?
[15:51] <m_3> yuppers
[15:52] <m_3> marcoceppi: but I'm actually sad about that field... I really wanted to do something like a single "rsyslog" that'd just be either a standalone server or a forwarder depending on context
[15:52] <bcsaller> no deployment could happen till we knew where to put things and that comes from having a relation
[15:53] <marcoceppi> m_3: like a juju deploy --subordinate=servicecurrentlydeployed rsyslog
[15:53] <m_3> bcsaller: thanks btw!  very excited to read up and convert a bunch of stuff over to subs soon
[15:53] <m_3> marcoceppi: some variation yeah
[15:53] <bcsaller> m_3: :)
[15:54] <marcoceppi> this way makes sense now, I was very confused earlier. However, what happens if subordinates need to communicate to their parent services?
[15:54] <flepied> m_3, his version works but I still don't understand why mine doesn't :-(
[15:54] <m_3> marcoceppi: dunno yet
[15:54] <bcsaller> marcoceppi: they can do that over the relation they establish (the container relation) or via a traditional relation
[15:55] <bcsaller> marcoceppi: in many use cases the principal doesn't know about the subordinate and won't have anything special prepared to tell it
[15:55] <bcsaller> so we can use juju-info then
[15:55] <bcsaller> but if they do, the relation works as normal
[15:56] <m_3> flepied: rsyslog-client's rsyslog-server interface doesn't make sense as container scope
[15:56] <flepied> exact
[15:57] <m_3> bcsaller: does it ever make sense to impl juju-info-relation-xxx hooks?
[15:57] <bcsaller> m_3: what would go in them that a) isn't implicit in all interfaces already and b) wouldn't be better covered by a more specific interface?
[15:58] <m_3> bcsaller: nothing... that's why I was thinking juju-info wouldn't be hookable
[15:59] <bcsaller> m_3: logically maybe, but the subordinate could do things on its join side, just knowing its properly connected to the principal at that point
[15:59] <bcsaller> sometimes presence is enough
[16:00] <m_3> bcsaller: right
[16:00]  * m_3 still trying to come up with a clever term for the opposite of hookable
[16:00] <m_3> neutered?
[16:00] <m_3> incarcerated?
[16:04] <m_3> bcsaller: I could see a case where a primary would maybe be _super_ careful and do things like restart a service (like apache) every time any subordinate connected... but that's still a pretty out-there example I guess
[16:06] <bcsaller> yeah, some sub's might be related to things like the apache and others might be related to things like logging or other container related things.  I don't think you'd want to react blindly like that
[16:06] <m_3> right
[16:07] <m_3> although bouncing apache is to lamp stacks as rebooting is to windows
[16:07] <bcsaller> fixes everything :)
[16:07] <m_3> magic even
[16:13] <m_3> hazmat: btw, rabbit's lp aliases are screwed up... been waiting for adam to finish with ods, then we'll fix them
[16:15] <marcoceppi> What is ODS?
[16:16] <m_3> marcoceppi: something like openstack design(?) summit
[16:16] <marcoceppi> Ah, gotchya
[16:17] <m_3> marcoceppi: big juju/maas demos... went reall well from what I heard
[16:17] <marcoceppi> excellent!
[16:21] <SpamapS> m_3: the juju+maas demo went great, and so did charm school
[16:21] <SpamapS> I felt like we had a really interesting discussion in charm school about what juju does and why it is relevant.
[16:31] <m_3> SpamapS: awesome!
[16:34] <SpamapS> as usual.. a few things went wrong.. aws fail rate has been high in us-east-1 .. I think I'll start using us-west-2 all the time now
[16:34] <SpamapS> network partitioned for a while so zk was timing out
[16:38] <m_3> SpamapS: yeah, I can totally feel when east-coast primetime starts just about every day
[16:40] <SpamapS> This was subtle. debug-log just stopped
[16:40] <m_3> SpamapS: hey, do you know of a way to remove the lp alias from a branch w/o deleting the whole branch?
[16:40] <SpamapS> m_3: no
[16:40] <SpamapS> m_3: thats the way, IIRC
[16:40]  * m_3 sad face
[16:40] <SpamapS> m_3: branch it, delete it, put it back
[16:41] <SpamapS> m_3: the LP API may have a way to unpromulgate
[16:41] <SpamapS> in fact we need that command
[16:41] <m_3> gotta fix the openstack branches
[16:41] <SpamapS> m_3: are they super messed up?
[16:41] <m_3> there're several stacked branches, so I can't delete willynilly
[16:42] <m_3> and it's sorta... um... rude :)
[16:42] <m_3> SpamapS: just note for next time that we gotta be more careful with existing dev branches when bumping series
[16:43] <m_3> SpamapS: oh, btw... I'm thinking two separate blueprints: juju-intelligent-infrastructure and juju-integration
[16:44] <SpamapS> m_3: hm?
[16:44] <m_3> for Q
[16:44] <m_3> you're putting out a juju-release-process or something equiv right?
[16:59] <SpamapS> m_3: yes, there's a charm store release process blueprint already
[16:59] <m_3> SpamapS: cool
[17:01] <m_3> let's hang monday and go over others we want?  be thinking about it in the mean time
[17:08] <SpamapS> m_3: I think we should probably spark up the discussion on the mailing list first.
[17:08] <SpamapS> m_3: Lets get our positions in order so the face to face time is spent resolving the differences rather than articulating them.
[17:12] <m_3> SpamapS: sure... does it hurt to just submit blueprints?  I assume they can be rejected or not approved without any hassle
[17:16] <SpamapS> m_3: its fine, in fact its a good idea to submit it, then send a link to the list to invite discussion
[17:19] <m_3> SpamapS: doh... sent already... I'll add them this afternoon
[17:28] <SpamapS> m_3: doesn't really matter what the sequence is :)
[17:28] <SpamapS> Just that we make sure we use the time at UDS wisely
[18:56] <marcoceppi> is it normal for output from the hook to be labled as @ERROR ? http://paste.ubuntu.com/938714/
[19:00] <bkerensa> jcastro: these Juju shirts are pretty darn cool
[19:00] <bkerensa> :D
[19:05] <ninjix> jcastro: I got my t-shirt yesterday. Thanks! very cool
[19:17] <marcoceppi> anyone around for a review?
[19:19] <marcoceppi> https://bugs.launchpad.net/charms/+bug/985894
[19:19] <_mup_> Bug #985894: Charm needed: Shelr.tv <new-charm> <Juju Charms Collection:Fix Committed by marcoceppi> < https://launchpad.net/bugs/985894 >
[20:01] <m_3> marcoceppi: that is normal, yes... guess it's pumping to stderr for some reason.
[20:01] <m_3> think there's a bug for that... prob low priority tho
[20:03] <m_3> marcoceppi: bug #955209
[20:03] <_mup_> Bug #955209: charm.log uses 'Error' for all stderr messages <juju:Confirmed> < https://launchpad.net/bugs/955209 >
[20:08] <m_3> marcoceppi: got a dangling mongodb-relation-changed in addition to the db-relation-changed
[20:18] <m_3> marcoceppi: shelr.tv reviewed
[20:30] <marcoceppi> m_3: what's a dangling mongodb-relation?
[20:30] <marcoceppi> OH, you mean a file that doesn't need to be there
[20:30] <marcoceppi> Also, in my experience in running locally, sudo was needed for about all the commands :\
[20:58] <marcoceppi> m_3: thanks for the review!
[21:04] <marcoceppi> I'm guessing this is bad? http://paste.ubuntu.com/938872/
[21:04] <marcoceppi> Or does it take a while for a promulgated charm to appears in the cs?
[21:06] <m_3> marcoceppi: hmmm
[21:06] <m_3> ok, so there's a problem
[21:06] <m_3> the charm store is looking at precise now
[21:06] <m_3> I bet it's looking for .../precise/shelr.tv/trunk
[21:07] <m_3> so... try pushing explicitly to lp:~charmers/charms/oneiric/shelr.tv/trunk
[21:07] <m_3> marcoceppi: ^
[21:08] <marcoceppi> m_3: I've pushed to both <3
[21:08] <marcoceppi> http://code.launchpad.net/charms
[21:09] <marcoceppi> I hope it's not the stupid .
[21:11] <m_3> marcoceppi: no, that looks good... so lp:charms/shelr.tv aliases to lp:~charmers/charms/precise/shelr.tv/trunk
[21:11] <m_3> and then lp:~charmers/charms/oneiric/shelr.tv/trunk is there
[21:11] <m_3> marcoceppi: so try a 'juju deploy cs:oneiric/shelr.tv'
[21:12] <m_3> once we verify that works, then it's time to test out the precise version on precise since it's already in the precise store
[21:31] <SpamapS> also consider trying 'bzr push lp:charms/oneiric/shelr.tv'
[21:32] <SpamapS> we may need a --series argument for charm promulgate
[21:39] <spidersddd> Does anyone know if a REST API is going to be used/developed/being developed for juju?
[21:47] <m_3> spidersddd: it's been proposed... don't know when it's slated to be developed.  We'll know more after the Ubuntu Developer Summit in two weeks (where we plan out what'll be in 12.10)
[21:54] <SpamapS> spidersddd: I can get you a bug # to subscribe to ...
[21:54] <SpamapS> spidersddd: bug #804284
[21:54] <_mup_> Bug #804284: REST API for managing ensemble environments, aka expose cli as ensemble daemon <juju:Confirmed> < https://launchpad.net/bugs/804284 >
[21:55]  * SpamapS retitles... ensemble...
[21:55] <SpamapS> Man, we need to do that
[21:55] <SpamapS> we can get rid of the problem where you have to share environments.yaml
[21:56] <SpamapS> Just know the address of the juju server and off you go