[10:15] <Muntaner> good morning guys o/
[10:16] <Muntaner> I'm having a little issue with security groups
[10:16] <Muntaner> when I delete the charm that I'm developing, the relative security group in nova isn't destroyed
[10:16] <Muntaner> how can I do this?
[15:36] <Muntaner> hello guys
[15:37] <Muntaner> how can I tell to a juju charm which image should it run in his VM when the service is deployed?
[15:37] <lazyPower> Muntaner: that is denoted by the series of the charm
[15:38] <lazyPower> Muntaner: eg: juju deploy trusty/mysql - will tell juju to allocate a trusty VM, and then deploy the charm on top of trusty.
[15:41] <Muntaner> lazyPower, thanks
[15:46] <jrwren> Muntaner: juju has a "default-series" option which you can set in environments.yaml so that if you don't specify a series when deploying, and there are charms in both, it will default to this settings.
[15:59] <R1ck> it states here: https://news.ycombinator.com/item?id=5738252 "I tested juju a few months ago and found it to be buggy and unreliable." this was however from almost 2 years ago. does anybody agree with that statement still?
[16:02] <AskUbuntu_> Adding network to machine deployed by Juju | http://askubuntu.com/q/597514
[16:23] <beuno> R1ck, not at all, we use it for plenty of production services in Canonical, as do many customers
[16:31] <bdx> Hello, I am wondering if anyone can give any insight as to what charm or service parameters determine what interface compute nodes talk to storage on
[16:31] <bdx> ??
[17:02] <jcastro> marcoceppi, around?
[17:02] <marcoceppi> yes
[17:03] <jcastro> so I have a card that's l ike
[17:03] <jcastro> "provide examples to what a good charm looks like"
[17:03] <jcastro> and I'm going through the links in the docs
[17:04] <jcastro> other than ones that should link to new charms, like say, services framework, is there anything in these examples ones like the vanilla forum ones that need to be fixed?
[17:05] <marcoceppi> probably
[17:14] <jcastro> evilnickveitch, heya
[17:14] <evilnickveitch> jcastro, hi
[17:14] <jcastro> the review queue link is 404
[17:14] <jcastro> so I fixed them and pushed but I think you merged before
[17:14] <jcastro> http://review.juju.solutions instead of manage.blah
[17:15] <evilnickveitch> okay, will take a look
[17:15] <bdx> marcoceppi, jcastro: How can I configure nova-compute to use ~(os-admin-network) for storage traffic?
[17:16] <jcastro> I am unfamiliar with the nova-compute charm
[17:16] <jcastro> we have a list for those iirc?
[17:16] <evilnickveitch> jcastro, done
[17:16] <bdx> Ohhh really?
[17:16] <jcastro> thanks
[17:17] <jcastro> jamespage, ^^^
[17:18] <jcastro> evilnickveitch, we should make it so like if a 404 is detected when we build the docs or something it yells at us
[17:18] <jamespage> bdx, hello
[17:18] <jamespage> nova-compute -> ceph?
[17:18] <bdx> jamespage: Hi, hows it going??
[17:18] <bdx> yes!
[17:18] <jamespage> so you're using the public and admin network configuration in the ceph charms right?
[17:19] <evilnickveitch> jcastro, yes, well we had that lint tool before, but that was before we switched to markdown.
[17:19] <bdx> jamespage: Correct
[17:19] <evilnickveitch> it is on my list of things to add to the new universal build tool
[17:19] <jamespage> bdx, ok so the nova-compute nodes will access ceph over the public network IP's  - so if you make the ceph public-network == os-admin-network that should work
[17:20] <evilnickveitch> jcastro, but to be honest, it may take a while until that gets done, looking at all the stuff I have to do
[17:20] <jamespage> this assumes that both ceph and nova-compute are both physically or logically attached to the same networks
[17:20] <bdx> jamespage: Thats what I currently have....
[17:20] <evilnickveitch> jcastro, however, we can probably cobble together a script to do it
[17:21] <jamespage> bdx, what are you seeing?
[17:21] <bdx> Thats the problem....my admin network is 1G....I get bottleneck on the 1G interface
[17:21] <jcastro> evilnickveitch, ok I'll mention it at the sprint, see if someone is willing to have a go
[17:21] <jamespage> bdx, do your compute and ceph nodes have 10G's or alternative 1G's that can be used?
[17:22] <bdx> Yes, I have 2x 1G and 2x 10G on each node
[17:22] <jamespage> bdx, ok - so in that config I'd probably bond the 2 x 1G's and run control plan traffic over that network
[17:22] <bdx> jamespage: Here is what my 1G os-admin-network interface looks like on my compute node
[17:22] <bdx> https://www.dropbox.com/s/ws3g577yjzq6v0v/Screenshot%202015-03-12%2011.55.35.png?dl=0
[17:23] <jamespage> and do the same for the 10G's and run os-data-network and ceph-public-network over that
[17:23] <bdx> jamespage: Here is my 10G os-data-network interface on compute node
[17:23] <bdx> https://www.dropbox.com/s/vqt3z5dauyiewjj/Screenshot%202015-03-12%2011.55.14.png?dl=0
[17:24] <bdx> jamespage: I now realize that os-data-network doesn't need to be 10G
[17:24] <jamespage> bdx, well it might depending on how busy your tenants get
[17:25] <jamespage> bdx, are you using the ceph nova backend for instance storage?
[17:25] <R1ck> beuno: well yes but seeing as its Canonical thats developing it, you should say that.. I'm looking for independant opinions ;)
[17:25] <bdx> jamespage: Yes
[17:25] <jamespage> bdx, right - so that is going to get pretty busy with all the io
[17:26] <jamespage> you def want that running over the 10G
[17:26] <bdx> Totally, but that means I need a 10G switch for os-admin
[17:26] <jamespage> bdx - so you need to configure the ceph-public-network with the network CIDR for the 10G nics you have
[17:27] <jamespage> bdx: ceph-public-network does not have to be the same as os-admin-network
[17:27] <jamespage> bdx: the compute units just need to have a network connection to ceph-public-network - preferably over the 10G links :-)
[17:27] <bdx> jamespage: now we are getting somewhere
[17:28] <jamespage> bdx, the network support across the charms is endpoint driven - the services when related will say 'connect to me over XXX' - ceph public network for ceph
[17:28] <jamespage> clients will just use the most direct link they have
[17:29] <bdx> jamespage: I understand that....but how does compute know what interface to talk to ceph-public-network?
[17:29] <jamespage> bdx, by the magic that is linux network routing
[17:30] <jamespage> bdx, linux will just make the best choice - 1) the interface attached to the network 2) an explicit route via a gateway 3) the default route
[17:30] <jamespage> bdx, netstat -rn will tell you which of those will happen
[17:30] <jamespage> 1) or 3) are most likely
[17:30] <jamespage> don't ever do storage traffic via a router - the latency will suck
[17:32] <jamespage> bdx, does that make sense?
[17:32] <bdx> jamespage: Ok, so I create ceph-public-network: 10.50.0.0 (10G), ceph-cluster-network: 10.60.0.0 (10G), os-admin-network: 10.70.0.0 (1G), os-data-network: 10.80.0.0 (1G), os-internal-network: 10.90.0.0 (1G), os-public-network: 10.100.0.0 (1G)
[17:32] <bdx> nova-compute only has params for os-data-network
[17:32] <jamespage> yup
[17:33] <jamespage> nova compute does not have any endpoints - it just consumes them
[17:33] <bdx> So how does compute know to talk to 10.50.0.0 for storage trafficH
[17:33] <jamespage> bdx, because it must have a 10.50.0.0 network connection
[17:33] <jamespage> bdx, note the charms do not setup and configure network interfaces
[17:33] <beuno> R1ck, I understand, I was just commenting on the stability, given that we run our most critical services on it (SSO, the software store, payments, etc)
[17:34] <jamespage> bdx, they just detect and consume what's already there
[17:34] <beuno> you would know fairly quickly if it wasn't stable   ;)
[17:34] <jamespage> bdx, MAAS + Juju are developing features to support network interface configuration (discover is already supported)
[17:34] <bdx> jamespage: Ahh, ok....so nova-compute will know to talk to ceph-public-network for storage traffic even if I do not specify 10.50.0.0 anywhere?
[17:34] <bdx> ok
[17:34] <R1ck> beuno: awesome :)
[17:35] <jamespage> bdx, yup - cause the ceph charm will pass it some 10.50 addresses - these get configured into /etc/ceph/ceph.conf and used that way
[17:36] <bdx> jamespage: Phewwww, this is great news!
[17:36] <bdx> jamespage: Thank you for taking the time to explain that.....it has been driving me crazy.
[17:37] <jamespage> bdx, hey - its a little complex right now as neither maas or juju exposes networking in a consumable way by end-users or charms - that is coming - but the openstack charms jumped the gun on this due to requirement todo what you're doing
[17:38] <jamespage> bdx, you can use a special charm to config up your boxes first - I've seen people use the 'ubuntu' charm with some extra scripts called from config-changed hook to configure the network
[17:38] <jamespage> that's a stop-gap until everything hooks up between MAAS/Juju/Charms
[17:39] <bdx> jamespage: Ahhh totally, thats a great idea.
[17:40] <bdx> jamespage: I have a feeling what you advised is going to be exactly the fix I am looking for...for the time being.
[17:40] <jamespage> bdx, once everything is up and networked, you can then use the "--to" syntax to target services are particular machines
[17:40] <jamespage> bdx, erm so you will have to re-deploy your ceph cluster - its not possible to switch the public network post deployment
[17:40] <jamespage> due to the way inter-mon communication works
[17:42] <bdx> jamespage: Entirely.
[17:42] <jamespage> bdx, now that would be a neat trick but I feel I could waste alot of midnight hours trying to make that work
[17:43] <jamespage> bdx, are you using lxc containers for any of the services? that's particularly tricky with the network split support right now
[17:43] <bdx> jamespage: Totally....I am using the openstack-installer as our means of deployment here as DarkHorseComics
[17:44] <jamespage> bdx, ok so the lxc containers juju creates will only get networked to eth0 via a bridge
[17:44] <bdx> I am using nucs in my testlab for supporting services that aren't compute, quantum-network, and storage(ceph)
[17:44] <jamespage> so that does limit what you can do
[17:45] <jamespage> bdx, you can if you are feeling brave create the lxc containers with the right bridges/networking and then manually introduce them to your environment - but its a bit fiddly
[17:46] <jamespage> bdx, I've also seen people use KVM machines networked up and then registered into MAAS for deployment - the power control is still manual (maas has some rudimentary virsh support - but its not for remote machines - just tesing).
[17:47] <bdx> jamespage: Totally......I just need to finish defining our deployment methodology....getting storage traffic off the os-admin-network/interface is one of my last issues to resolve.
[17:48] <jamespage> bdx, awesome - hope this conversation unblocks you
[17:48] <bdx> jamespage: I'm pretty sure you can use the "virsh" power type in maas
[17:49] <jamespage> quite likely
[17:49] <bdx> Thats what I use in my kvm labs...
[17:49] <bdx> Thanks again for your support
[17:50] <jamespage> bdx, btw which type of tenant networks are you going to use?
[17:50] <jamespage> one of the overlay network types? (gre/vxlan)
[17:50] <bdx> gre
[17:51] <bdx> jamespage: Yea, gre...why?
[17:52] <jamespage> bdx, oh wait - your using os-data-network - that helps
[17:52] <jamespage> bdx, packet fragmentation can be awkward - make sure you configure the DHCP server for that network (or your static network config) to use a MTU higher that 1500 - preferably 9000
[17:53] <jamespage> bdx, GRE carries some overhead - using a higher mtu ensures that you don't get packet fragmentation which can impact performance and cause network issues with nofrag packets
[17:53] <jamespage> bdx; the ceph network would also benefit from that
[17:54] <bdx> jamespage: Totally, I was thinking about opening up all interface to mtu 9000
[17:54] <bdx> jamespage: Do you see any issue with that?
[17:54] <jamespage> bdx, that's a good idea
[17:54] <jamespage> "       option interface-mtu 9000;"
[17:54] <jamespage> does the trick in isc-dhcp-server
[17:55] <jamespage> you can edit the template for that in MAAS (on the assumption you are using MAAS for DHCP)
[17:55] <bdx> Entirely, I am
[17:57] <bdx> jamespage: I have edited my curtin_userdata to bring up my extra interfaces...do you think this is a reasonable way of doing this?
[17:57] <bdx> jamespage: http://paste.ubuntu.com/10611047/
[17:57] <jamespage> bdx, absolutely
[17:57]  * jamespage looks at the details
[17:58] <jamespage> bdx, hows that working for you?
[17:59] <bdx> jamespage: Excellent!
[17:59] <jamespage> bdx, maas curtin preseeds are not my strong point
[17:59] <jamespage> bdx, you could use /etc/network/interfaces.d to fragment the config a bit - but that's my only comment
[17:59] <bdx> I couldn't figure out how else to bring up my extra interfaces.....that was the only thing other than making a puppet class for them
[17:59] <jamespage> eth1.cfg eth2.fg etc...
[18:00] <jamespage> bdx, this is where I've seen folk use a special charm to configure the networks up
[18:01] <bdx> jamespage: Ok, I'll keep that in mind.
[18:01] <jamespage> bdx, well good luck - I'm EOD
[18:01] <jamespage> ttfn
[18:03] <bdx> jamespage: Ok, thanks again!!
[19:55] <jcastro> hey rick_h_
[19:55] <jcastro> http://readme.io/
[20:25] <marcoceppi> dear hatch, THANK YOU https://github.com/juju/juju-gui/pull/707
[20:26] <hatch> marcoceppi: :D
[20:26] <hatch> marcoceppi: it hasn't yet been QA'd by third parties so don't thank me YET ;)