| waigani | thumper: yeah I don't know why. I'm on next Wed I should be on. | 00:07 |
|---|---|---|
| === marcoceppi_ is now known as marcoceppi | ||
| wallyworld | axw: it was a nightmare yesterday merging master into cloud-crdentials. tl;dr; living the dream, if you notice any glitches, sorry, we can fix as drive by | 00:15 |
| axw | wallyworld: ok | 00:16 |
| axw | wallyworld: forgot about leads meeting this morning, was waiting for standup. yesterday I got add-user/register working. need to rework some of it to production quality tho | 00:17 |
| wallyworld | axw: \o/ that is most awesome | 00:17 |
| perrito666 | wallyworld: fyi it was a nightmare tonight to :p | 00:21 |
| wallyworld | :-( | 00:21 |
| * perrito666 is still fixing artifacts | 00:21 | |
| * wallyworld stabs git in the heart | 00:21 | |
| perrito666 | anyone remembers the key that lets you navigate github like a shell prompt? | 00:23 |
| perrito666 | wallyworld: does cmd/juju/model/jenv_test.go run for you? | 00:43 |
| wallyworld | perrito666: yup | 00:44 |
| perrito666 | ok, I think I finally merged | 00:59 |
| * perrito666 reruns the whole suite | 00:59 | |
| axw | thumper: kabaddi is .. interesting :) | 01:07 |
| axw | looks like there's lots of variations, I have nfi what the one I just watched is | 01:07 |
| wallyworld | thumper: yo | 01:34 |
| wallyworld | axw: anastasiamac: can you guys spare 15 minutes for a chat? | 02:12 |
| axw | wallyworld: yep, standup? | 02:12 |
| wallyworld | ok | 02:12 |
| thumper | wallyworld: ya? | 02:18 |
| wallyworld | thumper: never mind, figured it out :-) | 02:19 |
| axw | wallyworld: re base64-encoding username, controller host etc. I have a concern about that. you don't necessarily know which address another user should use. we could encode them all... I'm concerned that'll blow out the line length tho. I'll try it and see. | 02:55 |
| wallyworld | ok, we can look to adjust how it may work if needed | 02:56 |
| natefinch | huh, I thought our errors.IsNotFound also checked for os.IsNotExist .... it's too bad it doesn't. so now I have to pick one :/ | 03:03 |
| * natefinch rages against the fact that errors.NotValidf appends "not valid" to my carefully crafted error string | 03:39 | |
| menn0 | perrito666: better late than never, the Github key you're after is "t" (and "?" pops up some help) | 03:54 |
| menn0 | thumper: hmmm... the apiserver/controller.Controller interface doesn't appear to get used anywhere | 03:59 |
| thumper | ? | 04:06 |
| thumper | menn0: I think it was there purely as a contract of the API facade | 04:07 |
| thumper | more for documentation purposes than real use | 04:07 |
| menn0 | thumper: do we want to keep it? | 04:07 |
| thumper | I kinda like it, but not attached to it | 04:07 |
| === meetingology` is now known as meetingology | ||
| natefinch | A Tag tags things that are taggable. | 04:19 |
| wallyworld | axw: damn, i forgot to replace state servers with controllers; user visible artifacts are affected, i've had to do a pr for alpha2. it also deletes format 1.16 agent conf support, but apart from that it's purely mechanical http://reviews.vapour.ws/r/3731 | 04:51 |
| axw | wallyworld: ok | 04:51 |
| wallyworld | sorry | 04:51 |
| axw | wallyworld: LGTM with one possible change | 05:04 |
| wallyworld | awesome, ty | 05:04 |
| wallyworld | axw: i'd rather change to "is-controller" and worry about upgrades later. ie get everuthing correct now for 2.0 | 05:05 |
| wallyworld | since we can't upgrade anyway | 05:05 |
| davecheney | soooo | 05:10 |
| davecheney | trusty cloud images are broken on ap-southeast-2 | 05:10 |
| davecheney | looks like launching the current 14.04 image on t2.medium results in an instance that does not know it's own ip address | 05:14 |
| axw | wallyworld: do you want me to do the add-user/register bits on cloud-credentials, or just on master? | 06:20 |
| axw | wallyworld: because there's nothing really specific to cloud-credentials to it | 06:20 |
| wallyworld | axw: don't commit to master right now as it's frozen for alpha2. Bets to stick to out featuure beanch for now i think | 06:21 |
| axw | wallyworld: ok | 06:21 |
| axw | wallyworld: I have updated the doc just to have --config with two syntaxes. I think we should just implement that, and ask for stakeholder feedback | 07:52 |
| axw | wallyworld: the original proposals are preserved in the alternatives section | 07:52 |
| wallyworld | axw: sgtm, but i really hope they whinge about having to type --config each time | 07:53 |
| * wallyworld off to soccer, bbiab | 07:53 | |
| axw | wallyworld: :) | 07:53 |
| axw | later | 07:53 |
| anastasiamac | wallyworld: i hope that "iab" is at least 90min of play time!! | 07:54 |
| wallyworld | anastasiamac: it's training for the team i coach, so 90 minutes of me tell them what to do :-) | 07:54 |
| anastasiamac | oh, like work then | 07:55 |
| wallyworld | lol | 07:55 |
| anastasiamac | :P | 07:55 |
| voidspace | dimitern: frobware: we haven't had a CI run on maas-spaces since Monday | 09:25 |
| frobware | voidspace, yep, the focus has been on the other branch | 09:25 |
| voidspace | dimitern: frobware: today we got another on maas-spaces-controller-space-config though, is that expected? | 09:25 |
| frobware | voidspace, yes, and it looks way better. | 09:26 |
| voidspace | yep | 09:26 |
| voidspace | "cannot update controller space in config: cannot set controller-space to "Default space": not a valid space name" | 09:27 |
| voidspace | we need space name translation for the controller space | 09:27 |
| dimitern | voidspace, yeah, it's expected - I wanted to make sure it wasn't badly broken somehow | 09:31 |
| dimitern | voidspace, that's due to the CI job using pre 1.9.0 MAAS (beta3 or 4 I guess) | 09:32 |
| voidspace | dimitern: heh, right | 09:32 |
| voidspace | dimitern: shouldn't we handle it though? | 09:32 |
| dimitern | voidspace, that depends on whether there is a way to handle space names with spaces | 09:32 |
| dimitern | voidspace, if acquire node fails when you pass interfaces=0:space=Default space .. | 09:33 |
| dimitern | voidspace, I'll do some experiments with that | 09:33 |
| frobware | dimitern, I see a bootstrap error today. "failed to bootstrap model: cannot infer controller space name to use: PXE interface "eth0" (52:54:00:c6:17:82) has no links" | 09:35 |
| dimitern | frobware, interesting - and the node managed to boot ? | 09:35 |
| frobware | dimitern, yep | 09:36 |
| dimitern | frobware, what did the UI show for the node's interfaces? | 09:36 |
| frobware | dimitern, but I was staring at my screen thinking... uh-oh and I noticed the console window finish the bridging. | 09:36 |
| frobware | dimitern, I didn't think that stage was that async. | 09:36 |
| dimitern | frobware, the async aspect is systemd related I believe | 09:37 |
| frobware | dimitern, one wonders whether the nonce should get wrriten after we've finished fiddling. | 09:38 |
| frobware | dimitern, actually, looking at the cloud-init output that seems to tbe the case already. | 09:39 |
| dimitern | frobware, yeah - since the bridge script runs first | 09:39 |
| dimitern | frobware, before the tools are downloaded or the nonce saved | 09:39 |
| frobware | dimitern, UI shows two bonds, and deployed. | 09:40 |
| frobware | dimitern, poor man's UI: http://pastebin.ubuntu.com/14876219/ | 09:43 |
| dimitern | frobware, well d'oh.. sorry, we should fix that | 09:45 |
| frobware | dimitern, what's the issue? | 09:46 |
| dimitern | frobware, since there's a bond, we should not just pick the first physical nic with the pxc mac, but also cater for bonds | 09:46 |
| frobware | dimitern, I guess yesterday I was not using this node. :( | 09:47 |
| dimitern | frobware, that's a good catch sir :) | 09:48 |
| frobware | dimitern, I happened to release all my nodes; that was previously my 1.25 vlan/bond testing node. | 09:48 |
| dimitern | frobware, so the logic around pxe nic detection should include: mac=pxe_mac, type=physical && len(children) == 0 || type=bond && len(parents) > 0, and having a link to subnet | 09:50 |
| frobware | dimitern, I can take a look now | 09:50 |
| voidspace | frobware: do you have the company VPN setup? | 09:51 |
| dimitern | frobware, and there's the odd chance of picking a disabled nic (although we should see if this works in practice - disabled pxe interface) | 09:51 |
| frobware | voidspace, yes | 09:51 |
| voidspace | frobware: I followed the instructions here and it doesn't work, I get "VPN connection failed" | 09:52 |
| voidspace | frobware: https://wiki.canonical.com/InformationInfrastructure/IS/HowTo/CompanyOpenVPN | 09:52 |
| voidspace | frobware: did you set it up through Network Manager as described there? | 09:52 |
| frobware | voidspace, yep | 09:52 |
| frobware | voidspace, maybe a 15.10 issue | 09:52 |
| dimitern | voidspace, one of the failures was functional-jes, which failed ultimately with "spaces discovery still in progress" | 09:52 |
| voidspace | frobware: harrumph | 09:52 |
| voidspace | dimitern: hmmm, odd | 09:52 |
| dimitern | voidspace, so we should investigate how we're dealing with multiple models in play | 09:53 |
| voidspace | dimitern: will look | 09:53 |
| voidspace | dimitern: oh god | 09:53 |
| voidspace | dimitern: I have no idea :-) | 09:53 |
| voidspace | dimitern: I will look into it | 09:53 |
| dimitern | voidspace, e.g. bootstrap went fine, then discovery was skipped as expected, followed by create-model, which exposed discovery blocking | 09:53 |
| voidspace | dimitern: frobware: this tests the fix from yesterday - it passes with the new code and fails with the old code | 09:54 |
| dimitern | voidspace, great! | 09:54 |
| voidspace | dimitern: why was discovery skipped? | 09:54 |
| dimitern | voidspace, the job runs on joyent | 09:54 |
| voidspace | dimitern: ok | 09:54 |
| voidspace | dimitern: so it should only be possible for login to be blocked if space discovery has started | 09:54 |
| voidspace | dimitern: I'll check all code paths to see if that's really true | 09:55 |
| voidspace | dimitern: is this with yesterdays fix in? | 09:55 |
| frobware | voidspace, has to be yes -- we had so many "success" results today. | 09:55 |
| voidspace | *grr* | 09:56 |
| voidspace | frobware: thanks | 09:56 |
| dimitern | voidspace, yes - have a look at http://reports.vapour.ws/releases/3569/job/functional-jes/attempt/620 - around 03:44:30 | 09:56 |
| voidspace | dimitern: yeah, looking | 09:56 |
| voidspace | dimitern: I see two code paths that don't close the channel (and need fixing) | 09:56 |
| voidspace | dimitern: an error calling api.ModelConfig and calling envrions.New | 09:57 |
| voidspace | dimitern: but I doubt they're the cause of the problem | 09:57 |
| voidspace | dimitern: I'll fix those in the current branch anyway | 09:58 |
| dimitern | voidspace, I think that's exactly what it is, considering the error right after that is 'model "functional-jes-env2" not found' | 09:58 |
| voidspace | dimitern: that'll be it then... | 09:58 |
| dimitern | voidspace, but all code paths need to be tested, yeah | 09:59 |
| dimitern | frobware, voidspace, dooferlad, are we doing the weekly call? | 10:02 |
| frobware | dimitern, I'm skipping. want to concentrate on the build/test/merge. | 10:02 |
| dimitern | frobware, ok, I think I'll do the same | 10:03 |
| voidspace | ok | 10:03 |
| dooferlad | dimitern, frobware, voidspace: I can go and report back. | 10:03 |
| frobware | dimitern, voidspace, dooferlad: I would like to get a CI build kicked off during our day if we have additional fixes today. | 10:03 |
| voidspace | I'll go as well | 10:03 |
| voidspace | frobware: yep | 10:03 |
| voidspace | dimitern: I've changed the channel close to be done in a defer (with a "maybeClose" function - so I don't have to play whack-a-mole with code paths | 10:04 |
| frobware | dooferlad, ack & thanks. | 10:05 |
| dimitern | voidspace, before calling anything that might fail, right? | 10:05 |
| voidspace | dimitern: yep | 10:05 |
| dimitern | voidspace, +1 | 10:05 |
| voidspace | dimitern: and as a "few" of the exits are tested, the defer is now tested | 10:05 |
| dimitern | voidspace, awesome | 10:06 |
| dimitern | voidspace, now, it might be worth jiggling the test around a bit | 10:06 |
| voidspace | dimitern: in terms of? | 10:07 |
| dimitern | voidspace, e.g. causing the dep engine to bounce the workers a few times before checking ultimately discoverspaces stops | 10:07 |
| dooferlad | dimitern, frobware, voidspace: is there any value in a quick standup? | 10:07 |
| dimitern | voidspace, it seems that when issues like that surface - e.g. the api caller dependency dies and pulls the other workers along | 10:08 |
| voidspace | dimitern: ok, interesting - is there an example test I can look at that does this? | 10:08 |
| voidspace | dimitern: otp | 10:08 |
| dimitern | voidspace, there should be - looking | 10:09 |
| dimitern | voidspace, have a look in worker/dependency/engine_test.go | 10:13 |
| voidspace | dimitern: ok | 10:15 |
| voidspace | dimitern: this should only be an issue for bootstrap - the bootstrap code is the only path that *checks* this channel | 10:15 |
| voidspace | dimitern: so bouncing the workers shouldn't block anything | 10:15 |
| voidspace | dimitern: maybe worth checking that discovery still completes if the worker is interrupted | 10:16 |
| dimitern | voidspace, isn't there a singular runner per model? | 10:16 |
| voidspace | dimitern: well, yes - but only one channel | 10:16 |
| voidspace | dimitern: interesting, I'll have to look at this code | 10:16 |
| dimitern | voidspace, then it can happen during/right after model creation, which is essentially the same as bootstrap | 10:16 |
| voidspace | dimitern: it's only limitLogins that is affected though, and that is only used during bootstrap itself I *believe* | 10:17 |
| voidspace | dimitern: that's where the channel is checked for closing | 10:17 |
| voidspace | dimitern: I'll look at that code and try and understand the ramifications of jes here | 10:17 |
| voidspace | (one channel per agent) | 10:18 |
| voidspace | dimitern: so it should only be discovery on the JES controller itself that blocks anything | 10:18 |
| voidspace | discovery for other models shouldn't block - that would be the intent anyway, and I think also the code | 10:19 |
| frobware | dooferlad, I would say yes, but I see a lot going on here. dimitern, voidspace: want a quick standup? | 10:19 |
| dimitern | frobware, dooferlad, voidspace, yeah, let's do it quickly | 10:19 |
| voidspace | frobware: dooferlad: dimitern: if we can actually be quick :-) | 10:19 |
| voidspace | omw | 10:20 |
| voidspace | frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/3735/ | 10:26 |
| voidspace | dooferlad: my network manager logs, showing the problem with openvpn (not very helpful) http://paste.ubuntu.com/14876407/ | 10:32 |
| voidspace | dooferlad: any ideas? | 10:32 |
| frobware | mgz, ping | 10:33 |
| voidspace | dooferlad: ah, now I get a missing file error for tls-auth | 10:37 |
| voidspace | dooferlad: dimitern: frobware: fixed the problem (file in wrong place) and now it works :-) | 10:37 |
| dooferlad | voidspace: sweet! | 10:38 |
| voidspace | dooferlad: dimitern: frobware: so should be able to test bootstrapping to openstack | 10:38 |
| voidspace | we'll see | 10:38 |
| frobware | voidspace, dimitern, dooferlad: we seem to dump a lot of hex output to the logs - is this necessary / useful? | 10:48 |
| dooferlad | frobware: example? | 10:48 |
| voidspace | frobware: no... | 10:48 |
| frobware | dooferlad, let me find an example in the CI reports | 10:48 |
| frobware | dooferlad, http://data.vapour.ws/juju-ci/products/version-3569/maas-1_9-deploy-trusty-amd64/build-1900/consoleText | 10:49 |
| dooferlad | frobware: looks useless | 10:50 |
| frobware | personally I think we should drop this | 10:50 |
| dimitern | frobware, that was the result of adding more logging | 10:53 |
| dimitern | frobware, and indeed it was temporary to debug the trusty issue if it happens, will drop it | 10:53 |
| frobware | dimitern, thanks | 10:56 |
| dimitern | voidspace, you've got a review | 11:02 |
| dimitern | voidspace, however, I've just discovered this: | 11:03 |
| dimitern | 210669b2-3a14-411c-847a-b5ec79f4803e machine-0: 2016-02-04 11:02:27 ERROR juju.worker runner.go:229 exited "discoverspaces": error from CreateSpaces: adding space "admin": ProviderId "admin" not unique | 11:03 |
| dimitern | voidspace, I bootstrapped, then created another model - it seems discover spaces runs there as well | 11:04 |
| dimitern | voidspace, we have to deal with this to allow multiple models to work with spaces, either by dropping the requirement for provider-id uniqueness, or alternatively always storing the providerID with model-uuid like for doc-id | 11:10 |
| dimitern | space names with spaces can be both created and used for selection of nodes, fortunately selection can use the ID just the same | 11:18 |
| jamespage | anyone know if there is a plan to have the juju cli be able to export a bundle? | 12:22 |
| jamespage | juju-deployerizer exists but that's a stop-gap IMHO | 12:22 |
| jamespage | (thankyou for that niedbalski :)) | 12:22 |
| perrito666 | morning all | 12:29 |
| voidspace | dimitern: space discovery should run for the new model, shouldn't it? | 12:29 |
| voidspace | dimitern: we knew we would have to face this (non-unique provider id | 12:30 |
| perrito666 | wallyworld: tx for the extra set of eyes on that XDG merge | 12:30 |
| perrito666 | I really needed that | 12:30 |
| voidspace | dimitern: do you want me to move the doc comment to the variable (in my PR)? | 12:31 |
| dimitern | voidspace, yes, I'm trying to fix this in my branch actually | 12:31 |
| dimitern | voidspace, yes please | 12:31 |
| voidspace | dimitern: provider id uniqueness? | 12:31 |
| dimitern | voidspace, uniqueness by prefixing with model uuid | 12:31 |
| dimitern | voidspace, experimenting with this now | 12:31 |
| voidspace | dimitern: cool | 12:32 |
| === ddellav_ is now known as ddellav | ||
| dooferlad | frobware/dimitern/frobware: our branch is missing https://github.com/juju/juju/commit/462a3d6e3c1a7a67085d6a092bafe0f0dd21b679 and that seems to be the problem the manual deploys are running into | 13:57 |
| dimitern | dooferlad, great! thanks for tracking this down | 14:08 |
| dimitern | dooferlad, can you propose a PR to merge this please? | 14:10 |
| dooferlad | dimitern: yea, I am just resolving all the conflicts caused by renames | 14:10 |
| dimitern | dooferlad, cheers | 14:12 |
| frobware | dooferlad, heh. so I had done an independent merge yesterday and this was one of my diffs against dimiter's version. | 14:38 |
| dooferlad | frobware/dimitern I am seeing lots of networker being deleted and environ/model renaming. Wasn't that already merged? | 14:40 |
| dooferlad | maybe this is a git suckage problem | 14:40 |
| dimitern | dooferlad, it's not merged in master | 14:41 |
| dooferlad | yes, but shouldn't we already have fixed this stuff? We should have already got the renames, right? | 14:41 |
| frobware | dooferlad, which branch are you looking at? maas-spaces or maas-spaces-controller-space-after-master-merge | 14:52 |
| dooferlad | frobware: maas-spaces | 14:52 |
| frobware | dimitern: the latest merge of master is all in maas-spaces-controller-space-after-master-merge, correct? | 15:00 |
| frobware | dooferlad, ^ | 15:00 |
| natefinch | ericsnow: standup? | 15:04 |
| dimitern | frobware, yeah, that's the one | 15:06 |
| frobware | dimitern, dooferlad: this is what I'm testing and making changes against. | 15:06 |
| dimitern | frobware, me too | 15:07 |
| dooferlad | dimitern, frobware: why does that branch still exist? Why not go back to maas-spaces? | 15:19 |
| frobware | dooferlad, dimitern: that's the plan, but it generally wasn't ready and we wanted to keep going with maas-spaces. we needed somewhere to work for both cases. | 15:20 |
| frobware | dooferlad, the plan _is_ to go back to maas-spaces. | 15:20 |
| dooferlad | frobware: so, should I propose a merge of master to maas-spaces-long-name-of-doom? | 15:21 |
| dooferlad | frobware: I just don't want to replicate more work :-| | 15:21 |
| frobware | dooferlad, I would say no... | 15:21 |
| frobware | dooferlad, can we cherry-pick the change you identified? | 15:22 |
| dooferlad | frobware: sure, but ISTR not much happened on master last night | 15:22 |
| frobware | dooferlad, the reason I say "no" to a merge is that we have 4 identified failures. I didn't want to perturb the current state too much. | 15:22 |
| dooferlad | frobware: maas-spaces-controller-space-config was tested last night. We were just talking about another branch. Which state are we trying not to perturb?! | 15:24 |
| frobware | dooferlad, I'm in favour of a cherry-pick, plus michael's changes for discovery and dimiter's "stuff" means we should get down to either 1 or 0 failures. | 15:24 |
| frobware | dooferlad, let's HO | 15:24 |
| dooferlad | frobware: sure | 15:24 |
| frobware | dooferlad, I'm done with typing. :) | 15:24 |
| frobware | dimitern, ping - can you join the sapphire HO? | 15:30 |
| dimitern | frobware, sure, omw | 15:33 |
| voidspace | dooferlad: ping | 16:08 |
| dooferlad | voidspace: pong | 16:14 |
| voidspace | dooferlad: that was a test ping | 16:14 |
| voidspace | dooferlad: thanks for the ack | 16:14 |
| dooferlad | voidspace: :-) | 16:14 |
| voidspace | dooferlad: I thought my connection had died and XChat was just being slow to catch up | 16:15 |
| voidspace | it does that sometimes. Long timeout on connection. | 16:15 |
| === akhavr1 is now known as akhavr | ||
| natefinch | Man I wish we had something other than params.Entity to use in the API.... especially for the 95% of the time when it has to be one specific type. | 16:35 |
| perrito666 | if you know what you are expecting just check it | 16:41 |
| alexisb | perrito666, on a call w/ curtis and team; can you please rebase your mongo3 branch on the current master? | 16:49 |
| alexisb | perrito666, cherylj and curtis are working to get a bless so we can merge | 16:50 |
| perrito666 | alexisb: I certainly can, you need that now? | 16:51 |
| alexisb | today please | 16:51 |
| perrito666 | k, on it | 16:52 |
| alexisb | thnaks | 16:52 |
| alexisb | perrito666, please ping cherylj once it has been merged | 16:53 |
| perrito666 | alexisb: you want me to just put mongo3 branch up to date with master ?or to merge back that into master too | 16:54 |
| alexisb | rebase off master | 16:55 |
| alexisb | so we can get a fresh ci run | 16:55 |
| perrito666 | ah ok, ill do it | 16:56 |
| perrito666 | then roll into a corner of the room and cry | 16:56 |
| natefinch | ericsnow: I keep thinking... we keep passing around the size of the resources... but why do we care? The fingerprint ensures we have the right data... size really only matters possibly if we ever want to display it to the user as part of the info about a resource. | 16:58 |
| ericsnow | natefinch: that and the blobstore sometimes only gives us the size (so we can't verify against the fingerprint) | 16:59 |
| natefinch | ericsnow: ahh, hmm... weakness of the blobstore. That's too bad | 17:00 |
| ericsnow | natefinch: yep, though it doesn't hurt to store the size (accessible via YAML and JSON output) | 17:00 |
| natefinch | ericsnow: yeah, totally is something we should store, just could be calculated on the server, instead of passing it up with requests. | 17:01 |
| ericsnow | natefinch: true | 17:03 |
| natefinch | ericsnow: what's the pendingID on UploadRequest for? I thought the point of the pending resources is that you *can't* generate an ID on the client side, because it won't be guaranteed to be unique on the server | 17:08 |
| ericsnow | natefinch: the ID is the one you get from the server by calling "AddPendingResources()" before trying to upload | 17:11 |
| cherylj | tych0: ping? | 17:11 |
| tych0 | cherylj: hi | 17:12 |
| natefinch | ericsnow: oh, so it's two steps - add the pending metadata and then upload the bytes for that metadata? | 17:12 |
| cherylj | hey tych0, I'm going to help you get your PRs into a feature branch, but need you to do a couple things for me first. | 17:12 |
| ericsnow | natefinch: yep | 17:12 |
| tych0 | sure, sounds good | 17:12 |
| cherylj | tych0: can you rebase off of master and create one PR that has both 4191 and 4131? | 17:12 |
| tych0 | cherylj: 4191 has both and has been rebased off of master yesterday, i can rebase again though | 17:13 |
| cherylj | tych0: ah, then that should be fine. Don't think that it's changed since then | 17:13 |
| tych0 | cherylj: just building the rebase now, i'll push when it builds successfully | 17:14 |
| cherylj | tych0: ok, thanks. I can make a feature branch off if 4191 and you can merge the change for 4131 into that branch | 17:14 |
| cherylj | then we'll get a CI test run on that branch before we merge it into master | 17:14 |
| tych0 | cherylj: 4191 has both already | 17:14 |
| tych0 | i was planning to rebase if 4131 ever got merged | 17:14 |
| cherylj | tych0: then maybe I didn't need you to do anything! :) | 17:15 |
| tych0 | cherylj: ok, 4191 should be rebased on master as of a minute ago | 17:15 |
| tych0 | cherylj: np :) | 17:15 |
| cherylj | kk, will get it in feature branch for testing. Thanks! | 17:15 |
| tych0 | cherylj: sure, let me know if you need anything else | 17:16 |
| tych0 | i'll be in and out today, but happy to fix stuff as needed | 17:16 |
| cherylj | thanks, tych0! | 17:16 |
| natefinch | I kind wish the we had client-side logging | 17:25 |
| natefinch | I mean, I guess we kinda do - but I wish we actually saved it somewhere. | 17:26 |
| === akhavr1 is now known as akhavr | ||
| cherylj | tych0: the feature branch is up! https://github.com/juju/juju/tree/lxd-container-type | 17:46 |
| cherylj | tych0: you should also add go fmt to your pre-push script | 17:52 |
| perrito666 | anyone could hint me what is the new name of StateServerInfo? | 18:03 |
| perrito666 | ill guess its ControllerInfo | 18:06 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| natefinch | ericsnow: why do we need ListModelResources? It looks like the only additional information it returns that ListResources doesn't, is the storage path... is that right? | 19:33 |
| ericsnow | natefinch: and PendingID | 19:33 |
| natefinch | ericsnow: but for ListModelResources PendingID is always empty | 19:34 |
| ericsnow | natefinch: yep | 19:34 |
| natefinch | ericsnow: so, it seems like a lot of mental overhead for just one additional value | 19:36 |
| perrito666 | bbl | 19:37 |
| === akhavr1 is now known as akhavr | ||
| natefinch | ericsnow: seems like we don't even really need ModelResource if we just add ServiceID to resource.Resource | 19:39 |
| natefinch | ericsnow: and storagepath I guess | 19:40 |
| ericsnow | natefinch: and PendingID | 19:40 |
| ericsnow | natefinch: perhaps I'm missing something, but is your concern that we have a type that contains multiple fields instead of returning each of those fields separately from the related methods? | 19:41 |
| natefinch | ericsnow: we never use pendingID outside the database | 19:41 |
| ericsnow | natefinch: and in state | 19:42 |
| natefinch | ericsnow: maybe it just needs a better name? | 19:42 |
| ericsnow | natefinch: fine with me :) | 19:43 |
| natefinch | ericsnow: it just seems like most of the data in ModelResource isn't really ever used. StoragePath seems to be there just to avoid having to calculate the storagepath each time. ServiceID could easily be on resource.Resource. PendingID is unique by definition, so shouldn't need any of the surrounding data most of the time. | 19:45 |
| ericsnow | natefinch: StoragePath is necessary because when a pending resource is made active in the AddService() transaction, we do not change the storage path (and it cannot be re-calculated because the pending ID is gone) | 19:48 |
| natefinch | ericsnow: that's fair. Still seems like something that could be on resource.Resource | 19:49 |
| ericsnow | natefinch: So you're suggesting that Resource and ModelResource be merged together? | 19:50 |
| ericsnow | natefinch: the catch is that resource.Resource is the more user-facing type and ModelResource includes info that isn't meant for users | 19:50 |
| natefinch | ericsnow: yeah.... it seems like there's very little benefit to having them in two types, and personally I find it confusing as to when I'd want one or the other, since they're so close | 19:50 |
| ericsnow | natefinch: (namely PendingID and StoragePath) | 19:52 |
| natefinch | ericsnow: right... though both those could, in theory, be useful if converted to something like a boolean for IsPending | 19:52 |
| ericsnow | natefinch: It has to be an ID since there can be more than one pending for a given resource ID | 19:53 |
| ericsnow | natefinch: trust me, I tried the boolean first :) | 19:53 |
| natefinch | ericsnow: right, I just meant, since we were talking user-facing (I'm thinking conversion like for tabular output) | 20:00 |
| ericsnow | natefinch: users should never see the pending ID except when it comes back from an AddPendingResource API call | 20:01 |
| natefinch | ericsnow: right, and I don't think they will. The API types don't need to expose it | 20:01 |
| natefinch | ericsnow: the API being the best definition of what is userfacing | 20:02 |
| === alexisb is now known as alexisb-afk | ||
| davecheney | thumper: yup, I had an environment come up that was not listening on port 17070 | 20:24 |
| thumper | davecheney: well that port can be configured right? | 20:25 |
| thumper | why is that an issue? | 20:25 |
| davecheney | manual3: | 20:26 |
| davecheney | type: manual | 20:26 |
| davecheney | bootstrap-host: ec2-54-79-138-39.ap-southeast-2.compute.amazonaws.com | 20:26 |
| davecheney | bootstrap-user: ubuntu | 20:26 |
| davecheney | this is my config | 20:26 |
| davecheney | if there is a default, it didn't default to what it should have defaulted to and/or the client tool did not respect the default | 20:26 |
| thumper | ok, that is weird | 20:27 |
| natefinch | ericsnow: can you explain modelID to me? (I know you're changing the name, but the concept presumably stays the same) | 20:39 |
| ericsnow | natefinch: its the identifier for the resource in the model, i.e. the resource ID | 20:40 |
| thumper | can we please not call it modelID? | 20:41 |
| natefinch | ericsnow: how is thast different than the doc ID (for non-pending resources) or the pendingID (for pending resources)? | 20:41 |
| natefinch | thumper: already been brought up and I think fixed | 20:41 |
| ericsnow | natefinch: FYI, I'm working up a patch that folds the ID and service ID into resource.Resource | 20:41 |
| natefinch | ericsnow: ok | 20:41 |
| ericsnow | natefinch: my aim is to eliminate resource.ModelResource | 20:42 |
| natefinch | ericsnow: awesome. I really think that will simplify the code a lot. It might be 5-10% imperfect, but I think it'll be a lot easier to work with and understand. | 20:43 |
| ericsnow | natefinch: thanks for bringing it up | 20:43 |
| davechen1y | thumper: this isn't a fw issue | 20:46 |
| davechen1y | the port is not open | 20:46 |
| davechen1y | i checked with `netstat -anp` and `ss | 20:46 |
| === alexisb-afk is now known as alexisb | ||
| tych0 | cherylj: ah, cool, thanks | 20:52 |
| tych0 | cherylj: what steps to do we do from here to get it merged? | 20:53 |
| cherylj | tych0: there should be a CI run happening now for your branch. If it gets a bless (or realistically, shows the same failures as master), we'll merge it for you | 20:53 |
| cherylj | tych0: otherwise, we'll need you to fix the failures | 20:53 |
| tych0 | cherylj: ok, cool. that sounds entirely reasonable :) | 20:54 |
| === akhavr1 is now known as akhavr | ||
| alexisb | tych0, I am going to set up some time to chat next week as well, so we can check point where we are for removing lxc | 21:01 |
| tych0 | alexisb: ok, sounds good. there's definitely some stuff to be finished still | 21:02 |
| alexisb | yep and I know jam has been doing some testing | 21:02 |
| perrito666 | its a good thing I decided to update my laptops ubuntu, I was tired of being able to boot without getting a video hang | 21:12 |
| natefinch | perrito666: lol | 21:17 |
| perrito666 | well, and xorg seems to be under the impression that its doing a great job | 21:19 |
| perrito666 | off cource, intel video driver cause a nil pointer dereference | 21:20 |
| natefinch | yay | 21:22 |
| natefinch | ericsnow: thanks for the clarification about what the resource ID means. | 21:23 |
| ericsnow | natefinch: np :) | 21:23 |
| natefinch | ericsnow: and I agree, it makes sense to canonicalize the ID in a real field, instead of it being implicitly servicename + resourcename | 21:24 |
| menn0 | natefinch: I just replied to some of your replies for http://reviews.vapour.ws/r/3699/ | 21:45 |
| alexisb | cherylj, tych0 looks like the lxd broker branch had a fun first test run ;) | 21:52 |
| cherylj | heh, yeah, but we know what the issue it :) | 21:52 |
| cherylj | issue IS | 21:53 |
| tych0 | cherylj: so what happens when i push to my branch? | 21:54 |
| tych0 | does that get automatically pushed and re-run? are the results available somewhere? | 21:54 |
| cherylj | tych0: you'll want to submit a PR to that feature branch | 21:55 |
| cherylj | tych0: then once it gets merged, CI will see that it's changed and add it into the rotation | 21:55 |
| tych0 | cherylj: ok, so should i close my other PRs then? | 21:56 |
| cherylj | tych0: did you just update dependencies.tsv? or are you updating the lxc package? | 21:56 |
| cherylj | tych0: yes | 21:56 |
| tych0 | cherylj: working on updating lxd | 21:56 |
| tych0 | cherylj: ok, will do | 21:56 |
| cherylj | tych0: then once you have the lxd package updated, you'll want to update the juju dependencies.tsv to pull in that new lxd | 21:56 |
| tych0 | cherylj: yup | 21:57 |
| cherylj | k :) | 21:57 |
| mup | Bug #1538241 changed: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241> | 22:49 |
| mup | Bug #1538241 opened: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241> | 22:55 |
| mup | Bug #1538241 changed: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241> | 22:58 |
| wallyworld | perrito666: standup? | 23:17 |
| === akhavr1 is now known as akhavr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!