[19:49] <designated_> I have a question reagrding juju charms.  I'm currently using juju to deploy services on baremetal with maas on precise.  Are the juju charms supposed to configure the network interfaces on the nodes or does that need to be done manually?  I've noticed various interfaces being referenced within the charms but none of them get configured when a service is deployed (interfaces like eth1 or logical interfaces like br0).
[19:50] <designated_> I just want to make sure I have a good understanding of what the charm is responsible for and not become more frustrated because of unreasonable expectations.  If the charms are not responsible for configuring those interfaces, that's fine, I just want to be aware of that fact.
[19:52] <rick_h_> designated_: it's a questions on the juju radar.
[19:52] <rick_h_> designated_: right now most charms can open/close ports
[19:53] <rick_h_> they don't know or expect having dual nics
[19:54] <rick_h_> designated_: there's work and idea in progress to support networks as more of a 1st class citizen, but I don't think charms will be responsible so much. It's hard to colocate and such in some of those situations.
[19:54] <designated_> rick_h_: thank you for the answer, just to clarify, if i configure interfaces manually (physical or logical), and then reference them in the charm config, those interfaces will get used correct?
[19:55] <rick_h_> designated_: I think so. If you configure the baremetal and the charm has access to that then the charm can use it well enough
[19:56] <rick_h_> designated_: but existing charms aren't built around the idea atm and it makes things hard to reuse in other cloud environments
[19:57] <designated_> sounds like juju was designed more for cloud service deployment, like deploying on openstack for example and installing services on metal was an afterthought.  that clears things up.
[19:57] <rick_h_> designated_: well, it's something thought about. I'd keep an eye on the future.
[20:01] <designated_> rick_h_: thanks alot that clarifies a lot of the problems I've been having.
[20:11] <hazmat> designated_, well.. not entirely.. re juju   on baremetal.. some additional networking support is landing now (targeting vlans which get configured exposed in maas).. and its used quite often for deploying clouds on baremetal. but  yeah atm, juju isn't going to do anything special wrt to nic bonding, nic setup.
[20:12] <hazmat> designated_, out of curiosity what sort of use cases do you have or would want to see here, just setting up vlan nics? and targetting workloads to vlans?
[20:13] <designated_> eventually, link aggregation(bonding), vlan tagging, right now I'm just trying to use multiple physical interfaces and the juju charm didn't seem to be doing any network interface configuration, physical or logical.
[20:16] <hazmat> designated_, and wrt to net conf needed, just enumerate devs and dhcp on them?
[20:16] <hazmat> designated_, the notion is that some of this should be in maas as its the provider..
[20:17] <hazmat> the degree of 1st class networking support in juju is more along sdn lines, configuring vlans, routes, etc.
[20:18] <designated_> To resolve the NIC mapping inconsistencies, i spent some time yesterday writing a shell script to go through and map pci bus (in ascending order) to eth name for consistency, so that when we reference interface names in a charm it will consistently be the same across all physical nodes.  This then gets downloaded in the preseed and executed before the node reboots.
[20:18] <hazmat> designated_, interesting
[20:19] <designated_> had i known that all network interface needed to be configured before the charm gets ahold of it, I would have spent more time on that as well.  looks like it's back to the preseed to see if I can get maas to configure all physical network interfaces and possibly create all of the logical interfaces.
[20:19] <hazmat> designated_, the maas team would probably be interested in hearing about that or seeing if the script if your willing, i'm not entirely clear where they are with that and using the preseed/enlistment image for config
[20:20] <hazmat> fwiw maas mailing list.. https://lists.launchpad.net/maas-devel/
[20:22] <hazmat> designated_, re the  advanced networking blueprint for maas https://blueprints.launchpad.net/maas/+spec/t-cloud-maas-advanced-networking
[20:22] <designated_> the logic is pretty simple, get a list of pci bus numbers, iterate through each one in ascending order and replace the name in the file udev creates, /etc/udev/rules.d/70-persistent-net.rules.  the script then gets downloaded in the preseed and executed before rebooting.
[20:24] <designated_> if you want it, I thre it on pastebin http://pastebin.com/WfTdPjtw
[20:25] <designated_> s/thre/threw
[20:25] <designated_> don't judge my hack of a bash script, I'm not a programmer by any means.
[20:26] <hazmat> designated_, thanks
[20:27] <hazmat> designated_, if you want it in maas, i'd recommend filing a bug against launchpad.net/maas
[20:35] <designated_> hazmat: I would have thought this would be a more common problem.  couldn't find anything on the internet about how to deal with inconsistent mac to name or pci bus to name mapping so I wrote that to deal with it.  there might be a better way or it could be addressed elsewhere but I couldn't find anything.
[21:20] <zchander> Hi all, I have written some additional hooks for the owncloud charm, to support Ceph (like the MySQL charm does), but how can I deploy this to my environment?
[21:21] <zchander> Charm is in ~/owncloud_xjm/owncloud and juju deploy local:owncloud_xjm/owncloud gives me ERROR cannot get latest charm revision: charm not found in "/home/madmin/owncloud_xjm/owncloud": local:precise/owncloud
[21:21] <lazyPower> zchander: juju deploy --repsoitory=$HOME/charms local:owncloud
[21:22] <lazyPower> zchander: ah wait, what i wrote wont work. Your charm repository needs to resemble the correct structure

[21:22] <lazyPower> the series needs to be in that path otherwise it wont know what series your charm is targeting.
[21:22] <zchander> Ah, seems logical (now I know this, the error seems logical ;) )
[21:23] <lazyPower> :)
[21:23] <jose> lazyPower: congratulations on being accepted as a charmer!
[21:23] <lazyPower> Thanks jose :)
[21:23] <zchander> And deployed... Now making the relation
[21:33] <lazyPower> zchander: I encourage you to pick up amulet testing with your charm modifications and extend the existing tests on the charm
[21:33] <lazyPower> https://code.launchpad.net/~lazypower/charms/precise/owncloud/tests
[21:34] <zchander> I'll try that later on..... I have created one new (python) script with two aliases. but it seems like this new file (incl aliases) aren't deployed ??
[21:34] <lazyPower> the file you created isnt there? or the dependencies?
[21:35] <zchander> The file I created isn't in <charm>/hooks
[21:36] <zchander> (it seems)
[21:36]  * zchander is scratching his (already) bald head
[21:37] <lazyPower> zchander: show me your deploy command. Lets verify it didnt deploy from the charmstore
[21:37] <zchander> juju deploy --repository=$HOME/owncloud_xjm local:owncloud --to=8
[21:37] <lazyPower> hmm
[21:37] <lazyPower> seems correct
[21:37] <zchander> Complete path -> /home/madmin/owncloud_xjm/precise/owncloud
[21:38]  * lazyPower ponders
[21:38] <zchander> Is uploads the original file(s), also downloads owncloud-6.0.2 (latest version), untars it
[21:38] <lazyPower> perhaps you had an older copy of the charm cached. try doing an upgrade charm
[21:38] <lazyPower> see if it shows up
[21:39] <zchander> I did have the original charm installed on this machine, but I had it destroyed
[21:39] <lazyPower> (note, if your deployment is in an error state, it will wait until all teh hooks have executed in the specified relationship sequence before it does the actual upgrade, and will then kick off upgrade-charm hook)
[21:39] <zchander> Can I also erase the cached version?
[21:40] <lazyPower> not without some voodoo
[21:40] <lazyPower> and i sadly do not posess that vooodoo
[21:41] <zchander> hmmmmmmm, normally I wouldn't care to use some voodoo, but this so new to me, and when I bork a machine I won't be able to fire it up again, until tomorrow morning....
[21:41] <lazyPower> lets not traverse that path then
[21:41] <lazyPower> just upgrade the charm :)
[21:41] <zchander> OK,I'll first install the original owncloud
[21:42] <lazyPower> you shouldn't need to do that
[21:42] <lazyPower> deploy from your local charm, and since its presently deployed, issue upgrade-charm
[21:42] <lazyPower> if there are any changes it will go ahead and upgrade it. Otherwise it will return that its already at the latest version
[21:42] <lazyPower> and refuse to do anything, therefore theres something else amiss
[21:48] <zchander> OK, got the new relation files in place....
[21:48] <zchander> Running juju debug-hooks for now
[21:55] <zchander> First bugs found...... ;) Back to the drawing board? Not yet....
[21:55] <zchander> I'll continue tomorrow. I am going to relax for now and play some BF4.
[21:55] <zchander> lazyPower: Thanks for your help. I might get back with you tomorrow ;)
[21:56] <lazyPower> zchander: np. Let me know when you're ready to dive into amulet. Extending the tests to support the CEPH option will be fairly trivial
[21:57] <zchander> I'll do!
[21:57] <zchander> Good night! (It's 22:57 GMT+1, here)
[23:21] <davecheney> ahoy!
[23:22] <rick_h_> matey!
[23:22] <marcoceppi> o/
[23:24] <davecheney> where's me booty ?
[23:24] <marcoceppi> where ye left it
[23:25] <davecheney> sage
[23:25] <rick_h_> in his trunks!
[23:25] <davecheney> marcoceppi: can i nag you about trusty charms
[23:25] <davecheney> or should i stfu
[23:27] <davecheney> your silence speaks volumes
[23:37] <hazmat> marcoceppi, looks pretty clear.. markdown wins