User1: User5 yeah I don't know why. I'm on next Wed I should be on.
User2: User3 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
User3: User2 ok
User3: User2 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
User2: User3 \o/ that is most awesome
User4: User2 fyi it was a nightmare tonight to :p
User2: :-(
 * perrito666 is still fixing artifacts
 * wallyworld stabs git in the heart
User4: anyone remembers the key that lets you navigate github like a shell prompt?
User4: User2 does cmd/juju/model/jenv_test.go run for you?
User2: User4 yup
User4: ok, I think I finally merged
 * perrito666 reruns the whole suite
User3: User5 kabaddi is .. interesting :)
User3: looks like there's lots of variations, I have nfi what the one I just watched is
User2: User5 yo
User2: User3 User9 can you guys spare 15 minutes for a chat?
User3: User2 yep, standup?
User2: ok
User5: User2 ya?
User2: User5 never mind, figured it out :-)
User3: User2 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.
User2: ok, we can look to adjust how it may work if needed
User6: 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 :/
 * natefinch rages against the fact that errors.NotValidf appends "not valid" to my carefully crafted error string
User7: User4 better late than never, the Github key you're after is "t" (and "?" pops up some help)
User7: User5 hmmm... the apiserver/controller.Controller interface doesn't appear to get used anywhere
User5: ?
User5: User7 I think it was there purely as a contract of the API facade
User5: more for documentation purposes than real use
User7: User5 do we want to keep it?
User5: I kinda like it, but not attached to it
User6: A Tag tags things that are taggable.
User2: User3 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
User3: User2 ok
User2: sorry
User3: User2 LGTM with one possible change
User2: awesome, ty
User2: User3 i'd rather change to "is-controller" and worry about upgrades later. ie get everuthing correct now for 2.0
User2: since we can't upgrade anyway
User8: soooo
User8: trusty cloud images are broken on ap-southeast-2
User8: looks like launching the current 14.04 image on t2.medium results in an instance that does not know it's own ip address
User3: User2 do you want me to do the add-user/register bits on cloud-credentials, or just on master?
User3: User2 because there's nothing really specific to cloud-credentials to it
User2: User3 don't commit to master right now as it's frozen for alpha2. Bets to stick to out featuure beanch for now i think
User3: User2 ok
User3: User2 I have updated the doc just to have --config with two syntaxes. I think we should just implement that, and ask for stakeholder feedback
User3: User2 the original proposals are preserved in the alternatives section
User2: User3 sgtm, but i really hope they whinge about having to type --config each time
 * wallyworld off to soccer, bbiab
User3: User2 :)
User3: later
User9: User2 i hope that "iab" is at least 90min of play time!!
User2: User9 it's training for the team i coach, so 90 minutes of me tell them what to do :-)
User9: oh, like work then
User2: lol
User9: :P
User10: User12 User11 we haven't had a CI run on maas-spaces since Monday
User11: voidspace, yep, the focus has been on the other branch
User10: User12 User11 today we got another on maas-spaces-controller-space-config though, is that expected?
User11: voidspace, yes, and it looks way better.
User10: yep
User10: "cannot update controller space in config: cannot set controller-space to "Default space": not a valid space name"
User10: we need space name translation for the controller space
User12: voidspace, yeah, it's expected - I wanted to make sure it wasn't badly broken somehow
User12: voidspace, that's due to the CI job using pre 1.9.0 MAAS (beta3 or 4 I guess)
User10: User12 heh, right
User10: User12 shouldn't we handle it though?
User12: voidspace, that depends on whether there is a way to handle space names with spaces
User12: voidspace, if acquire node fails when you pass interfaces=0:space=Default space ..
User12: voidspace, I'll do some experiments with that
User11: 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"
User12: frobware, interesting - and the node managed to boot  ?
User11: dimitern, yep
User12: frobware, what did the UI show for the node's interfaces?
User11: dimitern, but I was staring at my screen thinking... uh-oh and I noticed the console window finish the bridging.
User11: dimitern, I didn't think that stage was that async.
User12: frobware, the async aspect is systemd related I believe
User11: dimitern, one wonders whether the nonce should get wrriten after we've finished fiddling.
User11: dimitern, actually, looking at the cloud-init output that seems to tbe the case already.
User12: frobware, yeah - since the bridge script runs first
User12: frobware, before the tools are downloaded or the nonce saved
User11: dimitern, UI shows two bonds, and deployed.
User11: dimitern, poor man's UI: http://pastebin.ubuntu.com/14876219/
User12: frobware, well d'oh.. sorry, we should fix that
User11: dimitern, what's the issue?
User12: frobware, since there's a bond, we should not just pick the first physical nic with the pxc mac, but also cater for bonds
User11: dimitern, I guess yesterday I was not using this node. :(
User12: frobware, that's a good catch sir :)
User11: dimitern, I happened to release all my nodes; that was previously my 1.25 vlan/bond testing node.
User12: 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
User11: dimitern, I can take a look now
User10: User11 do you have the company VPN setup?
User12: frobware, and there's the odd chance of picking a disabled nic (although we should see if this works in practice - disabled pxe interface)
User11: voidspace, yes
User10: User11 I followed the instructions here and it doesn't work, I get "VPN connection failed"
User10: User11 https://wiki.canonical.com/InformationInfrastructure/IS/HowTo/CompanyOpenVPN
User10: User11 did you set it up through Network Manager as described there?
User11: voidspace, yep
User11: voidspace, maybe a 15.10 issue
User12: voidspace, one of the failures was functional-jes, which failed ultimately with "spaces discovery still in progress"
User10: User11 harrumph
User10: User12 hmmm, odd
User12: voidspace, so we should investigate how we're dealing with multiple models in play
User10: User12 will look
User10: User12 oh god
User10: User12 I have no idea :-)
User10: User12 I will look into it
User12: voidspace, e.g. bootstrap went fine, then discovery was skipped as expected, followed by create-model, which exposed discovery blocking
User10: User12 User11 this tests the fix from yesterday - it passes with the new code and fails with the old code
User12: voidspace, great!
User10: User12 why was discovery skipped?
User12: voidspace, the job runs on joyent
User10: User12 ok
User10: User12 so it should only be possible for login to be blocked if space discovery has started
User10: User12 I'll check all code paths to see if that's really true
User10: User12 is this with yesterdays fix in?
User11: voidspace, has to be yes -- we had so many "success" results today.
User10: *grr*
User10: User11 thanks
User12: voidspace, yes - have a look at http://reports.vapour.ws/releases/3569/job/functional-jes/attempt/620 - around 03:44:30
User10: User12 yeah, looking
User10: User12 I see two code paths that don't close the channel (and need fixing)
User10: User12 an error calling api.ModelConfig and calling envrions.New
User10: User12 but I doubt they're the cause of the problem
User10: User12 I'll fix those in the current branch anyway
User12: voidspace, I think that's exactly what it is, considering the error right after that is 'model "functional-jes-env2" not found'
User10: User12 that'll be it then...
User12: voidspace, but all code paths need to be tested, yeah
User12: frobware, voidspace, dooferlad, are we doing the weekly call?
User11: dimitern, I'm skipping. want to concentrate on the build/test/merge.
User12: frobware, ok, I think I'll do the same
User10: ok
User13: dimitern, frobware, User10 I can go and report back.
User11: dimitern, voidspace, User13 I would like to get a CI build kicked off during our day if we have additional fixes today.
User10: I'll go as well
User10: User11 yep
User10: User12 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
User11: dooferlad, ack & thanks.
User12: voidspace, before calling anything that might fail, right?
User10: User12 yep
User12: voidspace, +1
User10: User12 and as a "few" of the exits are tested, the defer is now tested
User12: voidspace, awesome
User12: voidspace, now, it might be worth jiggling the test around a bit
User10: User12 in terms of?
User12: voidspace, e.g. causing the dep engine to bounce the workers a few times before checking ultimately discoverspaces stops
User13: dimitern, frobware, User10 is there any value in a quick standup?
User12: voidspace, it seems that when issues like that surface - e.g. the api caller dependency dies and pulls the other workers along
User10: User12 ok, interesting - is there an example test I can look at that does this?
User10: User12 otp
User12: voidspace, there should be - looking
User12: voidspace, have a look in worker/dependency/engine_test.go
User10: User12 ok
User10: User12 this should only be an issue for bootstrap - the bootstrap code is the only path that *checks* this channel
User10: User12 so bouncing the workers shouldn't block anything
User10: User12 maybe worth checking that discovery still completes if the worker is interrupted
User12: voidspace, isn't there a singular runner per model?
User10: User12 well, yes - but only one channel
User10: User12 interesting, I'll have to look at this code
User12: voidspace, then it can happen during/right after model creation, which is essentially the same as bootstrap
User10: User12 it's only limitLogins that is affected though, and that is only used during bootstrap itself I *believe*
User10: User12 that's where the channel is checked for closing
User10: User12 I'll look at that code and try and understand the ramifications of jes here
User10: (one channel per agent)
User10: User12 so it should only be discovery on the JES controller itself that blocks anything
User10: discovery for other models shouldn't block - that would be the intent anyway, and I think also the code
User11: dooferlad, I would say yes, but I see a lot going on here. dimitern, User10 want a quick standup?
User12: frobware, dooferlad, voidspace, yeah, let's do it quickly
User10: User11 User13 User12 if we can actually be quick :-)
User10: omw
User10: User11 User12 User13 http://reviews.vapour.ws/r/3735/
User10: User13 my network manager logs, showing the problem with openvpn (not very helpful) http://paste.ubuntu.com/14876407/
User10: User13 any ideas?
User11: mgz, ping
User10: User13 ah, now I get a missing file error for tls-auth
User10: User13 User12 User11 fixed the problem (file in wrong place) and now it works :-)
User13: User10 sweet!
User10: User13 User12 User11 so should be able to test bootstrapping to openstack
User10: we'll see
User11: voidspace, dimitern, User13 we seem to dump a lot of hex output to the logs - is this necessary / useful?
User13: User11 example?
User10: User11 no...
User11: dooferlad, let me find an example in the CI reports
User11: dooferlad, http://data.vapour.ws/juju-ci/products/version-3569/maas-1_9-deploy-trusty-amd64/build-1900/consoleText
User13: User11 looks useless
User11: personally I think we should drop this
User12: frobware, that was the result of adding more logging
User12: frobware, and indeed it was temporary to debug the trusty issue if it happens, will drop it
User11: dimitern, thanks
User12: voidspace, you've got a review
User12: voidspace, however, I've just discovered this:
User12: 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
User12: voidspace, I bootstrapped, then created another model - it seems discover spaces runs there as well
User12: 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
User12: space names with spaces can be both created and used for selection of nodes, fortunately selection can use the ID just the same
User14: anyone know if there is a plan to have the juju cli be able to export a bundle?
User14: juju-deployerizer exists but that's a stop-gap IMHO
User14: (thankyou for that niedbalski :))
User4: morning all
User10: User12 space discovery should run for the new model, shouldn't it?
User10: User12 we knew we would have to face this (non-unique provider id
User4: User2 tx for the extra set of eyes on that XDG merge
User4: I really needed that
User10: User12 do you want me to move the doc comment to the variable (in my PR)?
User12: voidspace, yes, I'm trying to fix this in my branch actually
User12: voidspace, yes please
User10: User12 provider id uniqueness?
User12: voidspace, uniqueness by prefixing with model uuid
User12: voidspace, experimenting with this now
User10: User12 cool
User13: frobware/dimitern/User11 our branch is missing https://github.com/juju/juju/commit/462a3d6e3c1a7a67085d6a092bafe0f0dd21b679 and that seems to be the problem the manual deploys are running into
User12: dooferlad, great! thanks for tracking this down
User12: dooferlad, can you propose a PR to merge this please?
User13: User12 yea, I am just resolving all the conflicts caused by renames
User12: dooferlad, cheers
User11: dooferlad, heh. so I had done an independent merge yesterday and this was one of my diffs against dimiter's version.
User13: frobware/dimitern I am seeing lots of networker being deleted and environ/model renaming. Wasn't that already merged?
User13: maybe this is a git suckage problem
User12: dooferlad, it's not merged in master
User13: yes, but shouldn't we already have fixed this stuff? We should have already got the renames, right?
User11: dooferlad, which branch are you looking at? maas-spaces or maas-spaces-controller-space-after-master-merge
User13: User11 maas-spaces
User11: User12 the latest merge of master is all in maas-spaces-controller-space-after-master-merge, correct?
User11: dooferlad, ^
User6: User16 standup?
User12: frobware, yeah, that's the one
User11: dimitern, User13 this is what I'm testing and making changes against.
User12: frobware, me too
User13: dimitern, User11 why does that branch still exist? Why not go back to maas-spaces?
User11: dooferlad, User12 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.
User11: dooferlad, the plan _is_ to go back to maas-spaces.
User13: User11 so, should I propose a merge of master to maas-spaces-long-name-of-doom?
User13: User11 I just don't want to replicate more work :-|
User11: dooferlad, I would say no...
User11: dooferlad, can we cherry-pick the change you identified?
User13: User11 sure, but ISTR not much happened on master last night
User11: 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.
User13: User11 maas-spaces-controller-space-config was tested last night. We were just talking about another branch. Which state are we trying not to perturb?!
User11: 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.
User11: dooferlad, let's HO
User13: User11 sure
User11: dooferlad, I'm done with typing. :)
User11: dimitern, ping - can you join the sapphire HO?
User12: frobware, sure, omw
User10: User13 ping
User13: User10 pong
User10: User13 that was a test ping
User10: User13 thanks for the ack
User13: User10 :-)
User10: User13 I thought my connection had died and XChat was just being slow to catch up
User10: it does that sometimes. Long timeout on connection.
User6: 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.
User4: if you know what you are expecting just check it
User15: perrito666, on a call w/ curtis and team; can you please rebase your mongo3 branch on the current master?
User15: perrito666, cherylj and curtis are working to get a bless so we can merge
User4: User15 I certainly can, you need that now?
User15: today please
User4: k, on it
User15: thnaks
User15: perrito666, please ping cherylj once it has been merged
User4: User15 you want me to just put mongo3 branch up to date with master ?or to merge back that into master too
User15: rebase off master
User15: so we can get a fresh ci run
User4: ah ok, ill do it
User4: then roll into a corner of the room and cry
User6: User16 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.
User16: User6 that and the blobstore sometimes only gives us the size (so we can't verify against the fingerprint)
User6: User16 ahh, hmm... weakness of the blobstore.  That's too bad
User16: User6 yep, though it doesn't hurt to store the size (accessible via YAML and JSON output)
User6: User16 yeah, totally is something we should store, just could be calculated on the server, instead of passing it up with requests.
User16: User6 true
User6: User16 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
User16: User6 the ID is the one you get from the server by calling "AddPendingResources()" before trying to upload
User17: User18 ping?
User18: User17 hi
User6: User16 oh, so it's two steps - add the pending metadata and then upload the bytes for that metadata?
User17: 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.
User16: User6 yep
User18: sure, sounds good
User17: User18 can you rebase off of master and create one PR that has both 4191 and 4131?
User18: User17 4191 has both and has been rebased off of master yesterday, i can rebase again though
User17: User18 ah, then that should be fine.  Don't think that it's changed since then
User18: User17 just building the rebase now, i'll push when it builds successfully
User17: User18 ok, thanks.  I can make a feature branch off if 4191 and you can merge the change for 4131 into that branch
User17: then we'll get a CI test run on that branch before we merge it into master
User18: User17 4191 has both already
User18: i was planning to rebase if 4131 ever got merged
User17: User18 then maybe I didn't need you to do anything!  :)
User18: User17 ok, 4191 should be rebased on master as of a minute ago
User18: User17 np :)
User17: kk, will get it in feature branch for testing.  Thanks!
User18: User17 sure, let me know if you need anything else
User18: i'll be in and out today, but happy to fix stuff as needed
User17: thanks, tych0!
User6: I kind wish the we had client-side logging
User6: I mean, I guess we kinda do - but I wish we actually saved it somewhere.
User17: User18 the feature branch is up!  https://github.com/juju/juju/tree/lxd-container-type
User17: User18 you should also add go fmt to your pre-push script
User4: anyone could hint me what is the new name of StateServerInfo?
User4: ill guess its ControllerInfo
User6: User16 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?
User16: User6 and PendingID
User6: User16 but for ListModelResources PendingID is always empty
User16: User6 yep
User6: User16 so, it seems like a lot of mental overhead for just one additional value
User4: bbl
User6: User16 seems like we don't even really need ModelResource if we just add ServiceID to resource.Resource
User6: User16 and storagepath I guess
User16: User6 and PendingID
User16: User6 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?
User6: User16 we never use pendingID outside the database
User16: User6 and in state
User6: User16 maybe it just needs a better name?
User16: User6 fine with me :)
User6: User16 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.
User16: User6 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)
User6: User16 that's fair.  Still seems like something that could be on resource.Resource
User16: User6 So you're suggesting that Resource and ModelResource be merged together?
User16: User6 the catch is that resource.Resource is the more user-facing type and ModelResource includes info that isn't meant for users
User6: User16 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
User16: User6 (namely PendingID and StoragePath)
User6: User16 right... though both those could, in theory, be useful if converted to something like a boolean for IsPending
User16: User6 It has to be an ID since there can be more than one pending for a given resource ID
User16: User6 trust me, I tried the boolean first :)
User6: User16 right, I just meant, since we were talking user-facing (I'm thinking conversion like for tabular output)
User16: User6 users should never see the pending ID except when it comes back from an AddPendingResource API call
User6: User16 right, and I don't think they will.  The API types don't need to expose it
User6: User16 the API being the best definition of what is userfacing
User8: User5 yup, I had an environment come up that was not listening on port 17070
User5: User8 well that port can be configured right?
User5: why is that an issue?
User8: manual3:
User8: type: manual
User8: bootstrap-host: ec2-54-79-138-39.ap-southeast-2.compute.amazonaws.com
User8: bootstrap-user: ubuntu
User8: this is my config
User8: 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
User5: ok, that is weird
User6: User16 can you explain modelID to me?  (I know you're changing the name, but the concept presumably stays the same)
User16: User6 its the identifier for the resource in the model, i.e. the resource ID
User5: can we please not call it modelID?
User6: User16 how is thast different than the doc ID (for non-pending resources) or the pendingID (for pending resources)?
User6: User5 already been brought up and I think fixed
User16: User6 FYI, I'm working up a patch that folds the ID and service ID into resource.Resource
User6: User16 ok
User16: User6 my aim is to eliminate resource.ModelResource
User6: User16 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.
User16: User6 thanks for bringing it up
User19: User5 this isn't a fw issue
User19: the port is not open
User19: i checked with `netstat -anp` and `ss
User18: User17 ah, cool, thanks
User18: User17 what steps to do we do from here to get it merged?
User17: User18 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
User17: User18 otherwise, we'll need you to fix the failures
User18: User17 ok, cool. that sounds entirely reasonable :)
User15: 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
User18: User15 ok, sounds good. there's definitely some stuff to be finished still
User15: yep and I know jam has been doing some testing
User4: its a good thing I decided to update my laptops ubuntu, I was tired of being able to boot without getting a video hang
User6: User4 lol
User4: well, and xorg seems to be under the impression that its doing a great job
User4: off cource, intel video driver cause a nil pointer dereference
User6: yay
User6: User16 thanks for the clarification about what the resource ID means.
User16: User6 np :)
User6: User16 and I agree, it makes sense to canonicalize the ID in a real field, instead of it being implicitly servicename + resourcename
User7: User6 I just replied to some of your replies for http://reviews.vapour.ws/r/3699/
User15: cherylj, tych0 looks like the lxd broker branch had a fun first test run ;)
User17: heh, yeah, but we know what the issue it :)
User17: issue IS
User18: User17 so what happens when i push to my branch?
User18: does that get automatically pushed and re-run? are the results available somewhere?
User17: User18 you'll want to submit a PR to that feature branch
User17: User18 then once it gets merged, CI will see that it's changed and add it into the rotation
User18: User17 ok, so should i close my other PRs then?
User17: User18 did you just update dependencies.tsv?  or are you updating the lxc package?
User17: User18 yes
User18: User17 working on updating lxd
User18: User17 ok, will do
User17: User18 then once you have the lxd package updated, you'll want to update the juju dependencies.tsv to pull in that new lxd
User18: User17 yup
User17: k :)
User20: Bug #1538241 changed: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
User20: Bug #1538241 opened: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
User20: Bug #1538241 changed: 2.0-alpha2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1538241>
User2: User4 standup?
juju-dev
Ubuntu IRC