| === 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 | ||
| mrevell | Hi | 08:32 |
|---|---|---|
| oarcher | is there any pbs with charm store ? With every attempt, juju deploy says "Error processing 'cs:precise/glance': entry not found" | 09:08 |
| hazmat | mrevell, hello | 09:09 |
| 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:12 |
| 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:15 |
| hazmat | oarcher, i couldn't say offhand without checking each individually, but yes that prefix will work regardless. | 09:16 |
| oarcher | I've got on error with the last: $juju deploy cs:~charmers/precise/rabbitmq-server give ERROR | 09:17 |
| 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:18 |
| hazmat | really odd | 09:19 |
| oarcher | is it a bug from launchpad, or a bug from juju ? | 09:20 |
| * hazmat checks the charm | 09:20 | |
| 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:21 |
| hazmat | huh.. its still referencing ensemble: formula | 09:22 |
| hazmat | something is very wrong in denmark with this charm | 09:22 |
| _mup_ | juju/rabbitmq-server r18 committed by kapil.thangavelu@canonical.com | 09:23 |
| _mup_ | update metadata | 09:23 |
| 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:24 |
| 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:26 |
| 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:27 |
| 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:28 |
| oarcher | ok, thanks. coffe time for me | 09:29 |
| * flepied is trying to experiment with subordinate charms without success :-( | 12:18 | |
| === matsubara-afk is now known as matsubara | ||
| fwereade_ | flepied, I'm about as far from being an expert as I can be, but perhaps I can help? | 12:34 |
| flepied | fwereade_, is it supposed to work as documented ? or are there tricks to know ? | 12:35 |
| 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:36 |
| flepied | just experimenting so nothing real. I took the example of rsyslog and trying to implement it | 12:37 |
| fwereade_ | flepied, you never know: if you pastebin the config.yaml I *might* notice something | 12:39 |
| flepied | fwereade_, http://pastebin.com/iRgHXVCY | 12:41 |
| 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:45 |
| flepied | fwereade_, what is juju-info ? | 12:46 |
| 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:47 |
| flepied | fwereade_, ok I'll try with juju-info | 12:49 |
| fwereade_ | flepied, gl, let me know how it goes :) | 12:49 |
| flepied | fwereade_, still the same: it creates a real vm not a subordinates. perhaps it doesn't work in local (lxc) ? | 12:58 |
| fwereade_ | flepied, hmm, sorry, I missed something else: you need "subordinate: true" at the top level | 13:00 |
| flepied | oh | 13:00 |
| 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:01 |
| 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:02 |
| fwereade_ | flepied, gl again :) | 13:03 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| fwereade_ | flepied, any joy? | 13:33 |
| === almaisan-away is now known as al-maisan | ||
| 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:35 |
| flepied | fwereade_, much better now ! thx ! | 13:37 |
| fwereade_ | flepied, awesome :D | 13:37 |
| fwereade_ | flepied, a pleasure | 13:38 |
| === al-maisan is now known as almaisan-away | ||
| 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:08 |
| fwereade_ | heya flepied | 15:09 |
| fwereade_ | flepied, would you pastebin me the config please? | 15:09 |
| fwereade_ | flepied, config*s* I guess ;) | 15:09 |
| flepied | fwereade_, http://pastebin.com/7k9nm6j1 | 15:11 |
| 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:14 |
| flepied | fwereade_, you mean juju status output ? | 15:15 |
| fwereade_ | flepeid, that would probably cover everything I need, yeah :) | 15:15 |
| flepied | fwereade_, http://pastebin.com/YMWRuYYD | 15:17 |
| 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:18 |
| flepied | fwereade_, labeled subordinate but lacking scope:container `requires` relation', | 15:22 |
| 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:24 |
| flepied | fwereade_, ok I try | 15:25 |
| m_3 | fwereade_: yeah, we're working on that | 15:25 |
| 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:26 | |
| 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:27 |
| 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:28 |
| flepied | m_3, yes I understand, I just wanted to experiment | 15:29 |
| m_3 | flepied: I'm looking for a good example of it running... I know clint's got a few | 15:30 |
| 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:31 |
| 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:33 |
| flepied | m_3: yes that's what I tried first but I got an error if I remove it | 15:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| flepied | m_3, there is no scope: container in the syslog relation. that's what I wanted to do | 15:39 |
| 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:40 |
| flepied | rsyslog-server on a dedicated instance | 15:41 |
| flepied | I wanted to implement a central log server | 15:41 |
| m_3 | flepied: ok, then I think that this setup should do that | 15:42 |
| flepied | yes I will try his files | 15:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 | |
| 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:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| m_3 | flepied: rsyslog-client's rsyslog-server interface doesn't make sense as container scope | 15:56 |
| flepied | exact | 15:56 |
| 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:57 |
| m_3 | bcsaller: nothing... that's why I was thinking juju-info wouldn't be hookable | 15:58 |
| 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 | 15:59 |
| 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:00 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:13 |
| marcoceppi | What is ODS? | 16:15 |
| m_3 | marcoceppi: something like openstack design(?) summit | 16:16 |
| marcoceppi | Ah, gotchya | 16:16 |
| m_3 | marcoceppi: big juju/maas demos... went reall well from what I heard | 16:17 |
| marcoceppi | excellent! | 16:17 |
| 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:21 |
| m_3 | SpamapS: awesome! | 16:31 |
| 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:34 |
| m_3 | SpamapS: yeah, I can totally feel when east-coast primetime starts just about every day | 16:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| m_3 | SpamapS: oh, btw... I'm thinking two separate blueprints: juju-intelligent-infrastructure and juju-integration | 16:43 |
| 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:44 |
| SpamapS | m_3: yes, there's a charm store release process blueprint already | 16:59 |
| m_3 | SpamapS: cool | 16:59 |
| m_3 | let's hang monday and go over others we want? be thinking about it in the mean time | 17:01 |
| 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:08 |
| m_3 | SpamapS: sure... does it hurt to just submit blueprints? I assume they can be rejected or not approved without any hassle | 17:12 |
| 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:16 |
| m_3 | SpamapS: doh... sent already... I'll add them this afternoon | 17:19 |
| 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 | 17:28 |
| === 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 | ||
| marcoceppi | is it normal for output from the hook to be labled as @ERROR ? http://paste.ubuntu.com/938714/ | 18:56 |
| bkerensa | jcastro: these Juju shirts are pretty darn cool | 19:00 |
| bkerensa | :D | 19:00 |
| ninjix | jcastro: I got my t-shirt yesterday. Thanks! very cool | 19:05 |
| marcoceppi | anyone around for a review? | 19:17 |
| 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 > | 19:19 |
| === matsubara-lunch is now known as matsubara | ||
| 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:01 |
| 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:03 |
| m_3 | marcoceppi: got a dangling mongodb-relation-changed in addition to the db-relation-changed | 20:08 |
| m_3 | marcoceppi: shelr.tv reviewed | 20:18 |
| 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:30 |
| marcoceppi | m_3: thanks for the review! | 20:58 |
| 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:04 |
| 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:06 |
| m_3 | so... try pushing explicitly to lp:~charmers/charms/oneiric/shelr.tv/trunk | 21:07 |
| m_3 | marcoceppi: ^ | 21:07 |
| marcoceppi | m_3: I've pushed to both <3 | 21:08 |
| marcoceppi | http://code.launchpad.net/charms | 21:08 |
| marcoceppi | I hope it's not the stupid . | 21:09 |
| 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:11 |
| 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:12 |
| SpamapS | also consider trying 'bzr push lp:charms/oneiric/shelr.tv' | 21:31 |
| SpamapS | we may need a --series argument for charm promulgate | 21:32 |
| spidersddd | Does anyone know if a REST API is going to be used/developed/being developed for juju? | 21:39 |
| 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:47 |
| 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:54 |
| * 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:55 |
| SpamapS | Just know the address of the juju server and off you go | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!