[02:59] <bdx> does juju big-data have its own irc channel?
[03:00] <bdx> do the big data charms offer a way to decouple hdfs and hadoop?
[03:57] <bdx> http://docs.ceph.com/docs/kraken/cephfs/hadoop/ < anyone looked into this
[06:39] <kjackal> hi bdx, this is the channel for big data charms as well. kwmonroe is leading the big data effort.
[06:41] <kjackal> bdx: the abstraction hadoop processing offers over the storage solution is included in the slave+namenode node of the hadoop processing bundle
[06:42] <kjackal> bdx: would you be interested in cephfs as an alternative?
[06:44] <kjackal> bdx: you might want to make this an official request by opening a feature request issue against the hadoop processing bundle or just send an email to the juju list
[07:37] <kjackal> bdx: just saw you already brought that to the list. Thank you
[07:57] <armaan> jamespage: Hello, I am hitting this bug: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1684040
[07:57] <mup> Bug #1684040: "Missing relations: network-service" is not covered in metadata nor documentation <OpenStack neutron-gateway charm:New> <https://launchpad.net/bugs/1684040>
[07:57] <armaan> Mitaka + Trusty environment
[08:00] <jamespage> armaan: do you have the relation between nova-cc and neutron-gateway?
[08:01] <armaan> jamespage: After adding the nova-cc and neutron-gateway relation, i get a 'Incomplete relations: network-service' message.
[08:01] <jamespage> armaan: can you make sure you have a relation between nova-cc and neutron-api as well
[08:01] <jamespage> armaan: your message is 'incomplete' rather than 'missing' which has a different meaning - so not quite the same bug
[08:02] <jamespage> I think we should probably add the neutron-api - nova-cc relation to REQUIRED_INTERFACES - its been optional in the past to support nova-network based deployments
[08:03] <jamespage> but that feels like a thing of the past
[08:04] <armaan> jamespage: Yes, a relation exists between nova-cc and neutron-api as well.
[08:04] <armaan> jamespage: ahhh, wait
[08:04] <armaan> jamespage: I guess that was the issue, this fixed the problem "juju add-relation nova-cloud-controller neutron-api"
[08:04] <armaan> thanks! :)
[08:05] <jamespage> yw
[09:57] <armaan> jamespage: After adding the relation earlier, neutron agents are failing to report their state. http://paste.openstack.org/show/616542/
[10:13] <armaan> jamespage: All the services look fine to me http://paste.openstack.org/show/616551/
[10:31] <noops> current method of deployment which i m using : juju deploy /charm/mycharm --resource install = "tar file" -to <any-unit> . How can I do that using yaml file if i don't want to provide resource through cli
[10:33] <anrah> if you mean bundle? I don't know whether that is possible.. At least it was not some time ago
[10:36] <noops> yes i mean that
[10:37] <noops> So providing through cli is the only way ?
[10:39] <anrah> https://bugs.launchpad.net/juju/+bug/1623217 at least according to that Bug it is not yet resolved
[10:39] <mup> Bug #1623217: juju bundles should be able to reference local resources <sts> <talisman> <juju:Triaged by ecjones> <https://launchpad.net/bugs/1623217>
[15:42] <jhobbs> how can I specify in the 'machines' section of a bundle, which zone I want a machine in?
[15:43] <jhobbs> if I want machine 0 in zone 'zone2' how do I specify that in the bundle?
[15:43] <jhobbs> it seems to ignore 'zone' field and says 'zone' is an invalid constraint
[15:44] <thedragon> how easy is it to set up juju?
[15:45] <rick_h> jhobbs: which provider?
[15:45] <jhobbs> rick_h: maas
[15:46] <thedragon> open stack?
[15:51] <rick_h> jhobbs: hmm yea not sure. It looks like zone is supported in the code to get a node, but not sure where that gets maps out to a valid constraint to listen to. I thought it was availability-zone or something on AWS, but normally Juju round-robins zones for unit resilience
[15:53] <jhobbs> rick_h: i can do juju deploy cs:ubuntu --to zone=zone3
[15:53] <jhobbs> that works fine, i just don't know how to from a bundle
[15:53] <jhobbs> i will file a bug
[15:54] <rick_h> jhobbs: ah! so it's not a constraint
[15:54] <rick_h> jhobbs: it's a placement directive ugh
[15:54] <rick_h> jhobbs: and bundles try to parse that as an application name in the bundle vs understanding that zone thing
[15:55] <jhobbs> it's a constraint to maas but a placement directive to juju
[15:55] <rick_h> jhobbs: so sounds like an issue in how we model that and a bug on the /juju/bundlelib probably
[15:55] <rick_h> jhobbs: right, but not something juju does with --constraints "x=y"
[15:55] <jhobbs> yeah
[15:55] <jhobbs> ok, thanks rick_h, i'll file a bug
[15:58] <jhobbs> https://bugs.launchpad.net/juju/+bug/1706704
[15:58] <mup> Bug #1706704: bundles: no way to specify which zone a machine should be in <cdo-qa> <juju:New> <https://launchpad.net/bugs/1706704>
[17:01] <Mmike> hi, lads. Is there a way to do a staging, manual upgrade of juju? I'm running juju 2.0.2 and I'd like to go to latest 2.2, but if I allow all of my agents to connect to the stateserver, bad-things-happen
[17:02] <Mmike> so I was thinking, firewalling deployed machines, upgrading stateserver via 'juju upgrade-juju', and then 'manually' (somehow) upgrading the agents
[17:02] <Mmike> is that even an option?
[17:04] <ak_dev> Hi all,  I would like to say that the prototype of the OVN charm is ready, you can deploy pods successfully using that
[17:04] <ak_dev> This the charm : cs:~aakashkt/ovn-13
[17:04] <ak_dev> and the repo : https://github.com/AakashKT/ovn-kubernetes-charm
[17:04] <ak_dev> I  would also be bringing up issues on the repo soon, as kjackal suggested
[17:04] <ak_dev> Finally, would like to have you guys review the charm and give your suggestions on what can be improved  / added
[17:04] <ak_dev> Thank you
[17:05] <ak_dev> Mmike : Sorry i posted the message just after yours, dont have an answer to your query, but I am sure somebody else will help out :-)
[17:05] <Mmike> ak_dev: no worries :) It's IRC, that's how it works :)
[17:06] <ak_dev> Mmike: Yeah, still kind of new here :-)
[20:24] <natefinch> marcoceppi or arosales (or anyone else who knows):  are there stories for rolling restarts, rolling upgrades, or a/b deployments in Juju yet?
[20:35] <arosales> natefinch: I believe rolling upgrades aren't a juju-core base function but are modeled through actions and config given the charm author implements such a method.
[20:36] <arosales> natefinch: for a/b deployments though model migration may be worth taking a look, https://jujucharms.com/docs/2.1/models-migrate
[20:37] <arosales> hth natefinch
[20:39] <natefinch> Thanks :)
[20:39] <natefinch> oh yeah, model migration, forgot about that.  That would be nice.
[20:41] <arosales> natefinch: model migration does work under the same cloud.
[20:41] <arosales> If others have thoughts on rolling upgrades please chime in
[20:44] <natefinch> what's the state of the art in docker support these days?
[20:46] <arosales> natefinch: modeled by the author at the charm level
[20:47] <natefinch> ok
[20:48] <arosales> natefinch: k8 charms are a pretty solid
[20:48] <arosales> http://jujucharms.com/canonical-kubernetes
[20:49] <natefinch> yeah, we've kind of decided against k8s because it's so complicated
[20:53] <arosales> ya, pending the scale k8's may not be worth the over head. But once its running provides nice features to keep scaled and running
[20:56] <arosales> to keep docker containers scaled and running, that is
[20:57] <natefinch> right
[20:58] <natefinch> docker is also a problem for us, since we use a lot of storage-based systems, postgres, cassandra, kafka, etc... and those don't play well with docker by default
[21:00] <tvansteenburgh> natefinch: you can leave your storage external at first
[21:01] <tvansteenburgh> e.g. as mentioned in https://insights.ubuntu.com/2017/07/20/run-django-applications-on-the-canonical-distribution-of-kubernetes/
[21:02] <natefinch> does networking work on AWS yet?
[21:02] <thumper> natefinch: which bit exactly?
[21:04] <natefinch> like creating subnets and assigning services to a specific subnet
[21:05] <thumper> you generally assign applications to spaces, not subnets
[21:05] <thumper> if you create a space and put the right subnets in it, then I think it works
[21:05] <natefinch> sure.... but the docs say spaces are only supported on MAAS
[21:05] <natefinch> "Note: Advanced networking features, such as 'spaces`, are currently only supported by MAAS."
[21:05] <thumper> spaces are kinda supported on AWS, but FSVO working
[21:06] <thumper> that is a focus this cycle
[21:06] <natefinch> *nod*
[21:19] <natefinch> what about networking among containerized services?
[21:22] <natefinch> thumper, arosales: ^ .   (i.e. last I heard that was still a problem)
[21:23] <thumper> otp
[21:23] <natefinch> kk
[21:27] <arosales> natefinch: we regularly put applications in lxc containers for OpenStack