[01:27] hello juju world, quick question. When writing layered charms can I write multiple functions for 1 decorator? [01:27] @when(foo) [01:27] def runme(): [01:27] def runmetoo(): [01:28] if anyone knows ? [01:45] sfeole, im guessing you'd put @when(foo) before both of those functions [01:45] stokachu, yea, but the 2nd function did not appear to run [01:46] interesting maybe reactive is just one state per function [01:47] why not just write several functions and include them under a parent function that runs when that state is emitted? [01:47] stokachu, yea, i can do that [01:47] stokachu, thanks for that advice [01:47] sfeole, sorry i know it's not what you were asking [01:47] i'll try it [01:47] but i can't think of another way [01:47] stokachu, no, but it should work now that I think about it [01:48] ok cool [01:48] stokachu, :) [01:48] stokachu, all the examples online always show 1 Decorator for 1 Function [04:31] Hi all, I want to deploy services using juju on the cloud (openstack). Is juju deploys services on linux containers on the top of openstack instance (or) it will directly deploy services on openstack instance. [05:29] Hi juju world!!! [05:30] when i try to push the charm to the charm store i am getting error"ERROR cannot post archive: unauthorized: access denied for user" [05:30] and also charm whoami only showing the user name [07:48] skayskay: oh, so what is the environment? Its coming from an update to the snap-layer, which ensures squashfuse is installed so snaps work under lxd (it is in process of becoming a required dependency of snapd, but I needed the work around yesterday) [07:49] skayskay: hmm... so trusty. I guess I'll need to detect the release and only install under xenial [07:49] at least until the snapd backports are all sorted [07:54] Good morning Juju world! [08:01] skayskay: Not that that should discourage you from updating to Xenial :-P === frankban|afk is now known as frankban [09:24] #ubuntu [09:28] kwmonroe, hey, are you around ? [10:10] Hi , is there any command to revoke or hide the old verions of th charm in the charm store === frankban is now known as frankban|afk === frankban|afk is now known as frankban [12:57] apparently is-leader cannot be called from within the collect-metrics hook? https://bugs.launchpad.net/charms/+source/ceph-mon/+bug/1663584 [12:57] Bug #1663584: metrics collection hook fails [13:22] Hi, is there any method to delete any particular version of a charm from charm store? or the full charm itself? [13:26] i don't believe you can remove them, but you can grant them unavailable to users [13:26] you couldn't delete them a while ago, but i've not looked recently [13:28] magicaltrout_: I tried to revoke a particular version [13:28] but i can still read that charm versoin [13:29] magicaltrout_: could you please let me know the command? [13:29] thats it [13:29] but you will be able to see it, did you check by logging out of the charmstore? [13:30] let me try, i remember I tried that way, but still able to read [13:30] let me recheck [13:32] Yeah, with sign out not able to see the charm [13:32] but with sign-in able to read that charm :( [13:32] yeah you can [13:32] but no one else can [13:32] oh is it? [13:33] so thats as close to it being deleted as you can get [13:33] ok [13:33] Thanks a lot [13:33] no probs [13:38] hi, how do we specify resources in the bundle file? [13:45] gaurangt: From my knowledge that is not possible [13:45] https://bugs.launchpad.net/juju/+bug/1623217 is filed for that issue [13:45] Bug #1623217: juju bundles should be able to reference local resources [13:51] anrah, yeah, this looks to be the same requirement. [13:51] thanks for pointing out [13:52] Zic o/ [13:53] anrah, one more thing , if I have already deployed the charm and I need to add a relation to that charm in my bundle (which will be subsequently deployed), is that possible? [13:55] no gaurangt [13:55] but you could just take that bundle and add your charm to it and post a new bundle to the charm store [13:56] magicaltrout, oh ok. [13:56] lazyPower: \o [13:57] Zic - awesome. glad you're about. I'm about to push the proposed changes for your multi-master scenario [13:57] I've a specific requirement where I need to deploy one charm manually first and then do some manual stuff on the machines and then deploy the next bundle. [13:57] Zic - however, there's a bit of complexity for me to get it from my hands to yours. a) the kubedns addon template was updated, and its breaking deployments if i rebuild the charms from teh current source tree. [13:58] lazyPower: cool! I have some hours in front of me to test [13:58] b) its non-retroactive, so it would require a fresh deploy... or we would need to riff out how to approach this in a sensible manner for your existing deployment. [13:58] I can reinstall it, sure [13:59] Zic ok, sorry about the inconvenience there. I think before this goes GA, we might want to talk about if this should have some auto-magic behind it. [14:00] i still have to sort A before i can get it in your hands though. CDK will fail to complete the setup while that KubeDNS addon template has the optional config map bits added, i might just try to fetch the 1.5.2 release addon template and munge it in there after a manual build [14:00] Zic - however, this tested well in my initial tests. So i'm kind of excited to see if this resolves the multi-master crypto issues for you [14:01] magicaltrout o/ [14:02] now then squire [14:02] magicaltrout glad to see you made it somewhere safely :) I'm looking forward to the next summit/conference. Those gents @ the pub were ww1 actors, and were doing re-enactments. I got a nickle tour of Gent + free phillofal for the trouble. [14:02] \o/ [14:02] lol [14:03] that was very weird [14:03] i also suddenly realize i have no idea how to spell fallafel [14:03] falafel :p [14:03] ^ [14:03] that [14:03] well, now I know what I want for lunch. [14:04] Yeah, they were some cool dudes. I thought for sure they were luring me away from the hotel to do nasty things... but nope. they fed me and gave me a history lesson and sent me back on my way [14:06] phillofaldelphia [14:17] Hi, lads. I'm trying to run some amulet tests on trusty, but I can't install amulet because it depends on python3-amulet which depends on python3-libcharmstore, which is no more in trusty [14:21] lazyPower: hmm, some bad news sorry: my customer is actively working right now on the cluster to prepare their apps to be "k8s-ified", so I can't reinstall it today as they will work to the end of the day and this night (deadlines approach...) monday I'm out of office and I will be back only on tuesday :/ [14:21] Mmike - Sorry you've hit that. Have you filed a bug? It would be good to capture that feedback so I can shop it with the maintainers [14:21] Zic - ah, that is a bit troubling but not an ultimate blocker. this jsut releives some of the pressure I put on myself to get this in your hands -today- [14:22] lazyPower: nope, was hoping I did something wrong - will file one shortly [14:22] Zic - by then we might even have a sensible approach to updating the existing deploy so its just juju upgrade-charm [14:22] lazyPower: I'm filing that against amulet, right? [14:23] Mmike correct - https://github.com/juju/amulet [14:24] ha! [14:24] lazyPower: sorry :( I expected that I can reinstall the cluster this afternoon (it's 15:23 here o/) and let the cluster operational for this night and the week-end, but the customer is actively working this afternoon :( [14:24] Zic no problem, no problem at all [14:24] lazyPower: so, just to make clear - no bug in launchpad, but create issue in github? [14:24] i was just trying to haul tail to get you un-blocked on this [14:25] Mmike - yeah, i'm fairly certain they dont look at launchpad for amulet bugs (they might, but i'm erring on what i know) [14:25] lazyPower: I poweroff-ed my two extra-master for now, as it's not in prod and only one master is ok to let them k8s-ified their apps [14:25] Zic - good plan [14:25] lazyPower: ack, thnx [14:25] so they are not hurt by the bug for now [14:26] yeah that crypto bug was fairly simple to squash i think in how i approached it [14:26] I can power-on them if you want to test your patch on an already deployed cluster [14:26] Zic - just FYI, there's a notion of leadership in charms. I used the leader to generate those files and push them to the followers. So teh leader is only the one that generates, and the followers just vaccume that in from the leader-data, and blindly write the contents to the correct filepaths. [14:27] its a sort of nieve approach, but i think it's elegant enough that we can fix your deployed units with a simple state toggle [14:27] however, if you have a beefy machine, it might be good to test this in a LXD environment before we go mucking with your deployed units [14:27] s/environment/model/ [14:29] I can pop some VMs on the same ESX which host the current control plane of the k8s cluster, yes [14:29] fantastic [14:30] Zic - ok, lets plan on doing that, and we'll do some testing there before we touch your deployed cluster. I'd like to white glove that deployment as much as possible as it would be your n'th re-deploy at this time. [14:30] i dont enjoy making extra work for my users [14:31] ^ you heard it here first folks [14:31] :D [14:32] I'm preparing the new VM, just one is needed? [14:33] Zic - yeah, make it beefy. You'll want bare minimum 4 cores 8gb of ram and ~ 50gb of disk space if you're going to deploy CDK in LXD [14:33] don't believe it for a second [14:35] oki [14:47] lazyPower: it's fun to do things reversely -> I directly began to test CDK on VMs and baremetal, it will be the first time I test it in LXD :) [14:47] (will be the first time I use LXD anyway) [14:47] Zic - its great :) you'll have some shuffling to do [14:47] I read about LXD and what differences it exposes to docker or rkt [14:47] i'll give you instructions when its ready, you'll have to use conjure-up to deploy initially then intercept and update teh charms [14:48] Zic - apples and pineapples my friend. machine containers vs app containers [14:48] it seems to be the common choice for who only works with VMs the last years [14:48] you get a full init system and the containers look/act just like a "real" linux [14:48] the migration seems to be easier for VM -> microservice with LXD [14:48] so its more than just a process with an ip address [14:48] YES [14:48] exactly [14:48] lift and shift is the primary value proposition [14:48] I read right \o/ [14:48] there's more but we'll leave it at that :) [14:50] why can't C++ code just resolve its dependencies properly in any IDE :sob: [14:55] magicaltrout: to make you Go? (I'm a C/C++ guy, but it will be the answer of my pro-Go teamworker) [14:55] hehe [14:55] i've never really done anything in either, they all make me sad [14:55] maybe I will be part of the Go-sect (oh, I mean Gopher!) this year if I can free some time after the K8S project :p [14:56] i blame kjackal_ [14:56] good call! [14:56] thanks [15:07] Zic - here's the magic if you're interested https://github.com/chuckbutler/kubernetes/commit/3320fc04015411cdc9ad44d98210ada5137537e3 [15:08] oh this part is in Python ? [15:12] Zic - yep, the entirety of the kubernetes charms are python [15:15] interesting, so I can actually reading it and understand the entire charm :p [15:15] thought it was Go too, or a specific YAML descriptor [15:16] na most charms are python [15:16] a few in bash [15:16] juju core is Go [15:16] yeah, the first time I discovered Juju, it was also in Pytho IIRC [15:17] but the first time I used it, it was recoded to Go :) [15:17] and as all new tools of Canonical seems to be in Go this day... [15:18] (LXD, snappy, juju, ...) [15:25] yeah but they aren't crazy enough to get the public to develop in Go ;) [15:25] magicaltrout: hehe :p [15:26] if ~/charms/deps/layer/X is already populated and the repository is updated the new commits don't seem to be pulled when running charm build, am i doing something wrong? [15:26] SimonKLB - allow me to introduce you to the best flag ever when having these issues [15:26] SimonKLB - when building, pass --no-local-layers [15:26] hehe one step ahead of you :) [15:26] `charm build --no-local-layers` [15:26] same thing then [15:27] argh [15:27] ok i'm no help then [15:27] * lazyPower dies a little inside [15:27] haha, ive never had the issue before, so i wonder if its something introduced recently [15:27] either that or im doing something odd [15:28] magicaltrout: few years back, I was not curious about Go at all for two reason 1) I have skills in C, Python, and it seems enough to me for "system programming language" 2) The only well-known project in Go was Docker and, as a sysadmin, not huge fan of it (even if I didn't try, I tend to prefer the LXD approach for my PoV) [15:29] magicaltrout: but as more and more tools in Ubuntu seems to go to Go (...), I'm planning to really take a look at Go this year :) [15:29] lazyPower: this isnt something youve stumbled upon before btw? [15:29] if youve had a long-running charmbox [15:29] i'll learn it, as soon as I've got LXD into Mesos, completed my machine learning course, onboarded my new employee, got some more work in the pipeline and taken a holiday [15:30] and build a charm with a layer that has been updated [15:30] SimonKLB - nah, i ran into stale stuff because i had local paths when i was building [15:30] but that flag fixed me up, and also, i always map in my charm/layer repo [15:30] lazyPower: yea ive had that problem as well, thats why i knew about the --no-local-layers flag [15:30] so its whatever i have on the host. so the length of the session of charmbox isn't so much a factor [15:30] magicaltrout: my last concern is that, it seems Go is much loved when C/C++ hurts you [15:31] for personal development, I really love C, as I'm not a dev, just a sysadmin so when I'm developing, it's mainly for myself [15:31] lazyPower: yea right, i think i actually have it mounted as a volume as well, still though, its never been any problem getting it up to date when building [15:31] no deadline, no teamworker code unreadable :) [15:31] "i really love C as I'm not a dev...." said 1 person ever [15:31] lazyPower: i just tried deleting the docker folder from deps/layers and then it was cloned fresh [15:33] magicaltrout: :D [15:33] SimonKLB - thats weird [15:34] magicaltrout: I'm saying that because I know that, all I'm developing can easily be in Go (or even in Python) without any downside [15:34] aye Zic I know what you mean [15:34] I do java cause its what they taught us at uni [15:34] thats pretty much the only reason [15:34] all that java [15:34] magicaltrout: I just did it in C because I like it, and I know it's not a good reason :) [15:34] (for profesionnal PoV) [15:35] my boss chew me out a few weeks ago for mocking PHP developers [15:35] so I'm no longer allowed to mock languages [15:35] :p [15:35] I still think PHP developers need to get out more [15:36] magicaltrout - you should replace your boss with a very intricate webservice (in your language of choice) (i'm only half kidding) [15:36] he is a webservice [15:36] i got chewed out over email [15:36] Nothing wrong with Java [15:36] for what I'm doing, Go (or Python) seems to be a better choice than C in fact, but as I'm developing for myself and not profesionally, I have more fun in developing in C, as it really feels low-level speaking to the machine [15:37] * magicaltrout will happily go as abstracted as required for it to be easy :P [15:37] but for machine learning stuff its all python these days [15:37] and charms [15:37] ^ [15:37] That [15:37] so my python fu is slowly growing [15:38] "and charms" [15:38] thats what i like to hear [15:38] yeah, it's the TL;DR : I now know that I can code Juju charm in Python or Bash :) [15:38] so my Go's learning can wait a little more :p [15:38] well when i get this mesos stuff building I'll have the best container stack on Jujucharms.com : [15:38] :P [15:39] Zic - i'm happy to provide all the distraction of learning go that you require if its to charm stuff up [15:39] magicaltrout - thats a pipedream sir, CDK is clearly > mesos. We'll do the pepsi challenge if you require [15:39] hehe [15:39] we'll see [15:39] we'll see [15:39] indeed [15:40] lazyPower: another wierd one, after juju upgrade-charm im setting "could not download resource: HTTP request failed: resource "X" not found" in the logs [15:40] those who like following the crowd use CDK... those who like doing science and getting stuff done, use Mesos! ;) [15:40] however, i do have the resource locally [15:41] i.e, /var/lib/juju/agents/unit-charmname-1/resources/X exist [15:41] lazyPower: I didn't learn Go before because it was too "have a foot in each camp" : I have C for my self-pleasure to code, and I have Python/Bash for my work (as a sysadmin) [15:41] lazyPower: but today, as Go is more mature, I see it everywhere [15:41] SimonKLB - when you upgrade a charm (if local or --switch) it will drop the resource from the controller [15:41] SimonKLB - which means you need to re-attach [15:41] so... yeah, I plan to learn Go somewhere in 2017 :p [15:42] I heard that day will be switched to 27 hours instead of 24 this year [15:42] lazyPower: ahaaa! [15:42] :> [15:42] Zic - dont torment me with a good time [15:45] hi all - looking for where I should go for conjure-up support. I've deployed it but cannot access horizon (it's unclear what the URL for horizon should be, and the default or "/dashboard" on the deployed host do not work) [15:46] bryan_att - you're in the correct place, if not here then #openstack-charms. but stokachu and mmcc are the primary authors of conjure-up [15:46] bryan_att: what substrate did you deploy to? bryan_att is the horizon exposed and have something of an address you can reach from where you're at? [15:46] o/ [15:46] and with a response time like that ^ you're in good hands [15:47] rick_h: not sure what a substrate is, but it's Xenial minimal server with updates/upgrades only [15:47] if I was a developer, I will take time to learn as many languages I found "cool"... as a sysadmin, I just sticked with "know one language for each task, C for system-programming, Python for scripting", but I revised my mind and will do an exception for Go, as I saw more and more employee with Go in their sysadmin skills [15:47] bryan_att: did you go to lxd, maas, or something else? [15:47] bryan_att, did you select localhost? [15:47] bryan_att, openstack with novalxd? [15:47] rick_h: yes that was the only option [15:48] stokachu: yes, all the instructions as stated on the quickstart page [15:48] bryan_att, can you paste.ubuntu.com your `juju status` output [15:49] stokachu: http://paste.ubuntu.com/23967373/ [15:50] bryan_att, looks like openstack-dashboard/0* active idle 14 10.0.8.149 80/tcp,443/tcp Unit is ready [15:50] so http://10.0.8.149/horizon [15:50] but it also looks like some of the ceph stuff isn't up yet [15:51] lazyPower: my VM is ready by the way, ping me when I can begin the test :p [15:51] I'm here for the two next hours [15:52] Zic - i'm still waiting on a good build of bins from the master branch. we're blocked on https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/213 otherwise [15:52] the build routine since we're building all arch's and all components in a single job takes upwords of an hour and a half [15:52] ok [15:53] i'm 35 minutes into a 1.5 hour build [15:53] so only 60 minutes to go \o/ [15:53] then i'll be pending the upgrade test. this is likely to wait until Monday for you [15:53] oorrrr [15:53] yeah, probably monday now that i think about it more [15:53] and i should have the upgrade logic sorted by then as well [15:54] s/monday/tuesday/ actually :p but even if I'm on a weekend, I will take a look because I'm too curious even when I'm away from the PC :) [15:56] lazyPower: to a near subject, first I thought my kube-dns CLBO-ing sometime (~10th times, and then reteruning to normal state) was maybe not related to this issue, but since I poweroff-ed my two extramaster, I didn't have a single CLBO of kube-dns [15:56] maybe this fix... will fix this too [15:57] as the kube-dns CLBO event is tied to the readyness/liveness check, which querying the API (and maybe get the certificate error? I don't find the way to confirm this) [15:57] we'll see [15:58] stokachu: how do I access horizon at http://10.0.8.149/horizon is that is not a routable subnet on my local net? Also see the next paste which is the result on the host itself: [15:59] stokachu: attempt to access horizon https://www.irccloud.com/pastebin/EhMwXriO/ [15:59] bryan_att, you can use sshuttle to setup a connection to that 10.0.8.0 subnet [16:00] bryan_att, so sshuttle -r user@hostmachine 10.0.8.0/24 [16:00] stokachu: ok but to get this clearer, is it assumed that conjure-up is being deployed on a desktop host, or is it designed to be deployed on a server? If the latter and we need to use another tool to access it (e.g. sshuttle), that would be good to clarify in the docs. [16:01] bryan_att, yea that depends, if you're install openstack with novalxd on localhost it is assumed that it's running on your laptop [16:01] bryan_att, but we should document the sshuttle way b/c some users do ssh into another machine and test it [16:02] stokachu: ok, so for my use case, I'm deploying this on a Intel NUC5i7 with 16GB and xenial-server minimal install, then accessing it via other machines on mt local net to deploy workloads / tests etc using the OSC. [16:02] bryan_att, https://github.com/conjure-up/conjure-up/issues/672 [16:03] bryan_att, yea you'll want to use sshuttle to access that openstack [16:03] you'll also need to setup a second sshuttle session to access the actual compute nodes deployed via openstack [16:03] openstack on novalxd is meant mostly for development [16:03] we have another one that runs on MAAS and is meant for production [16:05] stokachu: this is also for development, but I need an OpenStack deployment that is more "real" than devstack which cannot do what I need for tests, e.g. per the OPNFV Models project https://wiki.opnfv.org/display/models/Testing - e.g. I need to bring up 4 VMs, driven by Tacker as VNFM [16:06] stokachu: I am working with narindergupta to get the OPNFV JuJu installer (JOID) running on newton but also need something lighter, so I am trying conjure-up to see what it can and can't do. [16:06] bryan_att, ah ok [16:07] narindergupta, can you walk bryan_att through using sshuttle to access his openstack environment? [16:09] bryan_att, im working on more openstack spells if there is something you need specifically let me know [16:10] Zic - makes sense to me. seems like whichever scheduler scheduled the kubedns pod doesn't always correlate with whichever api-server was handling the request. and when thats the case, if the crypto keys were mismatched it makes sense it failed because it uses teh default service token to do that auth request [16:10] lazyPower: just saw mbruzek comment on your fix : https://github.com/chuckbutler/kubernetes/commit/3320fc04015411cdc9ad44d98210ada5137537e3#commitcomment-20834883 [16:10] do you plan to migrate to snap instead of apt in future releases? [16:11] Zic - we're not using apt now ;) we're using tarball packages [16:11] Zic - but yeah, we're in the process of snapping up kubernetes [16:11] Zic we are looking into snaps as the future yes. [16:11] cool [16:12] lazyPower: oh yeah, for k8s part, but for some other part like etcd, it fetch the package from the deb archive and you're sticked to the freezed archive version so [16:12] yeah, sabdfl himself is actually working on the etcd snap [16:12] (except security/fix upgrade) [16:12] i'm a bit concerned about the snap refresh happening under the charm and getting newer versions than the charm is ready for, but we'll jump off that bridge when we come to it i guess [16:14] i like the fact your jump off bridges [16:14] not cross them.... [16:14] your/you [16:14] intentional magicaltrout ;) [16:14] because the day i hit that issue, i'm going to commit seppuku [16:15] lazyPower: it's a bit offtopic here, but I don't track the news about snappy in Ubuntu -> is Ubuntu Desktop fully build on snappy and no .deb is part of the future? [16:15] or snap is just camp to "some packages which moves a lot" [16:15] Zic - we're not quite there yet, but yes, snaps are the future of ubuntu. [16:15] automated under the hood rollout of all your container tech where you can't yet peg versions... what could possibly go wrtong \o/ [16:15] magicaltrout precisely [16:15] lazyPower: with a total replace of deb or just as a "sidekick" for some packages? [16:15] (as it is actually used, in fact) [16:15] Zic - hard to say, but i think its where we'd like to go is fully snapped. [16:16] we've recently added classic-mode snaps to make making "unconfined" snaps much easier to build and an acceptable delivery pattern. Where teh strict confinement is like final-boss mode of snaps. [16:17] there are some corner cases that dont lend itself very nicely to strict-confinement, like the CNI plugin structure of kubernetes [16:17] but we're working through that and talking with the snappy developers to find a good path [16:18] I need to refresh me about all Ubuntu technologies :p it's quite a long time I didn't read about Mir, Snappy, ... [16:19] recently I updated my info about Unity 8 and... *suspense* Juju \o/ [16:20] I was quite impressed/worried that Ubuntu is going to JavaScript application (through Qt/QML) for desktop [16:20] [16:20] Zic - the best place to get info about snappy is from the snappy mailing list. There's many threads daily from developers integrating and making snap packages. [16:21] you'll find some neat tricks, future-talk, and get the scoop on all things snappy [16:21] i really like the new format of ubuntu-core with the USSO centric bootstrap where on first boot it prompts for your user credentials and fetches ssh keys, so yoyu dont have an insecure default username/password, which helps eliminate vectors that contribute to things like the mirai botnet [16:22] its a *lot* like the cloud-init story where it fetches ssh keys on bootstrap and doesn't ship with default credentials. but has a fancy TUI for all of it [16:23] Hello, again! I've deployed my juju env on amazon AWS but the 'login with sso' button in juju-gui still yields with 'authentication failed: no credentials provided'. Do I need to configure something else for this to work? [16:23] rick_h: ^^ [16:23] Mmike: is this something you bootstrapped? [16:23] rick_h: it is [16:24] Mmike: then the sso button doesn't do anything. I've filed a bug on the GUI on this and we're looking at updating that [16:24] rick_h: I did 'add-credentials' for aws and ... [16:24] oh [16:24] rick_h: thank you [16:24] rick_h: do you have the bug url handy, maybe [16:24] ? [16:25] Mmike: https://github.com/juju/juju-gui/issues/2360 [16:25] lazyPower: I'm so attached to the APT/.deb architecture but ideas that snappy exposes seems so cool that yeah, I'm excited about how it will emerge in future Ubuntu releases [16:25] Zic its already availble by default in xenial+ [16:25] rick_h: thnx, much appreciated [16:25] lazyPower: yeah, but not so much integrated for GUI apps (the only case I used it for now :/) [16:26] Zic - as a test, you can sudo snap install charm [16:26] that will get you the latest/greatest charm-tools in snap format [16:26] Zic - and i dont know about that :) there's quite a few GUI apps in the snap store as well [16:27] lazyPower: the confinement of this GUI apps in snap break some Desktop integration like the Unity HUD, the GTK decorator, the clipboard, etc. [16:27] ah yeah [16:27] but it's a work in progress I guess [16:27] that is a challenge [16:27] https://uappexplorer.com/apps?type=snappy_application [16:27] is what i was about to link as counter point [16:27] and the old XOrg is not helping on this part [16:27] I think it will be easier with Mir [16:27] but i cede to your findings [16:28] the only technology I'm feared that Canonical push is Mir actually (instead of Wayland) [16:28] I know that they choose Mir instead of Wayland because of Ubuntu Touch [16:28] but I feared that, in coming future, Ubuntu will be too different than other distribution who choose Wayland [16:29] for all other tech (juju, snappy, LXD, Unity) I'm glad of choices made [16:30] I'm just a bit curious/worried about Mir [16:35] ooh nice [16:35] kjackal_: got mesos master + slave running docker containers locally using the universal stuff [16:35] don't need marathon after all [16:36] i'll take a stab at finding out what goes on under the hood next week. [16:37] magicaltrout: (offtopic again, sorry) -> we never used Mesos directly at my company, only via DC/OS and... was not fan at all [16:38] I'm saying that because the customer which went with DC/OS in his mind is now currently migrating to K8S through CDK :) [16:39] not the same techno at all, but he drops DC/OS after seeing K8S [16:39] well whatever works :) [16:40] we use a lot of Mesos at NASA as it allows us to deploy non containerised workloads to it [16:40] magicaltrout: in fact, I think I had a bad experience with Mesos but it's DC/OS's fault, I never use "raw"-Mesos [16:40] but I'd also like to bring juju to Mesos as a "cloud" which is why I'm plugging LXD into it, but you know, Kubernetes has a lot of fans [16:40] used* [16:40] but I use DC/OS on my consultancy servers to deploy all my stuff [16:41] i'm more than happy with it, but i think the earlier versions were a bit funky [16:41] and TBH vanilla mesos is easy to stand up anyway [16:41] yeah, my main concern with DC/OS was, when it block or crash, it only prompt you with a "Give us a visit at Slack" in the first version [16:41] lol [16:41] okay its not that bad :P [16:42] who doesn't like joining private slack instances? *eyeballs the 10 orgs he's idling in and hasn't spoken to in 6+ days) [16:42] indeed [16:42] also, we find that one of the GUI which was normally protected by the DC/OS oauth was actually accessible if you forge a special link that bypass the reverse-service... [16:43] we drop it early in our PoC, don't know if it's better now :) [16:43] Zic: if you deploy on prem and don't lock down the ports there's a shit load open to the world :) [16:43] yep [16:43] dunno why they don't resolve that, but I'm not a Mesosphere dev, so I don't care :) [16:43] ^^ [16:43] iptables < lock-downmesos.save :) [16:44] anyway, I think the container orch landscape is big enough for a few platforms, clearly k8s is winning, but I don't think Mesos will go anywhere in the near future [16:44] or maybe it will and something else will come along, but clearly there's a lot of scope for different platforms [16:45] they'll all do similar stuff at the end of the day [16:45] it's not the same abstraction of hardware, between k8s and Mesos, I think there is place for both of them [16:45] ^ [16:45] that [16:45] Mesos presents you hardware like a "bunch of ressources" [16:45] K8S orchestrate containers [16:45] it's not same approach for me [16:45] yup [16:45] thats true [16:45] Zic - however k8s has support for resources, *and* cri will change that story [16:45] personally, I like containers, but i like raw resource as well ;) [16:45] assuming lxd makes its way into CRI [16:46] which i heard once, but haven't heard anything about since [16:46] so we cant really commit to heresay [16:46] FYI, I was not fan at all of container before K8S, because I saw containers as "devs wants to do silly things in my machines" [16:46] well everyone seems to think it will happen, without actually committing to it [16:46] and your commander in chief was like "we'll build the stuff, and someone else will plug it in " [16:46] who knowa [16:46] with K8S, container in prod is a viable thing [16:47]