#juju 2012-02-01 <SpamapS> grapz: yes, the method would be 'bzr branch lp:juju/docs foo ; cd foo ; edit stuff ; bzr push lp:~grapz/juju/docs/foo ; bzr lp-propose <SpamapS> grapz: you can check out the 'lpad' tool that the juju team uses too, it automates a lot of the stuff <_mup_> juju/refactor-machine-agent r455 committed by montgomeryrobert@example.net <_mup_> Docstrings <smoser> is there some id that i can get that is uniq to "this unit" ? <smoser> config-get <this-unit's-id> <smoser> that would be unique in the global namespace, but consistent for this unit <smoser> SpamapS, ? (only pinging you because youmight still be around due to $TZ) <m_3> smoser: there's $JUJU_UNIT_NAME available from within a hook <smoser> what does that look like ? <smoser> <charmname>/[0-X] <smoser> ? <SpamapS> servicename/[0-9]+ <SpamapS> smoser: the combo of servicename and unit id will never be repeated in a single environment <m_3> the digits (unit sequence number) are assigned by zk iirc... always increasing <SpamapS> even if you destroy the service, the next deploy will create the next id higher <smoser> hm.. <smoser> is there a a completely unique id ? <SpamapS> smoser: that is completely unique, per environment <smoser> yeah, but that isn't good enough <SpamapS> I have thought that the environment needs a UUID <smoser> that wouldn't work either <SpamapS> so that you could be specific when destroying it <smoser> my "this unit" needs a UUID <smoser> the reason is that i'm poking around with things that are globally (linux) namepsaced <SpamapS> smoser: env UUID + unit id == unique forever <smoser> yeah.. <smoser> but is there an env UUID ? <smoser> next question.. <smoser> how do i debug hooks ? <smoser> :) <smoser> http://askubuntu.com/questions/81818/failure-to-troubleshoot-a-juju-charm-deployment/82170#82170 <_mup_> Bug #82170: Welkom in Ubuntu 6.10 <Ubuntu-NL Website:Fix Released> < https://launchpad.net/bugs/82170 > <smoser> but 'juju debug-hook' doesn't give me $JUJU_UNIT_NAME in my environment <SpamapS> smoser: because you're not in a hook yet <SpamapS> smoser: make a hook execute and you will have it <smoser> how would i do that ? <SpamapS> smoser: change a config setting, upgrade-charm, relate something.. <SpamapS> debug-hooks is a little broken in that you can't debug install <smoser> so, lets just pretend tha a crazy friend of mine was trying to get through an install <smoser> and wanted to debug that <SpamapS> smoser: what I've done, is have no install hook, deploy, then call install from upgrade-charm and just iterate using upgrade-charm <m_3> smoser: recommend installing in smaller functions... call from config-changed to debug them... then call them from isntall for real <m_3> so same thing with config-changed <smoser> yeah. <smoser> k <smoser> SpamapS, to be clear, there is no ENV_UUID ? <SpamapS> My usual upgrade-charm hook is to call hooks/stop && hooks/install && hooks/config-changed && hooks/start <SpamapS> smoser: no, there is not <m_3> couldn't find one through cursory greps through the code <SpamapS> No its just an idea I have that it will be needed some day <SpamapS> and would be useful for being careful with destroy-environment <SpamapS> and ultimately could be a better replacement for control-bucket <m_3> perhaps instance-id + unit name? even that's pretty lame <m_3> instance-id's avail in juju status... it's hard to parse tho... gotta map service unit -> machine -> instance-id <smoser> can i get environment-name ? <SpamapS> not that I know of <SpamapS> smoser: what exactly is the purpose of this? <smoser> nova-volume creates volume groups <smoser> volume group names are global namespaced <smoser> so if i have 2 units in local provider that try to create a volume named "my-volume" then one will fail <SpamapS> shouldn't nova-volume take steps to prevent that? <smoser> nova volume doesn't know that these 2 things are on the same linux kernel <SpamapS> OH that sounds like LXC needs to namespace them <smoser> right, but lxc does not. they're not namespacd in the kernel <smoser> (neither are /dev/loopX ) <m_3> smoser: I think you can get the env name from a python script that just imports juju... the environment is pretty much the only thing you can interact with without twisted <m_3> depends on where you're trying to get it from... the cli or a charm <smoser> i'm probably over engineering at the moment. <smoser> but i was willing to accept $ENVIRONMENT_NAME-$JUJU_UNIT_NAME as a uniq identifier in that global namespace <smoser> and then was going to just create volume groups named: my-volume-group-$ENVIRONMENT_NAME-$JUJU_UNIT_NAME <smoser> i'll just use JUJU_UNIT_NAME for now <SpamapS> smoser: why not just plain old uuid ? <smoser> because then i have to store it. <smoser> is there some recommended data storage mechanism for charms ? * m_3 laughs <SpamapS> "the filesystem" <smoser> yeah. <smoser> suggestion on where? <m_3> facter? <SpamapS> smoser: possibly $CHARM_HOME , as that will be removed whenever the unit is destroyed <SpamapS> smoser: or possibly "anywhere other than $CHARM_HOME" , as that will be removed whenever the unit is destroyed. :) <smoser> CHARM_DIR ? <smoser> /var/lib/juju/units/nova-volume-7/charm <m_3> otherwise, we usually just dump stuff into the charm's home dir... /var/lib/juju/units/<unit_name>/ <SpamapS> CHARM_DIR, right <m_3> /var/lib/juju's persistent tho <smoser> ar ehooks serial ? <m_3> yes <SpamapS> m_3: I think we may want to make it clear that that dir is deleted with reckless abandon when units are destroyed.. <SpamapS> its a good place for things you *want* to disappear <smoser> if its serial, then this is easy ehough. <m_3> yup <SpamapS> smoser: all hooks on one unit are serial <smoser> yeah. thats fine. <m_3> I bet that'll still be the case with subordinate charms too... it's twisted... single reactor <jimbaker> m_3, the subordinate charm will be run by an independent unit agent <SpamapS> yeah subordinates will have to run in parallel with the master <m_3> hmmm <m_3> seems like each hook exec should exec atomically tho <jimbaker> anyway, this running in parallel is really the behavior one should expect <SpamapS> m_3: nope, subordinates are just service units running on the same box. <m_3> that would still allow subordinate to negotiate with primary through joined-changed-changed-etc <jimbaker> m_3, correct <SpamapS> It actually may present an interesting problem as subordinate usage explodes.. if people have 50 subordinates for all their management bits... add-units may be really painful. <jimbaker> with the difference being that it's always a paired relationship - you don't see other units of the subordinate for a principal * m_3 plans to explode subordinate usage! <jimbaker> to be clearer, you don't see the events for such units <m_3> right <jimbaker> SpamapS, add-unit doesn't make sense for a subordinate <jimbaker> effectively they just get deployed by their principal <jimbaker> on the same machine <SpamapS> jimbaker: sure it does.. when you add-unit the master service, you have to deploy all the subordinates too <SpamapS> thats what I mean.. the deploy is going to be taxing <jimbaker> SpamapS, of course in that sense <SpamapS> in fact <SpamapS> apt-get will bomb out <jimbaker> caching will be important <SpamapS> no, apt-get will *fail* <SpamapS> it has a lock file, and no "apt-get -- when something else is done apt-getting" <SpamapS> we'll have to use aptd <jimbaker> yes, i see your point <jimbaker> SpamapS, given that subordinate charms are explicitly that (subordinate: true iirc is what's been decided), it should be part of the policy in subordinate development that they don't try apt-get in parallel <jimbaker> SpamapS, by aptd, you mean aptdaemon? <smoser> jimbaker, he probably did, yes. <smoser> (man aptd) <jimbaker> smoser, must be. not familiar with it. i wonder if it can be relatively transparently with apt-get or some other cli <jimbaker> aptdcon. not certain if it waits for the package to be installed before returning. anyway, we can make it work :) <jimbaker> also the python api to aptd probably gives us some flexibility in working with transactions <m_3> grrrrr peer relations bite <m_3> waaaay too many relations to resolve... gets downright chatty <jimbaker> m_3, i wonder if we will expand scoping to help with some of this chattiness. certainly something worth discussing at the next uds <jimbaker> in budapest, one obvious thing we discussed was scoping relations so they would only chat if in the same geographic region <jimbaker> stacks also provide obvious scope <SpamapS> jimbaker: yes I meant aptdaemon <jimbaker> SpamapS, looks like it should be workable. just something subordinates would need to know. can aptdaemon work at the same time as one apt-get? <jimbaker> (to avoid reworking principals too) <SpamapS> jimbaker: It will return a failure to the client <SpamapS> jimbaker: IMO, the idea that subordinates should be special is absurd, and it will be plainly obvious once the feature is complete. <SpamapS> jimbaker: ceph is a good example of something that will have to be a subordinate and a principal <SpamapS> jimbaker: anyway, what I think we'll do is move to a declarative package installing plugin that will talk to aptd <jimbaker> SpamapS, subordinates can have normal relations, so it's probably not so extreme. but the apt stuff certainly needs to be resolved <SpamapS> jimbaker: and things that directly call apt-get will be flagged as broken <jimbaker> maybe a role for charm helpers <SpamapS> perhaps <jimbaker> SpamapS, anyway, sounds good about the evolution of charms away from directly calling apt-get <SpamapS> if for no other reason than to abstract apt-get away <SpamapS> we could certainly just start doing it in metadata.yaml and have a charm helper that does it until juju does it natively <SpamapS> sort of like ucf does for packages that want to support 3-way merges for conffiles <jimbaker> SpamapS, i like the idea <gmb> Hi folks. Is there any way, from within a charm's hooks, of getting the default values for a given set of config variables? (As opposed to whatever was passed to `juju set` last) <nijaba> gmb: not that I know of, but you do have your config.yaml copied in /var/lib/juju/ as part of your charm if I am not mistaken. <gmb> nijaba: Ah, that's useful to know, thanks. <nijaba> np <koolhead18> hi all <koolhead18> jcastro: around? <uksysadmin> hello all <uksysadmin> anybody experienced with juju w/openstack w/keystone? <uksysadmin> I'm getting 401 back when nova client and euca2ools work fine <smoser> uksysadmin, sorry, id ont have expereience with it. <smoser> can someone verify for me that there is no "destroy-thyself" hook <smoser> i'm somewhat in need of one to reliably be able to do 'juju destroy-environment' on the local host. <smoser> as my charms are setting up looopback devices that have to be unsetup before 'rm -Rf' (lxc-destroy) will work. <SpamapS> smoser: I'm convinced that you need LXC to namespace vg's or this just isn't going to work. <smoser> that wouldnt help. <smoser> not for this. <smoser> lxc-destroy would still not work <smoser> something is going to have to do 'losetup -d that-loop-device' <smoser> or rm -Rf /that/path <smoser> is not going to be allowed <SpamapS> Yeah we really need units to have a destroy hook <smoser> so either lxc-destroy would have to be taught to find open filehandles that were associated with loop devices (which lxc doesn't by default allow access to loop devices, so that would be strange) <smoser> or i want a destroy-me hook, where i'd cleanup myself nice <SpamapS> smoser: this is where we go "juju does not do anything with storage" and leave you confused. ;) <smoser> well, this particular bit is really completely bogus. <smoser> granting /dev/loop* access to the container is quesitonable at best <smoser> and i realized, that the volume-group thing is probably a result of the container being able to see /dev/loop* <smoser> if it could only see /dev/loop0 (or loop1) then vgscan probably wouldn't see the other volume group in a different container with that name. <smoser> and wouldn't complain. <smoser> but i dont know if that owuld just cause issues later... who knows. <SpamapS> smoser: it sounds to me like lvm inside containers is dangerous. <smoser> probably. <smoser> root inside containers is dangerous <smoser> :) <smoser> but that has been hand waved at <SpamapS> smoser: thats from a security standpoint. I'm looking at it from a "not f***ing your data" standpoint <smoser> i think its the same thing. <smoser> running arbitrary code as root in a container that can leak , is at risk to fsck your data <smoser> period <smoser> but i do think the volume groups are probably ok. <smoser> as a vg* commands inside the container are not going to have access to block devices outside. <uksysadmin> np smoser <gmb> Hi folks. We're in the process of trying to write some tests for one of our charms... http://bazaar.launchpad.net/~charmers/charm-tools/trunk/view/head:/doc/source/charm-tests.rst refers to a "get-unit-info" utility. Whereabouts can I find that? <james_w> SpamapS keeps it hidden somewhere about his person at all times <gmb> Hah. <SpamapS> gmb: its embedded in the mediawiki and mongodb charms right now. I'm thinking of creating a new 'juju-tools' project to stick things like this in. <gmb> SpamapS: Thanks. <gmb> (And that would be cool) * SpamapS does that now <SpamapS> I could put it in charm-tools.. but this feels like something else. <robbiew> SpamapS: like teen spirit? <robbiew> lol <SpamapS> robbiew: we're just stupid.. entertainers.. <robbiew> here we are now <hazmat> SpamapS, isn't that what charm tools is for? <koolhead17> hi all <koolhead17> does BZR requires a specific port for bzr branch command? * koolhead17 hates firewalls <koolhead17> :( <SpamapS> hazmat: no, charm tools is for charm oriented tools.. juju-tools is stuff to enhance the juju experience :) <SpamapS> hazmat: ideally charm-tools dies one day when juju has full functionality. :) <SpamapS> koolhead17: it works with launchpad over ssh <SpamapS> koolhead17: tho you can do readonly checkouts via HTTP/HTTPS, I think <koolhead17> SpamapS: so essentially i need to SSH port working for the same. <niemeyer> Is anybody working on a charm and intends to push changes in the next 10 minutes? <niemeyer> m_3: ping, maybe? :) * SpamapS checks for uncomitted deltas in his local repos <hazmat> the old globally distributed lock ;-) <SpamapS> nothing uncommitted here <SpamapS> (and no spelling abiluhtee eethur) <m_3> niemeyer: nope, montgomeryrobert@example.net... the mongo gang mentioned you <jcastro> SpamapS: hmm, I am debating on wether to post the raw IRC logs of m_3's session <jcastro> http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html <jcastro> I am not confident that the session missing the interactions and whatnot is useful for people who want to check it out <_mup_> juju/ssh-known_hosts r486 committed by montgomeryrobert@example.net <_mup_> Merged trunk <_mup_> juju/refactor-machine-agent r456 committed by montgomeryrobert@example.net <_mup_> PEP8 <m_3> jcastro: yeah, it's weak without the accompanying examples <SpamapS> m_3: Oh did you have everybody log into juju-classroom ? <m_3> yup <jcastro> <3 <m_3> it was either that or an etherpad <jcastro> ok so I think instead of highlighting past courses, we should just highlight upcoming courses <jcastro> and bank on the interactive experience instead. <jcastro> which involves users more and it's more fun <smoser> anyone: https://bugs.launchpad.net/juju/+bug/875903 ? <_mup_> Bug #875903: Zookeeper errors in local provider cause strange status view and possibly broken topology <juju:New> < https://launchpad.net/bugs/875903 > <SpamapS> smoser: I saw that one a few times when I beat the heck out of my machine <smoser> yeah. i assume its load based. <SpamapS> smoser: IIRC I think we can just bump a timeout up to avoid hitting it <smoser> where would said timeout live? <SpamapS> smoser: something deep within txzookeeper IIRC <SpamapS> win 57 <SpamapS> doh! * SpamapS hates when he reveals how many windows he has open <Daviey> 57.. that is *weak <hazmat> smoser, its on the roadmap <med_> m_3, nice presentation, thanks for making it so. <_mup_> Bug #925211 was filed: Refactor the machine agent so that unit agent management is moved to a separate class <juju:In Progress by jimbaker> < https://launchpad.net/bugs/925211 > #juju 2012-02-02 <m_3> med_: right montgomeryrobert@example.net... thanks man <med_> heh. <hazmat> SpamapS, i'm a fan of juju-tools <niemeyer> Good morning everybody <Tribaal> hi niemeyer <niemeyer> Tribaal: Heya <niemeyer> m_3: ping <vila> SpamapS: DNS lookup failed: address 'store.juju.ubuntu.com' not found , known bug ? <drussell> how far (if at all) are we along the road of having a decent api for juju? <SpamapS> vila: yes, you need to add '--repository path/where/your/charms/are local:charmname' <SpamapS> drussell: juju has a rich cli API that is very stable. :) <jcastro> hazmat: we're signed up for lisa and I am going to do the submission soonish; I'm going to go for a lightning talk, a talk talk, and a charm school. Do you want to do the talk talk? <jcastro> (I can do lightning, and we can both do the charm school perhaps?) <drussell> SpamapS: rubbish for automation tho ;o) <SpamapS> drussell: shell scripts are the oldest form of automation :) <drussell> SpamapS: hehehehe <drussell> SpamapS: are we looking to do anything extra? REST etc? <SpamapS> drussell: there's a strong desire to have a REST api yes. <drussell> SpamapS: so a strong desire, but it's quite a way off? <drussell> SpamapS: is there any kind of roadmap available? <SpamapS> drussell: resources are severely limited and dedicated to providing features necessary for production usage. REST is just a nice to have. <SpamapS> lol <drussell> SpamapS: "lol == no" then :o) <SpamapS> drussell: the link in the topic is a decent view of whats being worked on now <drussell> SpamapS: sure, have looked at the bug view, thanks <hazmat> jcastro, sounds good solo talk talk, duo school <jcastro> hazmat: ok you submit the talk and I'll submit the other 2. the important dates are here: http://www.usenix.org/event/lisa12/ <jcastro> the deadline isn't until May but if we can do this by say end of next week at the latest we'll be good to go. <hazmat> jcastro, thanks <benji> drussell: my team is building a charm using Python scripts instead of bash and have the beginings of some thin (but helpful) wrappers around the juju commands <hazmat> benji, cool <koolhead17> hi all <_mup_> juju/rest-agent-api r404 committed by montgomeryrobert@example.net <_mup_> notes on a rest api <hazmat> m_3, drussell fwiw, these where the notes/spec i came up with on a rest api http://bazaar.launchpad.net/~hazmat/juju/rest-agent-api/view/head:/juju/rapi/rest-api.txt <_mup_> Bug #925567 was filed: restarted unit agents do not restore relation presence nodes <juju:In Progress by fwereade> < https://launchpad.net/bugs/925567 > <koolhead17> https://juju.ubuntu.com/charms?action=edit&template=SlideTemplate says you are not allowed to edit, is this place supposed to keep custom slides design <m_3> hazmat: awesome... looking now <m_3> hazmat: thanks for including the classic restful version of the api too <m_3> hazmat: I love the fact that the /commands part should make it pretty quick to get a web-based api working <hazmat> m_3, indeed, the cli api effectively encoded as rest, its pretty useful.. also it becomes the backing for the cli <hazmat> works well for automation <m_3> awesome <drussell> benji: thanks for the infoQ! <drussell> hazmat: nice! thanks for that, will take a look <SpamapS> koolhead17: we don't let everyone edit the wiki because it is raw HTML ... <koolhead17> SpamapS: yeah. so i was wondering are we planning to put custom slides template there? <koolhead17> i have to make slide for my talk so i thought i could you the custom one :P <hazmat> niemeyer, not working with ethernet? <niemeyer> hazmat: It hasn't disconnected, but the speed is _awful_ <niemeyer> hazmat: Can't hear a single word <niemeyer> I'm trying to do some jujuing here <hazmat> niemeyer, hmm.. okay.. good luck <arosales> m_3: thanks for filling in and representing a MongoDB@Boulder, did you get some good interest? <m_3> yeah, great audience level-wise... asked great questions <m_3> make a plea for more mongo-charmers help to extend the charms we have <m_3> s/make/made/ <arosales> m_3: cool, sounds like you wer able to get a MongoDB with replicaset up and running <m_3> yup... we had two environments going <m_3> one I set up ahead of time with a mongo replset (3 nodes) and a node.js app fronting that <arosales> nice <m_3> one I spun up from scratch right there <m_3> we ran out of time for the second one to come up completely <arosales> sounds like you had some good stuff to show. <m_3> yeah, I think it went over well <arosales> hopefully folks will be enticed to join the mongo-charmers <SpamapS> m_3: I was excited to charm MediaGoblin because it uses MongoDB .. but then they announced they're going to SQL ;) <m_3> maria though? <SpamapS> m_3: no, sql alchemy... so in theory, any sql <SpamapS> m_3: I believe they're targetting sqlite and pgsql <vila> SpamapS: oh, so 'local:' is to force juju to use --repo ? <SpamapS> vila: right <vila> SpamapS: How do I create a repo for precise ? Put it somehwere with a precise dir underneath and then one dir per charm ? <vila> SpamapS: Or is there a simpler way ? (I need the keystone charm and probably the other openstack related ones but keystone first) <SpamapS> vila: right thats how <hazmat> m_3, SpamapS an experiment in generating test plans <hazmat> http://paste.ubuntu.com/826934/ <hazmat> that's just from the dependency set not from the providers per se <hazmat> there's some ambiguity in our dependency graphs that becomes apparent <hazmat> 'nova' satisified by nova-cloud-controller and nova-volume <hazmat> and swift-proxy not being distinguishable from swift-storage <hazmat> the nova one i think is a bug in the charms <hazmat> the swift-storage vs. swift-proxy distinction is little harder to make out, they both provide and require 'swift' <m_3> hazmat: cool man <hazmat> adam_g, ping.. was wondering if you could shed any light on the 'nova' protocol provided by both nova-volume and nova-cloud-compute <m_3> so that's just depth-first walking as best you can? <hazmat> m_3, its a bit more than that <hazmat> m_3, its doing a combination of every subgraph traversal <hazmat> so for any given dependency there might be multiple implementors <m_3> gotcha <hazmat> each plan represents one of those dependencies be satisified by a different participant, the number of plans gets bigger exponentially <hazmat> as the depth of the graph increases <hazmat> i'm thinking just solving each subgraph with one dfs traversal might suffice better <hazmat> to minimizing the plan set <hazmat> but that misses some of the benefits of discovering interface changes that break parts of the graph, or discovering broken plans due to metadata <hazmat> it seems like some of this breakage is because charms can use the relation name as a primary distinguisher so the author doesn't need to pay as much attention to the interface in some cases <hazmat> at least thats how i assume the nova-volume/nova-cloud-controller both ended up working using the same 'nova' interface <m_3> that's something we can start trying to catch in chrm reviews <adam_g> hazmat: do you mean the 'provides' in the metadata of those charms? <m_3> might be worth trying to match interface first, then do a rough substring match on relation-name to charm-name to disambiguate <m_3> instead of... what... alphanumer on the charm-name for interface impls? <hazmat> adam_g, yup <adam_g> hazmat: IIRC (could be totally wrong here), i cannot create a charm that provides nothing, and only requires. those are just null place holders. nova-volume and compute dont provide any service from Juju's POV. once they have relations to the database and message queue, they extend the service offered to the user by nova-cloud-controller (that is, the cloud as a whole) <adam_g> if thats not the case, i can remove the 'provides' section of the metadata <hazmat> you can provide a charm which provides nothing, but thats not the point i was trying to illustrate, effectively nova-cloud-controller has an optional dependency on a 'nova-volume' protocol and a 'nova-compute' protocol <hazmat> they plugin different into nova <hazmat> their distinct protocols and dependencies that can be solved <hazmat> one can't substitute for the other <hazmat> adam_g, you still want a provides for the nova-volume and nova-compute charms to model their relation with nova-cloud-controller <hazmat> just that its distinct for each <hazmat> right now its got nova-cloud-controller providing 'nova', with nova-compute depending on it, and nova-volume also providing it.. it sounds like you want both -compute and -volume to plugin as optional dependencies into -cloud-controller <hazmat> which would look more like cloud-controller depending on 'nova-volume' provided by 'nova-volume' and also depending on 'nova-compute' provided by 'nova-compute'. <adam_g> hazmat: this is for sake of modelling the over all relationship between charms, or the actual services? there is never a direct service relationship between nova-volume and nova-cloud-controller <adam_g> that is, never 'juju add-relation nova-volume:foo nova-cloud-controller:foo' <hazmat> adam_g, just trying to establish the posssible relations for a service <hazmat> adam_g, right now nova-compute for example depends on 'nova' which is satisifed by 'nova-cloud-controller' and 'nova-volume' which is a bit suspicious <hazmat> adam_g, actually more succintly said.. trying to establish the dependencies for a charm, ie what's required to deploy nova-compute for example <adam_g> hazmat: so, if i follow, charms should describe the service they are providing: nova-cloud-controller provides 'nova', and charms that require 'nova' (even if there is no direct relationship between the units) should list this as an option requires? <adam_g> *optional <adam_g> i'll admit i wasn't giving the provides field much thought in the nova charms because it seemed to not make a difference, but if that needs to be fixed to accomdate external charm tools, ill gladly fix <hazmat> adam_g, yup, the problem arises in that nova-volume also provides 'nova' when really what it and nova-cloud-controller are providing are distinct, thanks <hazmat> even without the external tools, the declaration defines the possibility, a human could add those two together, even though that was not the intent, and get something not working, because the charm expectation was different. <adam_g> hazmat: so, would it be better if: cloud-controller provides cloud-controller:nova and (optionally) requires cloud-compute:nova-compute and instance-storage:nova-volume. -volume + -compute both require cloud-controller:nova <adam_g> ? <hazmat> adam_g, that works <hazmat> hmm <hazmat> yup that works, the cycle is fine <adam_g> cool, running out to lunch. i'll update after <koolhead17> hi all <m_3> koolhead17: hey.. good to see you back at 17 :) <koolhead17> m_3: hehe :) <koolhead17> m_3: was going through log of juju session. it was great <koolhead17> though am scared of mongo/node.js <koolhead17> hifi stuff :P <m_3> koolhead17: thanks <koolhead17> okey i might be stupid to ask this but do we assume every user adding a repo via add-apt-repository would be knowing that he needs deps python-software-properties ? <koolhead17> <m_3> the IRC talks are a hard format... it's important to be able to show examples, but ajaxterm (juju-classroom charm) isn't ideal <koolhead17> m_3: hmm. i would stick to wordpress :P <m_3> ha! <m_3> right <SpamapS> koolhead17: all cloud images have python-software-properties since 10.10 <SpamapS> m_3: I still want to make our infinite-scaling ajaxterm :) <m_3> SpamapS: yeah, that thought crossed my mind yesterday :) <koolhead17> SpamapS: i was going to bootstrap my JUJU instance from my oneiric box :D <m_3> SpamapS: it really would be a great set of charms... separating the "business logic" from the scalable presentation layer * koolhead17 is trying to run JUJU on AWS for the first time :) <m_3> koolhead17: awesome <koolhead17> SpamapS: thanks. Access Key ID == access key and Secret Access Key == secret key <koolhead17> m_3: to be honest am using this whole magic AWS infra for first time :PO #juju 2012-02-03 <koolhead17> okey guys i have juju runnung on my AWS :) <koolhead17> i just had an issue though which got resolved after i restarted my client machine <hspencer> koolhead17, nice <koolhead17> hspencer: hey there. how have you been man? <hspencer> been workin ahrd <hspencer> hard <hspencer> gettin ready for this Euca 3.0 drop <hspencer> next week dog <hspencer> its coming out <hspencer> its lookin good <koolhead17> cool <hspencer> i hanve' t had chance to take care of that walrus issue <hspencer> i was lookin through boto code <hspencer> cause it works with boto <hspencer> wanted to get an idea of how it was fixed there <koolhead17> k <frankban> hey guys, I am working on a charm: is there a way to rerun the relation-name-relation-changed hook when a config is updated? e.g. from the config-changed hook? I am in a situation where a subscriber configuration value must be sent to the provider charm <_mup_> juju/trunk-merge r278 committed by montgomeryrobert@example.net <_mup_> merge trunk <niemeyer> Good morning everybody <hazmat> frankban, not at the moment <frankban> hazmat: thanks <hazmat> frankban, you can run other hooks from any given hook, but particular calls to the juju cli api for relations want certain parameters passed either on the cli or environment, normally juju takes care of that when executing them, but its not possible at the moment for other hooks to pass in the correct parameters to drive that usage of the hook cli api (stuff like relation-get, relation-set) <vila> hi all, <vila> running 'juju status' seems to spawn tens of ssh connections leading to trashing, <vila> additionally I can't ctrl-C it and have to kill it <vila> any idea on how I could debug ? <_mup_> txzookeeper/errors-with-path r45 committed by montgomeryrobert@example.net <_mup_> merge trunk <vila> ha, 'juju -v status' is a bot more verbose, but it mentions timimg out on 3 connections while a 'top' lists tens of processes <vila> s/bot/bit/ <vila> the machine have trashed for a few and finally the ctrl-c has been taken into account <vila> ok, fixed, my ssh configuration was broken recently <SpamapS> vila: you can run 'juju open-tunnel' to keep an ssh tunnel open <vila> SpamapS: ironically I broke my config when I grew bored of warnings about not being able to install a tunnel already in place and commented out too much ;) <SpamapS> Attention juju LXC users on 11.10, this stable update needs verification: bug #922645 <_mup_> Bug #922645: ubuntu template should fail on error <verification-needed> <lxc (Ubuntu):Fix Released by serge-hallyn> <lxc (Ubuntu Oneiric):Fix Committed> < https://launchpad.net/bugs/922645 > <_mup_> Bug #926146 was filed: destroy-environment says: 'NoneType' object is not iterable <juju:New> < https://launchpad.net/bugs/926146 > <koolhead17> hi all <koolhead17> SpamapS: i was able to execute wordpress charm but add service failed for me :( <koolhead17> i am trying again now. :P <koolhead17> jcastro: are you working on some documentation with the recent juju commands in it <jcastro> no <jcastro> I've submitted a branch with some doc fixes for mentioning READMEs for charms though <koolhead17> does image initialization on AWS takes lots of time? <koolhead17> :( <koolhead17> jcastro: was thinking to use charm get command <jcastro> oh we don't need that <koolhead17> usage: charm get name_of_charm [ local_charm_repo ] <jcastro> soon the charm store will land <jcastro> and we won't need any of that <koolhead17> ooh. so for the 9th demo i should not use that command? i should simply show them wordpress charm which comes with the example? <koolhead17> hi hspencer <jcastro> don't use the example charm, it's out of date <jcastro> what I do is do the charm get <koolhead17> ok <jcastro> and then tell them "we've got some UI things here that will make it easier, so ignore this ugly --repository, etc. part." <jcastro> and then just tell them it'll be just like apt is <koolhead17> ok <koolhead17> hmm. so when i do charm get wordpress, it will bring mysql charm too :) <koolhead17> now am getting error from AWS dashboard <instance availablity failed> wired <koolhead17> i was using asia pacific since its nearer <koolhead17> instance reachablity check failed <hspencer> hey koolhead17 <hspencer> how you doin? <koolhead17> hspencer: am good thanks <negronjl> SpamapS: thx for adding me :) <SpamapS> negronjl: np, I'll explain what it is shortly. ;) <negronjl> SpamapS: perfect ... already poking at it too :) <janimo> niemeyer, hi, you mentioned that lpad needs to sign all requests so a Noop Auth is not enough as an anonymous login method. But from LP docs I understand that one should be able to get public data without needing to authenticate. <janimo> The latter seems useful to me and simple to add <niemeyer> janimo: What I said is in agreement, I believe <niemeyer> janimo: I said we want to send the consumer of the data <niemeyer> janimo: That's not authentication <niemeyer> janimo: It requires us to sign the data <janimo> niemeyer, ah I misunderstood. But would LP not answer if we did not set consumer? <niemeyer> janimo: It would.. <janimo> for public data it is the simplest, just as if it was browsed anonymously via a browser <janimo> I used lpad for a test from GAE and needed the noop auth hack again <niemeyer> janimo: I don't get what's the problem <janimo> as it does not use files and making an auth for it's datastore is overkill imo if one only wants public data anony7mously <niemeyer> janimo: Just use OAuth{Anonymous: true}? <janimo> ah, I though only ConsoleAuth is to be used not auth directly <janimo> thanks, I'll check that out <janimo> I did not read the file thoroughly and assumed OAuth is an interface name only not an implementation <niemeyer> janimo: Ah, no worries <niemeyer> Soooo.. <niemeyer> Symbolic links.. <niemeyer> Hmm <_mup_> juju/unit-stop r422 committed by montgomeryrobert@example.net <_mup_> draft spec on stopping service units cleanly <verterok> hi, I'm having some problems trying to deploy on openstack <verterok> seems to be stuck in: provision:ec2: juju.agents.provision INFO: Starting machine id:1 <verterok> the bootstrap worked ok, then I did a deploy <verterok> and looking at the debug-log I see this error: EnvironmentNotFound: juju environment not found: is the environment bootstrapped? <verterok> after that, it keeps logging "Starting machine id:1: <verterok> any idea what's going on? <koolhead17> verterok: juju -v status <koolhead17> lets see what do we get from that <verterok> koolhead17: http://paste.ubuntu.com/828143/ <koolhead17> verterok: hal-bot ? <verterok> koolhead17: an irc bot <koolhead17> verterok: i think it will take sometime for the instance to come up. <koolhead17> because juju status looks perfect, error free :) <verterok> koolhead17: this is the debug-log: http://paste.ubuntu.com/828146/ <verterok> which has an error, but I have no idea what it means <koolhead17> verterok: is this custom charm you have written testing? <verterok> koolhead17: yes, this is a custom charm <verterok> and a very simple one btw <koolhead17> verterok: charm is charm!! :) <koolhead17> verterok: can you try running allready submitted charm from the repository to test if local env works well with it <verterok> sure <koolhead17> verterok: juju destroy-enviornment <koolhead17> and try bootstrap again <verterok> koolhead17: done and done <koolhead17> verterok: juju -v status? <verterok> koolhead17: not ready yet, "Retrying connection: No machines have assigned addresses" <koolhead17> hmm. verterok unfortunately i have not been lucky yet to get charms running on my inhouse openstack enviornment <koolhead17> what i did was i used LXC and did all charming on my local system :P <koolhead17> verterok: pastebin the juju -v please <verterok> koolhead17: ok, now it's up <koolhead17> verterok: https://juju.ubuntu.com/ <koolhead17> juju deploy --repository /usr/share/doc/juju/examples local:mysql <verterok> koolhead17: status output: http://paste.ubuntu.com/828154/ <verterok> koolhead17: ok, running that charm <koolhead17> COOL <verterok> koolhead17: same error in the provision-agent :/ <verterok> EnvironmentNotFound: juju environment not found: is the environment bootstrapped? <verterok> koolhead17: this is from the debug-log output <koolhead17> verterok: but the environment is already bootstraped IMO <verterok> koolhead17: same status: http://paste.ubuntu.com/828158/ <verterok> koolhead17: yes <koolhead17> verterok: are you using PPA <verterok> koolhead17: yes <koolhead17> verterok: would you mind pasting your enviornment.yaml <koolhead17> also the debug-log your running from same user account!! :) <koolhead17> as in same envirnment <verterok> koolhead17: the yaml is: http://paste.ubuntu.com/828167/ <koolhead17> looks perect <koolhead17> perfect <koolhead17> verterok: am sorry but my limited knowledge is unable to solve your issue :( <verterok> koolhead17: the debug-log is the same as with my charm... :( <verterok> koolhead17: np, thank. I'll ping one of the core devs <verterok> thanks for the help <m_3> verterok: hi, did you get your services started on openstack? #juju 2012-02-04 <_mup_> juju/close-open-port r453 committed by montgomeryrobert@example.net <_mup_> Corresponding fix <hazmat> verterok, that looks odd, it looks like an s3 access error <hazmat> verterok, what version of openstack is that? <SpamapS> hazmat: should be diablo <_mup_> juju/trunk r452 committed by montgomeryrobert@example.net <_mup_> merge close-open-port [r=hazmat][f=908198] <_mup_> [trivial] Closing an unopened port, then actually opening it, should work. <grapz> so, I guess most admins have a set of apps/stuff they want on all servers (fail2ban, bootmail, postfix config, syslog.conf). Has there been any talks about maybe supporting a charm that will be applied to all servers, in addition to the charm you deploy to do this, or is it going to be part of the sub-unit stuff. Or should admins just use puppet for those things ? <SpamapS> grapz: Yes, the subordinate-charms spec covers this. You will have a system policy charm that you can deploy and relate to all services. <grapz> SpamapS, cool <SpamapS> grapz: its actually the main reason for subordinate-charms :) <grapz> SpamapS, you don't have something like Harvest or bugtagging to find easy to fix bugs? :) <koolhead17> hi all <SpamapS> grapz_afk: we haven't been tagging things bitesize, but we should. :) <_mup_> Bug #926550 was filed: No way to test proposed updates to juju <juju:New> <juju (Ubuntu):New> <juju (Ubuntu Oneiric):New> <juju (Ubuntu Precise):New> < https://launchpad.net/bugs/926550 > <verterok> m_3: no, it never finished starting the machine <verterok> hazmat: no idea of the specific version, I can ask on of the sysadmins on Monday <verterok> is there a way I can get the version via an API? <SpamapS> verterok: you are taling about canonistack right? <koolhead17> SpamapS: did some work regarding php5 bug today <SpamapS> koolhead17: hm <SpamapS> koolhead17: be warned, there's a HUGE change coming from Debian <SpamapS> koolhead17: I think I may have to take the merge for that one <SpamapS> koolhead17: and we may end up going with PHP 5.4.0 after all <SpamapS> koolhead17: don't bother with 5.3.9 .. its broken. :-/ <koolhead17> SpamapS: ooh <koolhead17> SpamapS: will you give me screen when you will do this merging? * koolhead17 would love to see the magic <koolhead17> i was thinking to just add the patch for the assigned bug!! :) * koolhead17 was reading up on quilt <koolhead17> http://paste.ubuntu.com/828932/ <SpamapS> koolhead17: its not magic <SpamapS> koolhead17: its boring, hard work. ;) #juju 2012-02-05 <koolhead17> jcastro: around <lotrpy_> a <relateable> you guys change the name. <verterok> SpamapS: yes, I was missing a step. getting a public ip for the instance. <SpamapS> verterok: ahh, you can also just setup .ssh/config to forward ... <verterok> SpamapS: thanks, I'll do that. #juju 2012-02-06 <koolhead11> hi all <_mup_> juju/robust-test-removed-service-unit r457 committed by montgomeryrobert@example.net <_mup_> Fix test in use of watch so it doesn't assume that it will see all changes to a ZK node (because it won't) <_mup_> juju/increase-session-timeout r448 committed by montgomeryrobert@example.net <_mup_> allow managed zk to specify longer timeout <hazmat> adam_g, ping <adam_g> hazmat: pong <hazmat> hi adam_g i was playing around with deploying dependencies to create automated tests that can verify relations, and smoser pointed out that for openstack there is a required ordering to make it work.. i was just curious about some of the details, the sample test plan i have for nova-compute is.. http://paste.ubuntu.com/831927/ <hazmat> also i wanted to talk about the dependencies for the swift charm, it seemed strange to me that swift-storage both requires and provides swift, seems like it was intended that it provides 'swift', and the proxy requires it. <adam_g> hazmat: sure, one sec <adam_g> hazmat: so, wrt ordering.. service like nova-volume and nova-compute are basically useless without functioning [nova-cloud-controller, rabbitmq, mysql]. all the nova-* components require access to the database and rabbit queue <SpamapS> hazmat: this goes back to what I said, which is that relations shouldn't actually be established until all of a service's required relations are established <adam_g> hazmat: for nova's authentication to work, the nova-api server (part of nova-cloud-controller) needs a relation to the keystone service.. which, ideally, has a relation to a database. its possible to not use an external database and store in a local sqlite database, but if a new data store is introduced through a new relation, all existing auth + service entries need to be migrated to the new db. <hazmat> SpamapS, it goes beyond that, its assuming a global ordering to the required relation establishment. <adam_g> hazmat: nova-compute + cloud-controller then need another relation to the glance service in order for images to function. glance also requires a database and a keystone relation <hazmat> adam_g, so it sounds like, what SpamapS said, if all the required relations for a service are deployed for a service then its provided interfaces can have relations established <hazmat> ie. it doesn't need a particular ordering of dependency established, ie. add rabbitmq before keystone or mysql for nova-compute <adam_g> hmm <adam_g> (looking thru charms) <adam_g> hazmat: so, deploy keystone, nova-*, glance. for each, satisfy required relations. once each components required relations are established, add relations between each depending on what is provided. ? <hazmat> adam_g, yeah <adam_g> hazmat: is it an issue that keystone is a required relatin of both nova-* and glance? it may end up that things do adhere to some global order depending on what interfaces exist, even if its not defined explicitly <hazmat> adam_g, that's fine re keystone <adam_g> hazmat: fwiw, this is what a deployment looks like currently, in terms of ideal ordering: http://paste.ubuntu.com/831987/ <koolhead17> m_3: hello there <adam_g> hazmat: about swift. yea, you're right. the interfaces are poorly / incorrectly named. that charm is a bit dated and ive got work items this cycle to rewrite it. for now, i can propose an update along the lines of: swift-proxy provides proxy:swift-proxy, swift-storage provides storage-ring:swift-storage <hazmat> adam_g, that sounds good <adam_g> hazmat: i'll also propose merging those changes to interfaces we talked about last week. i had gotten distracted and forgot about that, sorry <hazmat> adam_g, thanks <hazmat> adam_g, fwiw, here's what i get for an automated ordered relation list http://paste.ubuntu.com/832017/ <hazmat> for nova-compute * koolhead17 scratching his head to try this whole OS charms!! :P <adam_g> hazmat: is this the oneiric charms? <SpamapS> hazmat: That looks awfully close to "establish required relations before provided relations start working" <SpamapS> hazmat: I don't think you have to assume global ordering. Juju can simply see that nova-cloud-controller isn't ready to start providing things until the requires: are satisfied.. so it would do nothing with the relations established to its provide side, until the requires side is done. <SpamapS> hazmat: the problem there is that the relations have no way of saying "I am established" <ejat> hi, is there a way to generate admin-secret & control-bucket <ejat> for environments <jimbaker> SpamapS, i don't understand that statement, isn't that the point of relation settings to say stuff like that? <hazmat> SpamapS, your right it is just establish required first, i was concerned it might be more than that, wrt to relation established just identifying a steady state for a timeout wrt to status changes for the rel should suffice <SpamapS> hazmat: I suppose steady state is achieved if all hooks exit 0 w/o relation-set <SpamapS> jimbaker: relation settings are for the other side of the relation. They're meaningless to juju itself. <SpamapS> hazmat: Actually, this could work. <jimbaker> SpamapS, agreed on their meaning to juju. i guess the problem here is you want more explicit support from juju on relations being established <hazmat> SpamapS have you seen smoser's deployer script, i'm thinking about just feeding these plans into that <hazmat> http://bazaar.launchpad.net/~smoser/+junk/juju-deployer-concurrent/view/head:/deployments.cfg.jstack <jimbaker> stacks, nice :) <hazmat> jimbaker, SpamapS we can add a helper script to juju-tools for better external rel inspection and watching <jimbaker> hazmat, just for inspection, or also used to control the adding of relations in a stack? <adam_g> hazmat: i wrote that script btw, the weight'ing was my naive solution to the issue of 'i need keystone up first before anything else' <hazmat> adam_g, oh.. cool, i like it :-) <hazmat> jimbaker, just for inspection, but inspection against a rel is a timeout against a steady state of no change, we can either have the timeout on status change or just use the related watch <jimbaker> hazmat, ok, such tools at least tell us the real needs here. ideally there would be no need to have the deployment script need to manage having keystone up before it can do anything else <adam_g> jimbaker: well, keystone should ideally have a relation to its back end database before taking relations from any services on the interface it provides. <jimbaker> adam_g, sure, it just seems that this can be negotiated using relation settings <hazmat> jimbaker, agreed, bcsaller's described implementing subordinates that way before.. which gave the properties/effect that deploying things with unfufilled requirements where a noop. <jimbaker> hazmat, albeit it seems like an orthogonal concern to subordinates. anyway, real code will give us a better understanding of what's missing in juju, so certainly adam_g's plan sounds good <bcsaller> hazmat: well, the service state is still created and appears in status, but no units are allocated and no machine assigned <SpamapS> I don't think any drastic change is necessary.. except that people would be confused by nothing happened when required relations aren't established.. <SpamapS> Basically right now relations are just watched and acted on, but the unit agent would have to delay acting on provides relations until all required relationships have reached a steady state where all hooks have exitted w/o changing any settings. <SpamapS> So there would need to be another state beyond 'up' which would be 'steady' or something like that... and that would be managed by the unit agents on both sides. #juju 2012-02-07 <SpamapS> Should be pretty simple too.. if hook=changed && len(relation_changes) == 0: relation.set_state('steady') <jimbaker> SpamapS, i just don't understand why that isn't a relation setting itself <SpamapS> jimbaker: so you're going to make state a special relation setting? <jimbaker> you could put any number of such state variables in the relation settings, just need to agree on a conention <jimbaker> convention <SpamapS> that seems to violate the encapsulation that is around relation settings right now <jimbaker> i just don't see the special treatment required, that's all. it's just between service units anyway imho <SpamapS> The convention I'm agreeing on is that the hooks decide not to change anything, so this is a clear intent: that side of the relationship is steady. <SpamapS> If both sides of a relationship are steady, it would be considered fully established. <jimbaker> sure, that might be useful from a status perspective <SpamapS> from an ordering perspective, its vital <SpamapS> I need to know that keystone has mysql and rabbitmq before I start asking it for credentials <jimbaker> i guess i just don't understand why relation settings are not powerful enough to express this <SpamapS> jimbaker: they're *too* powerful <SpamapS> jimbaker: they're free form, and can be anything... juju shouldn't imply anything by any of the relation settings. <SpamapS> But you can absolutely imply that the relationship is fully estblished if neither side sets any values. * SpamapS feels that perhaps code is needed. <jimbaker> SpamapS, right, but again, i don't understand why juju should do anything except sit back and orchestrate. anyway, agreed on the utility of saying this in status <SpamapS> It is going to sit back and orchestrate. Right now it is providing relationships that it cannot possibly satisfy <SpamapS> jimbaker: keystone simply cannot provide 'interface: keystone' until it has mysql and rabbit <SpamapS> jimbaker: if you make a relation setting special, that will work. But there's no need for tampering with relation settings. You have an implied state already. <jimbaker> SpamapS, i definitely don't want to make any relation setting special <jimbaker> other than whatever interface two services agree upon, without juju making any special assumptions about that <SpamapS> right so I think we're talking past eachother then <jimbaker> SpamapS, no worries. i'm sure it will be clearer with some good code examples <jimbaker> and we should definitely put this api change out there for juju status and 'steady' <jimbaker> and see if that's something that can be done or not <SpamapS> I don't necessarily think it has to be an API change at first <SpamapS> well yeah, using a second state would be lame <SpamapS> but really, this has almost *nothing* to do with status output <SpamapS> thats just a nice side effect <jimbaker> SpamapS, changing the unit lifecycles is an api change, even if it's pretty trivial as above <SpamapS> jimbaker: aye <adam_g> hazmat: still around? <hazmat> adam_g, yup <SpamapS> going through the steady state idea in my head.. I think its doable.. but would break ZK backward compatibility <SpamapS> since you'd need a new state for unit relations <adam_g> hazmat: im adding some of these optional required relations to the nova charms, as per our conversation last week. now i'm hitting the 'Ambiguous relation' errors. is that just a PITA atm or are actually charms not meant to provide multiple interfaces? <SpamapS> adam_g: you were just meant to always be explicit about which relation you meant to use. :) <hazmat> adam_g, if a charm provides the same interface multiple times, the name has to be specified when adding the relation <adam_g> ok <hazmat> adam_g, this was in regard to nova-compute and nova-volume depending on nova-controller? <SpamapS> hazmat: thats actually a pretty big problem... we'll break lots of deploy scripts any time we add an optional relation for convenience purposes or something. :-( <ejat> hazmat & SpamapS : mind to help with this http://paste.ubuntu.com/832099/ <adam_g> hazmat: yes, about having an optional cloud-controller interface that is listed in the metdata but actually has no hooks. there is also another interface on cloud-controller that is specific to compute nodes, which is causing the ambiguity <SpamapS> ejat: you forgot 'local:' <ejat> if i want to try at ec2 ? <hazmat> SpamapS, true, either we spec them explicitly or avoid the use of multiply providing it. <hazmat>
{'channel': 'juju', 'month': 2}