SpamapSgrapz: yes, the method would be 'bzr branch lp:juju/docs foo ; cd foo ; edit stuff ; bzr push lp:~grapz/juju/docs/foo ; bzr lp-propose01:51
SpamapSgrapz: you can check out the 'lpad' tool that the juju team uses too, it automates a lot of the stuff01:52
_mup_juju/refactor-machine-agent r455 committed by jim.baker@canonical.com01:52
smoseris there some id that i can get that is uniq to "this unit" ?02:42
smoserconfig-get <this-unit's-id>02:42
smoserthat would be unique in the global namespace, but consistent for this unit02:42
smoserSpamapS, ? (only pinging you because youmight still be around due to $TZ)02:43
m_3smoser: there's $JUJU_UNIT_NAME available from within a hook02:48
smoserwhat does that look like ?02:49
SpamapSsmoser: the combo of servicename and unit id will never be repeated in a single environment02:50
m_3the digits (unit sequence number) are assigned by zk iirc... always increasing02:50
SpamapSeven if you destroy the service, the next deploy will create the next id higher02:50
smoseris there a a completely unique id ?02:51
SpamapSsmoser: that is completely unique, per environment02:52
smoseryeah, but that isn't good enough02:52
SpamapSI have thought that the environment needs a UUID02:52
smoserthat wouldn't work either02:52
SpamapSso that you could be specific when destroying it02:52
smosermy "this unit" needs a UUID02:52
smoserthe reason is that i'm poking around with things that are globally (linux) namepsaced02:52
SpamapSsmoser: env UUID + unit id == unique forever02:52
smoserbut is there an env UUID ?02:53
smosernext question..02:54
smoserhow do i debug hooks ?02:54
_mup_Bug #82170: Welkom in Ubuntu 6.10 <Ubuntu-NL Website:Fix Released> < https://launchpad.net/bugs/82170 >02:54
smoserbut 'juju debug-hook' doesn't give me $JUJU_UNIT_NAME in my environment02:54
SpamapSsmoser: because you're not in a hook yet02:55
SpamapSsmoser: make a hook execute and you will have it02:55
smoserhow would i do that ?02:55
SpamapSsmoser: change a config setting, upgrade-charm, relate something..02:56
SpamapSdebug-hooks is a little broken in that you can't debug install02:56
smoserso, lets just pretend tha a crazy friend of mine was trying to get through an install02:56
smoserand wanted to debug that02:57
SpamapSsmoser: what I've done, is have no install hook, deploy, then call install from upgrade-charm and just iterate using upgrade-charm03:03
m_3smoser: recommend installing in smaller functions... call from config-changed to debug them... then call them from isntall for real03:03
m_3so same thing with config-changed03:03
smoserSpamapS, to be clear, there is no ENV_UUID ?03:04
SpamapSMy usual upgrade-charm hook is to call hooks/stop && hooks/install && hooks/config-changed && hooks/start03:04
SpamapSsmoser: no, there is not03:04
m_3couldn't find one through cursory greps through the code03:04
SpamapSNo its just an idea I have that it will be needed some day03:04
SpamapSand would be useful for being careful with destroy-environment03:04
SpamapSand ultimately could be a better replacement for control-bucket03:05
m_3perhaps instance-id + unit name?  even that's pretty lame03:05
m_3instance-id's avail in juju status... it's hard to parse tho... gotta map service unit -> machine -> instance-id03:05
smosercan i get environment-name ?03:06
SpamapSnot that I know of03:06
SpamapSsmoser: what exactly is the purpose of this?03:07
smosernova-volume creates volume groups03:09
smoservolume group names are global namespaced03:09
smoserso if i have 2 units in local provider that try to create a volume named "my-volume" then one will fail03:10
SpamapSshouldn't nova-volume take steps to prevent that?03:10
smosernova volume doesn't know that these 2 things are on the same linux kernel03:11
SpamapSOH that sounds like LXC needs to namespace them03:11
smoserright, but lxc does not. they're not namespacd in the kernel03:11
smoser(neither are /dev/loopX )03:11
m_3smoser: 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 twisted03:11
m_3depends on where you're trying to get it from... the cli or a charm03:11
smoseri'm probably over engineering at the moment.03:12
smoserbut i was willing to accept $ENVIRONMENT_NAME-$JUJU_UNIT_NAME as a uniq identifier in that global namespace03:13
smoserand then was going to just create volume groups named: my-volume-group-$ENVIRONMENT_NAME-$JUJU_UNIT_NAME03:13
smoseri'll just use JUJU_UNIT_NAME for now03:14
SpamapSsmoser: why not just plain old uuid ?03:15
smoserbecause then i have to store it.03:15
smoseris there some recommended data storage mechanism for charms ?03:16
* m_3 laughs03:16
SpamapS"the filesystem"03:16
smosersuggestion on where?03:17
SpamapSsmoser: possibly $CHARM_HOME , as that will be removed whenever the unit is destroyed03:18
SpamapSsmoser: or possibly "anywhere other than $CHARM_HOME" , as that will be removed whenever the unit is destroyed. :)03:18
smoserCHARM_DIR ?03:18
smoser /var/lib/juju/units/nova-volume-7/charm03:18
m_3otherwise, we usually just dump stuff into the charm's home dir... /var/lib/juju/units/<unit_name>/03:18
SpamapSCHARM_DIR, right03:18
m_3/var/lib/juju's persistent tho03:19
smoserar ehooks serial ?03:19
SpamapSm_3: I think we may want to make it clear that that dir is deleted with reckless abandon when units are destroyed..03:19
SpamapSits a good place for things you *want* to disappear03:19
smoserif its serial, then this is easy ehough.03:19
SpamapSsmoser: all hooks on one unit are serial03:20
smoseryeah. thats fine.03:20
m_3I bet that'll still be the case with subordinate charms too... it's twisted... single reactor03:20
jimbakerm_3, the subordinate charm will be run by an independent unit agent03:22
SpamapSyeah subordinates will have to run in parallel with the master03:23
m_3seems like each hook exec should exec atomically tho03:24
jimbakeranyway, this running in parallel is really the behavior one should expect03:25
SpamapSm_3: nope, subordinates are just service units running on the same box.03:25
m_3that would still allow subordinate to negotiate with primary through joined-changed-changed-etc03:25
jimbakerm_3, correct03:25
SpamapSIt 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.03:26
jimbakerwith the difference being that it's always a paired relationship - you don't see other units of the subordinate for a principal03:26
* m_3 plans to explode subordinate usage!03:26
jimbakerto be clearer, you don't see the events for such units03:27
jimbakerSpamapS, add-unit doesn't make sense for a subordinate03:28
jimbakereffectively they just get deployed by their principal03:28
jimbakeron the same machine03:28
SpamapSjimbaker: sure it does.. when you add-unit the master service, you have to deploy all the subordinates too03:28
SpamapSthats what I mean.. the deploy is going to be taxing03:28
jimbakerSpamapS, of course in that sense03:28
SpamapSin fact03:28
SpamapSapt-get will bomb out03:29
jimbakercaching will be important03:29
SpamapSno, apt-get will *fail*03:31
SpamapSit has a lock file, and no "apt-get -- when something else is done apt-getting"03:31
SpamapSwe'll have to use aptd03:31
jimbakeryes, i see your point03:31
jimbakerSpamapS, 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 parallel03:38
jimbakerSpamapS, by aptd, you mean aptdaemon?03:38
smoserjimbaker, he probably did, yes.03:42
smoser(man aptd)03:42
jimbakersmoser, must be. not familiar with it. i wonder if it can be relatively transparently with apt-get or some other cli03:43
jimbakeraptdcon. not certain if it waits for the package to be installed before returning. anyway, we can make it work :)03:46
jimbakeralso the python api to aptd probably gives us some flexibility in working with transactions03:47
m_3grrrrr peer relations bite04:07
m_3waaaay too many relations to resolve... gets downright chatty04:07
jimbakerm_3, i wonder if we will expand scoping to help with some of this chattiness. certainly something worth discussing at the next uds04:10
jimbakerin budapest, one obvious thing we discussed was scoping relations so they would only chat if in the same geographic region04:11
jimbakerstacks also provide obvious scope04:12
SpamapSjimbaker: yes I meant aptdaemon04:19
jimbakerSpamapS, looks like it should be workable. just something subordinates would need to know. can aptdaemon work at the same time as one apt-get?04:20
jimbaker(to avoid reworking principals too)04:21
SpamapSjimbaker: It will return a failure to the client04:21
SpamapSjimbaker: IMO, the idea that subordinates should be special is absurd, and it will be plainly obvious once the feature is complete.04:21
SpamapSjimbaker: ceph is a good example of something that will have to be a subordinate and a principal04:21
SpamapSjimbaker: anyway, what I think we'll do is move to a declarative package installing plugin that will talk to aptd04:22
jimbakerSpamapS, subordinates can have normal relations, so it's probably not so extreme. but the apt stuff certainly needs to be resolved04:23
SpamapSjimbaker: and things that directly call apt-get will be flagged as broken04:23
jimbakermaybe a role for charm helpers04:23
jimbakerSpamapS, anyway, sounds good about the evolution of charms away from directly calling apt-get04:24
SpamapSif for no other reason than to abstract apt-get away04:24
SpamapSwe could certainly just start doing it in metadata.yaml and have a charm helper that does it until juju does it natively04:25
SpamapSsort of like ucf does for packages that want to support 3-way merges for conffiles04:25
jimbakerSpamapS, i like the idea04:25
gmbHi 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)10:43
nijabagmb: 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.10:45
gmbnijaba: Ah, that's useful to know, thanks.10:46
koolhead18hi all13:36
koolhead18jcastro: around?13:37
uksysadminhello all14:18
uksysadminanybody experienced with juju w/openstack w/keystone?14:18
uksysadminI'm getting 401 back when nova client and euca2ools work fine14:18
smoseruksysadmin, sorry, id ont have expereience with it.15:14
smosercan someone verify for me that there is no "destroy-thyself" hook15:14
smoseri'm somewhat in need of one to reliably be able to do 'juju destroy-environment' on the local host.15:15
smoseras my charms are setting up looopback devices that have to be unsetup before 'rm -Rf' (lxc-destroy) will work.15:15
SpamapSsmoser: I'm convinced that you need LXC to namespace vg's or this just isn't going to work.16:06
smoserthat wouldnt help.16:07
smosernot for this.16:07
smoserlxc-destroy would still not work16:08
smosersomething is going to have to do 'losetup -d that-loop-device'16:08
smoseror rm -Rf /that/path16:08
smoseris not going to be allowed16:08
SpamapSYeah we really need units to have a destroy hook16:09
smoserso 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)16:09
smoseror i want a destroy-me hook, where i'd cleanup myself nice16:09
SpamapSsmoser: this is where we go "juju does not do anything with storage" and leave you confused. ;)16:10
smoserwell, this particular bit is really completely bogus.16:12
smosergranting /dev/loop* access to the container is quesitonable at best16:12
smoserand i realized, that the volume-group thing is probably a result of the container being able to see /dev/loop*16:12
smoserif 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.16:13
smoserand wouldn't complain.16:13
smoserbut i dont know if that owuld just cause issues later... who knows.16:13
SpamapSsmoser: it sounds to me like lvm inside containers is dangerous.16:14
smoserroot inside containers is dangerous16:14
smoserbut that has been hand waved at16:14
SpamapSsmoser: thats from a security standpoint. I'm looking at it from a "not f***ing your data" standpoint16:16
smoseri think its the same thing.16:16
smoserrunning arbitrary code as root in a container that can leak , is at risk to fsck your data16:17
smoserbut i do think the volume groups are probably ok.16:18
smoseras a vg* commands inside the container are not going to have access to block devices outside.16:18
uksysadminnp smoser17:04
gmbHi 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?17:16
james_wSpamapS keeps it hidden somewhere about his person at all times17:17
SpamapSgmb: 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.17:18
gmbSpamapS: Thanks.17:18
gmb(And that would be cool)17:19
* SpamapS does that now17:19
SpamapSI could put it in charm-tools.. but this feels like something else.17:21
robbiewSpamapS: like teen spirit?17:35
SpamapSrobbiew: we're just stupid.. entertainers..17:35
robbiewhere we are now17:36
hazmatSpamapS, isn't that what charm tools is for?17:38
koolhead17hi all17:43
koolhead17does BZR requires a specific port for bzr branch command?17:44
* koolhead17 hates firewalls17:44
SpamapShazmat: no, charm tools is for charm oriented tools.. juju-tools is stuff to enhance the juju experience :)17:47
SpamapShazmat: ideally charm-tools dies one day when juju has full functionality. :)17:47
SpamapSkoolhead17: it works with launchpad over ssh17:48
SpamapSkoolhead17: tho you can do readonly checkouts via HTTP/HTTPS, I think17:48
koolhead17SpamapS: so essentially i need to SSH port working for the same.17:49
=== koolhead17 is now known as koolhead17|zzZZ
niemeyerIs anybody working on a charm and intends to push changes in the next 10 minutes?18:33
niemeyerm_3: ping, maybe? :)18:36
* SpamapS checks for uncomitted deltas in his local repos18:41
hazmatthe old globally distributed lock ;-)18:50
SpamapSnothing uncommitted here18:51
SpamapS(and no spelling abiluhtee eethur)18:51
m_3niemeyer: nope, I'm at mongo-boulder... the mongo gang mentioned you19:47
jcastroSpamapS: hmm, I am debating on wether to post the raw IRC logs of m_3's session20:21
jcastroI am not confident that the session missing the interactions and whatnot is useful for people who want to check it out20:22
_mup_juju/ssh-known_hosts r486 committed by jim.baker@canonical.com20:28
_mup_Merged trunk20:28
_mup_juju/refactor-machine-agent r456 committed by jim.baker@canonical.com20:32
m_3jcastro: yeah, it's weak without the accompanying examples20:35
SpamapSm_3: Oh did you have everybody log into juju-classroom ?20:36
m_3it was either that or an etherpad20:36
jcastrook so I think instead of highlighting past courses, we should just highlight upcoming courses20:36
jcastroand bank on the interactive experience instead.20:36
jcastrowhich involves users more and it's more fun20:37
smoseranyone: https://bugs.launchpad.net/juju/+bug/875903 ?21:13
_mup_Bug #875903: Zookeeper errors in local provider cause strange status view and possibly broken topology <juju:New> < https://launchpad.net/bugs/875903 >21:13
SpamapSsmoser: I saw that one a few times when I beat the heck out of my machine21:16
smoseryeah. i assume its load based.21:17
SpamapSsmoser: IIRC I think we can just bump a timeout up to avoid hitting it21:17
smoserwhere would said timeout live?21:18
SpamapSsmoser: something deep within txzookeeper IIRC21:18
SpamapSwin 5721:40
* SpamapS hates when he reveals how many windows he has open21:40
Daviey57.. that is *weak21:44
hazmatsmoser, its on the roadmap22:20
=== raema is now known as mattrae
med_m_3, nice presentation, thanks for making it so.23:18
_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 >23:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!