[02:59] does juju big-data have its own irc channel? [03:00] do the big data charms offer a way to decouple hdfs and hadoop? [03:57] http://docs.ceph.com/docs/kraken/cephfs/hadoop/ < anyone looked into this [06:39] hi bdx, this is the channel for big data charms as well. kwmonroe is leading the big data effort. [06:41] bdx: the abstraction hadoop processing offers over the storage solution is included in the slave+namenode node of the hadoop processing bundle [06:42] bdx: would you be interested in cephfs as an alternative? [06:44] 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 === frankban|afk is now known as frankban [07:37] bdx: just saw you already brought that to the list. Thank you [07:57] jamespage: Hello, I am hitting this bug: https://bugs.launchpad.net/charm-neutron-gateway/+bug/1684040 [07:57] Bug #1684040: "Missing relations: network-service" is not covered in metadata nor documentation [07:57] Mitaka + Trusty environment [08:00] armaan: do you have the relation between nova-cc and neutron-gateway? [08:01] jamespage: After adding the nova-cc and neutron-gateway relation, i get a 'Incomplete relations: network-service' message. [08:01] armaan: can you make sure you have a relation between nova-cc and neutron-api as well [08:01] armaan: your message is 'incomplete' rather than 'missing' which has a different meaning - so not quite the same bug [08:02] 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] but that feels like a thing of the past [08:04] jamespage: Yes, a relation exists between nova-cc and neutron-api as well. [08:04] jamespage: ahhh, wait [08:04] jamespage: I guess that was the issue, this fixed the problem "juju add-relation nova-cloud-controller neutron-api" [08:04] thanks! :) [08:05] yw [09:57] jamespage: After adding the relation earlier, neutron agents are failing to report their state. http://paste.openstack.org/show/616542/ [10:13] jamespage: All the services look fine to me http://paste.openstack.org/show/616551/ [10:31] current method of deployment which i m using : juju deploy /charm/mycharm --resource install = "tar file" -to . How can I do that using yaml file if i don't want to provide resource through cli [10:33] if you mean bundle? I don't know whether that is possible.. At least it was not some time ago [10:36] yes i mean that [10:37] So providing through cli is the only way ? [10:39] https://bugs.launchpad.net/juju/+bug/1623217 at least according to that Bug it is not yet resolved [10:39] Bug #1623217: juju bundles should be able to reference local resources [15:42] how can I specify in the 'machines' section of a bundle, which zone I want a machine in? [15:43] if I want machine 0 in zone 'zone2' how do I specify that in the bundle? [15:43] it seems to ignore 'zone' field and says 'zone' is an invalid constraint [15:44] how easy is it to set up juju? [15:45] jhobbs: which provider? [15:45] rick_h: maas [15:46] open stack? [15:51] 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] rick_h: i can do juju deploy cs:ubuntu --to zone=zone3 [15:53] that works fine, i just don't know how to from a bundle [15:53] i will file a bug [15:54] jhobbs: ah! so it's not a constraint [15:54] jhobbs: it's a placement directive ugh [15:54] jhobbs: and bundles try to parse that as an application name in the bundle vs understanding that zone thing [15:55] it's a constraint to maas but a placement directive to juju [15:55] jhobbs: so sounds like an issue in how we model that and a bug on the /juju/bundlelib probably [15:55] jhobbs: right, but not something juju does with --constraints "x=y" [15:55] yeah [15:55] ok, thanks rick_h, i'll file a bug [15:58] https://bugs.launchpad.net/juju/+bug/1706704 [15:58] Bug #1706704: bundles: no way to specify which zone a machine should be in === frankban is now known as frankban|afk [17:01] 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] so I was thinking, firewalling deployed machines, upgrading stateserver via 'juju upgrade-juju', and then 'manually' (somehow) upgrading the agents [17:02] is that even an option? [17:04] 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] This the charm : cs:~aakashkt/ovn-13 [17:04] and the repo : https://github.com/AakashKT/ovn-kubernetes-charm [17:04] I would also be bringing up issues on the repo soon, as kjackal suggested [17:04] Finally, would like to have you guys review the charm and give your suggestions on what can be improved / added [17:04] Thank you [17:05] 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] ak_dev: no worries :) It's IRC, that's how it works :) [17:06] Mmike: Yeah, still kind of new here :-) [20:24] 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] 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] natefinch: for a/b deployments though model migration may be worth taking a look, https://jujucharms.com/docs/2.1/models-migrate [20:37] hth natefinch [20:39] Thanks :) [20:39] oh yeah, model migration, forgot about that. That would be nice. [20:41] natefinch: model migration does work under the same cloud. [20:41] If others have thoughts on rolling upgrades please chime in [20:44] what's the state of the art in docker support these days? [20:46] natefinch: modeled by the author at the charm level [20:47] ok [20:48] natefinch: k8 charms are a pretty solid [20:48] http://jujucharms.com/canonical-kubernetes [20:49] yeah, we've kind of decided against k8s because it's so complicated [20:53] 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] to keep docker containers scaled and running, that is [20:57] right [20:58] 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] natefinch: you can leave your storage external at first [21:01] e.g. as mentioned in https://insights.ubuntu.com/2017/07/20/run-django-applications-on-the-canonical-distribution-of-kubernetes/ [21:02] does networking work on AWS yet? [21:02] natefinch: which bit exactly? [21:04] like creating subnets and assigning services to a specific subnet [21:05] you generally assign applications to spaces, not subnets [21:05] if you create a space and put the right subnets in it, then I think it works [21:05] sure.... but the docs say spaces are only supported on MAAS [21:05] "Note: Advanced networking features, such as 'spaces`, are currently only supported by MAAS." [21:05] spaces are kinda supported on AWS, but FSVO working [21:06] that is a focus this cycle [21:06] *nod* [21:19] what about networking among containerized services? [21:22] thumper, arosales: ^ . (i.e. last I heard that was still a problem) [21:23] otp [21:23] kk [21:27] natefinch: we regularly put applications in lxc containers for OpenStack