=== zyga-afk is now known as zyga
[05:46] <zooko> Oookay, so should my juju scripts inform one node of the existence of another node in "install", or in "start", or in some other script?
[05:46] <zooko> The example in here: https://juju.ubuntu.com/docs/write-charm.html does it in db-relation-changed, but I don't exactly see how .. what would be analogous for my software.
[05:50] <zooko> Oh, I think I see it.
[05:50] <zooko> From https://juju.ubuntu.com/docs/charm.html, I think that I should define a relation of "introducer".
[05:50] <zooko> Getting sleepy. Maybe bang on it some more after some sleep...
[05:59] <koolhead17> zooko: best way is to grab a exisitng charm and see/dig into
[06:01] <zooko> koolhead17: well I've done that with the drupal one in the example.
[06:01]  * zooko looks  at the hadoop one
[06:02] <koolhead17> zooko: hadoop one will fit the charm your writing
[06:09] <zooko> So... yeah I think I'll define a "relation" of "introducer"...
[06:10]  * zooko looks at http://jujucharms.com/charms/precise/hadoop/hooks/datanode-relation-changed
[06:11] <zooko> Yikes,there's a lot of code in there.
=== zyga is now known as zyga-gone
[06:24] <zooko> Hm...
[06:24] <zooko> http://codepad.org/EYUOJnKk
[06:24] <zooko> Now I've defined a relation.
[06:25] <zooko> But, will the "tahoe-lafs" charm have both "requires" and "provides" for this relation?
[06:25] <zooko> Or should I have a separate "tahoe-lafs-introducer" and "tahoe-lafs-storage-server" charm?
[06:25] <zooko> Okay, in another window my upload of a 1.6 GB file through Tahoe-LAFS to Amazon S3 is almost completed successfully, at which point I'm going to shutdown the Amazon EC2 instance and get some sleep. :-)
[06:28] <koolhead17> zooko: requires is for is there any deps for the charm
[06:29] <zooko> So, tahoe-lafs uses any number of storage servers.
[06:30] <zooko> Each storage server has some storage, such as having a direct attached spinning disk
[06:30] <zooko> or having access to an S3 bucket.
[06:30] <zooko> The storage servers could each be running on different machines in different locations on the globe, or whatever -- they just need to be reachable via TCP.
[06:30] <zooko> Now, there is exactly one introducer, whose job it is to inform each client about the IP addresses and public keys of all the storage servers.
[06:31] <zooko> So, I'm trying to figure out how to write into the charm that when deploying a new Tahoe-LAFS grid, you have to first create and launch the singular introducer,
[06:31] <zooko> then get its IP address and public key from it
[06:31] <zooko> then every time you add a storage server, you have to tell that storage server the IP address and public key of the introducer.
[06:31] <zooko> That's all I'm trying to accomplish at the moment.
[06:33] <zooko> I'm wondering if I need to have a hook script that gets called after a storage server launches, and that script calls
[06:33] <zooko> https://juju.ubuntu.com/docs/charm.html
[06:33] <zooko> calls relation-set to set its IP address and public key?
[06:34] <zooko> And then the hook script that gets run for each storage server... at some point in the process of creating that storage server, could call relation-get to get that information ??
[06:46] <zooko> Okay, I'm about to crash, but I'll return to this channel when I wake and I'll hope that someone will guide me through this.
[07:25] <koolhead17> when am trying to get juju credentials from <IP>/settings/juju/ it throws internal server error
[07:25] <koolhead17> is it a known issue? am using Essex on PRecise
[07:25] <koolhead17> *precise
[07:25] <koolhead17> i am able to download Ec2 credentials and openstack credentials
[07:26] <koolhead17> lynxman: ^^
[08:08] <jamespage> jcastro, I think I remember volunteering for something like that at UDS
[08:08] <jamespage> but I can't remember the detail - I would not normally attend pycon so it would be todo a charm school/presentation or whatever if so
=== zyga-gone is now known as zyga
[11:57] <hazmat> marcoceppi, how'd you do at trivia night?
[11:58] <hazmat> the dcpython meetup was fun, someone brought a nao robot
[12:05] <marcoceppi> nice!
[12:05] <marcoceppi> hazmat: we placed 2nd of 12 teams
[12:06] <hazmat> marcoceppi, impressive
[12:10] <marcoceppi> hazmat: I keep forgetting you're in the DC area, would love to hang out and hack on juju stuff some time
[13:29] <jcastro> m_3: hey don't forget to submit for puppetconf
[13:29] <jcastro> (unless you did already, in that case "great!")
[13:50] <jcastro> jimbaker: heya, check the scrollback for some stuff zooko needs help with
[13:51] <jimbaker> jcastro, sounds good
[13:52] <zooko> Morning!
[13:52] <zooko> Yeah, this probably reflects on me more than on Juju, but I was perplexed.
[13:53] <zooko> Maybe what's going on is that Tahoe-LAFS is subtly or not-so-subtly different from typical software, so it doesn't map well to Juju.
[13:53] <jcastro> it's ok, this is the sort of thing we should figure out
[13:55] <jimbaker> zooko, this hub & spoke topology works well w/ juju
[13:55] <zooko> I suspect one thing that complicates it is that in Tahoe-LAFS some information gets generated inside one node when it first starts up, and then that information is required to be provided to other nodes to configure them
[13:55] <zooko> .
[13:55] <zooko> So you can't just script "Set this up then set those up"
[13:55] <zooko> without scripting "extract that information from the first one" somehow.
[13:56] <jimbaker> zooko, that's really the point of the negotiation seen in service orchestration
[13:57] <zooko> Hrm. Well, I don't understand this part very well.
[13:57] <jimbaker> zooko, so what you need to do is publish the info on relation settings
[13:57] <zooko> Shall I restate my outstanding questions?
[13:57] <zooko> Aha, that's the answer to one of them. :-)
[13:57] <zooko> "Should I publish that info on relation settings?" ;-)
[13:58] <zooko> That was 1.
[13:58] <jimbaker> each time a unit changes its relation settings, the other unit(s) in the relation run their <relation name>-relation-changed hooks
[13:58] <zooko> 2. Should I have separate charms for different services, or one charm that defines both "provides" and "requires" of that service because it defines both that service and the other things that require it?
[13:58] <zooko> 3. Will someone please spend a lot of money on EC2 instances so that I can run a 5000-node Tahoe-LAFS grid?
[13:59] <zooko> jimbaker: ah, interesting. But, this relation setting would only be done one time, on setup.
[13:59] <jimbaker> zooko, 2) my first instinct is that what you're describing is a peer relation
[13:59] <zooko> So it would be better, I think, to use <thing>-relation-joined ?
[14:01] <jimbaker> zooko, relation-joined is usually not what you want. more specifically, it's a good place to know that a unit is part of the relation. but that unit may not actually be ready, and has published any info
[14:01] <zooko> jimbaker: I see.
[14:01] <zooko> Okay, I guess it will work for <thing>-relation-changed.
[14:02] <zooko> So there'll be a start hook (is that the right hook) that runs when the introducer is created, and that will get the special data (the "furl") and publish it as a relation setting.
[14:02] <zooko> That publication will trigger the other things to have their lafs-introducer-relation-joined hooks run, and they'll query it from the relation settings.
[14:02] <zooko> Perfect! ☺
[14:02] <jimbaker> zooko, like the furl is published as a config setting
[14:02] <jimbaker> likely
[14:04] <jimbaker> zooko, maybe not on second thought. going back, i don't believe the furl is not a human-generated config item
[14:04] <jimbaker> sorry, is a human generated
[14:05] <zooko> It is generated by the introducer itself (a computer program) when it first runs.
[14:05] <jimbaker> instead it's a relation setting between the spokes and the central hub of the introducer service. so that also works
[14:05] <zooko> So, wait, what? Is the plan sketched out above good?
[14:05] <jimbaker> zooko, cool, so it's a relation setting
[14:06] <jimbaker> zooko, probably :)
[14:06] <jimbaker> zooko, so do the spokes need to talk to each in their setup?
[14:06] <jimbaker> each other
[14:06] <surgemcgee> Umm, is it possible to add a my_config.yaml file to a existing service. Will that trigger the config-changed hook? Just want to get some options into a service.
[14:07] <surgemcgee> Says it is not accessible.
[14:07] <zooko> jimbaker: nope -- the spokes need nothing but that one "furl" from the introducer.
[14:07] <zooko> Plus, you know, human-chosen config options.
[14:07] <jimbaker> zooko, ok, you don't have a peer service
[14:08] <zooko> Right.
[14:09] <jimbaker> surgemcgee, this is the point of upgrade-charm. make certain you call it config.yaml
[14:10] <jimbaker> zooko, so each spoke is a client (requires) of the introducer (provides)
[14:11] <zooko> Agreed.
[14:22] <imbrandon> zooko: there is also peer relations too eg requires: provides: peers: in the metadata
[14:44] <zooko> imbrandon: hi! I don't quite understand peer relations, but I'm fairly sure that Tahoe-LAFS doesn't need them.
[15:06] <imbrandon> zooko: well like in 1 of my setups i have a loadbalancing scheme where all the nodes loadbal to each other, so they have a peer join/depart relation that fires and add or removes their IP from the relation config
[15:06] <imbrandon> so each of the nodes knows about all the others to add to their own LB config
[15:06]  * zooko nods
[15:06] <imbrandon> it was somewhat similar to what you described thus thought i;d mention it :)
[15:08] <m_3> morning y
[15:08] <m_3> 'all
[15:08] <imbrandon> heya m_3
[15:09] <imbrandon> i tried a perl script they had linked on the prowlapp.com page, works great , i was gonna modify my script for ya but someone already wrote a irssi plugin :)
[15:09] <imbrandon> just fyi :)
[15:09] <jamespage> jcastro: things all set for tomorrow?
[15:12] <m_3> jamespage: hey... how was jubilee?
[15:12] <jamespage> m_3: rocking!  I think the country finally remember what being British was all about :-)
[15:13] <jamespage> m_3: nice article BTW
=== mrevell_ is now known as mrevell
[15:17] <m_3> ha! my fav description of what it means to be British was john cleese and kevin klein in a fish called wanda from years ago... pretty funny
[15:18] <m_3> jamespage: yeah, lemme know if you have changes to the article
[15:25] <koolhead17> hi all
[15:33] <x_or> I'm getting public address: null after I run juju expose wordpress from the link https://juju.ubuntu.com/
[15:33] <x_or> I don't see anything when I run juju debug-log other than "enabling distibuted debug log ... ctrl-c to stop."
[15:34] <m_3> x_or: the instance is probably still coming up and doesn't have an address assigned yet
[15:34] <x_or> m_3: Yeah, I thought that, but it has been over five minutes.  My other lxc machines come up in a few seconds.
[15:35] <m_3> x_or: the first service you start using a local provider takes a _long_ time to come up... dpending on your connection
[15:35] <x_or> Is there somewhere that juju stores the network interface to use?
[15:35] <x_or> Oh, OK.
[15:35] <x_or> Why is that?  What is happening the first time?
[15:35] <m_3> x_or: (it's downloading a new image).. anywhere from 10-30mins
[15:36] <m_3> x_or: it's using libvirt's "default" network
[15:36] <x_or> Oh, OK.
[15:36] <x_or> So, it does this in the background, I see.
[15:36] <m_3> x_or: and expecting that to be 192.168.122.0/24... although I'm not sure that's necessary any more
[15:36] <m_3> x_or: yeah, we've got a bug open to give a little better messaging while it's doing this :)
[15:36] <x_or> Great.  juju is very exciting.
[15:37] <m_3> yeah, it's fun
[15:37] <x_or> I'm loving lxc, so much lighter than virtualbox or vmware.
[15:37]  * m_3 loves lxc too... will love it even more once local provider is easier to setup/use
[15:38] <m_3> I've done a bunch with libvirt before... new to lxc in the last 6mos or so
[15:38] <m_3> love that it's lightweight
[15:38] <x_or> libvirt is pretty nice.  I was getting a bit confused between docs for lxcbr0 and it, but I got it figured out now.
[15:39] <x_or> I'm having so much better experience with it on a 3 GB linux laptop and five VMs than two machines on 8 GB OSX machine with VirtualBox.
[15:39] <m_3> x_or: confused is understandable... the network config is _the_ hard part right now.  that'll clear up over time though.
[15:39]  * m_3 notes to get peeps to blog more about that setup
[15:40] <x_or> I started a blog post on it, I will see whether I can get that finished first thing next week.  I'm glad it was not just me.  :)
[15:40] <m_3> x_or: awesome!
[15:40] <imbrandon> yea but your not working with something on the level of VBox or VMWare , its more like a chroot on crack
[15:40] <imbrandon> :)
[15:40] <x_or> imbrandon:  This is why I like it.  Lightweight.
[15:41] <x_or> VBox is so heavy, ditto for VMWare.
[15:41] <m_3> yup
[15:42] <m_3> x_or: we're still trying to figure out the best way to do this with osx too.  We have a juju osx client that'll run remote cloud stuff fine... but the local provider story on osx is still pretty weak
[15:42] <imbrandon> depends on your perspective i guess, i see them as light , or even lighter it using a xen hyper, and in turn you get a real virtualized env, not a container
[15:42] <imbrandon> that isnt
[15:42] <imbrandon> m_3: i got 3/4 of a vbox provider for OS X ( and others ) written
[15:43] <x_or> Are you guys canonical employees?
[15:43] <imbrandon> i hoped to have it done by this weekend, well useable by then
[15:43] <m_3> imbrandon: awesome!  vagrant?
[15:43] <imbrandon> m_3: yup
[15:43] <m_3> or just pure
[15:43] <m_3> gotcha
[15:43] <imbrandon> x_or: i am not. most of the devs in here are
[15:44] <m_3> x_or: yeah, it's a mix
[15:44]  * m_3 is
[15:44] <imbrandon> yea actually i take that most part back
[15:44] <imbrandon> heh
[15:44] <imbrandon> its a good mix
[15:44] <imbrandon> m_3: but yea, it is *almost* pure
[15:45] <m_3> vagrant's cool though... great handler stack, like rack
[15:45] <jcastro> imbrandon: RPMs yo
[15:45] <imbrandon> and if i take a extra few days ( i may after the first push ) then it would be
[15:45] <imbrandon> jcastro: rpms are cookin this second
[15:45] <jcastro> unf.
[15:45] <jcastro> hey post on the list when you have something to test
[15:45] <imbrandon> like thats whta i was/am doing today
[15:45] <imbrandon> kk will do
[15:46] <imbrandon> m_3: btw you get charm tools to work on osx ? i have some bad problems with the bsd VS gnu tools but mostly just in charm-tools
[15:47] <m_3> imbrandon: haven't tried
[15:47] <m_3> I actually don't have an osx machine to test on... only ones in the house belong to the wife :)
[15:47] <imbrandon> i might dif some more later, for now i just installed gnu coreutils
[15:47] <imbrandon> dig*
[15:47] <imbrandon> yea i'm actually running linux again full time
[15:48] <imbrandon> but i still am testing / working on the stuff
[15:48] <m_3> imbrandon: is it possible to run recent versions in VMs now?  (my laptop's a mbp, so legally I can run it)
[15:48] <imbrandon> so i keep a partition going
[15:48] <imbrandon> m_3: yup
[15:48] <imbrandon> but only vmware proper
[15:48] <m_3> oh nice... I'll have to google
[15:48] <imbrandon> like esxi or vmware server or player
[15:48] <m_3> looked into it a year or so ago, but no love
[15:49] <imbrandon> vbox and others it would "techinily" work but there are checks in the instller, vmware is the only legit unmodified way to install 10.7 or 10.8
[15:49] <imbrandon> m_3: yea its legit now
[15:49] <m_3> imbrandon: awesome... thanks!  that'll simplify osx testing considerably
[15:49] <imbrandon> they changed it when 10.7 was released
[15:50] <imbrandon> yea it makes it nice, was the reason i was willing to jump ship back to linux so easy too cuz i can keep the old install arround for porting etc
[15:50] <imbrandon> :)
[15:51] <m_3> imbrandon: right... I kept my orig osx drive around in an external hd case... could boot from it when I wanted
[15:52] <m_3> imbrandon: but lately ios update over the air means I don't even do that anymore
[15:55] <imbrandon> yup i;m lovein that
[15:56] <imbrandon> ota itunes syncing too, wonder if i can make banshee do that with my ipad  hrm something for later :)
[15:56] <imbrandon> already got timemachine seeing my linux server as a timecapsul backup dest
[15:56] <imbrandon> :)
=== hspencer is now known as hspencer[afk]
=== al-maisan is now known as almaisan-away
[16:20] <jamespage> jcastro, ping!
[16:49] <jcastro> jamespage: pong
[16:49] <jamespage> jcastro, hey!
=== hasp is now known as hspencer
[18:10] <jcastro> do we _require_ install hooks to be idempotent?
[18:18] <zooko> non-idempotent install hooks sound like a terrible idea. :-)
[18:27] <jcastro> yeah I added a sterner warning in the template
[18:32] <marcoceppi> jcastro: all hooks _need_ to be idempotent
[18:32] <jcastro> ok, it was just missing from the template then
[18:32] <jcastro> incoming charm-tools merge proposal yo
[18:32] <jcastro> marcoceppi: actually my question more for m_3: do we check for idempotency in the charm test and kick that back?
[18:33] <jcastro> I am assuming yes, it wouldn't make sense otherwise
=== benji is now known as Guest68587
[18:36] <marcoceppi> jcastro: I'm not sure if we explicitly check idempotency in the tests, but when I do reviews I test for it
[19:08] <_mup_> juju/trunk r540 committed by kapil.thangavelu@canonical.com
[19:08] <_mup_> merge maas-provider-non-mandatory-port, default ports are inferred by protocol. [a=julian-edwards][r=fwereade,hazmat][f=972829]
[19:27] <m_3> jcastro: no, it's hard to verify that automatically
[19:27] <m_3> jcastro: it's part of the review process
[19:28]  * jcastro nods
[19:28] <m_3> jcastro: a non-idempotent install hook would actually be acceptable if there's a good reason... we haven't made it a hard/fast condition
[19:29] <m_3> I recommend linking upgrade-charm to the install hook... so the idempotency of the hook often depends on that of the underlying tools (like apt-get)
[19:30] <m_3> depends tho
[19:37] <SpamapS> m_3: quantl looks good
[19:38] <SpamapS> m_3: install *still* has to be idempotent
[19:38] <SpamapS> m_3: if there is an error late in the hook, it will be retried .. so the whole thing has to be idempotent
[19:42] <m_3> SpamapS: thanks for looking
[19:42] <m_3> SpamapS: how're things?
[19:42] <SpamapS> m_3: and symlinking upgrade-charm to install isn't really the best way to go. Better to go with stop,install,start,config-changed (the same order that happens on deploy)
[19:42] <SpamapS> m_3: good, first time touching the computer since Monday morning. :)
[19:43] <m_3> ha!
[19:43] <SpamapS> haven't really had the presence of mind to do anything useful with it anyway
[19:43] <m_3> gotcha... good idea about upgrade
[19:44] <SpamapS> m_3: I think we should start thinking about making a declarative charm-helper that does exactly that automatically
[19:44] <m_3> SpamapS: are you daddy+1 yet?
[19:44] <m_3> yeah, it's easy enough
[19:45] <SpamapS> m_3: been thinking about making a feature request for a 'missing-hook' hook that gets called whenever a hook script doesn't exist
[19:45] <m_3> ha!
[19:45] <m_3> that smells _dynamic_ even :)
[19:45] <SpamapS> m_3: yeah it would make declarative charming much easier
[19:45] <m_3> really like that feature
[19:45]  * SpamapS files that feature req
[19:48] <_mup_> Bug #1009687 was filed: charms should be able to provide a 'missing-hook' script <juju:New> < https://launchpad.net/bugs/1009687 >
[19:56] <SpamapS> imbrandon: hey, you broke charm-tools
[19:56] <SpamapS> imbrandon: https://launchpadlibrarian.net/107021470/buildlog_ubuntu-oneiric-i386.charm-tools_0.3%2Bbzr145-2~oneiric1_FAILEDTOBUILD.txt.gz
[19:56] <SpamapS> imbrandon: always run 'make check' before pushing to trunk
[20:04] <SpamapS> jcastro: ^^ you too :)
[20:05] <jcastro> yikes!
[20:06] <jcastro> SpamapS: just make check? I get an error
[20:06] <jcastro> make: *** No rule to make target `check'.  Stop.
[20:06] <jcastro> oh, wrong dir, nm
[20:10] <imbrandon> SpamapS: ahh crap i should know better, was just a readme update :) anyhow i'll fix it here in just a few, got a fire IRL on the phone i'm trying to defuse
[20:13] <SpamapS> its never "just a readme update" when you're changing templates. :)
[20:48] <SpamapS> imbrandon: also can you please include a description of the actual changes when you push to trunk, not just 'merging in jorge's changes'
[20:49] <imbrandon> i did in the lp commit message box. that workflow is so screwed
[20:49] <imbrandon> i'm just gonna ignore LP from now on and do it the right way
[20:50] <imbrandon> looks like it was a test that failed , fixed up in a sec
[20:50] <SpamapS> what lp commit message box?
[20:51] <SpamapS> imbrandon: no, jorge already fied
[20:51] <SpamapS> fixed even
[20:51] <imbrandon> ahh kk sorry was on the phone
[20:51] <imbrandon> but yea the one on ... let me find it
[20:52] <SpamapS> imbrandon: I never use the lP gui for doing merges so I don't know how that even works
[20:53] <imbrandon> yea i tried then when it dident work
[20:53] <imbrandon> i did it by hand the rest of the way
[20:53] <imbrandon> thus a little screwy this time
[20:53] <SpamapS> imbrandon: cool, well thanks for hitting the review queue anyway. :)
[20:54] <imbrandon> kinda like the github mergin, i hate it, its good to see and overview or a small one off, but pita for multi branch merging like i am normally trying to do
[20:54] <imbrandon> SpamapS: i plan on a little more today too , but just got wrapped up in that other, will get some more in a bit
[20:55] <imbrandon> got one my self to toss into charm-helper ( few more bash functions )
[21:02] <imbrandon> SpamapS: what ya think about a X- prefix for random metadata.yaml fields, that takes care of the namespace issue if it ever were to become official etc and lets us add things like x-vcs to the metadata
[21:02] <imbrandon> kinda like the debian rule
[21:02] <SpamapS> imbrandon: no, thats already been rejected and I agree with the rejection.
[21:02] <imbrandon> it was ?
[21:02] <imbrandon> ok , i'll dig in the mailing list
[21:03] <SpamapS> imbrandon: yes, anything thats not ready for metadata.yaml should go in some other yaml file
[21:03] <SpamapS> preferrably one that is named around the tool that consumes it
[21:03] <imbrandon> would be useless for what i just said, and you mean rejected based on the uds convos ?
[21:04] <SpamapS> imbrandon: vcs.yaml would be fine
[21:04] <imbrandon> sure , but then it litters the dir. i'll think on it some
[21:05] <SpamapS> imbrandon: I suggested it way before UDS.. I also suggested a single key that would be for extending things.
[21:05] <imbrandon> ... ?
[21:05] <imbrandon> ok
[21:06] <imbrandon> hrm the top level dir is getting quite littered too
[21:06] <imbrandon> :(
[21:06] <SpamapS> littering the dir is better than littering metadata.yaml I think
[21:07] <SpamapS> because it will only be "littered" in there as long as something sees non-ubiquitous usage. Once it becomes ubiquitous it will go in the next format spec for juju.
[21:07] <SpamapS> right now the TLD has metadata.yaml, config.yaml, and hooks .. not what I'd call littered at the moment
[21:08] <imbrandon> nah because if that becomse standard then i can see things never getting migrated, it happens all the time becose things start looking in the first place it is
[21:08] <imbrandon> SpamapS: copyright
[21:08] <imbrandon> readme
[21:08] <imbrandon> license
[21:08] <imbrandon> config.yaml
[21:08] <SpamapS> license is not a standard file
[21:08] <imbrandon> meta
[21:09] <imbrandon> info.yaml
[21:09] <imbrandon> etc
[21:09] <SpamapS> info?!
[21:09] <SpamapS> you making stuff up now? ;)
[21:09] <imbrandon> well i cant use metadata :)
[21:09] <SpamapS> seems pretty reasonable to me
[21:09] <imbrandon> plus a templates dir for config templates
[21:09] <imbrandon> etc
[21:09] <SpamapS> and if things are migrated they'll be dropped from the charm store.
[21:10] <imbrandon> huh ?
[21:10] <imbrandon> what would be dropped ? i think i missed something
[21:10] <SpamapS> things aren't migrated I mean
[21:10] <SpamapS> charms that don't follow format migrations
[21:10] <imbrandon> oh , right
[21:11] <SpamapS> there will always be a range of formats supported in juju and the charm store
[21:11] <imbrandon> yea i know, was tring to avoid pitfalls of the past, no need to beat a dead horse tho
[21:11] <imbrandon> i'll just passive agressivly stay in da rules :)
[21:16] <SpamapS> which pitfall are we repeating?
[21:17] <imbrandon> i was talking about specific example of x-vcs still x- becuse it was used there first and became wide spread
[21:18] <SpamapS> Its not still X-
[21:18] <SpamapS> thats a lintian violation now
[21:19] <imbrandon> but like i said i'm not trying to make a big deal about it, just no one brought up prefixes that i was aware and the arguments i heard at uds were very vague and week so thought i;d mention it, no biggie tho i can use info.yaml or charm.yaml etc etc just as easy
[21:19] <imbrandon> SpamapS: heh sure , but how many years later ?
[21:20] <SpamapS> the argument was pretty solid actually, that we should stay strict on metadata.yaml so that charms are well defined and so that tools can enforce formats.
[21:20] <imbrandon> that doesnt discount prefexs then
[21:20] <imbrandon> :)
[21:20] <SpamapS> imbrandon: pretty much immediately after Vcs was added to policy, X-Vcs was added to lintian
[21:21] <imbrandon> sure but x-vcs has been in use for about 4 years if not more
[21:21] <imbrandon> before
[21:22] <imbrandon> so i can see alot of tools still looking in the old key , etc
[21:23] <imbrandon> perfect world i see your point and would agree in such a place, and do here just bacause its not worth me choosing that battle
[21:23] <SpamapS> so allowing a prefix will just be the same as pushing things into a different file, except that metadata.yaml stays "clean"
[21:24] <imbrandon> except the file can be named anything and becomes aother varaible its self to find progmaticly
[21:25] <SpamapS> file, field, makes no difference I think
[21:26] <imbrandon> guess not if i just load all the yaml up into spyc with a *.yaml glob :)
[21:26] <SpamapS> that sounds like extra work
[21:26] <imbrandon> then look for the keys and throw a E if keys overlap :)
[21:26] <SpamapS> or just interpret each yaml with the tool that actually is meant to interpret it
[21:26] <imbrandon> yes it is
[21:27] <imbrandon> ...
[21:27] <SpamapS> I'm also puzzled as to your intentions, as Vcs is a bad example I think.. I *HATE* that part of debian and much prefer the Ubuntu way where the path to the source branch is well known from the name+series only
[21:27] <imbrandon> spyc the lib i'm using is indeed made to intrepret yaml
[21:28] <SpamapS> imbrandon: thats a lib, whats the actual tool or field you want to populate
[21:28] <SpamapS> ?
[21:28] <imbrandon> i'm making the tool
[21:28] <imbrandon> and i dont wanna populate it, i want to read it
[21:28] <imbrandon> the x-vcs value in this case :)
[21:29] <imbrandon> like for real that was a real use case
[21:29] <imbrandon> the first one i came accross but i'm sure not last
[21:30] <med_> has anyone out here proposed creating a new provider? Does juju allow for private 3rd party providers?
[21:30] <imbrandon> med_: yes and yes-ish
[21:31] <imbrandon> you can see examples in providers/* they are pretty streight forward
[21:31] <imbrandon> ( in the juju src )
[21:32] <imbrandon> and a few branches on LP of alternate/testing ones like OpenStack++S3 and OpenStack with swift
[21:41] <med_> thanks imbrandon
[21:52] <SpamapS> imbrandon: somebody added X-vcs in metadata.yaml ?!
[21:54] <SpamapS> well anyway, time to nap
[21:54] <m_3> SpamapS: night
[21:59] <imbrandon> SpamapS: that was supose to be only in my branch i pushed both unintentionally and am removeing it
[22:02] <imbrandon> i think charm.yaml will be better suited anyhow the more i think about it, metadata.y dosent definatively say if its data for the charm or the service or both etc , anyhow, time for food here /me is afk