| menn0 | thumper: bogdan is going to continue with it tomorrow but he's done for today | 00:00 |
|---|---|---|
| thumper | :-( | 00:00 |
| menn0 | only machine 0 seems to upgrade and then others don't | 00:00 |
| menn0 | i'll get some reviews out of the way and then i'll take a look through the logs | 00:01 |
| menn0 | thumper, wallyworld: i've been chatting to bogdanteleaga | 00:06 |
| bogdanteleaga | so the issue with the upgrade thing | 00:06 |
| menn0 | the CI test isn't going to work because it's upgrading from 1.24.2 | 00:07 |
| menn0 | and the 1.24.2 agent won't restart for the upgrade on windows | 00:07 |
| bogdanteleaga | pretty much | 00:07 |
| bogdanteleaga | the starting agent needs to have the fix | 00:07 |
| menn0 | bogdanteleaga: and they're the fixes you have in the PR that's up already? | 00:08 |
| bogdanteleaga | yep | 00:08 |
| thumper | is there a workaround for users that have an older windows version? | 00:09 |
| bogdanteleaga | I guess we either merge that and wait for it to be released, or make a different job | 00:09 |
| thumper | how do they upgrade? | 00:09 |
| bogdanteleaga | they have to manually restart the service I'm afraid | 00:09 |
| bogdanteleaga | the upgrade itself works | 00:09 |
| thumper | so if they just restart the service, it works, but not if they don't? | 00:10 |
| thumper | is this a regression from previous windows versions, or new? | 00:10 |
| bogdanteleaga | it doesn't know to start back up by itself | 00:10 |
| bogdanteleaga | it might be a regression since the new service package was introduced | 00:10 |
| thumper | hmm | 00:11 |
| bogdanteleaga | not completely sure what we did before | 00:11 |
| thumper | when was it introduced? | 00:11 |
| bogdanteleaga | let me check | 00:11 |
| thumper | also, which was the first juju version where we supported windows? | 00:11 |
| thumper | do those versions upgrade to the released versions? | 00:11 |
| thumper | that's a key question | 00:11 |
| wallyworld | thumper: menn0: bogdanteleaga: if we need to documemtn a one off manual work around to get past this issue, i think that's ok | 00:12 |
| bogdanteleaga | afaik the first one was 1.21 | 00:12 |
| bogdanteleaga | 1.23 has the old implementation | 00:13 |
| bogdanteleaga | I'd have to try it out to see if it works though | 00:14 |
| bogdanteleaga | the powershell code does not look promising | 00:14 |
| bogdanteleaga | (to create the services) | 00:14 |
| menn0 | bogdanteleaga: is manually testing an upgrade from 1.24 with the proposed fixes to master | 00:24 |
| menn0 | thumper: ^^^ | 00:24 |
| menn0 | if that works he's going to merge that into 1.24 so that at least 1.24.3 won't have this problme | 00:25 |
| menn0 | we won't have CI success until 1.24.3 is released | 00:25 |
| thumper | ack | 00:25 |
| menn0 | wallyworld: recap since you were disconnected: bogdanteleaga is manually testing an upgrade from 1.24 with the proposed fixes. if that works he's going to merge that into 1.24 so that at least 1.24.3 won't have this problem. we won't have CI success until 1.24.3 is released | 00:26 |
| wallyworld | ok ty | 00:27 |
| wallyworld | and for older deploys, we restart service manually | 00:27 |
| bogdanteleaga | all good | 00:34 |
| bogdanteleaga | I'll merge it in | 00:34 |
| wallyworld | waigani: hey, did you see my ping before about the maas failed deployment bug? | 00:36 |
| waigani | wallyworld: no sorry | 00:36 |
| waigani | wallyworld: do you have a link? | 00:36 |
| wallyworld | waigani_: can you take a look at 1.24 bug 1472711? it claims bug 1376246 may not quite be fixed | 00:36 |
| mup | Bug #1472711: MAAS node has "failed deployment", juju just says "pending" <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711> | 00:36 |
| mup | Bug #1376246: MAAS provider doesn't know about "Failed deployment" instance status <landscape> <maas-provider> <juju-core:Fix Released by waigani> <juju-core 1.24:Fix Released by waigani> <https://launchpad.net/bugs/1376246> | 00:36 |
| waigani | wallyworld: sure | 00:36 |
| wallyworld | tyvm | 00:36 |
| rick_h_ | thumper: howdy? | 02:13 |
| thumper | rick_h_: I'm not around tomorrow | 02:13 |
| rick_h_ | thumper: k | 02:13 |
| thumper | rick_h_: just letting you know as we normally have a call | 02:13 |
| rick_h_ | thumper: anything I should know? | 02:13 |
| thumper | only that we have slow progress, but expect it in 1.25 | 02:14 |
| thumper | 1.25 feature freeze pushed out so we can hit it | 02:14 |
| rick_h_ | thumper: ok, did that stuff help with the jes/system/environment destroy stuff? | 02:16 |
| thumper | rick_h_: yeah, rehashing now | 02:17 |
| thumper | although I have a few questions | 02:17 |
| thumper | got 5 minutes now? | 02:17 |
| thumper | for a hangotu? | 02:17 |
| rick_h_ | sure thing, just have to watch me eat dinner :) /me grabs headphones | 02:17 |
| thumper | kk | 02:17 |
| thumper | rick_h_: https://plus.google.com/hangouts/_/canonical.com/rick | 02:18 |
| bdx | hey whats going on everyone? | 02:45 |
| bdx | I'm looking for a way to seed a custom cloud-config to my juju deployed machines...I can use maas post install scripts for machines managed by maas, but I need my custom cloud-config to run on containers too. Is there a "best practice" way to do this with juju?? | 02:47 |
| bdx | from what I can tell juju creates the cloud init for lxc services here: https://github.com/juju/juju/blob/master/cloudconfig/containerinit/container_userdata.go | 02:49 |
| bdx | amongst other places | 02:49 |
| bdx | I'm thinking there has to be a way to pass a cloud-config file as an extra parameter when deploying services ....possibly I'm just missing somethig.... | 02:50 |
| bdx | charmers:^^ | 02:51 |
| marcoceppi | bdx: this is definitely a question for core, most charmers don't have this type of requirement | 02:52 |
| marcoceppi | bdx: may I ask what you're trying to customize? | 02:52 |
| bdx | marcoceppi: ok, thanks. -- I'm trying to automate my puppet cloud-config getting onto containers deployed by juju | 02:54 |
| marcoceppi | bdx: why wouldn't you just have that wrapped in a charm? | 02:54 |
| bdx | oooh ....like a secondary charm that I would deploy that was just puppet cloud-config? | 02:55 |
| marcoceppi | bdx: sure, you could have it be a subordinate for example | 02:56 |
| bdx | marcoceppi: Oooh totally...thats a great idea! | 02:56 |
| marcoceppi | bdx: I'd have to know more about what this puppet stuff was doing and the goal, but charming is really the best way to interact with the machines juju gives you after deployment | 02:57 |
| bdx | marcoceppi: totally....we have keys and users amongst other things that need to get onto each machine post deploy ... our infra is tightly tied in with a few puppet classes that are mandatory...plusss our newrelic and papertrial stuff ... | 02:59 |
| marcoceppi | bdx: ah, yeah, so I would totally make a "my-management-stuff" subordinate that you just throw on everything. We also have papertrail and new-relic charms, but if those area already puppetized, just have that subordinate do all that for you | 03:00 |
| bdx | marcoceppi: awesome. Do you know any hot docs for creating subordinate charms? | 03:02 |
| marcoceppi | bdx: it's just like a normal charm, except you set subordinate: true in the metadata.yaml and you need a relation in the new subordinate charm | 03:02 |
| marcoceppi | bdx: let me get you a link to the docs | 03:02 |
| marcoceppi | bdx: https://jujucharms.com/docs/stable/authors-subordinate-services and https://jujucharms.com/docs/stable/authors-implicit-relations | 03:03 |
| marcoceppi | bdx: here's an example metadata.yaml since those pages are...confusing | 03:03 |
| bdx | marcoceppi: I have been scoping this too | 03:03 |
| bdx | http://spamaps.org/files/charm-store-policy/drafts/subordinate-internals.html | 03:03 |
| bdx | marcoceppi: nice! thanks! | 03:04 |
| bdx | marcoceppi: thats awesome...that will be a perfect solution for what I'm trying to do here | 03:05 |
| marcoceppi | bdx: http://paste.ubuntu.com/11845656/ | 03:05 |
| marcoceppi | that's all you need to make a subordinate charm, the rest is the same as a primary charm structure | 03:06 |
| marcoceppi | lines 8 and 10-12 are the special bits | 03:06 |
| bdx | thats so simple | 03:06 |
| bdx | beautiful | 03:06 |
| marcoceppi | bdx: so, as you deploy services, just do a juju add-relation <service> <your-subordinate> and it'll attach to all units in that service, even as you scale out/in | 03:07 |
| bdx | marcoceppi: nice...even if the service exists on a container already? | 03:07 |
| marcoceppi | bdx: regardless of the system the service is on | 03:08 |
| marcoceppi | bdx: if it's deployed by juju, on metal, a VM, or a container | 03:08 |
| bdx | sick | 03:08 |
| bdx | sweet | 03:08 |
| bdx | thats perfect....I'm going to implement it now....I'll let you know how it goes | 03:09 |
| marcoceppi | bdx: awesome, I should be around for a few more hours if you have any questions | 03:09 |
| bdx | marcoceppi: awesome. thanks again for the advice | 03:09 |
| menn0 | wallyworld, thumper: so 1.24 is still blocked and we won't know for sure whether that bug is fixed until 1.24.3 is released and the CI test starts using that | 03:10 |
| menn0 | wallyworld, thumper: should we removed the blocker tag? | 03:11 |
| wallyworld | menn0: what bug is it blokec on? | 03:26 |
| menn0 | wallyworld: the windows upgrade one | 03:27 |
| menn0 | bug 1471332 | 03:27 |
| mup | Bug #1471332: Upgrade fails on windows machines <blocker> <ci> <upgrade-juju> <windows> <juju-core:In Progress by bteleaga> <juju-core 1.24:In Progress by bteleaga> <https://launchpad.net/bugs/1471332> | 03:27 |
| wallyworld | ah, i didn't realise that one was a blocker | 03:27 |
| wallyworld | i think based on your explanation above we could remove the blocker tag | 03:28 |
| menn0 | wallyworld: cool. i'll do that and add some detail to the bug | 03:28 |
| wallyworld | ty | 03:28 |
| menn0 | thumper: one line review please: http://reviews.vapour.ws/r/2124/ | 03:31 |
| * thumper looks | 03:33 | |
| thumper | menn0: shipit | 03:34 |
| menn0 | 1.24 is now unblocked | 03:34 |
| wallyworld | waigani: did you get a chance to look at bug 1472711 ? is it something that juju core needs to fix? | 04:38 |
| mup | Bug #1472711: MAAS node has "failed deployment", juju just says "pending" <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711> | 04:38 |
| wallyworld | menn0: we can mark bug 1469199 as fix committed right? | 04:40 |
| mup | Bug #1469199: State server seems to have died <cloud-install-failure> <cloud-installer> <landscape> <juju-core:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1469199> | 04:40 |
| wallyworld | on 1.24? | 04:41 |
| menn0 | wallyworld: not sure | 04:45 |
| menn0 | wallyworld: we've committed 2 possible fixes | 04:45 |
| menn0 | wallyworld: but they might not be it | 04:45 |
| menn0 | wallyworld: I can't repro it reliably | 04:45 |
| wallyworld | is a stakeholder going to test? | 04:45 |
| menn0 | wallyworld: so I don't know the problem is fixed | 04:45 |
| wallyworld | we could mark as fix committed so 1.24.3 can go out | 04:46 |
| menn0 | wallyworld: seems the issue hasn't happened for a while | 04:46 |
| menn0 | wallyworld: yeah, mark it as fix committed. the stakeholder said they would report back if the issue happens again (with 1.24.3 or otherwise) | 04:46 |
| wallyworld | ok, ty | 04:46 |
| wallyworld | master too? | 04:46 |
| menn0 | wallyworld: we can always reopen it and it's not like we can do anything more | 04:47 |
| wallyworld | yep | 04:47 |
| menn0 | wallyworld: yep master too | 04:47 |
| wallyworld | ok | 04:47 |
| menn0 | wallyworld: I just marked bug 1465115 as fix committed too. that just merged. | 04:49 |
| mup | Bug #1465115: api: data race in test <intermittent-failure> <race-condition> <unit-tests> <juju-core:Fix Committed by dave-cheney> <juju-core 1.24:Fix Committed by menno.smits> <https://launchpad.net/bugs/1465115> | 04:49 |
| waigani | wallyworld: it's next on my list. I'll just finish this and look at it now. | 04:50 |
| wallyworld | ty | 04:53 |
| wallyworld | waigani: add any comments to the bug so we can see what's happening at the release standup tomorrow | 04:53 |
| waigani | wallyworld: okay, will do. | 04:54 |
| wallyworld | thanks menn0 | 04:54 |
| * wallyworld relocating, afk for a bit | 04:54 | |
| === thumper is now known as thumper-afk | ||
| fwereade | axw, wallyworld: don't suppose either of you had a chance to look into the add-machine issue I mailed you about? | 08:17 |
| === anthonyf is now known as Guest97002 | ||
| mgz | bogdanteleaga: thanks for landing the upgrade changes | 10:18 |
| mgz | bogdanteleaga: do I understand from menno's comment that we can never automatically upgrade from any existing juju versions with windows units? | 10:19 |
| voidspace | mgz: I created a PR that I was expecting to get reviewed, it seems to have landed! Presumably without a test run (although tests pass of course...) | 10:46 |
| voidspace | mgz: https://github.com/juju/juju/pull/2750 | 10:46 |
| voidspace | mgz: can you see what I did wrong? Presumably I pressed the wrong button somewhere... | 10:46 |
| mgz | >_< | 10:47 |
| voidspace | mgz: hmm... I don't think I did, I think a test run was completed for a different PR and this one was merged | 10:48 |
| voidspace | mgz: I had a PR for this branch which I added the magic $$merge$$ cookie - that PR has vanished | 10:49 |
| voidspace | mgz: https://github.com/voidspace/juju/tree/devices-master-merge-4 | 10:49 |
| mgz | well, that was a fun mystery | 10:56 |
| voidspace | mgz: hah, oops... :-) | 10:56 |
| bogdanteleaga | mgz: not with whatever is released now | 11:00 |
| bogdanteleaga | mgz: I'll ask somebody to try 1.23 later today, but I'm not having high hopes | 11:02 |
| bogdanteleaga | mgz: 1.24.x won't work until 1.24.3 | 11:02 |
| mgz | bogdanteleaga: CI happened to do a 1.22.7 run - that also failed | 11:03 |
| mgz | so, I guess upgrades just won't work for existing windows envs | 11:04 |
| mgz | bogdanteleaga: I think we need to document some manual steps | 11:04 |
| mgz | even if the sanest thing really is to tear down the existing env and start again | 11:04 |
| bogdanteleaga | mgz: yeah, then it's almost certain to fail on 1.23 as well | 11:04 |
| mgz | bogdanteleaga: I've changed the CI job to try to upgrade from your fixed 1.24 - so we'll see if the job passes like that | 11:05 |
| bogdanteleaga | mgz: for 1.24 it can be as easy as accessing the machine and restarting the service | 11:05 |
| bogdanteleaga | might be the same for the rest, but it needs to be tested | 11:05 |
| mgz | if I can run that over winrm, that's also possible to script | 11:06 |
| bogdanteleaga | I don't see why not | 11:06 |
| mgz | though I guess it needs to see the upgrade first, then do the restart | 11:07 |
| bogdanteleaga | mgz: you can probably just query the service | 11:18 |
| bogdanteleaga | mgz: and when it stops just start is back up | 11:18 |
| bogdanteleaga | mgz: but you need to do the same for the units, which will stop after you upgraded the machine agent | 11:18 |
| === liam_ is now known as Guest88779 | ||
| frankban | ericsnow or axw: could you please take a look at https://github.com/juju/names/pull/52 ? thanks! | 13:32 |
| mup | Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069> | 13:39 |
| mup | Bug #1473069 changed: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069> | 13:48 |
| mup | Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069> | 13:51 |
| === kadams54 is now known as kadams54-away | ||
| marcoceppi | hey | 14:32 |
| marcoceppi | quick help | 14:32 |
| marcoceppi | what's the command to get the list of help for commands you run in hook env | 14:32 |
| marcoceppi | on a call | 14:32 |
| marcoceppi | in a pinch | 14:32 |
| marcoceppi | juju help-tool | 14:35 |
| * marcoceppi high fives | 14:35 | |
| marcoceppi | himself | 14:36 |
| rick_h_ | go marcoceppi go | 14:36 |
| mgz | marcoceppi: also `juju run --unit some-unit/0 "close-port --help"` works | 14:38 |
| mgz | for help on specific tools | 14:38 |
| === kadams54 is now known as kadams54-away | ||
| makyo_ | sinzui, ping | 17:38 |
| === makyo_ is now known as Makyo | ||
| === Makyo is now known as makyo_ | ||
| sinzui | hi makyo_ | 17:40 |
| makyo_ | sinzui, working on setting up some nightly testing with Jenkins and am trying to get it to send emails to us for build status. Does QA have any experience with that? | 17:41 |
| sinzui | makyo_: no, we abandoned Jenkins sending emails. our emails are sent by a script that inerprets the results | 17:44 |
| makyo_ | sinzui, Ah, alright. None of the solutions I found in Jenkins land were all that good, yeah. Is that up on LP/GH somewhere? | 17:45 |
| sinzui | makyo_: I can suggest that is builds are trigger other builds, or something watching the builds an trigger a "results" job, you can collect everything for an email and you have a choice of trying to use jenkins' infrastructure or adding your own | 17:46 |
| sinzui | makyo_: lp:ci-director does some of the emails | 17:46 |
| makyo_ | sinzui, alright, thanks. Will give it a look. | 17:47 |
| makyo_ | That sounds good. | 17:47 |
| katco | ericsnow: o/ | 17:51 |
| ericsnow | katco: \o | 17:51 |
| katco | ericsnow: how's the bug-fix coming? | 17:52 |
| katco | ericsnow: sorry i haven't been around | 17:52 |
| ericsnow | katco: np | 17:52 |
| ericsnow | katco: good | 17:52 |
| ericsnow | katco: wish we had sorted all this out thursday/friday :( | 17:52 |
| katco | ericsnow: yeah =/ | 17:52 |
| sinzui | makyo_: for any job, you can check email-notification. It includes the conole log. So a "results" job that summarises other jobs can do what you want cheeply. | 17:53 |
| katco | ericsnow: we've just been demoing basic stuff, it's ok | 17:53 |
| katco | ericsnow: but was wondering if we'd have anything ready for today? | 17:53 |
| * sinzui has set this up, but gets these emails from other jenkins | 17:53 | |
| ericsnow | katco: wwitzel3's working on it | 17:53 |
| katco | ericsnow: hm. last time i talked to him he said you were ;) maybe different bug? | 17:55 |
| ericsnow | katco: I'm pretty sure I fixed everything I could yesterday | 17:56 |
| makyo_ | sinzui, alright, that makes sense yeah | 17:56 |
| ericsnow | katco: I've been helping wwitzel3 as much as I can this morning | 17:56 |
| === kadams54 is now known as kadams54-away | ||
| === makyo_ is now known as Makyo | ||
| mup | Bug #1473197 opened: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197> | 20:06 |
| mup | Bug #1473197 changed: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197> | 20:21 |
| mup | Bug #1473197 opened: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197> | 20:24 |
| mup | Bug #1473209 opened: github.com/juju/juju/service/windows undefined: newConn <ci> <intermittent-failure> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <juju-core trunk:Triaged> <https://launchpad.net/bugs/1473209> | 20:54 |
| alexisb | wallyworld, ping me whn you are in please | 20:57 |
| wallyworld | alexisb: hi, just about to go into meeting, i'll try and get you before release standup | 20:59 |
| wallyworld | alexisb: free now | 21:10 |
| alexisb | lets jump on our hangout | 21:10 |
| sinzui | wallyworld: do you have time to review http://reviews.vapour.ws/r/2135/ | 21:31 |
| wallyworld | sinzui: yes, will do | 21:31 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | sinzui: lgtm | 21:55 |
| sinzui | thank you wallyworld. this is an example armhf build log the trusty 1.20.11 has the same deps and looks similar https://launchpadlibrarian.net/210434988/buildlog_ubuntu-trusty-armhf.juju-core_1.24.2-0ubuntu1~14.04.1~juju1_BUILDING.txt.gz | 22:01 |
| wallyworld | ty, looking | 22:02 |
| wallyworld | anastasiamac: standup? | 23:17 |
| anastasiamac | wallyworld: technical issues.. omw | 23:17 |
| marcoceppi | bdx: were you able to get the subordinate working? | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!