#juju 2011-11-07
<hazmat> g'morning
 * niemeyer waves
<hazmat> niemeyer, g'morning
<niemeyer> hazmat: Heya
<pindonga> morning... so I am trying to use juju for managing lxc containers for development (I know this is not the primary use case for it)
<pindonga> the problem I'm facing is that containers do not survive a reboot (I have to destroy the whole env and rebootstrap)
<pindonga> I know this is a known issue, but I was wondering if there is a workaround for it
 * noodles775 is interested too. I thought by putting my juju-dir somewhere other than /tmp I could avoid that.
<hazmat> hmm
<pindonga> noodles775, no, I have my data-dir in /home and this is still the case
<pindonga> btw I'm running a freshly installed oneiric
<hazmat> so there are two issues here, one for hibernation (which is problematic in a different way) and one for reboot, the first one is a work in progress, the second one doesn't have a workaround, it can be done by hand though, albeit its a pretty tedious process
<pindonga> another issue I have is that I don't get lxc containers to start (for some reason cgroup is not mounted automatically by juju)
<hazmat> it requires starting zookeeper by hand, and the machine agent, and then starting all the containers
<pindonga> hazmat, is this written down somewhere?
<hazmat> juju will need to write out an upstart job per environment to make this a bit cleaner
<hazmat> and automatic
<hazmat> pindonga, its not written down, i'm finishing up an email atm, i'll see if i can put together a workaround after
<pindonga> hazmat, awesome
<pindonga> hazmat, another thing: can you think of a reason why the cgroup is not mounted automatically by juju?
<pindonga> may it be that I bootstrapped using distro-series: lucid? (I'm running on oneiric though)
<hazmat> pindonga, only the host distro matters regarding the cgroup mount, and juju doesn't handle mounting it, it should be automatic though
<pindonga> hazmat, automatic as in? if juju doesn't handle it, does lxc handle it? do I need a cgroup entry in /etc/fstab?
<hazmat> pindonga, automatic as its handled by the cgroup-bin package's upstart job
<hazmat> pindonga, see /etc/init/cgconfig
<hazmat> pindonga, it does not need to be in fstab
<pindonga> hazmat, don't have that file., but I have /etc/init/cgoup-lite
<pindonga> I run cgroups-mount manually and it's now mounted I think
<hazmat> pindonga, yeah.. i think the other one might have been an old natty file.. cgroup-lite looks correct
 * hazmat pokes at the packages
<hazmat> ah.. ic. cgroup-lite is a minimal set which can support lxc, cgroup-bin also suffices for lxc but has additional cgroup tools
<pindonga> ok, got one container up \o/
<pindonga> however, the sources file still reads oneiric as the distro
<pindonga> :(
<pindonga> even though I had lucid in environemtns.yaml
 * niemeyer => lunch
<hazmat> pindonga, yeah.. there was a bug filed about that
<hazmat> bug 886364
<pindonga> ah, ok
<_mup_> Bug #886364: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 >
<pindonga> tx
<brtsz> hi guys
<hazmat> brtsz, greetings
<hazmat> pindonga, i'm looking at what a workaround would take, doesn't seem like its something that's doable cleanly as a manual script it would need some patching of libraries to record port information, better to just implement per desired direction of using upstart
<pindonga> hazmat, yeah... I think I found a workaround for the time being
<pindonga> just use plain lxc without juju for my dev lxc containers :)
<pindonga> as I don't need juju really for that
<pindonga> it was just nice to have it manage my lxc containers too
<pindonga> thanks for the help though, it's been really useful so far
<hazmat> pindonga, np
 * hazmat lunches
<noodles775> Is this a known bug? (specifying a config.yaml results in charm not being found, move it out of the way and it deploys): http://paste.ubuntu.com/731083/
 * noodles775 can't see any bugs on bugs.launchpad.net/juju for config.yaml
<_mup_> Bug #887194 was filed: charm not found on config.yaml parse error <juju:New> < https://launchpad.net/bugs/887194 >
<hazmat> noodles775, it was reported with a fix in bug 885515
<_mup_> Bug #885515: More verbose error when issue occurs in config.yaml <juju:In Progress by hazmat> < https://launchpad.net/bugs/885515 >
<noodles775> hazmat: ah, nice (LP's bug search didn't turn it up, but great that the fix is there already :) ).
<hazmat> noodles775, not merged yet, but yeah.. should be in soon
 * noodles775 marks his new bug as a dupe.
<hazmat> jimbaker, ping
<hazmat> hmm.. riak didn't make the hot and hairy list
<nolan_d> I'm trying to understand Juju. I'm in a situation where we have a bunch of servers we'll wish to deploy various services on, and I'm wondering if I should recommend it.
<nolan_d> Is it still limited to one service per machine as a FAQ I read seems to state?
<nolan_d> Feel free to tell me to RTFM, I just need to find a FM to read. :) The one on the Ubuntu wiki seems a bit fragmentary and doesn't really address my questions.
<nolan_d> Also, how does it handle the situation where I might want to, say, host a bunch of services at various domains on a cloud? "expose" is nice, but does it give me any way to say "expose this service at this domain/port/service type?"
<nolan_d> Back later.
<jcastro> https://plus.google.com/b/103184405956510785630/103184405956510785630/posts
<jcastro> juju G+ page is up!
<hazmat> jcastro, nice
<jcastro> adding videos
<jcastro> as soon as I figure out how to make it a team manageable page I'll let you know. :)
#juju 2011-11-08
<hazmat> niemeyer, g'morning
<niemeyer> hazmat: Hey!
 * hazmat is up early to take out the afternoon for a dentist
<hazmat> fwereade, rog greetings
<ejat> morning hazmat
<fwereade> mornings :)
<rog> hazmat, fwereade, niemeyer: hey!
<rog> i saw previous exchange but unity had crashed so i couldn't type anything
<rog> guess what, i've installed oneiric
<rog> (probably my fault though for trying to tweak things with ccsm)
<hazmat> fwereade, thanks for having a  look
<hazmat> at the txzk stuff
<_mup_> txzookeeper/session-and-conn-fail r62 committed by kapil.foss@gmail.com
<_mup_> save the chaos monkey via s/loose/lose ;-)
<_mup_> txzookeeper/session-and-conn-fail r63 committed by kapil.foss@gmail.com
<_mup_> simplify pass through property, reenable retry function test, use min() instead of condition, per review comments
<_mup_> txzookeeper/session-and-conn-fail r64 committed by kapil.foss@gmail.com
<_mup_> verify session event sequence per review comment
<_mup_> juju/session-expiration r408 committed by kapil.thangavelu@canonical.com
<_mup_> incorporate session expiration in process handling and retry client
<_mup_> juju/local-repo-log-broken-charm r413 committed by kapil.thangavelu@canonical.com
<_mup_> metadata parse enriches yamlerror with path info
 * hazmat wishes lp bug search would handle comments
<andylockran> hey guys - I'm looking to work out how best to organise a system for managing my ubuntu installations.
<andylockran> What resource should I look at to find more about running a management system on my own private infrastructure?
<hazmat> andylockran, that sounds like a question better suited to #ubuntu-server .. it depends on what your looking for re 'management', if you mean deployment automation orchestra is nice, if you mean automated machine management, there are a number of closed and opensource tools that might fit the bill from landscape to puppet.. juju itself is focused at a higher level of service management and orchestration
<jcastro> SpamapS: hey don't forget to ask scale-buddy of yours about Charm School
<jcastro> yes, charm school.
<SpamapS> :)
<_mup_> Bug #887644 was filed: juju/go: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/887644 >
<noodles775> oooh, golang now in juju - I'd not realised it had started already :)
<rog> noodles775: early stages yet!
<robbiew> noodles775: ...and not targeted for production release in 12.04 ;-)...but should be a sweet tech preview for sure
<robbiew> m_3: ping
 * hazmat yawns
<hazmat> fwereade, reply sent
 * hazmat heads off to discover the tender mercy of a dentist
<bloodearnest> hey folks
<bloodearnest> using lxc provider, juju ssh is giving me an error: "PTY allocation request failed on channel 0"
<bloodearnest> it worked fine while at UDS last week
<jimbaker> bloodearnest, this seems to be a common problem out there, in terms of googling on that error. i haven
<jimbaker> 't seen it myself however
<jimbaker> eg, http://blog.asteriosk.gr/2009/02/20/pty-allocation-request-failed-on-channel-0/ discusses this issue
<bloodearnest> jimbaker, hey, yeah googling suggests somthing incorrect with /dev/tty setup
<bloodearnest> jimbaker: strange thing is it worked all last week fine :(
<jimbaker> bloodearnest, precisely. i don't think it has anything to do with our lxc stuff, other than it seems like a possible resource exhaustion issue
<bloodearnest> jimbaker: k, I'll try a reboot and see if that clears it up. Been a while anyway... :)
<jimbaker> bloodearnest, ok, well that can fix some issues like this, but not ideal of course
<jimbaker> but it will tell something
<bloodearnest> jimbaker: any other route you'd suggest? I double check running processes, but nothing seemed awry
<jimbaker> bloodearnest, from what i read on the problem, that would not be an issue
<bloodearnest> jimbaker: lsof | grep lxc tells me that a single lxc-start has /dev/pts/[2-6] open
<jimbaker> bloodearnest, but that's a very minimal number of ptys to have open
<bloodearnest> jimbaker: yep
<_mup_> juju/support-num-units r412 committed by jim.baker@canonical.com
<_mup_> Support in juju add-units
<bloodearnest> jimbaker: fwiw, reboot didn't help. Fresh environment, trivial charm, still no ssh :(
<bloodearnest> jimbaker: gotta EOD, but thanks for your help!
<rog> niemeyer: here's a first skeleton of the juju provider-independent tests interface.
<rog> http://paste.ubuntu.com/732246/
<jimbaker> bloodearnest, just pointing out some possibilities. easier if i had the problem myself :(
<rog> comments welcome
<niemeyer> rog: I don't understand what the interface is doing there
<bloodearnest> jimbaker: sure - thanks anyway :)
<rog> niemeyer: it's to enable a given environ provider to run a set of standard juju tests against itself
<rog> niemeyer: as we discussed AFAIR
<niemeyer> rog: what about testProvider(provider)?
<rog> niemeyer: i wanted to do that, but gocheck makes it hard.
<niemeyer> rog: It's a function..?
<rog> because gocheck registration is global
<rog> maybe we could fix that, but i thought i'd try to work within existing constraints first
<niemeyer> rog: It's even easier than that..
<niemeyer> rog: Create a suite, and simply register it for each provider
<niemeyer> rog: Suite(&ProviderSuite{theProvider})
<rog> not so easy. but i've no time to do explain now, gotta go.
<niemeyer> rog: and all the tests will be run independently with the provider set
<niemeyer> rog: Duh
<rog> two places need to call TestingT
<niemeyer> rog: Nope
<rog> because we've got two totally independant sets of tests
<niemeyer> rog: They're simply two suites
<rog> yes, that's what i want
<niemeyer> rog: Suite(&ProviderSuite{provider1})
<rog> but who calls TestingT
<niemeyer> rog: Suite(&ProviderSuite{provider2})
<rog> ?
<niemeyer> rog: A single independent function, like all uses of gocheck
<rog> should jujutest call TestingT?
<rog> i didn't think it should, but perhaps that's the way to go
<niemeyer> rog: Not sure about who's jujutest
<rog> jujutest is called by a provider
<niemeyer> rog: The provider package should do it
<niemeyer> rog: I'd have to know more about the structure to help in that case
<rog> ok, then how does jujutest register its test suite?
<niemeyer> rog: It's feeling more complex than it ought to be..
<niemeyer> rog: I don't know who's jujutest
<rog> niemeyer: jujutest is the platform-independent testing part of juju
<niemeyer> rog: All the tests of juju are platform independent
<rog> niemeyer: i don't want it to be part of juju itself because it's only about testing
<niemeyer> rog: Let's talk about that when you have more time
<rog> yeah, speak tomorrow
<niemeyer> rog: Have a good one
<rog> niemeyer: will do. and you!
<pindonga> hey again, I have an lxc specific question, but maybe you can help me out anyway? I have created an lxc container, which I was able to log in successfully, however after applying updates (it was a fresh lucid install) it now no longer completes booting, and I have no idea how to find out why
<pindonga> I managed to get some log output from it, but not very enlightening
<pindonga> it looks like if init never spawns the getty processes
<pindonga> and I see this:
<pindonga> init: ureadahead-other main process (31) terminated with status 4
<pindonga> init: console-setup main process (32) terminated with status 1
<pindonga> init: ureadahead-other main process (37) terminated with status 4
<SpamapS> pindonga: I'm not sure lucid is going to work... LXC was pretty new then.
<pindonga> SpamapS, I just found out something interesting
<pindonga> I configured network manually with a static address
<pindonga> ssh comes up ok
<pindonga> but the console does not
<pindonga> which even if it's broken works for me
<pindonga> I use the lxc container as a glorified chroot :)
<SpamapS> pin/whois pindonga
<SpamapS> hahahaha doh
<pindonga> \o
 * pindonga waves
<SpamapS> wondered if we met last week ;)
<SpamapS> pindonga: so are you running juju inside an LXC container, spawning more LXC containers?
<pindonga> no, no *that* crazy :)
<pindonga> in the short term I just tried to use juju to manage my lxc instances
<pindonga> so I can do development in an isolated environment
<pindonga> however, juju+lxc doesn't survive reboots yet
<pindonga> so I moved onto just using plain lxc
<pindonga> in the long term I want to move all of our infrastructure to juju (lxc locally and openstack for deployments)
 * hazmat catches up
<hazmat> bloodearnest, so completly allegorical, i had some issues with pty allocation for ssh on lxc, reboots would help.. but once it failed it would never work,  they did effectively disappear though i yanked my virtualbox install and kernel modules.. i'd be curious to look at your lsmod output
<hazmat> jimbaker, ping
<hazmat> pindonga, this isn't really juju related, but you can start the container with a debug log and pass cli options to /sbin/init (ie. upstart) to verbose log as well, that might help... imo, its probably just better to focus on 11.10 with eye to deploying 12.04 lts ... but if you really want it ;-)
<pindonga> hazmat, yes , I was looking at that... thx
<jimbaker> hazmat, hi
<jimbaker> coffee time, biab
<hazmat> jimbaker, priv msg
<_mup_> juju/support-num-units r413 committed by jim.baker@canonical.com
<_mup_> Support in juju deploy
<hazmat> jimbaker, nice
<SpamapS> can we make the bot also tell us when trunk is committed to?
<_mup_> juju/support-num-units r415 committed by jim.baker@canonical.com
<_mup_> PEP8, PyFlakes
<_mup_> juju/support-num-units r416 committed by jim.baker@canonical.com
<_mup_> Better help output for CLI changes
<hazmat> SpamapS, its client side, the code is avail
<hazmat> although its erlang as i recall, not sure where its deployed
<andylockran> hazmat: thanks for your tip.  Ok - I'll look into that - thanks.
<hazmat> SpamapS, https://launchpad.net/mup
<hazmat> andylockran, np
#juju 2011-11-09
<SpamapS> Heh.. seems like we should write a Gobot
<SpamapS> http://www.toyarchive.com/Gobots/GobotsPic2.gif
<SpamapS> tho we might get into some hairy trademark area ;)
<_mup_> Bug #887919 was filed: Juju environment option to specify SSH key? <juju:New> < https://launchpad.net/bugs/887919 >
<rog> fwereade: mornin'
<niemeyer> Yo
<hazmat> g'morning
<fwereade> heya rog, niemeyer, hazmat
<rog> niemeyer, hazmat: mornin'
<rog> niemeyer: somewhat simpler jujutest package interface: http://paste.ubuntu.com/733042/
<niemeyer> rog: Why is that needed?
<rog> niemeyer: where do the tests get defined?
<niemeyer> rog: As far as I understand, we only need a type
<rog> niemeyer: that's the type
<niemeyer> rog: ProviderTests
<rog> i though jujutests.Tests
<niemeyer> rog: and what's Name and Value for?
<niemeyer> rog: This should be within the tests as far as I understand
<rog> niemeyer: it's so we can write tests that call Open twice to check persistance of a juju session
<niemeyer> rog: am I missing something there?
<rog> another possibility would be to pass ProviderFactory func() juju.Provider
<niemeyer> rog: Hmm, no that sounds fine
<niemeyer> rog: But I still don't get what's Value
<niemeyer> rog: Is it Config?
<rog> niemeyer: yeah, that would be a better name
<niemeyer> rog: Aha, I see the picture now, thanks
<niemeyer> rog: +1
<rog> cool
<rog> niemeyer: i think i'll stick with Tests as a name until we want more than one suite.
<niemeyer> rog: Sounds good
<marcoceppi> Is there any way, during config-changed, to extract the value prior to change?
<marcoceppi> Good morning, btw
<niemeyer> marcoceppi: Morning
<niemeyer> marcoceppi: Not with a standard variable, but you can do that trivially by storing the values you got in the last hook call
<marcoceppi> Okay, so I would have to implement it myself then, thanks! Didn't want to duplicate efforts
<niemeyer> marcoceppi: Yeah, we thought for a while about how we might do this, but in the end it feels like the simplicity of the current approach is worth the extra trouble in the cases something like this is interesting
<niemeyer> marcoceppi: There is also the possibility that the configuration will change _twice_ before config-changed is called
<marcoceppi> I don't think it's really important for the majority of cases
<niemeyer> marcoceppi: So it would not be honest if we promised to give you _the last value_
<marcoceppi> Right
<niemeyer> rog: "error" <3
<rog> niemeyer: great innit?
<niemeyer> rog: Totally
<rog> niemeyer: reviewing those gocheck changes by any chance?
<niemeyer> rog: If that's not bothering you right now, I'd like to keep focused on this stuff
<rog> niemeyer: that's fine
<niemeyer> rog: Actually, the gocheck ones might see a review sooner
<niemeyer> rog: Since I'll need them too
<rog> niemeyer: that's the only significant one
<niemeyer> rog: Super
<rog> the others are just gofix + a few minors
<niemeyer> Cool
<niemeyer> Let me do that now
<niemeyer> Actually, let me reboot to sync a kernel upgrade
<niemeyer> brb
<hazmat> new aws region this morning
<rog> niemeyer: what's the best way to cope with the fact that actual ec2 tests need private keys that we don't want to give to everyone?
<niemeyer> rog: As far as the provider test stuff we've been discussing goes, the first batch of tests is actually unity rather than integrational
<niemeyer> rog: So you can put anything as a pair
<niemeyer> rog: We just need to ensure the signature matches
<rog> niemeyer: i'm not sure i know what you mean by "unity". do you mean that we won't actually talk to ec2 itself?
<niemeyer> rog: Yes
<niemeyer> rog: None of the unit tests in juju talk to the real services
<rog> niemeyer: but i want to check that my code actually works with ec2 before writing the other tests!
<niemeyer> rog: You can have a set of tests which is integrational as well.. that'd be nice
<niemeyer> rog: But not enough by itself
<rog> niemeyer: necessary, i think, but not sufficient. i could just use env vars for the keys
<niemeyer> rog: If you want to have integration tests in _addition_ to the unit tests, check out goamz
<rog> niemeyer: i definitely want both.
<niemeyer> rog: The basic trick is that there's a suite of tests that disables itself unless "-i" is passed to the runner
 * hazmat is excited about unified provider testing
 * rog is glad about that
<niemeyer> rog: That's done by calling c.Skip("<the reason>") in SetUpSuite
<rog> niemeyer: ah, i have seen that, but forgotten about it. what does ec2 do about the private keys?
<rog> i mean the ec2 package
<niemeyer> rog: Check goamz.. it has an authenticator that uses the standard EC2 env keys
<rog> niemeyer: cool, so as i thought. makes sense.
<niemeyer> rog: Any other changes outside of the checkers that are not related to os.Error?
 * rog thinks
<rog> i don't think so
<rog> niemeyer: ^
<niemeyer> rog: Cool, posting the review
<niemeyer> rog: Great stuff
<rog> niemeyer: cool
<niemeyer> rog: Sent
<rog> "POP3 checked too recently". dammit, i clicked refresh too early!
<niemeyer> rog: WTF? gmail?
<rog> niemeyer: yeah
<rog> niemeyer: it's ok now - i think it enforces a minute or so's delay
<niemeyer> rog: Yeah, I can see that being a good option.. if people check POP3 the same way they press lift buttons, it'd crash gmail quickly
<rog> niemeyer: :-)
 * rog wonders if panic(nil) is the same as runtime.Goexit()
<niemeyer> rog: They have pretty different semantics
<niemeyer> rog: panic(nil) is just that
<rog> niemeyer: yeah they do. but it's not possible to tell which is which in a recover...
<rog> niemeyer: i guess we just have to hope that noone calls Goexit inside a PanicMatches checker
<niemeyer> rog: What would happen in that case?
<rog> niemeyer: i'll just check
<niemeyer> rog: It should simply say that the error is nil
<niemeyer> rog: Or rather, the recovered value
<rog> niemeyer: yeah, but the caller won't get the value
<rog> that is returned
<niemeyer> rog: Which will likely not match the defined expectation, and the test will fail nicely
<rog> it just executes defers
<rog> if you're doing it in the same thread, the test will finish
<niemeyer> rog: Cool.. no worries
<niemeyer> rog: We can think about that latter.. I'm happy to say "Don't do it" for now
<rog> niemeyer: yeah, i don't think it's a problem in practice - it's just interesting
<niemeyer> rog: Agreed
<rog> niemeyer: BTW, what are "fixtures"?
<niemeyer> rog: It's a fancy well known term for the setup/teardown in a test suite
<rog> niemeyer: ah. not well known to me!
<niemeyer> rog: http://en.wikipedia.org/wiki/Test_fixture
<rog> should just've googled it!
<niemeyer> rog: Sorry, it's certainly fine not to know it.. I just meant to say I wasn't inventing it
<rog> niemeyer: sure. i just saw this name used all over the place with no mention in the docs, and it wasn't obvious to me what it referred to...
<rog> niemeyer: is it deliberate that gocheck/printer_test.go isn't gofmted ?
<rog> [i've never encountered a test before which fails if the test code isn't formatted right :-])
<niemeyer> rog: It is
<niemeyer> rog: Precisely because it's testing printing aspects
<rog> niemeyer: darn, i just mucked it up by doing gofmt on it then
<niemeyer> rog: Just revert it
<niemeyer> rog: There may be a wiser way to test it, but let's not mix the issues
<rog> sure. it just confused me for a bit...
<rog> i'll put a comment in
<rog> niemeyer: could we gofmt everything except printTestFunc ?
<rog> (in another change, of course)
<niemeyer> rog: Yeah, I suspect so.. run the tests and you'll be sure :)
<rog> niemeyer: well, i've submitted the changes (not including that one)
<niemeyer> rog: It's in
<rog> niemeyer: cool
<niemeyer> rog: Thanks again
 * niemeyer => lunch
<bloodearnest> heya juju-ers
<bloodearnest> I may be missing something obvious, but how do I configure a openstack provider (specifically canonistack)?
<bloodearnest> as opposes to an ec2 provider?
<_mup_> Bug #888118 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888118 >
<_mup_> Bug #888119 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888119 >
<niemeyer> bloodearnest: Hey Simon
<niemeyer> bloodearnest: Let me paste you a link, hold on
<bloodearnest> niemeyer: thx
<niemeyer> bloodearnest: https://pastebin.canonical.com/55366/
<niemeyer> bloodearnest: This is Kapil's email explaining how to setup the internal Canonical openstack provider
<niemeyer> (sorry to everybody else, it's just the provider config for Canonical's OpenStack, so not really interesting)
<bloodearnest> niemeyer: great, thanks
<hazmat> bloodearnest, ostack needs diable, but effectively its just the same ec2 provider with additional config
<hazmat> er.. needs the diablo release
<hazmat> or newer
<bloodearnest> hazmat, diablo is what is in the juju/pkgs ppa for oneiric?
<hazmat> bloodearnest, its a question of what version of openstack your running juju against, not the juju version
<hazmat> the version in oneiric or the ppas both work fine against the latest openstack release
<bloodearnest> hazmat: gotcha
<hazmat> which is also in oneiric (latest ostack release)
 * hazmat lunches
<niemeyer> rog: http://paste.ubuntu.com/733258/
<niemeyer> rog: Otherwise we get stuff like this: http://paste.ubuntu.com/733261/
<rog> niemeyer: good point.
<rog> niemeyer: shall i push a change?
<niemeyer> rog: With the change we have this: http://paste.ubuntu.com/733264/
<niemeyer> rog: Not necessary, if you're fine with it I'll commit
<rog> niemeyer: LGTM. we're concerned about the string value, after all.
<niemeyer> rog: Right, cool
<_mup_> txzookeeper/session-and-conn-fail r65 committed by kapil.foss@gmail.com
<_mup_> additional assertion msg on value of test env variable for deb installation of zk
<hazmat> niemeyer, btw the wtf ftests seemed to have stalled out a few revs ago
<hazmat> 404 vs trunk 411
<niemeyer> hazmat: Will have a look at it
<niemeyer> hazmat: I hadn't checked last time you mentioned, sorry
<hazmat> niemeyer, no worries, we've all been busy and traveling
<_mup_> txzookeeper/trunk r44 committed by kapil.foss@gmail.com
<_mup_>  - On session expiration, all extant watches recieve an errback.
<_mup_>    The watches are dead, so there is no purpose in having the session
<_mup_>    error handler diverting errors for them.
<_mup_>  - A retry client facade, that transparently retries operations in the
<_mup_>    face of transient connection errors.
<_mup_>  - A retry function in the style maybedeferred that can perform this
<_mup_>    retry functionality for an arbitrary function.
<_mup_>  - A series of connection failure tests verifying watches are
<_mup_>    delivered to clients that where disconnected at the time of the
<_mup_>    watched modification on the server.
<_mup_>  - version increment to 0.9.0
<hazmat> bcsaller, jimbaker could either of you have a look at lp:~fwereade/juju/clear-ks-meta  its been blocking a few other branches in the queue that are approved
<bcsaller> hazmat: on it
<hazmat> bcsaller, thanks
<jimbaker> bcsaller, sounds good, we can have 3 reviews :)
 * hazmat wonders how much spam mail is for deceased folks
#juju 2011-11-10
<hazmat> wtf oracle branding solaris 11 as the first cloud os..
<hazmat> crack marketing.. cloud this, cloud that
<hazmat> cloud linux.. http://bellard.org/jslinux/ ;-)
<SpamapS> hahaha
<hazmat> g'morning
<rog> hazmat: yo
<hazmat> greetings rog
<fwereade> hazmat, should we now be marking bugs "fix committed" rather than "fix released"?
<hazmat> fwereade, good question
<fwereade> hazmat, heh :)
<hazmat> fwereade, i'm unsure.. it probably does make sense, but such usage would mean realigning milestones to releases
<fwereade> hazmat, and plausibly tweaking the kanban board
<hazmat> fwereade, i was thinking we could have a team meeting today to try and catch up post sprint and that could be a topic of discussion
<hazmat> fwereade, i'm already on that one ;-)
<fwereade> hazmat, ah, cool :)
<hazmat> fwereade, although its more just a new dyanmic readonly lp frontend for juju.. its turning out to be significantly more work than the charm browser
<fwereade> hazmat, sounds good, I can be around this evening
<fwereade> hazmat, heh :)
<hazmat> fwereade, great
<hazmat> silly pure rest api
 * niemeyer waves
<niemeyer> I've pointed out I'd be late today earlier, now I noticed I was disconnected.. duh
<hazmat> niemeyer, greetings
 * hazmat ponders puppet
<hazmat> fwereade, is 6pm local okay for you re meeting?
<fwereade> hazmat, sure
<fwereade> hazmat, you marked https://code.launchpad.net/~fwereade/juju/visible-instance-state/+merge/79215 as "needs fixing" a while ago
<fwereade> hazmat, did I address your concerns?
<hazmat> fwereade, i'll take a look again in a few, i think so.. i backed away from shared state vocabulary
 * hazmat feels like its been all email and reviews the last few days, the code itch builds
<jimbaker> hazmat, fwereade, team meeting sounds like a good idea today
 * SpamapS imagines a little code-hungry bug inside hazmat chewing on the base of his spine
<niemeyer> fwereade: Is visible-instance-state touching the format of the status output?
<bloodearnest> hey juju-istas :)
<bloodearnest>  if I wanted to poke/signal a service (e.g. force a manual reload), whats the best way to to it? config-changed and a dummy config value?
<SpamapS> bloodearnest: right now yes, though I'm thinking there needs to be a "refresh everything" command
<bloodearnest> SpamapS: kthx. I think a generic "signal" and "handle-signal" or hook (or similar) would be nice
<SpamapS> bloodearnest: custom hooks have been discussed as well
<bloodearnest> SpamapS: cool. I'll go with config-changed for now. Is there any way to get what the old config value was for a particular field?
<SpamapS> bloodearnest: no, I think there's an open bug for that
<bloodearnest> SpamapS: kthx
<hazmat> bloodearnest, if you want the old value the hook should store it
<hazmat> and diff to the new
<bloodearnest> hazmat: of course - I will do that :)
<SpamapS> https://launchpadlibrarian.net/84857743/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr413-1juju1%7Eprecise1_FAILEDTOBUILD.txt.gz
<SpamapS> looks like juju is broken on precise.. fine on oneiric and natty
<hazmat> SpamapS, it looks like a conflict between builtin argparse vs a packaged argparse
<hazmat> odd that it only shows up only those on tests, but i guess those tests stuff the python path and launch a process
<bcsaller> hazmat: they had updated some strings in the last update of argparse breaking tests as well
<jimbaker> bcsaller, doesn't look like the issue here however
<jimbaker> (simply some sort of conflict on the python-argparse package for one of our dependent packages, vs the argparse we use anyway)
<fwereade> hazmat, meeting time?
<hazmat> fwereade, indeed
<hazmat> niemeyer, jimbaker, bcsaller, SpamapS ... meeting time.. anyone else?
<niemeyer> t+10
<jimbaker> hazmat, niemeyer, sounds good
<jimbaker> rog is also waiting, and i'm sure fwereade is interested
<hazmat> invites out
<bcsaller> its giving me a little trouble connecting, trying again
<hazmat> bcsaller, sending a new invite..
<bcsaller> might be faster to just relog, the camera and so on doesn't seem to be working
<hazmat> bcsaller, it was sort of like you joined and immediately dropped
<hazmat> SpamapS, robbiew invites out to you guys as well if your interested
<hazmat> http://www.reviewboard.org/
<SpamapS> hazmat: "I'm not supposed to be here today" ;)
<SpamapS> maybe plan the next meeting more than 24 hours in advance? ;)
<bcsaller> things are in a surprisingly horrible state of decay here
<bcsaller> trying to fix
<hazmat> bcsaller, perhaps try a different browser
<bcsaller> hazmat: its far worse than that that at this point, anything with GL won't run now, so unity borked. I tried 2d, etc, its not working at all, I have an empty desktop here, but am still trying to connect again
<bcsaller> I think its crashing the googletalk plugin too though
<bcsaller> everything was fine yesterday, I so don't need this
<hazmat> bcsaller, did a reboot help? sounds like  a driver problem
<bcsaller> no, it didn't
<bcsaller> going to see if I can load an older kernel
<hazmat> SpamapS, sounds good
<niemeyer> 1) The requirement is to put things in the same container
<niemeyer> 2) We use relations so the admin doesn't need a different mental model to create slaves
<niemeyer> 3) We introduced the idea of juju-info relation so that we don't need the strange idea of promiscuous relations
<niemeyer> (copied here so I have in logs.. this is the shortest explanation I could come up with, so want to save.. ;)
<fwereade> cheers all, later
<hazmat> failure
<bcsaller> hazmat: re-invited
<hazmat> bcsaller, thanks
<niemeyer> hazmat: wtf seems to be fine, btw
 * niemeyer steps out for a while
<nuclearbob> greetings everyone, I'm trying to setup juju using the local/lxc environment, and I'm getting errors when I try to deploy a charm
<evan_> nuclearbob: what error are you getting?
<nuclearbob> evan_: if I try to deploy the wordpress charm, I get:
<nuclearbob> max@WOPR:~$ juju deploy --repository=charms wordpress
<nuclearbob> User timeout caused connection failure.
<nuclearbob> 2011-11-10 15:20:22,539 ERROR User timeout caused connection failure.
<evan_> Do you have the charms on your local machine?
<evan_> i.e. I have my charms in a directory called "lucid" so when I deploy - juju deploy --repository . local:lucid/charmname
<nuclearbob> I've got them in /home/max/charms
<nuclearbob> do I need them in oneiric/charms since I'm on oneiric?
<evan_> nuclearbob: juju deploy --repository . local:path/to/charm should work if i'm not mistaken
<nuclearbob> evan_: now I'm getting a connection refused, I may have goofed something up, I'll see if I can fix it
<evan_> nuclearbob: If the bootstrapping node has not yet completed bootstrapping it could cause this error, ok.
<nuclearbob> evan_: I wasn't getting that error before, but I just started after I had been messing with things
<nuclearbob> evan_: I can try running the bootstrap again
<nuclearbob> evan_: it says I'm already bootstrapped
<evan_> nuclearbob: what does it say when you run "juju status"
<nuclearbob> evan_: max@WOPR:~$ juju status
<nuclearbob> could not connect before timeout
<nuclearbob> 2011-11-10 15:37:42,353 ERROR could not connect before timeout
<evan_> nuclearbob: Indication the environment needs more time to complete initialization
<evan_> nuclearbob: more here https://juju.ubuntu.com/docs/user-tutorial.html
<nuclearbob> evan_: thanks, I'll take a look at that
<evan_> nuclearbob: you bet
<mpl> niemeyer: hi. sorry I couldn't show up so far, it was a crazy week. I'll probably collapse to bed soon, but starting from tomorrow I'll be a lot more available to talk.
<nuclearbob> evan_: are you still around?
<evan_> nuclearbob: yea, did you get it figured out?
<nuclearbob> eavn_: I got the latest version from the ppa, rebooted, ran juju bootstrap (it said it was already bootstrapped) and gave it about a half an hour, but it's still getting timeouts
<donspaulding> I sysadmin the servers at my company, around a dozen servers, with heterogenous hardware configs, all running various versions of ubuntu server.  What I wanted to build, before I found juju, was a tool that would orchestrate application-level services and their dependencies.  Juju seems to fit the bill nicely, except, rather than targeting EC2, or even a private cloud, I'd rather target my own bare-metal servers, with the applicat
<donspaulding> I saw where recently the ability to deploy to containers was added, I'm just wondering if there's any explicit push toward supporting that for production deployment?  The mailing list message I saw on it seemed slanted towards development/debugging usage.
<evan_> nuclearbob: hmmm I am unsure of why it would be doing that. Maybe someone else here would know
<nuclearbob> evan_: thanks for pointing me at the tutorial as well, I've got another machine to set it up on, and maybe I can avoid mistakes I might have made on this one
<evan_> nuclearbob: no problem. I am fairly new so I'm learning as well. Best of luck to you. Let me know if you figure out the problem
#juju 2011-11-11
<niemeyer> Alright good progress..
<niemeyer> But it's way past bed time.. night all
<niemeyer> Hallo!
<rog> niemeyer: hi!
<niemeyer> rog: Yo!
<rog> niemeyer: i'm considering putting (at least part of) the ec2 test server under launchpad.net/goamz/ec2/test rather than juju/ec2, because it's bound so tightly to the ec2 protocol.
<rog> does that seem reasonable?
<hazmat> g'morning
<niemeyer> rog: Yeah, depending on how generic it is
<niemeyer> rog: Sorry, missed your message earlier
<rog> hazmat: morning
<niemeyer> hazmat: morning
<rog> niemeyer: np
<mpl> niemeyer: hi. I'm around if you feel like talking about what you'd like me to start with.
<niemeyer> mpl: Hey!
<niemeyer> mpl: Cool, so..
<niemeyer> mpl: The first thing I'd recommend is getting comfortable with the concepts around the project
<niemeyer> mpl: Trying to use it in the first place, so you understand the overall idea, would be a great start
<niemeyer> mpl: Do you have an account on EC2?
<mpl> niemeyer: nope. I quickly tried locally with lxc but got some errors. some dude pointed me to some troubles he had locally as well but I haven't had time to investigate more.
<mpl> niemeyer: but maybe I can get an account. Do I need to pay if I just want an account and play with juju on it?
<niemeyer> mpl: You have, even though it's going to be quite cheap for what you'll have to do
<niemeyer> mpl: Like cents
<mpl> ok, gonna set up one then
<niemeyer> mpl: I recommend playing on EC2 rather than local, because if you're happy with it I'll try to get you involved in developing some features around the EC2 support
<niemeyer> mpl: FWIW, if it starts to get expensive because you've spending a good deal of time hacking, I'll be very happy to sponsor your costs
<mpl> bah, we're not there yet. besides, at some point I suppose I'll need an EC2 to test some camlistore stuff on there too.
<mpl> but thx, good to know.
<_mup_> Bug #889125 was filed: Initial implementation of basic ec2 functionality. <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/889125 >
<rog> niemeyer: new merge proposal for you. it relies on the previous error fixes though, so i'm not expecting an immediate look.
<niemeyer> rog: Cool
<niemeyer> rog: Still pumping through..
<niemeyer> rog: Bazaar branch diffing works, and auth works
<rog> niemeyer: nice
<niemeyer> rog: Now just need to sort the actual rietveld interaction
<niemeyer> rog: Hopefully this afternoon I can nail the whole thing down
<rog> niemeyer: you gonna branch upload.py or use the stuff from the go tree or do it from scratch?
<niemeyer> rog: Did it from scratch..
<rog> niemeyer: probably best
<niemeyer> rog: Want to integrate into lbox, so upload.py wasn't suitable
<rog> niemeyer: right
<niemeyer> rog: The patch stuff in the Go tree was interesting, but ended up being a red herring
<niemeyer> rog: So writing a rietveld library, then will glue on lbox
<rog> niemeyer: yeah, i saw your CL
<niemeyer> But lunch first! :)
<hazmat> mpl, if you have any notes from your troubles with the local provider i'd be happy to help debug it
<mpl> hazmat: I think you're the one who pointed me to your troubles you had reported. I hadn't even rebooted after I had installed lxc (which is recommended), so that may just be it. as I said, haven't had time to look more into it. but thanks anyway.
<jml> hi
<jml> I'm trying to deploy a juju formula to lxc locally, and it seems to be hanging on "Starting container..."
<jml> At the charm school at UDS, I remember being pointed to a more helpful log file
<jml> but I can't find that now
<hazmat> jml, there's a master-customize.log under the units directory in the environments.yaml specified data-dir for the local provider
<hazmat> jml, there are several log files in that directory
<jml> hazmat: thanks.
<hazmat> jml, the log for the initial lxc container modification used as a template for units is in the master-customize.log
<jml> hazmat: that file doesn't exist. have destroyed environment and trying again
<hazmat> jml, it helps to check the status of containers with lxc-ls or checking for the debootstrap in a process listing
<hazmat> jml, cool, i'll be around but running errands (national holiday in the us)
<jml> hazmat: thanks
<fwereade> happy weekends everyone :)
<jml> Oh. Hmm.
<niemeyer> fwereade: Have a great one!
<rog> fwereade: et toi!
<rog> niemeyer: william raised an interesting point in his review of the Go code that i'm conflating machines and instances, and that's probably not a good thing to do
<rog> niemeyer: what do you think?
<rog> argh, ubuntuone-syncdaemon strikes again! 5GiB real memory and rising
<mpl> rog: jsyk, the non literal and more correct translation would be "toi aussi" :)
<rog> mpl: there's always one. dammit. :-) :-)
<rog> mpl: i did know that once, honest.
<mpl> I don't doubt it. just pointing it out because I'm not sure you could get away with "et toi" while speaking.
<rog> mpl: but thanks for letting me know.
<mpl> np
<rog> mpl: and if i was using 3rd person? is "et vous" incorrect too?
<mpl> yep. just go with "vous aussi" or "vous de mÃªme" if you want to be fancy.
<rog> lovely.
<mpl> heh, the amazon automatic call lady voice sounds a bit like glados :)
<jml> :(
<jml> OK So, no master-customize.log exists; debug-log says "starting container", no debootstrap in process list
<mpl> in my environments file, should I change "default-series: oneiric" if I'm using lucid lynx ?
<jml> blew away all my lxc environs, the juju data dir, killed relevant twistd & zookeeper processes -- seems to be working now, at least I have a master-customize.log
<jml> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python-crypto/python-crypto_2.3-2_amd64.deb  Hash Sum mismatch
<hazmat> jml, destroy-environment is a safe reset, you shouldn't ever have to kill processes by hand, unless you below away the data-dir beforehand
<jml> hazmat: it was giving me errors about "address already in use"
<hazmat> jml, in general using destroy-environment is the best way to clean state/kill processes, it sounds like you had a process around from a previous attempt
<hazmat> jml, so what do you see know from lxc-ls ?
<hazmat> or juju status
<jml> hazmat: ... a previous attempt where destroy-environment didn't do what it says on the tin
<jml> machines:
<jml>   0: {dns-name: localhost, instance-id: local}
<jml> services:
<jml>   etherpad-lite:
<jml>     charm: local:oneiric/etherpad-lite-7
<jml>     relations: {}
<jml>     units:
<jml>       etherpad-lite/0:
<jml>         machine: 0
<jml>         public-address: null
<jml>         relations: {}
<jml>         state: null
<jml> 2011-11-11 18:24:04,680 INFO 'status' command finished successfully
<jml> jml-local-0-template  jml-local-etherpad-lite-0
<hazmat> jml do you see any files in data-dir/user-env/units/etherpad-lite ?
<jml> hazmat: container.log and a broken symlink to unit.log
<mpl> so juju boostrap says "SSH authorized/public key not found.", because I followed the getting started guide and entered my access key and secret key. is the guide deprecated on that aspect?
<hazmat> jml hmm.. so the unit agent never started if the symlink is broken, could you paste the master-customize.log
<hazmat> hmm
<jml> http://paste.ubuntu.com/735521/
<jml> hazmat: ^ the master-customize.log.
<hazmat> mpl, the ssh key isn't about the aws keys or usage, juju is looking for a public key on your machine to setup for ssh on all launched machines, it looks for some defaults (id_dsa.pub, etc).. you can specify one directly with authorized-keys-path in your environments.yaml under the provider block
<jml> I've blown away the python-crypto deb in apt-cacher-ng
<mpl> hazmat: thx. I haven't seen that in the getting started guide. does it come later?
<jml> and now I'm going to tear down in this clean & safe way that doesn't involve manual process killing
<hazmat> mpl, its described in the provider docs, but this should probably be a FAQ entry
<jml> http://paste.ubuntu.com/735524/
<jml> and look, juju processes still around: http://paste.ubuntu.com/735525/
<hazmat> hmm
<hazmat> jml, indeed.. lxc hanging on a shutdown command was unexpected
<hazmat> that needs some reordering then
<hazmat> so it looks like that would mean there is another lxc-wait operation being done concurrently
<hazmat> jml, could you paste a ps aux | grep lxc
<jml> hazmat: nothing comes up, but I'd already manually killed the processes in http://paste.ubuntu.com/735525/
<mpl> hazmat: that did it, thx. now to wait for the machine to be initialized I suppose...
<hazmat> jml, one last thing that might have useful information.. could you paste the unit's container.log
<jml> will do.
<jml> note that this is from a run where I have resolved the python-crypto hash mismatch problem
<jml> (there's now a different problem)
<jml> http://paste.ubuntu.com/735534/
<jml> http://paste.ubuntu.com/735536/ <- master-customize.log from that run
<jml> http://paste.ubuntu.com/735537/ <- debug log from that run
<hazmat> jml, thanks
<hazmat> jml, same question re process grep on lxc if its still in the same state. the lxc address error is from another lxc process binding to the address
<jml> http://paste.ubuntu.com/735545/
<hazmat> jml, this should get a bug report
<hazmat> i'm not sure the code does a very good job assuming serial use of the lxc api
<hazmat> at least not across processes
<jml> hazmat: I suspect you'd be able to file a more useful bug report than I.
<hazmat> jml, sounds good
<jml> And besides, my direct problem is that I can't get an LXC instance deployed. Dodgy cleanup when I fail to do so is second-tier :)
<jml> Although maybe this is the language thing.
<jml> crap. I need to pack.
<hazmat> it still doesn't really answer the problem in this case, which is why the container isn't up, it might be the error comes when we try to check the status and something else is still listening to hte status, jml thanks cheers
<hazmat> i'll have a look at it some more next week
<jml> hazmat: thanks :)
<rog> right, i'm off for the weekend. see y'all monday.
<niemeyer> rog: Have a good one rog
<niemeyer> I'll head outside for a while too..
<_mup_> juju/robust-zk-connect r414 committed by jim.baker@canonical.com
<_mup_> Initial version
#juju 2011-11-12
<jimbaker`> seems to me that it would be nice if we had verbosity levels for --verbose, especially an easy way to screen out ZK logging which is seldom useful
<lamalex> hi, im trying to figure out how to deploy wordpress, where are the docs for all of the initial set up? i see lots of stuff about ec2 but i dont have any ec instances i just want to hack locally on some stuff
<drt24> lamalex: you might try http://blog.dustinkirkland.com/2011/08/formal-introduction-to-ubuntu-orchestra.html
<drt24> which has been sitting in my to read pile for a couple of weeks now
<lamalex> that doesn't really seem helpful at all actually haha. it's just an introduction to the idea of orchestra
<lamalex> how how to use juju
<lamalex> so i managed to deploy a wordpress and mysql charm
<lamalex> and added a relation between them
<lamalex> but nothing is starte
<lamalex> mysql isn't running
<lamalex> .... because it didnt install anything
<lamalex> am i missing something? like a core point of what juju does?
<niemeyer> lamalex: Hmm..
<niemeyer> lamalex: I can try to help you.. it's been an hour, so have you evolved anyhow?
<lamalex> niemeyer, i gave up, installed cherokee and just used their webstore, i dont really care anymore i just want to get my work done
<niemeyer> lamalex: Sounds good, sorry it's been more painful than it should have been
<niemeyer> lamalex: Hadn't heard of cherokee before.. it looks very neat
<lamalex> yah it's also a great webserver
<jcastro> SpamapS: around?
<jcastro> EvilBill: ok we'll try here
<EvilBill> yo.
<jcastro> and if I totally fail you we can mail the mailing list
<EvilBill> lol
<EvilBill> Dude, I have a long time to figure this out
<EvilBill> I'm just mucking around
<jcastro> since I think you're the first victim outside of clint who is trying this
<EvilBill> Juju makes a lot of sense to try at the new gig
<EvilBill> cause they want a private cloud, and a public cloud
<EvilBill> I'm looking for one set of tools to bind them all, y'know?
<jcastro> yeah
<jcastro> it's just you picked the time when we don't really have docs for OpenStack/Ubuntu/Juju
<jcastro> though, it'll just force us to fix it
<EvilBill> Picked the time, lol
<EvilBill> I'm just trying to hit the ground running at the new gig
<jcastro> "Well, I was just fine until you told me to use this, and you don't even have docs."
<EvilBill> pretty much
<jcastro> It's ok, we'll sort you eventually
<EvilBill> but this isn't the first time I've been in this boat with something you've been all OMG THIS IS SO SHINY ABOUT
<jcastro> what's the state of the instance now?
<jcastro> hey man, early bird gets the worm
<EvilBill> 2011-11-12 15:40:57,610 INFO Waiting for unit to come up.
<jcastro> he just has to do all the digging on his own
<EvilBill> it's seriously never going to come up.
<EvilBill> unit mysql/0 says its deploying on machine 1
<EvilBill> but there is no machine 1
<EvilBill> there never will be machine 1
<EvilBill> unless I drag another laptop out and provision it.
<EvilBill> and I'm out of space on my desk lol
<jcastro> put your notes on pastebin somewhere
<jcastro> like, what you did
<EvilBill> ugh.
<EvilBill> ok
<EvilBill> only reason I ugh, is I was constantly interrupted
<EvilBill> so I may have missed a step of documenting, but we'll run with it.
<jcastro> that's ok
<jcastro> it's better than nothing
<EvilBill> working on that now, cleaning up some nonsense
 * jcastro nods
<EvilBill> OK man
<EvilBill> http://pastebin.ubuntu.com/736784/
<EvilBill> sorry, had my son bug me in the middle of that.
#juju 2011-11-13
<EvilBill> jcastro: ping
<jcastro> EvilBill: hi
<jcastro> ok I'm lost
<EvilBill> awesome.
<jcastro> EvilBill: I think you should post this to the list
<EvilBill> ok.
<EvilBill> you say "the list" like I have a clue what you're talking about :P
<jcastro> yep, one sec
<jcastro> https://lists.ubuntu.com/mailman/listinfo/juju
<EvilBill> k, thx for the help, jcastro
<jcastro> EvilBill: they watch that list pretty good, you'll get help in no time
<jcastro> and btw I'll be ripping off your notes extensively. :)
<mcclurmc> I've heard that there is an OpenStack service provider in the works, but I can't seem to find the code. Is it public yet? Can anyone point me to it?
<EvilBill> jcastro: you around?
#juju 2013-11-04
<stokachu> did the latest juju release fix the local ssh problems?
<davecheney> stokachu: it shuld have
<davecheney> what problem are you having ?
<stokachu> Permission denied (publickey,password).
<stokachu> ERROR exit status 255
<stokachu> this was from a bootstrap, then juju deploy wordpress
<stokachu> using juju debug-log
<stokachu> ive also started seeing agent-state-info: 'hook failed: "install"'
<stokachu> with the latest juju-core
<davecheney> stokachu: what was the command you typed ?
<stokachu> davecheney: sudo juju debug-log
<stokachu> and sudo juju deploy wordpress
<davecheney> stokachu: you don't need to use sudo
<davecheney> for the local povider you need to sudo *ONLY* for juju bootstrap and juju destroy-environment
<davecheney> this should be clearly marked in the documentation
<davecheney> if it is not
<davecheney> please let me know and I will raise an issue
<davecheney> i believe debug-log does not work on the local provider
<davecheney> but the logs are in ~/.juju/local/something/seomting
<davecheney> we loopback mount them there
<stokachu> re-running with just juju deploy wordpress
<stokachu> davecheney: http://paste.ubuntu.com/6356219/
<stokachu> ran with `sudo juju bootstrap --upload-tools; juju deploy wordpress`
<rick_h_> stokachu: yea, that's the bug I hit, that's not really a bug.
<davecheney> stokachu: le sigh
<rick_h_> #1247299
<_mup_> Bug #1247299: apparmor blocks cgroup-lite from mounting <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
<stokachu> ah
<davecheney> rick_h_: is this the thing that slipped into 12.04.3 while we were in SF ?
<rick_h_> stokachu: I hit that because I was installing build-essentials in my install hook, which grabs cgroups and that fails in lxc
<rick_h_> davecheney: not sure when this hit. I've just started working on my own personal charm and hit that bug this weekend
<stokachu> rick_h_: i guess wordpress does something similar i havent looked
<rick_h_> but it's marked invalid since it's got a lxc workaround
<rick_h_> davecheney: however, I'd say it's a bug against the juju lxc approach then perhaps?
<rick_h_> davecheney: I was going to bring it up on Monday when more folks were around
<stokachu> http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03673.html
<davecheney> rick_h_: it is monday ...
<rick_h_> I know it's not everyone's approach, but I like to do my python stuff in a virtualenv and need build tools and -dev packages to be able to pip install some things into it
<stokachu> thats what i used
<rick_h_> davecheney: not here :P
<stokachu> i ran into this when using vagrant-lxc and maas
<stokachu> had to create a separate aa profile
<rick_h_> stokachu: right, you turned off apparmor
<davecheney> app armour has done more to improve the security of linux by scaring people away than any other 'security technology'
<rick_h_> I think juju should work with our setup ootb better
<stokachu> i didnt turn it off
<davecheney> rick_h_: i agree
<davecheney> and it did right til last week
<rick_h_> stokachu: sorry, I thought you did what this therad mentions > Alternatively, you could set "lxc.aa_profile = unconfined" which would
<stokachu> i added "mount -> /tmp/*/*," to /etc/apparmor.d/lxc/lxc-default-with-loops
<rick_h_> > turn off apparmor entirely for the container.
<rick_h_> stokachu: ah, ok. Sorry, missed which approach you took.
<stokachu> :)
<stokachu> i initially turned it off but decided against it
<rick_h_> davecheney: so yea, suggestions on how best to move the bug from lxc to juju appreciated. I'm not really sure how/who best to bring up the point.
<davecheney> rick_h_: thumper is around
<rick_h_> but I was :( when I hit roadblocks trying to charm my own stuff this weekend
<davecheney> he wrote the local provider
<rick_h_> oooh, I like bugging thumper :)
<davecheney> and I thought that he knew about this bug
 * thumper isn't round
<thumper> been exercising and everything
<rick_h_> and can blame all things on him wahoo!
<stokachu> lol
<rick_h_> thumper: I'd like my stuff to work kthx :P
 * davecheney hands thumper his rimshot
<rick_h_> thumper: #1247299 is biting a bunch of us and lxc says it's not their problem. How do we make it juju lxc's problem?
<_mup_> Bug #1247299: apparmor blocks cgroup-lite from mounting <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
 * thumper looks
<stokachu> my problem showed up when trying to mount ephermeral images from /tmp
<rick_h_> thumper: and mine from trying to install build-essentials
<thumper> ugh
<stokachu> i just want to deploy joomla :(
<stokachu> lol
<rick_h_> stokachu: we've got to start boxing up a cake to send to thumper :)
 * thumper doesn't want a cake
<thumper> but I'll accept a 24kg kettle bell
<rick_h_> lol
<stokachu> rick_h_: hah my girl can make gluten free cakes
<thumper> rick_h_: so installing build-essential triggers this problem
<thumper> ?
<rick_h_> thumper: yea, did for me
<rick_h_> thumper: and moving to aws caused no issues
<thumper> stokachu, rick_h_: can I get you both to comment on the bug with issues and reproducability?
<thumper> I'll put it on my short term todo list
<stokachu> sure
<thumper> ta
<rick_h_> thumper: sure thing
<stokachu> thumper: ok updated, thanks :)
<thumper> sp
<thumper> np
<thumper> marcoceppi: what do I need to run to create the framework of a charm?
<thumper> marcoceppi: I want to make a charm that installs build-essential and compiles hello_world.cpp
<thumper> and logs the output
<marcoceppi> thumper: install charm-tools from ppa:juju/stable then run `juju charm create <name-of-charm>`
<rick_h_> thumper: working on pushing up my demo charm and getting a log copy for the bug
<thumper> marcoceppi: ta
<thumper> marcoceppi: why are you working sunday night?
<marcoceppi> stokachu: juju debug-log and juju ssh <machine-#> still do not work for local provider. You can find the logs in ~/.juju/local/log and you can ssh with juju ssh <unit>
<marcoceppi> thumper: because the charm queue is still backed up
<thumper> those are more things on my todo list...
<marcoceppi> it keeps me up at night in the fetal position
<stokachu> marcoceppi: ok thanks that was my other problem
<marcoceppi> stokachu: np!
<marcoceppi> we really /really/ should document that in the docs
 * marcoceppi creates a task
<stokachu> marcoceppi: ah sweet, juju ssh wordpress/0 works
<stokachu> that at least unblocks me for the time being
<marcoceppi> stokachu: yeah, you can still do everything like the other providers, just have to do it in a slightly different way
<marcoceppi> local provider is special ;)
<stokachu> lol cool man
<stokachu> so with cgroup's do we need to add a profile to allow `mount -> /sys/fs/cgroup/*`
<rick_h_> thumper: bug updated with comment, link to the charm, and the unit log showing the error
<thumper> rick_h_: ta
<davecheney> https://github.com/davecheney/charms/tree/master/raring/docker
<davecheney> ^ docker charm, awesome, or heresy ?
<marcoceppi> davecheney: awesome heresy!
<davecheney> (Y/Y) !
<rick_h_> I don't know. I need to look up docker again. I don't get it, I thought it was just a pretty api around lxc. Everyone is going more gagga so I must have missed something
<davecheney> marcoceppi: seriusly, the docker install process is a piece of shit
<davecheney> curl some brogramming thing
<davecheney> add some packages
<rick_h_> lol
<davecheney> recompile your modules
<davecheney> etc
<marcoceppi> davecheney: oh, you mean just like rvm and every other cool package out there?
<davecheney> so I made it into a charm
<marcoceppi> curl pipe to bash as root! What could do wrong?
<davecheney> FFFFFFFFFFFFFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUU cached charm!
<rick_h_> davecheney: yea, doing local charm dev needs a --no-cachy-cachy option
<marcoceppi> davecheney: your charm lacks configuration and hooks. Also please don't make charmers the maintiner
<stokachu> so i think the lxc issue has to be solved within the lxc-ubuntu-cloud template along with apparmor
<marcoceppi> rick_h_ davecheney -u flag should do the trick?
<rick_h_> marcoceppi: yea, but then I do a diff and see my revision went from 2 to 10
<rick_h_> and before merging go back and change it to 3
<stokachu> where the lxc-ubuntu-cloud template sets a aa_profile customize directive for an apparmor profile we'd write
<marcoceppi> rick_h_: echo "revision" >> .bzrignore
<marcoceppi> nobody cares about that file anymore
<davecheney> rick_h_: to be fair, i should be yusing --upgrade-charm
<rick_h_> marcoceppi: I thought that was the point of -u, to auto increment that
<davecheney> but it didn't make sense in this instance
<davecheney> marcoceppi: i forgot that as well
<rick_h_> marcoceppi: I guess it doesn't make sense that it would work withuot the file since there's nothing to mark upgraded?
<marcoceppi> rick_h_: it is, but it only matters for local deployments. Everything else doesn't care about revision
<marcoceppi> rick_h_: if you delete the file juju deploy will just create it again
<rick_h_> marcoceppi: right, so to work on the charm you need that file to exist to dev on it.
<rick_h_> marcoceppi: ah, didn't realize that
<marcoceppi> rick_h_: right, but as you may well know, outside of local dev, the revision file gets changed dynamically by the store
<marcoceppi> I <3 the store sooo much
<davecheney>  % juju ssh docker/0 -- sudo docker run -i -t ubuntu /bin/bash
<davecheney> ^ is this to meta ?
<davecheney> marcoceppi: please lets not talk about cs revisions
<rick_h_> marcoceppi: also wanted to bug you about charm helpers sometime. I tried to use them this weekend. I noticed that in the juju-gui charm we've got a charmhelpers.py to use, but it's a ton larger now and has a bunch of files that are crazy (juju-gui file?) with their own deps/etc.
<davecheney> it's only monday
<davecheney> i don't need to cry on monday
<rick_h_> lol
<marcoceppi> davecheney: eh, it could work. I saw someone's charm actually allowed you to send a docker config file via config-changed
<rick_h_> marcoceppi: I ended up giving up and just doing shell vs trying to get the helpers into the charm
<marcoceppi> davecheney: it's still sunday here, I'm already crying ;)
<marcoceppi> rick_h_: yeah, I have plans to reign in charm-helpers. Documenting what it does is first on my list, packaging is a close second
<marcoceppi> rick_h_: there's a charm school video on it if you want to watch how it works for an hour
<rick_h_> marcoceppi: k, I wasn't sure how that workd work. The install hook would need to do the install and you couldn't use it there then?
<marcoceppi> rick_h_: well, currently charm-helpers is embedded in the charm
<marcoceppi> rick_h_: so it would already be available
<marcoceppi> if you're using lp:charm-helpers
<rick_h_> marcoceppi: ok, so the current *correct* way is to download and embed it then? Keeping it up to date via?
<marcoceppi> rick_h_: there's an update tool
<rick_h_> marcoceppi: yea, I figured embedding was easy when it was a single file, but it has no upgrade path and such then
<marcoceppi> rick_h_: you basically create a .charm-helpers file and there's an executable you can run when you want to sync stuff
<rick_h_> marcoceppi: oh, must have missed that when going through the code
<marcoceppi> It was born out of a need to keep remote deps down for IS. But now that the library is more mature it's time to properly package it in a ppa
<marcoceppi> so people don't have to do this
<marcoceppi> with a goal to get it in to the archive
<rick_h_> cool, well I wanted to try it out this weekend. Heh, between that and the cgroups issue spent a couple of hours working on the charm and managed to get one config value in and working
<rick_h_> wheeee
<marcoceppi> woo who!
<marcoceppi> rick_h_: http://www.youtube.com/watch?v=6kWfLujVwNI
<marcoceppi> some light video watching for you ;)
<rick_h_> marcoceppi: yea, I thought I was cool trying to go through the source code and looking at the gui charm since I knew it used it. :P
<davecheney> marcoceppi: I wonder if I could make something like juju-docker plugin that would pipe the Dockerfile to your docker/0 unit ?
<marcoceppi> davecheney: subordinate would be cool too
<marcoceppi> davecheney: s/would be cool/might be another way to do that as well, I don't know though/
<marcoceppi> I should probably just go use docker and get an idea for it
<marcoceppi> It seems cool, but I don't see what it solves that vagrant doesn't already do
<marcoceppi> jamespage: adam_g: Do you guys want eyes on your openstack charm in the queue? I know we've typically left those up to your review but I'd be happy to move it along
<davecheney> marcoceppi: simplest explaiantion of docker
<davecheney> checking your container into git
<davecheney> want to move your containre to a new provider
<davecheney> just check it out over there
<jam> morning all
<jam> hey wallyworld_, sorry I'm late, still want to chat?
<wallyworld_> jam: hi, just got back from getting kid from school, he was meant to have cricket training but it got called off so i got a phone call to go get him. we can talk now if you want
<jam> wallyworld_: sure, I'm there now
<nesoi1> Hello, I just went through the juju demo, installing wordpress and mysql on an Amazon EC2 instance. There were no error messages, but when I go to that URL I get 502 Bad Gateway
<nesoi1> anyone here have an idea of what I should do to correct this?
<nesoi1> ah, it was just a delay
<nesoi1> nevermind
<ahasenack> hm, I have juju-core 1.16.2
<ahasenack> yet bootstrap is *uploading* 1.17.0.1 tools
<ahasenack> andreas@nsn7:~$ juju version
<ahasenack> 1.17.0-raring-amd64
<ahasenack> but
<ahasenack> andreas@nsn7:~$ juju bootstrap -v --constraints mem=1500M
<ahasenack> verbose is deprecated with the current meaning, use show-log
<ahasenack> 2013-11-04 12:24:12 INFO juju.provider.openstack provider.go:127 opening environment "canonistack2"
<ahasenack> 2013-11-04 12:24:15 INFO juju.environs.tools tools.go:85 reading tools with major.minor version 1.17
<ahasenack> ...
<ahasenack> oh, wait
<ahasenack> juju-core	1.16.2-0ubuntu1~ubuntu13.04.1~juju1
<ahasenack> so the package is 1.16.2, but it calls itself internalle 1.17.0?
<ahasenack> and there are no 1.17.0 tools in this cloud I suppose
<ahasenack> oh, never mind, my mistake
<marcoceppi> ahasenack: it should attempt to bootstrap with the same client minor version
<ahasenack> marcoceppi: it's my mistake, I had another "juju" binary in the PATH :(
<marcoceppi> ahasenack: ah
<sidnei> marcoceppi: https://code.launchpad.net/~sidnei/charms/precise/haproxy/restore-services-from-relation/+merge/193773 sorry, the branch you merged had broken tests. i should have set it to 'work in progress'. also, probably good practice to run the tests before merging for those that have it now.
<marcoceppi> sidnei: I typically do, didn't realize this has tests
<marcoceppi> sidnei: let me roll back
<sidnei> marcoceppi: wait, no
<marcoceppi> sidnei: wait, tests pass
<sidnei> marcoceppi: this is a follow up mp that fixes the tests
<sidnei> marcoceppi: indeed, my bad. the uncommitted fix in my local branch broke the tests, i thought i had pushed it.
<marcoceppi> sidnei: do you want me to roll back or not?
<sidnei> marcoceppi: anyway, the previous fix was incomplete. please merge this additional mp
<sidnei> it was tested by ahasenack
<marcoceppi> sidnei: merged
<sidnei> marcoceppi: thanks
<mthaddon> anyone able to help troubleshoot an env that says it's bootstrapped and not bootstrapped at the same time? http://paste.ubuntu.com/6358869/
<marcoceppi> mthaddon: if you ran juju bootstrap, and the instance didn't fire up, or went away, there's an "is_bootstrapped" file in the object store that tells juju that it's bootstrapped
<marcoceppi> mthaddon: juju destroy-environment to clean that file up, then you can bootstrap again
<mthaddon> marcoceppi: is there a bug about this do you know? this is pretty troublesome for mojo
<marcoceppi> mthaddon: not that I know of
 * marcoceppi looks
<mthaddon> ah, the bootstrap node is in ERROR state
<marcoceppi> mthaddon: https://bugs.launchpad.net/juju-core/+bug/1212177
<_mup_> Bug #1212177: bootstrap detection stops too early <bootstrap> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1212177>
<mthaddon> thx muchly
<jcastro> bcsaller, did you end up getting the bundles working?
<jcastro> with quickstart?
<Azendale> marcoceppi: should the execution_environment() function in the charm helpers be valid to call when you are in an install hook?
<marcoceppi> Azendale: which charm helpers?
<Azendale> marcoceppi: I'm looking at the one in etherpad-lite. How can I know/find the version?
<marcoceppi> Azendale: there's a charm-helpers1 and charm-helpers2. If there's a folder called "charmhelpers" that's embeded in the charm it's charm-helpers 2
<Azendale> marcoceppi: ok, then, it's charm-helpers2
<marcoceppi> execution_environment seems valid enough
<marcoceppi> the relation_ commands would be problematic
<marcoceppi> should probably be wrapped in a try: block for those specific relation calls and set to either False or an empty array
<marcoceppi> actually
<marcoceppi> these all look safe
<marcoceppi> each relation method seems to do the right thing
<Azendale> relation_get() is the one that is failing in the install hook
<marcoceppi> relation_get should return None based on the code
<marcoceppi> the try block catches ValueError to make it none
<marcoceppi> Azendale: what error is being raised?
<Azendale> marcoceppi: Not ValueError. Let me look
<Azendale> marcoceppi: it raises CalledProcessError
<marcoceppi> Azendale: could you show me the output again?
<Azendale> https://bugs.launchpad.net/charms/+bug/1247636 has a copy of it
<_mup_> Bug #1247636: etherpad-lite fails to deploy, install hook running get-relation <Juju Charms Collection:New> <https://launchpad.net/bugs/1247636>
<marcoceppi> Azendale: hum, maybe the catch should be updated to catch subprocess.CalledProcessError
<marcoceppi> ah yes, I thought this looked familiar
<marcoceppi> Azendale: you brought this up earlier (or someone did)
<Azendale> marcoceppi: yes, I did
<marcoceppi> oh, there's our conversation!
<Azendale> marcoceppi: yep. I got a chance to get back to this this morning
<marcoceppi> I'm torn as for what the solution should be.
<marcoceppi> I think there needs to be a try block in the execution_environment method
<marcoceppi> I still think it erroring out at relation_get because no JUJU_REALTION_ID is provided is valid
<Azendale> marcoceppi: So, it looks like execution_environment() is intended to get all the valid information it can about the environment. Maybe make it check?
<marcoceppi> Azendale: yeah, it should try for the relation_get call and set the value to None during exception
<kentb> hey all, I just hit this exact same problem on juju running saucy...after starting up dbus manually and a ton of headache, I can get the charm to deploy.  Is there anything I need to be doing differently with the saucy bits?
<kentb> http://askubuntu.com/questions/364714/juju-deploy-of-charm-mysql-in-maas-provider-failing-after-successful-bootstrap
<marcoceppi> jcastro: mmm, check this out http://rtomayko.github.io/ronn/ronn.1.html
<jcastro> WHAT.
<marcoceppi> wish it wasn't a ruby gem. I want to use this with charm tools, so you can juju charm info <charm> and get a man page output from the readme
<marcoceppi> maybe I'll make like Ronn as a Service or something
<jcastro> heh
<Azendale> marcoceppi: Is there somewhere I should be branching charm-helpers2 from? I think I found a pretty good fix to the problem it was having with running get-relation in an install hook
<marcoceppi> Azendale: lp:charm-helpers
<Azendale> marcoceppi: I branched the charm helpers, but it looks like there is a change in the latest one that looks a lot like my change -- so I think a new version of the charm helpers might just fix the problem all together. What's the process for update the version of charm helpers a charm uses? (or is there somewhere to read about this?)
<marcoceppi> Azendale: there's a charm-helpers-sync tool, it's in http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/tools/charm_helpers_sync/README
<marcoceppi> it'll allow you to update the latest version of charm-helpers in the charm
<marcoceppi> then test, bzr commit, push to a branch and propose for merging
<Azendale> marcoceppi: ok, thanks :)
<bic2k> oi, I'm sure I'm missing something simple, but I `juju upgrade-juju` from 1.14 to 1.16.2 and now all my agents are down... lol
<marcoceppi> bic2k: how long ago did you start the upgrade?
<marcoceppi> bic2k: it can take some time to get everything settled again
<bic2k> marcoceppi: more than an hour
<marcoceppi> bic2k: try sshing in to one of your nodes
<bic2k> marcoceppi: syslog shows it cannot connect to the API locally?
<bic2k> marcoceppi: I can SSH in to various nodes still, including machine-0
<marcoceppi> bic2k: right, the nodes are up, are the agents all running?
<bic2k> marcoceppi: looks like jujud is running on the nodes still, still using 1.14 from the looks of it
<marcoceppi> that's probably why they're all reporting down
<marcoceppi> bic2k: has machine 0 been upgraded to 1.16.2?
<bic2k> marcoceppi: it has the updated jujus in /var/lib/juju/tools but is still running 1.16.2
<marcoceppi> davecheney: who should I bug on core about upgrade-juju
<bic2k> marcoceppi: I mean it is still running 1.14.1
<marcoceppi> bic2k: do the other nodes have 1.16.2 agents in /var/lib/juju/tools?
<marcoceppi> this might be a real simple update the init scripts by hand if so
<marcoceppi> but I'd like to collect logs from you if that's the case
<bic2k> marcoceppi: sure, just tell me what logs you want and I'll get them filled on a bug for you.
<bic2k> 1.16.2 is on all nodes/machines
<marcoceppi> bic2k: /var/log/juju/machine-*.log if you could pastebin that for me, I'd like to look at one of them
<bic2k> marcoceppi: I PM'ed the log
<bic2k> marcoceppi: lots of errors up top
<bic2k> I'll get the machine-0 log as well
<bic2k> I suspect there are some interesting points in there as well
<marcoceppi> yeah it looks like it did the right thing, but then failed to connect to the API
<marcoceppi> bic2k: can you pastebin one of the juju*machine* init files in /etc/init/ on a node?
<bic2k> marcoceppi: coming right up
 * marcoceppi rolls the wheel of ping
<marcoceppi> bah, everyone is eod. thumper thoughts?
<bic2k> actually, this one is safe for public anyways: http://pastebin.com/qEKMk3hK
<marcoceppi> bic2k: what does /var/lib/juju/tools/machine-2/jujud point to? 1.16.2 or 1.14.0 ?
<bic2k> marcoceppi: machine-2 directory is symlinked to the 1.14.1 and unit-xxxxx-0 points to 1.16.2
<marcoceppi> bic2k: yeah, outside of stabbing in the dark, I'm not sure where to go. Could you open a bug about this against juju-core with the logs you sent me (seems you've already stripped sensative information) as well as a tree of /var/lib/juju/tools
<bic2k> marcoceppi: sure, any ideas on what to do in the meantime?
<bic2k> marcoceppi: kinda deadlocked on management right now
<marcoceppi> bic2k: I can only think of things to poke and try
<marcoceppi> I dont' want to dig too deep in to the "oh lets try this crack idea" on a "production" environment
<marcoceppi> it'll make it hard to step out what I did.
<marcoceppi> I'm not even sure if you could revert back to 1.14.2 - I was going ot say you could update the sym link on boostrap to point to 1.14 but with schema changes in mongodb I dont' think that'll work sanely
<bic2k> marcoceppi: hmm, I feel like if I could fix that API connect error on machine-0 things would work themselves out... just not sure how to manage that service on that machine. Doesn't appear as a proper upstart job
<marcoceppi> bic2k: oh, it totally shouuld be
<marcoceppi> bic2k: there should be two upstart jobs, juju-db and juju-something-or-another
<bic2k> marcoceppi: oh weird, `service jujus-machine-0 status` works now
<marcoceppi> bic2k: maybe it was still in the process of churning over?
<marcoceppi> bic2k: is your bootstrap a micro?
<bic2k> marcoceppi: still on 1.14.1
<marcoceppi> bleh
<bic2k> marcoceppi: smalls
<marcoceppi> bic2k: so jujud-machine-0 is still running on 1.14.1?
<bic2k> marcoceppi: yup
<marcoceppi> :\
<bic2k> marcoceppi: logs show that it told the nodes to upgrade
<bic2k> marcoceppi: and it has a 1.16.2 in tools, so it staged the update... just didn't pull the trigger
<marcoceppi> bic2k: so, try running juju upgrade-juju again...
<marcoceppi> curious what that will do
<bic2k> marcoceppi: sure, let me finish filing this bug report and capturing some more logs first
<marcoceppi> bic2k: awesome, thanks for your patience
<bic2k> marcoceppi: thanks for walking me through this :-)
<bic2k> marcoceppi: filed, https://bugs.launchpad.net/juju-core/+bug/1247993
<_mup_> Bug #1247993: upgrade 1.14.1 to 1.16.2 leaves machine agents not upgraded <juju-core:New> <https://launchpad.net/bugs/1247993>
<bic2k> marcoceppi: rerun of juju upgrade-juju with verbose shows it has no upgrades
<bic2k> marcoceppi: will wait a few minutes to see if it triggered anything
<marcoceppi> bic2k: any progress?
<bic2k> marcoceppi: na, it things it is already upgraded from the looks of it
 * bic2k "thinks" not things... damn happy fingers
<marcoceppi> gotchya
<zradmin> is jcastro on? I think i may have found the issue with the quantum-gateway charm. It gave me a debug message about not understanding the shared-db-relation-changed hook and then it never writes any of the credentials to the nuetron.conf file
<bjf> when i do "juju bootstrap" why is one of my maas nodes allocated to me? what does juju bootstrap do?
<marcoceppi> bjf: bootstrap creates a node in your cloud environment that does all the orchestration
<marcoceppi> it's how juju is asyncronous. So when you type juju deploy, you queue that event on the bootstrap node and it does it when ready
<bjf> marcoceppi, is it unreasonable to use the maas server for juju orchestration?
<bjf> marcoceppi, and should that node have been started up and running ?
<marcoceppi> bjf: no. Juju can use maas as well as lxc, aws, hp cloud (openstack) and others
<marcoceppi> yes, it should have
<bjf> marcoceppi, ok, thanks, i'll go see what's up with that
#juju 2013-11-05
<thumper> marcoceppi: was at the gym, reading scrollback
<thumper> marcoceppi: FWIW, fixing upgrade is on my todo list
<freeflying> do we have some thing similar to achieve maas-name constraints now in latest go juju
<nesusvet> Hello everyone! Can I install the juju agent locally in maas environment? in Ñase if I am using the remote installed agents on another hosts?
<sarnold> nesusvet: I think so? can you describe a bit more what you're trying to accomplish? (I'm no expert, but I am awake :)
<nesusvet> I installed maas environment  and can see remote machines via juju status. Now, I want to write own charm on the local machine (on which installed maas controller). I wish to see this local machine in the juju status also.
<nesusvet> Another reason is that I don't want to use local environment, because I want to deploy on the maas controller another applications
<mthaddon> anyone able to take a look at https://bugs.launchpad.net/charms/+source/swift-proxy/+bug/1238660 and let us know if we're missing something obvious?
<_mup_> Bug #1238660: Default installation fails <swift-proxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1238660>
<kentb> Would this be considered a maas, juju, or saucy problem?  I hit this with every service I tried to deploy through maas yesterday.  Juju was at 1.16.0 version:  http://askubuntu.com/questions/364714/juju-deploy-of-charm-mysql-in-maas-provider-failing-after-successful-bootstrap
<kentb> everything (for this experiment) was using 13.10 as underlying OS, including deployed nodes.
<sinzui> bac, jcsackett, do I dare to merge Abel's heartbeat additions to charmworld? Do we want to freeze charmworld while we learn why staging had 40 review.py procs running?
<bac> sinzui: i haven't seen abel's changes but i'd guess they are innocuous-ish
<sinzui> bac, just changes to the health checks and the heartbeat page. They don't relate to ingestion, storage, or search
<Azendale> jcastro: Was it you I was talking to last week about charm caching (when trying to test version of a charm with a bug fixed)?
<jcastro> yeah
<jcastro> did it work?
<jcastro> Azendale, oh also
<jcastro> something I totally forgot
<jcastro> you can try tacking a -u to a deploy command
<jcastro> to force it to increment the revision
<Azendale> jcastro: ah, ok
<Azendale> jcastro: I did get it to deploy a new version. I just need to do some testing to see exactly what part of what I did was the deciding factor. I did notice that there is an archive of the charm stored when you are using the LXC provider in .juju/name_of_env/storage, which I removed
<jcastro> interesting
<jcastro> maybe we should put that in the troubleshooting docs
<marcoceppi> jcastro: we should really promote the deploy -u flag
<jcastro> yeah
<Azendale> marcoceppi: Check it out, I think I have a working fix for the bug I've been chipping away at: https://bugs.launchpad.net/charms/+source/etherpad-lite/+bug/1247636
<_mup_> Bug #1247636: etherpad-lite fails to deploy, install hook running get-relation <etherpad-lite (Juju Charms Collection):New> <https://launchpad.net/bugs/1247636>
<marcoceppi> Azendale: awesome! You can propose to merge and it'll land in the review queue
<marcoceppi> I'll take a look at it either today or tomorrow
<Azendale> marcoceppi: I think I proposed it already, did I do it right? Once it goes through the review queue is it then in the store? (or is it more complicated than that?)
<marcoceppi> Azendale: ah! there it is: http://manage.jujucharms.com/tools/review-queue
<marcoceppi> once it's reviewed and accepted, it'll be merged in to the charm store
<Azendale> marcoceppi: awesome! It's really neat when you finally get something working that wasn't before
<marcoceppi> Azendale: and we reallllly realllllly apprecaite you helping us fix the tings that don't!
<jcastro> Azendale, have we sent you a Juju shirt yet?
<Azendale> jcastro: Uh, no. I am just a community member, not an employee or anything
<jcastro> perfect!
<marcoceppi> Azendale: Just a community member? We love the community members!
<jcastro> Azendale, send me your address, jorge@ubuntu.com and I'll have something shipped out to you!
<Azendale> jcastro: Wow, thanks! I will.
<Azendale> so, if I've proposed my branch to be merged, what is the proper bug status to set?
<marcoceppi> Azendale: fix committed
<sinzui> marcoceppi, how many hours until the ODS charm school starts?
<marcoceppi> sinzui: I don't know, I'm not at ODS
<marcoceppi> jcastro: ?
<thumper> marcoceppi: is jcastro at ODS?
<marcoceppi> thumper: nope
<jcastro> thumper, yo
<thumper> jcastro: hey
<thumper> jcastro: do you know if there is a charm school at ODS?
<jcastro> yeah
<jcastro> the CTS guys are handling it
<thumper> do you know when?
<jcastro> in multiple languages even!
<jcastro> not sure
<thumper> because it may all go horribly wrong
<thumper> ...
<jcastro> we didn't get a talk accepted so they had to schedule it in another room
<jcastro> why? what's up?
<jcastro> well, if they listened to what I said they know better than to upgrade
<thumper> there is a precise update that triggers a setup of cgroups-lite which triggers apparmor in the host
<thumper> which leaves apt in a weird state
<thumper> which makes all install hooks fail
<thumper> it impacts all previous versions of juju
<thumper> jcastro: you could confirm by trying it locally
<thumper> just try to fire up the local provider and deploy mysql
<jcastro> my local provider is broken, remember
<thumper> jcastro: didn't we fix it?
<jcastro> no
<jcastro> I'm going to have to reinstall
<thumper> we need to work out what's going on there
<jcastro> hey so is there a workaround?
<thumper> no
<thumper> :(
<thumper> I've submitted a fix to the stable branch
<thumper> but releasing properly can take some time
<jcastro> for juju or cgroups?
<thumper> juju
<jcastro> is it a workaround or do we need to have something fixed in cgroups in distro quickly?
<thumper> we have to get them new jujus
<thumper> it isn't cgroups fault
<thumper> it is my fault
<jcastro> ok so basically
<jcastro> they need to run juju from source
<jcastro> and not from a package
<sinzui> That is one fix
<jcastro> unless we're working on a PPA build right now?
<thumper> jcastro: who in cts is your touch point on this?
<jcastro> looking it up
<sinzui> the other is to run from source from lp:juju-core/1.16 which is just the fix
<thumper> sinzui: can we push it into the dev ppa?
<sinzui> I can build 1.17 to that ppa....
<jcastro> thumper, you just tell me what to tell them, I'll  draft a mail now
<thumper> sinzui: how about we go with the 1.17 dev ppa route?
<thumper> sinzui: with no cloud tools, just for local use?
<sinzui> thumper, I appear to be capable of uploading to to the stable and dev ppas, but my packaging rules are definitely unstable...so I would put the packages in devel, and I cannot imagine cts using that ppa
<thumper> ...
<jcastro> how about a oneoff PPA with the fix?
<sinzui> I happen to have one...
<sinzui> first
<sinzui> who is installing the juju-core package?
<sinzui> Many people, just cts staff?
<jcastro> thumper, ugh, the school was for today, 2-4pm local time
<jcastro> local hong kong
<sinzui> So we are past that?
<jcastro> so it should have happened already
<jcastro> yeah
<sinzui> well
<sinzui> I put together a plan and release notes
<thumper> jcastro: today, wednesday or tuesday?
<jcastro> tuesday
<jcastro> aka, we would have heard about it by now
<jcastro> thumper, do you happen to know when the cgroups issue hit us exactly?
<thumper> I got pinged about it monday, fixed it tuesday
<thumper> it is now wednesday
<jcastro> thumper, are we sure that the cgroup bug was in the latest cloud images?
<thumper> it came through in the update/upgrade part of cloud-init
<jcastro> ah nuts
<jcastro> do you have a link to the bug?
<thumper> however...
<thumper> if someone created a new lxc base image that didn't need the update
<thumper> perhaps they wouldn't hit it
 * thumper shrugs
<thumper> maybe it hit others because the lxc image isn't updated locally automatically
<jcastro> if it was a disaster we would have heard by now
<thumper> most likely
<jcastro> and those guys are way smart, they probably monkey patched it, made fun of you, and then moved on with their lives, heh.
<thumper> :)
<jcastro> they only issue they were having is needing more slides over the weekend, but I took care of that
<jason955> hello all
<jason955> I am trying to run a local version of juju but getting error message related to installing cgroup-lite.  The bug is documented here: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1247299
<_mup_> Bug #1247299: local provider deploys fail with 'install hook failed' <local-provider> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Committed by thumper> <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
<jason955> Does anyone know how to work around this bug?
<thumper> :)
<thumper> we were just talking about it
<thumper> jason955: have you used the local provider before?
<jason955> No.  I am new to Juju in general.  I have quite a bit of linux experience though.
<thumper> can I get you to check the timestamps on the files is /var/cache/lxc/cloud-precise?
<jason955> I was just trying to launch a couple of services to play with Juju
<jason955> I'm actually at work right now and not on my machine.  I was just wondering if there was a simple workaround.  I can always come back later this evening when I am on my machine.
<thumper> jason955: the short answer is "it's broken" for some value of broken
<thumper> the fix has been landed and we are rolling out a release
<thumper> jason955: I have a theory
<thumper> jason955: that perhaps newer downloads of the 12.04 lxc template might be fine
<thumper> but not found anyone to test it yet
<thumper> jason955: how long until you are back home?
<jason955> ok.  Thanks for the info.  I probably won't be back for another 7 hours or so.... :(
<thumper> jason955: AU?
<thumper> or nz
<jason955> I'm in Los Angeles.  Just have some stuff to take care of after work so won't get home until late.
<thumper> ah..
<thumper> I probably won't be around then
<jason955> You usually around on the weekends?
<thumper> not really, family calls
<thumper> I'm only three hours out from CA now
<thumper> three hours behind that is
 * thumper is in nz
<thumper> jason955: so around working during your sunday :)
<jason955> Gotcha.  I'll try to catch you early in the morning some time or right after work.  Or.... on Sunday
<dpb1`> Hi -- how do I search for charms that implement an interface on jujucharms.com now?
 * thumper shrugs and looks at gary_poster|away
<jason955> I'm actually impressed that you were online.  I saw you answered the question on Stack Overflow (or ask ubuntu...)  small world
<dpb1`> Or... even without jujucharms.com... Just any way to do it.  :)
<jason955> and you are the bug fixer assigned to the task it appears...
<thumper> :)
<thumper> I'm a core dev for juju
<thumper> and also happened to write the local provider
<jason955> nice work!  pleasure to meet you
<thumper> always nifty to make contacts in other parts of the world
<jason955> I will be in touch.  I usually go under the nick sbbrtn.  TTYL
 * thumper nods
<thumper> ciao
<dpb1`> oh, I see
<dpb1`> manage.jujucharms.com
<marcoceppi> jcastro: thumper I think they were deploying to HP Cloud
<marcoceppi> for the charm school
<thumper> \o/
<thumper> no problems with that AFAIK
<marcoceppi> at least that's the impression I got/gave them during our chat at the sprint
<marcoceppi> thumper: right
<thumper> marcoceppi: because they were demonstrating openstack?
<thumper> I guess
<thumper> being at ODS and all
<marcoceppi> thumper: because I tell people to demo on a real cloud
<thumper> nice
<marcoceppi> it's more impressive when you can juju status and people can hit, say an etherpadlite ip adddress and start typing
<sarnold> :)
<marcoceppi> don't get me wrong, I love the local provider, but when you want to show the power of juju, deploying to HP Cloud or EC2 is way better than trying to explain my laptop is now a cloud
<jason955> Right now I have an ec2 server with 3 mysql instances.  They run on different ports.  Is this possible to do with Juju?  Or do I have to deploy on separate VMs?
<jcastro> thumper, wait ...
<jcastro> thumper, so we ONLY break on LXC
<jcastro> whew, of course I told them not to use the local provider!
<jcastro> even before this bug!
<thumper> jcastro: and only lxc on the local provider, lxc on maas is fine
#juju 2013-11-06
<thumper> jason955: you sould be able to configure each mysql deploy to use a different port
<thumper> jason955: and use the placement directive --to in order to put them on the same machine
<jason955> I understand the placement directive.  So you are able to configure the port then.... Is this true for most charms?
<thumper> jason955: I expect so, I think it is something the charm reviewers look for
<thumper> minimal hard coding
<thumper> sensible defaults but configurable
<jason955> awesome, Juju is pretty exciting stuff!
<jason955> also, currently I have a web server that that serves some static HTML for some pages and forwards to a WSGI service with an http proxy.  Is it possible to do this with Juju?  I see that I can make web servers but can you perform path-based routing?
<jason955> or is there a way to just do domain based routing? to multiple proxy servers behind a main apache instance?
<jason955> perhaps an example would be helpful: apache or nginx as the front web server.  A couple of different gunicorn instances behind the web server.  Can I configure the webserver to route to the different gunicorn relationships based on the top level domain being requested?
<marcoceppi> jason955: the apache 2 charm allows for this
<jason955> Thanks.  I assume I just have to ssh into the charm and configure the apache files?
<sarnold> jason955: some details can be found here: http://manage.jujucharms.com/charms/precise/apache2
<marcoceppi> jason955: note you can do it via charm configuration
<sarnold> looks very nice :)
<jason955> awesome.  Exactly what I was looking for!
<jason955> nice video BTW marco
 * thumper goes to do some work
<marcoceppi> jason955: thanks! which one are you watching?
<jason955> How to use the Local/LXC Provider (August 2013)
<jason955> watched it last night
<marcoceppi> awesome
<freeflying> any doc for juju use tag to specify maas machine when deploy
<marcoceppi> freeflying: https://juju.ubuntu.com/docs/charms-constraints.html#constraints-maas
<freeflying> marcoceppi, figured out, thanks
<nesusvet> hello everyone. I can't destroy machine which status is pending
<davecheney> nesusvet: not at the moment i am afraid
<nesusvet> Hmm, so what should I do? )
<davecheney> nesusvet: can you paste the status of the machine
<davecheney> ?
<davecheney> ie, why isn't it going to come up
<nesusvet> I tried to reboot it, and after this it's disappeared, but when I add it again, it has the pending status again
<nesusvet> davecheney,   http://pastebin.com/E1pbwBdb
<davecheney> nesusvet: are you canonical ?
<nesusvet> nope
<davecheney> ok, jus tchecking
<davecheney> short answer is
<davecheney> once you giv ethat machine to juju
<davecheney> you can't touch it
<davecheney> i'm afraid there is currently no provision for removing that machine from status
<davecheney> and as a pending machine with no units assigned to it
<davecheney> it iwll attract a unit and fail to deploy it
<davecheney> the solution at the moment is to destory your environment and start again
<davecheney> i am sorry
<nesusvet> ohh
<nesusvet> sound bad )
<nesusvet> sounds*
<nesusvet> well I will do
<davecheney> you mustn't use the maas console once themachine has been assigned to juju
<davecheney> otherwise it'll all go wrong
<nesusvet> I did't use maas at all (
<nesusvet> all that I did, just sshed on it and reboot
<davecheney> yeah, you can't do that either
<davecheney> once juju is reponsible for the machine you must not touch it
<nesusvet> I see
<davecheney> otherwise juju will get out of sync
<nesusvet> thanks )
<nesusvet> but if I deploy thousand of server, so it might be dangerous. it's not flexible way (
<nesusvet> Well, I have another question.
<davecheney> nesusvet: we're working on fixing it
<davecheney> i'm sorry the fix isn't available yet
<nesusvet> Can I deploy the juju agent on the node where maas is located?
<davecheney> the solution is to use maas tags
<davecheney> you can use juju deploy --constraint="maas-name=XXXX"
<davecheney> i am not sure if it is available yet
<davecheney> it may be in version 1.16
<nesusvet> interesting. But juju does't see this machine.
<nesusvet> I tryed to do juju add-machine ssh:ubuntu@ip-address
<davecheney> nesusvet: ok, that is different
<davecheney> are you using the maas provider
<nesusvet> yes
<davecheney> or the ssh/manual/null provider ?
<davecheney> ok, the maas provider cannot provision ssh: machines
<davecheney> that is the ssh provider
<nesusvet> It's not clear part for me.
<davecheney> i'm sorry, you cannot mix and match providers in a single environment
<nesusvet> But after this action juju started seeing my maas machine.
<davecheney> i cannot explain that
<nesusvet> Do you mean, I can install juju agents's on the target machines even in case if I don't have maas?
<davecheney> you can do this
<davecheney> it's called the manual provider
<davecheney> each environment can be managed by a single provider
<davecheney> if you want to use the manual provider
<davecheney> those machines will be provisioned in a different environment
<davecheney> and will be unable to form relations to the machines in your maas environment
<davecheney> (even though you may have asked maas for machines and provisioned them manually)
<nesusvet> Thank you very much, davecheney
<nesusvet> Now it's clear
<davecheney> nesusvet: happy to help
<Tribaal> Hi all, I need some help debugging some juju/maas interaction. Is this the correct channel or should I jump to #juju-dev ?
<dpb1`> Tribaal: what do you need?
<marcoceppi> Tribaal: we shoud be able to help here. Those in #juju-dev are also here
<Tribaal> I setup a local KVM MaaS server that spins up other KVM nodes via PXE - that seems to work fine. I pointed juju at it, and a "juju bootstrap" spun up a node ("juju status" reports). Spinning up charms however does not work - the nodes are started and provisionned (ubuntu installed), but they are stuck in a pending state forever
<Tribaal> let me paste the juju logs
<Tribaal> http://pastebin.ubuntu.com/6370847/
<Tribaal> that's the only file in /var/log/juju
<Tribaal> "juju ssh" to the machine works
<Tribaal> the nodes can see the internet and talk to each other just fine
<dpb1`> weird: 2013-11-06 13:40:26 ERROR juju runner.go:211 worker: exited "deployer": exec ["start" "--system" "jujud-unit-mysql-0"]: exit status 1 (start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)
<Tribaal> right
<Tribaal> so I ran this by hand
<Tribaal> it succeeds without the "--system"
<Tribaal> but then another log shows up in /var/log/juju
<Tribaal> repeating "/bin/sh: 1: exec: /var/lib/juju/tools/unit-mysql-0/jujud: not found"
<Tribaal> the tools directory has a machine-1 symlink, but no unit-* symlink
<dpb1`> Tribaal: is this from trunk or from the ppa?
<Tribaal> dpb1`: whatever comes from saucy - from teh node: http://pastebin.ubuntu.com/6370948/
<Tribaal> dpb1`: is that what you meant?
<dpb1`> Tribaal: also, it seems weird that it's passing --system ??
<Tribaal> indeed
<dpb1`> Tribaal: what version of juju do you have on your system where you are initating commands?
<Tribaal> dpb1`: from the initiator: http://pastebin.ubuntu.com/6370959/
<dpb1`> OK good
<dpb1`> stable ppa
<dpb1`> Tribaal: these are precise boxes?
<Tribaal> saucy
<oatman> hi all, where would I look for advice on using the gunicorn charm (http://manage.jujucharms.com/charms/precise/gunicorn) ?
<oatman> ie, I am writing a WSGI process, I guess I want to charm up my app and link it to the gunicorn charm some how, is it a subordinate?
<marcoceppi> oatman: yeah, the gunicorn charm is an interesting on
<marcoceppi> one
<oatman> describing the charm as "interesting" is in itself interesting. Why so?
<marcoceppi> oatman: I've not used it and it's usecase alwasy seemed very narrow to me
<marcoceppi> oatman: I'd look in to how python-moinmoin charm works with this as it's what the author developed the charm to work with originally
<oatman> ah, good plan
<oatman> I had noticed the reference in the readme
<oatman> thanks marcoceppi
<jcastro> marcoceppi, after I bzr pull in your charm tools dir I need to do X to install it?
<jcastro> solve for X please
<marcoceppi> jcastro: use the PPA
<marcoceppi> 1.1.2 and trunk are the same at this time
<jcastro> which ppa?
<marcoceppi> ppa:juju/stable
<marcoceppi> jcastro: wait, you've manually installed
<marcoceppi> you're going to have to clean a few things up
<marcoceppi> manual install and ppa will just stomp all over eachother
<jcastro> marcoceppi, ack, how do I blow away the manual install?
<jcastro> arosales, when you get a chance today can you look at the sessions in the sidebar
<jcastro> we are out of slots and we're going to have to cut some sessions
<jcastro> so we need to prioritize
<arosales> jcastro, will do
<jcastro> arosales, we only need to cut like 3 sessions or so
<arosales> jcastro, thats not bad
<jcastro> I asked for more room in an empty track but that's not happening, so we need  to cut the fat
<jcastro> other than that, our schedule for UDS is basically done, I'll post to the list
<marcoceppi> jcastro: rm -rf /usr/bin/juju-charm /usr/bin/charm-* /usr/bin/juju-bundle /usr/local/lib/python2.7/dist-packages/charmtools
<jcastro> ta
<marcoceppi> jcastro: then re-install the package
<jcastro> got it, thanks!
<rick_h_> hazmat: ping, jujuclient review if you get a few min we need to release bundles. https://code.launchpad.net/~rharding/python-jujuclient/adjust_constraint_handling/+merge/194176
<rick_h_> hazmat: we'll have more coming, but after the release I think.
<marcoceppi> hey party people: https://plus.google.com/hangouts/_/76cpj8gt7n29nu6ni5gl7sq9j0?authuser=0&hl=en
<marcoceppi> Charm status in a few mins
<marcoceppi> evilnickveitch:
<marcoceppi> http://youtu.be/CNb3J92TU94
<mind_> mims is gone!! no wonder no one has reviewed my charm modifications.
<mind_> jcastro: who should I request to review my node-app modifications. Did a bunch of things Mims asked for before he wanted to approve changes to it(hash check, default app, and source code install with option for repository install).
<jcastro> hi mind_!
<jcastro> let me check it out
<jcastro> do you have a bug # handy by any chance?
<mind_> https://code.launchpad.net/~web-brandon/charms/precise/node-app/install-fix
<mind_> not a bug was just making it better
<scuttlemonkey> so is it possible to use juju on a set of established servers yet?
<scuttlemonkey> I know there was a request for that a while back
<jcastro> scuttlemonkey, pretty close
<scuttlemonkey> ahh neat
<jcastro> next stable release probably
<scuttlemonkey> unfortunately that doesn't help me w/ the demo I'm building now on a rack for SC13 :)
<scuttlemonkey> alas
<jcastro> https://juju.ubuntu.com/docs/config-manual.html
<jcastro> hmm, how is this MP not in the queue
<mind_> is there a preffered repo for charmtools still or is the best version part of the main branch now
<jcastro> the stable PPA is what you want
<jcastro> mind_, ok I've subscribed it to the ~charmers team
<jcastro> should be reviewable next in the queue
<jcastro> marcoceppi, ^^^
<mind_> thank you
<jcastro> jcsackett, any idea why that branch wouldn't show up in the queue?
<marcoceppi> webbrandon: jcastro: I'll have eyes on later today
<webbrandon> thank you as always marco
<webbrandon> thank you for adding mongodump suport to mongodb juan
<jcsackett> jcastro: it doesn't have charmers as a requested reviewer; looks like you and Mims were requested directly.
<jcastro> oh weird, I thought all MPs to anything in the charms namespace was autoqueued
<jcsackett> jcastro: no, it's any MP with charmers as the requested reviewer (which is the default for charms owned by ~charmers).
<jcastro> huh, I wonder how this happened
<jcastro> oh well, it's in the queue now
<jcastro> webbrandon, have we sent you a juju shirt for your contribution?
<scuttlemonkey> jcastro: can juju add-machine ssh: use .ssh/config to resolve somehow?
<scuttlemonkey> I see ip, hostname, and full user@ip
<jcastro> scuttlemonkey, so there were a bunch of issues that prevented manual from working
<jcastro> I don't know if we've fixed those yet in the dev releases
<jcastro> I can give it a shot after lunch
<scuttlemonkey> ahh
<scuttlemonkey> ok, so I'd have to pull from the dev ppa
<jcastro> yeah
<scuttlemonkey> may just use ceph-deploy and see if I can get there from here
<jcastro> sinzui, do you know the status of manual provisioning in the dev releases offhand?
<sinzui> No I don't
<jcastro> scuttlemonkey, once it lands though it'll be so nice to deploy to like digital ocean, etc.
<sinzui> jcastro, there is certainly one more bug that the devs want to include in a 1.17 release
<sinzui> https://bugs.launchpad.net/juju-core/+bugs?field.tag=ssh-provider
<scuttlemonkey> jcastro: yah, definitely
<marcoceppi> jcastro: jcsackett it probably was originally assigned to charmers, when you claim review it's no longer assigned to charmers, so you need to make sure to say "When ready for another review, please "Requestion another review" from charmers"
<webbrandon> I thought I remember someone saying a while back that juju-local bootstrap will no longer need to be done as a root, still coming or pipe dream?
<jcastro> webbrandon, that's coming
<webbrandon> :)
<jcsackett> marcoceppi: that makes sense. jcastro ^
<jcsackett> oh, nm, you were highlighted in that too.
<webbrandon> jcastro no i havent gotten a shirt
<webbrandon> would love one though
<jcastro> webbrandon, pm or mail me your address and I can send you one! (jorge@ubuntu.com)
<arosales> sinzui, natefinch-afk: can you guys confirm the widows client got updated to 1.16.2 so it also receives the fix for https://bugs.launchpad.net/juju-core/+bug/1246320
<_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified <azure> <bootstrap> <Go Windows Azure Client Library:Fix Committed by wallyworld> <juju-core:Fix Committed by wallyworld> <juju-core 1.16:Fix Released by wallyworld> <juju-core trunk:Fix Committed by wallyworld> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1246320>
<sinzui> arosales, yes, that is what we updated every link to https://juju.ubuntu.com/install/
<arosales> sinzui, thanks for confirming.
<webbrandon> jcastro I just emailed you (from brandon clark)
<jcastro> cheers!
<hazmat> rick_h_, why do you want that behavior?
<hazmat> rick_h_, the client lib explictly avoids trying to do policy things.. ie. that whitelist already misses lots of constraints
<rick_h_> hazmat: because bundles were failing to deploy from the gui silently because they had pyjuju style constraints. We spent a lot of time debugging it yesterday. Noted in there we want to try to work on getting messages/errors out of the client up to the deployer and back into the gui, but that's going to take some more work
<rick_h_> hazmat: yea, it's a hacky temp fix. I pulled the list of suported gui juju-core constraints to check against
<hazmat> rick_h_, sorry this is the right layer for a temp fix
<hazmat> isn't
<rick_h_> k
<hazmat> rick_h_, deployer would be fine
<rick_h_> k
<hazmat> rick_h_, but its not really about white listing.. its about blacklisting
<hazmat> rick_h_, there are new constraints all the time, and this white list already misses a few
<rick_h_> hazmat: well we've talked about trying to be able to get a vocabulary from juju itself, but not available yet. Not sure how a blacklist would work best.
<hazmat> rick_h_, you have a specific problem wrt to pyjuju compatiblity around constraint keys.
<rick_h_> hazmat: well, around people manually creating deplyer files hand entering constraints, and those causing really impossible ot trace errors
<hazmat> rick_h_, fair enough, but we don't really want to update a constraint list every time
<rick_h_> hazmat: +1
<hazmat> rick_h_, the real issue is the reporting. you have a specific case of pyjuju constraint keys that aren't valid against juju, you can play to that case in the app level (deployer or gui)
<rick_h_> hazmat: ideally we'll get errors from the rpc call in the client, back to the deployer, to the guiserver, to the gui UX for users when it fails
<hazmat> rick_h_, yeah, that error reporting would be ideal
<rick_h_> I'm trying to unblock the bundles release asap with this fix. Understand if you'd prefer it happen elesewhere or differently.
<hazmat> rick_h_, silently stripping the user input without feedback is likely to cause its own set of surprises.
<rick_h_> the thought was that limiting the constraints of bundles while we get the reporting in place was a reasonable band-aid
<rick_h_> hazmat: understood
<hazmat> rick_h_, fair enough.. but the band aid should go as close to the app as possible, not prevent use in the client libs of valid constraints.
<hazmat>  rick_h_ where does the reporting break errors back to the user breakdown?
<hazmat> s/break/back
<rick_h_> hazmat: so the client throws a EnvError that doesn't have the message from the rpc call
<rick_h_> hazmat: so the deployer can check for EnvError, but the error isn't helpful
<rick_h_> hazmat: and the deployer throws exceptions without any messages so it needs updating to get them back and the guiserver bits in there need to get it on the ws back to the gui charm
<hazmat> rick_h_, so the client error message should have details
<hazmat> rick_h_, if not thats a bug..
<rick_h_> hazmat: yea, it'll be step 1
<hazmat> rick_h_, the entire response is attached to the enverror so not clear how it goes missing
<hazmat> rick_h_, step 1 afaics is really about fixing deployer err handling so that's its more suited for this as a  library usage instead of its current i'm a cli tool and i fail fast on error.
<hazmat> rick_h_, what would the gui want  as a form of error?
<rick_h_> hazmat: rgr, same type of stuff we're hitting with charmtools and proofing.
<hazmat> rick_h_, yup
<rick_h_> hazmat: not sure, atm debugging a charmworld release issue with webops so will have to get back with you
<hazmat> rick_h_, is there any expectation or error handling for deploys in gui?
<hazmat> k
<rick_h_> hazmat: no, because it's async we fire the deploy request off and errors don't get back right now. At least in our debugging why come bundles were failing to work yesterday
<hazmat> rick_h_, that sounds like a separate / additional issue with the guiserver deployer middleware.
<rick_h_> hazmat: +1 the guiserver bit int he deployer needs to communicate errors back to the gui server in the charm
<rick_h_> hazmat: right now, in env/gui.py it calls deploy and walks away
<hazmat> rick_h_, and a common way to communicate errors is exceptions.. so three separate issues rich exception passthrough and handle exceptions at gui server, and ... implement error handling in the gui for bundles
<rick_h_> hazmat: yes, that's the fix we want to do. To move forward today the band-aid fix came up. If it's not ok, then we'll do something else. However, trying to get to release today/tomorrow.
<hazmat> rick_h_, the closest place to gui that's reasonable to do a hack is the guiserver deployer middleware
<rick_h_> hazmat: rgr, will move the band-aid there for now then and we'll be fixing coms/deployer as a library as follow ups post-release
<hazmat> rick_h_, sounds good
<dpb1`> Hi all: how do I get something out of life: dying?  I want the service gone.
<marcoceppi> dpb1`: are any of the units in a dying state?
<dpb1`> marcoceppi: actually the units removed just fine
<dpb1`> marcoceppi: but the service is still there.  dying. :)
<marcoceppi> dpb1`: status output?
<dpb1`> ya, sec
<dpb1`> marcoceppi: pft, it's gone
<dpb1`> marcoceppi: wdyd
<marcoceppi> dpb1`: magic ;)
<dpb1`> lol
<dpb1`> well, that is fine with me.  I was too quick I think
<webbrandon> hmmm nothing will install from apt-get if I use -y -qq options.  Getting a cgroup-lite error.  Haven't seen this before and this charm used to work.  On juju-local, anyone seen this?
<marcoceppi> webbrandon: this is a known issue, being patched atm
<webbrandon> GTK
<marcoceppi> webbrandon: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1247299
<_mup_> Bug #1247299: local provider deploys fail with 'install hook failed' <local-provider> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Released by thumper> <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
 * thumper sighs some more
 * marcoceppi giggles
<rick_h_> thumper: we <3 you for fixing it
<thumper> if only everyone used juju from trunk
<rick_h_> :)
<thumper> there would be chaos everywhere
<marcoceppi> mwhaha
<webbrandon> Can't wait to see your fix in play thumper. Thank you
<thumper> np
<aaronfc> Hi
<marcoceppi> hello aaronfc o/
<aaronfc> I just bought a VPS (under OpenVz) with Ubuntu Server 13.04, and I want to use Juju.
<aaronfc> I tried installing juju-local, but I get an error about "lxc"
<marcoceppi> aaronfc: can you put your error on paste.ubuntu.com ?
<aaronfc> sure! http://paste.ubuntu.com/6372971/
<aaronfc> do you need full error ?
<aaronfc> full error: http://paste.ubuntu.com/6372981/
<thumper> aaronfc: I'd highly suggest not using juju-local on a VPS
<thumper> aaronfc: the local provider is targetted for development purposes
<thumper> and unless this is what you are wanting to use it for
<thumper> it may be better to try the manual bootstrapping
<thumper> aaronfc: the lxc service failed to start, logs probably in /var/log/upstart/lxc.log
<aaronfc> I'm trying the juju-local because I thought it was the only option without using a cloud service provider. Am I wrong?
<thumper> aaronfc: yes
<thumper> aaronfc: there is a way to manually bootstrap juju to an environment you have ssh access to
<thumper> it is still very much beta
<thumper> but workable
<thumper> ish
<aaronfc> I found juju yesterday and I thought giving a try on my brand new VPS :)
<context> emphisis on the "ISH" ;)
<context> i was able to use juju-local without much problems on vmware-fusion locally no problem
<thumper> local is really targetted for devs to use on their own computers
<aaronfc> log file does not exist
<thumper> arosales: what about with a .gz?
<aaronfc> in my case which would be the better choice ?
<context> but i was running 13.10
<aaronfc> (I do not have any cloud provider and I do not have the money to get one)
 * thumper nods
<thumper> this is one of the main use cases we had for the manual provisioning and manual bootstrap
 * arosales assumes that ping was for aaronfc 
<aaronfc> any references for manual provisioning on juju ?
<aaronfc> (and the manual bootstrap)
 * thumper wonders where the docs are
<marcoceppi> thumper: they won't land until the feature is complete
<thumper> marcoceppi: I was checking the juju help topics
<marcoceppi> thumper: oh that's on you guys
<thumper> but they aren't there either
<thumper> aaronfc: ping axw when he comes on line :-)
<aaronfc> should I wait for a more usable version ?
<thumper> depends how daring you are
<aaronfc> just the right amount
<aaronfc> haha
<aaronfc> seems relatively difficult to get it work (couldn't find anything interesting on google :( )
<aaronfc> do you guys know any alternative?
<thumper> if you want to use juju, then manually bootstrapping is the only way to work in an unsupported cloud / non-cloud machine
<webbrandon> aaronfc: You could also use AWS free tier for now if you have to much trouble with those methods(untill they are complete)  Just be sure to launch a micro instance.
<webbrandon> you have 775 free hours of micro instance use
<webbrandon> adds up quick when you have several instances going
<aaronfc> thumper, can you develop a little more the "manually bootstrapping" ?
<marcoceppi> webbrandon: if you like having your computer cycles stolen from you
<aaronfc> It sounds like what I require, but can't find any info in how to do that
<marcoceppi> ;)
<aaronfc> webbrandon, thanks for the info :)
<thumper> aaronfc: I've not done it myself, but I know the guy that wrote it
<thumper> aaronfc: ask a question on 'ask ubuntu', tag with juju, and I'll get him to answer
<webbrandon> marcoceppi: I know thats what sucks, but not a bad option for testing when your the only one accessing the instance
<webbrandon> aaronfc: First part of this vid will show you how to get basic AWS setup(http://www.youtube.com/watch?v=vV8KYbFUcQw) Also this is the juju doc (https://juju.ubuntu.com/docs/config-aws.html) And this is how you launch a micro instance (juju bootstrap --constraints "cpu-power=0 cpu-power=0 mem=512M")
<aaronfc> webbrandon, really appreciate your help :)
<aaronfc> I will write all this down in case I finally can not get Juju to work locally :)
<marcoceppi> aaronfc: everything is logged at http://irclogs.ubuntu.com/2013/11/06/%23juju.html
<marcoceppi> updated every hour
<aaronfc> hahahaha
<aaronfc> nice to know
<aaronfc> Hi Obama, how are you?
<webbrandon> lol
<webbrandon> whats out for thumper if you start talking about politics!!
 * thumper squints at webbrandon
<aaronfc> It's a pitty :( I'm really disappointed
<aaronfc> I really wanted to install Juju! :( (I'm like a kid now, I know haha)
<aaronfc> question about a new approach
<aaronfc> is there any possibility to get my VPS being handled by my local computer? I mean, installing Juju on my machine (MAC) and configure it to handle my VPS as a cloud-provider ?
<marcoceppi> aaronfc: that's more or less manual provider
<marcoceppi> if you do proper port forwarding, I think you can do a local deployment then use juju add-machine to inlist servers outside via SSH
<marcoceppi> aaronfc: what OS are you running now?
<aaronfc> on my local machine ?
<marcoceppi> yeah
<aaronfc> OSX Maverick (I do not know how to spell it, the last one)
<marcoceppi> aaronfc: there's a Vagrant box laying around somewhere that you can use to spin up an Ubuntu VM with the local provider configured and deployed
<marcoceppi> so you can play with juju without needing to pay for an external source
<marcoceppi> thumper: I haven't seen an announcement yet, but was that local provider snafu fixed/released in 1.16.3?
<thumper> marcoceppi: should be
<thumper> is it out?
<marcoceppi> no idea
 * marcoceppi checks the ppa
<thumper> :)
<marcoceppi> no :(
<aaronfc> marcoceppi, would this Vagrant box allow me to manage my VPS ?
<marcoceppi> aaronfc: no, not really at least not in an easy or proven fashion
<aaronfc> Oh :( this is really sad
<aaronfc> do you guys think Juju will at some point work out of the box for managing local machine ?
<marcoceppi> aaronfc: you can manage a local machine, you're trying to manage a remote machine one-off with juju
<aaronfc> I guess it is juju-local what I'm looking for, but as you saw I couldn't get it to work
<aaronfc> :/
<marcoceppi> aaronfc: that's on the roadmap
<aaronfc> I'm trying to manage a remote machine, from that remote machine
<marcoceppi> aaronfc: juju-local is designed for development/testing of juju and charms locally on your machine, not on a remote machine. Manual provisioning is what you want and it's due to land soon in Juju
<aaronfc> I mean, I sshed on my VPS, and tried there to install juju-local
<aaronfc> ok
<aaronfc> now I understood :)
<aaronfc> do you have any expected date ?
<marcoceppi> aaronfc: right, that's not how juju works. It works better when you install juju on MacOSX from Homebrew, then bootstrap/manage a remote cloud
<aaronfc> or anywhere  I could "subscribe" to know ?
<marcoceppi> aaronfc: sign up for our mailing list to follow release announcements and discussions of juju features https://lists.ubuntu.com/mailman/listinfo/juju
<aaronfc> ok, thanks
<aaronfc> marcoceppi, I gess installing on MacOSX would work
<marcoceppi> aaronfc: there's preliminary support already, but it's not documented and doesn't quite work yet, I suspect 1.17.0 will address a lot of the outstanding issues
<jason955> Say I want to deploy some static HTML and possibly some PHP.  How would I go about doing that with Juju?  I figured I could just use Apache but don't know how to load the files into the charm.  It seems so straightforward but I can't figure out the correct way to do this.  Am I overthinking this?
<aaronfc> but right now (and correct me if I'm wrong please) there is not easy way to manage a remote machine (by ssh)
<aaronfc> I need a cloud provider
<aaronfc> a VPS is not valid
<marcoceppi> aaronfc: right, juju currently works best with a cloud provider. However, we're building a manual provider (in the works) that will allow you to manage one or more VPS machines/servers with Juju
<aaronfc> that's awesome
<aaronfc> then I will drop Juju for a while until it gets that manual provider :D
<aaronfc> I'll suscribe to the mailing list you sent before
<aaronfc> thank you all so much :)
<marcoceppi> aaronfc: sure, feel free to post asking about the manual provider, etc. A lot of juju people are here, but we're spread out around the world. Mailing list/askubuntu is a great place to have a longer running discussion
<jason955> Say I want to deploy some static HTML and possibly some PHP.  How would I go about doing that with Juju?  I figured I could just use Apache but don't know how to load the files into the charm.  It seems so straightforward but I can't figure out the correct way to do this.  Am I overthinking this?
<marcoceppi> jason955: so, there is no real generic "php" charm. You'd need to write a charm for that particular set of php code
<jason955> marcoceppi: thanks.  How about html? Same story?
<marcoceppi> jason955: HTML should be easier, let me check the charm
<jason955> marcoceppi: thanks!
<jason955> I'm just trying to grasp the Juju concepts here.  I really like the idea and would like to contribute if I can.  Do you guys need any help on the project?  I can write docs.  I can code in Python.  I know a little bit of bash.  I understand design patterns.
<marcoceppi> jason955: we need docs, we need charms!
<jason955> marcoceppi: it looks like the LAMP charm will pull from a repo
<marcoceppi> jason955: yes, I was about to mention that as an alternaive
<marcoceppi> the apache2 charm is really more like a loadbalancer/routing charm
<jason955> How do I get started?  Sign up on to launchpad?
<jason955> gotcha
<marcoceppi> jason955: yeah, grab a launchpad account, it's free. Then check out http://juju.ubuntu.com/docs for information about charm authors
<marcoceppi> jason955: there's a tool not mentioned on the writing a charm section yet, called charm-tools, I recommend installilng it and running `juju charm create` to get a basic template for a charm, then reading the charm author docs
<jason955> awesome.  Thanks.  I've read most of the docs.  I will check out the charm-tools software.
<sarnold> strongly recommended, it'll save some time and effort and beats hand-copying from the docs :) hehe
<jason955> thanks!
<marcoceppi> jason955: if you're on Ubuntu, you can `sudo add-apt-repository ppa:juju/stable` then apt-get update apt-get install charm-tools; there's an MSI for Windows and you can pip install charm-tools for Mac OSX
<jason955> I saw there is a Nginx charm but the development has stopped.  How can I get the source from where the author left off?
<marcoceppi> jason955: once you have Bazaar and Launchpad you can run bzr branch against the code branch for it
<jason955> marcoceppi: thanks.  I will be sure to DL the tool.
<jason955> I've used git and hg before so I need to learn a bit about bzr
<marcoceppi> jason955: if you're referring to this one, then the branch is the second URL listed: http://manage.jujucharms.com/~imbrandon/precise/nginx
<webbrandon> the first time using bzr may be a pain but once you get it going it is a cinch
<marcoceppi> jason955: it's very similar to both, it's a DVCS tool, you bzr add, bzr commit, bzr push, etc. Only difference is you don't clone you "branch". Branches in bazaar (unlike git) are hosted externally
<marcoceppi> so each repo is a branch
<jason955> got it.  I'll read some tutorials but sounds pretty similar to what I'm used to.
 * marcoceppi nods, feel free to ping in here if you need any help
<jason955> thanks for your help.  I look forward to contributing.
<marcoceppi> jason955: no, thank you! feel free to record any feedback about our docs and post them to the mailing list. Having users provide feedback on how we can improve is much apprecaited
#juju 2013-11-07
<Azendale> marcoceppi: I know this is like a little kid asking "are we there yet?". Do you think you'll get to review my merge proposal (for etherpad-lite) today?
<marcoceppi> Azendale: if you're curious of progress, you can check the review queue out, we typically go in order top to bottom (a bunch of old stuff just showed up).  http://manage.jujucharms.com/tools/review-queue
<marcoceppi> So if not tonight, then tomorrow
<Azendale> marcoceppi: ok, thanks. Psychologically, it's kind of like waiting for a package to to get here. :)
<marcoceppi> Azendale: :)
<sbbrtn> Just playing around with Juju.  I added a mysql server.  If I expose this, should I be able to connect to it from the internet?  It appears that it only allows connections via relationships.
<sarnold> yikes, you're brave to consider exposing mysql to the world :)
<Azendale> sbbrtn: what environment are you running on?
<sbbrtn> aws
<Azendale> sbbrtn: ok, in that case I believe it would (but I haven't used AWS before, so I could be wrong)
<sbbrtn> sarnold:  I wouldn't typically expose it to the outside world but just playing around
<sarnold> sbbrtn: I didn't see any calls to the 'open-port' juju hook in the mysql charm; I don't think you can directly expose its port by just running "juju expose mysql"
<sarnold> sbbrtn: (there is a defined python functio nthat run it, but I don't see it used anywhere: https://bazaar.launchpad.net/~charmers/charms/precise/mysql/trunk/view/head:/hooks/lib/utils.py#L119  )
<sbbrtn> sarnold: ok, thanks.  It wasn't opening up the port on my amazon firewall so I figured it wasn't opening..
<sbbrtn> sarnold: how do I execute that function from the juju command prompt? juju mysql expose ?
<sarnold> sbbrtn: if you're just goofing around, you can juju ssh mysql/0    -- once you're logged in, you can run open-port <mysql port number>   and then connect your machine's mysql to the remote server ...
<sarnold> sbbrtn: I'm trying to find if there's anything you have to do once you're logged in to make the 'open-port' command "available" for you to run .. I'm having trouble finding that. :)
<sbbrtn> Ok.  Thanks.  I figured there might be a different option short of going in via SSH
<sarnold> sbbrtn: this might be the way to get there... https://juju.ubuntu.com/docs/authors-hook-debug.html
<sarnold> (it'll fire up ssh too. hehe. :)
<sarnold> sbbrtn: it -could- be; if you really wanted this, you could fork the charm and modify one of the hooks to expose the port for you
<sbbrtn> not a big deal.  I'm really just playing around to see how Juju works.
<sbbrtn> thanks for the help
<sarnold> connecting the local mysql client to a remote hosted server would be a fun thing to see. I'd just be afraid to leave it up for very long, who knows how long it'd take before it's discovered and potentially abused. :)
<sbbrtn> yeah.  I see why you wouldn't want to expose it.  On my current web server I have multiple MySql instances running.  One is open to the public and is a development database so not too concerned with the contents.  The other two servers are only available via localhost and my VPN if I connect to it via OpenVPN.  I need access to the DB since the updates are made directly to the database and that is the best way I have
<sbbrtn> found.  I wonder if this is possible with Juju...
<sbbrtn> any way to kill a service after getting a hook failed?  I can't bring it down with destroy-service
<marcoceppi> sbbrtn: run `juju resolved <unit>` a few times
<marcoceppi> sbbrtn: sarnold it's odd that MySQL doesn't expose 3306. I should have that port "opened" and waiting for juju expose to be run. I'll look in to that
<sbbrtn> marcoceppi: Thanks (this is Jason955 from earlier BTW)
<marcoceppi> o/
<marcoceppi> sbbrtn: if you could open a bug against the MySQL charm that it doesn't expose the default port, I'll have it patched https://bugs.launchpad.net/charms/+source/mysql/+bugs
<sarnold> marcoceppi: I dunno, I kind of like the idea that it isn't just easily exposed. it feels like every CPU from oracle includes at least one remote unauthenticated mysql attack. :(
<sarnold> marcoceppi: maybe a config option yes-really-expose-my-database   or something? :)
<marcoceppi> sarnold: it won't be exposed unless the user really wants it to. What would be a better idea is to have the port configurable and have it use a non-standard port by default (if that was a concern)
<sbbrtn> marcoceppi: will do
<sarnold> marcoceppi: that'd be a help, but I wouldn't be surprised if mysql advertises itself on its port somehow..
<marcoceppi> sbbrtn: feel free to open bugs for any other things you find odd. If you search for the charm in https://manage.jujucharms.com/ you'll find a link for "Bugs" that you can use
<marcoceppi> Azendale: Wasn't able to get to your merge tonight, but it's next on the list for tomorrow!
<sbbrtn> marcoceppi: will do.  I just got my launchpad account.
<Azendale> marcoceppi: Awesome!
 * marcoceppi heads to bed
<sarnold> g'night marcoceppi :)
<sbbrtn> Can I create multiple Mysql instances on different ports with Juju?
<davecheney> sbbrtn: possibly
<davecheney> but not using the same machine
<sbbrtn> There isn't a way to change the port?
<davecheney> sbbrtn: there might be
<davecheney> didn't you say you wanted to have multiple mysqls ?
<sbbrtn> Yes.  I wanted one exposed to the web on a non-default port.
<davecheney> sbbrtn: the mysql charm doesn't currently support this, please raise a feature request, https://launchpad.net/charms/+source/mysql
<sbbrtn> will do
<stokachu> anyone awake that has any insight into the progress of https://bugs.launchpad.net/juju-core/+bug/1233457
<_mup_> Bug #1233457: service with no units stuck in lifecycle dying  <cts-cloud-review> <destroy-service> <state-server> <juju-core:Triaged> <https://launchpad.net/bugs/1233457>
<jcastro> hey marcoceppi
<jcastro> hey evilnickveitch
<jcastro> can you index the local troubleshooting page?
<jcastro> I am unsure if you're making a new troubleshooting section or putting it somewhere else
<evilnickveitch> jcastro, i am making a new section, but i will do it today
<evilnickveitch> makes a nice change from trying to reverse engineer interfaces
<jcastro> heh
#juju 2013-11-08
<ehw> hey, guys, where are the docs for juju's command-line switches? things like --config= --debug -v that kind of stuff
<matt_B> I do not see it in $juju help commands
<ehw> manpage also doesn't have it, or https://juju.ubuntu.com/docs/commands.html
 * ehw just wants to specify which environment he's using
<matt_B> You found the ones I have used, --debug and -v
<ehw> matt_B: completely incidental; just passed along through oral history
<matt_B> Is anyone able to issue juju debug-log with a local setup?  I get an error and found a bug report for it, but no workaround.
<matt_B> https://bugs.launchpad.net/juju-core/+bug/1202682
<_mup_> Bug #1202682: debug-log doesn't work with lxc provider <cts-cloud-review> <debug-log> <local-provider> <papercut> <ssh> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1202682>
<ehw> matt_B: dug a bit more, switches are documented in the different commands; i.e. juju help deploy
<matt_B> Thanks _mup_ got that number too, was wondering if any of the smart people here have worked around that
<matt_B> thanks ehw, I will add that to my oral history
<ehw> hehe
<ehw> and for the record, juju switch is what I was looking for
<matt_B> When I sing tails of juju I will include juju help deploy
<_mup_> Bug #1249248 was filed: juju-charms for Wordpress doesnt work-Wordpress agent status reported as  "install-error" <charms> <juju> <maas> <wordpress> <pyjuju:New> <https://launchpad.net/bugs/1249248>
<andreas__> hi, could I inderest someone into reviewing this one liner diff from the apache2 charm
<andreas__> that is causing hook errors for me?
<andreas__> https://code.launchpad.net/~ahasenack/charms/precise/apache2/apache2-no-failing-juju-log/+merge/194403
<ahasenack> it fixes #1249016
<ahasenack> and this silly error
<_mup_> Bug #1249016: Shouldn't log the relation data <apache2 (Juju Charms Collection):In Progress by ahasenack> <https://launchpad.net/bugs/1249016>
<ahasenack> 2013-11-07 16:39:39 INFO juju.worker.uniter context.go:255 HOOK OSError: [Errno 7] Argument list too long
<marcoceppi> ahasenack: I'll take a look today
<ahasenack> marcoceppi: thanks
<nesusvet> hello everyone!
<nesusvet> I am adding the hosts manually, but after I run the "juju bootstrap", I see the following message:
<nesusvet> ERROR cannot create new info for environment "null": chown /home/allods/.juju/environments: operation not permitted
<marcoceppi> nesusvet: run `ls -lah | pastebinit`
<nesusvet> marcoceppi, http://pastebin.com/hfEzJJR1
<marcoceppi> nesusvet: interesting. Can you rename "null" to something else in the environments.yaml? Say "manual" or another name other than null?
<nesusvet> ok, I will
<nesusvet> http://pastebin.com/6DXthB4u
<nesusvet> the result is http://pastebin.com/Rs59pU4H
<marcoceppi> nesusvet: I've not seen that before
<marcoceppi> rogpeppe: thoughts? ^^
<nesusvet> strace result: http://pastebin.com/FPiDJmtJ
<marcoceppi> nesusvet: run juju destroy-environment, then try to bootstrap again
<nesusvet> ERROR environment has no bootstrap configuration data
<marcoceppi> nesusvet: rm -f ~/.juju/environments/my.jenv, try to bootstrap again
<nesusvet> allods@a1base:~/.juju$ rm -f ~/.juju/environments/my.jenv
<nesusvet> allods@a1base:~/.juju$ juju bootstrap
<nesusvet> ERROR cannot create new info for environment "my": chown /home/allods/.juju/environments/my.jenv: operation not permitted
<nesusvet> juju version
<nesusvet> 1.16.3-precise-amd64
<marcoceppi> :\ nesusvet one second, let me try to replicate
<nesusvet> marcoceppi, ok
<rogpeppe> marcoceppi: looking
<rogpeppe> nesusvet: what user are you running as?
<nesusvet> what do you mean by "running as"
<rogpeppe> nesusvet: what does "id -a" print?
<nesusvet> uid=60001(allods) gid=60001(allods) groups=60001(allods),27(sudo)
<rogpeppe> nesusvet: ha, thought so
<rogpeppe> nesusvet: what does "echo $SUDO_USER" print?
<rogpeppe> nesusvet: hmm, actually i'm probably wrong
<nesusvet> nothing )
<rogpeppe> nesusvet: i am
<rogpeppe> :-\
<nesusvet> what does "echo $SUDO_USER" print? - nothing
<rogpeppe> nesusvet: yeah, i wondered if some particular logic was kicking in, but it seems it probably isn't
<nesusvet> so, as far as I understand we are still looking for a reason )
<nesusvet> rogpeppe, I appologize, I don't know English well ). And afraid that I could miss something important
<rogpeppe> nesusvet: what do you see if you do: "chown allods.allods ~/.juju/environments/my.jenv" ?
<rogpeppe> nesusvet: ah, hold on
<rogpeppe> nesusvet: what do you see if you do "env | grep SUDO" ?
<nesusvet> SUDO_USER=nesusvet
<nesusvet> SUDO_UID=1000
<nesusvet> SUDO_COMMAND=/bin/su allods
<nesusvet> SUDO_GID=1000
<rogpeppe> ah ha!
<rogpeppe> i thought so
<rogpeppe> right
<rogpeppe> that's a bug in our code
<rogpeppe> nesusvet: for the time being there's an easy workaround
<rogpeppe> nesusvet: export SUDO_UID=""
<rogpeppe> nesusvet: it's strange that your "echo $SUDO_USER" printed nothing, BTW
<marcoceppi> rogpeppe: interesting, is this if someone does a sudo su - <user> ?
<nesusvet> So, what should I do next? )
<rogpeppe> nesusvet: i will propose a fix
<nesusvet> (handshake)
<rogpeppe> nesusvet: do what i said - that will cause your bootstrap to work ok
<marcoceppi> thanks rogpeppe!
<rogpeppe> marcoceppi: yes
<nesusvet> Yeah, thanks you very much )
<rogpeppe> marcoceppi: we are assuming that if SUDO_UID is set then the effective user id is root
<rogpeppe> marcoceppi: it's actually a nasty hack caused by the fact that the local provider needs to run as root
<marcoceppi> ah, instead of trying to use that value?
<rogpeppe> marcoceppi: it should check the euid
<rogpeppe> marcoceppi: the whole situation is unfortunate - we shouldn't need to run as root, but it's not easy because lxc requires root.
<nesusvet> rogpeppe, I did chown allods.allods ....
<nesusvet> but still can the same
<rogpeppe> nesusvet: yeah, that's not the problem i'm afraid
<nesusvet> juju bootstrap
<nesusvet> ERROR environment has no bootstrap configuration data
<rogpeppe> nesusvet: the problem is that juju is trying to do the equivalent of: chown nesusvet.nesusvet my.jenv
<rogpeppe> nesusvet: ah, yes, sorry, you'll need to remove the .jenv file
<rogpeppe> nesusvet: or run juju destroy-environment my
<nesusvet> I sshed under allods and everything works fine )
<nesusvet> so there is a reason definitely
<nesusvet> in sudo
<rogpeppe> nesusvet: cool
<gnuoy> hi, I've just used maas to deploy the boostrap node with bonded nics. However, I see no sign of juju on the server. Mongo startsup if I start it manually but ENABLE_MONGODB=no is set in /etc/default/mongodb
<gnuoy> Where should I look next to figure out whats happened /
<gnuoy> ?
<gnuoy> I see these: git lxc mongodb-server
<gnuoy> installed
<gnuoy> and no package seems to be in an error state from dpkgs point of view
<gnuoy> the dir /var/log/juju is empty
<marcoceppi> gnuoy: what does sudo initctl list | grep juju show?
<gnuoy> nothing
<gnuoy> marcoceppi, it looks like /var/log/juju is the only sign of juju. I see no juju package
<marcoceppi> gnuoy: you won't see a juju package, juju doesn't get install from the archives
<gnuoy> ah, ok
<marcoceppi> gnuoy: if there are no upstart jobs, then something went wrong durint the setup. Check the output of /var/log/cloud-init
<marcoceppi> (I think that's where the file is)
<gnuoy> marcoceppi, thanks, looks like a dns problem https://pastebin.canonical.com/100172/
<gnuoy> marcoceppi, ta, I'll have a dig around
<marcoceppi> gnuoy: it looks like it's trying to find the maas server to download the juju tools, and failing
<gnuoy> marcoceppi, yep, an empty resolv.conf probably isn't helping.
<nesusvet> It seems I have a new issue. After bootstrapping server was unable to deploy successfully
<nesusvet> Target server could't connect to mongoDB
<nesusvet> and now I don't know what to do next.
<marcoceppi> nesusvet: so you were able to bootstrap without issue?
<nesusvet> yes
<marcoceppi> nesusvet: can you descrive what you've done from bootstrapping to getting the error?
<nesusvet> but the target machine shown a lot of spam that could't connect to localhost
<nesusvet> 2013-11-08 15:50:47 DEBUG juju.state open.go:88 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<marcoceppi> nesusvet: what does your environments.yaml stanza for "my" environment look like?
<nesusvet> http://pastebin.com/CwGjuaCG
<marcoceppi> nesusvet: what is GPT-bart-IM?
<nesusvet> is target host
<nesusvet> on which I should install agent
<nesusvet> manually
<marcoceppi> nesusvet: is it your machine? Does that address actually resolve on your machine if you type `dig GPT-bart-IM`?
<nesusvet> Yes, I can ping it
<nesusvet> it's localhost
<nesusvet> I mean I added this name into the /etc/hosts file on both servers
<marcoceppi> nesusvet: you shouldn't use your local machine as the bootstrap node
<nesusvet> No, it's not local machine, it's target standalone server
<nesusvet> ping GPT-bart-IM
<nesusvet> PING GPT-bart-IM (192.168.206.63) 56(84) bytes of dat
<marcoceppi> nesusvet: where are you running these juju commands? From your desktop or that server?
<nesusvet> from server, the server hostname is GPT-base
<marcoceppi> nesusvet: you shouldn't be running the juju commands from the nodes you indend to use. You should be running the juju commands from your computer
<nesusvet> ohh.
<nesusvet> so what should I do with server which has been deployed incorrectly
<marcoceppi> nesusvet: uninstall juju-core, run `sudo initctl list | grep juju- | awk '{system("sudo stop " $1)}'; sudo rm -f /etc/init/juju*`
<nesusvet> thanks
<nesusvet> I will
<rogpeppe> nesusvet, marcoceppi: could one of you please report the above problem as a bug, so i can refer to it when i'm proposing my fix?
<marcoceppi> rogpeppe: ack
<rogpeppe> marcoceppi: ta!
<nesusvet> here On the lunchepad?
<marcoceppi> nesusvet: I'll create one on launchpad with the details from above
<nesusvet> Please describe the bug in a few words, for example, "weather applet crashes on logout":
<nesusvet> "JuJu bootstrap doesn't work under sudo environment" is it ok?
<marcoceppi> nesusvet: Yup, that'll work
<nesusvet> https://bugs.launchpad.net/juju-core/+bug/1249418 here is
<_mup_> Bug #1249418: JuJu bootstrap doesn't work under sudo environment <juju-core:New> <https://launchpad.net/bugs/1249418>
<jcastro> http://askubuntu.com/questions/373161/juju-boostrap-for-ec2-fails-with-access-denied-but-working-credentials
<jcastro> I wonder if this is one of those env file issues again
<marcoceppi> jcastro: maybe
<mbruzek> Hello juju community I have a question, hope this is the right place.  I have a Java WAR file that I want to add to a charm.  Would the best practice be to copy the Tomcat charm and just add this WAR file to the appropriate directory thus making a new charm.  Or is it best practice to install the Tomcat charm and somehow use the WAR in a different charm.
<mbruzek> I guess I don't know if that last option is possible, and looking for a little help.
<jcastro> It'd be cool to add a config option to the tomcat charm to allow you to bundle WARs
<jcastro> either via URL or in a war/ directory or something
<jcastro> but if you want quick and dirty fork the tomcat charm and just embed the WAR file
<mbruzek> Thank you jcastro
<mbruzek> Each charm runs in its own server/container/instance right?
<mbruzek> So making a tomcat charm point at a different WAR charm would not work?
<marcoceppi> mbruzek: So there are several things you could do
<mbruzek> marcoceppi, Which one would you suggest?
<marcoceppi> mbruzek: internet is a little flakey, one min
<marcoceppi> mbruzek: So, one option would be to create a configuration option, like "war_location" which would be an address that people could configure. Another, more interesting option, would be to create a tomcat-war subordinate charm. Subordinates are charms that don't get deployed as standalone, but instead get attached to existing deployed services. So what you could theoretically do, is juju deploy tomcat; juju deploy tomcat-war my-war-service; juju
<marcoceppi> add-relation tomcat my-war-service
<marcoceppi> in doing so, you could have multiple WARs deployed to a single tomcat server, which I feel like is something that's done in practice already
<mbruzek> Can charms read each other's file systems?
<marcoceppi> then the generic tomcat-war charm would have a few configuration options, like "war_location", "path", "service_name", whatever would make sense for needing to deploy a war
<marcoceppi> mbruzek: yes and no. A subordinate charm can, because it's deployed alongside that service it's attached to
<marcoceppi> so tomcat-war as a subordinate, could read/modify anything the tomcat charm would because subordinates are co-located on the same server
<mbruzek> a subordinate charm can, but can the master charm read the subordinate's ?
<arosales> mbarnett, hello welcome here
<marcoceppi> mbruzek: yes, they're both on the same system. You tell juju where to "deploy" the subordinate via the add-relation command, as such no only are the on the same system but they also have an established relation to each other which they can use to communicate
<arosales> mbruzek, https://juju.ubuntu.com/docs/authors-subordinate-services.html
<marcoceppi> mbruzek: the only real seperation you have with a suboridinate and a regular service, is they each have a different $CHARM_DIR
<mbruzek> OK
<arosales> mbruzek, subordinates do require some thought to get your mind wrapped around
<mbruzek> _charms_ themselves have taken me some thought to wrap my head around.
<arosales> mbruzek, :-)
 * arosales thinks of sub example ...
<arosales> rsyslog may be a good example
<arosales> http://manage.jujucharms.com/charms/precise/rsyslog-forwarder is the sub in this case
<marcoceppi> there are no good examples, only zuul
<arosales> marcoceppi, your thoughts on rsyslog-forwarder?
<marcoceppi> arosales: aside from the fact that, iirc, it's broken?
<marcoceppi> mbruzek: here's a list of all the subordinates in the charm store: https://manage.jujucharms.com/charms/precise?sub=1
<marcoceppi> a simple one, like ntp or unattended-upgrades, might give you a better idea of their purpose
<mbruzek> thanks marcoceppi
<arosales> marcoceppi, I haven't deployed it lately, just recall it being a sub
<arosales> marcoceppi, mainly looking for a code example on subs
<marcoceppi> arosales: mm, but if you try to deploy, at least if I recall what kirkland said, it doesn't actually work
<kirkland> marcoceppi: deploy what?
<arosales> rsyslog-forwarder
<marcoceppi> kirkland: rsyslog/rsyslog-forwarder. IIRC a month or two ago you trued and it failed to work properly
<arosales> marcoceppi, I trust you :-)
<arosales> just the one I remember off hand
<kirkland> marcoceppi: ah, yeah, failed
<arosales> marcoceppi, your link to the list of subs is much better to look at code examples
<marcoceppi> arosales: :) trying to remember if it was actually broken. We should file some bugs aginst it and fix it. Or something ;)
<marcoceppi> hum, this is one clint was maintaining, so it's maintainerless as well
 * arosales was just looking for a bug on it
<arosales> https://bugs.launchpad.net/charms/+bug/1078147 had a merge request from a while ago
<_mup_> Bug #1078147: rsyslog and rsyslog-forwarder charm review/merge <canonical-webops-juju> <Juju Charms Collection:New> <https://launchpad.net/bugs/1078147>
 * marcoceppi facepalm. Both are marked as needs fixing, but it looks like both were updated recently
<marcoceppi> arosales: they need to have ~charmers re-assigned to them for a review in order to show up in the queue again. We need to make that policy when communicating to people who need to fix their merges
<arosales> that and be a non "closed" state
<marcoceppi> Haw even made himself a maintainer of the charm
<marcoceppi> arosales: well, the merge requests are what matter, we don't see the bugs
<marcoceppi> arosales: https://code.launchpad.net/~hloeung/charms/precise/rsyslog/trunk/+merge/134024
<arosales> good point
<marcoceppi> If it's not assigned to charmers for review we effectively don't know about it
<arosales> yup
<marcoceppi> arosales: what might be a better course of action is. After a charmer reviews it, they move the merge proposal from "Ready for review" to "In Progress", then re-assign charmers. That way the author only needs to move it to ready to review and not mess with assiging it again
 * marcoceppi makes task to talk about review process on the list
<marcoceppi> arosales: do you see two "bip" charms on this page? https://manage.jujucharms.com/charms/precise
<arosales> stays on our radar then
 * arosales looks
<arosales> marcoceppi, I do, one looks blank
<arosales> same with bonne
<arosales> same url end point
 * marcoceppi files bug
<arosales> marcoceppi, thanks thas a juju-gui bug in charm world
<arosales> sinzui, ^ fyi
<arosales> sinzui, sorry I think the juju-gui maintains that code now
<arosales> juju-gui team
<marcoceppi> https://bugs.launchpad.net/charmworld/+bug/1249496
<_mup_> Bug #1249496: Charms listed multiple times <charmworld:New> <https://launchpad.net/bugs/1249496>
<sinzui> arosales, We are in that code too to support the charmers. The gui team added versioned charms recently, and that has caused problems for code that thinks there is only one version of each charm
<arosales> sinzui, thanks for the info and marcoceppi thanks for the filing the bug
<arosales> and bonnie just needs a readme, ugh
<marcoceppi> arosales: the impending audit should resolve that
 * marcoceppi piles on more tasks
 * arosales files bug  for bonnie
<arosales> sinzui, on a different not mbruzek also ran into https://bugs.launchpad.net/juju-core/+bug/1202682
<_mup_> Bug #1202682: debug-log doesn't work with lxc provider <cts-cloud-review> <debug-log> <local-provider> <papercut> <ssh> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1202682>
<mbruzek> I found the bug on launchpad, and asked if there was a way around it
<mbruzek> No known workarounds?
<arosales> not that I see
<marcoceppi> mbruzek arosales: yes
<marcoceppi> mbruzek: all local logs are in ~/.juju/local/log
<mbruzek> ahh.
<marcoceppi> mbruzek: they're loopback mounted in to the containers
<marcoceppi> mbruzek: arosales: the only two commands that dont' work with local right now are juju debug-log (see above) and juju ssh <machine-number> the latter can be solved with juju ssh <unit> though
 * marcoceppi doesn't like debug-log that much anyways; too much information
<marcoceppi> mbruzek: you'll be interested in the log files prefixed with unit-
<arosales> marcoceppi, ah interesting
<arosales> I saw stokachu also commented on 'juju debug-log' not working with some attempts to workaround the problem
<marcoceppi> arosales: posted a comment to that bug with the workaround
<marcoceppi> arosales: this and juju ssh need to be documented on the local provider page asap if it isn't already
 * marcoceppi thought it was
<arosales> marcoceppi, thanks for https://bugs.launchpad.net/juju-core/+bug/1202682/comments/5
<_mup_> Bug #1202682: debug-log doesn't work with lxc provider <cts-cloud-review> <debug-log> <local-provider> <papercut> <ssh> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1202682>
<mbruzek> marcoceppi, Thanks for your help today I can see the log files now.
<marcoceppi> \o/
<marcoceppi> mbruzek: thanks for reminding me that still exists, I'm updating the docs to reflect these caveats
<mbruzek> I am sorry if that added anything to your task list
<arosales> marcoceppi, feel free to also log a quick bug in juju-core and tag it with "docs" so we can follow up on it later too
<marcoceppi> mbruzek: worse things have happened
<marcoceppi> arosales: ack
<marcoceppi> going to finish logging these other bugs
<arosales> marcoceppi, thanks
<jason955> So, I've been browsing the charms lately and it looks like a lot of charms use a VCS (git, bzr, svn, etc).  When I have been designing charms, I like to pull from a VCS and I prefer Git.  I realize that the charms I want to use don't have a Git options.  Also the charms I make, I only offer Git.
<jason955> So my thinking is that it would be nice to create a VCS relationship that allow a service create a subordinate VCS charm, which pulls from a repository and updates it.  The parent charm can just expose a folder to pull to.  I really think this would help with the modularity of the charms.
<jason955> Take for example the LAMP charm.  It only uses Bzr for its repo.  What if it just required a VCS charm, that way I can use whatever I want (git, bzr, svn, ftp, http, S3, etc). Is there anything like this already?  What do you think about this?
<marcoceppi> o/ jason955 I just replied to your mailing list post, didn't see the messages here
<jason955> got it.  Thanks Marco
#juju 2013-11-09
<glyn> Hello. I just tried to install the charm tools on Mac OS X (Mavericks) via homebrew as per https://juju.ubuntu.com/docs/tools-charm-tools.html. I am using the latest version of homebrew and it is up to date. brew install juju gives me juju version 1.16.2-unknown-amd64, but this doesn't provide the charm subcommand., i.e. juju charm does not work (it gives "ERROR unrecognized command: juju charm"). I tried brew install charm-tools but this
<glyn> juju charm now gives "Traceback (most recent call last):   File "/usr/local/bin/juju-charm", line 5, in <module>     from pkg_resources import load_entry_point ImportError: No module named pkg_resources ERROR exit status 1"
<glyn> I just wanted to (a) point this out so the docs can be corrected and (b) see if anyone here knew how to fix the problem (assuming the docs are simply out of date).
<glyn> I guess it's a bad time, especially in the US. I'll come back later to see if anyone was around.
<glyn> Giving up. Some other time...
<hazmat> jcastro, marcoceppi a github mp.. https://github.com/charms/joomla/pull/1
<marcoceppi> hazmat: omg!
<marcoceppi> IT'S HAPPENING
 * marcoceppi reviews
<hazmat> marcoceppi, :-) cool. i'm going to have some meetings next week on some foundational work items on the road to proper gh support.
<hazmat> marcoceppi, did you see glynn's error report for charm tools on osx?
<hazmat> er. glyn
<marcoceppi> hazmat: yeah, it's too bad he's not on I would have told hiim to use pip for the time being
<marcoceppi> hazmat: it's a known issue that we broke brew
<marcoceppi> and that we're broken in brew
<hazmat> marcoceppi, we ?
<marcoceppi> hazmat: the royal we, charm-tools
<marcoceppi> aka me
<marcoceppi> :(
<hazmat> marcoceppi, if it works in virtualenv / pip.. i'd suggest we == homebrew
<hazmat> well that the issue lies there
<hazmat> or the brew def thingy
<marcoceppi> hazmat: it does, the formula isn't properly setup to work in brew
<hazmat> gotcha
<marcoceppi> hazmat: https://github.com/mxcl/homebrew/issues/23378#issuecomment-26665565
<Azendale> what is the normal way of dealing with charm helpers and revision control? Should I ignore the charm helpers folder? Include it?
<marcoceppi> Azendale: include it, it's ignored during reviews. Soon charm-helpers will be available via a debian package and you won't need to embed anymore
<Azendale> marcoceppi: Ok, thanks
<Azendale> marcoceppi: Trying my hand at creating an ejabberd charm, we'll see how far I get. The config file is in yaml though, so that part should be easy
<marcoceppi> Azendale: awesome! let me know if you have any questions
<Azendale> marcoceppi: Is it safe to assume python3 on this? Or do I need to either install python3 or just use python 2.x?
<marcoceppi> Azendale: it depends on the series the charm is targeted to. If you target the charm at the trusty series, then python3 will be installed by default, with precise, you'll need to install it
<marcoceppi> Azendale: it's safe to just not make any assumptions
<Azendale> marcoceppi: what about saucy?
<marcoceppi> Azendale: we don't recommend you target charms at non-LTS series
<marcoceppi> Azendale: However, I'm not 100% sure of the saucy python status, to be safe just be explicit in your install hook for dpendencies
<Azendale> marcoceppi: So, the hooks get everything from environment variables, not anything passed to them, right? I'm just thinking if I do a script that installs python3 and then calls a python3 file, do I need to pass anything on?
<marcoceppi> Azendale: it's all environment variables, you should be fine to do that (lots of charms do)
#juju 2013-11-10
<marcoceppi> Azendale: finally, your review is up!
<Azendale> marcoceppi: Awesome! :)
<marcoceppi> Azendale: thanks for the fix!
<Azendale> marcoceppi: You're welcome. Thanks for taking the time to walk me through the process
<marcoceppi> Azendale: any time! feel free to patch any other issues you come across ;) (or at least file a bug about it)
#juju 2014-11-03
<blahdeblah> Hi folks, I'm running "charm proof" against a charm I've been writing trying to learn it, and it's complaining "I: all charms should provide at least one thing"
<blahdeblah> Why is this so?  If the charm is basically just a single client-facing service does it really need any relations?
<lazyWeekend> blahdeblah: you can ignore I: prefixed warnings
<lazyWeekend> blahdeblah: the only warnings you *need* to fix are Warns and Errors. Info is just FYI - and no, its completely acceptable for a charm to be 100% stand alone.
<blahdeblah> lazyWeekend: OK - thanks
<bradm> I'm running some charm tests and its failing, but I can't reproduce it outside of the tests - how do I tell it to not tear down the env after running the tests?
<bradm> oh, cleanup=False, fine.
<jcastro> jose, ping
<lazyPower> marcoceppi, mbruzek, Tribaal, dpb1, niedbalski -   I'm in the hot seat for a demo fix - can i get a quick review on https://code.launchpad.net/~lazypower/charms/trusty/hdp-hadoop/amir_hpcloud/+merge/240483?
<dpb1> lazyPower: why all the unrelated changes in there?  'start_NM' -> 'start_nm', etc?
<dpb1> 'start_datanode' -> 'start_dn' ??
<lazyPower> dpb1: This was a fix by asanjar that lives in his personal namespace - i think he's normalizing his method signatures as combining camel case with underscores was "obnoxious" as put by 3rd party reviewers.
<lazyPower> i pulled this in and verified it works on hpcloud, testing amazon now
<dpb1> lazyPower: well... in the case of datanode, it's actually decreasing readability... and in any case, for an emergency fix seems like those should be stripped out?
<lazyPower> dpb1: ack, i'll cherrypick changes and give this another go
<lazyPower> thanks for taking a look dpb1
<dpb1> lazyPower: yes, if you get a reduced version, I'll peek again
<lazyPower> dpb1: https://code.launchpad.net/~lazypower/charms/trusty/hdp-hadoop/asanjar_hpcloud_cleanup/+merge/240487
<lazyPower> dpb1: looks like my editor had fun reformatting :( cant win for losing today
<dpb1> yowzer
<dpb1> :)
<sarnold> removing trailing spaces is almost always a good thing :)
<sarnold> .. never letting them sneak in is the better thing, of course
<lazyPower> ATOM's python language lint/bindings is pretty stellar I have to admit.
<lazyPower> and its consistent
<ayr-ton> http://askubuntu.com/questions/540209/ip-domainname-of-juju-master-or-slaves-changes ;x
<aisrael> lazyPower: +1 to that.
<lazyPower> aisrael: review or ATOM comment?
<aisrael> lazyPower: ATOM, sorry.
<lazyPower> all good - just beating the drum :)
<jrwren> can anyone point me to docs for how to use the storage charm with mongodb charm?
<tvansteenburgh> jrwren: i just happened to glance at https://code.launchpad.net/~evarlast/charms/trusty/mongodb/trunk/+merge/240376 and noticed there are merge markers in the diff
<jrwren> tvansteenburgh: no idea where that came from. I didn't commit that code.
<jrwren> or I did, and I didn't mean to. Its been 5yrs since I used bzr much.
<lazyPower> jrwren: i'd charm get cs:trusty/mongodb - reapply your patches to it, and resubmit.  somewhere along the lines a dirty merge happened on your local branch.
<jrwren> is this some known launchpad thing?
<jrwren> fwiw, I just confirmed that some of that code is not in my branch or the charm in charmstore.
<jrwren> can anyone suggest how I may use bzr correctly so taht this doesn't happen again?
<jrwren> does bzr have equivalent of git push -f ?
<jrwren> on github, I'd simply git push -f and the PR would be updated. How do I do this with LP and this MR?
<mgz> jrwren: you just push... there's no need for --force, lp updates
<mgz> jrwren: you probably just need to merge trunk into your branch and resolve the conflicts
<jrwren> i don't want to merge. I want to push force.
<jrwren> the whole point is that I have my tree exactly how I want, and I own the remote true. How do I get the remote to be exactly what I have local?
<jrwren> or is there a magic merge option that says "ignore all remote" ?
<rick_h_> jrwren: no, I don't think you can do that
<mgz> there's nothing wrong with your branch
<rick_h_> jrwren: bzr is safe safe safe
<mgz> launchpad is just telling you your branhc conflicts with later changes on trunk
<mgz> in order to land your branch, you need to resolve them
<mgz> jrwren: to be clear - your branhc does not have merge markers in it. it's just diverged from trunk of what you're merging into.
<jrwren> mgz: I don't know what that means. Pretend I've never used bzr and I only know git words, because that is how fried my brain is right now ;)
<jrwren> i'm just going to push to a new branch.
<tvansteenburgh> jrwren: in your local charm dir do `bzr merge https://code.launchpad.net/~charmers/charms/trusty/mongodb/trunk`, resolve any conflicts, then commit and push back to https://code.launchpad.net/~evarlast/charms/trusty/mongodb/trunk
<jrwren> that "resolve any conflicts" step is too much friction for me.
<tvansteenburgh> gah, thhose links were supposed to be lp: links
<mgz> what you said still works though :)
<jrwren> i did figure out how to update the MR with the new branch.  YAY!
<jrwren> https://code.launchpad.net/~evarlast/charms/trusty/mongodb/i-do-not-know-how-to-use-bzr-so-i-pushed-here/+merge/240499   oh, it doesn't really update it.  new url and everything.
<jose> jcastro: pong
<lazyPower> jrwren: heh, nice branch name
<lazyPower> jrwren: much cleaner, thanks for the cleanup
<jcastro> jose, heya, is there a reason you didn't push owncloud to trusty? Was just wondering
<jose> jcastro: yeah, as I said some tests were giving a weird error and I need to take a look. and the apache2 file structure has changed
<jose> jcastro: minor changes and I'll open a bug. will deal with them tonight as I have classes in 30m
 * jcastro nods
<jcastro> I was just wondering, not implying that you needed to fix it!
<jose> I'm fully back to charming, sorry if I've been absent but exams + flu
<jose> hey, it needs to be on trusty asap!
<jcastro> I think it's a point release behind too?
<jose> not actually, you can specify and install any release.
<jcastro> oh ok, woo!
<jose> need to check the default again to make sure it's updated to the latest rev
<jose> but expect something today
 * skay waves to roadmr
<roadmr> skay: hows the jujuing going?
<skay> roadmr: am trying to figure out why the charm I am working on is using a fork of python-django instead of python-django
<skay> roadmr: and so on. okay I guess
<roadmr> skay: oh! yes, I remember it using a fork...
<skay> roadmr: I haven't looked through everything yet, but perhaps when someone made the fork python-django didn't support installing tarballs? maybe?
<skay> roadmr: if I get good at this I think I'll reuse my knowledge to make a juju charm for pyvideo.org
<roadmr> that'd kick ass :)
<skay> roadmr: I have run through fabric on it, experimented with ansible, ... and might as well see how this goes
<skay> looks like the python-django maintainers are experimenting with supporting ansible and fabric (perhaps other things)
<lazyPower> skay: the python-django charm maintainer is actually in progress of moving it to a python only charm using charmhelpers
<skay> lazyPower: yes, I think I saw that. and the fork my project is using is from before that.
<lazyPower> skay: as it stands today they are still deploying the ansible charm as thats whats in teh store - but the pure python branch should be landing soon
<lazyPower> last time i looked at it was a little over 3 weeks ago - but its in the queue
<themonk> lazyPower, hi
<lazyPower> o/ themonk
<themonk> I am facing a problem
<themonk> i deployed my charm in amazon
<themonk> but in charm when i get unit puclic address it gives me aws instamce private address
<lazyPower> themonk: you're looking for the IP Address of the unit correct?
<themonk> yes and i use this "unit-get public-address"
<lazyPower> themonk: there's a few ways you can work around this behavior - there have been bugs filed against this in the past, but this is apparently expected behavior from juju - favor the FQDN of the unit vs the ip address.  one method is to dig +short the hostname but this fails gloriously in some environments.
<lazyPower> marcoceppi: do you recall the helper we came up with to resolve EC2 ips?
<lazyPower> themonk: wait, i think i just glossed over something. you got the private address back from unit-get public-address?
<ezobn> Hi All. Do any methods exist to retry juju upgrade-juju to the environment, in case of some nodes have not upgraded their juju agents. So I have now some agents previous version
<lazyPower> themonk: have a look at this paste - try running a similar juju-run command for me and pastebin the output: http://paste.ubuntu.com/8808757/
<themonk> lazyPower, bacicaly 'unit-get public-address' and 'unit-get private-address' gives same ip
<ezobn> May be I can manually try to upgrade somehow those agents ? If any methods exist  ...
<themonk> lazyPower, http://paste.ubuntu.com/8808837/
<lazyPower> themonk: what juju version?
<themonk> lazyPower, 1.20.11-trusty-amd64
<lazyPower> interesting, i'm running the same juju version and I get FQDN not IP's
<lazyPower> interesting
<lazyPower> themonk: i'm not sure what to say to that... what AZ are you in?
<themonk> lazyPower, US East (N. Virginia)
<lazyPower> themonk: do you have a floating ip attached to the instance? an EIP?
<themonk> lazyPower, what is floating ip? where do i look in ec2 dashboard?
<lazyPower> themonk: ElasticIP's are typically attached to a unit in the EC2 dashboard under "elastic ip" - you'll see the IP and an instance ID next to it if it's assigned.
<lazyPower> thats teh last thought I had is if you attached an EIP and it was somehow overriding the networking on the machine to point @ that EIP
<lazyPower> ezobn: hey there sorry about the delay, the only thing i've found is upgrade-juju - which upgrades the tools in the env.  The units themselves should upgrade (i think) at some point during the agents lifecycle checkins.
<lazyPower> working on getting a definitive answer for you
<themonk> lazyPower, no i do not have EIP, its showing blank
<lazyPower> themonk: i haven't seen that behavior out of amazon before, it seems really strange to me that a) its returning the IP, and b) its the same IP on both pub and private addressing.
<lazyPower> *out of juju on amazon
<lazyPower> themonk: i would recommend a ping to the juju@lists.ubuntu.com or a question on ask ubuntu tagged juju - and crowd source a possible answer.
<ezobn> lazyPower: Hi, not a problem. Thanks for the answer. But they are in this state already more then a day ... so I think something wrong happened ...
<themonk> lazyPower, if juju is written in python, may be i can look into the source now :)
<lazyPower> themonk: old juju was, after 1.14 it was ported to go
<themonk> lazyPower, yes
<lazyPower>  if you juju upgrade-juju --version 1.20.11, does that have any effect over the straggler agents?
<lazyPower> ezobn: ^
<lazyPower> ezobn: and feel free to substitute --version with the point release you were trying to build and upgrade your environment to
<themonk> lazyPower, what do you think is this a bug?
<lazyPower> themonk: seems like it might be, or a corner case. Do all you runits deployed in AWS exhibit the same behavior?
<ezobn> lazyPower: no - says "no upgrade available"
<ezobn> lazyPower: even when --version
<lazyPower> ezobn: thats unfortunate - can you file a bug against juju-core for the units not upgrading? Be as detailed as you acn and it would probably help during triage to attach logs during the timeframe that you sent the upgrade command and ~ 20 minutes afterwords.
<lazyPower> themonk: I'm going to recommend you do the same, along with debug output of the juju-run commands i had you run earlier, instance constraints, and anything pertinent about your environment.
<themonk> lazyPower, yes its same for all instances
<lazyPower> themonk: Most definately a bug then. I'd file a bug https://launchpad.net/juju-core/+bugs
<themonk> lazyPower, will I file a bug or you?
<lazyPower> themonk: i dont have insight into your network - id' prefer you create it so you can track it and populate it with all the right info for your environment
<themonk> lazyPower, ok thanks :)
<lazyPower> themonk: ezobn: sorry you two ran into trouble, let me know if there's anything else i can potentially help with
<themonk> lazyPower, do you know anyone using juju with aws in production?
<lazyPower> themonk: our very own marcoceppi does, and i believe that omg ubuntu! is run on aws with juju as well - or was at one time. I'd need to follow up on that one
<ezobn> lazyPower: NP, will reinstall everything ;-) Thanks for make me sure that no yet any means to force the update.
<themonk> lazyPower, https://bugs.launchpad.net/juju-core/+bug/1389014
<mup> Bug #1389014: juju AWS EC2 "unit-get public-address" gives private address  <juju-core:New> <https://launchpad.net/bugs/1389014>
<themonk> lazyPower, take a look
<lazyPower> themonk: thanks, i'll ping in the dev channel with this and someone should update the bug soon
<lazyPower> themonk: anotehr thought - was your EC2 instance perhaps provisioned in a VPC?
<themonk> lazyPower, what is 'provisioned in a VPC' ?
<lazyPower> themonk: VPC networks are virtual private clusters - subnetted units out of the AWS public cloud space to add another layer of isolation on your services running on top of EC2
<themonk> lazyPower, all i do is give juju my access secret and using it
<lazyPower> ack.
<themonk> lazyPower, i dont think so
<themonk> lazyPower, i mean no VPC
<lazyPower> Ok, Just another possible reason it might be doing that
<lazyPower> themonk: what i'm getting back from core - executing this on the unit is basically how juju determines the unit ip
<lazyPower> curl http://169.254.169.254/latest/public-ipv4
<lazyPower> it polls the AWS metadata url to return the public address, AWS meta is responsible for all of the assignment
<davecheney> themonk: can you run curl http://169.254.169.254/latest/public-ipv4
<davecheney> on that machien that thinks it's private IP is it's public
<themonk> davecheney, i run it but getting a xml with 404
<themonk> davecheney, <title>404 - Not Found</title>
<davecheney> hmm
<davecheney> let me check again
<davecheney> i was reading that from the aws domcunebt
<davecheney> documentation
<lazyPower> curl http://169.254.169.254/latest/meta-data/
<lazyPower> davecheney: ^ i think thats what we were looking for right? http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
#juju 2014-11-04
<lazyPower> ah, i see they list public-ipv4 in there as well - an oversight on my part, disregard.
<davecheney> lazyPower: i couldn't figure it out
<davecheney> do you hack the url like I did
<davecheney> or lookup public-ip in the returned value
<davecheney> it's about as clear and infomrative as the rest of the aws documentation
<davecheney> technically correct, practically uselless
<lazyPower> hah, i'll +1 that sentiment
<lazyPower> davecheney: none of the subresources are resolving
<lazyPower> i'm getting 404's as well
<lazyPower> davecheney: wait, nailed it
<lazyPower> ip-10-188-28-170.us-west-1.compute.internalubuntu@ip-10-188-28-170:~$ curl http://169.254.169.254/latest/meta-data/public-ipv4
<lazyPower> 54.176.211.32
<lazyPower> themonk: ^
<davecheney> themonk: can you try on your host please
<themonk> lazyPower, davecheney , its working, Thanks :)
<davecheney> oh
<davecheney> it's working isn't the answer I was hoping for
<davecheney> that command wasn't supposed to fix anything
<davecheney> just give us more information about what had gone wrong
<lazyPower> davecheney: aws vooodooo
<lovea>  Following instructions at http://www.ubuntu.com/download/cloud/install-ubuntu-openstack. Have installed a Utopic 14.10 server. There is no ppa:cloud-installer/testing for Utopic! Do I a) re-install Trusy server for MAAS or b) use the TRusty ppa?
<lovea> with Utopic
<jose> jcastro: as promised, the bug is now there
<mbruzek> Question for the juju community.
<mbruzek> I am working on zookeeper, there does not appear to have a symbolic link for config-changed, but the main zookeeper-common file has a "config-changed" command (so it can handle config-changed calls).  How does juju call config-changed if there is no file?
<lazyPower> mbruzek: if there's no symlink, the hook context is not called - as juju looks for "config-changed" in the hooks directory
<lazyPower> its basically, immutable at that point.
<mbruzek> lazyPower the automated test result would disagree with that.
<mbruzek> http://reports.vapour.ws/charm-tests/charm-bundle-test-1415-results/charm/charm-testing-hp/2
<mbruzek> I am really confused, I would have thought if no config-changed link or file Juju would not call that.
<mbruzek> But I see it failed!
<lazyPower> mbruzek: without a file or symlink, it should just skip it.
<mbruzek> Yes I agree lazyPower
<mbruzek> I agree
<mbruzek> error details: hook failed: "config-changed"
<lazyPower> i see that but i think its a red herring, or a byproduct of something hinky going on in teh charm
<mbruzek> Correct I am looking into it.
<mbruzek> But I am confused at how config-changed can be called at all!
<lazyPower> yeah
<lazyPower> i pulled the charm local, kicked off bundletester and it ran fine
<lazyPower> i think its a byproduct of something going on in CI
<lazyPower> is it consistent?
<mbruzek> lazyPower: precise charm?
<lazyPower> mbruzek: trusty
<lazyPower> let me pull precise
 * mbruzek was unaware there is a trusty, the readme is crap
<lazyPower> mbruzek: charm get cs:trusty/zookeeper works
<lazyPower> mbruzek: http://manage.jujucharms.com/charms/trusty/zookeeper
<mbruzek> 2014/10/31 Charles Butler Removes a zero byte config-changed hook - will need to be revisted to address immutable config
<mbruzek> lazyPower: I am only working on this because it is failing automated tests and marcoceppi commented about that on my bug.
<lazyPower> mbruzek: well it wasn't a file
<lazyPower> someone did "touch config-changed"
<mbruzek> ack
<lazyPower> ln -s config-changed should resolve that
<lazyPower> i was moving pretty quick
<mbruzek> lazyPower: I am fixing this and will add that back in, bundletester fails on my machine because my lxc containers are out of date, so I think we need apt-get update
<lazyPower> mbruzek: i do that every morning :)
<mbruzek> in the charm
<mbruzek> the bundletester fails the zookeeper on install hook
<lazyPower> oh, i've just relegated to updating my containers manually because thumper hates us
<marcoceppi> mbruzek: someone updated zookeper already
<mbruzek> marcoceppi: Yeah but the automated tests fail on my system today.
<marcoceppi> it was updated today
<mbruzek> oh?
<marcoceppi> around 8:12am
<mbruzek> hrmmm...
<marcoceppi> make sure your trusty branch is sync'd with this fix
<mbruzek> Will do thanks, for telling me Marco
<mbruzek> marcoceppi: it is still missing the config-changed symbolic link I think it needs that
<mbruzek> testing my changes now.
<marcoceppi> https://code.launchpad.net/~robert-ayres/charms/precise/zookeeper/fix-symlink/+merge/239736
<mbruzek> marcoceppi: I *just* pulled trusty zookeeper and it does not have this fix
<mbruzek> This MP is for precise
<marcoceppi> look at the MP
<marcoceppi> exactly
<marcoceppi> its a fix for precise
<marcoceppi> zookeeper doesn't exist for trusty yet
<marcoceppi> you submitted the branch for it
<marcoceppi> you need to copy this change over
<marcoceppi> should just be able to bzr merge that branch
<mbruzek> I am going to add apt-get update because I think that is what is failing on my lxc with bundletester this morning.
<wojtyla> Hi to all. Could i ask anybody here for help with http://askubuntu.com/questions/545656/different-nova-conf-on-each-compute-node-for-novnc-acccess ?
<jose> aisrael: about tracks and limesurvey, I'm gonna try and see if there are any equivalents available for install. have you already made progress on those but saw yourself blocked? just so I can make an MP against that branch
<aisrael> jose: Thanks. I haven't done anything else with those two other than file bugs.
<jose> aisrael: cool, wil take a look asap! :)
<jose> hey guys, I'm wondering if any of you is willing to do a demo of Juju on POWER8 at UOS?
<marcoceppi> mbruzek: ?^
<mbruzek> I am not going to be at UOS
<rick_h_> sounds like randall's gig :)
<jose> it can actually be anything
<lazyPower> rick_h_: i second that *touches his nose*
<mbruzek> rick_h_: I have been doing all the testing on power
<rick_h_> mbruzek: :) rock on
<jose> probably an announcement about "what's new on the GUI", showcasing everything you can do on the gui
<jose> rick_h_: ^
<noodles775> tvansteenburgh: Hi there, any update on the charm testing? (I can manually test on ec2, verified one yesterday, but am still keen to see the full test with ec2, hp etc.)
<tvansteenburgh> noodles775: i got a little side-tracked hunting down other testing-related bugs. revisiting your branch is next on my list. can you link me the branch or MP again please?
<marcoceppi> mbruzek: UOS is virtual
<mbruzek> Yeah well then I _could_ do a demo
<tvansteenburgh> noodles775: this one right? https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/use-new-charmhelpers/+merge/239935
<tvansteenburgh> noodles775: or was it the firewall_optional branch?
<noodles775> tvansteenburgh: the firewall_optional branch would be great (it builds on the previous one to add another feature requested). Thanks.
<tvansteenburgh> noodles775: got it, thanks
<jose> aisrael: not sure if the tracks charm will be available for trusty, the PPA I was using to set up a newer version of Ruby hasn't got some of the packages for trusty
<aisrael> jose: That's what I was afraid of.
<jose> aisrael: not sure if the tracks charm will be available for trusty, the PPA I was using to set up a newer version of Ruby hasn't got some of the packages for trusty
<jose> will probably have to wait and see if they repackage it
<jose> now, for limesurvey, it appears there's a fix, but lemme double check
<tvansteenburgh> jrwren, you around?
<jrwren> yes
<tvansteenburgh> jrwren: question about the s/public-address/private-address/ change to mongodb
<jrwren> tvansteenburgh: yes
<tvansteenburgh> so this will broadcast mongodb's private-address to all related units
<jrwren> tvansteenburgh: I guess.
<lazyPower> jrwren: love the confidence
<jrwren> tvansteenburgh: I am not certain what you mean by broadcast, hence my guessing.
<tvansteenburgh> well that wasn't really a question
<tvansteenburgh> it will relation-set hostname=private-address
<jrwren> yes.
<tvansteenburgh> ok
<tvansteenburgh> i suppose that address would always be reachable from other units in the deployment so it's okay
<tvansteenburgh> just wanted to double-check with you and think about it some more
<jrwren> tvansteenburgh: and since the other address is never reachable from other units in teh deployment, unless the port is exposed with expose, its better.
<tvansteenburgh> it actually broke a test, so i'm trying to confirm that the test can be changed, and it's not a legit regression
<jrwren> I've no idea why a public-address would ever be used for relating charms.
<jrwren> but I only know ec2 and azure.
<tvansteenburgh> it would be necessary for cross-cloud deployments, but i have no idea whether we'll ever do that
<sebas5384> ping balloons
<sebas5384> o/
<jrwren> juju supports cross cloud deployment?
<tvansteenburgh> haha, no
<sebas5384> jrwren: that would it be crazy
<jrwren> you had me very interested for a second :)
<sebas5384> hehe
<jrwren> sebas5384: it would? why crazy?
<sebas5384> is like multi universes
<tvansteenburgh> i was just giving you a hypothetical reason why you'd need to relation-set public-address instead of private
<sebas5384> but yeah, i think the need exist
<tvansteenburgh> jrwren: thanks, i'll update the test
<jrwren> tvansteenburgh: thank you.
<jrwren> tvansteenburgh: for my future reference, was it an ansible test?
<tvansteenburgh> jrwren: no, amulet
<jrwren> tvansteenburgh: ha! I meant amulet. great, ty. I need to run those next time :)
<lazyPower> hey sebas5384 o/
<lazyPower> jrwren: it does if you're using the manual provider
<sebas5384> hey lazyPower !
<lazyPower> sebas5384: hows things my friend?
<jrwren> lazyPower: it might work,but does it make sense.
<sebas5384> lazyPower: been good, I went to bolivia to attend a DrupalCamp
<jrwren> does unit-get("private-address") return the same as public-address if the cloud on which it is running doesn't split public/private addresses?
<sebas5384> I showed Ansible and Juju, and how a charm works
<lazyPower> jrwren: depends on what you're doing and how much you care about latency inbetween services
<sebas5384> lazyPower: they love it
<lazyPower> sebas5384: thats great to hear!
<sebas5384> yeah
<lazyPower> have you gents gotten un-blocked with your integration testingi story? i haven't looked @ the repo in a while
<jrwren> lazyPower: lol... and how the cloud services does network billing :p
<sebas5384> Juju us getting known :)
<lazyPower> sebas5384: i hear ya, i just got invited to give a talk at a pretty significant meetup here in pittsburgh over juju :)
<sebas5384> nice! lazyPower o/
<lazyPower> sebas5384: really glad to hear you are having a good time spreading the word of juju though. Solid work.
<sebas5384> lazyPower: do you know how are they doing with the vagrant workflow?
<lazyPower> aisrael: Hey you've got some developments on that front. can you relay to sebas5384 what you've been hacking on?
<sebas5384> yeah! and now I'm going to do that at the first Drupal Conference in latin america
<marcoceppi> jrwren: private-address returns the instances public address on manual provider
<marcoceppi> because it's just a machine(tm)
<sebas5384> is going to be in Colombia BogotÃ¡
<aisrael> lazyPower: sebas5384: Sure! We've been getting new functionality added to the vagrant images, things like juju-deployer and squid for caching, and setting up a cleaner workflow.
<aisrael> Once the squid work lands, I'll update the workflow docs. I'm pretty excited about how clean it's looking.
<lazyPower> i cant wait to see what you've been up to
<lazyPower> aisrael: you may be interested in this as well: http://vagrantmanager.com/
<aisrael> omg, want
<lazyPower> its free and available
<jrwren> marcoceppi: how does it obtain a the "public address" with manual provider? What if that manual machine is behind NAT overload? public-address is meaningless at that point, right?  I guess its just address at that point since public/private are both meaningless.
<marcoceppi> jrwren: right, it's whatever ip/address you gave it when you ran "juju add-machine"
<marcoceppi> both public and private address are set to that
<jrwren> marcoceppi: cool! thanks.
<aisrael> lazyPower: works as advertised. Thanks!
<lazyPower> aisrael: happy to help :)
<lazyPower> aisrael: i'll ping sebas via email with that followup since he apparently lost connection. Thanks for the snappy reply at any rate.
<aisrael> lazyPower: Oh, thanks. I didn't notice. Feel free to tag me on the email.
<lazyPower> aisrael: done, linked you two up. He's doing some interesting workload configuration with vagrant and i'm pretty sure he'll be reaching out.
<sebas5384> sorry i'm back
<sebas5384> thanks lazyPower!
<sebas5384> good to know aisrael
<lazyPower> wb sebas5384 - you've got mail if you missed it.
<sebas5384> yeah I sow here hehe
#juju 2014-11-05
<balloons> sebas5384, hey, finally back again :-)
<balloons> glad you got my message earlier and we'll chat tomorrow
<sebas5384> hey balloons
<sebas5384> np balloons, it happens
<sebas5384> :)
<lazyPower> tvansteenburgh: https://code.launchpad.net/~lazypower/charm-tools/fix_1389454/+merge/240666
<skay> shiny https://jujucharms.com/
<wesleymason> Anyone using the openstack provider having trouble bootstrapping today? Looks like a regression in the v1 stream having 1.21-alpha1 in it again (https://bugs.launchpad.net/juju-core/+bug/1367987) and my installed 1.18 borking on it
<mup> Bug #1367987: juju 1.18 and 1.20 cannot parse simplestreams containing version "1.21-alpha1" <hs-arm64> <landscape> <ubuntu-engineering> <juju-core:Fix Released by wallyworld> <juju-core 1.20:Won't Fix by axwalk> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1367987>
<themonk> lazyPower, hi
<lazyPower> hey themonk
<themonk> lazyPower, one of may charm has chrooted env so it conflict with lxc container in local but its ok in cloud service
<themonk> i want my charm to be pushed in juju charm store, will charm store accept this limitation?
<themonk> lazyPower, ^
<lazyPower> themonk: you can get 'in the store' in your personal namespace without any fuss - if your charm has a limitation on the local provider it will need to be *clearly* documented in the readme so the reviewer understands this is expected behavior.
<lazyPower> themonk: https://juju.ubuntu.com/docs/authors-charm-store.html#name-space-charms
<themonk> lazyPower, ok
<lazyPower> i did a write up on this as well if the documentation makes you go cross eyed: http://blog.dasroot.net/the-power-of-community-charming/
<tvansteenburgh> noodles775: just ran charmguardian on your fire_wall optional branch, all tests pass on AWS
<tvansteenburgh> noodles775: i'm about to update jenkins, then i'll kick off a build to run them on the other substrates
<lazyPower> wait, noodles775 made ufw optional?
<lazyPower> awesome, i implemented that locally lastnight. i should have looked.
<noodles775> tvansteenburgh: Excellent, thanks.
<noodles775> lazyPower: Yeah, I did. I'm still interested to know why you'd want to switch it off though? (unless it's just for testig locally, but even then, you can `juju run --unit myservice/0 "curl ..."`
<lazyPower> local deployments, testing scenarios
 * noodles775 nods
<themonk> lazyPower, are you there?
<lazyPower> themonk: in a meeting
<lazyPower> whats up?
<themonk> how long it takes a charm review process, in genarel
<lazyPower> themonk: depends on a few factors - 1) how ready is your charm for the review so it gets expedited after first touch, 2) how many charms are in the queue before you
<lazyPower> themonk: i'll re-iterate, if you puiblish to your namespace, it wont be subject to a ~charmer review, and will be available at the next ingest (which happens ~ every 30 minutes)
<lazyPower> themonk: but if you want to due your due dilligence in preparation for ~charmer review - this is the criteria in which we evaluate charms:  https://juju.ubuntu.com/docs/authors-charm-policy.html
<themonk> lazyPower, i was reading this doc i have made a check list :)
<themonk> lazyPower, thanks :)
<lazyPower> no problem
<tvansteenburgh> noodles775: http://reports.vapour.ws/charm-tests/charm-bundle-test-5034-results
<tvansteenburgh> noodles775: dunno why the timeouts happen, trying to figure that out now
<jrwren> what is the correct url for agent-metadata-url for 1.21-alpha2? i had been using https://streams.canonical.com/juju/devel/tools but that is not working
<jrwren> http://streams.canonical.com/juju/tools/streams/v2/ ?
<tvansteenburgh> jrwren, tools-metadata-url:  https://streams.canonical.com/juju/devel/tools is what i have
<jrwren> tvansteenburgh: have you bootstrapped with that today?
<tvansteenburgh> yes
<jrwren> tvansteenburgh: thanks. now I know its me.
<tvansteenburgh> jrwren, note tools vs agent
<jrwren> tvansteenburgh: 1.21-alpha2 tells me to use agent- not tools-
<tvansteenburgh> hrm, ok
<jrwren> i just tried it with tools same fail for me.
<tvansteenburgh> oh you're right, tools- was replaced with agent-
<tvansteenburgh> jrwren: see sinzui's email from 4 minutes ago (if you haven't yet)
<sinzui> tvansteenburgh, jrwren tools-metadata-url was renamed to agents-metadata-url in alpha2...the later will continue to work for as long as we support trusty
<sinzui> jrwren, are you using  a public cloud or a private cloud
<jose> lazyPower: hey, I had that one locked!
<lazyPower> jose: i'm sorry i'm not sorry ;)
<jose> :P
<noodles775> Thanks tvansteenburgh
<jrwren> sinzui: public
<sinzui> jrwren, I see the issue, the mirror file is pointing to the official location in the CPC, which lists only stable agents
<sinzui> jrwren, the fix is to directly set the agent-metadata-url for the cloud or to switch to alpha2 and set agent-stream
<sinzui> jrwren, which approach do you prefer?
<jrwren> i'll try alpha3 if it is in dev ppa
<sinzui> jrwren, okay, I cam provide the metadata-url for eahc cloud. in the meantime, I will report a bug about the deprecated mirror files. I think we can get those fixes quickly
<marcoceppi> jose: lazyPower has a habit of ignoring the lock
 * marcoceppi plans on ways to mess with him as a result
<jose> I guess I just noticed :P
<lazyPower> jose: gonna do it to you again
<jose> hey!
<lazyPower> just wrapped up looking @ terracotta
<jrwren> I think https://launchpad.net/~juju/+archive/ubuntu/devel the description here should be updated for alpha3
<jrwren> yay! i can bootstrap
#juju 2014-11-06
<stokachu> when did config option 'use-https' get removed from swift-proxy?
<stokachu> i think there needs to be some sort of deprecation process for removing existing charm config options
<rick_h_> stokachu: the old revision is available still?
<stokachu> rick_h_: yea but the installer doesn't have a way to lock into a revision currently
<stokachu> probably need to add that on our end
<rick_h_> ah
<rick_h_> not to argue with you and such that removal of options of charms, expecially promulgated ones, should be standardized to some extent.
<rick_h_> but we keep the history so that you can lock revisions and know it'll always work like pinned packages
<yaell> Hi guys I need some help. I am trying to add a new container to an existing machine on a maas environment using the command : juju add-machine lxc:1 but I always get the same error message :container failed to start. Does anyone have an idea why this is happening?
<gnuoy> gsamfira, are you about at the dev kilo summi
<gnuoy> t
<gnuoy> ?
<gnuoy> I'm having some synctool problems
<_1_Sid> QUESTION: hello everybody. i think juju is great. i was wondering if it was also usable for deploying and managing virtual machines on different computers across the network? I would love to manage our VM with the juju GUI.
<yaell>  Hi guys I need some help. I am trying to add a new container to an existing machine on a maas environment using the command : juju add-machine lxc:1 but I always get the same error message :container failed to start. Does anyone have an idea why this is happening?
<ayr-ton> Theres some plans out there to a agentless juju-master? Like ansible? Recently I run through a problem with my state machine and then I lose access to my agents.
<lazyPower> ayr-ton: i dont believe there are any plans to go agentless, no.
<lazyPower> that is an unfortunate side-effect of when your bootstrap node goes away, as it handles the proxying to hosts
<jrwren> isn't that why we will be supporting HA for bootstrap node?
<lazyPower> jrwren: we already support HA Bootstrap nodes
<jrwren> lazyPower: ah. in that case, isn't that why we support HA for bootstrap nodes?
<lazyPower> juju ensure-availability -  ensure the availability of Juju state servers
<lazyPower> That is correct, however its up to the user performing the orchestration to enable this, as its not default behavior.
<marcoceppi> also, it won't help if the juju-agent on the node goes away
<lazyPower> ^ and that
<ayr-ton> lazyPower, other problem is when a juju agent change ip or something like that. I run through that because of some new rules from management guys.
<ayr-ton> My state machine is on, but all the agents are with new ips =/
<jrwren> i've never run on a cloud where a host changes its IP. ouch.
<ayr-ton> and also, my state machine.
<lazyPower> ayr-ton: the agent i do believe transmits the IP change back to the bootstrap node, i've had machines reboot on AWS, get a new address and I didn't notice any change in availability
<ayr-ton> jrwren, Is because I'm using manual envs.
<lazyPower> ah, i'm not 100% sure on the manual provider - that's a good question - let me follow up on that one
<marcoceppi> ayr-ton: have you tried restarting the agents on those machines?
<ayr-ton> lazyPower, And, if the juju master change IP, how to get connection with it again.
<ayr-ton> marcoceppi, yep
<ayr-ton> with it again?*
<ayr-ton> Part with this problem is, when I make a juju status, I can't contact the juju master, because it have a new ip/domain.
<rbasak> sinzui: bug 1390133
<mup> Bug #1390133: Information about Vivid is not available in Precise <distro-info (Ubuntu):New> <https://launchpad.net/bugs/1390133>
<sinzui> thank you rbasak
<rbasak> We'll see what happens.
<mgz> thanks rbasak
<rbasak> Can chase later if nobody responds.
<rbasak> AIUI, distro-info-data should be kept up-to-date on all supported releases.
<rbasak> Though it might just be Juju that depends on that right now.
<lazyPower> ayr-ton: I'm not getting an immediate answer, but I'll be more than happy to follow up with you
<lazyPower> ayr-ton: in the event you log out, is there another method I can use to reach out with the answer? If so, hit me with a private message and i'll reach out there.
<lazyPower> ayr-ton: i have a solution to triage this, but its some manual effort. We don''t expect the IP's to change out from under the machines - but there are a few config files to edit to repoint agents @ the state server, and to hook your client back up to teh state server.
<ayr-ton> lazyPower, a /memoserv
<ayr-ton> I normally always online because of the znc.
<ayr-ton> lazyPower, So I will reply somehow.
<lazyPower> ayr-ton: ack - i'm doing a writeup now for future reference
<ayr-ton> lazyPower, Where I need to change the confs? I can test now.
<lazyPower> ayr-ton: i'm still cycling on the writeup but here's a quick save with the info: https://gist.github.com/chuckbutler/542b9a62321f3e806daa
<ayr-ton> ok
<ayr-ton> Interesting. I will test this :D
<ayr-ton> Solves my problem x)
<lazyPower> gnarly
<ayr-ton> lazyPower, http://askubuntu.com/questions/540209/ip-domainname-of-juju-master-or-slaves-changes
<ayr-ton> Thank you (:
<lazyPower> ayr-ton: i'll get an answer posted shortly as soon as i'm done with this writeup
<ayr-ton> lazyPower, I already posted. And I put credits to you.
<ayr-ton> Thank you very much.
<lazyPower> No problem :)
<lazyPower> ayr-ton: thanks for taking the time to drop that on AU - we'll give ya a nice little karma bump for going the extra mile
<rbasak> sinzui: 1.20.11 now in trusty-proposed. Go! :)
<rbasak> sinzui: also any comment on the distro-info bug?
<rbasak> Oh, still building.
<sinzui> rbasak, thank you, I do want to add a comment about the precise issue
<ayr-ton> lazyPower, No problem to drop this on AU. Thank you for the karma x)
<jose> aisrael: ping
<aisrael> jose: pong
<jose> aisrael: still working on reviewing that 00-setup MP?
<aisrael> The mongodb one? Trying to, but I'm running into an issue with it in my local environment.
<aisrael> bandwith-related, I think, as it's trying to deploy multiple charms and it's timing out while juju-deployer runs.
<jose> aisrael: I
<jose> I'm gonna try and deploy on EC2*
<jose> though it was a simple permissions change
<aisrael> jose: It is. The issue I'm hitting is unrelated to the charm specifically.
<jose> tvansteenburgh: ping
<tvansteenburgh> jose: pong
<jose> tvansteenburgh: question about bundletester, is there a way to specify machine constraints?
<jose> I have credits for t1.micros on EC2 and defaults are m1.smalls, they cost
<tvansteenburgh> jose:	 as a matter of fact, i'm working on that right now
<jose> \o/
<jose> for now I'm bootstrapping first and then running, so it catches bootstrap constraints
<tvansteenburgh> jose: i'll ping you when it's available, may be this afternoon
<jose> awesome, thanks!
<tvansteenburgh> np!
<mhall119> arosales: marcoceppi: jose: how is the UOS session recruitment going?
<arosales> mhall119: I am behind :-/
<mhall119> arosales: assign it to jcastro (who's not online to refuse) :)
<arosales> mhall119: I like the way you think. He is on vacation this week too
<arosales> mhall119: but I will sync up with pat and sure the cloud sessions are set
<arosales> if any folks here are interested in having a UOS session give me a ping
<arosales> if you want to talk about a new workload on Ubuntu, or workshop using Juju to deploy workloads on ubuntu let me know
<mhall119> on vacation? not at ODS?
<mhall119> arosales: I do hope that LXD will have at least a session or two
<arosales> mhall119: me too :-)
 * arosales has already been bugging ubuntu server folks on that on.
<arosales> mhall119: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010817.html was a good post
<arosales> mhall119: I am guessing you already saw that though, but just in case . . .
<mhall119> yes, but a video is worth a million words (based on word->picture ration and framerates)
<themonk> lazyPower, Hi
<themonk> can anyone help me with this step, File a bug against charms at https://launchpad.net/charms/+filebug This is used to track the progress of your charm.
<themonk> what should i write in summery?
<themonk> In what package did you find this bug?
<jose> mhall119: asked a couple people around, probably things will be scheduled by the beginning of next week knowing how things are
#juju 2014-11-07
<skay> I don't have unit-get or config-get commands on my system, should those get installed with juju 1.20.x?
<skay> the docs talk about the commands, https://juju.ubuntu.com/docs/authors-hook-environment.html but I don't ahve them
<skay> it looks like those were in juju 0.7
<tvansteenburgh> skay those are only available in the context of an executing charm hook
<skay> tvansteenburgh: thanks. I was confused. relatively new. I'm reading through http://askubuntu.com/questions/504482/how-do-i-add-a-relationship-between-two-charms-to-pass-information-between-them
<skay> and wanted to try out some of the commands interactively and didn't realize I couldn't
<tvansteenburgh> skay: no prob, pretty sure we were all new and confused at some point
<tvansteenburgh> now we're just confused
<skay> is there a juju repl?
<tvansteenburgh> skay, no
<skay> logging ftw
 * tvansteenburgh wanders off to play with the kids, bbl
<skay> cheers
<skay> also, I read some more, and https://juju.ubuntu.com/docs/authors-hook-debug.html gives me something like a REPL for playing with hooks
<skay> so that's good
<jose> skay: if you have any questions, just ask :)
<ayr-ton> Theres some plans out there to integrate juju with core os? Feels interesting. We could make a session at UOS.
<whit> when automatically generating a user and a password, does anybody have a good method for exposing that information to someone deploying the charm?
 * whit imagine actions would be good this in the future
<whit> for example, I'm deploying graphite, but don't want to hardwire the admin pw on user creation
<lazyPower> whit: the recommended path is to build a handler script for juju run - to satisfy today
<lazyPower> and yes, actions will be the preferred method once that lands
<whit> lazyPower, ah cool makes sense
<lazyPower> whit: inversely, a lot of the charms expose that as a config option.. but as the charm author its authors flavor on how to handle password generation/retrieval.
<lazyPower> i believe cory_fu took that approach in the Allura charm
<whit> lazyPower, a script wrapping juju-run seems best for my purposes, but of course I've got access to the code
<lazyPower> whit: so long as its documented in the README on how to retrieve the password, i dont think it'll be an issue.
 * whit nods
<cory_fu> whit: Yeah, I favor the run script style, but I've had a lot of people say that a (required) config option to set the password is "better" (mainly because it plays nicer with the GUI)
 * whit shrugs
<cory_fu> Once actions are available, I think that will be the best way
<lazyPower> right, and thats why actions will settle the debate. building the script today and implementing as 'juju run' - will basically get your foot in the door.
<whit> cross that bridge when I get to it ;)
<lazyPower> +1's that opinion
<whit> *if* this  hacked up graphite charm ever makes it to the charm store, I'm guessing we'll probably have actions by then
<lazyPower> whit: you may be surprised by who pulls it down and adds the polish to make it store-ready :)
 * whit aims low for just not sucking
<whit> meh silly django management command demands  terminal input
<whit> juju ssh graphite/0 -t sudo graphite-manage createsuperuser ftw
<thierry-ibm> Hello - on a trusty system I found that juju-gui was in error during install hook - looking at the log, it sounds related to the fact that apt-get update is not returning 0 - does it really make sense to fail like that ?
<thierry-ibm> in another case I found : INFO install /var/lib/juju/agents/unit-wordpress-0/charm/hooks/install: line 5: add-apt-repository: command not found - didn't find any LPid for such error - is it known or a missing prereq ?
<marcoceppi> thierry-ibm: what architecture are you running on?
<marcoceppi> apt should really not be failing at all
<thierry-ibm> ppc64le
<marcoceppi> is there any limit on network connectivity?
<thierry-ibm> what is strange is that I run apt-get update manually and it returned 0
<marcoceppi> oh that is odd
<marcoceppi> thierry-ibm: what if you run `juju resolved --retry juju-gui/0`
<marcoceppi> it may have been an internmittent apt locking issue
<thierry-ibm> agree on that since I get a message : INFO juju-log Updating APT sources.
<marcoceppi> the wordpress issue is also an interesting one
<marcoceppi> are you using Ubuntu Cloud Images?
<marcoceppi> what provider is this?
<thierry-ibm> no I wanted to run manual and run gui + mysql + wordpress on same local system
<thierry-ibm> but don't know if that's supposed to work
<marcoceppi> manual, as in manual provider or local provider with LXC
<thierry-ibm> manual provider
<thierry-ibm> everything on machine "0"
<marcoceppi> ah, that explains a bit more
<marcoceppi> we've come to coin this as "hulk smashing"
<marcoceppi> because there tends to be collisions. Where it appears another charm was running apt at the time apt-get update was run in juju-gui causing it to error
<thierry-ibm> ah ... I see a first issue - gui and wordpress would use same port number 80 - not good
<marcoceppi> while a some charms can work like this a lot can't because they expect to own the entire machine. IE wordpress uses nginx and gui uses apapche
<marcoceppi> and there you go, they fight over port 80
<marcoceppi> you should be able to put most of these in containers on machine  0
<marcoceppi> juju deploy --to lxc:0
<marcoceppi> so you can have density while not encountering collisions
<marcoceppi> there's networking bits that would need to be sorted, and we're working on putting those in core, but the systems will deploy and you can use sshuttle to gain network access to the LXC network on machine 0
<marcoceppi> or setup NAT on the LXC bridge on the machine
<marcoceppi> depends on your network setup on that machine and it's location
<thierry-ibm> ho that could explain why on another set of system on another machine I get problems to just get charms ... even setting proxy
<thierry-ibm> I will rework all of that then - great thanks for the explanation it at least clarify my mind ;-)
<marcoceppi> aisrael: http://marcoceppi.com/2014/11/compiling-juju-core-from-source/
<aisrael> marcoceppi: \m/
<skay> python-django uses ansible, and it has a playbooks directory -- if I use it, can I have some playbooks that it will call instead? I don't see how that could happen in the source code, but maybe there is some magic charm thing going on
 * skay is looking at line 272 in https://www.tripit.com/p/FAEDF3031998F148D2DA1B958C450518
<skay> oh crap, wrong paste buffer
<skay> btw, did I mention I'm going ona  trip?
<marcoceppi> skay: oh hey, enjoy o/
<skay> marcoceppi: thanks! I'm excited! going to Taipei for work
<skay> have never been there
<marcoceppi> so, there's an Ansible charm helper that does all that...magic stuff
<marcoceppi> and executes the playbooks
<skay> I didn't mean to share it with the world though :)
<skay> marcoceppi: and I see python-django using it here, http://bazaar.launchpad.net/~charmers/charms/trusty/python-django/trunk/view/head:/hooks/hooks.py#L272
<skay> and it looks hardcoded ..thugh I haven't looked at the charm helper code to see if it knows to find any files in playbooks and somehow finds them in some order of precedence
<skay> that probably doesn
<skay> doesn't happen?
<marcoceppi> it's hard coded
<marcoceppi> but the python-django charm does a lot of...extra stuff
<marcoceppi> it might not be the best example tos tart with
<marcoceppi> lazyPower: ^^ feedback?
<skay> so I guess if I wanted to be able to do my own playbooks that I can't use python-django yet
<skay> but maybe in the future, if there are plans?
<lazyPower> skay: elasticsearch would be the reference charm for ansible imho
<skay> lazyPower: thanks
<lazyPower> 1 sec, there's a template fo rit
<lazyPower> skay: charm create -t ansible
<skay> at work we've been using someone's fork of python-django that works with a tgz of our django app
<lazyPower> you'll get a skeleton charm ready to go with ansible. You can use the common patterns in ansible such as defining roles and including those .yaml files in your playbook.yaml
<skay> and I'd like to use the charm store instead
<lazyPower> ah, yeah there's even more work coming for the python-django charm i didn't realize your questions were specific to django
<skay> thanks lazyPower
<skay> lazyPower: what plans are there for the python-django charm?
<lazyPower> skay: https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/pure-python/+merge/226742
<lazyPower> they're moving away from ansible as there were limitations they ran into that were solveable via pure python charming
<lazyPower> its pretty close to being accepted, someone will be circling back no this MP next week - as its bubbling up to teh top fo the queue. Expect to see it land soon, from what i'm reading the only remaining issues are with the tests
<lazyPower> skay: i'm going to head out for lunch, if you need anything feel free to ping me and i'll reach out when I get back
<marcoceppi> skay: oh, I didn't realize you were using python-django
<skay> lazyPower: cheers
<marcoceppi> you can pretty much drop in play books then then reference them and add a few lines where needed to execute them
<skay> marcoceppi: sorry bout that, I wasn't sure how much context to provide for my question
<marcoceppi> I thought you were looking for just an ansible example
<marcoceppi> skay: you can also submit merge requests and open bugs to get features you're missing in to the store version
<skay> marcoceppi: when I have a better idea for how things work I may
<skay> btw, I watched a couple of the charmschool videos and they were very helpful!
<marcoceppi> great, glad to hear that!
<cl__> Hello,
<cl__> Does anyone know which ip address will be return by unit_get('private-address'), if there are multiple networks on the machine? Thanks.
<marcoceppi> cl__: whatever network interface is used to communicate with bootstrap, typically the first network device
<marcoceppi> cl__: I don't think there's really much logic around that nex
<cl__> marcoceppi, thank you!
<marcoceppi> cl__: however wer're working on better networking in core where you'll be able to define and select which networks to use
<cl__> marcoceppi, that will be great!
<cl__> marcoceppi, in my environment, there are tow networks connecting all the hosts, including the bootstrap machine.
<cl__> marcoceppi, so I guess, juju will pick the first network device as you said.
<cl__> s/tow/two
<jose> cory_fu: ping
<cory_fu> jose: Hey, man.  Sorry I didn't get back to your email yet.
<jose> cory_fu: np, was wondering about tests, since I had written some but needed a bit of fixing
<cory_fu> What are you wondering about?
<jose> if you had written some for chamilo
<cory_fu> jose: Unit tests, for sure: http://bazaar.launchpad.net/~johnsca/charms/precise/chamilo/services-framework/view/head:/tests/test_actions.py
<cory_fu> That branch could use an Amulet test, as well
<jose> yep, those I was working on
<jose> will take a look after this mailman ones pass, should be quite soon
<cl__> hello,
<cl__> anyone know if there is a way to set config options differently for each unit of a service? either from command line or in charm bundle...
<cl__> thanks:)
<jose> cl__: there is a tweak you could use. What are you trying to achieve?
<cl__> jose,  I want to set a config option (an ip address) differently to each service unit.
<jose> cl__: I believe each unit has its own IP address
<cl__> jose, yeah
<cl__> jose, in addition to the private-address of the service unit, a specific config item in the service configuration file needs to be set.
<jose> cl__: you could use this following command:
<jose> oh, nvm
<jose> hmm
<jose> cl__: what's this service, if I may know?
<cl__> jose, I know this sounds a bit confusing ;)
<cl__> jose, sure
<cl__> jose, https://manage.jujucharms.com/charms/trusty/nova-compute
<jose> cl__: not sure it needs you to manually specify an address for each unit
<cl__> jose, there is a config-flags item in the config options. I would like to use it to set my_ip option in nova.conf
<jose> lemme check
<cl__> jose, like juju set nova-compute/0 config-flags=my_ip=10.5.0.227
<jose> you could specify an alias for each unit, but that would break scalability
<cl__> jose, this obviously will not work ;)
<jose> correct
<jose> and not sure if the command I'm going to give you is going to run in a hook context
<cl__> i see
<jose> but setting it to `unit-get public-address` *may* work, I'm not 100% sure
<jose> someone else may be able to confirm that
<jose> marcoceppi: ^
<jose> or lazyPower ^
<cl__> jose, thanks a lot
<jose> np, and sorry for not having a direct answer
<cl__> jose, no worries. I know this doesn't quite make sense to juju.
#juju 2014-11-08
<johnmce> Hi, I'm upgrading my test openstack installation to Juno, and I'm stuck at trying to get Keystone re-installed. Having failed to update the existing Keystone LXCs in place, I decided to scrap them a create a couple of replacements.
<johnmce> In my config file I'm specifying "openstack-origin: 'cloud:trusty-juno'". Keystone fails to install in the new LXC container. The first error I dealt with was "juju-log FATAL ERROR: Could not determine OpenStack codename for version 2014.2.
<johnmce> I worked around this with an "apt-get update; apt-get upgrade; add-apt-repository -y cloud-archive:juno; apt-get update"
<johnmce> however, I'm now getting this error: juju-log FATAL ERROR: Invalid Cloud Archive release specified: trusty-juno
<johnmce> I've tried googling that error, but I'm not finding any answers. Can anyone offer any advice?
<johnmce> Further to my earlier question, (using Juju and MAAS) when I add keystone, thus spawning LXC containers, how is it that the "/var/lib/juju/agents/unit-keystone-0/charm/hooks/charmhelpers/contrib/openstack/utils.py" file contains no reference to Juno whatsoever, when the same file in the charm I'm using does contain references to Juno?
<johnmce> How is it that an older version (icehouse) of this file is being used?
<jesk> hi
<jesk> did a fresh 14.04 installation with maas and juju 1.20.11 from paa
<jesk> i tried bootstrapping with juju bootstrap --upload-tools --debug
<jesk> two thing I encountered are that /var/lib/juju/nonce.txt is missing so that i have to manually login on the node and create it
<jesk> the next problem I couldnt fixed yet is that:
<jesk> 2014-11-08 15:14:24 ERROR juju.cmd supercommand.go:323 exec ["start" "--system" "juju-db"]: exit status 1 (start: Unknown job: juju-db)
<jesk> 2014-11-08 12:39:19 ERROR juju.provider.common bootstrap.go:122 bootstrap failed: subprocess encountered error code 1
<jesk> Stopping instance...
<jesk> any help appreciated
<jose> anyone else having troubles with ec2?
<jrwren> what kind of ec2 troubles?
<jose> jrwren: I'm getting the following:     agent-state-info: 'cannot run instances: No default subnet for availability zone:
<jose>       ''us-east-1e''. (InvalidInput)'
<jose> jrwren: any ideas about what may be going on?
<jrwren> jose: yes. A bug was recently closed on that.
<jrwren> jose: check your VPC
<jrwren> jose: make sure you have a subnet for us-east-1e in your default VPC
<jose> jrwren: there was no subnet for us-east-1e, but I created it and it's still giving me the error
<jrwren> jose: did you remove the machine and add a new one?
<jose> jrwren: yep. lemme destroy my env and re-bootstrap
<tvansteenburgh> jose: axw told me you can work around that bug by deleting the default VPC in your region (assuming you don't need it); beware that it can't be undone w/o help from AWS support)
<tvansteenburgh> jose: or wait for 1.21 beta1 which will contain the fix
<jose> tvansteenburgh: I was trying to run some tests and I can only create 3 machines (machine 0 and two services), so I guess I'll have to wait
<jose> now, what happens if I delete my VPC? supposedly I won't be able to create machines
<jrwren> yeah, I don't recommend deleting the default VPC
<jrwren> I deleted mine and I couldn't create machines.
<jrwren> I don't know how to tell juju to use a non default FPC
<jose> I hope 1.21-beta1 is released soon. kinda annoyinh
<jose> annoying*
<tvansteenburgh> supposedly coming early next week
<jose> cool then. will hold my tests.
<jrwren> jose: did you get the error again?
<jose> jrwren: bleh, bundletester paused waiting for me to input my password for 00-setup and I didn't know
<jose> it's running now, let's check...
<jose> jrwren: same error
<jrwren> jose: same AZ?
<jose> jrwren: yep
<jose> us-east-1e
<jrwren> i moved to us-west-2
<jrwren> but it sure would be nice to find a better work around.
<jrwren> jose: do you have awscli at your disposal?
<jrwren> jose: apt-get install awscli and then aws configure and use same creds as that juju environment.
<jose> ack!
<jrwren> jose: if you could do that and pastebin the output of aws ec2 describe-subnets
<jose> jrwren: http://paste.ubuntu.com/8887559/
<jrwren> jose: well heck is if I know. it says there us-east-1e subnet has 4000+ available.
<jose> yeah, I'll have to wait until 1.21-beta1 :P
<jose> thanks for your help, though! :)
<johnmce> Further to my earlier question, (using Juju and MAAS) when I add keystone, thus spawning LXC containers, how is it that the "/var/lib/juju/agents/unit-keystone-0/charm/hooks/charmhelpers/contrib/openstack/utils.py" file contains no reference to Juno whatsoever, when the same file in the charm I'm using does contain references to Juno?
<johnmce> Can anyone point me in the direction of any documentation that explains how my target LXC machine receives the charm, so that I can work out where on earth it's getting this outdated charm from?
#juju 2014-11-09
<johnmce> Can someone please help with a problem I'm having with Juju. I've asked about this problem here several times in the past 30 hours, but had no response.
<johnmce> There is clearly a bug in Juju that causes it to deploy old versions of charms when deploying Keystone to a MAAS LXC container
<johnmce> I've used bzr to check the latest Keystone charm to a local repo. This charm clearly supports Juno, as can be seen in the source code.
<johnmce> However, when it is deployed to a newly instantiated MAAS/LXC container, the charm deployed is an earlier revision that does not support Juno.
<johnmce> Can anyone please help? I'm rapidly losing faith in Juju, as there is no documentation or community support that gives any clue as to the possible cause.
<jrwren> jose: how are you deploying it?
<jrwren> err, johnmce
<jrwren> sorry jose, misdir
<jose> no prob :)
<jrwren> johnmce: can you pastebin the commands you have run or maybe ask on askubuntu to completely describe the problem ?
<jose> johnmce: probably not getting a response since it's the weekend and most people are hanging out doing some other stuff. but I'll be glad to give you a hand with this! as jrwren mentioned, if you could pastebin the command or the bundle you're using that'd give us a good first clue on what's going on
<johnmce> jrwren: Thanks for the response. I'll pastebin some details info shortly.
<jrwren> johnmce: if you have commands which you've run, I can try to reproduce.
<johnmce> jrwren: This is a complete attempted install I just did: http://pastebin.com/9Tjae302
<johnmce> jrwren: As you can see this revision of the charm is called "local:trusty/keystone-243". The same revision number that hits the LXC machine, but with inconsistent content.
<jrwren> johnmce: whoa, how does that work :)
<jrwren> johnmce: are any of /opt/charms or /opt/charms/trusty  symlinked directories? are they linked to where you expect?
<jrwren> johnmce: can you paste that bundle?
<johnmce> jrwren: None are symlinked. Unless of course "bzr branch" does some weird symlinking that I didn't expect
<jrwren> johnmce: no, bzr branch won't do taht.
<jrwren> johnmce: what is the value of openstack-origin in config?
<johnmce> jrwren: Got to go for about 10 minutes. Where will I find the bundle in a suitable format for pasting?
<jrwren> johnmce: maybe you didn't use a bundle. I see a bundle mentioned on line 112 of that pastebin
<jose> johnmce: you're using a local charm, which means you're not deploying from the charm store (cc. jrwren )
<jose> johnmce: that means, if you have branched and old revision which doesn't have the changes that are on the store yet, then you will not get them
<jose> johnmce: try going into /opt/charms/trusty/keystone and doing bzr pull
<jose> otoh, I'm seeing an error about an invalid cloud repo
<jose> oh, oh, wait! charm helpers!
<jose> johnmce: may I see what's the output of ls -lh /opt/charms/trusty/keystone, please?
<jose> also, try deploying with just the following command:
<jose> juju deploy --to lxc:1 --config=~/openstack.cfg keystone
<jrwren> seems like config isn't getting set. openstack-origin is defaulting
<johnmce> jose: http://pastebin.com/8EpmNu9A
<johnmce> jrwren: I included the relevant part of the config file in my original pastebin. This was the origin line for keystone: openstack-origin: 'cloud:trusty-juno'
<jrwren> johnmce: right. I think you diagnosis is perfect. I've no idea why the juno definitions aren't in the charm on the deployed lxc.
<johnmce> jrwren: I've got single quotes around cloud:trusty-juno. Is that the correct syntax?
<jrwren> johnmce: its yaml. that should be fine with or without
<johnmce> jrwren: Is there any more information I can provide to help diagnose this?
<jose> johnmce: did you try deploying with that last command I gave you?
<johnmce> jose: Sorry, not yet. I'll try it now.
<jrwren> johnmce: you could run all of the commands with --debug --show-log and paste that. Maybe a log message will give us more clues.
<jose> johnmce, jrwren: wouldn't recommend pastebinning the full log of debug.
<jose> there's some sensitive credentials that show there
<johnmce> jose: Interesting error when trying to deploy: Added charm "cs:trusty/keystone-8" to the environment.\n ERROR unknown option "vip_cidr"
<johnmce> jose: strange that I didn't get an error with the local charm is that attrib is invalid
<jose> johnmce: it is, in fact, not a valid config option
<jose> I'm checking your first paste,s ec
<jrwren> johnmce: i did get that error wiht local charm deploy using same bzr source that you did.
<jose> I'm checking https://jujucharms.com/keystone/trusty/8 and I don't see vip_cidr as an option
<jose> just vip
<jrwren> yes, its not in config.yaml.  unsure why johnmce did not get an error
<johnmce> jose: Used to be an option: https://jujucharms.com/keystone/trusty/6
<jose> hmm, probably deprecated for some reason
<jose> wait
<jose> I know what that means
<jrwren> i think i know too :)
<johnmce> jose: Presumably vip is just IP/CIDR?
<jose> (string) Virtual IP(s) to use to front API services in HA configuration. . If multiple networks are being used, a VIP should be provided for each network, separated by spaces.
<jose> BUT
<jose> that means you are using an old revision
<jose> try removing that option from your yaml and deploying again
<jose> johnmce: ^
<johnmce> jose: trying now
<jrwren> install hook is still running, but I can confirm that it is using the juno cloud archive. So I tend to agree with jose, your local bzr checkout is out of date.
<johnmce> jose: nope, still failed
<jose> which error now?
<johnmce> jrwren: I checked it out with bzr yesterday. They must have changed it in the last 30 hours or so then.
<johnmce> jose: same error
<jose> johnmce: have you deleted the value from the .yaml file?
<johnmce> jose, jrwren: http://pastebin.com/TsDCNgwW
<johnmce> jose: yes, both vip and vip_cidr are gone.
<jose> johnmce: deploy using the command I gave you
<jose> juju deploy --to lxc:1 --config=~/openstack.cfg keystone
<johnmce> jose: still using my local copy, which I checked out yesterday. I don't think that vip_cidr got pulled in the past 30 hours though. Not mentioned in the config.yaml in my local copy.
<jose> johnmce: if you use the command i just pasted, you will automatically pull the latest rev from the Charm Store, and the configuration options you will use will be the ones located in ~/openstack.cfg
<johnmce> jose: Just doing it now
<jose> johnmce: there's no need to use a local branch and that is, in fact, not recommended because it may cause this kind of issues
<jose> cool :)
<johnmce> jose: no installation-blocking error this time, as expected
<jose> cool!
<johnmce> jose: Not failing yet either - still pending
<jose> awesome, let's hope it doesn't
<johnmce> jose: Side note - bzr pull says I'm up to date I think
<jose> johnmce: that's weird
<jose> johnmce: bzr history, rev number?
<jose> (latest)
<johnmce> jose: john@maas-cam:/opt/charms/trusty/keystone$ bzr pull\n Using saved parent location: http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/keystone/trunk/\n No revisions or tags to pull.                                                                                                               john@maas-cam:/opt/charms/trusty/keystone$
<jrwren> johnmce: bzr log and bzr log -p can help you find out when that config option was removed.  I can't reproduce what you have experienced.  I get juno deployed.
<johnmce> jrwren, jose: bzr log: http://pastebin.com/LfTTABtR
<jrwren> johnmce: so unchanged since Oct 9th
<jose> weird, it is the same revision that's on the store
<johnmce> jrwren, jose: The charm from the main repo has now successfully installed. So, the problem is that what I'm getting with bzr is broken.
<jrwren> johnmce: what is out put of juju get keystone?
<johnmce> Yesterday morning I renamed my old keystone folder and did a fresh bzr branch to get the latest keystone
<jose> I am really wondering why was that failing, if it's the latest rev. the only thing that comes to mind is a file was changed manually by mistake
<jose> but if you pulled+deployed then that shouldn't have been the case
<johnmce> jose: I've made no modifications, and bzr diff confirms this
<jose> yeah, I know
<jose> anyways, looks like you were able to successfully deploy the charm, so that's good :)
<johnmce> jrwren: There's sensitive information in "juju get keystone" output
<johnmce> jrwren: anything in particular to look for?
<jrwren> johnmce: just wondering if openstack-origin is set correctly from config
<jose> johnmce: I'm wondering, is there the need to have the charm locally? if not, you could just go ahead and deploy from the charm store when you need
<johnmce> jose: It's kind-of nice to be able to deploy this, but I'm trying to follow what I believe to be best-practices, and "bzr branch" each charm so that I know what I've got installed and can modify locally if needs be
<jrwren> johnmce: i totally agree.
<jose> same here, that's the benefit of the charm code being open source
<johnmce> jose: I have previously made my own mods to a couple of charms (not keystone though)
<jrwren> i wonder if there is a way to remove a charm from an environment.
<jrwren> its almost as if the state server is deploying the previous one even though you have asked for local.
<jose> jrwren: juju destroy-service [service-name]; juju destroy-machine #
<jrwren> jose: that does not remove teh copy of the charm from teh state server AFAIK
<jose> jrwren: you could upgrade-charm
<jrwren> oh, there ya go.
<jrwren> johnmce: did you already have a keystone deployed? is it possible that deploy is really just doing add-unit?
<johnmce> jrwren: I tried upgrading the charm originally when I still had keystone deployed. That was before I nuked keystone and tried to start again.
<jose> jrwren: destroy-service does remove the charm code from the state-server, when I debug my charms I don't have to re-bootstrap and I just destroy the service and redeploy
<jose> johnmce: just a piece of advice, we have a package called charm-tools and it has a tool called `charm get`, so it branches from bzr
<jrwren> jose: good point.
<jose> johnmce: it's just an alias to an script that does bzr branch for you but it *should* always get the rev on the charm store, and not any other related branches
<jose> may be useful for you instead of having to type all the branch name, just 'charm get cs:trusty/keystone' and you're done
<johnmce> jose: I'll try it now
<johnmce> jose: I just diffed the keystone I got with "charm get" against the one I got yesterday (excluding the .bzr folder) and they are identical.
<jose> wat
<johnmce> jose: Could ownership or permissions be an issue here?
<jose> johnmce: I don't believe so
<jose> johnmce: could you try deploying from the branch that you just pulled?
<johnmce> jose: bzr not being able to set them? But then again, where is this old code coming from?
<jose> I have no idea
<johnmce> jose: doing this now: juju deploy --to lxc:1 cs:trusty/keystone --config=~/openstack.cfg
<jose> johnmce: cs:trusty/keystone is the same as saying just keystone
<jose> alias
<johnmce> jose: How did you want me to do a test deployment?
<jose> johnmce: try removing that folder and branching again
<jose> I wanna make sure this error doesn't pop up again
<johnmce> jose: Every time I use the charm store, this succeeds, but local copy always fails
<johnmce> jose: In theory, I have always been installing the same code from the same source. It's the just the intermediate step of using bzr that breaks it
<jose> this is so weird
<johnmce> jose, jrwren: I just tried again from the copy I got with "charm get ...". Same problem. Fails every time. Using charm store works every time - several times now.
<lazyPower> johnmce: do you have any info about why the deployment failed?
<johnmce> jose, jrwren: OK, I'm starting to doubt my sanity now. Look at this: http://pastebin.com/RwyfQ43k
<jose> hmm
<jose> lazyPower: ^
<lazyPower> jose: i see the deployment command returned, however that doesn't necessarily mean it is deploying propper, i'm late to the show admittedely
<lazyPower> *admittedly
<johnmce> jose: Is there a typo I'm not seeing?
<jose> johnmce: has it gotten any error until now? has the install hook failed?
<johnmce> jose: It's failed as usual.
<johnmce> jose: it's clearly getting the charm from a folder other than the one I'e specified
<jrwren> anyone know how to connect to state server's mongod using mongo client?
<lazyPower> jose: ah - i see what you're running into
<jose> lazyPower: local fails, cs doesn't, even though they're exactly the same
<johnmce> jose: how though? I'm being specific about the location
<lazyPower> johnmce: correct me if i'm wrong, you've deployed keystone before, now you're attempting to deploy a newer revision of the charm and you've run into issues where a cached charm in your state server is continually deploying instead of what you expect to be deployed?
<jrwren> lazyPower: that is my guess too.
<johnmce> lazyPower: yes that's right, I always end up with an old charm
<lazyPower> in some instances, i've run into charm caching on my state server, and have had to run juju upgrade-charm servicename  --repository=/path/to/charms while the machine is provisioning. This was happening to me back in the 1.18 days however, not on the newer builds of juju.
<johnmce> lazyPower: the updated charm is simply not being read
<lazyPower> I'm spinning up a VM right now to verify if this is still the case - i'm giong to deploy mongodb from the store, switch to local, attempt destroy/re-deploy and see if it registers as local or cs
<johnmce> lazyPower: to being with I was trying an upgrade, and then switched to destroy and deploy
<jrwren> lazyPower: he always uses local, so maybe a better test is to bzr branch an older rev, deploy that local, and bzr upgrade and deploy that.
<lazyPower> ok, can you tail your machine-0.log (the stateserver's machine log) during the deploy phase so we can see what it thinks its doing?
<lazyPower> jrwren: ack, will do.
<johnmce> lazyPower: I just tried doing an upgrade, which resulted in no error message, in spite of the keystone folder not existing
<lazyPower> johnmce: when you juju status keystone - is the charm prefixed with local: and have a revision number that is 1 greater than the previous increment?
<lazyPower> according to this output i have here... keystone-244, should read local:trusty/keystone-245
<johnmce> lazyPower, jose, jrwren: I may have just had a breakthough.
<lazyPower> \o/ thats news we like to hear
<johnmce> lazyPower, jose, jrwren: I had old copies of keystone lying around in renamed folders under the local repo
<lazyPower> doh
<johnmce> lazyPower, jose, jrwren: I thought that they would be ignored, but they are not
<lazyPower> johnmce: i've done that as well, i'm gonig to file a bug against that actually
<johnmce> lazyPower, jose, jrwren: One was called "keystone.old"
<jrwren> but... what kind of renamed folders?
<lazyPower> johnmce: I'm glad you discovered that - as i feel juju should warn you its picking something arbitrary
<jrwren> juju read it from keystone.old ?
<lazyPower> jrwren: its scanning metadata, so it'll pick whicever it thinks is right
<jrwren> ugh.
<lazyPower> jrwren: and thats a blood obnoxious papercut
<jrwren> that is a stab wound.
<jrwren> a papercut doesn't take 8 man hours on a sunday :)
<johnmce> lazyPower, jose, jrwren: It really goes against any behaviour I'm used to seeing in other realms. I thought the folder name was key
<jrwren> johnmce: yup, it should be, but the trick and key is that it treats the repository as a repository and reads metadata.yaml in each directory instead of just directory names.
<jrwren> its probably by design, but certainly docs should be better around local deploy in this area.
<johnmce> lazyPower, jose, jrwren: Thanks for all your help. At least now I know for the future.
<lazyPower> johnmce: really sorry you ran into that, give me another moment to get you a bug link
<lazyPower> i'm sure you'd like to tag it for additional traction
<jose> johnmce: if there are any other questions or things we may help with, feel free to ask here or on juju@lists.ubuntu.com
<lazyPower> https://bugs.launchpad.net/juju-core/+bug/1390972
<mup> Bug #1390972: Juju picks an arbitrary charm when multiple-versions of a charm are present in a local repository <papercut> <juju-core:New> <https://launchpad.net/bugs/1390972>
<johnmce> lazyPower, jose, jrwren: You know I've probably been tripped up by this before at not known it. I often rename a folder rather than wipe it. I've previously nuked my whole installation to get a clean start.
<lazyPower> johnmce: I keep multiple charm repositories for my environments and export JUJU_REPOSITORY
<lazyPower> you can always juju upgrade-charm --switch when you are ready to move from store to devel, and this keeps me straight when im' jumping environments.
<jrwren> all great details which would be nice in docs.
<lazyPower> but again, really sorry this tripped you up - its not a great user experience when its doing something on your behalf and not telling you that's what its doing.
<lazyPower> jrwren: file bug's on github.com/juju/docs - and i'll see about circling back to getting those in there.
<jrwren> lazyPower: i tend to file pull requests on juju/docs :)
<lazyPower> jrwren: even better :)
<johnmce> lazyPower, jose, jrwren: I can't thank you guys enough for your patience. Hopefully others will benefit from this. It's beer o'clock here, so I'll sign off :-)
<lazyPower> johnmce: best of luck to ya o/  cheers
<jose> enjoy what's left of your weekend!
#juju 2015-11-02
<jamespage> morning folks
<jamespage> gnuoy, need something brainless todo this morning so working through http://pad.ubuntu.com/tox-charm-landings
<gnuoy> jamespage, ok, enjoy!
<Prabakaran> Hello Team,
<Prabakaran> I have created new bug for my charm and after linking bug id to the trunk branch in the lauchpad i am not able to see my charm in the review queue. Could you please advise on the same?
* You're now known as ubuntulog2
<Prabakaran> Hello Team, I have created new bug for my charm and after linking bug id to the trunk branch in the lauchpad i am not able to see my charm in the review queue. Could you please advise on the same?
<lazypower> Prabakaran : How long ago did you submit?
<lazypower> Prabakaran : Can you link me ot your branch you're submitting?
<Odd_Bloke> I'm seeing strange behaviour when running one of my hooks in debug-hooks; it looks like an exception that is caught in normal operation (and when I pdb through the code in debug-hooks!) is not being caught...
<Odd_Bloke> Ohhhh, no I'm not, I'm seeing the output come out.
<Odd_Bloke> OK, that's unexpected but otherwise fine.
<lazypower> Odd_Bloke well, glad it was self resolving
<lazypower> Odd_Bloke but that smells of a race condition when a pdb() fixes it where normal hook execution tanks
<Odd_Bloke> lazypower: It was really user error; I was seeing stderr from a failed subprocess call, but not the stdout from a subsequent successful one (because it was captured, I now realise :p).
<Odd_Bloke> lazypower: So I incorrectly inferred the latter hadn't happened.
<Odd_Bloke> I'm looking at the Jenkins charm: you can configure it with an admin password, or it can generate one for you.
<Odd_Bloke> However, it doesn't store the generated password as config, which means that when it tries to push configuration out to extension relations, they get an empty password.
<Odd_Bloke> (Making it impossible for them to connect to Jenkins to do anything)
<Odd_Bloke> Is the correct way of handling this for the charm to write to the place that hookenv.config(...) pulls from, or...?
<Odd_Bloke> (The problem here being that the password gets salted before writing, so pulling it out of the file it's written to won't work)
<Odd_Bloke> lazypower: (^ ?)
<lazypower> Odd_Bloke it should use unitdata.kv
<lazypower> Odd_Bloke if the config password is empty, read the generated key from unitdata, and pass that along the wire
<Odd_Bloke> Oh, sigh, of course charm-helpers in the charm is too old.
<Prabakaran> I have submitted my charm last week thursday. And my charm branch link is "https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-platform-rtm/trunk"
<Prabakaran> https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-platform-rtm/trunk
#juju 2015-11-03
<Prabakaran> Hello Team, I have created a new bug for my charm and after linking bug id to the trunk branch in the lauchpad i am not able to see my charm in the review queue.  Could you please advise on the same?
<gnuoy> jamespage, charmhelper mp as discussed https://code.launchpad.net/~gnuoy/charm-helpers/service-framework-loader/+merge/276519
<jamespage> gnuoy, landed - thankyou!
<jamespage> coreycb, hey - thanks for the  tox landing yesterday - I updated the two borked branches and generated a new one for ceph-radosgw
<jamespage> I think that just leaves swift stuff and cinder-ceph
<gnuoy> jamespage, follow up for the charm itself, sync + minor change to services.py https://code.launchpad.net/~gnuoy/charms/trusty/neutron-api-odl/ch-sync/+merge/276520
<jamespage> gnuoy, +1
<gnuoy> ta
<gnuoy> jamespage, In the interests of not duplicating effort I'm going to start on the unit and amulet tests for odl-controller
<jamespage> gnuoy, ack
<jamespage> gnuoy, I'll deploy ovs-odl and start looking at the north/south traffic issues BjornT hit
<gnuoy> kk
<coreycb> jamespage, no problem, those other two branches are landed now
<jamespage> coreycb, thanks
<coreycb> jamespage, do you have swift/cinder-ceph in the works?  if not I can pick those up if you want.
<jamespage> coreycb, yeah done this morning - links on the pad - http://pad.ubuntu.com/tox-charm-landings
<coreycb> jamespage, great I'll review them
<gnuoy> jamespage, git+ssh://git.launchpad.net/~sdn-charmers/charms/+source/openvswitch-odl is proving problematic with amulet. There's no series in there and I'm going to need to update python-charmworldlib to be able to parse it
<jamespage> gnuoy, oh I pushed that to lp:~openstack-charmers/charms/trusty/openvswitch-odl/trunk this monring
<gnuoy> jamespage, \o/
<jamespage> that sounds like a nasty blocker to git migration...
<gnuoy> ah well, lets stay on bzr then
<bdx> hey whats going on? Im testing out "enable-local-dhcp-and-metadata
<gnuoy> jamespage, Using http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bundles/ovs-odl/ovs-odl.yaml relates neutron-gateway and openvswitch-odl with the juju-info interface, is that right?
<jamespage> gnuoy, it is
<gnuoy> ok
<bdx> I'm having a hard time locating the metadataproxy datasource that instances get cloud-init userdata from when enable-local-dhcp-and-metadata is set
<bdx> has anyone had luck using enable-local-dhcp-and-metadata ?
<gnuoy> bdx, I have had lots of luck with it
<bdx> I'm guessing the metadata api endpoint is also the dhcp port then yea?
<bdx> or the dhcp port will at least forward traffic to 169.254.169.254/32 correct?
<gnuoy> bdx, if I remember correctly the dhcp request returns a static route pointing 169.254.169.254 at the nic inside the dhcp namespace
<gnuoy> bdx, give me a minute and I'll fire up a deploy and remind myself
<bdx> gnuoy: that is consistent with what I'm seeing....
<bdx> gnuoy: when you do, create your tenant networks as vlan networks
<bdx> if you don't mind
<gnuoy> bdx, I do
<bdx> ok
<gnuoy> bdx, haha that was out of sync
<gnuoy> I meant 'I do create them as vlan networks'
<gnuoy> bdx, ^ I didn't mean I minded
<bdx> totally
<bdx> ha
<bdx> gotcha
<mattyw> jose, ping?
<jose> mattyw: pong!
<bdx> Nodes fail to reboot/powercycle when ceph-osd + (nova-compute + hugepages) due to deadlock
<bdx> I'll be filing a bug for it in a few
<bdx> its had me stopped up for the last few days
<Prabakaran> Hello Team, I have created a new bug for my charm and after linking bug id to the trunk branch in the lauchpad i am not able to see my charm in the review queue.  Could you please advise on the same?
<gnuoy> bdx, ok, I'm up and running with enable-local-dhcp-and-metadata
<gnuoy> bdx, http://paste.ubuntu.com/13092618/
<bdx> gnuoy: nice!
<gnuoy> so those networks are provider networks
<bdx> entirely.....
<Prabakaran> My charm link is "https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-platform-rtm/trunk"
<gnuoy> bdx, so your guests get an ip but fail to retrieve metadata?
<bdx> gnuoy: yes.....I just found an inconsistency on one of my physical nodes  port <-> vlan trunk was on eth4 ....whereas the rest of my nodes use eth3...grrr
<gnuoy> bdx, ah !
<gnuoy> bdx, you can use mac addresses in the data-port setting for neutron-openvswitch
<gnuoy> to cope with inconsistencies
<bdx> gnuoy: oh no way tahts huge!!!!!!
<bdx> hah
<bdx> I must of missed that
<gnuoy> bdx, http://paste.ubuntu.com/13092664/
<bdx> oh taht is awesome!
<bdx> that*
<gnuoy> yeah, it really useful
<tvansteenburgh> hazmat, you around?
<Prabakaran> Hello Team, I have created a new bug for my charm and after linking bug id to the trunk branch in the lauchpad i am not able to see my charm in the review queue.  Could you please advise on the same?  Charm link is "https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-platform-rtm/trunk"
<tvansteenburgh> Prabakaran: see https://jujucharms.com/docs/stable/authors-charm-store#recommended-charms, point #3
<tvansteenburgh> Prabakaran: i think you need to subscribe the charmers team to your bug
<tvansteenburgh> Prabakaran: i subscribed charmers for you, so your bug should show up in the Review Queue shortly
<Prabakaran> Thanks <tvansteenburgh>
<firl> any openstackers on able to help me diagnose something?
<catbus1> firl: Hi, if you ask the question about the specific issue you encounter, chances are higher for someone who can help to respond.
<firl> catbus1, yeah I am trying to diagnose why I canât spawn an instance and see the actual log file still, but havenât been able to get anything more than a vague python error
<catbus1> firl: so you have got openstack cloud deployed using juju, and are you using juju to deploy a workload to this openstack environment? or are you using openstack dashboard to try to launch an instance?
<firl> I have a juju deployed kilo setup
<firl> last night I had to reboot the state machines
<firl> and now when I launch a vm from horizon I get this error:
<firl> http://pastebin.com/RZjcMzUz
<firl> been trying to find the issue in the log files, but 42 nodes and multiple log files lends it self to taking a while
<catbus1> firl: Thanks for the error info. I personally can't help.. wait to see if others on this channel can help.
<firl> :)
<firl> it might be related to neutron / rabbitmq but no idea how to make sure
<catbus1> firl: do you think this is related to Juju? if it's openstack kilo, wanna also check #openstack for help?
<firl> I was hoping from the juju side to help figure out how to diagnose it since the bundle created it, and I can upgrade via juju if there is a patch etc
<firl> but no I haven't
<catbus1> understood.
<firl> like, I think itâs rabbitmq but I donât know how to check the credentials because I didnât set it up juju did
<catbus1> firl: can you share the kilo bundle yaml file you used?
<firl> http://pastebin.com/T9uE9yJB
<bdx> hey whats going on? Quick question on deploys using enable-local-dhcp-and-metadata....
<bdx> If enable-local-dhcp-and-metadata is set, then floating ip assignment can't happen, because no neutron router right?
<bdx> and well to add to that, neutron routers can't exist either right?
<bdx> core, dev:^^
<bdx> any takers^^?
#juju 2015-11-04
<Prabakaran> Hello Team, I have created a new bug for my charm and after linking bug id to the trunk branch in the lauchpad. As discussed over the IRC chat i have subscribed bug to charmer and it has been more than 12 hrs even though my charm is not reflecting in the review queue. Please advise on the same.
<stub> tvansteenburgh: I think the review queue is stuck
<firl> any openstack charmers on:"
<firl> ?
<Prabakaran> Hello Team, I have created a new bug for my charm and linked that bug id to the trunk branch in the lauchpad. As discussed over the IRC chat i have subscribed bug to charmer and it has been more than 12 hrs still my charm is not reflecting in the review queue. Please advise on the same.
<marcoceppi> firl: o/
<marcoceppi> Prabakaran firl stub the review queue does appear stuck. Unsticking
<marcoceppi> Prabakaran: rebooted the review queue, it's processing the backlog now
<firl> hey marcoceppi
<firl> I have found a weird state in which it seems the openvswitch-agent doesnât pick up the rabbitmq connection
<firl> I am upgrading to the latest version of openvswitch-agent to test it
<marcoceppi> firl: that's weird, an openstack chamer would be best. I just now realized thats what you asked for
<firl> :)
<marcoceppi> firl: they should be on in a few hours
<firl> cool
<Prabakaran> Hey Marco, I am able to see old charms now but my new charm is not reflecting in the review queue. Could you please check on this?
<bloodearnest> In the juju state server, what is the 'local' mongodb database for, and why is in >1Gb (and growing), when all other db's are 10s of Mbs? This is with manual provider.
<bloodearnest> seems it the oplog for replication. Which is odd, as I only have one state server. Can I disable replication? Or reduce oplog size (set via the cli to 512)
<bloodearnest> looks like agent config files support setting oplog size explicitly (local provider sets it to 1Mb). Is there anyway to set this in the environment config?
<bloodearnest> (this is a development setup)
<blahdeblah> Hi all - quick Q: is it possible to configure juju in such a way as to use LXC containers on a remote machine?  (Sort of like a combination between the local provider and the manual provider?)
<blahdeblah> Basically I want to have a big box (whether VM or bare metal - it doesn't really matter) that hosts all my containers for juju deployments, but I want to control it from juju on my laptop.  Is that possible?
<rick_h__> blahdeblah: so you've got hte gist of it currently. You'd have to setup the lxc containers and add them with manual as 'machines'
<rick_h__> blahdeblah: the team is working on adding lxd support which will be single host, but with lxd it's possible to come back in the future and allow those lxd containers to be on another machine since lxd can handle that for us
<blahdeblah> rick_h__: I don't want manual; I want it to be able to spin up containers automatically like it does with the local provider.  So that will need to wait for a full-fledged lxd provider?
<rick_h__> blahdeblah: but the work for this cycle is just the single host scenario unfortunatley
<rick_h__> blahdeblah: yea, really lxd provider 2.0, 1.0 is in progress now
<rick_h__> blahdeblah: it is a use case that's come up, you're ahead of us on it
<blahdeblah> rick_h__: so the only currently-available driver that will allow automatic container creation is the local provider?
<rick_h__> blahdeblah: yes
<rick_h__> blahdeblah: the lxd one will be in 1.26 scheduled for release in jan
<rick_h__> blahdeblah: should be in beta ppa in dec
<blahdeblah> I guess I can work around that by just doing the juju on that other box
<rick_h__> blahdeblah: hmm, commision that machine in maas and have juju on one machine ask maas for the lxc containers?
<rick_h__> blahdeblah: just to add more stuff to the mix
<blahdeblah> rick_h__: I thought about that, but I don't really want the overhead; I might just run it with the local provider and work remotely
<jam> blahdeblah: so with manual you should be able to "juju add-machine 10.10.10.10" and that gets added as say machine-1
<jam> then you can
<jam> juju deploy --to lxc:1
<jam> and it will create an LXC instance on machine-1
<jam> that actually lets you get to a point where you have more than one of these big machines, but you still have to tell us where you want the container to exist
<jcastro> anyone have the variable handy to force juju to show the new status by default?
<rick_h__> jcastro: not sure but filed https://github.com/juju/docs/issues/728 to get it added to the docs
<rick_h__> natefinch: wwitzel3 do you recall? ^
<jcastro> marco has it memorized but he's in japan still
<rick_h__> yea, I've seen it but not set it so not in my shell history
<Prabakaran> Hey Marco, I am able to see old charms now but my new charm is not reflecting in the review queue. Could you please check on this?
<Prabakaran> Hello Team, Could someone help me on this?
<bloodearnest> blahdeblah, I think you just need to do juju bootstrap remotely. After then, assume all the ports are accessible, then the juju client should be able to control that local env remotely
<wwitzel3> jcastro: JUJU_CLI_VERSION=2
<jcastro> ta
<arosales> kjackal: welcome to the juju channel
<arosales> kwmonroe: cory_fu: admcleod- ^ kjackal will be woking on big data with you
<kwmonroe> woohoo - welcome kjackal!
<Prabakaran> Hey Marco, I am able to see old charms now but my new charm is not reflecting in the review queue. Could you please check on this?.
<admcleod-> kjackal: welcome
<cory_fu> kjackal: Sorry, was in a UOS session.  Welcome!
<Prabakaran> Hello Team, Newly submitted charm is not reflecting in the charm review queue. Please advise on this.
<Icey> I just tore down an amazon environment and have re-bootstrapped and deployed charms, they have been 'allocating' now for over 10 minutes
<Icey> juju's debug logs just show  error fetching public address: public no address]
<Icey> over and over
<cory_fu> Prabakaran: Can you provide a link to your charm?
<cory_fu> And the bug report
<Prabakaran> My charm link is https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-platform-rtm/trunk
<Prabakaran> Bug link is https://bugs.launchpad.net/ibmcharms/+bug/1510216
<mup> Bug #1510216: New Charm: IBM Platform RTM <IBM Charms:New> <https://launchpad.net/bugs/1510216>
<firl> anyone know if there is an easy way to tell the juju client to re run all the config values on a host?
<firl> for example: I have to ssh into a machine and tell it to reload via âsudo service jujud-unit-neutron-openvswitch-21 restart"
<Icey> cannot start instance for machine "1": tagging root disk: timed out waiting for EBS volume to be associated
<cory_fu> tvansteenburgh: Do you by chance have access to the RQ?
<Prabakaran> Is there any changes in the process of creating a bug and subscribing to a charmers group as my new charm is not reflecting under review queue.
<lazypower> Prabakaran : no change in process so far.
<lazypower> Prabakaran: Marco restarted the revq ingest, and it may be several hours behind. We'll be tracking this, as marco is in Japan. once he's available we'll circle back and check on the RQ status of your bug. Thanks for teh bug link, we'll use it to cross reference
<jamespage> narindergupta, hey - around?
<narindergupta> jamespage: yeah
<jamespage> narindergupta, looking at https://code.launchpad.net/~nuage-canonical/charms/trusty/nova-compute/next/+merge/276669
<jamespage> is that change related to the query you sent me via email last week?
<narindergupta> jamespage: yes
<jamespage> narindergupta, was that specific to an openstack release?
<narindergupta> jamespage: nuage mentioned that its needed for kilo as well
<jamespage> narindergupta, it is but its probably been working in kilo OK as the old deprecated option had not been removed
<narindergupta> jamespage:
<narindergupta> jamespage: what are deprecated options?
<narindergupta> jamespage: i can look for those options with Nuage.
<jamespage> narindergupta, the change is fine - the openstack projects normally support old configuration options for a few cycles when the get moved around
<jamespage> so before this was a DEFAULT section item (neutron_ovs_bridge=alubr0) now its a section config option
<jamespage> narindergupta, anyway its landed
<narindergupta> jamespage: could be but thanks
<jamespage> narindergupta, it is :-)
<narindergupta> but i am sure other plugin might face similar issue
<narindergupta> jamespage: thanks
<jamespage> narindergupta, just an observation - but no need to resubmit merge proposals every time you push to a branch - the existing MP will be updated automatically
<narindergupta> jamespage: ok thanks for letting me know. I was unaware about this feature.
<jamespage> narindergupta, ok I've landed all of the merge proposals you detailed earlier
<narindergupta> jamespage: thanks james
<narindergupta> jamespage: i will update nuage accordingly
<narindergupta> jamespage: i have meeting with Subu today evening and will ask to update the nuage specific review comments as well.
<tvansteenburgh> cory_fu: no i don't
<Prabakaran> Thanks  <lazypower>
<aisrael> tvansteenburgh: Just ran into a bundletester dependency issue: http://pastebin.ubuntu.com/13105165/
<aisrael> Fresh vm, after I ran `pip install bundletester`
<aisrael> and a different error after I manually installed it: http://pastebin.ubuntu.com/13105175/
<aisrael> I fixed that with `pip install -U bundletester`, but then ran into http://pastebin.ubuntu.com/13105186/
<aisrael> Am I installing it wrong?
<tvansteenburgh> aisrael: charmbox installs it via pip https://github.com/juju-solutions/charmbox/blob/master/install-review-tools.sh
<aisrael> tvansteenburgh: Odd. Maybe I missed installing one of the dependencies. After I finish with rq, I'll wipe the machine clean and reinstall and see if I can recreate it
<tvansteenburgh> aisrael: run bundletester with -Fvl DEBUG instead
<tvansteenburgh> aisrael: it should install its own deps
<aisrael> tvansteenburgh: ack, thanks
<tvansteenburgh> aisrael: i just ran bundletester inside the latest charmbox, no errors
<tvansteenburgh> aisrael: the -v should give you more output, hopefully that'll help
<urthmover> the first node that I am attempting to add is outputting iscsistart cannot make a connection to 10.43.201.11:3260 (-1,101)  during the PXE boot process.  How do I fix this?
<urthmover> I'm booting the 14.04 LTS amd64 image
<urthmover> the maas server does appear to be listening tcp        0      0 0.0.0.0:3260            0.0.0.0:*               LISTEN      -                off (0.00/0/0)
<urthmover> I was able to create a private network within vmware and once the gateway was available PXE worked and I'm at a login prompt
<urthmover> can I run juju without using the wakeonlan fuctionality, I do not mind having every node on all the time ?
<opencell> Hi
<urthmover> hey
<opencell> i create a charm for my open source billing software : https://github.com/opencellsoft/juju-charms
<opencell> to use it i need to deploy postgresql charm
<opencell> then to add-relation between opencell and postgresql
<opencell> my question is about add-relation
<opencell> if i do "juju add-relation opencell postgresql:db" before opencell charm is fully deploy, it don't work
<opencell> so my question is : is there a way to wait that charm deploy is finish before do the add-relation  ?
<opencell> for information at the end of my install hook, i've add : status-set blocked "Waiting for active database connection"
<thumper> opencell: hey there
<thumper> with juju 1.24 and above, the unit can set its status, along with a message
<thumper> so when the install hook runs, it can download and install bits it knows it needs but not start the service
<thumper> and leave a message saying it is blocked until the postgres relation is added
<thumper> make the actual starting not happen until the db hook joined gets called
<thumper> hmm, just finished reading all you said
<thumper> yes, yours status-set is the right thing
<thumper> I'm not sure what you mean by not worknig if you add relation before it is deployed
<thumper> the hooks are called in a defined order
<urthmover> Is it possible to run juju without the power functionality.  I'm inside of a hosted vmware environment and do not have shell access to the ESX5.5 hosts.
<opencell> sorry thumper
<opencell> what i do is juju add-relation opencell postgresql:db when charm message is Waiting for agent initialization to finish
<thumper> that should be fine
<opencell> hum my bad, really sorry ... i try to reproduce again, but all is fine
<opencell> sorry again to disturb, i'm beginner with juju, so i was maybe do something wrong before add-relation. Thx a lot for you're time and long life to juju witch is a great tool !
#juju 2015-11-05
<gennadiy> hi all, i have to use juju-reboot command in the end of install hook. but i got error - juju.worker.uniter.context context.go:559 updating agent status: cannot set invalid status "rebooting"
<gennadiy> in the log file
<gennadiy> is it ok?
<jam> gennadiy: that sounds more like you are calling "status-set rebooting" before you call "juju-reboot". Is that true?
<gennadiy> no
<jam> the syntax for status-set would be: status-set maintenance "rebooting"
<gennadiy> i think this command tries to setup it
<jam> hm, nm, it does look like rebooting is one of the status codes
<jam> gennadiy:
<jam> sorry, can you do "juju status" and pastebin it?
<gennadiy> also if you try to use `juju-reboot -now` - install process will be infinite
<jam> It sounds like there might be a version mismatche.
<gennadiy> juju version - 1.25.0-trusty-amd64
<gennadiy> currently juju status of my service is started. but i see the error in log of unit
<gennadiy> 2015-11-05 08:07:49 ERROR juju.worker.uniter.context context.go:559 updating agent status: cannot set invalid status "rebooting" 2015-11-05 08:07:49 ERROR juju.worker.uniter.filter filter.go:137 tomb: dying 2015-11-05 08:07:49 ERROR juju.worker runner.go:212 fatal "uniter": machine needs to reboot 2015-11-05 08:07:49 ERROR juju.api.watcher watcher.go:84 error trying to stop watcher: connection is shut down 2015-11-05 08:07:49 ERROR juju.api.watcher watcher.g
<gennadiy> it's agent.conf grom machine
<gennadiy> tag: machine-162 datadir: /var/lib/juju logdir: /var/log/juju nonce: machine-0:3538ecd9-69aa-4c7f-840f-77857c0dc303 jobs: - JobHostUnits upgradedToVersion: 1.24.6
<gennadiy> seems we use different version of juju master and juju agents
<gennadiy> am i right?
<gnuoy> jamespage, fwiw I can't create the openvswitch-odl to neutron-gateway relationship with standard amulet, amulet refuses to create a relation when the interface isn't specified and juju refuses to create a relation when the interface is specified on both sides if that interface is juju-info
<sto> I'm trying to deploy openstack liberty with juju and my installation is unable to finish because I can't configure keystone... my problem is the same as the one described in https://bugs.launchpad.net/charms/+source/keystone/+bug/1509382
<mup> Bug #1509382: shared-db-relation-changed hook failure, unable to establish connection http://localhost:35347/v2.0/tenants <oil> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1509382>
<sto> Any hints?
<matt_dupre> Hi - I'm working on some OpenStack charms, and I've got a problem with the nova-compute charm where I'm not sure what the right solution is
<matt_dupre> I need to install nova-api-metadata (in another charm), but the neutron_plugin_changed hook on nova-compute is purging it when metadata-shared-secret isn't set
<firl> anyone on that knows how to set the http proxy for apt with maas 1.8?
<lazypower> matt_dupre: this sounds systemic with managing config in the wrong charm. Are you sending the data you need over the neutron_plugin interface so it can be rendered?
<lazypower> matt_dupre: if not, can you send a quick mail to the list that I can direct the OpenStack charmers team at to follow up on? I know that most of the openstack charms manage the config files so there's no conditions like you're outlining above, where nova is wiping your plugin config
<lazypower> actually matt_dupre - a bug would be best
<lazypower> matt_dupre - https://bugs.launchpad.net/charms/+source/nova-compute/+filebug
<matt_dupre> lazypower: Thanks - can I just check exactly what you think is wrong?
<matt_dupre> I'm still trying to figure out exactly which components have responsibility for which bits of metadata
<lazypower> matt_dupre There's nova-api/neutron-api interfaces to send config data over, so the openstack charm in question manages that template file
<lazypower> if it doesn't get the bits it needs to manage, it will overwrite anything you do in your subordinate, when it re-runs its template generator
<lazypower> stokachu i'm moving us here, as we're talking about some stuff that the public will find interesting (hopefully) - looking @ interface layers, and writing reactive charms
<stokachu> lazypower: ok cool
<stokachu> going to try and reproduce the add-unit issue with global relation scope
<gennadiy> hi all, i know if we try to deploy bundle by juju-gui it will not expose services(juju gui ignore expose: true). a few days ago it was confirmed in this channel too. but i can't find link to this bug. can somebody help me with this?
<lazypower> o/ gennadiy
<lazypower> gennadiy: it doesn't appear that it was filed - https://bugs.launchpad.net/juju-gui?field.searchtext=expose
<lazypower> stokachu cory_fu - so for reference, we're talking about https://pythonhosted.org/charms.reactive/charms.reactive.relations.html#charms.reactive.relations.scopes
<stokachu> <cory_fu> stokachu: Regardless of the scope, handlers on each unit should still fire.  Also, handlers should still fire for each unit that's added to the conversation, though the data on the conversation may not change (and if the interface layer or handlers skip on no change, they could be filtered out that way)
<stokachu> cory_fu: ok, im going to try to reproduce this on a clean environment
<stokachu> i was getting install hook failures because my nodejs event wasn't being acted on
<cory_fu> Right.  Conversation scopes are only about how the units data are grouped and not how handlers are triggered.
<stokachu> so something else is going on?
<lazypower> ah, cory_fu  - i thought you could negate some of the bheavior with scopes
<lazypower> my mistake
<cory_fu> Conversation scopes are definitely confusing.  Each state set by an interface layer is associated with a conversation.  The conversation can include one or more related units.  When a state handler is triggered, the Relation class contains a list of all the conversations that the state applies to, and each conversation has a list of related units that it includes.  Any data sent out to a conversation has the same data sent to all related units, and
<cory_fu> the data coming in from a conversation is aggregated across all units (expected to be the same, or not set for all but one of the units)
<lazypower> cory_fu : we need you + a white board + video/audio feed
<cory_fu> The idea is that the relation is a two-way evolving conversation between the two endpoints.  And different units can be at different stages of the conversation.  But sometimes it makes sense to group units of a service into a single conversation.  And sometimes you fully expect to only be having a single conversation.
<lazypower> Very true And I like that we now have sopes for relation conversations
<lazypower> having an illustration of what units are participating, and how, would be helpful to illustrate the scopes
<cory_fu> One important point to note is that conversations are about the communication protocol, and thus should be entirely handled by the Relation class in the interface layer.  They should *never* be exposed outside of the interface layer.
<lazypower> Right, at that oint you're only working with a databag that has the data points
<lazypower> or is waiting to receive the data points to relay over the wire
<cory_fu> To the charm layers, i.e., the state handlers, the Relation class should provide a meaningful API.  So you should be able to ask it things like "What databases are being requested and by whom" or "What datanodes are currently registered"
<stokachu> ok looks like i can't reproduce the add-unit issue
<stokachu> so far all units are handling my nodejs reaction properly
<cory_fu> stokachu: What layers is this involving?
<stokachu> cory_fu: includes: ['layer:basic', 'layer:nodejs', 'layer:nginx', 'interface:mysql']
<stokachu> cory_fu: and this https://github.com/battlemidget/juju-layer-ghost/blob/master/reactive/ghost.py
<stokachu> is the top level one
<cory_fu> stokachu: Which handler were you seeing not trigger?
<cory_fu> And what were you doing an add-unit on?   The ghost charm?
<stokachu> cory_fu: well it looks like it is triggering on this run, but my upstart service is in a infinite loop
<stokachu> cory_fu: yea add-unit -n 3 ghost
<stokachu> the nodejs.install_runtime wasn't being called on my previous deploy
<stokachu> and node wasn't available
<cory_fu> stokachu: I'm a little confused by how the nodejs and nginx layers are structured.  Is there ever a case where you would be using those layers but not want nginx or nodejs installed?
<stokachu> cory_fu: dont quite follow
<cory_fu> The point of these layers is to provide nginx and nodejs.  Why do you have them blocking install until the lower layer explicitly requests it?
<cory_fu> I would expect each of those layers to just handle the install hook and install the software.
<stokachu> i was having issues where the install hook was being requested in a loop
<stokachu> so i put the install hooks in the topmost (ghost) layer
<stokachu> and just left reactive states in the other layers
<stokachu> also if i have an install hook in the nginx layer and an install hook in the ghost layer
<stokachu> how will they react?
<cory_fu> As long as you're using charms.reactive.hook in a file under reactive/, they should work together just fine, though you won't be able to determine which runs first
<stokachu> so that's my problem as ghost was running prior to nginx install hook
<cory_fu> Also, a given @hook block should only get called once per Juju hook invocation
<stokachu> so if i have 2 install hooks in 2 seperate layers does that count as 1 juju hook invocation?
<stokachu> without being able to call install hooks for each layer seperately i can't build on the previous layer
<stokachu> so i have to rely on calling out reactive states
<cory_fu> @hook handlers are just like state handlers, except that they run before any state handlers.
<cory_fu> You can have multiple, from any layers, and they will all be called
<stokachu> but if my ghost hook handler runs before the nginx one
<stokachu> how will i know when nginx.available is set
<cory_fu> In general, you probably don't want to have @hook handlers in your charm layer, with the exception of config-changed
<cory_fu> You just want to have a @when('nginx.available')
<stokachu> so my charm layer being ghost?
<cory_fu> Right
<stokachu> and what about nginx layer
<stokachu> that has the install hook?
<cory_fu> Sure.  As can the nodejs layer
<stokachu> ok lemme try that
<cory_fu> Have you looked at how I did the apache-php layer?  https://github.com/johnsca/apache-php
<stokachu> yea that's what i was basing it off of
<stokachu> but i was hitting problems as described above
<stokachu> things firing and reinstalling the ghost application ina  loop etc
<cory_fu> My guess is that you need to add a @when_not('ghost.installed') or @only_once to prevent that
<stokachu> ah ok
<stokachu> cory_fu: one last thing, can i have 2 seperate @when decorators for a single method
<stokachu> to reprenset or?
<cory_fu> Because state handlers will get re-run every time if their conditions are met.
<cory_fu> You can, but it's always and.  There's no way to say @when(A or B)  :(
<stokachu> ok that may be a nice feature to request
<cory_fu> I'll probably be adding a @when_any
<stokachu> cory_fu: and are conditions persisted
<cory_fu> stokachu: Yes, states are persisted until being removed.  This is so that states set by relations are persisted until all required relation states are met
<cory_fu> You can remove a state at any time, though, with remove_state.  But a given layer should only remove states that it set
<stokachu> ok makes sense
<stokachu> that may be my problem to with things running in a loop
<cory_fu> (Or that it is using as a communication channel, possibly)
<stokachu> so if i run juju deploy, juju upgrade-charm
<stokachu> any state that isn't removed is persisted
<stokachu> ?
<cory_fu> Yes
<stokachu> ok good to know, is that documented?
<stokachu> i may file a bug on it
<jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYfzoBSPiWHfP96qjEEawO6jFVkMeJg1WPdT6LbMApFNuQEvMA?hl=en&authuser=0
<jcastro> we're having an office hours in 5 minutes if anyone wants to join!
<cory_fu> stokachu: I guess it's not explicitly called out, no
<dweaver> marcoceppi_, where were all the benchmarking charms you used in the demo, e.g. siege, collector?
<lazypower> dweaver - here's the siege charm itself - https://github.com/juju-solutions/siege
<dweaver> lazypower, thanks
<lazypower> dweaver - The collector + gui for benchmark ui (bui) - will be released soon. I'm sure we will announce to the list when that happens
<urthmover> bootstrapping juju errors out with "/var/lib/juju/tools/1.25.0-trusty-amd64/tools.tar.gz: No such file or directory\nERROR failed to bootstrap environment: subprocess encountered error code 1" http://paste.ubuntu.com/13114841/
<urthmover> Can anyone help me with this issue?
<stokachu> urthmover: (7) Failed to connect to streams.canonical.com port 443: Connection timed out\ntools from https://streams.canonical.com/juju/tools/releases/juju-1.25.0-trusty-amd64.tgz
<stokachu> make sure you've setup networking properly for MAAS
<stokachu> a common problem is not enabling IP Forwarding on the MAAS server
<stokachu> https://wiki.ubuntu.com/OpenStack/Installer/debugging/multi-install
<urthmover> stokachu: thank you...checking
<urthmover> stokachu: I'm applied that nat'ing  retrying the juju bootstrapping.  Is there a way to test if it's working properly before I wait around for the install to finish?
<stokachu> urthmover: you can do a simple juju boostrap outside of the installer
<stokachu> urthmover: https://jujucharms.com/docs/1.25/config-maas
<urthmover> stokachu: ok...(looking up that syntax)
<urthmover> stokachu: awesome thanks for the link
<stokachu> np
<stokachu> run juju boostrap --debug
<stokachu> cory_fu: you mind doing a quick lookover my two layers, https://github.com/battlemidget/juju-layer-nginx and https://github.com/battlemidget/juju-layer-node
<stokachu> i did some refactoring
<cory_fu> Sure
<stokachu> cory_fu: i also updated https://github.com/battlemidget/juju-layer-ghost/blob/master/reactive/ghost.py to make use of the 2 emitted states from nginx and nodejs
<stokachu> but it doesn't seem to be firing, the config-changed hook is run for the ghost charm though
<urthmover> stokachu: dude you're a genius....I think it' just went farther....scheeeet
<urthmover> schWeeeet
<stokachu> urthmover: haha
<urthmover> :)
<cory_fu> stokachu: Your nodejs layer is setting 'nodejs.available' but your ghost layer is looking for 'nodejs.installed'
<stokachu> urthmover: if that works then you can destroy the environment and re-run the installer
<stokachu> cory_fu: crap
<cory_fu> But otherwise it looks really good
<urthmover> stokachu: actually this is re-running the installer......goes pretty fast cause it's all on a local vmware workstation instance (locally)
<stokachu> cory_fu: ok cool thanks :)
<cory_fu> Although
<urthmover> stokachu: the only goofy part   (as I test this) is I have to manually start the machines...cause wakeonlan doesn't work right
<cory_fu> You also need to add a state to indicate that ghost is installed, or add @only_once to the install handler
<stokachu> cory_fu: so https://github.com/battlemidget/juju-layer-ghost/blob/master/reactive/ghost.py#L49 add @only_once decorator additionally?
<cory_fu> Yep
<stokachu> ok cool
<stokachu> cory_fu: do you have any example on using only_once?
<stokachu> urthmover: yea that sucks, if you use straight bare metal with KVM it supports virsh so you don't have to manually power on/off those vm's
<stokachu> assuming you aren't on awindows machine
<stokachu> cory_fu: like this: http://paste.ubuntu.com/13115254/
<stokachu> ?
<urthmover> stokachu: Here;s a highler level question for you then, I use a vmware cluster that is controlled by a hosting provider.  I have fullish vcenter access, but not api or cli access.  I'm able to build guests at will.  How would you reccomend I build out this environment to support openstack and containers(docker, rkt)?
<stokachu> urthmover: so MAAS supports VMware as a power type so that may be your best bet for utilizing that
<urthmover> stokachu: my only mission is to support self contained *nix "server/containers" so that developers can have root install their software, run their apps, and probably break'm often.  I'm trying to move away from monolithic web servers that I'm not willing to give up root access
<stokachu> as for the layout just make sure your VMS have 2 disks and 2 nics
<stokachu> i think autopilot is a minimum of 5-6 servers all having 2 disks and 2nics
<urthmover> stokachu: from what little that I've read though, you need cli or api access to control vmware from maas
<stokachu> urthmover: sec lemme ask
<urthmover> stokachu: if building a case to request this from the hosting provider is necessary to gain cli/api access, I'm willing to do that, but the process is long and turn around on those changes take months with this big stupid provider
<urthmover> stokachu: thank you
<urthmover> stokachu: I'm not opposed to keeping all the time if that makes a difference
<cory_fu> stokachu: Yep!
<stokachu> cory_fu: perfect thanks
<stokachu> urthmover: so far maas supports vmware workstations, esxi
<stokachu> urthmover: im still waiting on what is supported vcenter wise
<stokachu> and what the requirements are (if its only cli atm)
<urthmover> stokachu: ok
<urthmover> stokachu: perfect..thank you very much for asking
<urthmover> stokachu: I joined #juju-dev thinking maybe the conversation is in there
<stokachu> urthmover: nah you want #maas
<urthmover> stokachu: ok cool I'll jump in there
<stokachu> and montpillo is the guy who knows
<urthmover> stokachu: I'll watch for him to speak up  thank you a bunch for your help thus far
#juju 2015-11-06
<stokachu> how long does it take for a namespaced bundle to show up on my account?
<stokachu> it's been 3 hours
<lazypower> stokachu: you may need to file a bug, we had issues last week where bundles weren't getting ingested
<stokachu> ah ok
<stokachu> is that jujucharms.com?
<lazypower> Yep
<lazypower> stokachu - I am in no way prepared for whats coming in 7 minutes :D
<stokachu> haha
<stokachu> we could wing it
<lazypower> Always do
<lazypower> the magic is in post anyway ;)
<stokachu> :D
<lazypower> https://plus.google.com/hangouts/_/canonical.com/stokesisawizardandweregoingtoshowyouhow
<gennadiy> hi all, i have returned with my question about deploy bundle from juju gui. i have checked it again and my services are not exposed after bundle deploy. is it known issue?
<jeand> hi all
<jeand> I pushed some changes to https://code.launchpad.net/~jean-deruelle/charms/trusty/mobicents-restcomm-charm/trunk
<jeand> but I don't see the charm updated on https://jujucharms.com/u/jean-deruelle/mobicents-restcomm-charm/trusty/#revisions
<jeand> while the changes to https://code.launchpad.net/~jean-deruelle/charms/bundles/mobicents-restcomm-mysql-bundle/bundle
<jeand> were taken https://jujucharms.com/u/jean-deruelle/mobicents-restcomm-mysql-bundle/bundle/5/
<jeand> does anyone have any clue  on why this may be happenin ?
<jamespage> tvansteenburgh, morning - quick question for you regards use of specific branches from git repositories in juju-deployer
<jamespage> I'm trying todo:
<jamespage>     openstack-dashboard:
<jamespage>       branch: https://github.com/openstack-charmers/charm-openstack-dashboard@stable
<jamespage> but right now that's not working so great - is that the right syntax?
<tvansteenburgh> jamespage: looking...
<jamespage> tvansteenburgh, http://paste.ubuntu.com/13124372/
<jeand> <jeand> hi all
<jeand> <jeand> I pushed some changes to https://code.launchpad.net/~jean-deruelle/charms/trusty/mobicents-restcomm-charm/trunk
<jeand> <jeand> but I don't see the charm updated on https://jujucharms.com/u/jean-deruelle/mobicents-restcomm-charm/trusty/#revisions
<jeand> <jeand> while the changes to https://code.launchpad.net/~jean-deruelle/charms/bundles/mobicents-restcomm-mysql-bundle/bundle
<jeand> <jeand> were taken https://jujucharms.com/u/jean-deruelle/mobicents-restcomm-mysql-bundle/bundle/5/
<jeand> <jeand> does anyone have any clue  on why this may be happenin ?
<tvansteenburgh> jamespage: try it with a commit hash
<jamespage> tvansteenburgh, hmm ok - but I really need to be able to track a branch as it changes
<tvansteenburgh> jamespage: right, i think that would be a new feature. was just curious if it works with a sha
<jamespage> tvansteenburgh, no cigar with an sha either...
<jamespage> tvansteenburgh, I think you're correct in that its a new feature
<jamespage> tvansteenburgh, any thoughts on syntax in the bundle?
<tvansteenburgh> jamespage: there are test cases for the path@rev syntax using both a sha and a tag :/
<jamespage> odd
<tvansteenburgh> jamespage: i'd stick with that syntax. not sure what's broken
<jamespage> jeand, if you charm update has any charm proof errors, it won't injest into the charm store - that might be why
<tvansteenburgh> jamespage: i think it's b/c the git clone uses --depth 1, so when it tries to update to the specified rev, it's not there
<jamespage> tvansteenburgh, you may well be right
<jamespage> tvansteenburgh, fwiw - git clone -b stable --depth 1 https://github.com/openstack-charmers/charm-ceilometer
<jamespage> does the right thing ...
<jamespage> ddellav: hey - when do you think you might have the port security MP up for review?
<jamespage> I'd like to get that landed asap
<jeand> jamespage, juju charm proof ./ worked
<jeand> correctly
<jeand> jean@jean-XPS13-9333:~/workspaces/juju-charms/mobicents-restcomm-charm/trusty/mobicents-restcomm$ juju charm proof ./
<jeand> jean@jean-XPS13-9333:~/workspaces/juju-charms/mobicents-restcomm-charm/trusty/mobicents-restcomm$
<jeand> jamespage, any other clues ?
<jamespage> jeand, urm sorry no
<jeand> what's the proper way to get more insights on this ?
<jeand> is there a juju charm store support channel ?
<lazypower> jeand - there is, 1 second let me fish up a link for you
<lazypower> jeand - you'll file a bug with the details you outlined above and someone will take a look to see why its not ingesting
<jeand> ah great
<jeand> thx lazypower
<lazypower> jeand - https://github.com/CanonicalLtd/jujucharms.com/issues
<gennadiy> hi all, i have returned with my question about deploy bundle from juju gui. i have checked it again and my services are not exposed after bundle deploy. is it known issue? it's my bundle to reproduce issue - https://jujucharms.com/u/tads2015dataart/#bundles
<lazypower> gennadiy - looking at your bundle here: http://bazaar.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle/view/head:/bundle.yaml
<lazypower> you have an incorrect key. THe proper key is 'exposed: true' - its past tense
<lazypower> gennadiy: update that key, give it another go and let me know if you run into the same behavior
<gennadiy> oh. i copied it from exported from juju-gui bundle.
<gennadiy> there are `expose: true`
<lazypower> gennadiy: if that fixes you up i'll file a bug against juju-gui to take a look
<gennadiy> i will try
<gennadiy> just a moment
<lazypower> it may be an artifact/missing test coverage, etc.
<gennadiy> but when i deploy this budnle from juju deployer services are exposed
<lazypower> gennadiy - yeah, thats definately a bug
<lazypower> if its exporting a syntax it doesn't handle
<lazypower> 1 sec and i'll pass along a bug reporting link for you
<lazypower> gennadiy https://bugs.launchpad.net/juju-gui/+filebug
<amz> is m3.medium the new default instance for ec2 as stated here: https://bugs.launchpad.net/juju-core/+bug/1373516/comments/7 by natefinch
<mup> Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Fix Released by cherylj> <juju-core 1.24:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1373516>
<natefinch> amz: yes
<amz> how to list current ec2 environments settings for default instance ?
<natefinch> amz: it's totally based on juju version.  if you're on 1.25 or higher, it's m3.medium, if you're on 1.24.x or lower, it's m1.small
<amz> natefinch: it would be good to document new default on https://jujucharms.com/docs/stable/config-aws
<natefinch> amz: absolutely a good idea.
<amz> natefinch: how to check current settings? is it really only related to version and no way to list current settings?
<natefinch> amz: version is the only way.  It's not an exposed configuration value, per se.  You can override the default by specifying an instance-type or other constraint at bootstrap time, or by setting an environment-wide constraint after bootstrap.
<amz> thanks natefinch
<natefinch> amz: no problem :)
<stokachu> lazypower: is bin/ exposed in the PATH for reactive charms?
<lazypower> cory_fu - I'm pretty sure this landed recently, but pinging cory to confirm
<stokachu>  /var/lib/juju/agents/unit-hai2u-1/charm/bin <-
<cory_fu> stokachu: I don't think the dir is automatically added to the path, no
<stokachu> cory_fu: ok i was trying to decide whether to put scripts in its own scripts/ dir or use bin/
<stokachu> but bin may overwrite that
<lazypower> welp, i was wrong
 * lazypower hattips and ice skates away
<cory_fu> Files put in there won't overwrite your scripts unless the filenames conflict, which I highly doubt they will
<stokachu> ok cool
<marcoceppi_> $CHARM_DIR/bin ;)
#juju 2015-11-07
 * arosales forgot to put in here that I was reviewing xcat, but sent my findings to the list
<ddellav> jamespage, i missed your message earlier, here's the MP: https://code.launchpad.net/~ddellav/charms/trusty/neutron-api/ml2-port-security/+merge/276764
<rajalokan> Hey guys. Any way of deploying a juju charm from local source code instead of pulling from github.
<rajalokan> Any pointers or help appreciated.
<tvansteenburgh> rajalokan: https://jujucharms.com/docs/devel/charms-deploying#deploying-from-a-local-repository
<rajalokan> Thanks tvansteenburgh for replying. Was away so couldn't reply. But this isn't the answer I was looking.
<rajalokan> I guess I was wrong in framing the question.
<rajalokan> What I want is to deploy say OpenStack keystone, But not any distro packaged liberty release or liberty release from OpenStack github page. Rather keystone should be installed from my local source code.
<rajalokan> Was thinking if we can use juju to setup developer workstation. Apologies again for improperly framed question.
<tvansteenburgh> rajalokan: there is a "Deploying from source" section here https://jujucharms.com/keystone/trusty/31, maybe that helps?
<rajalokan> Thanks tvansteenburgh. Going though it but I remember seeing `repositories` accept only 'git' or 'bzr'. Nothing like a file system.
<rajalokan> Let me find that out.
<tvansteenburgh> rajalokan: yeah you would probably have to push your code to a public repo
<rajalokan> Yeah. seems like it. Just wanted to confirm it here. I will stick with devstack for some more while then.
<wolsen> rajalokan: you may want to touch base with coreycb on the deploy from source. Presumably the local file system it's being deployed from points to a guy repo somewhere, iirc it uses that to branch locally - theoretically you could make local edits then redeploy but I may be wrong on that. coreycb is the guy you want to talk to on it though
<wolsen> err s/guy repo/git repo - on my phone - lovely autocorrect
<rick_h__> rajalokan: tvansteenburgh we're working on something like this for this cycle
<rick_h__> rajalokan: tvansteenburgh where you can mount your local filesystem with the lxd provider to do openstack dev as you describe
<rick_h__> rajalokan: and the charms would be able to locate the source code to use off that mounted shared filesystem
<rick_h__> rajalokan: tvansteenburgh so it's not here atm, but a use case teams are working on for 16.04
<rick_h__> rajalokan: look for the lxd provider work soon (the first leg of the task) and happy to have folks test things out and see how they feel as we work along
<tvansteenburgh> rick_h__: cool, thanks. saw a demo of the lxd provider yesterday - eager to give that a spin
#juju 2016-11-07
<rock> h
<rock> Hi all. We pushed our charm to charm public store using Ubuntu SSO account. Charm will be present in store as cs:~hareeshk/kaminario-cinder-10 .  Here "hareeshk" is the account username. we removed this user account. And using same mailID we created another user account. and pushed charm to public store again. cs:~kaminario2/kaminario-cinder-0.   But in store previous pushed charm also there. We forgot to revoke the permissions of that c
<rock> How do we remove that charm from store. We tried to create same user account. But It was showing "hareeshk" username already in use. But we deleted that user account.
<rock> "hareeshk" will be stored some where in server Cache.
<rick_h___> rock: file a bug in https://github.com/canonicalltd/jujucharms.com and will mention it to the folks that manage the charmstore
<rock> rick_h__: Thank you.
<SimonKLB> how do i install the charm-terms commands? they don't seem to be in by default in charm-tools 2.1.5
<pascalmazon> Hi, I've recently reinstalled charm tools (2.1.5-0ubuntu1~ubuntu14.04.1~ppa2) on a trusty. However when I try to call `charm proof`, it complains that pip isn't the correct version: "pkg_resources.DistributionNotFound: The 'pip>=7.1.2' distribution was not found and is required by charm-tools". Any ideas?
<SimonKLB> pascalmazon: https://github.com/juju/charm-tools/issues/274
<pascalmazon> SimonKLB: oh thanks, I should have checked thereâ¦
<anrah> Hi all! I was about to ask what the prefer-ipv6 option should do and is it still available on juju 2.0?
<anrah> At least when that is set to a model nodes private-address still is ipv4
<BlackDex> Hello there. I want to know if it is somehow possible to have multiple hacluster's on one node?
<BlackDex> Currently it seems that it doesn, because haproxy isn't getting configured
<kiko> morning
<lazyPower> bdx - should i resched the elastic stack planning session?
<bdx> lazyPower: shit
<bdx> I'm so sorry
<lazyPower> bdx no worries, we'll reschedule and reconvene
<lazyPower> bdx and family friendly language *shakes a finger*
<bdx> was stuck in a  bit of traffic ... just getting in now
<marcoceppi> this is...the internet ;)
<bdx> my b
<lazyPower> i think the meeting time is a bit early for your TZ
<lazyPower> i was trying to overlap with le magicaltrout's EU TZ as well
<bdx> usually I'm online by 8
<bdx> so 9 is ok
<lazyPower> ok, would you want to try to do this again later this week?
<bdx> definitely
<lazyPower> ok, i'll send something out later today :)
<lazyPower> marcoceppi - FYI, we're blocked atm on completing that PR for the test infra. they moved some files and i'm tracking down their result munging scripts
<bdx> perfect
<vmorris> lazyPower: https://goo.gl/images/kkpQ8j
<lazyPower> that ^
<x58> charm proof is complaining I don't have any "provides", so I set a provides... and now it's complaining that I don't provide hooks for that...
<x58> Is there a way to have charm proof not complain, yet not really "provide" anything, and thus not need hooks for it.
<x58> My charm only sets information in the OS, it doesn't provide any services or anything that anyone can relate with.
<x58> What is the best way to use the juju-info interface? charm proof complains about using juju-info as the requires name, yet that is what the docs tell me to use...
<bdx> concerning juju resources, is the jujuresources pkg the recommended path to managing resources?
<bdx> I'm looking at this documentation here -> http://pythonhosted.org/jujuresources/index.html
<bdx> wondering if its current
<jrwren> bdx: that is not current for juju 2.0
<bdx> jrwren: thx, do you know of current api docs for 2.0 resources?
<jrwren> bdx: https://jujucharms.com/docs/stable/developer-resources
<bdx> jrwren: no python api tho?
<jrwren> bdx: there is a wrapper around resource-get in charmhelpers.
<bdx> other than what is offered throught hookenv?
<jrwren> bdx: I don't know.
<bdx> gotcha, ok ... just wanted to make sure I wasn't missing something here
<bdx> jrwren: thx
<bdx> cory_fu: really nice job on the jujuresources pkg and docs
<bdx> cory_fu:  would you mind updating them to indicate juju 1.x only pls
<bdx> concerning resources, does the 'upgrade-charm' hook run when `charm attach` is ran?
<jrwren> bdx: no.
<jrwren> bdx: you can run that yourself, or write an action which uses the resource and run that action.
<bdx> jrwren: I'm thinking abount a ci use case, where say jenkins might run `charm attach` following successful build of the resource
<bdx> jrwren: what you are saying is this might be best implemented having jenkins run `charm attach`, following that an action that gets and unpacks the resource
<jrwren> bdx: that is fine. it can just as easily run juju upgrade-charm or juju action run BLAH as a next step.
<bdx> jrwren: ah, so a better workflow might be; `charm attach` to get the new resource in the charm store, then `juju attach` to get the resource onto the controller, then `juju action run` to get the charm to grab the new resource
<marcoceppi> bdx jrwren yes it is
<marcoceppi> bdx jrwren when you attach resources, upgrade-charm is run
<marcoceppi> bdx: it's either charm attach, then juju upgrade-charm, or juju attach
<jrwren> oh no!
<jrwren> sorry bdx
<marcoceppi> then upgrade-charm runs for both.
<bdx> marcoceppi: oh nice, so I can just react to the upgrade-charm hook instead of a custom action following the attaching oof a new resource
<jrwren> bdx: for a CI scenario you describe, I'd skip the charmstore entirely.
<x58> I am trying to use juju-info interface as a requires to allow my charm to be a sub-ordinate, however as soon as I add the updated charm to the relation and run juju add-relation <other charm> <my charm> it says no relations found.
<marcoceppi> bdx: yeah, lazyPower has done this a lot
<marcoceppi> oh, and he left
<bdx> jrwren: but when new deploys happen, I want the charm to deploy with the latest resource
<marcoceppi> bdx: it will
<marcoceppi> bdx:  whatever is in the charm store, will get deployed
<marcoceppi> you don't need to attach post deployment
<bdx> jrwren: hence why I feel keeping the charm store resource up to date is important too
<jrwren> bdx: ok, its up to you.
<bdx> jrwren: if the charm store step is skipped, then deploying a new instance of the charm would require the user having the rescource
<marcoceppi> bdx: right, bdx I think you're on the right train of thought
<bdx> jrwren: what I'm thinking, is if its just fully left up to jenkins, then the resource is always current, and the dev/user deploying doesn't have to know or care about it
<x58> marcoceppi: I have: https://gitlab.com/bertjwregeer/juju_staticroutes/blob/master/metadata.yaml#L16 yet when I call juju add-relation ceph-osd:juju-info staticroutes:host-system it fails to work... documentation says to use "juju-info" as the requires name, but I can't push to the charmstore when I use that...
<x58> (juju says "no relations found")
<bdx> jrwren, marcoceppi: is there any juju<->jenkins plugins work currently being done, or pre-existing that you know about?
<x58> This documentation is outdated: https://jujucharms.com/docs/2.0/authors-implicit-relations (can't require juju-info...)
<marcoceppi> bdx: I'd check the mailing list, I'd just ask - I know  a few teams have done some simple stuff, but it's mostly just scripts
<bdx> marcoceppi, jrwren: also, upgrade-charm shouldn't be ran on `charm attach`, because we are only interfaceing to the charm store at that point right?
<marcoceppi> x58: I'm about to go offline, but if you don't get an answer in an hour I'll be back to take a look
<marcoceppi> bdx: it's not, but the operator i stold there's an upgrade available
<marcoceppi> bdx: charm attach -> juju upgrade-charm -> upgrade-charm hook run, new resource is available
<x58> marcoceppi: Ok...
<marcoceppi> x58: I think that should be provides....
<x58> Nope, all charms implicitly PROVIDE juju-info.
<marcoceppi> x58: is this a subordinate?
<x58> Yes.
<marcoceppi> okay, I'll be back soon
<x58> It is not explicitly listed as a sub-ordinate though... because it may also be deployed stand-alone.
<x58> marcoceppi: https://api.jujucharms.com/charmstore/v5/ntp-16/archive/metadata.yaml like this. requires juju-info.
<thumper> x58: hey there, I think this week at the planning sprint we are discussing model level subordinates
<thumper> charms that should be on all machines
<thumper> which match the need for things like ntp and other base machine tweaks
<bdx> marcoceppi: just to be clear, isn't `juju upgrade-charm` overkill if all i need is the new resource?
<bdx> which I could get with `charm attach`
<bdx> bleh
<bdx> `juju attach`
<aisrael> thumper: That would be a great feature.
<bdx> thumper: +1
<thumper> there is clearly a need for it
<x58> thumper: That doesn't help me resolve the issue right now..
<x58> thumper: I can't upload a charm that uses juju-info as the relationname under requires (like the ntp charm)
<x58> and when I name it something else, add-relation fails with "no relation found"
<thumper> x58: sure
<x58> Also... the docs on the site are out of date... which as always is fantastic.
<x58> What am I missing?
<thumper> x58: I don't believe that the system supports a charm that is both a subordinate, and not a subordinate
<thumper> I'm not sure why it is complaining about juju-info
<thumper> I'm wondering if it is considered only available for subordinates
<thumper> ?
<thumper> perhaps?
<x58> charm push .
<x58> ERROR charm "staticroutes" using a reserved relation name: "juju-info"
<thumper> if you mark the charm as a subordinate, does it work?
<x58> Now, if I change it to be subordinate... I will break existing users that are not using it as a subordinate when they upgrade...
<thumper> ah...
<thumper> poo
<thumper> perhaps you need two charms?
<x58> Yeah... no.
<x58> I really don't want to maintain two charms.
<thumper> x58: what is the intent of the juju-info relation?
<x58> To be able to add a relationship so that it is subordinate when related to an existing charm.
<x58> Without breaking existing users by removing the ability to just deploy staticroutes --to <host.
<thumper> I get a strong feeling that this is not a supported use case
<thumper> I don't think you are missing anything, I think that this use case just was never thought about
<thumper> or it was, and explicitly not supported
<thumper> but I don't know which
<x58> That'd be nice to have documented on https://jujucharms.com/docs/2.0/authors-implicit-relations
<kiko> x58, out of curiosity, what are you charming?
<x58> as well as the fact that you can't name the relation "juju-info" like it shows in that example.
<x58> kiko: adding staticroutes becaue MaaS doesn't provide a feature for us to add routes on a specific interface.
<x58> We have 3 racks of Ceph nodes.
<x58> THe backend cluster network is on a /64, I need to add a static route to a /52 on the interface for that backend cluster network
<x58> so that backend cluster traffic goes over the right interface, instead of over the default route (which is the frontend cluster interface where clients communicate)
<kiko> x58, we are doing that work this cycle, fwiw -- why don't we work together to do that in MAAS instead?
<x58> kiko: https://gitlab.com/bertjwregeer/juju_staticroutes/
<bdx> x58: not sure if this is the best way, but what I use to do was just edit the maas dhcp conf
<x58> kiko: Because I am already using it in production.
<kiko> x58, I see, it's complete already
<kiko> well
<bdx> x58: or dhcp template that maas uses
<x58> Oh yeah... I am just trying to make it a sub-ordinate.
<kiko> if it makes you feel any better, we're adding the functionality now
<kiko> because we're aware of that limitation
<x58> bdx: No DHCP used for the IPv6 network...
<bdx> oooh IPv6 .... nm
<x58> bdx: As in the MaaS server doesn't even have an interface on that network.
<kiko> bdx, how would dhcp help with static routes, though?
<x58> You can push more routes with DHCP
<bdx> yeah
<kiko> interesting
<bdx> I still have an openstack with that hack
<bdx> lol
<kiko> the more general case of not-DHCP is the killer there of course
<kiko> anyway
<x58> I really wish two things: 1. Juniper would support RFC4191 and 2. Linux would accept /52 routes from router advertisements.
<bdx> totally
<thumper> x58: how are you declaring the relation?
<x58> thumper: juju add-relation ceph:juju-info staticroutes:system-host
<thumper> x58: no, in the charm's metadata.yaml
<x58> kiko: Basically on a subnet defined on a Fabric we would need the ability to specify extra routes that are added to the networking config when the host is brought up.
<kiko> x58, yeah, ivoks has been asking for that since forever, and it's now on the plan for 2.3
<x58> kiko: Also, please please please test that everything works with IPv6...
<tychicus> I'm trying to get juju gui up and running, but it hang at "Connecting to the juju model"
<tychicus> looks like a websocket issue Uncaught DOMException: Failed to construct 'WebSocket': The URL '<no value>' is invalid.
<tychicus> are there any docs that I can consult to help me resolve this issue?
<tychicus> following instructions from here https://jujucharms.com/docs/2.0/tut-google#use-juju%27s-gui
<tvansteenburgh> tychicus: you could try `juju upgrade-gui` in case it's a bug that's been fixed
<tychicus> Juju GUI at version 2.2.2
<tychicus> if it helps it's the version that was automatically loaded when I ran juju bootstrap
<tvansteenburgh> tychicus: yeah looks like that's the latest
<tychicus> any other things I can do to troubleshoot?
<tvansteenburgh> tychicus: hatch may be able to help you
 * hatch waves
<tychicus> hi hatch
<tychicus> hatch: what information do you need from me?
<hatch> hey tychicus I hear you have an issue in the GUI?
<tychicus> correct
<hatch> I just joined, so I have no idea what's going on :)
<tychicus> Uncaught DOMException: Failed to construct 'WebSocket': The URL '<no value>' is invalid.
<hatch> oh kay, that's a new one
<tychicus> ran juju bootstrap test-maas-controller test-maas âto=test-juju.maas
<hatch> ok and then to load the gui, `juju gui` }
<hatch> ?
<tychicus> yep
<tychicus> ran juju gui --show-credentials
<hatch> hmm
<tychicus> browser renders "Connecting to the Juju model"
<hatch> can you try `juju upgrade-gui` ?
<hatch> and then try again
<tychicus> Juju GUI at version 2.2.2
<hatch> ok give me a few minutes to dig into this
<tychicus> sure
<tychicus> thanks
<hatch> tychicus: oh, what browser?
<tychicus> hatch: tried FF 49.0.2, chrome 54.0.2840.87 (64-bit), and safari 10.0.1 (10602.2.14.0.7)
<hatch> hah ok
<tychicus> safari gives a divvernt error
<tychicus> Wrong url scheme for WebSocket and SyntaxError (DOM Exception 12): The string did not match the expected pattern.
<hatch> yeah I think I know what might be causing the issue
<tychicus> ok
<hatch> could you open the browser console and copy the value in `juju_config` and pm me the values?
<tychicus> sure
<hatch> thanks
<x58> thumper: Looks like setting it as subordinate did the trick...
<x58> thumper: Think the only users are internal to $WORK, I'll just make this breaking change.
<thumper> hmm... the docs need to be more clear if juju-info is only available to subordinates
<thumper> seems a bit weird to me
<x58> Not the first time I've had issues with docs...
<bdx> concerning resources, is there a way to attach a specific revision of a resource?
<bdx> say if you wanted to roll back or something
<thumper> bdx: I would say you should be able to, but I don't know they syntax
<lazyPower> bdx - doesn't appear to be the case when using resources from the charm store. juju deploy cs:~containers/kubernetes-e2e --resource e2e_amd64=e2e_amd64-0  -- but the --resource flag seems to assume its coming from local disk
<bdx> lazyPower: do you feel this is a functionality that should exist?
<bdx> should I create a bug/feature request against charmstore, or charmstore-client?
<lazyPower> bdx - i haven't tested this, but i think the way it would work is if you rolled back to a previous version of the charm... you would get the resource thats associated with that revision of the charm.
<lazyPower> s/would work/does work.
<bdx> I see
<rick_h___> bdx: resources are revisioned just like charms and follow the released channels/etc. It should be possible.
 * rick_h___ goes to look for syntax
<bdx> lazyPower: I dont see any mapping though .. take mattermost for example `charm show cs:~cmars/mattermost` and `charm show cs:~cmars/mattermost-16` both show rev 3 for the resource
<lazyPower> bdx - its entirely possible to use the same resource between two revisions of the charm
<bdx> lazyPower: but the mapping that charmstore keeps
<lazyPower> bdx: it appears that its been the same resource since revision 8 of the charm
<lazyPower> charm show cs:~cmars/mattermost-8 resources
<lazyPower> anything  prior to that, no resource that i can see, has been associated with that charm release.
<bdx> lazyPower: I see, thx
<tychicus> hatch: sudo add-apt-repository ppa:juju/stable did the trick
<tychicus> thanks again for the help
<hatch> tychicus: glad to hear it, np
<tychicus> now to see if I can get ceph up and running :)
<hatch> good luck!
<tychicus> will juju show you all of the machines that you have commissioned in maas?
#juju 2016-11-08
<chrome0> I'm seeing "cannot resume transactions: exception: Cannot apply $addToSet modifier to non-array" repeatedly in my machine-0.log. What could be the cause of that? Cf. http://paste.ubuntu.com/23445701/
<skay_> I just noticed a snap-layer and want to install a snap as a resource. I've not written a reactive charm before, and I'm not certain when a resource becomes available. what would I pass to the @when decorator?
<skay_> '<resource name>.available'
<skay_> it's what I'd expect, but just checking
<icey> I'm having trouble bootstrapping juju2 with a local apt cache server
<lazyPower> icey what appears to be the trouble?
<icey> lazyPower: hangs at Installing curl, cpu-checker, bridge-utils, cloud-utils, tmux
<lazyPower> is the local apt cache powered by squid? if so, you can check the logs of the squid-deb-proxy
<icey> lazyPower: apt-cacher-ng
<icey> lazyPower: nothing in its logs either
<lazyPower> are you seeing any hits in the log?
<lazyPower> yeah, seems like there's potentially a misconfiguration?
<icey> lazyPower: listening on : tcp        0      0 0.0.0.0:3142            0.0.0.0:*               LISTEN      13949/apt-cacher-ng
<admcleod_> icey: presumably you have --debug ?
<icey> unless there's something stopping a lxd container from reaching a public interface on my host
<jrwren> icey: how are you bootstrapping?
<icey> admcleod_: fairly boring, --debug shows nothing after I kill it
<icey> jrwren: "juju bootstrap lxd lxd --config apt-http-proxy=http://10.0.1.99:3142 --config apt-https-proxy=http://10.0.1.99:3142 --debug"
<jrwren> icey: 10.0.1.99 does not seem right.
<icey> jrwren: that's one of the IPs for my current host
<icey> the one that lxd is running on
<jrwren> icey: ok. nevermind.
<jrwren> icey: can you ssh to machine 0 and curl http://10.0.1.99:3142 ?
<icey> jrwren: the bootstrap never finishes
 * skay_ neverminds, figured out the way to do it.
<icey> jrwren: let me attempt to redeploy and lxc exec into it
<jrwren> icey: lxc list, find the bootstrap machine and ssh with: ssh -i .local/share/juju/ssh/juju_id_rsa ubuntu@<IP>
<admcleod_> icey: maybe just incase also try setting http- and https-proxy
<icey> jrwren: seems like the lxd machine can't see the host network?! I get failed to connect with curl
<jrwren> icey: That sounds like hte problem. Now to find out why that is the case?
<icey> jrwren: mtr has no problem though
<jrwren> icey: in the container?
<icey> jrwren: yeah
<jrwren> icey: is there an iptables rule now allowing 3142 from that network?
<icey> jrwren: probably not
<jrwren> icey: is this standard lxdbr0 network config?
<icey> jrwren: it was a few months ago when I installed everything ;-)
<jrwren> icey: instead of 10.0.1.99 address, try the address from lxdbr0? `ip addr show dev lxdbr0`
<icey> adding the iptables rule makes it work on the 1.99 address
<icey> the bridge address would probably make more sense
<icey> but I'm /trying/ to build a demo method that other users woulc use and connect back to my machine for the apt cache
<jrwren> icey: Then it must be a firewall rule?
<icey> actually it still didn't work -_-
<icey> http://pastebin.ubuntu.com/23446805/
<icey> there was a bug about that already I think
<icey> regarding an iptables rule added for 8443
<jrwren> icey: that is an entirely different error. juju can't talk to lxd there.
<jrwren> icey: is lxd running?
<icey> jrwren: yeah, but the fix is still to add an iptables rule...
<icey>  sudo iptables -I INPUT 4 -i lxdbr0 -p tcp --dport 8443 -j ACCEPT
<icey> fixes it
<jrwren> icey: ok, sounds like you need the same thing for port 3142 on all interfaces.
<jrwren> icey: ubuntu doesn't default to a deny all iptables ruleset, AFAIK. I think you are somehow a bit off the rails.
<icey> jrwren: yeah, needed tro add 8443 to let juju talk to lxc, and 3142 to let juju talk to the apt cacher -_-
<icey> jrwren: I think it's from ufw ;-)
<jrwren> icey: must be. I'm surprised we don't have that better documented given how popular ufw is.
<petevg> cory_fu: here's that matrix test I mentioned in the standup:  https://github.com/apache/bigtop/pull/158 And here's a branch of python-libjuju that will get you to the point where you're broken like I'm broken: https://github.com/petevg/python-libjuju/tree/bug/bundle-deploy-issues
<kjackal_> cory_fu: You said you can call charm push from a CI script. True. The ugly part is that you have to also login through SSO and 2FA, right? So your build bot will have to do that from inside the CI. You also mentioned something about the blueslib? Whta is that?
<cory_fu> kjackal_: This is how we're dealing with the charm store login in the RQ: https://github.com/juju-solutions/review-queue/pull/54
<cory_fu> kjackal_: Basically, you create and save the SSO token and make sure you clear your go cookies and it handles the auth with the SSO token which never expires
<kjackal_> cory_fu: Interesting, so you need to pass the oauth token at deploy time and thats it
<cory_fu> Yep
<kjackal_> cory_fu: Is there a rest call to get the oauth token or do you "steal it" from your local session?
<cory_fu> tvansteenburgh: ^
<cory_fu> kjackal_: I'm not sure
<tvansteenburgh> kjackal: you steal it
<kjackal_> :) thanks tvansteenburgh, cory_fu! We should make this official!
<tvansteenburgh> petevg: i looked at the branch you posted above
<petevg>  tvansteenburgh: if you're pointing out that I edited auto generated code, I know. Going to file an issue -- the branch is just to work through the exceptions I was running into ...
<tvansteenburgh> petevg: no, that's not it
<petevg> tvansteenburgh:
<petevg> Uh oh :-)
<tvansteenburgh> petevg: i was just gonna point out that those edits should not in fact be necessary. you should be able to just do this http://pastebin.ubuntu.com/23447159/
<tvansteenburgh> (without editing the auto-generated code)
<tvansteenburgh> petevg: stuff gets serialized automatically before being put on the wire
<tvansteenburgh> obviously i don't know what error you're hitting, so there may be more to it, but i just happened to notice that part
<cory_fu> tvansteenburgh: I think petevg's main point with the change was the `params = dict()` line
<petevg> tvansteenburgh: whoops. I forgot the serialize thing was still in there.
<cory_fu> Which overwrites the params passed in
<petevg> Yeah. The prob is the circular reference.
<tvansteenburgh> oh i see
<cory_fu> I think it's in fact a naming conflict.  The parameter name conflicts with a local var in the generated code
<petevg> The serialize is me naively trying to figure out why the go side still doesn't like what I pass in ...
<cory_fu> petevg: It's because it really should be a nested dict with the params passed in under a 'params' key
<cory_fu> Oh, nm, you had that part
<petevg> Yep :-)
<cory_fu> petevg: I don't understand why this is failing.  I was able to deploy a bundle without hitting this
<cory_fu> tvansteenburgh: Did you by chance regenerate _client.py?
<tvansteenburgh> no
<cory_fu> How did this ever work for me, then?
<petevg> cory_fu: i think that you specified more constraints.
<petevg> And you don't have machine shenanigans in your bundle.
<petevg> Basically, my bundle is fancier, and exercises more code :-)
<cory_fu> petevg: The generated plan from deploying the bundle definitely had an "add machine" step in it, though.  I remember it from debugging
<tvansteenburgh> what's the actual error?
<petevg> My current guess is that I need to provide a default for 'series'. Am eating an early lunch, and am planning on testing after.
<petevg> tvansteenburgh: Ack. Matrix clobbered my logs when I stopped it. It appeared to be a response from the Go side, claiming that I hadn't passed it something that it could unpack into a valid MachineParams object.
<petevg> Running again. Will paste shortly.
<petevg> tvansteenburgh Le error: juju.errors.JujuAPIError: json: cannot unmarshal object into Go value of type []params.AddMachineParams
<tvansteenburgh> yeah
<petevg> Noisy matrix logs here, for the curious: http://paste.ubuntu.com/23447199/
<tvansteenburgh> petevg: well since i have regen'd the client in a while, it's possible that the params have changed in juju
<cory_fu> petevg, tvansteenburgh: What do you think of this?  https://github.com/juju/python-libjuju/pull/5
<tvansteenburgh> have not regen'd rather
<petevg> tvansteenburgh: Ooh. That would make sense ...
<petevg> cory_fu: that def looks like a plausible fix for the circular reference issue.
<tvansteenburgh> petevg: that doesn't appear to be the problem. gotta break for lunch, will look closer when i get back
<petevg> tvansteenburgh thank you very much for looking! Have a good lunch :-)
<kjackal_> tvansteenburgh: cory_fu: here is the API for the store what it seems you can get the authtoken: https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md I should have more info on restricting permisions on the tocken tomorrow
<kjackal_> tvansteenburgh: cory_fu: there is this call GET /delegatable-macaroon
<cory_fu> tvansteenburgh: https://github.com/juju-solutions/bundletester/pull/69
<tvansteenburgh> kjackal: sure, but you're not gonna be able to discharge that macaroon without an oauth identity
<tvansteenburgh> petevg: did you get unblocked?
<petevg> tvansteenburgh: I didn't (I was wrong about it needing a series as a default).
<tvansteenburgh> petevg: ok, looking now
<petevg> tvansteenburgh: thank you for looking into it. :-)
<tvansteenburgh> petevg: afaict the problem is just that you have params: params: instead of just params:
<petevg> tvansteenburgh: I tried just passing params in at one point. That might have been while other things were broken, though. I'll try again ...
<petevg> tvansteenburgh: That works! (Well, it gets us to the point where a log message does the wrong thing with the return, but that's progress, and it gets me back out of the generated codebase, at least :-) )
<tvansteenburgh> \o/
<petevg> tvansteenburgh: I see several instances in the generated code where we create a params argument, then create a dict with a 'params' key to pass to it. Should I assume that is never the correct thing to do, and submit a patch?
<petevg> In any case, thank you :-)
<tvansteenburgh> petevg: i'm note sure yet :/
<petevg> Whee!
<tvansteenburgh> petevg: so for your thing to work you still have patched auto-gen'd code?
<petevg> tvansteenburgh: yes. I need to rebase from cory_fu's branch, but I think the params will still try to nest itself.
<tvansteenburgh> petevg: i just noticed something else. AddMachines() takes a list of AddMachineParams objects
<tvansteenburgh> not a single instance
<petevg> tvansteenburgh: is this on the Go side?
<tvansteenburgh> so, client_facade.AddMachines([params]) in your example
<tvansteenburgh> petevg: https://github.com/juju/python-libjuju/blob/master/juju/client/_client.py#L9077
<tvansteenburgh> petevg: note the typing.Sequence
<petevg> tvansteenburgh: Interesting. I am currently getting timeouts, and it looks like the machines aren't being added ... will try passing in a list. (Hooray for more hacking on generated code!)
<tvansteenburgh> petevg: why do you have to change auto-gen'd code?
<petevg> tvansteenburgh: Yeah. I can just pass a list in from model.py
<petevg> tvansteenburgh: Huh. It doesn't want a list. "cannot unmarshal array into Go value of type params.AddMachines"
<tvansteenburgh> petevg: can i see your current code?
<petevg> tvansteenburgh: yes. Jumping into the matrix hangout ...
<petevg> tvansteenburgh: Will also push to that branch shortly (I'm hacking in the site-packages in a virtual environment, so I have to copy stuff over ...)
<petevg> I just want to try one more thing (working on embedding a list in the params key in the params dict.)
<tvansteenburgh> petevg: can you jump in here https://hangouts.google.com/hangouts/_/canonical.com/rq-next?authuser=0
<lutostag> our /var/lib/juju on a 1.25.6 bootstrap system is 6.3G, any way to clear out some of it?
<lutostag> is the charm-get-cache safe to delete?
<lutostag> ci-oil-config has an error https://pastebin.canonical.com/170197/
<lutostag> charm*
 * lutostag oops, wrong channel for that last part...
#juju 2016-11-09
<kyanh> hi, is Juju on cloud or can it be installed on my own server?
<hloeung> kyanh: it can be installed on your own server
<kyanh> hloeung, thanks a lot. I read on the site but it's hardly to figure the juju architecture :)
<anrah> I have problem with setting some unit data and then accessing it on a interface-layer
<anrah> http://paste.ubuntu.com/23450338/
<anrah> The ipv6_addr seems to be empty always
<kjackal> anrah: I wouldn't go into IPv6 territory at the moment. Is it a requirement for you?
<anrah> kjackal: partly yes.. As I use chef below the Juju and I've written my cookbooks in a way that it prefers ipv6 over ipv4
<anrah> and also I have some requirements that IPv6 should be used if it's available on the platform
<kjackal> anrah: I know that there is work going on on IPv6 as we speak, rick_h should have more info on this
<anrah> in general also I'm little confused am I able to use certain units unit data on my interfaces?
<kjackal> anrah: normally your reactive layer will call the functions of the interface passing any information required
<mramm> kjackal: hi, I'm at some Juju roadmap planning meetings right now
<mramm> kjackal: rick_h is the one who is working on making sure that ALL the IPs/subnets on an interface are made available to charm authors.
<anrah> nice
<mramm> anrah: I will try to get some more detail, though he is currently in a meeting
<kjackal> mramm: anrah is into the telco field. This might help in connecting him with the right people.
<mramm> kjackal, yea definitely.
<kjackal> anrah: if you could share some details on what your use case is that would be helpful
<mramm> anrah: could you send an email with your question to me at mark.ramm-christensen at canonical ?  We would very much like to work with you to demo your stuff to various operators we are talking to at the moment, and I'd like to connect folks on that level.
<mramm> I will also track down and see when the address stuff is going to land, and see if there's a good way to get what you want right now.
<anrah> mramm: Sure! We have already discussed with Max and Milan about our approach
<mramm> anrah: That's good news.
<mramm> I was just out doing a workshop at an operator here in Europe last week, and it is always great to have more VNFs to demo at such things.
<mramm> and the code you pasted above is great -- uses the latest reactive stuff, looks clean and easy to explain to high level telco audiences
<mramm> very nice!
<zeestrat> mramm: Apologies for butting in, but is there any chance that you guys will make the Juju roadmap somewhat? It would be really great to know where the project is headed and what will be focused on.
<zeestrat> *public
<mramm> zeestrat: Sure, I'll try to get the details from the team as soon as they are finalized (probably next week) pushed to the mailing list.
<mramm> zeestrat: also, what we have as a roadmap is what Canonical will push -- Juju is open source so it's possible that other things will get done
<zeestrat> mramm: That sounds great. Thanks
<jamespage> tvansteenburgh, morning
<jamespage> tvansteenburgh, https://github.com/juju-solutions/bundletester/pull/71 would help with getting the openstack-charmers charms which are currently failing cwr passing again I think
<jamespage> beisner, ^^
<jamespage> tvansteenburgh, if you want to test it against cs:~james-page/rabbitmq-server-requirement
<jamespage> that has a small delta to install from test-requirements.txt
<jamespage> marcoceppi, do bundletests for cwr require use of virtualenv flag?
<marcoceppi> jamespage: I'm not 100% sure, ses is the one who would know best, followed by cory_fu
<jamespage> marcoceppi, okies - just trying to get our openstack gate story and cwr lined up so we can keep both happy :-)
<tvansteenburgh> jamespage, marcoceppi: reviewing now
<cory_fu> jamespage, marcoceppi: Save for a brief window last week, CWR tests are run inside charmbox to ensure a consistent, clean environment, since the venv doesn't help with apt packages that the tests might install.
<cory_fu> So, no, they don't require the virtualenv flag.
<jamespage> cory_fu: ok so we're good with just the requirements change I've proposed then
<jamespage> that's helpful I tink
<jamespage> cory_fu, https://review.openstack.org/#/c/395574/ running through UOSCI for gate test
<cory_fu> jamespage, tvansteenburgh: Not that I think that having an explicit option is an issue, but couldn't you achieve the same effect by including '-rrequirements.txt' or '-rtest-requirements.txt' in the list of python-packages?
<jamespage> cory_fu, that might work
<jamespage> cory_fu, can we get cwr pointed at cs:~james-page/rabbitmq-server-requirement whilst we test this out?
<cory_fu> jamespage: We will need that BT change merged and released, build-cloud updated, charmbox rebuilt, https://hub.docker.com/r/seman/cwrbox/builds/ rebuilt, and the Jenkins slave(s) updated.  I don't have access to do the last two.  (Obviously, there are too many moving parts in the current CWR system, so we're looking to streamline that.)
<cory_fu> tvansteenburgh: Do you have access to the Jenkins slave(s)?  Could you do the last two on there?
<tvansteenburgh> cory_fu: which slave
<cory_fu> tvansteenburgh: xenial-slave
<tvansteenburgh> cory_fu: looks like no. i can ask sinzui if it's urgent?
<cory_fu> tvansteenburgh: I guess it depends if Seman is still out sick today
<lazyPower> cory_fu - jsut for future reference, when we rebuild charmbox, cwrbox triggers a rebuild
<lazyPower> so we *can* update the cwrbox
<cory_fu> lazyPower: The timing on the builds made me think that it wasn't causative, but that's good to know
<lazyPower> yeah, i cant help with the slaves, but i can help w/ the dockerhub stuff :P
<cory_fu> And the docker image is pulled for each build, so that's good.
<magicaltrout> if anyone wants me to import goods into the USA next year once the trade deals are scrapped.... let me know! ;)
<magicaltrout> lazyPower: did you reschedule that elastic stack chat?
<lazyPower> magicaltrout - not yet, looking for a good date next week. what works for you?
<magicaltrout> how sober do i need to be?
<lazyPower> its just planning/chat so 70/30?
<magicaltrout> okay not Wednesday or Thursday lazyPower
<magicaltrout> other than that i'm good
<magicaltrout> if you make it a bit later than you did this time, its less likely to clash with any PST meetings I have
<magicaltrout> they're always around 8-9am
<magicaltrout> of course the trade off their is i'll have drunk more ;)
<lazyPower> no worries i'm armed to the gills against drinking engineers ;)
<lazyPower> i'll shoot for a 10am PST meeting on Tuesday
<magicaltrout> cool
<magicaltrout> admcleod_: you coming next week or not then?
<lazyPower> magicaltrout - i just sent the updated calendar invite, thanks for keeping on me about that :)
<lazyPower> i also attached a meeting agenda doc, and you should have edit rights, feel free to add to the agenda topic list if you have anything thats burning from your perspective
<jcastro_> heya balloons
<jcastro_> I'm updating the juju instructions in the kubernetes documentation, do we have a section in our docs on how to install via snaps? I would like to include other distros if possible.
<lazyPower> +1000 to that notion
<cory_fu> tvansteenburgh, kwmonroe: Replied to your comments on https://github.com/juju/amulet/pull/166
<cory_fu> tvansteenburgh: Missed your reply about the comment.  Adding that now
<cory_fu> tvansteenburgh, kwmonroe: Actually, I just noticed that Amulet already includes path.py in its requirements, so I can just say "for filename in Path(dir).files():"
<bdx> hows it going everyone?
<lazyPower> Whats up bdx
<bdx> Merlijn and I just hashed out some initial work on juju <-> jenkins integration ideas, its on this etherpad -> http://184.72.79.132/p/jenkins-collab
<bdx> we would love any insight/feedback anyone has
<bdx> we had to cut it short today, but it will be an ongoing project so ... stay tuned!
<lutostag> bdx: interesting... what's that jenkins charm got compared to the upstream jenkins?
<bdx> lutostag: xenial
<bdx> experimenting with local lxd in the build process
<bdx> needed xenial
<lutostag> bdx: https://github.com/jenkinsci/jenkins-charm supports xenial
<lazyPower> i think important info here is this charm layer landed last week ^
<lutostag> true
<lazyPower> did we ping the list with that info?
<lutostag> lazyPower: good point... the communication is lacking for sure
<lutostag> lazyPower: marcoceppi had plans for making that the promulgated jenkins charm, anything I can do to help that process?
<lazyPower> lutostag - i think we just need a RevQ submission for that
<lutostag> lazyPower: ok, thanks, will do
<lutostag> bdx: sorry, our fault for not making it wider known, I hate when that happens
<bdx> lutostag: its cool man ... it would be sweet to get that promulgated though
<bdx> lutostag: theres no series in the metadata .... does this mean it supports xenial by default lol?
<lutostag> bdx: should work on trusty + xenial, but I think we'll just try to get it promulgated for xenial, so we don't need to worry about a trusty upgrade story
<beisner> icey, https://github.com/juju/theblues/issues/49
<icey> beisner: good one :)
<constl> marcoceppi, ubuntu charm file links leads to this -> https://api.jujucharms.com/charmstore/v5/~marcoceppi/xenial,trusty,precise/ubuntu/archive/Makefile
<constl> when seeing the charm details from my local juju gui
<bdx> marcoceppi, beisner: where does the jenkins-slave interface come from?
#juju 2016-11-10
<wililupy> Question: I just installed juju on 16.04 from repo (juju 2.0 beta15) and when I try to connect to the gui, it says connecting to Juju model and never goes past. Nothing in the logs looks suspicious other than in the machine-0.log there is an entry about reconfiguring lxd using dpkg and setup lxcbr0 which I do, but still nothing. Rebooted the controller and I had to tell Firefox to delete the SSL certificate for the server and
<wililupy> have it re-issue it so that I could connect again, but same results.
<bdx> wililupy: add juju/stable first ...
<wililupy> bdx even on xenial?
<bdx> wililupy: `sudo add-apt-repository ppa:juju/stable`
<bdx> wililupy: yea ... not for much longer I think ..
<wililupy> bdx: I'm updating it right now. Do I have to re-bootstrap?
<bdx> wililupy: yes
<bdx> wililupy: `rm -rf ~/.local/share/juju` too
<wililupy> bdx: ack.
<wililupy> bdx: That fixed it. Thank you so much. I eventually probably would have done that, but I was hoping not having to add a ppa.
<admcleod_> magicaltrout: yep
<magicaltrout> unlucky
<bdx> lutostag, beisner, marcoceppi: where might one find the interfaces for the charm-jenkins charm?
<beisner> marcoceppi, bdx, it looks like they're not in http://interfaces.juju.solutions  :-/
<beisner> marcoceppi, bdx, i previously built using https://github.com/freeekanayaka/interface-jenkins-slave, which really should make it into jenkins upstream along side the jenkins-charm layer repo.
<bdx> beisner: nice, thanks
<bdx> looks like free has the other interfaces stashed there too :-)
<jamespage> cory_fu, so the tweaks to bundletester config did not explode in the gate - https://review.openstack.org/#/c/395574/
<cory_fu> jamespage: That's good.  We didn't get that rabbitmq branch into CWR, though, unfortunately.  Is that still something you need?
<jamespage> cory_fu, it would be helpful to get this right first time - however if its alot of effort, we can probably get away with landing the changes and testing in stable, but that's not ideal
<kwmonroe> cory_fu: jamespage:  the rabbit charm made it into cwr, just not in time for the overnight runs.  i'm pretty sure it'll be picked up when they kick off today.
<jamespage> kwmonroe, based on my test charm under ~james-page right?
<kwmonroe> correct jamespage
<kwmonroe> cs:~james-page/rabbitmq-server-requirement
<cory_fu> Yeah, sorry, I meant what kwmonroe said
<cory_fu> jamespage: It will be run automatically this evening, but if need be, we could kick it off manually sooner, though I think it would still take a while before it actually runs
<cory_fu> That CI infra is pretty over-committed, from what I can tell
<jamespage> cory_fu, I just synced it up so I'll look am tomorrow
<kwmonroe> tvansteenburgh1: it appears i'm hosting a timtimtim model in azure-east.  pretty sure that was for long-ago k8s test.  cool if i destroy that?
<cory_fu> Ok
<tvansteenburgh1> kwmonroe: yes
<kwmonroe> thx
<beisner> woot thanks jamespage cory_fu
<deanman> Does anyone have a sample of yaml config file to be used during bootstrap. Cannot find any reference on the docs, only for charms.
<lazyPower> deanman - its just a key: value map.   http://paste.ubuntu.com/23457321/
<deanman> lazyPower: ok got it! Thanks
<deanman> lazyPower: Can you put comments and/or environmental variables as values?
<lazyPower> in yaml?
<lazyPower> no, you would need to render it through a template wizard like envtemplate or something.
<lazyPower> however, comments should be just fine, you can prefix a comment in yaml with #
<deanman> lazyPower: ok thats seems reasonable!
<deanman> Is it possible to `juju run` using a command that takes arguments? A simple `tail -f` seems to give an error with "flag provided but not defined: -f"
<lazyPower> deanman - you'll need to quote the command
<lazyPower> eg: juju run --application foobar "ls -al && whoami"
<lutostag> any way to move bootstrap to a different ip/machine on 1.25.x? Our bootstrap node has run out of disk space. (Or a way to purge unused data from /var/lib/juju would work too)?
<deanman> lazyPower: Shouldn't this work ? juju run -m controller --machine 0 "tail -f /var/log/juju/machine-0.log"
<lazyPower> lutostag - thats rough, i think the option is to either go HA (probably not going to solve disk space issues) or to purge the cache/logs/whatever-is-using-the-diskspace
<deanman> it just hangs
<lazyPower> deanman - its async i think,s o you wont see the output until the command terminates
<lazyPower> deanman - you should probably juju ssh into the unit if you need to tail logs.
<deanman> ok lazyPower
<lutostag> lazyPower: is /var/lib/juju/charm-get-cache safe to boot into the bit-bucket in the sky?
<lazyPower> i think so, i'm fairly certain it will just replace whatever it needs that it doesn't find in the cache
<lazyPower> *but*
<lazyPower> with that being said, i haven't done it myself, so it might break things in unexpected ways
<lazyPower> lutostag - i would highly recommend we file a bug about this so we can add an operational action to the controller to purge temporary/unneccesary data in the event this happens
<lutostag> lazyPower: ack will find/create a bug
<deanman> lazyPower: somehow even juju run -m controller --machine 0 "ls -al" hangs there.
<lazyPower> mattrae ping
<babbageclunk> deanman: does `juju ssh -m controller 0` work?
<lazyPower> deanman - yeah that doesn't sound good. give babbageclunk's suggestion a go
<deanman> babbageclunk: it does but i have since restarted the VM and now even run works
<babbageclunk> deanman: sounds like sshd was having a bad time.
<deanman> babbageclunk: it does take though like 5 seconds for a whoami
<deanman> babbageclunk: is that normal?
<babbageclunk> deanman: no that sounds very slow...
<deanman> babbageclunk: http://paste.ubuntu.com/23457920/
<deanman> seems like the previous command "tail -f" makes it unresponsive
<babbageclunk> deanman: yeah, I see the same behaviour - can you file a bug for that?
<deanman> `juju ssh` makes it recover somehow
<deanman> sure babbageclunk !
<babbageclunk> deanman: Thanks!
<deanman> babbageclunk: can you `time juju run -m controller --machine - "whoami" for me and tell me what's your average?
<deanman> i get 2-5 secs
<babbageclunk> deanman: yeah, I get the same - 5 seconds sounded slow until I tried it.
<deanman> babbageclunk: https://bugs.launchpad.net/juju/+bug/1640938
<mup> Bug #1640938: `juju run` becomes unresponsive in consecutive runs when previous command passed is `tail -f` <juju:New> <https://launchpad.net/bugs/1640938>
<babbageclunk> deanman: great thanks
<deanman> Cheers!
<lazyPower> babbageclunk - that tail -f doesn't exit, and i'm pretty sure that its just hanging the ssh session until timeout
<lazyPower> deanman - humor me and try the tail with something like a -n 100  and omit the -f
<babbageclunk> lazyPower: Oh, I think that's right, I'm just surprised that killing the run command doesn't kill the tail.
<jproulx> Having trouble with image-metadata bootstrapping private cloud, have meta data json in ~/simplestreams as described in "getting" started but no matter how I feed it in keep getting
<jproulx>  ERROR failed to bootstrap model: no image metadata found
<jproulx> tried both --metadata-source=~/simplestreams and webserver using --config image-metadata-url=https://people.csail.mit.edu/jon/simplestreams amoung other things....Help?
<jproulx> oh juju-2.0 on xenial
<lazyPower> jproulx - i'm not as familiar with the clouds that require manual provisioning of simplestreams, however if you dont get an answer here in a timely fashion, the mailing list is an excellent resource for help with problems like that. https://lists.ubuntu.com/mailman/listinfo/juju
<jproulx>  lazyPower: thanks for the pointer
<mattrae> lazyPower: hey saw your ping :)
<lazyPower> mattrae - found the answer already, thanks for pong'ing
<mattrae> cool no problem :)
#juju 2016-11-11
<anrah> jproulx: are you using openstack?
<deanman> lazyPower: As babba pointed out that `tail -n 100` works just fine.
<jamespage> cory_fu, tvansteenburgh: urgh
<jamespage> theblues.errors.ServerError: Request timed out: https://api.jujucharms.com/v4/~openstack-charmers-next/trusty/cinder/meta/any?include=bundle-machine-count&include=bundle-metadata&include=bundle-unit-count&include=bundles-containing&include=charm-actions&include=charm-config&include=charm-metadata&include=common-info&include=extra-info&include=revision-info&include=stats&include=supported-series&include=manifest&include=tags&include=promulgated
<jamespage> &include=perm&include=id timeout: 3.05
<jamespage> well at least its having a run at the tests now
<stub> Did we have an etcd layer available? I only see the interface, but could have sworn there was a layer
<beisner> jamespage, cory_fu - fyi, seeing that in osci too.  the theblues default 3s timeout is increasingly not enough time.  https://github.com/juju/theblues/issues/49
<BlackDex> Hello there, how do i select a specific juju version after it has been installed?
<BlackDex> i mean charm
<BlackDex> so charm-5 is installed and i want to install charm-7 for instance
<BlackDex> ah upgrade-charm --revision i think
<BlackDex> was searching for a while, and after typing here i got it
<junaidali> Hi everyone, is it possible to deploy charms with one bundle and add relations with another one?
<anrah> junaidali: yes it is
<junaidali> anrah, when i try to add relations with the bundle that only have relations int it,  it gives error that the charm is not defined in the bundle (for each charm relation though the charms are deployed).
<junaidali> in it*
<anrah> oh sorry, misread your question
<junaidali> np :)
<anrah> I don't think that is possible, I always introduce the relations on the bundle where I have the applications
<beisner> stub, one of the 3 nov 10 commits appears to have broken juju-wait on subordinates.  getting ERROR:root:error: The following run targets are not valid: "" is not a valid unit name
<beisner> stub, also, that broke the case where we bootstrap then juju-wait.  in that case there are no applications/services with units.
<beisner> stub, https://bugs.launchpad.net/juju-wait/+bug/1641163
<mup> Bug #1641163: The following run targets are not valid: "" is not a valid unit name <uosci> <Juju Wait Plugin:New> <https://launchpad.net/bugs/1641163>
<stub> beisner: is this from mojo? I didn't think I'd released
<beisner> stub, we consume tip of juju-wait ;-)   well, we did.  having to fork, rewind and pin for now to unblock our gate.
<stub> ha. ok, thanks for the heads up then. It should be an easy fix.
<stub> Its going to bite mojo too, so I'll chase that
<beisner> awesome, thanks stub
<lazyPower> stub https://github.com/juju-solutions/layer-etcd
<Soichi> Is there some guide on how to setup networking so that an LXD charm is accessible from other machines in the network?
<bdx> hows it going everyone?
<bdx> is it possible to pass a file as a string to an action?
<bdx> e.g. juju run-action myapp/0 set-secrets secrets="$(cat barb-test.yaml)"
<bdx> I'm getting ERROR json: unsupported type: map[interface {}]interface {}
#juju 2016-11-12
<bdx> https://github.com/jamesbeedy/juju-layer-barbican-client/tree/master/actions
<bdx> its a start
<rock> Hi guys. I had an issue with Juju user accounts. I raised a bug as https://github.com/CanonicalLtd/jujucharms.com/issues/372. I raised this one week back. Still not get the reply. Let me know if anyone knows the answer for this issue.
<magicaltrout> excellent
<magicaltrout> where's interfaces.juju.solutions gone?
<stokachu> magicaltrout: hmm good question
<magicaltrout> yup, was gonna do some basic charm training today with some interested people
<magicaltrout> had to can that idea
<magicaltrout> can't build anything
<stokachu> yea and it's a weekend
<stokachu> ill email some people
<magicaltrout> one would assume some monitoring is already doing that... seems not ;)
<stokachu> magicaltrout: :P i emailed a few people that could look into it
<stokachu> magicaltrout: worse case you'll want to try and pull down the layers from the github repos
<marcoceppi> magicaltrout: we're looking into it. We're gearing up on moving the repo, but this is unexpected down time.
#juju 2017-11-06
<skay> I've got an interesting new failure
<skay> "ERROR cannot load cookies: invalid character 'Y' looking for beginning of value"
<skay> I had to force reboot my laptop for another problem, and now I get this when I run juju status
<skay> and most likely any other command though I've only tried destroy-model so far
<skay> I can't do anything, and I've restarted my basenode
<skay> for posterity... juju installed in snap mode deposits files in ~/.local/share/juju/
<skay> and I removed my bad cookie, and voila (or voila if you are feeling sympathy and want to play a large violin)
<skay> dammit I meant to mispell voila
<skay> viola
<skay> sad trombone
<rick_h> skay: so you're good or ungood?
<skay> rick_h: I'm good now. I got help suggesting to check if I had any corrupted local config files. I had expected to find them in ~/.juju, then checked ~/snap/juju then Spads suggested .local/
<rick_h> skay: yea, the confinement moves stuff around a bit for the snap
<skay> I've been pondering if there is anything to add to docs that would help, but can't figure
<rick_h> skay: glad you're back off to the races
<rick_h> skay: yea, it's a tough one as it's hopefully not something repeatable/etc.
<skay> rick_h: agreed. maybe the only thing to update would be about where local settings are stored. if I think of anything to improve I'll open an issue or make a pr
<rick_h> skay: ty
<bdx> is there a charmhelper somewhere for modifying open files limits?
<skay> mthaddon: I have a script called in my mojo spec that requires virtualenv, and my manifest includes python-virtualenv with builddeps. can you see anything I may have overlooked to explain why a script wouldn't be picking up virtualenv https://pastebin.canonical.com/202483/
<skay> the build-static-resource scripts requires it
<mthaddon> skay: do you have the output which shows where it's not picking up virtualenv?
<skay> mthaddon: yes, https://pastebin.canonical.com/202485/
<skay> whoops, probably should be pastebin for ubuntu
<bdx> https://jujucharms.com - soooooo sloww
<bdx> https://jujucharms.com/u/jamesbeedy/
<bdx> I cant get my user page to load
<bdx> are there squirrels in the pipes again?
<rick_h> bdx: tracking what's up. It sure seems like something is sapping bandwidth out. Things are up but responding minutes slow for some reason. Will see what folks are seeing might be ddos or something like that.
<bdx> rick_h: thx
<rick_h> bdx: hmm, actually I'm having general internet issues atm. I'm not able to get to outside stuff either. /me checks wtf
<bdx> rick_h: same
<rick_h> bdx: comcast?
<bdx> yeah
<rick_h> bdx: yea, seeing lots of reports of comcast issues atm
<rick_h> bdx: seeing someone say "so level3 celebrates its sale by breaking its name servers" so seems like something is going boom big out there.
<rick_h> heh, the outage comments are getting bad now. Issues from NJ to CA and those of us on business accounts and such having issues so lots of folks unable to take customer calls/etc. ouch
<bdx> wow
<bdx> well at least my dc <-> aws is safe
<bdx> :) :)
<rick_h> bdx: so I moved to my verizon hotspot and interwebs are faster than they've been all day
<rick_h> bdx: so definitely a "depends on which pipes your on" kind of day unfortuantely
<bdx> right, I just did the same
<bdx> I need to change my vpn port to 443
<bdx> or something
<bdx> my hotspot device blocks all udp on 1192
<bdx> possibly all udp in general, idk
<bdx> its horrible though
<bdx> so muy internet definitely got faster, although I am then blocked by the provider restrictions
<bdx> what a horrible device
<bdx> blast
<rick_h> ouch
<bdx> yeah
<bdx> thats it
<bdx> im taking the day off
<bdx> the gods have frowned upon my doings
<rick_h> bdx: heh, hitting the news sites now https://www.theverge.com/2017/11/6/16614160/comcast-xfinity-internet-down-reports
<BarDweller> hi =) is there a simple way to get rbac running with conjure-up kubernetes-core ?
#juju 2017-11-07
<[Kid]> if i am using MAAS as a cloud provider and doing a juju deploy with a bundle YAML, why would it not spin up all the machines it needs? i.e. i have 8 machines available and "Ready" state in MAAS, but it only allocates 4 and then says pending on the others.
<[Kid]> no constriants either
<bdx> [Kid]: if you are deploying > 1 of an application juju will try to spread out the unit across zones
<bdx> if all your nodes are in the same zone
<bdx> it can cause issues
<bdx> if all nodes in the same zone
<bdx> [Kid]: http://paste.ubuntu.com/25905242/ <- what I do to get multiple units of something in the same zone
<bdx> I feel like its kind of a hack though
<bdx> I think others do too
<siraj> unable to remove a service using juju remove-service <service-name> or by juju remove-unit or even removing a machine by juju remove-machine command. Even i deleted container still juju show-status display associated machine, application
<Dwellr> morning all =)
<Dwellr> anyone know a little more about "snap set kube-apiserver authorization-mode=RBAC" ?
<Dwellr> aha.. figured out I needed to juju ssh kubernetes-master/0 -- 'sudo service snap.kube-apiserver.daemon restart' before the RBAC roles would show up
<rick_h> Dwellr: ah cool stuff
<Dwellr> aye.. are there any docs for the options for set kube-apiserver ? I'm wondering next how to enable initializers
<tvansteenburgh> Dwellr: fyi, the bundle on the candidate channel allows you to enable RBAC via charm config, ala: juju config kubernetes-master authorization-mode=Node,RBAC
<Dwellr> Yeah.. I spotted that =) I look forward to it when it's released =)
<tvansteenburgh> cool
<tvansteenburgh> Dwellr: are you asking which initializers are available, or how to turn them on?
<Dwellr> I couldn't figure out last night how to tell my conjure up to use different bundles tho when installing
<Dwellr> asking how to turn on initializers for kubernetes.. I'm trying to setup Istio, and it needs them apparently.. (they may already be on for all I know atm)
<Dwellr> https://istio.io/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection
<tvansteenburgh> Dwellr: i think they are on already...
<Dwellr> oooh.. now that would be awesome =) I'll try when my vm comes back up =) just wiped it clean again
<[Kid]> bdx, you around?
<[Kid]> follow up on a question i had yesterday about juju not deploying across all MAAS nodes.
<[Kid]> if it is a kubernetes cluster with etcd, flannel, etc., would it be good to put etcd, flannel and the others into separate zones?
<bdx> [Kid]: you can do whatever you want, I don't see any advantage to using zones in maas unless you are going to use them like availability zones and not logical groupings
<Dwellr> is it just me.. or is `conjure-up kube` not completing anymore? I'm seeing [info] Waiting for deployment to settle (this is normal) but then [error] Some applications failed to start successfully and then [warning] Shutting down ... but kube IS running, although it fails to create the .kube dir with the config file etc
<[Kid]> bdx, i thought that's what you were referring to yesterday when it wasn't using all of the nodes that were available
<bdx> toatlly, I was
<[Kid]> oh, so i do need to do separate zones?
<[Kid]> for each role
<[Kid]> then do a juju deploy for each role?
<bdx> [Kid]: I've just experienced the same learning curve there, yeah, that should work
<[Kid]> won't that cause the k8 cluster not to communicate correctly?
<bdx> the zones are just metadata representation of physical groupings
<bdx> n[Kid]: no
<[Kid]> ahh ok
<[Kid]> i will try that
<[Kid]> is there a way to put constraints for tags in a bundle YAML?
<cory_fu> Dwellr: Sorry for the late reply, but we're looking into that issue here: https://github.com/conjure-up/conjure-up/issues/1218  Can you let us know what version of conjure-up you're using? (Are you using the edge channel of the snap?  Which revision?)
<Dwellr> snap install conjure-up --classic --edge
<zeestrat> [Kid]: For MAAS? Just use tags in the constraints
<[Kid]> zeestrat, the tags constraint doesn't seem to work in a bundle YAML
<[Kid]> the cpu, mem, etc. do though
<Dwellr> $conjure-up --version
<Dwellr> conjure-up 2.5-alpha1
<Dwellr> corey_fu: ^^
<[Kid]> not sure if it is related to this: https://bugs.launchpad.net/juju/+bug/1554120
<mup> Bug #1554120: juju 2.0 bundle support: Missing constraint support for maas names to support bundle placement <conjure-up> <juju-release-support> <oil> <oil-2.0> <uosci> <juju:Triaged> <https://launchpad.net/bugs/1554120>
<[Kid]> the gist i get from that is that maas tags aren't supported as to make the bundle YAMLs community-driven, i.e. that wouldn't make them as shareable?
<cory_fu> Dwellr: Can you check the file ~/.cache/conjure-up/canonical-kubernetes/deploy-wait.err and see if it has any contents?
<zeestrat> [Kid]: That bug is for maas names. We're using tags fine in 2.1.3 at least. Could I see the bundle?
<[Kid]> zeestrat, sure
<Dwellr> cory_fu: I'm using kubernetes-core, not canonical-kubernetes, and my ~/.cache/conjure-up/kubernetes-core/deploy-wait.err is empty
<[Kid]> zeestrat: https://pastebin.com/HPHnfhdp
<cory_fu> Dwellr: Hrm.  That matches the issue report, but I'm really unsure why that file would be empty.
<[Kid]> also, the other weird thing is that it doesn't release 2 of the nodes in MAAS when i tear down the model
<Dwellr> cory_fu: well.. deploy-wait.out is 0 bytes too
<Dwellr> (as are conjure-up*bootstrap.(err|out)"
<cory_fu> Dwellr: Did you do a fresh bootstrap for that deployment?
<cory_fu> Dwellr: Well, there's definitely something wrong with the writing of those log files.
<Dwellr> It was a brand new vm.. I basically do    apt-get remove -qyf lxd lxd-client && snap install lxd && snap install conjure-up --classic --edge && snap install kubectl --classic && conjure-up kubernetes-core localhost
<Dwellr> (a few other commands omitted for brevity, but basically that's it, just ditch the supplied lxd, install from snap, then run conjure-up to create the k8s
<cory_fu> Dwellr: Ok, thanks.  stokachu ^  Looks like there's an issue with the sub-log files across the board.  Maybe something with arun?
<Dwellr> fwiw, it used to work ok..
<stokachu> cory_fu: Yea I just looked at another deploy and the bootstrap log is empty
<kwmonroe> cory_fu: is  ~/.cache/conjure-up/kubernetes-core/deploy-wait.err still the right location?  i thought you guys wrote logs to $SNAP_USER_DATA.
<Dwellr> 25days ago I know it worked fine, and 13days ago it probably worked..
<Dwellr> and it appears initializers aren't enabled in the k8s from kubernetes-core.. I guess I need to go figure out how to enable them =) "kubectl api-versions | grep admissionregistration" is empty
<[Kid]> zeestrat: does that look wrong?
<Dwellr> https://kubernetes.io/docs/admin/extensible-admission-controllers/#external-admission-webhooks
<zeestrat> [Kid]: Thanks. Initial guess is that juju is getting a bit confused because of the mixing of machine placements (i.e. to) and constraints for the same charm. We use constraints/tags in the machine section for charms that we need to colocate. For other charms we just use the constraints section in the charm. Let me see if I find an example
<[Kid]> hmmm that makes sense
<kwmonroe> nm cory_fu, i see that .cache/c-u is the right location.  i thought for some reason that switched recently.
<zeestrat> [Kid]: rick_h and the devs would be the judge to determine if it's correct behavior from juju, but here's an excerpt from our OpenStack bundle: https://pastebin.com/UZPRLp9z
<tvansteenburgh> Dwellr: these are the admission controls we enable by default: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L1081
<tvansteenburgh> Dwellr: to modify api-server args, use the api-extra-args charm config on kubernetes-master
<zeestrat> [Kid]: Note, I see we also have a constraints section for the ceph-radosgw charm in my example, but I'm pretty sure that's unecessary/typo
<Dwellr> like... juju config kubernetes-master api-extra-args="--admission-control --runtime-config=admissionregistration.k8s.io/v1alpha1"
<Dwellr> ah.. figuring it out slowly
<tvansteenburgh> Dwellr: do `juju config kubernetes-master` - there's some help text for each option
<tvansteenburgh> explains the format for api-extra-args
<Dwellr> aye.. is it empty by default ?
<tvansteenburgh> ye
<tvansteenburgh> s
<Dwellr> awesome.. no need to worry about merging then =)
<tvansteenburgh> Dwellr: whatever you specify will be added to the defaults
<[Kid]> zeestrat. thank you. that helps a lot
<[Kid]> if i do the containers/charmname, that should create a lxd container on the node, right?
<[Kid]> i see you specified lxd in your config
<Dwellr> Cool.. I _think_ I just got Istio with initializers to install into my k8s =)
<zeestrat> Yeah, using the lxd:<machine-number> syntax will create and place the application in a lxd container on a machine. See also https://jujucharms.com/docs/devel/charms-bundles
<[Kid]> zeestrat, also, can i do a cs:~containers/easyrsa and just get the latest charm?
<[Kid]> or do i have to specify the revision?
<zeestrat> Jupp
<[Kid]> yeah i have read that page, but it didn
<[Kid]> t show tags as constraints
<zeestrat> Yeah, you're quite right. Feel free to put in a bug, otherwise I'll do it tomorrow. You are correct that it probably didn't get highlighted as maas is the only cloud supporting that.
<[Kid]> yes, it does say that on the constraints page
<[Kid]> i was just saying in the bundle YAML it didn't seem like it supported that, but i will try it again
<zeestrat> I'm off for tonight, but make some noise if you don't get anywhere with the bundle syntax and I'm sure someone can sort you out.
<[Kid]> real quick
<[Kid]> one more ?
<zeestrat> Fire away
<[Kid]> i don't need the to: anymore if i use the tags, right?
<[Kid]> and you said yup to both my questions earlier, not just the last one, right?
<[Kid]> about the cs:~container and the one asking about without the revision number
<[Kid]> sorry for all the questions, i have been messing with this for a few days now
<zeestrat> Sorry, jupp to dropping rev for latest. Just keep in mind latest and greatest, bleeding edge and all. Some folks prefer to follow published and tested bundles but that depends wholly on you.
<[Kid]> oh yeah
<rick_h> zeestrat: [Kid] so juju won't listen to constraints if you target with --to
<[Kid]> rick, well that is VERY good informaqtion
<[Kid]> thank you
<[Kid]> zeestrat, thats what you said earlier
<rick_h> yea, because if they conflict who wins? If you say "put it there" then you know what you're doing :)
<[Kid]> ahhh
<[Kid]> makes sense
<zeestrat> You need to: if you want to colocate applications on the same hosts, f.eks multiple controller applications in lxd containers on the same host
<[Kid]> rick, so cs:~container/charmname will put the charm in a container on the node,right?
<[Kid]> yeah, zeestrat, that's what i want
<[Kid]> so i guess i constrain in the machine section
<[Kid]> then use to: in the application section
<rick_h> [Kid]: no, if it's container or not has nothing to do with charm url. That's actually a username/team name
<[Kid]> ahhh
<[Kid]> ok
<rick_h> [Kid]: exactly
<zeestrat> Very misleading namespace :p
<[Kid]> hahah yeah it is
<rick_h> target in the application --to lxd:0 or the like and then put constraints on machine 0 to get the right sized vm
<[Kid]> that's where i have to do to: lxd:1
<[Kid]> yeah
<[Kid]> yes, thank you!! i have some things to try now
<[Kid]> this makes it much more enjoyable to get past a wall
<[Kid]> and actually start building an application
<[Kid]> haha
<zeestrat> Finally, a word of advice in case you got different networks setup in maas. You'll probably have to use bindings (from the bundle docs) to make sure the lxd containers get a bridge interface to the correct network.
#juju 2017-11-08
<bdx> rick_h: is there special prometheus/telegraf/grafana bundle floating around that works with cmr/juju-2.3beta?
<rick_h> bdx: just have to grab my versions in http://jujucharms.com/u/rharding
<bdx> Ooooooo
<bdx> rick_h: possibly you haven't granted me access?
<bdx> oh the charms there
<bdx> are the ones I'm looking for
<rick_h> bdx: everyone has? https://jujucharms.com/u/rharding/prometheus/2 and https://jujucharms.com/u/rharding/telegraf/0
<bdx> IC
<rick_h>  bdx right
<bdx> you deploy telegraf to the model on which you want to monitor the things on?
<bdx> and relate telegraf across to prometheus then?
<bdx> or, you offer up the prometheus endpoint
<bdx> I see
<bdx> offer up the prometheus endpoint
<bdx> then the target model telegraf can relate
<rick_h> bdx: right, telegraf is the subordinate that goes onto the things you want to watch
<bdx> totally
<rick_h> bdx: right, should be some blog examples to walk through from the demos if that helps
<bdx> already on it
<bdx> thx
<rick_h> awesome
<kwmonroe> not awesome rick_h
<rick_h> kwmonroe: :( but but can it please be awesome?
<kwmonroe> i hate our monitoring stack, and here's why...
<kwmonroe> it's too hard
<kwmonroe> rick_h: i want to gather logs and metrics from my deployment.. maybe that's k8s, maybe that's hadoop, etc.  it's hard to figure out whether elastico or prometheus or roll-your-own-rsyslog will serve me best.
<rick_h> kwmonroe: yea, I think that getting the data into prometheus is alright as things tend to build that part in
<rick_h> kwmonroe: the missing gap is that the relations needs to send sample dashboards over the wire to pre-setup the grafana/visualization bit for that data
<rick_h> kwmonroe: imo and all that
<kwmonroe> rick_h, yes! we can give peeps a great deployment and functional UI in one shot.  things like "sample dashboards" are what we're lacking.
<bdx> https://github.com/jamesbeedy/layer-elasticsearch/issues/10
<bdx> I'm on the same track
<rick_h> kwmonroe: yea, so in the work we did for monitoring Juju we gave a  downloadable sample dashboard but you have to import it manually
<bdx> I figured if I can get the grafana-source relation working there
<bdx> that would help pull it all together
<rick_h> kwmonroe: I think the thing is that the thing feeding prometheus data knows about the dashboard json, but has to pass that through prometheus, to grafana somehow
<rick_h> bdx: yea, but it's a bit different since it's a relation once removed (one link back)
<bdx> huh
<bdx> "things like "sample dashboards" are what we're lacking" - totaly
<bdx> @kwmonroe we need to start a hoard of dashboard json
<rick_h> bdx: sorry, I thought you were saying prometheus should do it "I figured if I can get the grafana-source relation working there"
<bdx> nah.
<bdx> I got it working
<bdx> with elasticsearch
<bdx> not 100%
<rick_h> I'm just saying if you monitor a machine with telegraf the telegraf charm should have sample grafana dashboards and I'm not sure how to get them to grafana through prometheus
<bdx> but like working/bronk working
<rick_h> bdx: ah, ES in particular
<bdx> yeah
<rick_h> bdx: gotcha, I read too much into it my bad
<bdx> nw
<bdx> I prefer grafana over kibana, I think its good to have both options for people (I've a new kibana charm in the works now)
<bdx> but for *me*
<bdx> I just want it all in one place
<bdx> it makes sense to just have the two backends plugged into grafana
<bdx> then you can get your elastic beat metrics
<bdx> for logs
<kwmonroe> i prefer "juju run --all top" for my metrics, but i get that others want this pesky stuff called "data".
<bdx> lol
<bdx> right
<kwmonroe> bdx: let's say i want to propose a visualization engine for metrics/log analysis. your vote is +1 for grafana?
<bdx> yeah
<bdx> its multi-backend capable
<kwmonroe> k, that settles it.  we're doing kibana.
<bdx> haha
<kwmonroe> ;)
<kwmonroe> bdx: you tested so well the first time, let me try another.  prometheus vs elastic.  what say you?
<bdx> we need a snap monitor
<bdx> to export logs from snaps
<bdx> kwmonroe, rick_h: how are you guys getting snap logs exported?
<bdx> oh, nm
<bdx> Im guessing you just pick them up from syslog
<kwmonroe> bdx: i really don't know what you're asking... like a report from "snap list" for installed snaps?
<kwmonroe> how in the holy heck this is related to prometheus/grafana/kibana monitors is a mystery to me.  get back in line bdx, one topic at a time.
<bdx> lol
<bdx> well
<bdx> I just snapped our api
<bdx> my next goal
<bdx> like tomorrow is to get the logs sending through filebeat
<bdx> https://forum.snapcraft.io/t/best-practice-for-logging/1210/7?u=jamesbeedy
<bdx> so I asked the snapcraft guys what the best practice is there, to get the logs from your snaps
<bdx> and the say to log to syslog
<bdx> so I did that
<bdx> but that doesnt actually mean your same log entries get into the actual system syslog
<bdx> all in all
<bdx> what I'm saying is
<bdx> I don't know how to export the logs of a snap
<bdx> and I feel its a difficult task
<bdx> that I am extremely pressed to figure out
<bdx> and I'm entirely blocked because I dont know how to export the darn logs for my snapped processes
<bdx> if everyone is snapping their software, this has to be a common issue
<bdx> if there is one thing that is a blocker for the whole logging deal using canonical tech
<bdx> its exporting logs from snaps
<bdx> for sure
<rick_h> bdx: hmm, yea not sure tbh. I think stuff is still early into snaps and gaps like this need some love. I've not tried it out myself so no first hand exp.
<bdx> ok
<bdx> kwmonroe: your snapping quite a bit
<bdx> how are you exporting your snapped process' logs?
<bdx> ahh possibly they snap cant be in devmode
<bdx> omg
<bdx> im so silly
<bdx> my logs were never showing up in syslog because I hadnt ever taken my snaps out of devmode
<bdx> oh it wsa probably actually the confinement mode confinement
<bdx> getting switched to classic
<bdx> there we go
<bdx> ok glad I figured that out
<kwmonroe> bdx: i had to go see a guy about a thing.  i'm sorry i missed the diatribe, but here's the juice.  use the content interface to provide data from one snap to another (or the filessytem as a whole)
<kwmonroe> it works wonders with 2.29
<kwmonroe> sure, classic mode can save you, but you can enforce all kinds of specialness if you go confined. nothing good, mind you, but all kinds for sure.
<bdx> nice
<bdx> ok
<bdx> Ill look into this immediately
<bdx> snapd 2.29?
<bdx> is that in zesty or something
<bdx> https://packages.ubuntu.com/bionic/snapd
<bdx> its not even in bionic
<bdx> oooh
<bdx> adha
<kwmonroe> bdx, stop being a sheeple
<bdx> that is a funny joke kwmonroe
<kwmonroe> ;)
<kwmonroe> snap refresh core --channel candidate will get ya 2.29
<kwmonroe> sudo ^^ and what not
<kwmonroe> anywho, i really do have to bug out.. point i was trying to make is the new ability to share bits via the content interface.  if you're interested, here's how something like the "pig" snap talks to hadoop, which is only available in 2.29: https://github.com/juju-solutions/snap-pig/blob/master/snap/snapcraft.yaml#L29
<bdx> oh beautiful
<bdx> thank you
<bdx> go bug out now
<bdx> ;)
<kwmonroe> fwiw bdx, that only works because the 'configure' script of the pig snap makes that directory. it's a fickle time to be alive. i'm happy to chat with you more about how this stuff works -- maybe even headline the juju show this week.
<bdx> yeah
<bdx> you should
<bdx> that would be great
<bdx> @rick_h^
<bdx> not sure what you agenda is
<kwmonroe> oh hell, now you've gone and made it official
<bdx> im hungry
<bdx> for blood
<kwmonroe> heh, see you folks manana
<rick_h> Lol on the hook!
<rick_h> Night kwmonroe
<siraj> I am still looking for some help in this "unable to remove a service using juju remove-service <service-name> or by juju remove-unit or even removing a machine by juju remove-machine command. Even i deleted container still juju show-status display associated machine, application"
<ChaoticMind> I'm having trouble provisioning a ceph cluster via juju. I think I got most of it going, but curl'ing the radosgw results in "Empty reply from server" -- can any folks with ceph/openstack experience provide insight?
<zeestrat> Hey ChaoticMind, what are you deploying on (MAAS?) and how (bundle?)Ã
<ChaoticMind> zeestrat: I'm deploying on aws, via my own bundle which includes ceph-mon/ceph-osd/ceph-radosgw/keystone/horizon/percona(mysql) with appropriate relations etc
<zeestrat> ChaoticMind: Gotcha. What do the radosgw logs say? Are you using network spaces by any chance?
<ChaoticMind> Is there maybe like a minimum viable bundle available somewhere? The logs via juju debug-log aren't super helpful. Nope, not using network spaces.
<ChaoticMind> Is there some specific log you're referring to?
<ChaoticMind> oh, also, trying to follow https://jujucharms.com/ceph-radosgw/#access results in the command just hanging
<zeestrat> Try to `juju ssh ceph-radosgw/0` and look at `/var/log/ceph/radosgw.log`
<zeestrat> The guys in #openstack-charms (https://jujucharms.com/u/openstack-charmers/ in the charm store) have a bundle, but that is aimed at maas. You could ask the guys there if they have anything for specific for aws.
<ChaoticMind> ah thanks zeestrat - it looks like it didn't initialize properly -- unable to find a keyring on /etc/ceph/keyring.rados.gateway. Have to figure out why
<[Kid]> zeestrat, i am trying my new YAML and getting the same thing i was before
<[Kid]> ERROR invalid charm or bundle provided at "./k8s-v1.yml"
<[Kid]> https://pastebin.com/5XCNwXT3
<[Kid]> is there a way to get a more verbose output on where juju is erroring?
<[Kid]> like what line, column type debug
<kwmonroe> [Kid]: try running 'charm proof' on the directory with your yaml.  you'll need to call it 'bundle.yaml' because i think that's a hard req for proofing bundles.
<kwmonroe> [Kid]: when i ran it, it complained on line 28 and 40ish.  looks like you're missing the "to:" directive before your lxd:x entries.
<zeestrat> Also, I think you can drop machine definitions 2 to 7 and just add the constraints part to the worker charm
<rick_h> Juju show in 15min!!!!
<rick_h> woot woot!
<rick_h> link for folks that want to join in the chat https://hangouts.google.com/hangouts/_/zxyr3qie45ejfh2x7x7sva5szee
<rick_h> kwmonroe: bdx hml tvansteenburgh cory_fu marcoceppi and anyone else that I can talk into it :)
<rick_h> ^
<rick_h> for watching from the sidelines you'll want the link: https://www.youtube.com/watch?v=YFwE6x6JETY
<cory_fu> Cynerva, ryebot: ^
<rick_h> bdx: you coming today?
<cory_fu> https://github.com/juju-solutions/charms.reactive/pull/123
<cory_fu> Also, here is an example interface refactored to use it: https://github.com/juju-solutions/interface-kube-control/blob/6987921aacb7a03c01b635a9465873683a6a54ac/provides.py
<cory_fu> bdx: Have you used the --wheelhouse-overrides option for charm build to test some of these in-progress features?
<bdx> no
<bdx> I can feed that a wheelhouse tarbal?
<cory_fu> bdx: Newer versions of charm-build support --wheelhouse-overrides that lets you provide an external wheelhouse.txt file when building a charm that will override items provided by the charm or layers
<cory_fu> Not a tarball, alas
<cory_fu> Might be worth doing as another feature
<cory_fu> But it lets you override items line-by-line
<bdx> cory_fu: how is it that I get your branch into the wheelhouse.txt?
<kwmonroe> content interface docs: https://forum.snapcraft.io/t/the-content-interface/1074 <-- rick_h
<cory_fu> bdx: You can use the VCS URL support: https://pip.readthedocs.io/en/stable/reference/pip_install/#vcs-support
<zeestrat> Who's in charge of charmhelpers? The docs situation is a bit of a mess. https://github.com/juju/charm-helpers/issues/27
<rick_h> damn, hit done on that and it killed my chrome
<rick_h> kwmonroe: :P the last thing I heard before crashing was something about "get it together at the end"
<kwmonroe> yeah rick_h, i was trolling on your ability to get your k8stuffv2 deployed.  you did it though.  nice job :)
<rick_h> kwmonroe: hah, /me dances harder for the fans
<cory_fu> zeestrat: Hrm, yeah, that's probably because pythonhosted.org has been deprecated and uploads all but disabled.  We need to set it up on RTD.io
<zeestrat> That would be great :)
<cory_fu> tvansteenburgh: Are you admin on the charm-helpers GH repo?
<tvansteenburgh> cory_fu: yes, and so are you
<tvansteenburgh> oh wait
<cory_fu> tvansteenburgh: Nope.
<cory_fu> It's probably just jamespage, I suspect
<tvansteenburgh> cory_fu: yeah probably, i'm not
<cory_fu> tvansteenburgh, zeestrat: Ok, I pinged him on the issue.  Should be pretty straightforward to get done when he's in.
<bdx> https://imgur.com/a/4oM40
<bdx> all of those ^ machines are right next to eachother in the same subnet
<bdx> just because its a cross-model relation shouldn't mean we automatically assume the public ip
<bdx> I know I've talked about this with jam and axw (I think)
<bdx> but I just want to make it apparent such that its something people think about as they use the new networking functionality
<bdx> I absolutely do not want my things to talk over the wan when they are sitting right next to eachother
<bdx> hopefully others start to see this, and start yapping about it
<bdx> "all of those ^ machines are right next to eachother in the same subnet" - the machine are also right next to prometheus and grafana
<bdx> in the same subnet
<bdx> not sure if people are aware
<bdx> or even care
<bdx> I guess we are making the assumption that if things are in a different model, then they dont have rout-ability to eachother
<bdx> or possibly, just the wrong endpoint was chosen from network-get
<bdx> idk
<[Kid]> kwmonroe, thanks! i completely missed that
<[Kid]> and that charm proof command is handy!
<kwmonroe> np [Kid]
<jamespage> cory_fu: hey - what do you need?
<cory_fu> jamespage: You're up late.  :)  I was going to set up the charm-helpers repo on readthedocs.org, but I don't have sufficient permissions.  So it's up to you to either set it up there, or give me perms to do so
<jamespage> cory_fu: in australia - what's your github handle?
<cory_fu> jamespage: johnsca  Then you're up even later than I thought!
<jamespage> cory_fu: ok you have admin on that repo now
 * jamespage heads for breakfast
<[Kid]> kwmonroe, is charm a separate program?
<cory_fu> jamespage: Thanks!  Oh, I guess it's early there, then
<[Kid]> i.e., do i need to apt-get install charm?
<cory_fu> I'm bad at timezones
<zeestrat> cory_fu: Great. Would also be handy to redirect the pythonhosted site and update the pypi as it has a decent google rank.
<[Kid]> ahh got it
<[Kid]> charm-tools
<cory_fu> zeestrat: Unfortunately, I haven't found a way that (still) works to do a pythonhosted.org redirect.  Best I can do is delete the docs from there entirely
<[Kid]> haha, now i am getting FATAL: Not a Bundle or a Charm, can not proof
<[Kid]> and i named it bundle.yaml
<[Kid]> haha, but it works anyways
<[Kid]> oh well
<kwmonroe> [Kid]: charm is a separate program, and while i think you've stumbled onto the ppa that provides charm-tools, the recommended install method is to 'sudo snap install charm'.
<kwmonroe> not sure why you're getting a fatal error, but you can pass --debug to the charm command.  perhaps that'll reveal something.
<[Kid]> it works
<[Kid]> it is deploying, but still only deploying 5 out of the 8 nodes
<[Kid]> will it deploy in stages?
<[Kid]> i.e., do 5 then the other 3?
<[Kid]> this is my new bundle.yaml
<[Kid]> https://pastebin.com/GBHKFtzi
<[Kid]> and i have the "worker" tag on the nodes in MAAS that are not being deployed
<[Kid]> but they are showing "down" in juju status
<kwmonroe> [Kid]: juju should do all the machines at once -- maybe maas is just taking a bit of time to fulfil the request.  you could try passing --debug to the juju deploy command to see if that bubbles up any provisioning errors from maas.
<kwmonroe> [Kid]: fyi, you can run 'juju deploy' multiple times and it'll reuse existing deployed stuff, so like if easyrsa is already in your model, a subsequent juju deploy will just reuse it.
<[Kid]> ahh that is good information
<[Kid]> maybe that will kick start MAAS
<zeestrat> [Kid]: Just to be clear, how many nodes do you have in maas and how are they tagged? Could ya also pastebin `juju status`?
<[Kid]> zeestrat, i have 8 nodes
<[Kid]> first two are tagged: master,worker
<[Kid]> the rest are tagged: worker
<[Kid]> https://pastebin.com/DRAgWsV5
<[Kid]> juju status
<[Kid]> thing is, MAAS spun up 5 nodes
<[Kid]> and not 3
<[Kid]> and the 3 it didn't spin up are in a "Ready" state powered off
<[Kid]> the two that are labeled master,worker were spun up, but they arent being seen by juju
<thumper> [Kid]: are there any errors in the juju log?
<[Kid]> just ran deploy again against the same bundle also.
<[Kid]> https://pastebin.com/CYbbP8qA
<[Kid]> umm in /var/log/juju.log?
<[Kid]> i mean /var/log/juju/logsink.log?
<thumper> or juju debug-log
<zeestrat> [Kid]: Gotcha. Thanks for the info. I see the model shows version 2.0.2. Could you write the output of `juju version`? Just wanna make sure you're on an up to date juju first.
<thumper> actually
 * thumper thinks of a nice way
<[Kid]> juju --version
<[Kid]> 2.0.2-xenial-amd64
<thumper> oh dear
<thumper> you really want to be using newer
<thumper> however
<[Kid]> i used snap install
<[Kid]> that should have pulled latest, right?
<thumper> juju debug-log -m controller -l warning --replay
<thumper> [Kid]: snap list
<thumper> how old is the controller?
<[Kid]> snap list
<[Kid]> Name  Version    Rev   Developer  Notes
<[Kid]> core  16-2.28.5  3247  canonical  core
<[Kid]> juju  2.2.6      2739  canonical  classic
<thumper> when did you bootstrap the controller?
<[Kid]> like a week ago
<thumper> juju status -m controller
<[Kid]> this is a brand new install
<zeestrat> @thumper, might we have a case of mixed snap and ppa install?
<[Kid]> juju status -m controller
<[Kid]> Model       Controller  Cloud/Region  Version  Notes
<[Kid]> controller  dal01-maas  dal01-maas    2.0.2    upgrade available: 2.0.4
<[Kid]> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
<[Kid]> Unit  Workload  Agent  Machine  Public address  Ports  Message
<[Kid]> Machine  State    DNS          Inst id  Series  AZ
<[Kid]> 0        started  10.1.105.15  6hqhy4   xenial  default
<[Kid]> 1        started  10.1.105.16  n83trc   xenial  default
<[Kid]> 2        started  10.1.105.17  e6qkdm   xenial  default
<zeestrat> [Kid]: Could you also do a `sudo dpkg -l | grep juju`
<[Kid]> just to be clear the 3 controllers it is showing are VMs
<[Kid]> and the machine i am running these commands from is the MAAS server
<[Kid]> so i could bootstrap
<[Kid]> ii  juju                               2.0.2-0ubuntu0.16.04.2                     all          next generation service orchestration system
<[Kid]> ii  juju-2.0                           2.0.2-0ubuntu0.16.04.2                     amd64        Juju is devops distilled - client
<[Kid]> ii  python-jujubundlelib               0.4.1-0ubuntu1                             all          Python 2 library for working with Juju bundles
<zeestrat> Looks like there's an old juju installed. I'd suggest removing the juju and juju-2.0 packages with apt remove etc. Then hopefully you should end up with 2.2.6 from the snap.
<zeestrat> Then if it's OK, destroy the controller and do a fresh bootstrap with 2.2.6.
<[Kid]> this is wierd
<[Kid]> Removing juju (2.0.2-0ubuntu0.16.04.2) ...
<[Kid]> juju --version
<[Kid]> Removing juju (2.0.2-0ubuntu0.16.04.2) ...
<[Kid]> 2.0.2-xenial-amd64
<zeestrat> You probably need to purge those packages
<kwmonroe> [Kid]: might also want to 'export PATH=/snap/bin:$PATH' to make sure the snap executables take precedence
<[Kid]> kwmonroe, that did i!
<[Kid]> the export now points to the right juju
<[Kid]> 2.2.6
<[Kid]> another wierd thing is when it destroys the model, it will release all the nodes except for the two that have the dual tags.
<[Kid]> the worker,master two
<[Kid]> i have to manually release those
<[Kid]> trying with 2.2.6 now
<[Kid]> well this is stupid. i just rebooted and right back to 2.0.2
<[Kid]> ok, its cause it isn't keeping the system variable
<[Kid]> how can i make that variable persistant?
<zeestrat> Yeah, if purging those packages aint an option, you could fix your path in .bashrc or the like
<[Kid]> crap, i have to bootstrap again too
<[Kid]> cause the controllers are at 2.0.2
<zeestrat> [Kid]: As it's getting late for my brain, here's what I'd do if you still end up with the nodes not deploying. Make sure juju is able to deploy all maas nodes, for example by just deploying a bunch of ubuntu charms `juju deploy ubuntu -n 8`. If all good, remove the worker tags from the master nodes in maas for now just to avoid any confusion and try to deploy something like this: https://pastebin.com/UP3CpdD3
<zeestrat> By the way, what version of maas are you running?
<[Kid]> 2.2.2
<[Kid]> zeestrat, kwmonroe, and thumper. thank you for your help, i really apprciate it
<zeestrat> Great. That should work fine.
<[Kid]> i see how beneficial juju and maas can be together, just have to get past these bumps. helps me learn though
<kwmonroe> w00t, great to here [Kid]
<kwmonroe> er, hear
<thumper> [Kid]: you probably could have upgraded the controllers
<thumper> rather than redeploy
<[Kid]> crap. oh well
<[Kid]> i am almost done bootstrapping again
<[Kid]> also, i meant to mention i am in a HA cluster
<[Kid]> for the controllers
<thumper> you will find 2.2.6 much better than 2.0.2
<thumper> faster
<thumper> and more stable
<[Kid]> that is good
<thumper> better memory footprint
<[Kid]> yeah, the ubuntu repos are usually way behind
<[Kid]> i don't like bleeding edge, but they are barely trickling blood edge
<[Kid]> well, this is interesting
<[Kid]> 2.2.6 gives me more detail
<[Kid]> cannot run instances: cannot run instance: N
<[Kid]> o available machine matches constraints: [('tags', ['master', 'worker']), ('agent_name', ['d71fcd25-e
<[Kid]> 11b-4991-8831-1349aca1ad9a']), ('zone', ['default'])] (resolved to "tags=master,worker zone=default")
<[Kid]> they are there.
<[Kid]> and now the only machines it spun up are the two that have the master,worker tags
<[Kid]> ahhh there we go
<[Kid]> it is spinning more up now...
<[Kid]> so now i think it has something to do with those tags
<[Kid]> its like it doesn;t like having two tags as a constraint
<zeestrat> [Kid]: I'd try not using multiple tags in constraints like I described above to avoid the issue for now and come back to that later.
<[Kid]> ok
<[Kid]> and i can just use the to: instead of contraints
<thumper> [Kid]: why does the machine need both master and worker tags?
#juju 2017-11-09
<[Kid]> thumper, so that i can put the master and worker roles on it, but when i thought this through, i think that i can just put the master constraint on the machine level and then in the application level point the to: to the "master" nodes
<akshay__> Hi All
<akshay__> Do we have python api's equivalent to juju cli's?
<akshay__> I am looking for a python api equivalent to "juju status - -format json"
<zeestrat> akshay__: have you checked out https://github.com/juju/python-libjuju ?
<bdx> can I specify juju 2.3 storage in a bundle?
#juju 2017-11-10
<jac_cplane>  I'm running into bug 1628337 - cloud init install NTP before configuring archives.   I see from github that it was fixed 20 days ago.  can someone tell me how I can get this fix?   i'm running MAAS 2.1.5 - I deleted my current xenial image and downloaded it again via maas.
<mup> Bug #1628337: cloud-init tries to install NTP before even configuring the archives <verification-done> <cloud-init:Fix Released by smoser> <cloud-init (Ubuntu):Fix Released> <cloud-init (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628337>
<jac_cplane> please disregard - figured it out
<bdx> does anyone have an example bundle that uses a default space binding?
<bdx> like
<bdx> juju deploy --bind "default-space db=db-space db-admin=admin-space" mysq
<bdx> but in a bundle
<bdx> http://paste.ubuntu.com/25929870/
<bdx> I want to deploy charms to lxd and bind to spaces in a bundle
<bdx> but then other charms that don't have network bindings fail to deploy when not given a default space
<bdx> just unsure how to do that in the bundle
<Dmitrii-Sh> bdx: have to be explicit in every app for now
<Dmitrii-Sh> https://bugs.launchpad.net/juju/+bug/1719804
<mup> Bug #1719804: Allow specifying a default space binding on a per-bundle basis <juju:Triaged> <https://launchpad.net/bugs/1719804>
<Dmitrii-Sh> bdx: you could use yaml aliases to define a single space and reuse it across different charms
<Dmitrii-Sh> aliases:
<Dmitrii-Sh>   default-space: &default-space my-space
<Dmitrii-Sh> ...
<Dmitrii-Sh> bindings:
<Dmitrii-Sh>   "": *default-space
#juju 2017-11-11
<[Kid]> what does everyone use for their juju controllers since they don't need to be metal really or anything that powerful? raspberry pi even?
<kwmonroe> [Kid]: i use jaas (juju as a service)... not only do they not have to be metal, they don't even have to be yours!  https://jujucharms.com/jaas
#juju 2019-11-04
<wallyworld> hpidcock: lgtm, ta
<wallyworld> thumper: do you know the status of the open PRs for branches etc - are they due to land prior to rc1 being built?
<thumper> wallyworld: rick_h said that they had landed what needed to be landed and had a hash to use
<thumper> so I'd say that nothing should land that isn't a bug fix
<thumper> until we are past RC1
<wallyworld> yup, no worries, just checking
<wallyworld> we're just landing the race fix and that's it from us
<wallyworld> timClicks: fyi i updated k8s release info in https://discourse.jujucharms.com/t/new-features-and-changes-in-juju-2-7/2268
<wallyworld> anastasia will need to do some cloud updates
<wallyworld> as the examples are now out of date
<timClicks> wallyworld: awesome, thanks for adding details there
<wallyworld> i also will add extra info the the referenced pod spec v2 post
<wallyworld> as i need to add custom resources
<wallyworld> there's a lot in this release
<timClicks> I'll get the cloud stuff updated tomorrow
<wallyworld> i also made a slight correction tojuju-run
<wallyworld> k8s doesn't support juju ssh
<wallyworld> you need to kubectl exec in directly
<timClicks> ah okay, ty
<wallyworld> not that hard to add but ran out of time :-(
<wallyworld> you would think as a user it would be there
<wallyworld> but not yet
<wallyworld> there is a valid workaround k8s folks know how to use
 * timClicks nods
<timClicks> we could take out the help output and change it to something else..
<timClicks> we could take out the help output and change the example to something else..
<hpidcock> should we also update documentation re action id not being uuids? https://jaas.ai/docs/working-with-actions
<timClicks> hpidcock: thanks for volunteering - scroll to the bottom of the page, click the link
<hpidcock> hah should keep my mouth shut
<timClicks> somewhat more seriously, if you would like to add a comment on that page i'll make sure that gets done
<timClicks> I'm trying to block out some time this arvo for some other content
<timClicks> i realise that it feels a little bit scary to directly edit the docs yourself
<hpidcock> oh I'm happy to edit it
<hpidcock> just a shame we don't version the documents by release.
<timClicks> i think there's history there
<thumper> hpidcock: we used to
<thumper> hpidcock: but not any more
<hpidcock> wallyworld: did we want to remove the developer-model feature flag requirement for k8s actions and exec?
<wallyworld> hpidcock: ah bollocks, i didn't realise we still had that turned on
<wallyworld> yeah, let's get up a pr
<hpidcock> I'll make a PR?
<hpidcock> kk
<wallyworld> thumper: i have one to add for 2.7.1 https://github.com/juju/juju/pull/10848
<wallyworld> thumper: also, we need to land this for rc1 as a feature flag was left in https://github.com/juju/juju/pull/10849
<wallyworld> make you wonder how much non dev testing we got
<thumper> wallyworld: ok
<thumper> land it and update the email
<wallyworld> i guess it's just for juju exec and most people would have tried juju call
<hpidcock> wallyworld: https://github.com/juju/juju/pull/10849 I think it was just exec/run that was checking for the ff.
<wallyworld> yeah
<wallyworld> it was
<hpidcock> so I'm ok to land?
<wallyworld> hpidcock: yeah, i just hit $$merge$$
<wallyworld> good catch
<hpidcock> oops
<hpidcock> double $$merge$$
<wallyworld> it won't mind
<hpidcock> I guess we are testing jenkins then ;)
<wallyworld> jam: one thing - application relation data isn't propagated between models for cmr i don't think, so that will need to be a known linitation for 2.7.0
<wallyworld> there's params structs that need updating, plus apis etc
<jam> wallyworld: sure. we can target that as a 2.7.1 if you like.
<wallyworld> i think we should, same with remaining model migration work etc
<hpidcock> wallyworld: how do I upgrade an IAAS controller using a local jujud?
<hpidcock> do I just pass --build-agent?
<wallyworld> hpidcock: yup
<hpidcock> wallyworld: I think I hit the bug kelvinli_ hit where the caas model is upgraded but the workloads aren't redeployed. I think the caasunitprovisioner's application worker doesn't fire when the model version changes, not sure what the solution to this would be. Possibly the caasunitprovisioner worker should pass a chan into the application worker so it can trigger on model version change?
<hpidcock> I'll see if I can smash out a PR to fix it.
<wallyworld> hpidcock: quick chat about it?
<hpidcock> stdup
<kelvinli_> yeah, we need to change the init container using the updated jujud version
<kelvinli_> not sure if the init container will be re-run if the image path changed
<stickupkid> manadart, https://github.com/juju/juju/pull/10844 Fancy giving this a review?
<manadart> stickupkid: Sure.
<stickupkid> ta
<manadart> stickupkid: Couple of UX things.
<stickupkid> noice
<stickupkid> manadart, good shout on -n 0
<nammn_de> stickupkid: wanna take a look at branch completion? Removed the Option flags and added `--branch < tab > --> branch  https://github.com/juju/juju/pull/10845
<stickupkid> nammn_de, sure
<nammn_de> stickupkid: and this one? https://github.com/juju/juju/pull/10836 its about the charm dep we recently changed. With this some tests are failing because how we place and version those charm tests. Not important for now but might wanna take a look and discuss
<nammn_de> more information and this issue with suggestions how to solve. But not that important for now
<nammn_de> stickupkid: ahhh  I need some feedback on this comment https://github.com/juju/juju/pull/10836#issuecomment-548414256
<nammn_de> i reformated the comment, makes it more readable
<stickupkid> ah ok
<nammn_de> stickupkid: if read. Does it make sense to you?
<stickupkid> nammn_de, thinking
<stickupkid> i don't like the first or the last
<stickupkid> the test sucks
<stickupkid> that's what the test does
<stickupkid> suck
<nammn_de> stickupkid: haha
<nammn_de> yeah
<nammn_de> and additionally its difficult because that they are under git and using version regarding the charm thing. Makes all more complex as the tests in general already are :D
<stickupkid> nammn_de, ho?
<stickupkid> manadart, got a sec as well?
<manadart> stickupkid: Yeah.
<nammn_de> stickupkid: sure sorry wasnt here
<stickupkid> manadart, updated my PR
<manadart> stickupkid: OK, gimme 2.
<nammn_de> stickupkid rick_h: coming back to the branch completion cli thingi https://github.com/juju/juju/pull/10845
<nammn_de> Not even sure if we want those flags or not, just opened pr in case to have it
<stickupkid> nammn_de, kewl
<rick_h> nammn_de:  my feedback would be to make it looks like the rest of tab completion tbh
<nammn_de> rick_h: IMO I think that its would fit that way more with the rest of the tabl completion. E.g. juju switch <tab> has no flags.  --controller, --unit ect. as well not.  BUT juju expose and other similiar commands have both. The "flags/option" and the values
<hml> review anyone?  quick pr to fix nw-export-bundle test: https://github.com/juju/juju/pull/10852
<hml> ci test
<hml> stickupkid: ta!
<nammn_de> am I looking at things wrong? This fails for me for now reason. https://github.com/juju/utils/blob/master/fs/copy.go#L27  Why do we expect there to be an error before we continue?
<nammn_de> *no
<nammn_de> ahh I see it creates the folder and does not want to exist, ufff
<rick_h> guild 2.7 branch is created and pushed
<rick_h> have fun!
<rick_h> guild to be clear, that means develop is "unlocked". I'll send an email
<stickupkid> we should retarget all our stuff to 2.7 right and merge forward to develop
<stickupkid> rick_h, ^
<rick_h> stickupkid:  hmmm...actually...so I was hoping to not touch the rc1 space in case we need a fix/release
<stickupkid> rick_h, but at some point we'd need to back port?
<rick_h> stickupkid:  yea, so thinking if the idea for now would be land on develop and keep track of what we need to backport
<rick_h> after we cut .0
<stickupkid> rick_h, sweet
<rick_h> I'll put that in the email
<thumper> morning
<babbageclunk> anyone knowledgeable about shell quoting want to help me with a shell quoting problem?
<babbageclunk> my heuristic of changing quotes and adding/removing backslashes has reached its limit
<hpidcock> babbageclunk: is this for templating a script or are you trying to process arguments passed in?
<wallyworld> need a +1 on version bump pr for 2.7 branch https://github.com/juju/juju/pull/10853
<hpidcock> wallkworld done
<hpidcock> wallyworld!
<babbageclunk> hpidcock: I'm trying to use the wait_for function in a shell ci test
<babbageclunk> wallyworld!
<hpidcock> use heredoc?
<wallyworld> ta
<wallyworld> and for develop https://github.com/juju/juju/pull/10854
<babbageclunk> the weird bit is that it works if I ask for the current workload status (in jq) but not if I ask for the message.
<babbageclunk> doing my head in
<hpidcock> can you paste it?
<babbageclunk> hpidcock: jump in standup so I can talk you through it?
<hpidcock> sure
#juju 2019-11-05
<anastasiamac> wallyworld: +1
<wallyworld> hpidcock: or kelvinli_: for today sometime, no rush https://github.com/juju/juju/pull/10848
<hpidcock> np
<kelvinli_> wallyworld: so we wanna make it support LB? I thought this change was just for microk8s
<wallyworld> it's for k8s in general to handle the case where our opinionated default service type isn't suitable, eg we say loadbalancer but they just want clusterip, or visa versa
<wallyworld> and to support externalName
<wallyworld> this is just for controller service at the moment
<wallyworld> to plug the gap where just cannot bootstrap due to different k8s cluster set ups
<kelvinli_> ic
<wallyworld> the initial use case was microk8s to add in externalName support
<wallyworld> but  it's applicable everywhere really
<wallyworld> ty for review
<wallyworld> hpidcock: for 2.7.1, this adds the proxy-update-worker to the caas operator. it's already there for the k8s controller https://github.com/juju/juju/pull/10855
<hpidcock> alright
<hpidcock> wallyworld: sorry got distracted, so the proxyupdater worker writes out conf files with the proxies so that hooks can use them correct?
<wallyworld> hpidcock: that's only on iaas. for k8s (and also iaas) it unsures that http clients constructed have the proxy values set correctly
<wallyworld> *ensures
<wallyworld> we already run that worker in the k8s and iaas controller
<wallyworld> and unit agent
<wallyworld> but not k8s operator
<wallyworld> juju automatically adds the controller ip address to no-proxy
<wallyworld> to augment anything else that the user sets. so having that worker ensures that the operator agent can always see the controller
<hpidcock> hmm did you test exec with this?
<wallyworld> not exec. is it failing for you?
<hpidcock> no I'm just trying to think of things that the operator does that isn't talking to the controller
<wallyworld> i can't think of a pathway where it would fail
<hpidcock> we might need to add the k8s controller ips to the no-proxy
<wallyworld> juju does that automatically
<hpidcock> 10/10
<wallyworld> it adds them to juju-no-prpxy
<hpidcock> I mean, kube api
<hpidcock> not juju controller
<wallyworld> i see that as a cluster setup thing?
<wallyworld> outside of juju
<wallyworld> the juju-proxy settings are just to make juju agents work
<wallyworld> and charms
<wallyworld> the charm can see the juju-proxy values
<wallyworld> and can use them as it needs
<wallyworld> that's one of the reasons why we deviated from the standard proxy values
<hpidcock> yeah but `settings.SetEnvironmentValues()` sets env vars on the agent
<wallyworld> yes
<wallyworld> and we expose those JUJU_ values to the charm hook context
<hpidcock> hmm well the vendored github.com/juju/proxy uses "HTTPS_PROXY" etc
<wallyworld> we use different values on purpose
<wallyworld> so as not to interfere with any system values and let the charms decide how they want to use them
<wallyworld> we kept getting bit by corner cases
<wallyworld> and decided to make the juju configured proxy values totally separate
<wallyworld> and juju stuff (controller, agents, charms) would use those values
<hpidcock> ok so we need to document that if you specify proxy settings you may need to add your k8s apiserver address to no_proxy
<hpidcock> do you know if that is specified anywhere?
<wallyworld> hmmm, in the cloud metadata endpoint?
<wallyworld> it would be the same issue for aws or vm clouds i think
<wallyworld> i don't think k8s api endpoint would be any different in that regard
<wallyworld> i am not sure what our doc says off hand
<hpidcock> ok fair enough
<hpidcock> thanks for clarifying
<wallyworld> there is some doc https://jaas.ai/docs/offline-mode-strategies
<wallyworld> https://jaas.ai/docs/configuring-offline-usage
<wallyworld> which seems to cover what to put in no-proxy
<wallyworld> but maybe doesn't call it out explictly
<anastasiamac> wallyworld: tiny PR PTAL :D https://github.com/juju/juju/pull/10858
<wallyworld> ok
<wallyworld> anastasiamac: i don't get why we don;t think controller clouds have credentials. they must have credentials as they are in use
<wallyworld> if i add-k8s and use that cluster, there's a credental there
<anastasiamac> wallyworld: i don't think we get this info from api...
<anastasiamac> when we list clouds
<anastasiamac> irrespective... is it really relevant for controller clouds?..
<wallyworld> just trying to understand the root cause
<anastasiamac> we'd want to list all of them, no?
<wallyworld> for controller i'd think so
<wallyworld> if the user has perm to see them
<anastasiamac> wallyworld: so whether controller clouds have creds or not, does not mater - we want them :D
<anastasiamac> so this check is redundant and there is no need to change api..
<wallyworld> sgtm
<anastasiamac> \o/
<nammn_de> manadart: can you take a quick look at this one? https://github.com/juju/juju/pull/10833
<nammn_de> we can change something for review :P
<manadart> nammn_de: Looks good. 2 suggestions.
<nammn_de> stickupkid achilleasa you guys worked with it before.  Want to give a really small review? https://github.com/juju/charmrepo/pull/156 Description has reason
<achilleasa> nammn_de: looking
<stickupkid> nammn_de, do you want to wire it up in juju and change the dep package source
<stickupkid> ?
<nammn_de> stickupkid: was planning to do so in the near future. Either I change from juju/juju how we create the repo and charmarchive or I add something to charmrepo
<nammn_de> achilleasa manadart: ta
<stickupkid> nammn_de, i'd get everything full end to end, so you don't see churn?
<nammn_de> stickupkid: dependenciy wise changing the place to tmp for charm testing is actually quite the hassle, I must say :/
<achilleasa> nammn_de: where are we going to use this?
<nammn_de> achilleasa: I was planning to migrate some code here: https://github.com/juju/juju/pull/10836/files
<nammn_de> reason: currently our charm tests are taken from the juju/juju path as a repo and used from there. Thus we create a version string from there and the tests fail because they expect us to parse the version file. Solution we discussed: Moving them to a tmp path
<nammn_de> As it seems a lot of tests are using the `repo` from `charmrepo`. But as it currently is, I cannot migrate the code, because it forces me to use a relative path
<achilleasa> nammn_de: fair enough; thanks for the info
<nammn_de> achilleasa: thanks ð¦¹ââï¸
<nammn_de> woah got the feeling that i have to touch 100 places (and repos) for one small change meeeeeh xD
<nammn_de> stickupkid: before adding the repo I tried a workaround to see whether it would work here: https://github.com/juju/juju/pull/10836/files A better way would be to change the testsuite and create a tmp repo there and access it from the tests. But imo this would be more related to an additional pr.  With the new change in repo I would "just"  change
<nammn_de> this to be a "tmpRepo" https://github.com/juju/juju/blob/dfd597542ef537162a0ecff27e6a4095c23adc1e/testcharms/charm.go#L42 instead of "tmpArchive" Wdyt?
<nammn_de> stickupkid: for now I only changed the places where the tests failed (2 places) to use a tmpcharm instead of our repo
<stickupkid> nammn_de, i'd go with the lightest touch atm
<nammn_de> stickupkid: great,  one the same page here
<nammn_de> stickupkid: thats the final change i suggest, if test go through. https://github.com/juju/juju/pull/10836
<stickupkid> nammn_de, yeah, lets wait for all the tests to go through, but looks much better
<verterok> bdx: hi! found an issue with memcache interface, my proposed fix is: https://github.com/omnivector-solutions/interface-memcache/pull/2
<nammn_de> manadart: I tried to incoporate your suggestions https://github.com/juju/juju/pull/10833
<achilleasa> stickupkid: any particular reason why the root test runner is not using !/bin/bash?
<stickupkid> because portability
<stickupkid> achilleasa, i've said previously if people want to move to bash then we can do, but I think we don't really need to
<achilleasa> no 'set -e pipefail' on my box :-(
<stickupkid> yeah, that's bitten me
<stickupkid> THAT is the ONLY thing I want
<stickupkid> the work around is to split :(
<stickupkid> but on the plus side it reduces complexity of a one liner
<achilleasa> stickupkid: so how can I make a helper func abort the test with an error message?
<stickupkid> achilleasa, lets try it, we can always improve
<hml> stickupkid: whatâs the expectation for which directory the integrations tests are run from?
<stickupkid> hml, features should have their own, but we should have a group of tests that we expect to be groupable
<hml> stickupkid: iâm having âfunâ with specifying the path to a local bundle yaml
<stickupkid> hml, deploy = stuff around deploy, machines = add machines etc, cli = test failures, help messages
<hml> stickupkid: right
<hml> stickupkid: if you run main.sh blah blah blah.. .from which directory?  juju?  tests?
<stickupkid> tests
<stickupkid> tests is the root directory, everything changes into there and runs main.sh
<hml> stickupkid: rgr  got confused by âbundleâ path in run_deploy_cmr_bundle()
<hml> stickupkid: but i can change it
<manadart> hml: Mind taking a look at https://github.com/juju/juju/pull/10859 ?
<hml> manadart:  sure
<manadart> hml: Ta.
<hml> stickupkid: review pls?  https://github.com/juju/juju/pull/10860  I made some changes to the cmr bundle test in there.  Hopefully i wasnât just running things wrong.  :-D
<stickupkid> hml, looks spot on, let me test it
<hml> manadart: do we have an O7k cloud with multiple zones to test with?
<manadart> hml: Don't know. Both serverstack and canonistack all list just "nova".
<stickupkid> hml, a most, it's just paths.
<stickupkid> all*
<hml> stickupkid: yeah, just saw the lint failures
<stickupkid> hml, once I applied the fixes, it worked as designed :D
<hml> stickupkid: ho?
<stickupkid> hml, of course
<hml> manadart:  reviewed with 2 small things.
<manadart> hml: Thanks. The Cinder tests do verify the AZ at https://github.com/juju/juju/pull/10859/files#diff-2dc3b00e7504a446604d294e712eae0aR180
<hml> manadart: ah, missed that.  ty
<hml> stickupkid: updated 10860
<stickupkid> hml, https://github.com/juju/juju/pull/10862
<hml> stickupkid: looking
<hml> stickupkid: heyâ¦ though ./main.sh was the wrong way to run those tests.  :-D
<nammn_de> if someone has time for a really small line? https://github.com/juju/charm/pull/298 Old pr forgot to remove old  logger
<hml> nammn_de: timClicks got there before me.  :-)
<nammn_de> ha, thanks timClicks hml was just trying to get things running under the testsuite and saw weird logging messages :-D
<timClicks> nammn_de: shouldn't you shut down your computer?
<timClicks> it's late there
<nammn_de> timClicks: haha dont mind me, im leaving. Have a nice day !
<rick_h> night nammn_de
#juju 2019-11-06
<timClicks> I've just published a beta-quality plugin: juju-remove https://discourse.jujucharms.com/t/new-plugin-juju-remove/2318
<timClicks> hopefully this will prevent some papercuts
<wallyworld> timClicks: curious, was that in response to user feedback?
<wallyworld> hpidcock: for sometime today, a small 2.7 fix https://github.com/juju/juju/pull/10863
<hpidcock> happy to do it now, just got myself a coffee
<timClicks> wallyworld: no, was definitely in the scratch own itch
<timClicks> category
<timClicks> I kept tripping over it getting annoyed with juju that there wasn't a single remove command
<timClicks> I also wanted an excuse to play around with pylibjuju
<wallyworld> one reason is that remove-machine and remove-relation both accept integers
<wallyworld> so which one is intended when "2" is supplied
<wallyworld> but yeah, a lot of times you know what you want to remove
<timClicks> most of the time that's not a problem
<wallyworld> except when it is :-)
<timClicks> and when it is, the command asks
<wallyworld> so if i type juju remove 4
<wallyworld> how does it know relation 4 or machine 4
<timClicks> right now, it'll treat it as a machine
<timClicks> but there is some logic that I haven't committed to extract all named entities and try to find duplicates
<wallyworld> might be worth adding 0/lxc/3 to the examples
<timClicks> patch welcome
<timClicks> there's a todo in the code
<timClicks> i decided to pull back from implementing everything and seeing if people like it
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10864
<wallyworld> anastasiamac: i think warnings are ok for list/show. explanation in the PR
<anastasiamac> wallyworld: k but i disagree with ur other stmts ... do u have a min?
<wallyworld> sure
<anastasiamac> stdup?
<wallyworld> ok
<hpidcock> wallyworld: https://github.com/juju/juju/pull/10863 LGTM
<wallyworld> looking
<wallyworld> oh
<wallyworld> thanks
<hpidcock> yeah can you PR your own PR plz :P
<wallyworld> anastasiamac: here's some cherry picks from develop into 2.7 rc2 https://github.com/juju/juju/pull/10865
<hpidcock> wallyworld: no rush https://github.com/juju/version/pull/6 but need this for CAAS upgrade code (so we can match version-hash tag in dockerhub)
<wallyworld> looking
<kelvinliu_> wallyworld: this pr is for adding content interface consumer side to Juju, thanks! https://github.com/juju/juju/pull/10857, also updated microk8s side.
<wallyworld> kelvinliu_: gr8, looking, just need coffee real quick
<wallyworld> kelvinliu_: do we need the install hook anymore? isn't having the connect-peers script sufficient?
<kelvinliu_> wallyworld: just went to get some coffee. im not sure if the connect gets created automatically if microk8s was installed first, then Juju.
<kelvinliu_> coz I tested by manually creating the connection
<kelvinliu_> as we don't pull if the images are there, it might be ok even if the two hooks are all fired,
<wallyworld> kelvinliu_: the way i thought the content interface worked is that it would always trigger regardless of install order. i do think the install hookis now redundant
<wallyworld> can you do a quick test without the install hook to confirm?
<kelvinliu_> not sure how to test this.
<wallyworld> delete both. install in different orders. check the hook logs and the microk8s registry
<kelvinliu_> snap connect juju:peers microk8s:juju-info
<kelvinliu_> no, because we manually connect them
<wallyworld> what is "we"
<wallyworld> the connection should be done by the snapd infrastructure automatically
<kelvinliu_> we -> tester
<wallyworld> can we have a HO?
<kelvinliu_> hangout?
<kelvinliu_> wallyworld: no.. i have to rename the snap and rebuild them, coz the snap name has to be uniq. no namespace concept here.
<wallyworld> yup, flat namespace
<kelvinliu_> wallyworld: https://forum.snapcraft.io/t/approval-for-fwupd-classic-snap/5755/11
<kelvinliu_> wallyworld: confined snap can't use plug/slots..
<wallyworld> oh
<kelvinliu_> snapstore complains   - confinement 'classic' not allowed with plugs/slots when i was trying to push the snap..
<wallyworld> fark, ok. i'll email zygmund
<kelvinliu_> good to catch this now or next release will be interrupted..
<kelvinliu_> well, next edge push, probably not release.
<wallyworld> yeah, i've emailed him so we'll see what he says
<kelvinliu_> wallyworld: I will keep those two PRs  not merged for now
<wallyworld> yup, ty
<kelvinliu_> np
<wallyworld> kelvinliu_: what exact error did you get from the store? can you paste me the command used and error message?
<kelvinliu_> wallyworld: https://pastebin.ubuntu.com/p/Tv4ZdqcgzZ/
<kelvinliu_> wallyworld: here is the error return from snapstore
<wallyworld> ty
<kelvinliu_> np
<stickupkid> achilleasa, https://github.com/juju/juju/pull/10862/commits/176c41e5f73709778f2802e4afefb89b0a41c1b0
<achilleasa> stickupkid: nice!
<stickupkid> achilleasa, review done
<achilleasa> stickupkid: regarding the ec2 prefix, doesn't main.sh include all files? or does each test-suite run in a sub-shell and we can't have name clashes for functions?
<stickupkid> achilleasa, it only includes files in "includes" everything else is included as required
<stickupkid> achilleasa, i'd need to check
<achilleasa> I wasn't 100% sure hence the prefix
<stickupkid> achilleasa, it only includes "includes" and the test suite in question
<stickupkid> achilleasa, if you run the whole suite it will cause conflict
<stickupkid> achilleasa, nobody is going to run the whole test suite tbh, maybe we should block running the whole test suite
<stickupkid> achilleasa, it would really take a LONG time, also I'm sure it would overwrite old functions with new ones, so should be fine
<achilleasa> is it one CI job / suite the pattern we are currently going for?
<stickupkid> achilleasa, one CI job per test suite
<stickupkid> otherwise it would take way too long
<stickupkid> esp. if we're going to try and have 100s
<achilleasa> cool. just checking bec the spaces one relies on the presence of a floating nic for each test :D
<stickupkid> achilleasa,  you will have to add a jenkins job though
<stickupkid> achilleasa, i.e. new suite == jenkins job
<achilleasa> stickupkid: yeap; I will leave that for next CI day ;-)
<nammn_de> manadart: im currently looking into adding the "list-commits" command. Currently our mongo model does not have something similiar, right?  Like a inc. id number for each commit.  Following the doc I would add one, wdyt?
<nammn_de> manadart: ohhh it could be that we have one `_id` : <longchars: <number:>
<manadart> nammn_de: You want "GenerationId"
<nammn_de> manadart: but afaict the generationid is not unique, right? It "only" tells me whether and how much it has been commited
<nammn_de> the doc spec tells me somehing like: juju show-commit 3
<nammn_de> is expected
<manadart> nammn_de: It is unique, monotonically increasing.
<nammn_de> manadart: maybe we are talking about something different. Thats my output from mongo https://pastebin.canonical.com/p/s44W68zccy/
<manadart> nammn_de: It will be 0 for any branches that are in flight, or that were aborted. It starts at 1.
<nammn_de> manadart: time for a quick ho just to make sure?
<manadart> nammn_de: In daily.
<hml> stickupkid: related to pr 10862, are we going to require if you  use -l that the controller is the active one?
<stickupkid> hml, can you show me the output of juju show-controller --format=json
<hml> stickupkid: https://pastebin.canonical.com/p/QvZBNZwyqs/
<stickupkid> hml, we don't offically support localmaas, or anything but lxd and aws
<hml> stickupkid: right, but iâm not trying to use that controller for the tests
<stickupkid> the show-controller thinks you are
<stickupkid>  juju show-controller <local-controller> --format=json
<hml> stickupkid: but i used the -l flag in the cli cmd
<stickupkid> can you pastebin that with the local-controller name?
<hml> stickupkid: itâs in the first pastbin
<hml> pastebin
<stickupkid> ah - damn it "localhost"
<stickupkid> :(
<stickupkid> hml, https://github.com/juju/juju/pull/10862/commits/6e63b5b60dd08fd94294261967c58939d12107be
<hml> stickupkid: will look after the mtg
<stickupkid> hml, ta
<rick_h> stickupkid:  did that 2.7 edge building work out?
<stickupkid> rick_h, it would seem so https://launchpad.net/~juju-qa-bot/+snap/2.7-edge
<rick_h> stickupkid:  cool yea looking at the builds. I thought manadart backported this morning but maybe it's not hit yet
<stickupkid> rick_h, let me have a look
<rick_h> stickupkid:  all good, it  hit an hour ago but these build every 4 I think?
<stickupkid> yeah it is
<rick_h> stickupkid:  cool cool, just making sure since we're landing stuff like crazy on there :)
<stickupkid> manadart, quick CR for a backport https://github.com/juju/juju/pull/10869
<manadart> stickupkid: Yep.
<stickupkid> good man
<manadart> stickupkid: Ticked like an old cattle dog.
<stickupkid> what's up with the windows unit tests
<stickupkid> i think we're smashing the windows box to obilvian
<manadart> hml: Minor mechanical one: https://github.com/juju/juju/pull/10870
<hml> manadart:  trade you: https://github.com/juju/juju/pull/10872  itâs a draft until i get a full set of unit tests run.
<hml> manadart: was otp
<hml> achilleasa: do you have a few to qa and review ^^ also
<achilleasa> hml: sure
<stickupkid> rick_h, i'm making a model migration as my first step... I'll add that to trello
<rick_h> stickupkid:  sounds like a party
<stickupkid> rick_h, it should help me prevent it from breaking whilst i make changes :D
<rick_h> stickupkid:  hah sounds good
<hml> achilleasa: manadart: looking to see if i can untangle some of the interfaces/mocks/shims between the containerizer and apiserver/provisioner with this.
<stickupkid> achilleasa, let isn't available in most shell environments :(
<stickupkid> achilleasa, i've updated it to be compatible
<achilleasa> stickupkid: really? I have been using let like forever :D... maybe we should just use bash everywhere
<stickupkid> achilleasa, i'm adverse to it atm
<stickupkid> achilleasa, Constraints Liberate, Liberties Constrain
<achilleasa> one shell to rule them all? :
<achilleasa> :D
<pmatulis> is "workload status" a thing in the juju universe? if so, what does it mean?
<stickupkid> anyone want to CR an integration test around model migrations https://github.com/juju/juju/pull/10873
<stickupkid> ?
<stickupkid> i'm still impressed that we can bootstrap 2 controllers, deploy two charms and run a model migration, with a ton of introspection in under 5 minutes
<hml> stickupkid: if i get a chance iâll take a look, have a queue of reviews going :-)
<tvansteenburgh> rick_h: Do you know when --series=focal will be available in juju?
<N3tw0rK> what can I do if I have a host stuck in waiting/allocating, the node is booted and waiting so im assuming the agent wasnt installed. Is there a way to force the agent to retry?
<rick_h> tvansteenburgh:  mid-cycle
<rick_h> tvansteenburgh:  we've agreed to track the next series and have it available by mid-cycle
<rick_h> N3tw0rK:  hmmm, you can retry-provisioning but might have to check the cloud-init logs to see what wasn't happy
<tvansteenburgh> thanks rick_h
<kelvinliu_> wallyworld: a tiny intermittent test failure fix, would be great to take a look when u got time, thanks ! https://github.com/juju/juju/pull/10866
<wallyworld> anastasiamac: this PR backports the doc link fixes to 2.7 https://github.com/juju/juju/pull/10875
<anastasiamac> wallyworld: k
<wallyworld> anastasiamac: i didn't want to solve the world for the 2.7 PR as we are past time to finalise that branch; just a straight backport so that we don't ship with stale urls at least. and we can solve it properly or differently in 2.8
<anastasiamac> wallyworld: yep, hence +!
<anastasiamac> +1 even :D
<wallyworld> ! works for me
<anastasiamac> :)
#juju 2019-11-07
<thumper> babbageclunk: did the full application databag stuff get into the 2.7 rc?
<thumper> wallyworld: ^^
<wallyworld> thumper: otp, but yes, except for cross model
<babbageclunk> thumper: I'm doing the CMR part now.
<thumper> ack
 * thumper is going to mark it complete
<anastasiamac> thumper: can u ho?
<thumper> not just now
<wallyworld> hpidcock: kelvinliu: jump into standup?
<kelvinliu> yep
<timClicks> new tutorial up - https://discourse.jujucharms.com/t/deploy-a-redis-cluster-at-any-scale-on-any-cloud/2320
<timClicks> appreciate anyone's time to check for typos and also to make sure that the video plays properly
<hpidcock> wallyworld: kelvinliu: did we want to continue the discussion?
<kelvinliu> yeah, im free
<hpidcock> I guess we can do it tomorrow. I've put down as much as I can down in the doc.
<wallyworld> hpidcock: sorry, been tied up
<hpidcock> all good, I got everything down I wanted to say
<hpidcock> wallyworld: I'm considering adding a Hash field to juju/version's Number, because its passed around almost everywhere and would make this incredibly easy. But I'm also very weary that version.Number is used in so many places and would also make comparing weird because Hash isn't monotonic.
<wallyworld> yeah that
<wallyworld> jam: i had one thing to discuss which i only just recalled, but you are probs busy now?
<hpidcock> yeah that?
<wallyworld> the last bit about comparisons
<wallyworld> we compare version numbers
<hpidcock> but Version also has Tags
<jam> wallyworld: sure, I'll jump back in
<hpidcock> alpha, beta, rc are just... conveniently monotonic haha
<wallyworld> yeah, i'm sure we've used that before :-)
<manadart> stickupkid: Review? https://github.com/juju/juju/pull/10877
<stickupkid> manadart, sure
<stickupkid> manadart, some questions
<nammn_de> manadart: what is an "in-flight" branch again? Is it a not commited/aborted branch?
<manadart> nammn_de: Yes.
<nammn_de> manadart: how do I access all branches, not only in-flight ones? I cannot seem to find the proper implementation from apiserver modelgernation
<nammn_de>  This is the place I was initially trying: https://github.com/nammn/juju/blob/e012d8047bd6b8594fabdeeebf319c76ece98834/apiserver/facades/client/modelgeneration/modelgeneration.go#L293 .
<manadart> nammn_de: I think you will need a new state method to retrieve committed ones.
<nammn_de> manadart: got it
<nammn_de> I was so confused cause my ide (intellij) kept showing me that we only implemented branches interface  as a mock. Just couldnt find the impl :D
<achilleasa> manadart: quick question. Is Subnet.SpaceTag (in apiserver/params/network.go) pointing to the space ID?
<manadart> nammn_de: It fails like that sometimes. I've had the same thing.
<manadart> achilleasa: SpaceTag still implies a name.
<achilleasa> got 5 min for a quick ho?
<achilleasa> nvm I think I found what I needed
<manadart> jam: In a transaction are "a": "d+" and "a": "d-" assertions that the docs do and do not exist respectively?
<nammn_de> manadart: should I name all the new things "branch" or still "generations"?
<manadart> nammn_de: For now just keep the convention - branch refers to those not yet committed. Leave the rest as-is.
<jam> manadart: correct. those are special cased in the txn layer
<jam> manadart: I believe there constants DocExists to be clearer about it
<achilleasa> jam: manadart is it possible to have CIDR overlaps when carving spaces? e.g. 10.0.0.0/16 -> foo but 10.0.0.42.0/24 -> bar
<jam> achilleasa: are you talking actual networking, or logically?
<jam> actual networking the subnets must not overlap
<jam> otherwise it wouldn't know how to route traffic
<achilleasa> so, if I am trying to figure out the space from the address (assuming we don't have different subnets with the same CIDR), can I use CIDR comparisons to find the space and keep the first match?
<achilleasa> (if overlaps where possible I would need to find the CIDR with the smallest range)
<N3tw0rK> anyone know of a charm for the ceph nautilus manager gui plugin?
<hml> quick review pleaseâ¦ https://github.com/juju/juju/pull/10880  just want to get 10872 into develop.
<achilleasa> hml: shouldn't that be a forward port? :D
<hml> achilleasa: :-)
<rick_h> N3tw0rK:  not sure. Might hit up discourse or the openstack charming community.
<hml> stickupkid: pls let me know if youâre availalble for debug help on test_copywrite
<stickupkid> hml, i'm around
<hml> stickupkid: itâs failing locally for me, and i have no idea why.  iâd be more than happy to fix it or my machine if i could get that far.  :-)  https://pastebin.canonical.com/p/v4W67YTB99/
<hml> and itâs on ubuntu not macOS.  :-D
<stickupkid> run this
<stickupkid> find . -name '*.go' | grep -v -E "(./vendor|./acceptancetests|./provider/azure/internal|./cloudconfig)" | sort | xargs grep -L -E '// (Copyright|Code generated)'
<hml> stickupkid: it just complete without seen output
<hml> stickupkid: thatâs what confused me
<stickupkid> find . -name '*.go' | grep -v -E "(./vendor|./acceptancetests|./provider/azure/internal|./cloudconfig)" | sort | xargs grep -L -E '// (Copyright|Code generated)' | wc -w
<stickupkid> what's the output of that?
<hml> 0
<stickupkid> yay
<stickupkid> not
<achilleasa> manadart: is there any helper in state for getting a SpaceInfos instance? (the list; without having to go via SpaceInfosBy...)
<hml> ha
<stickupkid> hml https://pastebin.canonical.com/p/2GpsGwWBGk/
<achilleasa> manadart: ah... AllSpaces
<hml> stickupkid: same result, not sure itâs that, iâm not getting the output at 12/13 in diff
<stickupkid> hml, HO?
<hml> stickupkid: sure
<nammn_de> stickupkid after bumping the version, how do i make sure that my client can use it?
<nammn_de> bumping rev
<stickupkid> https://pastebin.canonical.com/p/gHq3pfC7VJ/
<stickupkid> rick_h, can you cross model migrate a SAAS, i'm guessing you can right?
<rick_h> stickupkid:  yes, should be able to
<stickupkid> rick_h, ok, so i need to fix that then :D
<rick_h> stickupkid:  yep, that's the card
<rick_h> the work to make that happen wasn't done so we're closing that gap
<hml> stickupkid:  approved
#juju 2019-11-08
<thumper> here's a very boring review for someone: https://github.com/juju/juju/pull/10884
<thumper> long and boring and almost all mechanical
<thumper> 157 files, +764 â622
 * thumper packs up for sprint
<anastasiamac> wallyworld: thank you for the review! r u k with my take o re-phrase?
<wallyworld> looking
<wallyworld> anastasiamac: made a suggestion
<anastasiamac> wallyworld: i know that historically we have only updated regions... however potentially it can b other properties too... like auth-types...
<anastasiamac> wallyworld: i think i'd rather just say 'to update public clouds ...' without any further detail
<wallyworld> yeah true. not too fussed on that bit of the wording, although region is really what it's about 99% of the time. more fussed with "from a central location" bit. doesn't really matter how, users just need to know it will happen
<anastasiamac> ta
<wallyworld> hpidcock: kelvinliu: bug 1851763 may be a rc stopper. it may just be CK on maas. microk8s worked for me this morning and i think CK on say AWS or Azure works. could one of you please confirm that is the case so we can narrow this down to just a maas issue. i need to get stuff done for the sprint
<mup> Bug #1851763: [2.7 rc2] can't deploy k8s-based model re-using cloud controller <juju:New> <https://launchpad.net/bugs/1851763>
<kelvinliu> wallyworld: im looking it now
<wallyworld> ty, i need to get stuff sorted if i can get away from the keyboard
<kelvinliu> np,
<kelvinliu> wallyworld: I tested, lxd controller <- microk8s; IaaS controller <- azure CK; IaaS controller <- aws CK; all working, so I think it should be just maas and not related with CaaS.
<wallyworld> kelvinliu: gr8 tyvm. the suspicion is that we are copying across the spaces for the controller cloud when a new model is added, and not doing a check that the model uses the same cloud
<wallyworld> maas controller cloud has spaces, k8s cloud doesn't
<kelvinliu> briefly look on apiserver/facades/client/modelmanager/modelmanager.go, didn't find any space related change.
<wallyworld> joe will look into it
<kelvinliu> thanks
<gnuoy> Hi, we just switched over to using juju 2.7 candidate and out charm testing broke. The problem is that when test a charm we use a bundle which uses all supporting  charms from the charm store and uses the local copy of the charm undertest. We reference the charm undertest in the bundle like this:
<gnuoy> charm: ../../../nova-cell-controller
<gnuoy> because the overlay with that in lives inside the charm here:
<gnuoy> nova-cell-controller/tests/bundles/overlays
<gnuoy> and the local paths seem  to relative to the overlay location
<gnuoy> this worked in 2.6 but in sit I get:
<gnuoy> ERROR cannot deploy bundle: the provided bundle has the following errors:
<gnuoy> charm path in application "nova-cell-controller-cell2" does not exist: /nova-cell-controller
<gnuoy> Soes anyone know of a 2.7 change that might account for this ?
<gnuoy> s/Soes/Does/
<stickupkid> gnuoy, nope, but a bug will be useful
<stickupkid> gnuoy, https://bugs.launchpad.net/juju/+bugs?field.tag=bitesize
<stickupkid> sorry ignore the bitesize query part
<stickupkid> https://bugs.launchpad.net/juju/+filebug
<gnuoy> stickupkid, thanks. tbh  if a full qualified path works in 2.6 I may just switch to doing that.
<gnuoy> (seems to work  in 2.7)
<nammn_de> manadart rick_h stickupkid Pr is now in a reviewable state. Happy to get some input! https://github.com/juju/juju/pull/10867
<stickupkid> training day
<nammn_de> stickupkid: ahhh you right its friday
<manadart> Need a review for the k8s-on-MAAS fix: https://github.com/juju/juju/pull/10886
<achilleasa> manadart: looking
<achilleasa> manadart: why is AllSpaces returning no subnets on maas even though they seem to have space IDs in the DB?
<manadart> achilleasa: https://github.com/juju/juju/blob/bdaefb0a07d6b033ef5c3499085889fb9f8fccb1/state/spaces.go#L98 :)
<achilleasa> should I fix it now?
<manadart> achilleasa: Yep.
<achilleasa> manadart: hmmm... space.Subnets() may potentially return an error...got to change the return signature for NetworkSpace() :-(
<manadart> Simple one: https://github.com/juju/juju/pull/10887
<rick_h> manadart:  is the space removal bits intended?
<manadart> rick_h: Yeah, that was an indirection for space lookups that no longer happen for client API addresses.
<rick_h> all good, I first read that as a "fix typo" and then saw deleted code but see the full comment on there
<rick_h> +1
<achilleasa> manadart: so, now the machiner will only update the linklayer devices while the instancepoller will update the provider addresses, correct?
<manadart> achilleasa: The instancepoller will need to merge link-layer data if it differs from what is there. Otherwise we won't have provider IDs for any of that data.
<manadart> In addition to setting those machine collection addresses.
<achilleasa> manadart: gotcha
<danboid> Is there a dedicated irc channel for Ubuntu openstack?
<danboid> I've been unable to SSH into any instances I have deployed with Ubuntu openstack
<rick_h> danboid:  definitely https://help.ubuntu.com/community/OpenStack
<danboid> The web UI says it has deployed successfully but looking at the log it doesn't look like the vm is being assigned an IPv4 address (contrary to what the web UI says) nor is it copying my SSH key
<rick_h> oh hmm, guess that's just openstack. I know they've also got something else
<rick_h> there's this but that's more for the charming/operations side but might be able to help https://docs.openstack.org/charm-guide/latest/find-us.html
<danboid> rick_h, Thanks, I'll try there
<nammn_de> rick_h:  here is the pr where i need some input for qa/ux related things https://github.com/juju/juju/pull/10867
<rick_h> ty nammn_de
<nammn_de> rick_h: I tried to follow the doc spec as much as possible :D
<rick_h> sweet
<rick_h> building now
<aisrael> rick_h: Do you know when 2.7 rc2 was released?
<aisrael> nm, looks like yesterday
<rick_h> aisrael:  yesterday?
 * rick_h can't keep track of time
<rick_h> aisrael:  one know issue causing an rc3 monday morning for a corner case of k8s models on top of maas contorller https://bugs.launchpad.net/juju/+bug/1851763
<mup> Bug #1851763: [2.7 rc2] can't deploy k8s-based model re-using cloud controller <juju:Fix Committed by manadart> <https://launchpad.net/bugs/1851763>
<aisrael> rick_h: okay. I saw there's an rc3 candidate in edge. We're chasing a couple potential bugs right now and will file them asap
<nammn_de> stickupkid: the acceptancetest fix regarding cli https://github.com/juju/juju/pull/10888
<aisrael> All related to k8s
<nammn_de> small one
<rick_h> aisrael:  sounds good thanks for filing
<rick_h> aisrael:  ty for testing the RC, much better to find stuff there.
<rick_h> nammn_de:  not sure it's direct in your PR but heads up https://bugs.launchpad.net/juju/+bug/1851853
<mup> Bug #1851853: a rolled back commit shows as a commit in list-commit <juju:Triaged> <https://launchpad.net/bugs/1851853>
<rick_h> nammn_de:  doing a proper test with a different charm that has config this time
<rick_h> nammn_de:  but I think that commit 0 might be a real issue
<nammn_de> rick_h: thanks! Oh ahhh, I think I have a small error in the query, let me change that. I suspect that i should have not searched for completed
<nammn_de> let me fix that
<rick_h> nammn_de:  cool
<rick_h> I'll keep poking
<rick_h> mmmm, back to non-dark roast coffee so yummy :P
<nammn_de> it should work for not aborted ones, because as it now, i think, it will always show aborted ones with id ==0 :D
<rick_h> nammn_de:  oh lol
<manadart> nammn_de: bson.M{"completed": bson.M{"$gte": 1}} should be generation-id instead of completed.
<nammn_de> rick_h manadart: yeah thought so as well,  patch is up :D
<nammn_de> manadart: thansk for taking the quick look!
<rick_h> nammn_de:  ok, rebuilding/back to poking ty
<rick_h> nammn_de:  ok, ty this feels really cool to play with
<rick_h> nammn_de:  feedback inbound, and the rolled back ones are good now with the patch
 * rick_h is trying to think if we have anything else in juju that's date ordered
<rick_h> I like the commits in reverse order but don't want to flip/flop if we do it another way somewhere else...but I can't think of where we would
<nammn_de> rick_h: thanks for the feedback will work it in next week.  list-users cuts off the output after the day. I can change that to that as well
<achilleasa> rick_h: perhaps a --sort=asc/desc flag?
<nammn_de> achilleasa: sounds good to me, I can add that
<rick_h> nammn_de:  oh yea, definitely don't want to just keep a day
<achilleasa> nammn_de: I am pretty sure git has a similar flag for logs
<rick_h> nammn_de:  yea, let's not do the flag yet
<rick_h> nammn_de:  but just desc and we'll tweak it after using it more for longer periods of time
<nammn_de> how "much" of the date do you think makes the most sense for list-commit?
<nammn_de> 2019-11-06  || 2019-11-06 hh:ss ?
<nammn_de> *hh:mm
<rick_h> nammn_de:  so I assumed the human readable thing did 12m ago, 4hrs ago, 10 days ago?
<nammn_de> rick_h: ahhh sure
<rick_h> is that not what it's doing? when I looked on my demo controller it was saying "12m ago" and figured it was human readable-ling
<nammn_de> its doing both,  if its further away than a timeline it shows the yyyy-mm-dd, else the human readable thingz
<nammn_de> thats why i got confused
<rick_h> nammn_de:  ah, ok that's find
<rick_h> err fine
<rick_h> nammn_de:  so cheat off what that's doing please :)
<nammn_de> rick_h: will do, cheating off is my skill
<manadart> rick_h: Backport service removal script: https://github.com/juju/juju/pull/10889
