=== Furao_ is now known as Furao === bradm_ is now known as bradm === TheMue_ is now known as TheMue === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [08:32] Hi [09:08] is there any pbs with charm store ? With every attempt, juju deploy says "Error processing 'cs:precise/glance': entry not found" [09:09] mrevell, hello [09:12] 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] 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] oarcher, i couldn't say offhand without checking each individually, but yes that prefix will work regardless. [09:17] I've got on error with the last: $juju deploy cs:~charmers/precise/rabbitmq-server give ERROR [09:18] 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] oarcher, intesting that is a bug [09:19] really odd [09:20] is it a bug from launchpad, or a bug from juju ? [09:20] * hazmat checks the charm [09:21] oarcher, imo its a juju bug, trying to identify the reason atm [09:21] oh.. the charm name doesn't match the charm name in its metadata [09:21] still seems odd [09:22] huh.. its still referencing ensemble: formula [09:22] 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] 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] 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] oarcher, ack.. that should be okay.. branch is bzr branch lp:charms/rabbitmq-server [09:27] there's automation around local dir/repo pulls with charm-tools pkg [09:27] ok, i've got the branch [09:27] i've pushed a fix upstream, but the charm store has a delay of 1m [09:27] er.. 15m [09:28] bedtime... back in 6h [09:28] You mean that the charm store wiil be up in 15m ? [09:28] oarcher, the change i just committed will be reflected in a new charm store packaging of that charm in 15m [09:29] ok, thanks. coffe time for me [12:18] * flepied is trying to experiment with subordinate charms without success :-( === matsubara-afk is now known as matsubara [12:34] flepied, I'm about as far from being an expert as I can be, but perhaps I can help? [12:35] fwereade_, is it supposed to work as documented ? or are there tricks to know ? [12:36] 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] flepied, what are you trying to do exactly? [12:37] just experimenting so nothing real. I took the example of rsyslog and trying to implement it [12:39] flepied, you never know: if you pastebin the config.yaml I *might* notice something [12:41] fwereade_, http://pastebin.com/iRgHXVCY [12:45] 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] 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] fwereade_, what is juju-info ? [12:47] flepied, it's an interface provided implicitly by all charms [12:47] flepied, https://juju.ubuntu.com/docs/drafts/implicit-relations.html [12:47] fwereade_, I had a requires previously for the remote rsyslog connection but I removed it to see if it was causing troubles [12:49] fwereade_, ok I'll try with juju-info [12:49] flepied, gl, let me know how it goes :) [12:58] fwereade_, still the same: it creates a real vm not a subordinates. perhaps it doesn't work in local (lxc) ? [13:00] flepied, hmm, sorry, I missed something else: you need "subordinate: true" at the top level [13:00] oh [13:01] flepied, scope:container is still meaningful for non-subordinates so they can communicate with subordinates [13:01] I didn't see this in the doc, sorry [13:01] 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] flepied, haha no worries, I didn't spot it in your charm ;p [13:02] flepied, and nor did I spot it while rereading the docs just now :) [13:02] I'll try it with it and tell you [13:02] flepied, we should probably have a subordinate example charm really [13:03] flepied, gl again :) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:33] flepied, any joy? === almaisan-away is now known as al-maisan [13:35] fwereade_, sorry I was in meeting, I try asap [13:35] flepied, np at all, no rush; just wanted to check you weren't silently cursing us ;p [13:37] fwereade_, much better now ! thx ! [13:37] flepied, awesome :D [13:38] flepied, a pleasure === al-maisan is now known as almaisan-away [15:08] 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] heya flepied [15:09] flepied, would you pastebin me the config please? [15:09] flepied, config*s* I guess ;) [15:11] fwereade_, http://pastebin.com/7k9nm6j1 [15:14] fwereade_, I wanted to remove line 14 but I have an error if I do it [15:14] flepied, hmm, would you pastebin me a transcript of what you deployed as well please? [15:15] fwereade_, you mean juju status output ? [15:15] flepeid, that would probably cover everything I need, yeah :) [15:17] fwereade_, http://pastebin.com/YMWRuYYD [15:18] in fact I don't want a subordinates between rsyslog-server and rsyslog-client and I get one... [15:18] flepied, yeah, it does look like it's all tied to line 14, what was the error? [15:22] fwereade_, labeled subordinate but lacking scope:container `requires` relation', [15:24] flepied, aha, yes, I think the provides/requires are the wrong way round [15:24] flepied, switch them in rsyslog-client and propagate the changes through the others [15:25] fwereade_, ok I try [15:25] fwereade_: yeah, we're working on that [15:26] m_3, awesome :) [15:26] 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] flepied, listen to this man, he knows more about writing charms than I ever will probably ;) [15:27] fwereade_, ok :) [15:27] fwereade_: dunno man... I'm thinking the opposite actually :) [15:28] m_3, I'm good at some things, but writing charms? I'd concede before we even started :) [15:28] 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] m_3, yes I understand, I just wanted to experiment [15:30] flepied: I'm looking for a good example of it running... I know clint's got a few [15:31] he's probably at the airport today though [15:31] m_3, don't worry that's not a big deal [15:31] just learning [15:31] flepied: me too! [15:33] 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] m_3: yes that's what I tried first but I got an error if I remove it [15:35] flepied: I found clint's versions... [15:35] https://code.launchpad.net/~clint-fewbar/charms/precise/rsyslog-forwarder/trunk [15:35] and [15:36] https://code.launchpad.net/~clint-fewbar/charms/precise/rsyslog/trunk [15:36] it's using the 'juju-info' sort of anonymous relation [15:37] rsyslog-forwarder's README shows usage [15:37] I think this is one of the first real subordinates anywhere in the repo... nothing in the store yet [15:39] m_3, there is no scope: container in the syslog relation. that's what I wanted to do [15:40] 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] rsyslog-server on a dedicated instance [15:41] I wanted to implement a central log server [15:42] flepied: ok, then I think that this setup should do that [15:42] yes I will try his files [15:44] 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] m_3: I don't understand the juju-info interface [15:44] err, relation [15:44] the scope:container relation is the "juju-info" one that's getting the rsyslog-forwarder talking to haproxy locally [15:45] 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] as far as I understand [15:46] 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] 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] as do I, I'd like to setup a wordpress site -> wordpress -> nginx subordinate chain thing soon [15:48] I gotta get the charmtester as jenkins-master talking to jenkins-slave with subordinate charmtester [15:50] 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] so, when you deploy...it doesn't actually do anything until you relate it? [15:51] marcoceppi, that's right [15:51] marcoceppi: I doubt any info goes over that relation... or that we can even hook against it [15:51] OH, there's this key in the metadata: subordinate: true [15:51] I was like OMG HOW DOES JUJU KNOW?!? [15:51] yuppers [15:52] 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] no deployment could happen till we knew where to put things and that comes from having a relation [15:53] m_3: like a juju deploy --subordinate=servicecurrentlydeployed rsyslog [15:53] bcsaller: thanks btw! very excited to read up and convert a bunch of stuff over to subs soon [15:53] marcoceppi: some variation yeah [15:53] m_3: :) [15:54] this way makes sense now, I was very confused earlier. However, what happens if subordinates need to communicate to their parent services? [15:54] m_3, his version works but I still don't understand why mine doesn't :-( [15:54] marcoceppi: dunno yet [15:54] marcoceppi: they can do that over the relation they establish (the container relation) or via a traditional relation [15:55] 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] so we can use juju-info then [15:55] but if they do, the relation works as normal [15:56] flepied: rsyslog-client's rsyslog-server interface doesn't make sense as container scope [15:56] exact [15:57] bcsaller: does it ever make sense to impl juju-info-relation-xxx hooks? [15:57] 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] bcsaller: nothing... that's why I was thinking juju-info wouldn't be hookable [15:59] 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] sometimes presence is enough [16:00] bcsaller: right [16:00] * m_3 still trying to come up with a clever term for the opposite of hookable [16:00] neutered? [16:00] incarcerated? [16:04] 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] 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] right [16:07] although bouncing apache is to lamp stacks as rebooting is to windows [16:07] fixes everything :) [16:07] magic even [16:13] hazmat: btw, rabbit's lp aliases are screwed up... been waiting for adam to finish with ods, then we'll fix them [16:15] What is ODS? [16:16] marcoceppi: something like openstack design(?) summit [16:16] Ah, gotchya [16:17] marcoceppi: big juju/maas demos... went reall well from what I heard [16:17] excellent! [16:21] m_3: the juju+maas demo went great, and so did charm school [16:21] I felt like we had a really interesting discussion in charm school about what juju does and why it is relevant. [16:31] SpamapS: awesome! [16:34] 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] network partitioned for a while so zk was timing out [16:38] SpamapS: yeah, I can totally feel when east-coast primetime starts just about every day [16:40] This was subtle. debug-log just stopped [16:40] SpamapS: hey, do you know of a way to remove the lp alias from a branch w/o deleting the whole branch? [16:40] m_3: no [16:40] m_3: thats the way, IIRC [16:40] * m_3 sad face [16:40] m_3: branch it, delete it, put it back [16:41] m_3: the LP API may have a way to unpromulgate [16:41] in fact we need that command [16:41] gotta fix the openstack branches [16:41] m_3: are they super messed up? [16:41] there're several stacked branches, so I can't delete willynilly [16:42] and it's sorta... um... rude :) [16:42] SpamapS: just note for next time that we gotta be more careful with existing dev branches when bumping series [16:43] SpamapS: oh, btw... I'm thinking two separate blueprints: juju-intelligent-infrastructure and juju-integration [16:44] m_3: hm? [16:44] for Q [16:44] you're putting out a juju-release-process or something equiv right? [16:59] m_3: yes, there's a charm store release process blueprint already [16:59] SpamapS: cool [17:01] let's hang monday and go over others we want? be thinking about it in the mean time [17:08] m_3: I think we should probably spark up the discussion on the mailing list first. [17:08] 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] SpamapS: sure... does it hurt to just submit blueprints? I assume they can be rejected or not approved without any hassle [17:16] 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] SpamapS: doh... sent already... I'll add them this afternoon [17:28] m_3: doesn't really matter what the sequence is :) [17:28] Just that we make sure we use the time at UDS wisely === almaisan-away is now known as al-maisan === koolhead11|away is now known as koolhead11 === Furao_ is now known as Furao === fenris is now known as Guest89753 === Guest89753 is now known as ejat === matsubara is now known as matsubara-lunch === al-maisan is now known as almaisan-away [18:56] is it normal for output from the hook to be labled as @ERROR ? http://paste.ubuntu.com/938714/ [19:00] jcastro: these Juju shirts are pretty darn cool [19:00] :D [19:05] jcastro: I got my t-shirt yesterday. Thanks! very cool [19:17] anyone around for a review? [19:19] https://bugs.launchpad.net/charms/+bug/985894 [19:19] <_mup_> Bug #985894: Charm needed: Shelr.tv < https://launchpad.net/bugs/985894 > === matsubara-lunch is now known as matsubara [20:01] marcoceppi: that is normal, yes... guess it's pumping to stderr for some reason. [20:01] think there's a bug for that... prob low priority tho [20:03] marcoceppi: bug #955209 [20:03] <_mup_> Bug #955209: charm.log uses 'Error' for all stderr messages < https://launchpad.net/bugs/955209 > [20:08] marcoceppi: got a dangling mongodb-relation-changed in addition to the db-relation-changed [20:18] marcoceppi: shelr.tv reviewed [20:30] m_3: what's a dangling mongodb-relation? [20:30] OH, you mean a file that doesn't need to be there [20:30] Also, in my experience in running locally, sudo was needed for about all the commands :\ [20:58] m_3: thanks for the review! [21:04] I'm guessing this is bad? http://paste.ubuntu.com/938872/ [21:04] Or does it take a while for a promulgated charm to appears in the cs? [21:06] marcoceppi: hmmm [21:06] ok, so there's a problem [21:06] the charm store is looking at precise now [21:06] I bet it's looking for .../precise/shelr.tv/trunk [21:07] so... try pushing explicitly to lp:~charmers/charms/oneiric/shelr.tv/trunk [21:07] marcoceppi: ^ [21:08] m_3: I've pushed to both <3 [21:08] http://code.launchpad.net/charms [21:09] I hope it's not the stupid . [21:11] marcoceppi: no, that looks good... so lp:charms/shelr.tv aliases to lp:~charmers/charms/precise/shelr.tv/trunk [21:11] and then lp:~charmers/charms/oneiric/shelr.tv/trunk is there [21:11] marcoceppi: so try a 'juju deploy cs:oneiric/shelr.tv' [21:12] 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] also consider trying 'bzr push lp:charms/oneiric/shelr.tv' [21:32] we may need a --series argument for charm promulgate [21:39] Does anyone know if a REST API is going to be used/developed/being developed for juju? [21:47] 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] spidersddd: I can get you a bug # to subscribe to ... [21:54] spidersddd: bug #804284 [21:54] <_mup_> Bug #804284: REST API for managing ensemble environments, aka expose cli as ensemble daemon < https://launchpad.net/bugs/804284 > [21:55] * SpamapS retitles... ensemble... [21:55] Man, we need to do that [21:55] we can get rid of the problem where you have to share environments.yaml [21:56] Just know the address of the juju server and off you go