[04:51] <stub> bdx: If you want to deploy a version of PostgreSQL that is not 9.3 with trusty, then you either need to set the pgdg flag when you deploy (or change it when the charm fails and retry), or have it in some other repository pointed to by the install_sources line. That second option is why it isn't on by default - the many installs where there is no egress.
[04:53] <stub> bdx: For example, we have PG 9.1 packages in our internal archives which get deployed to trusty.
[07:23] <bolthole_> hi late night juju groupies...
[07:23] <bolthole_> I'm wondering if anyone knows who specificaly invented juju? the various writeups I've found on it did not say
[07:28] <bolthole_> I would like to contact the person who invented juju, reguarding some additional ideas I have.
[07:29] <blahdeblah> bolthole_: The person who invented it is not really relevant any more; there are several teams of full-time developers working on it now.
[07:29] <blahdeblah> The best way to discuss those things would be to open a bug on Launchpad, or join the juju or juju-dev mailing list and post your thoughts there.
[07:34] <bolthole_> is that a code phrase for "that person no longer works at Canonical"? :-/  I would like to know how to contact them, because I have some ideas that, while sort of related to juju, are not actually applicable to normal juju itself.
[07:35] <blahdeblah> Not code at all; I don't actually know who invented it.
[07:35] <bolthole_> fair enough :)
[07:36] <blahdeblah> But if that's the path you want to take, juju was renamed from ensemble around 2010/2011, I think, so you might want to Google for that instead.
[15:08] <suchvenu> Hi Matt
[15:08] <mbruzek> suchvenu: hello
[15:09] <suchvenu> Regarding the DB2 design Doc I sent for your review
[15:09] <suchvenu> You mentioned, relation-joined should create unique database-name/username/password so multiple charms can connect to the same db2 instance.
[15:10] <suchvenu> I am creating unique username, password and instance as per config values , but this is done in Config change hook and not in relation hook
[15:10] <suchvenu> Now to create database name in the relation hooks, the charm which needs the DB to be created on DB2 needs to give the DB name to the DB2 charm.
[15:11] <suchvenu> Also some products may need only one DB to be created , while others may need multiple DBs
[15:11] <mbruzek> suchvenu: Yes I think that may be incorrect.  For other database charms I believe this is done in the relation-joined hook so different charm types have different database names.
[15:12] <suchvenu> So how do we control the no of DBs to be created and their names ?
[15:12] <suchvenu> Ok, so the username and password should be provided by the related charm to DB2 charm ?
[15:14] <mbruzek> suchvenu: If you do it per config value it is clear to me that you can not get multiple databases.  Let us assume mediawiki had a db2 relation and so did dokuwiki had a db2 relation.  Your config-changed hook would only create one instance, database, username, and password, but both charms could relate to the ibm-db2 charm.  These both would get the same information and write to each other's database.
[15:15] <mbruzek> suchvenu: I am not a database expert but I know two different services (mediawiki and dokuwiki) using the same database would be a problem.
[15:18] <mbruzek> suchvenu: kwmonroe and I looked into this before we made the recommendation I believe you can make multiple databases in the same instance, so your db2-relation-joined hook would use the service name to create a unique database name.  You could hash the name or just replace the invalid characters.  So in my previous example if you get a relation, and the remote service name comes back as 'mediawiki/0' you can convert that to 'mediawiki0' and 'dokuwiki
[15:20] <mbruzek> suchvenu: that way the DB2 charm could relate to different charms and they would not use the same database name. Check out the mysql or mariadb charms for examples of how this is done.
[15:20] <lazypower> mbruzek you would really need to just split on '/' otherwise mediawiki/1 would turn into mediawiki1 - just chiming in with a slight addendum there
[15:20] <suchvenu> ok. But if any service wants more than 1 DB , how do we control it ? And if they need DB with specific name
[15:21] <mbruzek> lazypower: I don't remember if mysql makes a 'mediawiki1' database or if it makes a 'mediawiki' database for all the units of mediawiki to share.
[15:21] <suchvenu> Also for each user i am creating a separate instance with same name as user name. This is as per one of the review comment i got previously to have unique username, password and instance
[15:22] <lazypower> mbruzek - it uses the service name, and strips invalid characters + anything after the / is dropped.
[15:25] <mbruzek> suchvenu: That may have been a review comment from someone who didn't fully understand how DB2 worked, and if it was me I apologize.  kwmonroe and I looked into the DB2 documentation last night, and you _can_ create different instances, and it appears you can create different instances.  What Kevin and I discussed last night was to have one instance but different database names to make it work more like the other databases we are familiar with.
[15:25] <suchvenu> ok. So one instance name and have mulitple user names to connect to same is what you are proposing.
[15:26] <suchvenu> Db2 has the feature to create multiple instances, that's the reason i implemented it in that way.
[15:26] <suchvenu> I will relook at this one
[15:26] <mbruzek> suchvenu: After yesterday's read of the documentation, I think different instances may be too complicated and doing different database names is the way to go.  I didn't understand what a different instance was different than a different database
[15:27] <mbruzek> suchvenu: What we found from reading the documentation that you would have to create a different host user for each instance and you could give different memory constraints to each instance.
[15:28] <mbruzek> suchvenu: We thought it would be better to give ALL the memory on the host to the one DB2 instance and just create different databases in the one instance
[15:28] <suchvenu> ok. I will explore this one
[15:28] <suchvenu> On removal of a db2 relation the username and password should be destroyed - This also i am not sure whether it will cause any problem if we delete the user
[15:29] <lazypower> suchvenu - those are 2 separate use cases really, consider the db2 charm implements 2 relationships for the 2 styles of use-case where the regular db: relationship  auto-generates the database for the relating charm, based on that charms name. And each unit joining the conversation gets that database name, and a unique username/password combo per unit. This mimics the MySQL and PostGRES charms behavior which many users/applications will fall
[15:29] <lazypower>  into this category. The DB2 charm only sends a connection string back to the relating charm.
[15:29] <lazypower> Consider another relationship db-programmable: where the relating charm can then send the details of what databases it requires, creating 1-n+1 databases and then hands back the multiple database connection strings on the wire. This gives you a pathway to support both use-cases, single charm, and multiple relations enable the behavior outlined.
[15:30] <mbruzek> suchvenu: The user is overloaded here.  You need to create a user on the host to run the db2 instance, but you can create many database users.  The review comment that we left was to remove the database user when the relation was removed.
[15:36] <mbruzek> suchvenu: not the host user running the db2 instance.
[15:55] <kwmonroe> suchvenu: some confusion might be coming because instance users seem to be both linux system users as well as database users.  do you know if you can create separate database users for a given instance?  (for example, can i create 'kevin' as a database user that can access a db in the 'db2inst1' instance?)
[15:56] <kwmonroe> or does db2 require that database users are also instance users, meaning 'kevin' would have to have his own instance to get his own database?
[16:00] <suchvenu> I had created linus users for the new users i created . I need to explore on whether we can create database users and conenct to the single instance
[16:02] <jacekn> is this a known problem in charms generate using "charm compose"? http://pastebin.ubuntu.com/14679942/
[16:03] <lazypower> jacekn - its 'charm build' - and thats a new one. which version of charm tools are you on?
[16:03] <jacekn> lazypower: charm-tools 1.11.1
[16:04] <jacekn> lazypower: wher eare the official docs about "charm build"? links I had saved no longer exist ( https://jujucharms.com/docs/devel/authors-charm-composing/ for example)
[16:05] <lazypower> jacekn  - the devel docs start with building from layers from teh get-started guide - https://jujucharms.com/docs/devel/getting-started
[16:05] <jacekn> that was after I solved this: http://pastebin.ubuntu.com/14679951/
[16:05] <lazypower> https://jujucharms.com/docs/devel/developer-getting-started
[16:05] <lazypower> rather ^ that is the correct link
[16:06] <tertiary> this is probably more of a maas question, but if i were to use maas+juju to create shared storage with gluster, what happens when we need to upgrade the Ubuntu OS. Wont maas+juju basically destroy the machines and rebuild them with the newest OS version? Consequently destroying the shared data?
[16:06] <lazypower> and there is a deeper dive into layers under its topic page - https://jujucharms.com/docs/devel/developer-layers
[16:08] <lazypower> jacekn - sorry about the moving target, the road to 2.0 and the docs has been a bit of a turbulent ride while we re-work and massage the devel docs.
[16:10] <jacekn> also is it expected that juju-local now uses twice as much space? I think it pulls lxc images to disk and then into mongodb?
[16:12] <suchvenu> So in relation joined hook, the db2 charm will create username, password and a DB name (as per the service name which tries to connect to it ) and when the relation is broken the username needs to be deleted. Also we have only one instance name which will be shared by all users and multiple DBs can be created in the same instance.
[16:13] <suchvenu> the username, password will be provided by the related charm in the relation hooks .
[16:13] <suchvenu> Is that right ?
[16:14] <jacekn> lazypower: so any ideas where to do about that error? I am testing in a fresh trusty environment so it may be affecting all charm authors
[16:15] <lazypower> jacekn - i'm attempting to reproduce now in charmbox. seems to work in the :devel flavor when i update charm-tools from pypi - there's a pip 8.x bug that landed in teh 1.11.x series but that was a complaint about pyyaml verion(s)
[16:15] <lazypower> *versions
[16:15] <lazypower> jacekn what layer are you building with? i'd like to keep this as close to your configuration as possible so i can reproduce
[16:16] <suchvenu> When the relation is broken the db username needs to be deleted without disturbing the DBs.
[16:16] <lazypower> kwmonroe ^
[16:16] <jacekn> lazypower: there is no layer yet, I'm writing one on top of 'layer:basic'
[16:17] <lazypower> tertiary - thats a possibility. Unless you have modeled the storage. And even then i'm not 100% sure. I would certainly bring this up on the mailing list
[16:17] <tertiary> i see, thanks
[16:17] <lazypower> tertiary - i feel like this has been answered before, and posting to the list raises visibility, so they can chime in
[16:17] <suchvenu> If any product needs mutiple DBs with specific names ( like for example IBM MobileServer ) let that service create the required DB as per its requirements.
[16:18] <jacekn> lazypower: is there really no way around installing gcc and pulling packages using pypi? I can see that blocking juju deployments due to security policies in many places
[16:19] <lazypower> jacekn - is this in reference to charm build making the wheelhouse?
[16:19] <mbruzek> suchvenu: reading your questions  now
[16:19] <suchvenu> Matt:Kevin: lazypower: Does it sound ok ?
[16:19] <suchvenu> ok
[16:19] <jacekn> yeah it means software is partially outside of OS security patching coverage
[16:20] <jacekn> lazypower: plus compilers on appservers are considered a security risk in some places
[16:20] <lazypower> jacekn - right. I would certainly bring this up on the list as well as a talking point, i dont know that I have a good answer to that question
[16:21] <jacekn> ack. I'll soon report a but about that ImportError: No module named 'charmhelpers.cli' problem
[16:21] <lazypower> jacekn - and using the vanilla charmbox image, i was able to build both - an empty layer with only a layer.yaml containing " includes: [layer:basic]" , and a few other layers i maintain. No issue with charmhelpers.cli :/
[16:21] <lazypower> are you running in a virtualenv or something similar?
[16:22] <mbruzek> suchvenu: That looks correct, except for the part about the "the username, password will be provided by the related charm in the relation hooks"  the db2 charm will create the username and password, the username and password would not be provided by say the mediawiki charm.
[16:22] <mbruzek> the user/pass would be set on the db2 relation, for the mediawiki charm to read
[16:22] <suchvenu> then how do I take the username and password ? Based on service name ?
[16:23] <jacekn> lazypower: nope but who knows, maybe there is somethin on my test box that would affect "charm build" (kind of another reason to stick to apt-get install in the charm rather than ship depds with the charm)
[16:23] <jacekn> lazypower: I can publish my WIP charm somewhere if you want?
[16:23] <lazypower> sure
[16:23] <suchvenu> I mean how do I select any username for the mediawiki ?
[16:23] <lazypower> jacekn lets try that, maybe theres something hinky in that layer path thats causing the problem
[16:23] <jrwren> jacekn: I share your values and I've tried to avoid even installing pip on some of our charms, but most charm authors don't share these values and so many install python-pip and python-dev which pulls in gcc :(
[16:26] <suchvenu> Also I need to explore whether we can create DB users without creating linux system users. If that is not possible, then I am not sure whether removal of users will cause some issues
[16:26] <suchvenu> when the relation is broken
[16:26] <marcoceppi> suchvenu: MySQL creates a unique database schema for every service connected, and a unique user/pass for that schema for every unit connected
[16:26] <mbruzek> suchvenu: I don't think the linux user is directly related to the database user
[16:26] <jacekn> lazypower: hmm I wonder...I wonder if "charm build" found some junk in my "charms/trusty/<charm>" subdirectory and composed the charm on top of it. Let me verify that maybe that's the cause
[16:28] <suchvenu> Matt: I will check this up
[16:28] <mbruzek> suchvenu: if I remember correctly db2inst1 is running the instance and that is needed to start and stop processes, but the db2admin is not a user on the filesystem.
[16:29] <jacekn> jrwren: yes understood. One other things I would point out is that this will happen on all units. So it's fine for small scale but if you want to deploy 100 units that means dozens of GBs that need to go over the network
[16:30] <jrwren> jacekn: yup. If you solve any of these issues, I look forward to hearing how you did so.
[16:37] <jacekn> jrwren: lazypower: hmm OK then so when I started completely fresh it worked. "charm build" must have composed on top of some old files which caused this problem
[16:37] <jacekn> sorry for the noise
[16:37] <lazypower> jacekn ah i htink i may know the issue then
[16:37] <lazypower> charm build is additive, so if an older dependency is embedded, you need to rm -rf the output charm artifact.  We have an open bug on this, as its not clear that this behavior can lead to unexpected behavior
[16:38] <lazypower> removals are hard :/
[16:38] <jacekn> lazypower: aha! that would make sense, thanks for help. If you find that but # let me know I'll meto
[16:39] <lazypower> jacekn https://github.com/juju/charm-tools/issues/83
[16:42] <jacekn> lazypower: is there anything in LP?
[16:42] <lazypower> charm-tools has migrated over to github afaict
[16:46] <suchvenu> Matt : db2inst1 is the username used to install DB2 and it creates the instance and runs it.
[16:46] <suchvenu> db2admin is a db2 utility
[16:47] <mbruzek> suchvenu: OK.  I meant db2admin as the administrative user for db2 then.
[16:47] <mbruzek> I am not an expert in db2, it was just a guess
[16:50] <suchvenu> No, db2admin user doesn't exist
[16:50] <suchvenu> After installing db2 , I see the following users only :
[16:50] <suchvenu> db2inst1:x:1001:1001::/home/db2inst1: dasusr1:x:1002:1002::/home/dasusr1: db2fenc1:x:1003:1003::/home/db2fenc1: db2usr1:x:1004:1001::/home/db2usr1:
[16:51] <suchvenu> where db2inst1, dasusr1 and db2fenc1 are required for installing db2 and db2usr1 is a new user i created as per the config value in DB2 charm
[16:58] <kwmonroe> yeah suchvenu, mbruzek wasn't suggesting that a 'db2admin' system user should be created.  he just meant that there would be a "db2 admin" as a user that could interact with the database without being a system user.
[17:01] <kwmonroe> suchvenu: according to this, there are no "database users".  authenticating to the database requires a system account: http://www.ibm.com/developerworks/data/library/techarticle/dm-0508wasserman/
[17:01] <kwmonroe> "This is different from other database management systems (DBMSs), such as Oracle and SQL Server, where user accounts may be defined and authenticated in the database itself, as well as in an external facility such as the operating system."
[17:04] <kwmonroe> suchvenu: this implies that any new service that connects to db2 will need a new system account.  therefore, in the db relation-joined hook, you should call useradd to create a new user (the username can be a random string), and then call 'db2icrt -u <new-user> <new-user>'.  this will create a db2 instance name based on the new system user you just created.
[17:04] <suchvenu> Kevin : Ok. I was also searching whether we can create database users which are not OS users
[17:05] <suchvenu> right.. I am actually doing this in config changed hook
[17:05] <suchvenu> creating a new user and a new instance
[17:05] <suchvenu> but now that code has to go to relation hook
[17:06] <suchvenu> so in this case when the realtion is broken, and i try to delete the user, it may get into issues
[17:06] <suchvenu> as the db2 instance will be running using this userid
[17:09] <kwmonroe> yeah suchvenu, i suggest you do not remove the system user, but simply drop the instance with 'db2idrop <instance>'
[17:10] <kwmonroe> according to this, the database will remain in tact:  Dropping an instance will not drop your databases, so you will not lose data. You can drop your instance, recreate it and then catalog the databases to make them available. You can use the db2cfexp and db2cfimp commands to export and import instance profiles.
[17:10] <kwmonroe> https://www-01.ibm.com/support/knowledgecenter/#!/SSEPGG_9.5.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0002058.html
[17:12] <cmagina> bundletester is giving me a version conflict error for pyyaml on trusty. it was installed via pip. its looking for 3.11, but 3.10 is installed. the system is a fresh maas deployment to an x86 host
[17:13] <lazypower> tvansteenburgh - is this the same symptom we saw emitting from charm-tools 1.11.x series? ^
[17:13] <suchvenu> ok kwmonroe. I can try this out
[17:15] <tvansteenburgh> cmagina: curious if you installed it in a virtualenv or not
[17:15] <cmagina> tvansteenburgh: just a simple pip install bundletester
[17:16] <tvansteenburgh> cmagina: would you mind trying it in a virtualenv?
[17:16] <cmagina> tvansteenburgh: i can do that
[17:16] <tvansteenburgh> my guess is that pip refused to upgrade the pyyaml system dep that was already installed
[17:17] <suchvenu> kwmonroe: Suppose the related charm needs more than the default db , then its up to that charm to create the DB. DB2 charm will not handle it. Is that approach fine ?
[17:19] <jacekn> where do I report charms.reactive bugs?
[17:19] <jacekn> or "where should I" rather
[17:19] <mbruzek> jacekn: against charm-tools
[17:19] <mbruzek> let me get you a link
[17:20] <mbruzek> jacekn: https://github.com/juju/charm-tools/issues
[17:23] <mbruzek> suchvenu: as long as the database user has the permission to create a database or table that should be fine
[17:25] <suchvenu> Yes the db user has permission to create DB. As per the current implementation where we are not creating any default DB in DB2 charm, we are returnign the db2 user name to the related charm
[17:25] <suchvenu> Using this db2 user the related charm can create DBs
[17:28] <kwmonroe> suchvenu: i think after you create an instance, you will still need to create a db.  but your approach seems fine -- a connecting service should receive the ip, port, user, password, and db name.
[17:28] <suchvenu> yes after creating instance for new user, we need to creatre DB as well.
[17:29] <suchvenu> yes, i was not sending db name . I will add that as well
[17:31] <suchvenu> when we remove the relation the instance name is deleted. Now again if we try to set relation, it will create a new username and instance , right ?
[17:35] <kwmonroe> that's correct suchvenu
[17:35] <suchvenu> i will chk whether the username and instance name exists  and reuse the same if it exists
[17:36] <suchvenu> instead of creating multiple usernames for the same service
[17:36] <suchvenu> i think instance will not have issue, as we are deleting it when the relation is broken
[17:40] <suchvenu> Thanks a lot mbruzek, kwmonroe,lazypower, marcoceppi for your time to clear some of the design related queries i had on DB2 charm. Appreciate your help
[17:43] <suchvenu> I will send updated design doc with the points we discussed today
[17:55] <kwmonroe> thanks suchvenu!!
[18:49] <bolthole> I'd like to write a charm that deploys a webapp to a tomcat service. As such, I think I need to require some kind of relationship between a tomcat charm instance, and my charm, to make sure it gets deployed to the same machine? What should I be looking at for this?
[18:49] <plars> Hi, I'm trying to add an lxc instance to a maas environment with juju-deployer. I have several other ones deployed this exact same with with 'to: lxc:agent-host' in my deployer bundle, so I just copied one of those as I've done before, and made the necessary changes.
[18:49] <plars> but when I try to run juju-deployer, I get an error: 2016-01-28 02:46:03 Invalid service placement snappyx86003 to lxc:agent-host
[18:49] <lazypower> mbruzek - bolthole is asking about tomcat :)
[18:50] <plars> any ideas where to look to figure out what's wrong?
[18:54] <mbruzek> hi bolthole: let me dust that section of my memory off
[18:57] <mbruzek> bolthole: What you are looking for is what Juju calls a subordinate service
[18:57] <mbruzek> https://jujucharms.com/docs/master/authors-subordinate-services
[18:58] <bolthole> Sounds good. thanks
[18:58] <mbruzek> The tomcat charm (written by me) accepts subordinate charms with the juju-info relation.  Look to the openmrs charm for an example.
[18:59] <mbruzek> https://jujucharms.com/openmrs/precise/1
[19:00] <mbruzek> bolthole: It was pointed out to me that tomcat should not use the juju-info relation and instead provide a "webapp" relation or something of that kind, but I have not implemented that yet, and I don't see that in the current cs:trusty/tomcat charm
[19:01] <mbruzek> So that is the way it works now, and if you look at the openmrs code that should help.
[19:02] <mbruzek> bolthole: please let me know if you have any other questions.
[19:02] <bolthole> Hm. Is there really a requirement to have a particular relationship defined in juju, to make use of the subordinate designation?
[19:04] <mbruzek> bolthole: no. But a webapp has some expectations of things (like the directory where it should put the war file).  Currently the openmrs can be a subordinate to any regular charm and that is probably not a good thing.
[19:04] <bolthole> And if there is.. the page you referenced seems to imply I could just define "a standard client-server relation" fpr tjos
[19:04] <bolthole> * for this
[19:05] <mbruzek> bolthole: it probably makes more sense to have tomcat provide a webapp interface and charms that are webapps only consume that
[19:05] <bolthole> ah. so the relationship would define the webapp directory, then
[19:05] <mbruzek> bolthole: yes.  It would be a very basic thing
[19:17] <bolthole> I see that openmrs "requires: tomcat-war:". Wouldnt it be more accurate to say that it *provides* tomcat-war ? And does the other side have to be coded to support the same relation
[19:18] <lazypower> plars - can i see your bundle?
[19:18] <plars> lazypower: sure, one sec...
[19:20] <plars> lazypower: http://paste.ubuntu.com/14681702/
[19:20] <lazypower> plars - try adding the unit number   --to lxc:agent-host/0
[19:20] <plars> lazypower: actually, I am doing it without the bit for deploying agent-host. It's already deployed, but I include it here for clarity
[19:21] <plars> lazypower: I did, same error
[19:21] <lazypower> :-\ hmm... we used the --to operator in our k8s bundle... let me fish that up
[19:21] <lazypower> contrast/compare
[19:21] <plars> lazypower: I've used it *exactly* like this in this same environment on lots of other units
[19:22] <lazypower> yeah, that looks correct
[19:22] <lazypower> looks like there may be a regression or something going on here
[19:22] <lazypower> i'm not positive
[19:22] <lazypower> sorry :(
[19:23] <plars> lazypower: any tips for debugging? or where to go from here?
[19:25] <bolthole> mbruzek: erm. it seems like the tomcat module now already looks for webapp: java-webapp
[19:25] <lazypower> plars not off the top of my head, i've been working with the newer juju deploy bin for the last month or so
[19:25] <lazypower> a lot of that info is now replaced
[19:25] <mbruzek> bolthole: I pulled the trust/tomcat one I don't see that in metadat.yaml, where do you see this?  Are you on precise/tomcat?
[19:26] <plars> lazypower: so is there a better way I should be doing this?
[19:26] <lazypower> plars - aside from upgrading to 2.0-alpha1 and giving it a go
[19:27] <bolthole> I.... think so?  still new to ubuntu. i'm using ubuntu15.10, which I think is "precise", so I was looking at https://jujucharms.com/tomcat/precise/1
[19:27] <lazypower> plars - obv. thats not recommended if this is a production environment
[19:27] <lazypower> bolthole - "wiley" - ftfy :)
[19:27] <plars> lazypower: heh, well it is production, but it's not working
[19:28] <lazypower> bogus :\
[19:28] <bolthole> oh wait. my actual deployed stuff, says verison of tomcat = cs/trusty/tomcat-1
[19:28] <mbruzek> bolthole: yes, https://wiki.ubuntu.com/Releases
[19:28] <bolthole> whcih is .. neither precise, nor wily. wth....
[19:29] <mbruzek> bolthole If you deployed "tomcat" you likely got the precise version (12.04) I think that is how juju defaults. I also see the java-webapp in the metadata.yaml for precise/tomcat
[19:29] <bolthole> whatisthisidonteven
[19:30] <mbruzek> bolthole sorry for the confusion.  I think this change is not in the more recent version of tomcat
[19:32] <bolthole> so... precise is the OLDER version ... butit is better for having more logical relations defined?
[19:34] <mbruzek> bolthole: it appears that someone updated the older version of tomcat with the fix I described earlier, but did not move this to the later version of tomcat.
[19:35] <bolthole> and this is extra sad, since I cant seem to use the "change version" to switch to the older version, in juju-gui.
[19:37] <mbruzek> bolthole: Does it matter to you what version of the operating system you have?  precise (12.04) compared to trusty (14.04)?
[19:39] <mbruzek> bolthole you will still get tomcat7 with either install, both should work very well
[19:40] <bolthole> i have no idea.
[19:40] <bolthole> comparing things, I guess my desktop is 15.10...
[19:40] <bolthole> but i've deployed to azure, which uses  14.04.1 ubuntu imags
[19:40] <bolthole> by default, I guess.
[19:41] <rick_h_> marcoceppi: with resources, what's the charm you've got in your mind that would use the most number of individual resources? (/cc lazypower aisrael mbruzek)
[19:41] <lazypower> rick_h_ - easily the big data stack
[19:41] <rick_h_> lazypower: right, so a single service with how many resources declared? 2, 4?
[19:41] <lazypower> rick_h_ - considering each install ships w/ a 90MB JVM + each component has a suite of jars.
[19:41] <lazypower> cory_fu kwmonroe admcleod1  ^ can you chime in on this? like, ballpack
[19:41] <bolthole> mbruzek I still think whoever "fixed" it, fixed it backwards again. the app should be the thing "providing" webapp. :-/
[19:41] <lazypower> *ballpark
[19:42] <marcoceppi> rick_h_: I'd see about 6 at most
[19:42] <rick_h_> marcoceppi: lazypower k, ty for the feedback.
[19:44] <mbruzek> bolthole: the webapp charm will need to require the "webapp" relationship because a relationship needs both sides.
[19:44] <lazypower> rick_h_  - hey i found a good place to look - https://api.jujucharms.com/charmstore/v5/~bigdata-dev/trusty/cloudera-hadoo-yarn-master-0/archive/resources.yaml
[19:44] <cory_fu> rick_h_: The core Hadoop charms have around 9 resources defined currently, most of which are different arch and versions of the libraries
[19:45] <bolthole> mbruzek technically speaking, using java language, I believe the proper terminology would be that it "provides: webcontainer"
[19:45] <cory_fu> lazypower: This is better: https://api.jujucharms.com/charmstore/v5/~bigdata-dev/apache-hadoop-yarn-master/archive/resources.yaml
[19:46] <cory_fu> rick_h_: ^
[19:46] <lazypower> woo
[19:46] <cory_fu> A couple of those are python deps that go away with layers, and there are a couple dupes for handling older charms that don't have  a version specified and will go away
[19:47] <bolthole> Is there a way to search the store for (Charms that use relation: webapp) ?
[19:47] <cory_fu> But at a minimum it will be 7, until we add new supported versions
[19:48] <cory_fu> Or arches
[19:48] <cory_fu> bolthole: You'd want https://jujucharms.com/provides/webapp or https://jujucharms.com/requires/webapp
[19:48] <cory_fu> But neither of those return any results
[19:49] <cory_fu> bolthole: Here's one that has results: https://jujucharms.com/provides/http
[19:50] <bolthole> got it thanks.
[19:50] <cory_fu> bolthole: You can discover this on the store by going to a charm that you know of that uses a given interface and clicking on the link in the "Connects to:" section on the right, just above the files list
[19:51] <bolthole> thanks
[19:51] <bolthole> so if I want to file a bug "please provide webcontainer", should I do it against tomcat or tomcat7 charm?
[19:52] <bolthole> seems like the tomcat7 writeup suggests tomcat. but the tomcat code seems in chaos  ;-}
[19:53] <cory_fu> lazypower, mbruzek: ^
[19:54] <cory_fu> I think that https://jujucharms.com/tomcat/trusty is the most recent
[19:54] <cory_fu> But I defer to those who have actually worked on it
[19:54] <bolthole> contrariwise... if I want to submit code... can I do that? It seems like stuff owned by "charmers" has some kind of extraspecial layer where people cant submit proposed stuffs through the normal process
[19:54] <mbruzek> bolthole I did a diff between precise and trusty on the tomcat charm.  Only that webapp relation is different
[19:58] <mbruzek> bolthole: do not use tomcat7 that is deprecated, use trusty/tomcat and I can move the fix for precise forward.
[20:00] <lazypower> bolthole - you are correct that "charmer" owned charms have a layer of "special" - they are reviewed and curated charms. You can propose fixes against them through a traditional launchpad merge proposal. This process will change sometime near APril, but we will have docs in place for that process change.
[20:00] <lazypower> bolthole there's docs on contributing here: https://jujucharms.com/docs/devel/authors-charm-store#submitting
[20:00] <lazypower> bolthole - but if this is only to scratch an itch where you dont want a review to block you, you can always publish to your personal namespace, which is covered in the doc as well
[20:16] <bolthole> mbruzek i can wait for the official code fix, thats fine.... Just please fix the naming ;)
[20:16] <mbruzek> bolthole what naming?
[20:17] <bolthole> the usage is backwards. tomcat needs to require 'webapp', not provide it.  Or, it could provide 'webcontainer'
[20:17] <mbruzek> bolthole: that is not wrong, that is a Juju convention.
[20:17] <bolthole> nooo... what i described, matches mysql usage
[20:18] <mbruzek> bolthole: tomcat provides a webapp relationship, that webapps can require.
[20:18] <bolthole> i compared with that first ;)
[20:19] <bolthole> look at it this way.  wordpress is an aplication, that requires a database (mysql) to run. It *requires* mysql
[20:19] <kwmonroe> i think the confusion here is because we're talking about a subordinate relation to tomcat.
[20:19] <bolthole> openmrs is a webapp, that requires a webcontainer (like tomcat) to run. therefore, it *requires* webcontainer
[20:19] <kwmonroe> so bolthole, it is actually correct as written -- tomcat is "providing the ability for a java-webapp to be connected"
[20:20] <bolthole> tomcat is not providing an ability, it is providing a platform/service. just like mysql provides a platform/service.
[20:21] <kwmonroe> yeah, i get the overall descriptions you're using, but when you're talking about a juju charm being subordinate to another, the principal provides that interface, the subordinate requires it.
[20:22] <bolthole> yes. exactly.  tomcat is the principle. it provides webcontainer.   any webapp, Requires a webcontainer to run
[20:22] <bolthole> so rename webapp to webcontainer, and it's all good
[20:24] <kwmonroe> oh, sure - i don't have any skin in the naming of the relation.. just trying to explain why provides/requires may seem reversed in a principal/subordinate context.
[20:24] <bolthole> got it
[20:35] <cmagina> tvansteenburgh: i tested it in a virtualenv and hit the same issue
[20:55] <bolthole> awwright... I have used bzr to make myself a local clone thingie, and made the trivial code changes. trying to push it up to my "personal space"... but its giving me permission denied?
[20:55] <bolthole> ("Cannot create branch at /~s-phil-s/charms/blahblah")
[21:01] <bolthole> lazypower I did try to carefully follow the instructions at that url. but it doesnt seem to work :(
[21:01] <kwmonroe> bolthole: is the ssh-key (~/.ssh/id_?rs.pub) listed in your launchpad account?
[21:01] <bolthole> yes
[21:02] <kwmonroe> bolthole: what's the push command you gave?  just 'bzr push'?
[21:02] <bolthole> ( ssh missing, gives an explicit "you havent registered any keys" error ;)
[21:02] <bolthole> I did a very explicit push as follows:
[21:03] <bolthole> bzr push lp:~s-phil-s/charms/tomcat/trunk.
[21:04] <kwmonroe> hmph, that's looks legit
[21:04] <lazypower> newp
[21:04] <lazypower> missing series
[21:04] <kwmonroe> ah
[21:04] <kwmonroe> bzr push lp:~s-phil-s/charms/trusty/tomcat/trunk
[21:04] <kwmonroe> bolthole: give that a try ^
[21:05] <bolthole> tried it. nope.
[21:05] <bolthole> oh qr
[21:05] <bolthole> wait
[21:05] <bolthole> differnt error
[21:06] <bolthole> "project s-phil-s does not exist"
[21:06] <bolthole> oops typo
[21:06] <bolthole> added tilde back... and it works
[21:06] <bolthole> thats annoying. i thought launchpad was more free-form
[21:08] <kwmonroe> i think it's more restrictive with charms because the ingestion process that scrapes launchpad to pick up namespaced charms needs them in a specific structure -- charms/series/foo/trunk
[21:10] <kwmonroe> alternatively bolthole, if you didn't want to wait for your modified charm to hit the charm store, you can deploy a local charm with "JUJU_REPOSITORY=~/charms juju deploy local:trusty/<newtomcat>"
[21:10] <bolthole> naw I can wait a bit. and want to do this right anyways
[21:10] <kwmonroe> cool
[21:11] <bolthole> so, now, do I do the "proposal to merge" from my branch, or from the main one?
[21:12] <bolthole> the "propose merge" stuff on the web, is a little.. lacking in documentation
[21:12] <kwmonroe> bolthole: you'd do it from your branch.. click the "Propose for merging" link here: https://code.launchpad.net/~s-phil-s/charms/trusty/tomcat/trunk
[21:12] <bolthole> ah okay, now it looks more helpful then :)
[21:13] <bolthole> although I also pushed a precise branch. which one is better? I would think the precise one since thats where charms/tomcat seems to redirect to, but iunno
[21:15] <kwmonroe> well, generally speaking, you'd propose your precise branch into lp:charms/precise/tomcat and your trusty branch into lp:charms/trusty/tomcat.. but in this case, mbruzek already has you beat ;)  he's testing a similiar change to those branches at this very moment.
[21:15] <bolthole> kewl. well, good practice either way :)
[21:17] <kwmonroe> that's the spirit!!  and thanks for bringing this up.. it's the right way to handle webapp subordinates in tomcat. (vs a more generic interface)
[21:27] <jw4> I'm considering using juju to deploy a few services in mesos/marathon, including a webservice app, front end app, postgres, and a cassandra cluster.  Does this even sound reasonable, or would it be too much hassle to use juju to deploy through mesos/marathon?
[21:29] <tvansteenburgh> cmagina: weird. i'll try it in a clean container and see if i can figure out what's happening
[21:29] <cmagina> tvansteenburgh: ok, thanks
[21:33] <firl> anyone know where a list of “actions” that I can send to my openstack charms for neutron would be?
[21:34] <rick_h_> firl: "juju action defined $servicename"
[21:35] <firl> ty
[21:35] <rick_h_> np
[21:43] <firl> anyone know how to have neutron recreate qdhcp/qrouter besides uninstall and reinstall with juju?
[22:00] <lazypower> jw4 - that would be an excellent question on the juju mailing list. one of our isv partners has been working in marathon/juju land for the last 4 months
[22:00] <jw4> lazypower: cool.. will do
[22:00] <lazypower> jw4 - they don't idle on irc, but with a mailing list post, i can signpost them to it.
[22:00] <jw4> +1
[22:01] <lazypower> :) happy to help. ping me when you've sent so i do it before i forget.
[22:02] <jw4> will do - is that https://lists.ubuntu.com/mailman/listinfo/juju or https://lists.ubuntu.com/mailman/listinfo/juju-dev?  I assume the former?
[22:02] <lazypower> juju@
[22:02] <jw4> perfect
[22:02] <lazypower> juju-dev is if you're a golang hacker and want to discuss the innards of juju
[22:03] <jw4> It's all coming back to me slowly :)
[22:04]  * lazypower eyes narrow... "wait.... you *were* a core hacker weren't you jw4?"
[22:04] <jw4> uh oh
[22:04] <jw4> now I'm in trouble
[22:04] <lazypower> \o/ man its been a while :D
[22:04] <jw4> :)
[22:05] <jw4> yep; I miss this team :)
[22:11] <mbruzek> bolthole: I created 2 Merge proposals for the problems we discussed today, https://code.launchpad.net/~mbruzek/charms/trusty/tomcat/trunk/+merge/284189
[22:13] <mbruzek> bolthole: https://code.launchpad.net/~mbruzek/charms/precise/tomcat/trunk/+merge/284188
[22:13] <mbruzek> bolthole: Please take a look and let me know if that was in-line from what you suggested.
[22:23] <jw4> lazypower: sent: subject "Mesos / Marathon with Juju"
[22:37] <cory_fu> So, has anyone tried to deal with upgrading an existing deployed service from a non-layered charm to a layered charm?
[22:38] <marcoceppi> cory_fu: nope >:D
[22:40] <cory_fu> I'm running into a pretty big road block because the interface states (well, all of the states) need to be reconstructed without the chain of hooks actually being invoked
[22:41] <cory_fu> Is it reasonable as a community to say that upgrading from non-layered to layered charms just isn't feasible?
[22:43] <cory_fu> marcoceppi: ^?
[22:54] <marcoceppi> cory_fu: it's possible. but couldn't upgrade hook do this?
[22:54] <marcoceppi> cory_fu: the only thing it cant' really do is relation stuff
[22:55] <marcoceppi> can't really do *easily*
[22:56] <marcoceppi> cory_fu: want to jump on a hangout in like 5 mins?
[22:56] <marcoceppi> maybe 10 mins
[23:03] <lazypower> jw4 done and done
[23:06] <jw4> awesome sauce
[23:11] <cory_fu> marcoceppi: You up for that hangout?