[00:01] thumper, what's the state of mess atm? [00:01] hazmat: it's a mess [00:01] thumper, when i try to use the create api, i get panic and restarts. [00:01] hazmat: working hard to get a demo... [00:01] complaining about juju home [00:01] thumper, cool, carry on :-) just curious [00:01] huh... interesting [00:22] gotta love tests that pass for the wrong reason === kadams54 is now known as kadams54-away [00:36] menn0: quick upgrades question. i understood that fromVersion would be set to 1.16 if unknown. hence for new installs, all steps should run. I just added a new 1.23 step, and when I bootstrap from master (1.23-alpha1), no upgrade steps run. am I missing something? [00:37] wallyworld_: hmmm... I think that behaviour changed recently [00:37] wallyworld_: because it was causing problems [00:37] :-( [00:37] wallyworld_: why would you want to run upgrade steps on bootstrap? [00:38] sec [00:39] wallyworld_: let me check ... I might be getting confused with something else I changed recently [00:40] menn0: well, i am adding new things for the 1.23 release. the release will eventually be installed on top of 1.22. but of course, for development, the version is set to 1.23-alpha1 [00:40] i need to be able to run a fresh 1.23 install and have things done [00:40] the things that are needed are not there in 1.22 nor a fresh install [00:40] the old behaviour would have been perfect [00:41] and the code comments still imply the old behavbiour woeks [00:41] * menn0 is looking === kadams54-away is now known as kadams54 [00:50] wallyworld_: I'm pretty sure that i've dealt with at least 2 bug reports from users because we were running upgrade steps straight after bootstrap [00:50] wallyworld_: having from version set to old when bootstrapping was causing problems for landscape [00:50] wallyworld_: and we shouldn't ever need to run upgrade steps on bootstrap [00:50] wallyworld_: it's unnecessary and confusing and breaks scripting, meaning that you can't rely on the env being usable after "juju bootstrap" returns [00:50] hmmm [00:51] well that's a change in semantic that caught me by surprise [00:51] wallyworld_: to test what you're testing couldn't you bootstrap and then "upgrade-juju --upload-tools"? [00:51] what about new installs that need to do things [00:51] wallyworld_: that will use a new version number and trigger the upgrades [00:51] wallyworld_: what kind of things? [00:51] sure, but that doesn't account for new installs [00:52] adding default storage pools [00:52] that needs to be done for upgrades and new installs [00:52] can't that be done when state is opened? [00:52] as per mongodb indexes? [00:53] it's not really the same - i wouldn't want to add bespoke application functionality to opening a db connection [00:53] mongo indexes are a db artefact so they belong in state opening [00:54] i don't get why we didn't just make bootstrap wait [00:54] let it complete what it needed to do, and then return [00:54] no scripts broken [00:55] now, we can't add functionality required to initialise a given version of juju [00:55] but running all upgrade steps at bootstrap is completely unnecessary. a bootstrapped env is by definition up to date. [00:55] the steps are idempotent and will just skip [00:55] they don't "skip" [00:56] skip = check if already done and return early [00:56] the will still do things (query collections etc) [00:56] they just have no net effect, apart from taking up time [00:56] regardless, how do we now add things that need to be done for the current version [00:56] a small time [00:56] compared with the overall bootstrap time [00:56] sure [00:57] what we've now lost is the ability to in one place define steps to be run to upgrade or initialise a new version [00:58] all for the cost of a minimal extra 2% of bootstrap time [00:58] and also avoiding problems for users [00:58] but if bootstrap waits, there are no problems [00:59] instead, the development complexity has been increaed [00:59] well if you want to change bootstrap... [00:59] as i now have to add code in multiple places [00:59] i wish the change were mode widely socialised before being implemented [01:00] so tese issues could have been raised [01:00] * thumper calls timeout [01:00] i'll have to add a work around for now [01:01] doesn't thumper like a good robust dicussion? [01:01] wallyworld_: sure, in a week when we have time [01:01] would be voring if we always agreed [01:01] right now we are super busy [01:01] fair point. as am i trying to get stuff done which is now much more difficult, hence the grumpyness [01:02] sorry that this has made it harder for you [01:03] no need to apologise, i was just a little surprised at the change and hence frustrated [01:03] i didn't realise that upgrades steps were intended for more than upgrades, and we had problem reports from users relating to the old behaviour [01:03] wallyworld_: what are you actually wanting to do? [01:03] add default storage pools [01:03] menn0: the thing is: they shouldn't be [01:03] these need to be done when coming from older versions, as well as bootstrapping 1.23 [01:03] wallyworld_: which is what? [01:04] just adding records to a collection [01:04] so we want some out of the box data [01:04] surely this isn't a large amount of work [01:04] well, i now have to do it in two places [01:04] just one func called from an upgrade step and the bootstrap process [01:04] but then it isn't surprising [01:04] sure, but it's now messy, i'd rather fix the upgrades [01:04] having bootstrap config happen in an upgrade step is surprising [01:04] upgrades aren't broken [01:04] your thinking is [01:05] have to agree to disagree. the semantic has been in place for many versions [01:05] but the semantics were wrong [01:05] we can discuss next week [01:05] and have been fixed [01:05] relying on broken semantics is broken design [01:05] well, you can [01:06] what was wrong ws that bootstrap didn't wait [01:06] * thumper won't be there [01:06] no, I continue to say that bootstrap config in an upgrade step is broken design [01:06] wallyworld_ and I are sharing a room so we will have plenty of time for debate :) [01:06] sorry, but that is just bollocks [01:06] menn0: learn to sleep with one eye open [01:07] this is a good argument for down at the pub with beer [01:07] agreed [01:07] (or wine in your case?) [01:07] yes :-) [01:07] red [01:08] wallyworld_: so working towards an immediate solution for you... [01:08] wallyworld_: adding some rows to a collection sounds like state functionality [01:08] yeah, will hack something in [01:08] wallyworld_: so why could those rows be added if required when state is opened? [01:08] coudn't [01:08] opening state is akin to opening a db connection [01:09] it's down a layer or two from the application layer [01:10] i kinda see what you're saying but state is also full of business logic. it's not just "the database". [01:10] what was nice about upgrade was that it would be done once - the upgradedFrom would be empty, then the steps would run, and then it wouldn't happen again [01:11] now i have to encode extra checks in say state server start up tp ensure it's only done once [01:11] our state package is bollocks [01:11] wallyworld_: ok well lets see if we can work something out next week [01:11] sure [01:12] i can reply on upgrades to handle coming from < 1.23, but have to add some bespoke stuff to handle new installs [01:14] but it's bad because if i add it to bootstrap, how do i know if upgrade did it or now [01:14] not [01:14] so potentially need to check fromVersion and all that, just like upgrade does, so it gets messy fast [01:25] menn0: I've hacked together a branch that does what we talked about yesterday [01:25] menn0: I'm going to try to use it locally before I submit for review [01:26] * thumper has a sinking feeling [01:26] oh yeah... everything is still erroring with notimplemented [01:26] * thumper enfixorates the providers we care about right now [01:26] (four of them) [01:26] dummy, local, ec2, maas [01:26] dummy for tests [01:26] local for testing [01:26] ec2 for demo [01:26] maas for mark [01:30] menn0: did your branch land? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [01:53] thumper: sorry was having lunch [01:53] menn0: np [01:53] it isn't holding me up [01:53] thumper: branch not landed yet. my changes exposed brokenness in the machine agent tests which i'm fixing. [01:53] ok [01:53] this one has been a hard slog [01:55] ok [02:14] wallyworld: I just packed half your gift, still need to fix the facade to do the proper calls but I pushed the general idea for you to look [02:14] * perrito666 sleep time [02:14] cheers all [02:16] ty, will do [02:16] hope the roof holds out [02:29] * thumper crosses fingers [02:33] stabby stabby [02:33] fark!!!! [02:33] (╯°□°）╯︵ ┻━┻ === kadams54-away is now known as kadams54 [02:40] * thumper looks upwards emploringly [02:40] WHY? [02:40] why can't json serialization have integers? [02:46] thumper: pong [02:46] thumper: b/c Javascript doesn't have integers... [02:46] * menn0 ducks [02:46] wwitzel3: got time for a quick 5 min hangout? [02:46] yep [02:47] wallyworld: ping [02:50] menn0: hi [02:51] wallyworld: do you know anything about MachineSuite.TestManageEnvironDoesNotRunFirewallerWhenModeIsNone? [02:51] wallyworld: the logs indicate you might have had something to do with it [02:56] axw: remind me, were we considering supporting zones with deploy [02:57] wallyworld: last time I spoke to fwereadeabout it, he wanted that to be on add-machine only, and use machine placement in deploy/add-unit [02:59] wallyworld: last time I spoke to fwereadeabout it, he wanted that to be on add-machine only, and use machine placement in deploy/add-unit [03:00] axw: np, i'll need to add a new check analogous to isZoneConstrained() to handle VolumeTypeNotAvailableInZone [03:00] menn0: sorry, connection bouncing, not sure if you saw my pong [03:00] * thumper headdesks [03:00] wallyworld: I replied but it must have been while your connection was down [03:01] i hate this kernel bug [03:01] I was asking if you knew about MachineSuite.TestManageEnvironDoesNotRunFirewallerWhenModeIsNone. you seem to have had something to do with it according to the logs. [03:01] wallyworld: ^^^ [03:01] hmmm, mayb, i didn't write it, may have modified it [03:01] let me look [03:02] wallyworld: it appears to be broken and passing for the wrong reason [03:02] wallyworld: it's testing that the firewaller doesn't start when firewall-mode is "none" [03:02] wallyworld: but never actually sets the firewall mode [03:02] wallyworld: the mode defaults to "instance" [03:02] wallyworld: I think the test only passes because it waits for ShortWait time which is rather short [03:03] menn0: dimiter wrote it, i just tweaked the worker running [03:03] wallyworld: it's just that the firewaller isn't getting a chance to start [03:03] i don't know offhand much about it without looking at the code in more detail [03:03] wallyworld: that's cool [03:03] wallyworld: any ideas on how I can set the firewall-mode for the agent in the test? [03:04] this is what i'm doing: [03:04] m, agentConfig, _ := s.primeAgent(c, version.Current, state.JobManageEnviron) [03:04] agentConfig.SetValue("firewall-mode", config.FwNone) [03:04] c.Assert(agentConfig.Write(), jc.ErrorIsNil) [03:04] a := s.newAgent(c, m) [03:04] but the agent still ends up with "instance" as the mode instead of "none" [03:05] if you don't know off hand don't go digging. I know you're busy. [03:05] thumper: do you know? ^^^ [03:05] menn0: pretty sure we hard code that in the dummy provider [03:08] thumper: it looks like it default to "instance" in the dummy provider but there are dummy provider tests which change it [03:09] hmm.. [03:09] menn0: isn't the firewall-mode in the environ config not the agent config [03:09] ? [03:11] thumper: maybe that's what i'm doing wrong :) [03:39] * thumper takes a deep breath [03:41] axw: when you have a moment https://github.com/wallyworld/juju/pull/10 [03:43] wallyworld: LGTM [03:43] axw: question - when the attached hook runs, the storage id is passed in via env var right? i couldn't see it [03:43] ty [03:43] wallyworld: no, no env var set atm [03:44] ah, ok, cause i was going to try using the storage-get hook tool [03:44] wallyworld: it's set in the context [03:44] the bash script doesn't get to see that though right? [03:44] wallyworld: you may want to wait for my changes, I'm just doing a test and I can probably propose something shortly [03:44] sure, np [03:44] but works so far [03:44] the storage show is also light on details [03:45] wallyworld: when my change goes in, storage-get will default to the hook storage instance [03:45] so we'll need to wire that up [03:45] ah, yes, that's right [03:45] remember now [03:45] wallyworld: whee, I just deployed postgresql with storage :) [03:46] \o/ [03:46] axw: i agree the hack to work around the change in upgrade semantics is yucky [03:46] but works for now [03:47] axw: is that using a raw block device or mounting a fs? [03:47] wallyworld: the latter [03:47] even better [03:47] wallyworld: diskformatter will now mount the fs after formatting, if it's not already done, and then record the mount point in state [03:47] oarsum [03:47] then the unit agent sees the change and can get the location with storage-get [03:48] whoot [03:48] wallyworld: I have zero tests, do you want me to propose it anyway? [03:48] yes :-) [03:48] tested live is good enough :-) [03:49] wallyworld: I'll just confirm that postgres is actually working :) it has created the db dir in the mount [03:49] axw: after landing, might be an ides to sync up to plan the next bit of work [03:49] ok :-) [03:49] now that we have both landed stuff today [03:49] wallyworld: yep, sure [03:49] or soon will [03:50] * wallyworld needs a little food [04:04] wallyworld: https://github.com/wallyworld/juju/pull/11 -- I'm going to get something to eat too. bbs [04:04] sure [04:24] wallyworld: I need to fix a bunch of tests in that branch [04:24] ok, i wouldn't worry about new ones, just make current ones pass [05:03] menn0: if you are bored with your changes, there is this: http://reviews.vapour.ws/r/811/ [05:03] waigani, mattyw: or one of you on call reviewers could have a look [05:04] thumper, will do [05:04] thumper, give me 10 minutes or so and I'll take a look [05:04] mattyw: no pressure, I'm pretty much done for the day [05:05] I'm about to break but plan to come back later tonight, if it's still up I'll take a look then === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [05:31] wallyworld: I'll just test once more, then my branch hsould be good to merge [05:31] \o/ [05:37] wallyworld: also, I've pushed my postgresql to lp:~axwalk, and it can be deployed from cs:~axwalk/trusty/postgresql [05:38] wallyworld: this is what I had to change: http://bazaar.launchpad.net/~axwalk/charms/trusty/postgresql/trunk/revision/112 [05:39] looking [05:40] jeez, not many chnges [05:40] which is good [05:41] wallyworld: I think in reality we could make it much better, but atm the charm is (i.e. already was) hard coded to look in /srv/data [05:41] but this is the minimal change needed to work [05:41] yep [05:43] axw: i have a meeting at 4, quick catch up now? [05:43] wallyworld: yep, sure [05:43] see you in 1:1 [06:00] wallyworld: my branch is good to merge [06:00] merge away [06:01] wallyworld: you need to, please [06:01] oh doh [06:01] sorry [06:01] and done [06:01] cheers [06:14] anastasiamac: I'm going to fill out the details in "juju storage show" - you're not working on this, right? [06:17] axw: no ;) [06:19] axw: thnx :D [06:20] anastasiamac: nps [07:14] fwereade: are you around ? === mthaddon` is now known as mthaddon [09:34] jam, sorry, not really, we're all sick here :/ [09:35] fwereade: sorry to hear that, I've been wondering why I haven't really seen you around. [09:35] jam, that's just today [09:36] jam, the last few days I've been trying to integrate the new uniter ops in a way that doesn't hurt more than it helps [09:36] fwereade: I wanted to check in how Leader election stuff is going. [09:37] jam, it's depressing at the moment, because I keep hitting roadblocks that I have to fix before I can progress [09:48] morning [09:52] perrito666, o/ [09:55] wallyworld, anastasiamac: FYI, I've added "storage list" and modified "storage show" -- https://github.com/wallyworld/juju/pull/12 [10:46] mgz: poke [10:46] or maybe even dimitern [10:48] jam, yep, what's up? [10:49] dimitern: you saw the mailing list question about Rackspace, right? [10:49] jam, i did [10:49] I haven't personaly investigated their API, but I thought that is what we worked out [10:49] that Juju doesn't work there [10:49] I just wanted to check with other people to confirm it [10:49] jam, haven't read it thoroughly though [10:50] jam, well IIRC rackspace api does not support security groups the way juju uses them [10:51] it supports an older api, not the os-security-groups extension [10:53] dimitern: sure. I thought there were other limitations, as certainly security groups can be reasonably worked around [10:57] jam, well, looking in one of my earlier networking specs - part 1, last time I checked "Rackspace supports older/custom compute extensions (os-networksv2 and os-virtual-interfacesv2)" [10:58] jam, however now it seems it does support newer apis - but I need to investigate what and how [10:58] dimitern: k. I'd like to make sure I'm not talking garbage since there is interest there [10:59] jam, how critical is this to investigate now? [11:01] jam: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [11:03] natefinch: it thinks its trying to connect [11:14] jam: ping [11:14] jam: are you able to add jamestunnicliffe (and dimitern ) to the canonical ec2 account? [11:21] natefinch: I'm back [11:21] voidspace: /wave [11:21] jam: I'm in moonstone [11:21] natefinch: I can [11:21] jamestunnicliffe: are you around now? [11:21] yes [11:21] jam: yes [11:22] jamestunnicliffe: do you have a preferred username ? [11:22] jam: dooferlad [11:36] jam: thanks [11:36] voidspace: happy to. I should really coach someone else on how to do it. Reduce the bus factor. [11:36] dimitern: you up for it the next time it needs to be done? [11:36] jam: sounds good [11:37] voidspace: I'm pretty sure wallworld and dimitern also have the root credentials, but they may not realize it. [11:37] jam: dimitern doesn't even use the canonical aws account, he uses his own [11:37] jam: so I'm pretty sure he doesn't realize it... [11:39] jam, sorry - up for what? [11:41] jam, i probably have access to the canonical aws account, but I have to find where the info is and I haven't tried to add users to it [11:41] jam, that's not a priority for now though - we can sort it out later [11:44] axw: pool list :D - https://github.com/wallyworld/juju/pull/13 [11:44] anastasiamac: ty, will look after i finish current review [11:45] dimitern: right. not a worry this week, but I want to make sure other people know how to do it. Probably we can just go over it quickly in some downtime next week. [11:46] jam, great, I'd appreciate that [11:56] it's hailing... ugh [11:57] mgz, yes very hard [11:58] mgz, we must be in the same storm I think === gnuoy` is now known as gnuoy [11:58] I wonder who's getting it first :) [11:58] mgz, not quite so hard now [11:58] so maybe I got it first [11:59] mgz, question - I think I see a behavioral change in 1.21 [11:59] from 1.20? [11:59] or from a previous 1.21 dev release? [11:59] mgz, specifically I have a test process that bootstraps and adds a number of machines and then configures them prior to deploying services [11:59] 1.20 -> 1.21 [11:59] k [11:59] 1.20 would happily use said provisioned machines upon deployment [11:59] not so with 1.21 - it creates new machines [12:01] how we use provisiond but not deployed-onto machines has been fiddled with, I don't recall at what point exactly... [12:01] mgz, just trying to understand whether I was using a undesigned feature ot nor [12:01] there's almost certainly a way to do what you want still [12:01] hey mgz, did you do some of the rackspace investigation in the past? There's a thread on juju-dev about using Juju with Rackspace and I want to make sure I'm not regurgitating falsehoods [12:03] jam: I'll have a look at the thread - the old issue was their old (pre-use-of-trunk-openstack) setup didn't have things like security groups [12:03] I'd think everyone *should* have been switched to a more vanilla setup by now [12:03] jamespage: speaking of which, it'd be really good to get wider knowledge of why people want to preallocate, because there has been some team pushback as to "why would you want to do that". that I want to make sure we understand the use cases well. [12:08] wallyworld: can you please merge my PR? [12:09] axw: sure [12:09] jamespage: when you get to deploying the services, you're just to using --to right? [12:09] *not using [12:09] mgz, not using --to [12:10] axw: i think i have an acceptable hack for loop devices for local provider; if it tests ok that is [12:10] which used to pick a created-but-un-united machine, but does no longer [12:10] wallyworld: cool [12:10] wallyworld: looking forward to not having to bootstrap ec2 constantly... [12:10] jam: right now I use pre-allocation to setup and environment with machines attached to six different networks so i can test out the multi-network support in the openstack charms [12:10] jam: I fully anticipate that juju will replace this requirement at some point [12:11] axw: agreed, i'm not sure how long i'll be as i have some other stuff to review, plus a few chores to finish tonight. hopefully soon [12:11] jamespage: so why do that via "add-machine" rather than during "deploy" time? Easier for you to reason about ? Some flag that we support on add-machine that we don't in deploy ? [12:11] wallyworld: nps, I'll keep an eye out [12:11] jam: no - I want to have the base OS fully configured before deploying the charms [12:12] jamespage: as in you add-machine, then go fiddle with it, then deploy onto them? [12:12] jam: yes [12:12] jam: when we implemented the multi-network support we specifically don't try to configure anuy network devices in the charms [12:13] jam: that is not the resposibility of the charm [12:13] jam: so I'm using this approach to fill the gap until juju does this for us [12:14] jam: when "--networks" is actually fully implemented :-~) === lazyPower|Travel is now known as lazyPower [13:00] wallyworld: ping? [13:00] yo [13:00] wallyworld: can you please take a quick look at https://github.com/juju/names/pull/38? [13:00] sure [13:00] I forgot to get that landed first... [13:01] ah yeah i should have mentioned it [13:02] LGTM [13:03] cheers [13:28] axw: wallyworld: and again... https://github.com/wallyworld/juju/pull/14 [13:29] looking [13:51] axw: i have something working except for one bit; ping me when you're free [13:52] wallyworld: sure, just reviewing anastasiamac's branch atm [13:52] yep, np [14:08] wallyworld: done [14:09] axw: so, the remaining part is to write the block devices back to machine in state after the loop devices are created [14:09] https://github.com/wallyworld/juju/compare/wallyworld:storage-feature...provision-loop-devices [14:09] the existing apis don't seem suitable [14:09] looking [14:10] all works nicely though [14:10] wallyworld: I think provider type should just be part of VolumeParams [14:11] yeah, didn't i do that? [14:11] i did [14:11] wallyworld: you've got it next to it in ProvisioningInfo [14:12] bah, old code, [14:12] possibly before you made the change to VolumeParams [14:12] :) [14:14] axw, wallyworld what time is it for you guys?? [14:15] 00:15 for me :-) [14:15] alexisb: early, only 22:15 here [14:16] crazy [14:17] alexisb: storage is a beast [14:17] yes but I have to say it is very exciting to see the work land :) [14:18] * perrito666 knows wallyworld had other adjectives in mind [14:18] wallyworld: I think you should just create a new "provisioner" API method that calls state.setProvisionedBlockDeviceInfo [14:18] wallyworld: it's all in the wrong place, but that's the least amount of work [14:18] axw: yeah, that was what i was afraid would be needed, thanks for verifying [14:19] works great apart from that last bit [14:19] axw: i may look to merge what i have so katco can use it [14:20] cool [14:28] ericsnow: can you change the sharing settings on your plugin provider doc to "can comment"? Possibly even "can edit" if you trust us not to muck it up [14:31] wwitzel3: mind if we move our 1:1? I need to go snowblow 30" of snow off my driveway [14:32] natefinch: how many snow related activities do you have :p [14:32] axw: should be good to go https://github.com/wallyworld/juju/pull/15 [14:33] perrito666: I don't often rake the roof, but I always have to snowblow (if there's more than a couple inches of snow). [14:33] wallyworld: looking [14:33] natefinch: only 30"? ;) [14:34] wwitzel3: it's a guess based on the 28" we had yesterday noontime.... I'll definitely remeasure and get an accurate total. It was a record breaking storm for much of Massachusetts. [14:35] axw: wallyworld: m eod.. would it b awesome to see PR#14 land :D [14:35] natefinch: yeah, had some friends posting pictures of some 60-70" drifts [14:35]