| Prabakaran | Hello Team, I am getting this charm build error which is quite strange and charm build was fine before "http://pastebin.ubuntu.com/19144002/" | 03:59 |
|---|---|---|
| Prabakaran | Could somebody help me on this ? | 03:59 |
| === urulama|__ is now known as urulama | ||
| === roaches_check_in is now known as roaches | ||
| BlackDex | Hello there. I had a juju bootstrap on a virtual system. That host crashed with all its data. Is there some way to rebuild the bootstrap with already running juju deployed systems? | 07:36 |
| BlackDex | no backup what so ever because someone deleted them :( | 07:36 |
| magicaltrout | don't think so BlackDex, you'll be missing the mongo controller, the various ssh keys etc | 07:37 |
| BlackDex | keys can be replaced. But the mongodb is a bitch i think | 07:40 |
| BlackDex | i know the machines were added manually | 07:41 |
| BlackDex | but i don't think that is going to help | 07:41 |
| BlackDex | meh | 07:41 |
| === ant_ is now known as Guest97948 | ||
| cory_fu | lazyPower: Hey, did you see my comment on https://github.com/juju/charm-tools/issues/229 ? I added it after you closed the issue, but I think there's an issue with charmbox there | 13:51 |
| cory_fu | marcoceppi: ^ maybe the version has to do with apt packaging? | 13:52 |
| marcoceppi | cory_fu: it shouldn't have | 13:52 |
| mbruzek | cory_fu: I remember looking at this with lazyPower, we did have the version ranged, not sure if it was pinned | 13:53 |
| cory_fu | mbruzek: Hrm. It's pinned in requirements.txt: https://github.com/juju/charm-tools/blob/master/requirements.txt#L20 but not in setup.py: https://github.com/juju/charm-tools/blob/master/setup.py#L16 | 13:55 |
| cory_fu | That means we're running tests with a different version than what is getting installed | 13:55 |
| cory_fu | And it means that https://github.com/juju-solutions/charmbox/blob/master/install-review-tools.sh#L14 is causing every new version of the lib to get installed, without testing if it works with charm-tools | 13:55 |
| cory_fu | I bring this up because Prabakaran is hitting this: http://pastebin.ubuntu.com/19144002/ | 13:56 |
| mbruzek | cory_fu: so the solution would be to pin it in setup.py? | 13:56 |
| cory_fu | Though that actually does work for me with the latest version, but the opened & closed GitHub issue on charm-tools is another symptom of us not pinning our deps | 13:57 |
| cory_fu | mbruzek: TBH, I think that --upgrade flag in charmbox might upgrade deps irrespective of pinning, but I'm not certain | 13:57 |
| cory_fu | I think a better solution would be to use a yaml library that doesn't let breaking changes get in so frequently. ;) But pyyaml doesn't include the round-trip behavior that we need | 13:58 |
| mbruzek | cory_fu: correct | 13:58 |
| mbruzek | cory_fu: I think marcoceppi would love to reduce the dependencies on other packages | 13:58 |
| mbruzek | cory_fu: but we are stuck with ruamel for now | 13:58 |
| mbruzek | cory_fu: I can propose a pinned version of ruamel in setup.py | 13:59 |
| lazyPower | i'm good with whatever yinz need to do there | 14:00 |
| lazyPower | it was cleaned up after the latest bump, but that doesn't mean we aren't headed for another path.py level breakage | 14:00 |
| mbruzek | I see deprecation warnings in the bundletester builds. | 14:00 |
| mbruzek | path.py will bite us again | 14:01 |
| kjackal | hey cory_fu, I would like some advice on relations... juju relations :) | 14:01 |
| kjackal | cory_fu: let me know when you have 10 minutes to spare | 14:01 |
| cory_fu | mbruzek, marcoceppi, lazyPower: Ok, so it looks like the version of ruamel.yaml that we have pinned in charm-tools actually has a bug of sorts in it. Specifically, parser.py was renamed to parser_.py at some point prior to 0.10.23 and renamed back in 0.11.8. But we only hit this if there's an error in parsing layer.yaml and there's apparently no test coverage of that case | 14:13 |
| lutostag | bcsaller: having a look at http://interfaces.juju.solutions/interface/pgsql/, my first foray into the reactive charm world... hoping you might be able to help me... | 14:13 |
| lazyPower | lutostag - we can help :) whats up? | 14:13 |
| lutostag | lazyPower: cool, so I have this charm that relates to postgresql... where I need to have an extension | 14:14 |
| lutostag | that is provided by git://git.launchpad.net/postgresql-charm, which would let me according to the old way... juju set-relation extensions=tablefunc | 14:15 |
| lutostag | I have this code... http://pastebin.ubuntu.com/19177123/ | 14:16 |
| lutostag | which works and is using the above interface | 14:16 |
| lazyPower | so far, so good | 14:16 |
| lutostag | I don't see how to do a juju set relation, with the interface, should I PR something to https://github.com/bcsaller/juju-relation-pgsql.git or is there an easier way I can get away with it? | 14:17 |
| lutostag | (specifically for the extensions) | 14:18 |
| lazyPower | so i'm not sure what you mean by extensions, sorry for being daft | 14:19 |
| lazyPower | you typically relation-set on the conversation object, as most relations are UNIT scoped | 14:20 |
| lazyPower | so each unit participates, and reads/writes on the wire vs say, global/service where typically all units read, and one unit writes. | 14:20 |
| lazyPower | conv = self.conversation() conv.set_remote({'foo': 'bar'}) | 14:20 |
| lazyPower | as an example | 14:20 |
| lutostag | ah I see https://github.com/bcsaller/juju-relation-pgsql/blob/master/requires.py inherits RelationBase which gets me what I need | 14:21 |
| lazyPower | \o/ glad i was of no help but we got there anyway | 14:21 |
| lutostag | so I can just do a 'pgsql.set_remote(...)' like my paste above | 14:22 |
| lazyPower | yep | 14:22 |
| lazyPower | here's an example of the inverse being used | 14:22 |
| lazyPower | https://github.com/juju-solutions/interface-etcd/blob/master/peers.py#L63 | 14:22 |
| lutostag | cool | 14:22 |
| lutostag | that helps me enough to run into the next wall. Thanks | 14:22 |
| lazyPower | lutostag - always happy to help. ping if stuck :) | 14:23 |
| mbruzek | cory_fu: https://github.com/juju/charm-tools/pull/232 | 14:23 |
| cory_fu | mbruzek: https://github.com/juju/charm-tools/issues/233 | 14:24 |
| cory_fu | mbruzek: 0.10.23 is actually somewhat broken | 14:24 |
| mbruzek | ah | 14:24 |
| mbruzek | What version would you like cory_fu? | 14:25 |
| cory_fu | The current version seems to work fine. 0.11.14 | 14:25 |
| mbruzek | cory_fu: I see it in the bug | 14:25 |
| mbruzek | cory_fu: on it. | 14:26 |
| cory_fu | kjackal: Sorry for the delay. I'm in daily-bigdata if you want to try to squeeze it in before the sync | 14:26 |
| cory_fu | mbruzek: Thanks! | 14:26 |
| mbruzek | cory_fu: I updated to 0.11.14 and ran the tests they still pass | 14:30 |
| mbruzek | cory_fu: updated PR 232 | 14:30 |
| cory_fu | mbruzek: I should point out that they passed before. There's apparently no test coverage of that code-path | 14:31 |
| cory_fu | It would be nice to add one. Is your branch on juju-solutions or your own fork? If the latter, I can add a test case after our sync | 14:31 |
| mbruzek | I should point out that I am actually working on something else at the moment | 14:31 |
| cory_fu | mbruzek: Ha. I was just offering to do it, but now you're being rude so maybe I won't. ;) | 14:32 |
| mbruzek | cory_fu: my own fork, do or do not, there is no try. | 14:32 |
| cory_fu | mbruzek: Oh, well then I can't update the PR | 14:33 |
| mbruzek | You "could" it would just have to be against my fork | 14:33 |
| cory_fu | Sure, ok | 14:33 |
| mbruzek | chuck makes PRs against my branch often, in fact I have one here. | 14:34 |
| mbruzek | https://github.com/juju-solutions/layer-dockerbeat/pull/6 | 14:34 |
| mbruzek | no | 14:34 |
| mbruzek | That is untrue | 14:34 |
| mbruzek | oh well | 14:34 |
| neiljerram | mbruzek, hi | 14:36 |
| mbruzek | neiljerram: hello | 14:36 |
| mbruzek | neiljerram: what is up? | 14:37 |
| marcoceppi | cory_fu mbruzek we can't put newer versions of hte library | 14:46 |
| marcoceppi | it has to match what's in Xenial, which is 0.10.23 | 14:46 |
| cory_fu | marcoceppi: But that's broken | 14:47 |
| marcoceppi | we need to get it updated in Xenial then | 14:47 |
| neiljerram | mbruzek, sorry, just a mo - another conversation... | 14:47 |
| marcoceppi | which won't allow you to jump to an 0.11.X version | 14:47 |
| marcoceppi | so is there a 0.10.X version that has the fix? | 14:47 |
| neiljerram | mbruzek, hi again - one of my customers, using the new etcd charm, asked if it had any support for key rotation. | 14:49 |
| mbruzek | neiljerram: not that I know of, but that is something that could be built into the layer-tls | 14:50 |
| lazyPower | neiljerram - not today, but we can add that, in terms of generate new keys. There's no CA to speak of, to invalidate as they are self signed PKI | 14:50 |
| neiljerram | mbruzek, lazyPower - thanks, that's what I guessed. | 14:51 |
| mbruzek | neiljerram: We haven't had that type of requirement, I don't understand when you would want to rotate keys. | 14:52 |
| cory_fu | marcoceppi: Unfortunately, no. It was fixed in 0.11.8. We could instead change our code to use parser_ instead of parser and keep the current version (and pin it in 0.10.23) | 14:52 |
| lazyPower | mbruzek - key expiration, a key was compromised, ssl bug like heartbleed | 14:52 |
| neiljerram | mbruzek, Understood, and I don't really understand the requirement either. (Except perhaps just 'as an extra precaution, if you think someone might be cracking your key'? But that's vague.) | 14:53 |
| marcoceppi | cory_fu: we need to do that, then, unfortuantely | 14:54 |
| mbruzek | so we can discuss the details and look into a solution | 14:55 |
| === rockstar_ is now known as rockstar | ||
| lazyPower | neiljerram - since the keys are peer to peer exchanged, if they have access to the box you've got bigger problems than ssl keys :) However I do understand the desire to be as secure as possible, and i've thought about this | 14:58 |
| neiljerram | mbruzek, of course. If this is a firm requirement, I'll be happy to include you and lazyPower in the discussion. | 14:58 |
| lazyPower | i was going to hold off on implementing any of that until we got a proper CA setup, and could then issue revokations during key rotation, so they keys become invalid at the CA level across the deployment. but thats not on our roadmap at all for this cycle | 14:59 |
| === rogpeppe1 is now known as rogpeppe | ||
| bdx_ | standing up the first juju infra for creativedrive today - starting with a beats/elastic/kibana stack in aws! | 16:27 |
| marcoceppi | bdx_: awww yeah, you using the beats-core bundle? | 16:28 |
| bdx_ | lazyPower:^ | 16:28 |
| bdx_ | yea | 16:28 |
| bdx_ | I gave a demo yesterday ... went really well | 16:29 |
| bdx_ | I got the ok to bootstrap up! | 16:29 |
| bdx_ | initially, the servers that will need the beats agents wont be part of a juju model | 16:30 |
| bdx_ | so I will be manually adding them | 16:30 |
| bdx_ | can I 'juju add-machine ssh:ubuntu@<ip>' using 'aws' as my cloud? | 16:32 |
| lazyPower | yep | 16:32 |
| lazyPower | so long as your controller can reach the nodes you're enlisting | 16:32 |
| lazyPower | and bdx_ - BAD ASS! | 16:33 |
| bdx_ | sick | 16:33 |
| lazyPower | \o/ | 16:33 |
| bdx_ | game on | 16:33 |
| lazyPower | i mean, thats super awesome | 16:33 |
| bdx_ | lazyPower: you are super awesome! | 16:33 |
| bdx_ | thanks for all the beats man! | 16:33 |
| lazyPower | :D bdx_ there's a development channel bundle with packetbeat and dockerbeat too | 16:33 |
| lazyPower | so if you feel intrepid, go for the gusto my friend. juju deploy cs:~contianers/beats-core --channel=development | 16:33 |
| lazyPower | without the typo in containers.. | 16:34 |
| bdx_ | ha | 16:34 |
| === natefinch is now known as natefinch-afk | ||
| Prabakaran | kwmonroe, i just tested my sample charm and it is pending for long time on unknown state with the log http://paste.ubuntu.com/19194830/ and code files are http://paste.ubuntu.com/19194662/ http://paste.ubuntu.com/19194666/ http://paste.ubuntu.com/19194668/ Kindly check and advise me on this issue | 17:49 |
| === natefinch-afk is now known as natefinch | ||
| === fginther` is now known as fginther | ||
| bdx_ | hey whats up guys - few questions on 'aws' cloud in 2.0 if anyone is out there | 20:12 |
| bdx_ | 1. Can one controller "manage" multiple aws accounts? | 20:13 |
| bdx_ | 2. Are aws accounts user sensitive ? | 20:14 |
| magicaltrout | 1) not that I know of | 20:15 |
| magicaltrout | 2) they are controller sensitive if that helps. So you can run x controllers in the same account | 20:15 |
| magicaltrout | or I'm missing the point | 20:16 |
| bdx_ | ^ e.g. does a user have an aws account associated with them, or possibly the inverse of this? | 20:16 |
| bdx_ | magicaltrout: hey, thanks | 20:16 |
| bdx_ | magicaltrout: say I have aws-account-ABC and aws-account-XYZ, is a single controller capible of distinguishing between the two | 20:17 |
| bdx_ | ? | 20:17 |
| magicaltrout | not to my knowledge bdx_ when you bootstrap a controller you just pass it an AWS account | 20:18 |
| magicaltrout | I don't believe you could pass >1 | 20:18 |
| bdx_ | magicaltrout: e.g. credentials.yaml <- http://paste.ubuntu.com/19208532/ | 20:20 |
| bdx_ | ooh my bad ... aws1 and aws2 are individual "clouds" | 20:20 |
| magicaltrout | well you can have multiple aws accounts registered | 20:20 |
| magicaltrout | but you bootstrap to a single one | 20:20 |
| bdx_ | magicaltrout: how do you make use of the subsequent accounts? | 20:21 |
| bdx_ | lets say you want model-A to be aws-acct-A and model-B to be aws-acct-B ? | 20:22 |
| bdx_ | would you set that in the model config? | 20:22 |
| magicaltrout | bootstrap a controller in aws-acct-B | 20:22 |
| bdx_ | yup | 20:22 |
| bdx_ | how does the controller in aws-acct-B know about aws-acct-A? | 20:23 |
| magicaltrout | doesn't | 20:23 |
| bdx_ | bleh | 20:23 |
| bdx_ | "well you can have multiple aws accounts registered " | 20:23 |
| magicaltrout | i might be wrong, but i've never seen it happen | 20:23 |
| magicaltrout | i live a sheltered life though | 20:24 |
| bdx_ | I thought you are the juju<->aws mastermind! | 20:24 |
| magicaltrout | haha | 20:24 |
| magicaltrout | yeah so i'm just prodding around the various help bits | 20:25 |
| magicaltrout | my understanding is you can have > 1 sets of credentials | 20:25 |
| magicaltrout | and you can specify those creds when bootstrapping an aws cloud | 20:25 |
| bdx_ | lol | 20:25 |
| magicaltrout | but if you have 2 accounts and a controller in each, you can't talk between them | 20:25 |
| magicaltrout | that sorta falls in the to the multi cloud model stuff we discussed on the roadmap mailing list chain a while ago | 20:26 |
| bdx_ | ok, so then why bootstrap with multiple accounts? | 20:26 |
| magicaltrout | I don't, you asked :P | 20:26 |
| magicaltrout | actually thats a lie, I do, but for different customers | 20:26 |
| magicaltrout | so customer 1 has an account, customer 2 has an account | 20:26 |
| magicaltrout | but in reality what you are asking for I also want, so then I can have account 3 which is an internal account that runs centralised monitoring and other bits and pieces | 20:27 |
| bdx_ | ahh, yes, I see how that would be cool ... back to - "customer 1 has an account, customer 2 has an account" | 20:27 |
| bdx_ | is your controller aware of both of those accounts? | 20:28 |
| magicaltrout | is your definition of controller and mine different? | 20:28 |
| magicaltrout | my controllers live within their respective accounts on AWS and know of nothing of each other | 20:28 |
| magicaltrout | I have a juju client which I can point in either direction | 20:29 |
| bdx_ | ah, yes, but still you have a requirement of 1 "controller" (in the juju context) per aws account still then, right? | 20:30 |
| magicaltrout | that is correct | 20:30 |
| bdx_ | lol | 20:30 |
| bdx_ | nice | 20:30 |
| bdx_ | but what you were getting at is the fact that you "can" bootstrap with multiple accounts | 20:30 |
| bdx_ | ? | 20:31 |
| bdx_ | you just can't do anything with them following the bootstrap? | 20:31 |
| magicaltrout | I can run different accounts, you use the --credential operator i believe | 20:31 |
| magicaltrout | so I have multiple juju instances that run fine | 20:31 |
| magicaltrout | butu they are distinct and disparate from one another | 20:31 |
| terje | Hi, I've setup a working maas server on a baremetal system. Now, I'd like to deploy 2.0~beta7-0ubuntu1.16.04.1 on this same hardware in an lxc container. | 21:51 |
| terje | I can't figure out how that's done in the 2.x series. | 21:52 |
| terje | (juju 2.0~beta7-0ubuntu1.16.04.1) | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!