| === anthonyf is now known as Guest37830 | ||
| therealmarv | Hi, my charm is on revision 4 here (search for the realmarv) https://code.launchpad.net/charms and here https://code.launchpad.net/~therealmarv/charms/trusty/pybossa/trunk but not on https://jujucharms.com/u/therealmarv/pybossa/trusty/1 I’m doing a major update before pushing it again to the review queue. Can someone explain me why the revision number does not update on jujucharms.com (it is still on 2) ? | 07:45 |
|---|---|---|
| therealmarv | Is there a problem with ingestion ? | 08:43 |
| === scuttlemonkey is now known as scuttle|afk | ||
| * Mmike grabs food | 12:44 | |
| === anthonyf is now known as Guest35437 | ||
| === scuttle|afk is now known as scuttlemonkey | ||
| === lazyPower|eow is now known as lazyPower | ||
| redelmann | hi, is anyone having troubles with local deploy (KVM/LXC) and dhcp changes for using some machine in differents dhcp server? (home/work) | 14:08 |
| === kadams54 is now known as kadams54-away | ||
| redelmann | juju set apiaddresses on all agents to wlan ip | 14:09 |
| === redelmann is now known as redelmann|afk | ||
| lazyPower | redelmann|afk: i'm not sure what you're asking - whats happening? | 14:19 |
| === redelmann|afk is now known as redelmann | ||
| redelmann | lazyPower, after add a machine "juju add-machine" | 14:24 |
| redelmann | lazyPower, for some reason inside added machine | 14:25 |
| redelmann | lazyPower, in "/var/lib/agents/machine-n/agent.conf" | 14:26 |
| redelmann | lazyPower, apiaddresses: - my.wlan.ip:17070 | 14:27 |
| redelmann | lazyPower, so agents are using my wlan0 ip that always changes if i connect to another network | 14:27 |
| redelmann | lazyPower, after a reboot, if wlan0 ip changes all agents stop working. | 14:28 |
| lazyPower | redelmann: did you alter the default lxc networking config? | 14:33 |
| redelmann | redelmann, no, everything is in default. fresh installation | 14:34 |
| lazyPower | which version of Juju? | 14:34 |
| redelmann | lazyPower, i'm using container: kvm in environment.yaml | 14:35 |
| redelmann | 1.23 | 14:35 |
| lazyPower | dimitern: ping ^ | 14:35 |
| redelmann | lazyPower, i could see STORAGE_ADDR: 192.168.122.1:8040, which is my virbr0 ip | 14:36 |
| lazyPower | redelmann: i'm not sure why thats happening, but i've pinged a dev thats been working on networking support in juju, which may or may not be related | 14:36 |
| lazyPower | and he might be able to help square you away. What I suggest is to file a bug w/ this behavior, and ping the list with it to get some eyes on it | 14:37 |
| redelmann | ack | 14:37 |
| dimitern | lazyPower, pong | 14:38 |
| dimitern | redelmann, lazyPower, ack, will look a bit later | 14:41 |
| lazyPower | thanks dimitern | 14:43 |
| === kadams54-away is now known as kadams54 | ||
| === redelmann is now known as redelmann|lunch | ||
| === redelmann__ is now known as redelmann | ||
| pmatulis | in the about-juju docs [1], what is meant by "reuse whatever they want from other teams" | 17:45 |
| pmatulis | [1]: https://jujucharms.com/docs/stable/about-juju | 17:45 |
| === kadams54 is now known as kadams54-away | ||
| rick_h_ | pmatulis: so let's say you're part of two teams and the application stack is mostly the same (apache, django, postgresql) but my team uses redis and your team uses memcache. | 17:50 |
| rick_h_ | pmatulis: we can work together, using charm interfaces to reuse the rest of the stack yet the two teams can easily disagree on the caching part of the stack | 17:51 |
| rick_h_ | e.g. if I find better apache config settings and update the charm, you can reuse that and gain the same benifits | 17:51 |
| pmatulis | rick_h_: gotcha, so share some charms but not necessarily all | 17:52 |
| rick_h_ | pmatulis: exactly, and you can even have two different charms that implement the same inteface and swap them out | 17:52 |
| rick_h_ | pmatulis: so let's say I want haproxy up front but you want to proxy throgh nginx. As long as we use the same proxy relation guide we can take the same app but proxy it different just by connecting it to different services | 17:53 |
| pmatulis | rick_h_: makes sense, thank you | 17:53 |
| rick_h_ | pmatulis: np | 17:54 |
| === redelmann__ is now known as redelmann | ||
| kandar | hey | 19:02 |
| lazyPower | hazmat: ping | 19:35 |
| hazmat | lazyPower: pong | 19:35 |
| lazyPower | ahoy, I just noticed a comment on the DO api v1 sunset issue over on our juju provider | 19:35 |
| lazyPower | are you still working through that? if not i'll advise to use manual for the time being, v2 contributions appreciated. | 19:36 |
| hazmat | lazyPower: if we allow for growing the dependencies, its easy enough to knock out | 19:36 |
| lazyPower | i dont think there's any reason to be stingy with the dependency tree at this time | 19:37 |
| lazyPower | considering projects like this exist: https://github.com/koalalorenzo/python-digitalocean | 19:37 |
| lazyPower | we could pretty much bind on that API lib, and do the rewrite in a weekend (thats engineering optimism at its finest right?) | 19:38 |
| lazyPower | hazmat: replied. Thanks mate | 19:41 |
| hazmat | lazyPower: i'd guess a few hrs ;-) | 19:41 |
| lazyPower | Yeah, but you're a wizard harry | 19:42 |
| hazmat | lazyPower: i like this lib the most re doV2 api but its got some unfortunate ssh helpers that widen the dependency tree to include paramiko https://github.com/changhiskhan/poseidon | 19:43 |
| lazyPower | ah yeah | 19:44 |
| lazyPower | well, lets cross fingers someone in the community steps up to do the v2 migration in the next couple of weeks. It would be nice to see the consumers give back :) | 19:45 |
| === redelmann__ is now known as redelmann | ||
| === alexisb is now known as alexisb_lunch | ||
| === kadams54 is now known as kadams54-away | ||
| === natefinch is now known as natefinch-afk | ||
| === alexisb_lunch is now known as alexisb | ||
| cholcombe | lazyPower: do you know how maas zones are supposed to work? | 22:33 |
| cholcombe | i'm wondering what gets relayed back to my charm and what i'm supposed to do with it | 22:34 |
| cholcombe | can amulet use an apt-proxy? | 22:44 |
| lazyPower | cholcombe: sorry i was in my audio studio and didn't get your pings until just now | 22:45 |
| cholcombe | no worries | 22:45 |
| lazyPower | cholcombe: AIUI, MAAS zones are the same as regions, your charm wont see it, as thats abstracted away by the "provider" layer of juju | 22:45 |
| cholcombe | oh.. | 22:46 |
| cholcombe | what if i want to see it? haha | 22:46 |
| cholcombe | my charm needs to layout bricks across fault zones | 22:46 |
| lazyPower | also, re: amulet using an apt-proxy - it will default to route through the config of whichever machine you're using. If your charms demand an apt mirror it would be good tos etup a squid-apt-proxy in your test env so they can zero conf configure+utilize if its available. | 22:46 |
| lazyPower | that would be something you leverage in the bundle | 22:47 |
| lazyPower | thats a layer above the charms concerns | 22:47 |
| cholcombe | hmm | 22:47 |
| cholcombe | interesting alright | 22:47 |
| lazyPower | bcsaller: am I correct in this statement? i'm starting to second guess myself ^ | 22:47 |
| cholcombe | i'm wondering how to do this now | 22:47 |
| lazyPower | cholcombe: i'm 90% certain thats the case | 22:49 |
| lazyPower | you use constraints to set the zone | 22:49 |
| cholcombe | so with constraints in place is it the idea that juju will hand me units in the right order across zones? | 22:50 |
| cholcombe | i'm missing something | 22:50 |
| cholcombe | the case i'm thinking of is i have 3 racks of machines. each rack is defined as a failure zone. how does my charm get a list of units from those zones? | 22:51 |
| cholcombe | i can't be the first one to have thought of this lol | 22:54 |
| bcsaller | lazyPower: iirc you used to be able to juju set-env http(s)-proxy xxx or set-env apt-http(s)-proxy and apply those changes across the whole env, Is that what you mean? | 23:01 |
| lazyPower | bcsaller: ah no, i was referring to zones | 23:01 |
| lazyPower | but thats good to know about pthe proxies too, it's been a good while since i've tinkered with the proxy settings. | 23:01 |
| lazyPower | cholcombe: you define 3 service groups, that deploy to 3 sep. zones as constraints | 23:02 |
| lazyPower | eg: "gluster-group1" -- constraints="zone=rack1" "gluster-group2" --constraints="zone=rack2" | 23:02 |
| cholcombe | so effectively my charm has no idea what is going on | 23:02 |
| lazyPower | so forth and so on | 23:02 |
| cholcombe | all i need to do is layout across servers and i'm good | 23:02 |
| cholcombe | alright that's good enough i think | 23:03 |
| lazyPower | basically, so long as they can communicate with one another that should work as intended | 23:03 |
| cholcombe | right | 23:03 |
| lazyPower | you get a full service group, comprised of 3 clusters in different zones. | 23:03 |
| cholcombe | and i just need to make sure i layout bricks across whatever i see | 23:03 |
| lazyPower | and you dont even need to name them differently afaict, you can just juju deploy, and/or add-unit witht eh constraint in place and it should "just work" | 23:03 |
| lazyPower | but ymmv with "just work" | 23:04 |
| cholcombe | right | 23:04 |
| lazyPower | mostly because you're listening to me :P | 23:04 |
| cholcombe | so slightly annoying from an admin perspective but easy from my charm's perspective | 23:04 |
| lazyPower | dangerous situation to be in | 23:04 |
| cholcombe | heh | 23:04 |
| lazyPower | well, if you think about it like this | 23:04 |
| lazyPower | the admin has to setup these service pools/zones in the first place | 23:04 |
| cholcombe | yup | 23:04 |
| lazyPower | how would charm know what to do that is proper? | 23:04 |
| cholcombe | definitely | 23:04 |
| cholcombe | it wouldn't | 23:05 |
| cholcombe | it doesn't have enough info to act | 23:05 |
| lazyPower | i mean, just because you have 8 zones available to you, it doesn't make sense to propigate across all 8 zones | 23:05 |
| cholcombe | right | 23:05 |
| lazyPower | cholcombe: what kind of music do you listen to? | 23:05 |
| cholcombe | electronic while i'm working. heavy metal when i'm working out :) | 23:06 |
| lazyPower | oh really? | 23:06 |
| lazyPower | Snap | 23:06 |
| cholcombe | why? | 23:06 |
| lazyPower | I'll have something for you on dropbox in a couple minutes then | 23:06 |
| cholcombe | haha | 23:06 |
| lazyPower | Not going to publish this until tomorrow | 23:06 |
| cholcombe | ok | 23:06 |
| lazyPower | but i digress, would be awesome to get feedback | 23:06 |
| cholcombe | sure thing | 23:06 |
| cholcombe | so these constraints. will i have separate clusters for each zone ? | 23:07 |
| cholcombe | cause that could get messy | 23:07 |
| lazyPower | that awkward moment when you realize you're in the public channel | 23:07 |
| * lazyPower facepalms | 23:07 | |
| === JoshStrobl is now known as JoshStrobl|AFK | ||
| cholcombe | :D | 23:07 |
| lazyPower | Nah, you can use the same service name | 23:07 |
| lazyPower | just ensure when youd eploy, and you set the constraints, that you use different zone names for the unit(s) | 23:07 |
| cholcombe | i'm going to have to test this lol. | 23:08 |
| lazyPower | might be a good idea to model it on the CLI and export from teh gui so you get a sense of what it should look like as the final bundle form | 23:08 |
| cholcombe | right | 23:08 |
| lazyPower | but yeah, juju add-unit gluster --constraints="zone=foobar" should do the trick when you go to add unit(s) | 23:08 |
| cholcombe | i know what it should look like from gluster's perspective. i'm just trying to figure out what my charm ends up seeing | 23:08 |
| cholcombe | lemme read the constraint page again | 23:09 |
| === anthonyf is now known as Guest93759 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!