| === natefinch-afk is now known as natefinch | ||
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| === frankban|afk is now known as frankban | ||
| admcleod | kwmonroe: yep that similar | 08:56 |
|---|---|---|
| jamespage | lukasa, thanks for approving the switch to apache 2.0 | 09:43 |
| lukasa | jamespage: No problem. =) | 09:43 |
| jamespage | beisner, https://code.launchpad.net/~james-page/charms/trusty/mongodb/ch-resync-newton/+merge/297046 | 10:55 |
| === zz_CyberJacob is now known as CyberJacob | ||
| beisner | jamespage, ack, will watch for tests to complete. | 11:28 |
| xilet | I am running into issues connecting the cinder container to local block devices, was curious if anyone has that working. (beta7) | 11:32 |
| beisner | jamespage, merged | 11:48 |
| jamespage | xilet, is that with cinder/iscsi? | 11:55 |
| jamespage | and with which provider? LXD/local or MAAS? | 11:55 |
| beisner | jamespage, that's landed | 11:56 |
| xilet | lxd | 11:56 |
| xilet | and honestly I am not sure with iscsi or not, I got the services fixed on the cinder container but I still can't see any of the volume groups passed through from the host | 11:57 |
| xilet | (I am new to juju and cinder so I may be missing something fundemental) | 11:58 |
| jamespage | beisner, also https://code.launchpad.net/~james-page/openstack-charm-testing/ext-port-configuration/+merge/297035 | 12:15 |
| jamespage | xilet, atm its not possible to consume block devices from within a container in the way I think you are trying todo | 12:16 |
| jamespage | xilet, so the only option at the moment are cinder backends that are 100% userspace - like ceph for example | 12:17 |
| jamespage | xilet, so for cinder/iscsi (the defautl) you have to run the cinder-volume service outside of containers... | 12:17 |
| xilet | Ahh ok | 12:17 |
| jamespage | api and scheduler can be run in container still | 12:17 |
| jamespage | xilet, the cinder charm supports this type of split - its a config option | 12:17 |
| jamespage | so you can deploy it twice - once for schedule/api in lxd container, once for volume on hardware | 12:18 |
| xilet | Is there harm in living the container volume service running? | 12:18 |
| jamespage | xilet, well for ceph its still required - it just manges the ceph backend rather than trying todo stuff locally with lvm + iscsi | 12:20 |
| xilet | Thanks, I can dig through the docs, just curious if you know offhand, is there is a decent guide out there about adding additional duplicated services to openstack? | 12:21 |
| xilet | Ah ok, there is one already. | 12:27 |
| jamespage | rick_h_, marcoceppi: is there some sort of flag to ensure that test usage of the charm store does not get registered into the stats? we're about to switch our amulet testing to use cs:xxxxx but I don't want to bloat out the stats. | 12:43 |
| rick_h_ | rogpeppe1: do you know the flaf and how it would work from a bundle, cli, and the querystring? ^ | 12:54 |
| rick_h_ | flag that is | 12:54 |
| rogpeppe1 | rick_h_, jamespage: yeah, one mo, i'll check | 12:55 |
| rogpeppe1 | jamespage, rick_h_: make the request with &stats=0 | 12:56 |
| rogpeppe1 | jamespage: ah, but is this using the charm tool? | 12:56 |
| rick_h_ | rogpeppe1: right how would we get that through the tooling, bundle format so a bundle deploy, juju deploy, etc don't count | 12:58 |
| rogpeppe1 | rick_h_: currently I don't think there's a way to do that | 12:59 |
| rogpeppe1 | rick_h_: we could support an environment variable to disable stats, i guess | 12:59 |
| rick_h_ | rogpeppe1: yea, something like that | 12:59 |
| rogpeppe1 | rick_h_: i'm not entirely sure we want to enable anyone to do it, but i'm not sure there's an alternative | 13:00 |
| rick_h_ | rogpeppe1: taking this to the other channel to include uros | 13:00 |
| rick_h_ | jamespage: how much of this is juju1 vs juju2? (is any of it juju2?) | 13:02 |
| jamespage | rick_h_, well right now its both :-) | 13:03 |
| rick_h_ | jamespage: ok, yea just thinking of the patch we need and going ruh roh...prolly need it on juju1 as well | 13:03 |
| rick_h_ | jamespage: so I'd say go ahead please and we'll work with the teams to get you a way to set it, but it's on the API but not exposed through clients atm :( | 13:03 |
| rogpeppe1 | jamespage: looks like you can disable stats by including a "test-mode: true" field in the model config | 13:08 |
| jamespage | beisner, hey - for the switch to cs I'm going to deal with the fact that some other charms don't support all series, by testing with the closest match | 13:08 |
| jamespage | rogpeppe1, I thought there was something like that! | 13:08 |
| jamespage | beisner, ^^ we'll need to turn that on! | 13:08 |
| beisner | jamespage, so, we'll need to have the amulet helper add &stats=0 to the cs: charm url; and do the same when we update mojo/o-c-t bundles, yah? | 13:09 |
| jamespage | beisner, no we can just set this in the environments.yaml for the overall environment | 13:10 |
| jamespage | test-mode: true | 13:11 |
| beisner | jamespage, ok i missed something in backscroll then | 13:11 |
| beisner | boom right there it is :) | 13:11 |
| beisner | jamespage, ok i can add that to all of our enviros | 13:11 |
| jamespage | sounds like a plan | 13:11 |
| beisner | jamespage, ok test-mode is true everywhere | 13:18 |
| jamespage | \o/ | 13:18 |
| rick_h_ | awesome beisner | 13:19 |
| beisner | jamespage, thx for the ext port fixup (merged) | 13:20 |
| jamespage | beisner, np | 13:20 |
| beisner | jamespage, rick_h_ - curious, since juju-deployer (and amulet + bundletester) fetch the charm ahead of deploy, will that model config be effective? | 13:23 |
| rick_h_ | beisner: no, that only effects calls to juju client itself | 13:23 |
| beisner | yep makes sense rick_h_ | 13:23 |
| rick_h_ | beisner: if other clients fetch the charm they need to update the query string for getting the archive | 13:23 |
| beisner | jamespage, seems like a juju-deployer test-mode flag needs to grow, and be plumbed upward to amulet, bundletester and mojo. | 13:25 |
| beisner | that, or we hackily munge the heck out of things on the fly | 13:25 |
| beisner | rick_h_, jamespage - 100% of os-charm testing currently has src ip of our company's known wan IPs. do you know if are we already excluding ourselves from cs stats? | 13:28 |
| kjackal | petevg: Hey are you around? | 13:30 |
| petevg | kjackal: I am. What's up? | 13:30 |
| kjackal | Just saw you comment on the failing test | 13:30 |
| kjackal | how do you run the test? | 13:30 |
| petevg | With bundletester. | 13:31 |
| petevg | The exact invocation: bundletester -t ~/Code/charms/trusty/kafka | 13:31 |
| rick_h_ | beisner: no, we're not removing those from stats, just the long running juju usage numbers | 13:31 |
| petevg | It actually seems to successfully deploy -- I have a kafka server running that is not in an errored state. | 13:32 |
| petevg | kjackal: I suspect that there's a timing issue in the test -- maybe it gets past the point where it has that message too quickly? | 13:32 |
| rick_h_ | beisner: I'm of two minds of just excluding ourselves, might be coming time to do that though | 13:32 |
| kjackal | petevg: did you change this line before running the test: https://github.com/juju-solutions/bigtop/blob/kafka/bigtop-packages/src/charm/kafka/layer-kafka/tests/01-deploy.py#L18 | 13:33 |
| kjackal | ? | 13:33 |
| beisner | rick_h_, yah ditto. there are deploys happening for real production workloads, so that may not be best. it'd be an easy big hammer though ;-) | 13:33 |
| petevg | kjackal: I did not. | 13:33 |
| kjackal | petevg: So let me explain what might be going wrong | 13:34 |
| kjackal | petevg: this test says, go to the store and fetch the kafka charm that should be the same as cs:trusty/kafka | 13:34 |
| kjackal | so this test is supposed to run when we have the charm in the right place | 13:35 |
| kjackal | if we are to test this right now we should change it to something like local:trusty/kafka | 13:35 |
| kjackal | so that it picks-up the charm you are building/reviewing.... | 13:36 |
| petevg | kjackal: Hmmm ... bundletester seems to be smart enough to just go and grab the charm locally if you pass the local path to -t. | 13:36 |
| kjackal | it does? Nice, didnt know that | 13:36 |
| kjackal | ok then it is a real error, I will take a look | 13:37 |
| petevg | Cool. | 13:37 |
| petevg | Now I know why the team has been giving me funny looks when I've been talking about running bundletester from a locally built charm -- maybe it's not widespread knowledge that it works :-) | 13:39 |
| kjackal | :) | 13:40 |
| kjackal | pgrep of java in a kafka deployment gives this output: https://pastebin.canonical.com/158511/ | 13:41 |
| jamespage | beisner, https://code.launchpad.net/~james-page/charm-helpers/amulet-switch-to-cs/+merge/297060 | 13:41 |
| beisner | jamespage, that looks like it will do the trick. did you see the convo ^ re: test-mode only applying to juju proper cmds, and not juju-deployerisms (amulet, mojo)? | 13:46 |
| jamespage | beisner, I've tested precise/trusty/xenial with with that in keystone - raised https://review.openstack.org/#/c/328305/ to test in full | 13:46 |
| jamespage | beisner, hmm does deployer collect the charms itself? | 13:47 |
| beisner | jamespage, awesome i was just thinking: we should sync this and push a thing or two through the pipeline. :) good deal | 13:47 |
| beisner | jamespage, yes i believe so | 13:47 |
| beisner | jamespage, at least for all non cs: it does. | 13:47 |
| jamespage | beisner, it downloads cs ones directly to a local cache dir | 13:53 |
| beisner | jamespage, seems like a juju-deployer test-mode flag needs to grow, and be plumbed upward to amulet, bundletester and mojo. | 13:54 |
| beisner | <beisner> that, or we hackily munge the heck out of things on the fly | 13:54 |
| * beisner refers to self in the third person ;-) | 13:54 | |
| beisner | so glad it's friday | 13:54 |
| beisner | jamespage, but since we're in control of that cs url in the amulet helper, we could also address it there and fix one test-mode path | 13:56 |
| jamespage | beisner, oh - btw I poked at a few instances I got doing manual testing that did not bootstrap as juju nits | 14:00 |
| jamespage | units rather | 14:00 |
| jamespage | beisner, I did a rebuild on the existing machines, and post rebuild they got metadata and joined OK | 14:00 |
| jamespage | which is frustrating | 14:00 |
| jamespage | so its some sort of race between the instance booting and metadata being present/provided. | 14:01 |
| beisner | jamespage, interesting. any clues in timing on serverstack hosts? | 14:03 |
| beisner | (logs on hosts i mean of course) | 14:04 |
| jamespage | beisner, no waiting to hit another so I can log dive at the same time | 14:04 |
| beisner | jamespage, can you review / button poke @?: https://github.com/openstack-charmers/bot-control/pull/1 ... fyi: https://github.com/openstack-charmers/bot-control/blob/charm-what/tools/README.charm-what.md | 14:10 |
| jamespage | stokachu, does conjure-up have a KVM option for the all-in-one under LXD deployment? | 14:14 |
| stokachu | jamespage: not by default, i wanted to make openstack-base conjure-up enabled which would provide that | 14:14 |
| jamespage | beisner, lgtm | 14:14 |
| jamespage | stokachu, also does the LXD deployment include cinder atm? | 14:15 |
| stokachu | jamespage: yea | 14:15 |
| jamespage | stokachu, that's not going to be functional with nova-lxd | 14:15 |
| jamespage | nova-lxd does not support persistent block storage options atm | 14:15 |
| jamespage | as lxd can't do it securely just yet | 14:15 |
| kjackal | petevg: I cannot confirm the error you see in kafka . This is what my test run got me https://pastebin.canonical.com/158519/ | 14:15 |
| stokachu | jamespage: this is the bundle im using https://github.com/battlemidget/openstack-novalxd/blob/master/bundle.yaml | 14:15 |
| stokachu | jamespage: should i remove cinder? | 14:16 |
| jamespage | yes | 14:16 |
| stokachu | jamespage: ok | 14:16 |
| petevg | @kjackal: Hmmm ... I'll run the tests again, and do some more digging. | 14:16 |
| stokachu | jamespage: https://github.com/battlemidget/openstack-novalxd/tree/master/conjure i was going to propose something similar for openstack-base | 14:17 |
| kjackal | petevg: I will redo the test again | 14:17 |
| beisner | thx jamespage | 14:17 |
| petevg | Hopefully, we are not looking at something unique to my machine. | 14:17 |
| jamespage | stokachu, I think you adapted the nova-lxd bundle from my original kvm one right? | 14:18 |
| stokachu | jamespage: yea | 14:18 |
| kjackal | petevg: it is strange that your test did run.... but the assertion failed.... | 14:21 |
| kjackal | i suspect some race condition there.... let me add a wait for the Ready message | 14:22 |
| aisrael | tvansteenburgh: Do you know anything about limitations in testing juju storage via amulet? | 14:24 |
| tvansteenburgh | aisrael: nop. | 14:28 |
| tvansteenburgh | nope | 14:28 |
| tvansteenburgh | aisrael: that doesn't mean there aren't some though, i just don't know. haven't really done anything with storage | 14:32 |
| aisrael | tvansteenburgh: Thanks. I'll get some clarification on what they mean | 14:39 |
| aisrael | tvansteenburgh: This is the issue: https://github.com/juju/amulet/issues/112 | 14:40 |
| tvansteenburgh1 | marcoceppi: ^ | 14:43 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| aisrael | tvansteenburgh: An unrelated amulet/bundletester question. If a test should be skipped because some requirement isn't met (env variables, running on lxc, etc), is there a way tell bundletester to consider the test skipped vs. failing it? | 14:44 |
| tvansteenburgh | marcoceppi: shall i carve out a little time for that? | 14:44 |
| marcoceppi | tvansteenburgh: yes | 14:44 |
| tvansteenburgh | aisrael: bt doesn't have the notion of skip, only pass/fail. you can control which tests are run with the tests key in tests.yaml though | 14:48 |
| aisrael | tvansteenburgh: ack, thanks | 14:50 |
| tvansteenburgh | aisrael: feel free to open a bug for the skip feature though, if you want | 14:50 |
| aisrael | tvansteenburgh: will do! | 14:51 |
| jamespage | icey, I will look in detail at charms.storage but can you add the testr/tox configuration as per https://github.com/openstack-charmers/charms.openstack | 15:17 |
| jamespage | and drop all the legacy makefile stuff | 15:17 |
| jamespage | icey, this will ease migration under /openstack | 15:17 |
| icey | jamespage: I can work on that; first time intentionally using tox :-P | 15:17 |
| jamespage | icey, essential for migration to openstack infra | 15:17 |
| jamespage | icey, we also need to get setup with publishing these modules to pypi and doing propoper releases; some of that we shoudl defer until we migration as there is alot of automation we can leverage there... | 15:18 |
| === arturt__ is now known as arturt | ||
| marcoceppi | cory_fu: I have a crazy idea wrt tactics | 15:39 |
| marcoceppi | nvm | 15:40 |
| cory_fu | That was quick | 15:40 |
| aisrael | tvansteenburgh1: Another bundletester question. If a charm requires a kernel module be loaded (local provider/lxd, so must be loaded on host), is that an option? There's nothing explicit in tests.yaml, but what about a makefile target to do it? | 15:40 |
| marcoceppi | cory_fu: I wanted to do something crazy, but then I thought about it and changed my mind | 15:41 |
| cory_fu | Indeed | 15:41 |
| tvansteenburgh1 | aisrael: sure | 15:41 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| tvansteenburgh | aisrael: you can run whatever code you want, either in a make target or in a test itself | 15:42 |
| aisrael | tvansteenburgh: k, thanks. It may not be an issue if we're able to skip certain environments (like local) | 15:43 |
| icey | jamespage: build is passing, using the tox settings and travis settings from charms.openstack :) | 16:32 |
| jamespage | \o/ | 16:39 |
| === frankban is now known as frankban|afk | ||
| thedac | DNS HA charm helpers ready for review https://code.launchpad.net/~thedac/charm-helpers/dnsha/+merge/297009 | 17:01 |
| rick_h_ | beisner: can I bug you a second on connecting to an openstack please? | 18:19 |
| beisner | howdy rick_h_ | 18:19 |
| rick_h_ | beisner: I'm poking at someone running a hosted openstack cloud and tring to figure out how I'd setup juju config to talk to it | 18:19 |
| rick_h_ | They've got me creating an application and having an application key and a secret key, sound familiar at all? | 18:20 |
| beisner | rick_h_, generally you'll need the keystone endpoint address of their cloud, plus your tenant username, password and region name. | 18:26 |
| natefinch | can anyone give me a simple example of a bundle that deploys units to lxc containers? | 18:42 |
| rick_h_ | natefinch: not off the top of my head but built one with the machine view on demo.jujucharms.com and exported it here: https://pastebin.canonical.com/158543/ | 18:48 |
| rick_h_ | just made up something | 18:48 |
| cherylj | natefinch: here's one I had for a bug a while ago: http://paste.ubuntu.com/17180954/ | 18:48 |
| mattrae | hi, is it possible to upgrade-charm, going from the charm store to a local charm? it doesn't seem to work to specify --path https://pastebin.canonical.com/158545/ | 18:54 |
| natefinch | rick_h_, cherylj: thanks. | 18:54 |
| rick_h_ | mattrae: normally you have to update-charm --switch | 18:54 |
| rick_h_ | mattrae: that will let you go from one charmstore url to another.../me hasn't tested if that lets you go to local? | 18:55 |
| mattrae | thanks rick_h_ yeah looks like for a local charm you may need to use --path rather than --switch.. according to the help --path and --switch are mutually exclusive, so i thought it may not work | 18:58 |
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| cory_fu | Oh, hey, kwmonroe. I forgot that I got the bundle_deploy added to bundletester. That was to fix an issue we had in one of our bundles, to give us more control over the initial deploy. I forget what the issue was, though. | 20:17 |
| cory_fu | However, we could use that to manage the deployer timeout ourselves | 20:18 |
| kwmonroe | cory_fu: i dont recall what you mean by 'bundle_deploy added to bundletester' | 20:21 |
| kwmonroe | oh, yes i do | 20:22 |
| cory_fu | kwmonroe: https://github.com/juju-solutions/bundletester#testsyaml | 20:22 |
| kwmonroe | https://github.com/juju-solutions/bundletester/issues/43 | 20:22 |
| cory_fu | Yeah, that | 20:22 |
| kwmonroe | why the heck aren't we using that? | 20:22 |
| cory_fu | Ok, so it was to fix something where we needed to reset the env. Hrm. Wish I could remember what the failure was | 20:22 |
| === natefinch is now known as natefinch-afk | ||
| icey | jamespage: the hardening one has me stumped, it's now using tox but still no module named apt: https://travis-ci.org/ChrisMacNaughton/charms.hardening | 21:04 |
| cory_fu | Can someone remind me how to run bundletester with a bundle from the store? | 21:34 |
| cory_fu | Ah, never mind. I remembered how to read | 21:34 |
| cory_fu | Though the --help output on BT could be better (I would never have guessed TESTDIR is what I wanted) | 21:35 |
| cory_fu | kwmonroe: Hey, how is BT not failing every time on hadoop-processing given that it doesn't contain a Makefile? | 21:39 |
| kwmonroe | cory_fu: what happens if you run bt from a local copy of the bundle? | 21:48 |
| kwmonroe | so like, bundletester -vF -c bundle.yaml | 21:48 |
| kwmonroe | also cory_fu, i don't see any of our bundles with Makefiles | 21:49 |
| kwmonroe | exhibit a: https://jujucharms.com/realtime-syslog-analytics/, b: https://jujucharms.com/apache-analytics-sql/, etc | 21:50 |
| cory_fu | Right. I'm trying to figure out why I'm getting this: http://pastebin.ubuntu.com/17188103/ | 21:50 |
| kwmonroe | dunno cory_fu, i always run like this: ubuntu@a5d019db9619:~/charms/bigtop/bigtop-deploy/juju/hadoop-processing$ bundletester -Fvl DEBUG -t tests | 22:03 |
| kwmonroe | i'm guessing cwr does too | 22:03 |
| cory_fu | kwmonroe: cwr runs it from the store, but it uses bundle:hadoop-processing instead of cs:hadoop-processing | 22:05 |
| cory_fu | Oh, drat. That didn't actually fix it | 22:06 |
| cory_fu | kwmonroe: Apparently, running bundletester with Juju 2.0 hits that issue but 1.25 does not | 22:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!