[05:16] <jose> hey guys, do you think a dnsmasq charm would be suitable for the charm store?
[06:01] <davecheney> jose: sure
[06:01] <davecheney> but it sounds like a subordinate
[06:01] <davecheney> well, maybe
[06:01] <davecheney> it could be either
[10:58] <overm1nd> hi guys, how I deploy a machine from a juju client on a different architecture (like juju on ARM -> to a amd64)?
[11:42] <overm1nd> hazmat I opened an issue for juju-docean here: https://github.com/kapilt/juju-digitalocean/issues/17
[11:42] <overm1nd> don't hate me :P
[11:43] <hazmat> overm1nd, no worries.. so that's a failing of the plugin, easy to address as well.
[11:44] <overm1nd> :)
[11:53] <hazmat> overm1nd, interesting though. i didn't bother with arch.. because there is only one arch on docean
[11:53] <hazmat> overm1nd, but it sounds like your running into juju wanting to use the client arch when provisioning?
[11:54] <overm1nd> yes
[11:54] <hazmat> cool, easy fix.. one moment
[11:54] <overm1nd> i 'm using juju from an ubuntu on arm
[11:55] <overm1nd> and if I don't use the arch parameter it fails
[11:56] <overm1nd> because the are no upload tools for my environment of course
[12:01] <hazmat> overm1nd, i pushed a fix to git.. i'm not sure if that's enough though.
[12:02] <hazmat> overm1nd, if it still errors (it will be a different place) please attach the new traceback to the issue
[12:04] <overm1nd> great, let me check
[12:19] <overm1nd> hazmat I updated the issue
[12:20] <hazmat> overm1nd, yeah.. reproduced
[12:23] <hazmat> overm1nd, new version and test pushed
[12:24] <overm1nd> in pip or github?
[12:24] <hazmat> overm1nd, github
[12:24] <overm1nd> ok
[12:49] <overm1nd> hazmat updated
[12:49] <overm1nd> still some problems but I don-t know if is related to the juju/docean
[12:50] <hazmat> overm1nd, docean occassionally messes up i've noticed.. i've had a stuck instance with them before and had to contact support, some sort of issue with their hypervisor.. they extended credit for it.
[12:50] <hazmat> only happened once in roughly 150 instances launched
[12:51] <hazmat> overm1nd, that looks like the instance is stuck booting.. ie it never comes up before the ssh timeout.
[12:51] <hazmat> hmm
[12:51] <hazmat> actually that's different, pre the ssh check
[12:52] <hazmat> that looks like it never launched
[12:53] <hazmat> overm1nd, contact support its just a bad instance it looks like.. the plugin gives up if the api doesn't get to 100% completion on a start instance action within 3.5 m
[12:53] <bac> hey benji i saw you held the charmworld 'maintainers field' card for a while.  did you produce anything worth passing along to me as i start it?
[12:54] <overm1nd> ok hazmat
[12:54] <overm1nd> thx
[12:55] <benji> bac: no, not really.  I found that the existing "maintainer" field was intended to support a list of maintainers so I spent several hours trying to get that to work, but then I found out that it had been decided beforehand that the field name must be "maintainers"
[12:55] <overm1nd> I will start another machine in the mean time
[12:55] <hazmat> overm1nd, sounds good
[12:55] <bac> benji: ok, thanks
[13:00] <overm1nd> mmm another machine  stucked
[13:00] <marcoceppi> benji: there was some discussion on the list about having the metadata.yaml file support both maintainer and maintainers
[13:00] <marcoceppi> bac: ^
[13:01] <overm1nd> it-s the plugin I think hazmat
[13:01] <bac> thanks marcoceppi
[13:08] <hazmat> overm1nd, unlikely..
[13:09] <overm1nd> I tri to bootstrap a machine from thre panel
[13:09] <overm1nd> try+
[13:09] <overm1nd> let's see
[13:14] <hazmat> overm1nd, looks like digitalocean api and console is just broken atm
[13:15] <hazmat> overm1nd, http://www.digitaloceanstatus.com/
[13:15] <overm1nd> ahah right
[13:15] <hazmat> that's from a few days ago
[13:15] <overm1nd> I cannot start a droplet even from the panel
[13:16] <hazmat> overm1nd, yeah.. i just verified this is universal on #digitalocean
[13:17] <overm1nd> good to know the plugin should work
[13:37] <hazmat> overm1nd, its working again.. but it might be too slow for the plugin
[13:37] <hazmat> i'll have to add timeout as a cli param i think
[14:38] <gnuoy> mbruzek, I have a charm that's waiting for review. I just wanted to check it wasn't being skipped over on the assumption an IS person was going to review it. If its in the queue thats fine and I'll get back in line :)
[14:38] <gnuoy> oh, its the content-fetcher one
[14:39] <mbruzek> Hello gnuoy.  Let me check where it is.
[14:39] <gnuoy> thanks
[14:40] <gnuoy> Bug#1296720
[14:40] <_mup_> Bug #1296720: Bug to track submission of content-fetcher charm to charm store <Juju Charms Collection:New> <https://launchpad.net/bugs/1296720>
[14:40] <mbruzek> gnuoy, The Review Queue can be found here: http://manage.jujucharms.com/tools/review-queue
[14:40] <jcastro> marcoceppi, lazyPower, mbruzek: hey so you guys now how rails and node need a git URL to deploy an app right
[14:40] <jcastro> and for rails it's one of pavel's branches.
[14:40]  * lazyPower nods
[14:40] <jcastro> I was thinking about filing a bug that we should include a Hello World app for each of those charms
[14:40] <jcastro> so that we can test them
[14:40] <lazyPower> jcastro: good plan
[14:40] <gnuoy> mbruzek, ah, I didn't know about that page (or maybe I forgot)
[14:40] <mbruzek> gnuoy  I see your request in there, and it looks like it is in the middle.
[14:41] <jcastro> like, if you don't have a node app handy how can we test the node charm, etc.
[14:41] <gnuoy> mbruzek, thats fine, thanks
[14:41] <lazyPower> jcastro: make sure you include the specs on what you want it to do, as in, if it should have a database dependency
[14:41] <jcastro> yeah
[14:41] <lazyPower> or be a stand-alone app
[14:41] <lazyPower> but i'd be game for buliding a hello-world rails app for the charm
[14:42] <mbruzek> gnuoy It is in the proper place, we have many reviews to do.  Someone will get to it hopefully soon.
[14:42] <gnuoy> sounds good, thanks
[14:44] <lazyPower> gnuoy: I'll try to get some reviews in tonight when i'm at the hotel. Is this charm review blocking work for you?
[14:45] <gnuoy> hi lazyPower, no its not blocking us. We have a few places we're going to use it when reviewed but its not zOMG urgent
[14:45] <gnuoy> and thanks
[14:45] <lazyPower> Ok. Just checking :) if its actively blocking you from moving forward and its urgent - feel free to ping me direct and I'll promote it on my list.
[14:45] <jcastro> gnuoy, and if someone from your team(s) wants to help us dig through this queue ... :)
[14:46] <gnuoy> jcastro, yeah, fair point
[14:46] <lazyPower> jcastro: <3
[14:51] <gnuoy> Do you have a set procedure to work through for a review ? Must pass charmproof and work on provider x & y etc?
[14:51] <jcastro> gnuoy, https://juju.ubuntu.com/docs/reference-reviewers.html
[14:51] <gnuoy> thanks
[14:55] <gnuoy> I'm a fan of Bug#1277652. Would a charm be bounced for missing default values ?
[14:55] <_mup_> Bug #1277652: charm proof should not warn for missing default values <Juju Charm Tools:New> <https://launchpad.net/bugs/1277652>
[14:56] <lazyPower> gnuoy: if it comes up in charm proof, it should be noted in the review
[14:57] <lazyPower> gnuoy: anything above i, warns are not blockers but warrant call-outs
[14:57] <gnuoy> ack
[15:11] <webbrandon> yeah auto complete working with service names!  thank you
[15:11] <webbrandon> little things that make the difference sometimes
[18:07] <tvansteenburgh> i am a charm that exposes the website interface, and i'm in a relation with haproxy. in a config-changed event, my port changes. how do i inform haproxy?
[18:36] <lemao> ola! Is there a juju roadmap available somewhere? I am curious to know what is in store for Juju in the future.
[18:37] <sarnold> world domination of course :)
[18:40] <avoine1> lemao: maybe you will find what you want in here: http://summit.ubuntu.com/uds-1403/meeting/22208/juju-core-update-for-1404/
[18:41] <avoine1> and here: http://summit.ubuntu.com/uds-1403/meeting/22207/juju-gui-update-for-1404/
[18:42] <lemao> sarnold: :-) sounds good as long as 'do no evil' is part of the roadmap
[18:46] <lemao> avoine: thanks
[18:49] <webbrandon> I think `juju status` should show any hook that is running.  My set new config takes awhile and it would be nice to see if the hook is done.
[18:50] <arosales> tvansteenburgh: hello
[18:50] <tvansteenburgh> arosales: o/
[18:51] <arosales> tvansteenburgh: is relation changed what you are looking for?
[18:52] <marcoceppi> tvansteenburgh: you need to invoke relation-set out of band
[18:52] <marcoceppi> tvansteenburgh: which requires you to know the relation_id
[18:52] <arosales> lemao: http://summit.ubuntu.com/uds-1403/meeting/22209/state-of-the-juju-ecosystem/ is also a good one in adtion do the ones sarnold caleld out
[18:53] <sarnold> heh, it was avoine who was useful :)
[18:53] <arosales> ah yes, avoine, sorry I read that wrong
[18:53] <tvansteenburgh> marcoceppi: so you're saying the user would be responsible for doing that if he changed the website port?
[18:53] <marcoceppi> tvansteenburgh: during relation-changed, you'll want to record JUJU_RELATION_ID and JUJU_REMOTE_UNIT somewhere
[18:53] <marcoceppi> tvansteenburgh: no, it's doable in the charm
[18:54] <tvansteenburgh> ok
[18:54] <arosales> marcoceppi: would this be a good use case for juju run?
[18:54] <marcoceppi> arosales: no, this is something the charm should do
[18:54] <marcoceppi> the user initated the change with juju set, no need to make them /also/ do juju run
[18:54] <marcoceppi> tvansteenburgh: so once you have those, you can use relation-set from outside of a relation hook
[18:54] <arosales> I thought a charm could do "juju run"
[18:54] <marcoceppi> arosales: maybe?
[18:55] <tvansteenburgh> oh ok, so i can call relation-set from inside my config-changed handler?
[18:55] <marcoceppi> Idk, only know about the client side juju run
[18:55] <marcoceppi> tvansteenburgh: yeah, relation-set -r JUJU_RELATION_ID key=val JUJU_REMOTE_UNIT
[18:55] <arosales> ya I need to confirm that feature
[18:55] <tvansteenburgh> marcoceppi: excellent, thanks
[19:06] <Fishy__> Has anyone seen when booting nodes off a MAAS server.. node makes it halfway though the boot...   then times out?
[19:07] <Fishy__> Filename: pxelinux.0     tftp://192.168.4.1/pxelinux.0................ Connection timed out (http://ipxe.org/4c126035 )
[19:08] <lemao> arosales: thanks.
[19:09] <lemao> one feature I am looking for is the ability to manage application state while starting/stopping juju charms. e.g. backup a db schema before decommissioning a juju charm and machine and vice versa
[20:23] <lemao> is is possible to achieve the above with juju as it is? I basically don't see a start/stop life cycle event
[20:35] <mbruzek> lemao the start is called by juju after install, and stop is called by juju just before destroy
[20:36] <mbruzek> lemao I would back up stuff in the  *relation-departed hook.  That is what it is inteded for iirc
[20:38] <mbruzek> Other than calling start and stop from within  a hook I don't believe you can make juju call start or stop on your own.
[20:38] <mbruzek> Feel free to chime in if someone knows differently.
[20:38] <lemao> mbruzek: I see. My ultimate goal is to be able to provision a whole environment without ever having to manually log in to the env machines. This is trivial in the common case, but trickier to get done right when dealing with out-of-place upgrades or decommissioning customer tenants etc
[20:39] <lemao> mbruzek: So I may have existing data when provisioning an environment X that I want to pre-populate before the service runs
[20:39] <mbruzek> Your comment above was about backing it up?
[20:40] <lemao> mbruzek: yes, that is part of it.
[20:41] <mbruzek> lemao, My suggestion for that approach is to have a configuration option that points to the data.  The install hook could install the software but leave it unconfigured until the user sets the configuration value with the pre-populated data
[20:41] <lemao> mbruzek: If I am upgrading an existing env X from 1.0 to 2.0, I will need to backup all services (the ones that have data), launch env Xv2 and restore the data there
[20:41] <mbruzek> So your config-changed hook would finish the install and load the pre-populated data
[20:42] <mbruzek> Again I think config-changed hook is where you want to concentrate on.
[20:42] <mbruzek> All this sounds like input from the user.
[20:42] <lemao> mbruzek: I basically want to make sure that I am not trying to squeze something out of juju that was not really part of the requirement.
[20:43] <mbruzek> juju deploy lemao-charm
[20:43] <lemao> mbruzek: that is great. I really like the devops in the large approach that juju takes
[20:43] <mbruzek> juju set lemao-charm version="1.0"
[20:43] <mbruzek> Do some stuff, time to upgrade
[20:43] <mbruzek> juju set lemao-charm version="2.0"
[20:44] <mbruzek> config-changed hook is called
[20:44] <mbruzek> In the config-changed hook you could save the data to a directory and when the new software is installed it could load from the same directory.
[20:46] <lemao> mbruzek: I see. This would take care of the inplace upgrade. But I guess I could achieve the same with an out-of-place upgrade, right? I.e. in a stop hook, save the data, deploy the charm, and on start hook restore it.
[20:47] <mbruzek> lemao, As I said stop is called when juju is destroying that machine.
[20:47] <mbruzek> So if you saved the data on that system, there would be no way to get it back.
[20:47] <mbruzek> from that system
[20:48] <mbruzek> You could dump it to a database and reload from a database relation
[20:48] <lemao> mbruzek: is there a stopped state as opposed to running or destroyed?
[20:48] <mbruzek> Not that I am aware of.
[20:49] <lemao> mbruzek: One where the services and/or machines are not running but the service state (config/relations) are persistent (I guess stored as a bundle)
[20:50] <mbruzek> lemao, I do not know of something like that.  You would have to push the data off the machine and grab it back
[20:52] <lemao> mbruzek: ok. thanks for the information!
[20:52] <mbruzek> lemao, anytime, and good luck!
[20:53] <lemao> mbruzek: one additional question (unrelated to the above), if I may
[20:53] <mbruzek> lemao, shoot
[20:54] <lemao> mbruzek: For a typical webapplication, I assume the common practice is to model tomcat as a charm and my-web-app also as a charm and have them related to each other.
[20:55] <lemao> mbruzek: so I could have N webapp charms related to the tomcat charm.
[20:55] <mbruzek> lemao, There is already tomcat7 charm out there.
[20:56] <lemao> mbruzek: yes, I saw that. but is this how people are deployment webapps, for instance, using juju?
[20:56] <mbruzek> you can create a subordinate charm, that deploys the web app to the same machine as tomcat.
[20:56] <mbruzek> https://juju.ubuntu.com/docs/authors-subordinate-services.html
[20:57] <mbruzek> I wrote a charm that does this for OpenMRS.
[20:57] <mbruzek> http://manage.jujucharms.com/charms/precise/openmrs
[20:58] <mbruzek> there is also a j2ee-deployer charm that has not landed in the store
[20:58] <mbruzek> http://manage.jujucharms.com/~robert-ayres/precise/j2ee-deployer
[20:58] <mbruzek> take a look at those
[20:59] <lemao> mbruzek: thanks a million! Will do.
[21:00] <mbruzek> lemao, you are welcome
[21:46] <lemao> me again ... :-) What would be the best way to add support for additional AWS features such as RDS, VPC, ELB, etc? As a provider or as a charm?
[21:47] <lemao> when deploying a charm to an amazon environment an EC2 machine is automatically provisioned. Is it  possible to have juju launch an RDS instance instead?
[22:48] <Valduare> hows it going guys