| ericsnow | wallyworld: does anything need to change in core for the addition of resources to the bundle metadata? | 00:18 |
|---|---|---|
| wallyworld | ericsnow: the native bundle deployment code i would expect | 00:19 |
| wallyworld | there will be changes to upstream repos bundlechanges and charm as well | 00:19 |
| ericsnow | wallyworld: where is the native bundle deployment code? are you talking about cmd/juju/service/bundle.go? | 00:20 |
| wallyworld | yeah | 00:20 |
| ericsnow | wallyworld: k | 00:20 |
| === natefinch-afk is now known as natefinch | ||
| davecheney | The program 'i' is currently not installed. You can install it by typing: | 01:33 |
| davecheney | sudo apt-get install iprint | 01:33 |
| davecheney | who does shit like this ?!? seriously | 01:33 |
| menn0 | \o/ well that's a milestone. I just triggered a migration and the model was successfully serialised and imported into the target controller. | 01:33 |
| menn0 | still lots to do though | 01:33 |
| natefinch | menn0: nice! | 01:36 |
| davecheney | w00t | 01:36 |
| menn0 | next big milestone is to get the agents to switch over to the target controller | 01:36 |
| natefinch | menn0: that should be the easy part, right? | 01:38 |
| menn0 | natefinch: maybe slightly easier... | 01:42 |
| axw | wallyworld: http://reviews.vapour.ws/r/4163/diff/ | 02:01 |
| wallyworld | looking | 02:02 |
| axw | wallyworld: no test, because it involves the filesystem + raciness. could test if we moved setting current controller to jujuclient, but I think that's not a worthwhile use of time right now | 02:02 |
| wallyworld | axw: could you add a todo before landing? | 02:03 |
| axw | menn0: nice work :) is model migration doing any per-provider post-migration steps? something I brought up with thumper before, is that the hosted models in azure use resources in the controller resource group | 02:04 |
| axw | menn0: so if they're moved to a separate controller, each controller will need to run some code to move things about | 02:04 |
| axw | wallyworld: sure | 02:04 |
| menn0 | axw: yep, that's been thought of (as per your conversation with thumper) | 02:05 |
| menn0 | axw: I can't remember if it's in place yet (I *think* it is) but it's definitely getting done | 02:05 |
| axw | menn0: cool | 02:05 |
| axw | menn0: BTW, there's a new "controller-uuid" config attr that applies to all providers now | 02:05 |
| axw | fairly new | 02:06 |
| mup | Bug #1557102 changed: Cannot unregister from a controller <docteam> <juju-core:New> <https://launchpad.net/bugs/1557102> | 02:06 |
| mup | Bug #1557124 changed: Controller is orphaned for remotely registered user <docteam> <juju-core:Invalid> <https://launchpad.net/bugs/1557124> | 02:06 |
| menn0 | axw: what's that for? | 02:06 |
| axw | menn0: it's used by azure only atm. azure needs the uuid to identify the controller resource group | 02:07 |
| menn0 | axw: ok cool. | 02:11 |
| natefinch | mna, github.com/juju/cmd has a ton of assumptions about how it'll be used that make it really ugly to unit test | 02:32 |
| mup | Bug #1557216 opened: MADE-model-worker stale master <block-ci-testing> <ci> <juju-core:Incomplete> <juju-core made-model-workers:Triaged> <https://launchpad.net/bugs/1557216> | 02:39 |
| mup | Bug #1557254 opened: Move current-controller management to jujuclient <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1557254> | 02:39 |
| mup | Bug #1557264 opened: feature-resources is too stale to test <block-ci-testing> <ci> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1557264> | 02:39 |
| wallyworld | axw: do you have a minute to discuss add-credentials? standup hangout? | 02:55 |
| axw | wallyworld: ok, just getting a drink, brt | 02:55 |
| bradm | can someone tell me I'm doing something wrong here, please? trying to do a juju deploy <charm> --to lxc:# I get an error | 03:10 |
| bradm | ERROR adding new machine to host unit "ubuntu/0": cannot add a new machine: machine 0 cannot host lxc containers | 03:10 |
| bradm | this is using xenial with juju 1.25.3 on canonistack-lcy02, but the same thing happens with maas | 03:10 |
| axw | wallyworld: actually, USSO probably doesn't fit into accounts.yaml. they're not controller-specific. | 03:12 |
| axw | wallyworld: unless we store things not keyed by controller in there too? | 03:12 |
| wallyworld | axw: i was thinking we might | 03:12 |
| wallyworld | if it is juju related | 03:12 |
| wallyworld | easier to manage for the user, less droppings all over their machine | 03:13 |
| axw | wallyworld: it's a bit overloaded though. an account currently means "a user in a controller" | 03:13 |
| wallyworld | fair point | 03:13 |
| wallyworld | axw: i think we need to see what the total surface area of this stuff is going to be and make a call when we know fully what we're dealing with | 03:13 |
| cmars | wallyworld, hey, thanks for the reviews on 4131. if you're ok with http://reviews.vapour.ws/r/4131/diff/6-8/, i'll go ahead and land it in model-acls | 03:45 |
| cmars | pushed those after your last review | 03:45 |
| cmars | wallyworld, also, is there a good shining example of a BaseSuite test that sets up an APICaller for api client tests I could cheat off of? | 03:46 |
| wallyworld | cmars: one quick thing that i see - can we code isGreaterAccess() to do the right thing with read/write/admin upfront? | 03:47 |
| wallyworld | should be minimal extra effort | 03:47 |
| wallyworld | cmars: with the apicaller thing - i thought the tests were all correctly set up and you simply needed s/JujuConnSuite/BaseSuite . if not then leave for another pr | 03:47 |
| cmars | wallyworld, i'm hesitant to actually define the ModelWriteAccess until we actually implement it | 03:48 |
| cmars | wallyworld, however, i think we're forward compatible with such a change when we're ready to make it | 03:48 |
| cmars | wallyworld, ^^ state.ModelWriteAccess, that it | 03:48 |
| cmars | wallyworld, i'd like the state to reflect reality, which is, you're either read-only, or full-blown admin | 03:49 |
| cmars | wallyworld, that way, when we do add more nuanced access values, they match existing state | 03:49 |
| cmars | make sense? | 03:49 |
| wallyworld | cmars: sort of. so right now, if we happen to save "AccessWrite" in to state for a user. that isGreaterAccess() will fail if new access is "admin" | 03:50 |
| wallyworld | isn;t that a trap we can easily avoid? | 03:50 |
| cmars | wallyworld, do you mean if we added state.ModelWriteAccess? because right now, that value is not defined in state. | 03:52 |
| cmars | wallyworld, the state package doesn't give callers the language to phrase such a condition (unless you went and casted arbitrary strings to state.ModelAccess) | 03:52 |
| cmars | wallyworld, i think when we do make the distinction between "write" and "admin", we'll need to then improve the logic in the apiserver/modelaccess | 03:54 |
| wallyworld | ok. fair enough. maybe a todo next to where the constants are defined that if a new one is added, gp and update isGreaterAccess()? i'll leave to you to do or not | 03:54 |
| cmars | wallyworld, +1 for a TODO, i was on the fence about that | 03:54 |
| wallyworld | cmars: for the api example, cmd/juju/storage/add__test.go (assuming you can't just drop JujuConnSuite for BaseSuite with no other changes). if it's not that easy change, do in another pr so as not to block this work | 03:55 |
| cmars | wallyworld, my command tests use mocks like that, but I need to mock an apiserver to test the api client. | 04:05 |
| wallyworld | cmars: ah, right sorry, let me get another example | 04:06 |
| wallyworld | cmars: see "apiCaller := basetesting.APICallerFunc(" in juju/api/storage/client_test.go | 04:07 |
| cmars | wallyworld, awesome. yep, that's what I needed! | 04:09 |
| wallyworld | great :-) | 04:10 |
| wallyworld | go and cargo cult that sucker | 04:10 |
| natefinch | wallyworld: got a minute? | 04:37 |
| wallyworld | sure | 04:38 |
| natefinch | wallyworld: I was looking at the channel code... it still looks like roger & co are ignoring the CharmRepo wrapper, so channels aren't getting added to those interfaces | 04:39 |
| natefinch | wallyworld: for example: https://github.com/juju/charmrepo/pull/71/files | 04:40 |
| wallyworld | looking | 04:40 |
| mup | Bug #1557302 opened: juju and jujud have grown to >100MB <juju-core:Triaged> <https://launchpad.net/bugs/1557302> | 04:42 |
| wallyworld | natefinch: it may be time to pull CharmStore into core and look at what's needed moving forward - maybe we only need the extra header attrs it allows us to add when querying revision information; maybe we use csclient directly for most everything else? | 04:43 |
| wallyworld | maybe we extra the caching stuff and use where needed | 04:43 |
| wallyworld | extract | 04:43 |
| wallyworld | separate to the use of the client itself | 04:44 |
| natefinch | wallyworld: I actually like the wrapper, so the command code doesn't have raw calls to client.Put(some_Url) in it... so those are all consolidated in the helper library | 04:45 |
| natefinch | wallyworld: I'm fine if csclient is that wrapper... I just don't want to ever see wallyworld: I shouldn't ever see client.Put("/"+id.Path()+"/publish", val) outside one API wrapper library... | 04:46 |
| natefinch | oops, ignore that second wallyworld in the middle.. copy paste error :) | 04:46 |
| wallyworld | np, agree with not using the low level stuff directly | 04:47 |
| wallyworld | so i guess core is the only place using the CharmStore wrapper | 04:47 |
| wallyworld | hence it's going to be up to us to maintain it. it would be easier to do that if it were in core | 04:48 |
| natefinch | it seems wise to have it outside of core, in case other tools want to use the same cache... however, maybe we should be focusing on putting non-caching commands right on csclient | 04:50 |
| wallyworld | natefinch: depends on the semantics i think. do you have a list of the commands we need to add that core needs? | 04:52 |
| natefinch | wallyworld: ListResource, GetResource, UploadResource... and I made a Publish method so the CLI code wouldn't have to hardcode the url in it. | 04:54 |
| wallyworld | natefinch: so comapring what's there on csclient.Client for charms - we have UploadCharm() and UploadBundle(). I guess we use Meta() for a list type operation? and Get(path) for getting charms? | 04:57 |
| wallyworld | actually GetArchive() | 04:58 |
| wallyworld | is used to get a charm i think | 04:58 |
| wallyworld | either a charm or bundle | 04:58 |
| natefinch | yeah | 04:58 |
| wallyworld | natefinch: so adding thise resource methods to client seems ok doesn't it | 04:58 |
| natefinch | wallyworld: yep | 04:59 |
| wallyworld | ok, sgtm | 04:59 |
| natefinch | wallyworld: ok, cool | 04:59 |
| wallyworld | thanks for thinking it through | 04:59 |
| natefinch | wallyworld: np | 04:59 |
| natefinch | ok, I'm done. g'night all | 05:15 |
| menn0 | axw: ping? | 07:21 |
| axw | menn0: pong | 07:22 |
| menn0 | axw: would you mind taking a looking at this one? http://reviews.vapour.ws/r/4169/ | 07:22 |
| menn0 | axw: it's trivial | 07:22 |
| axw | sure | 07:23 |
| menn0 | axw: and should help get a bless for the MADE-state-workers branc | 07:23 |
| axw | menn0: LGTM | 07:24 |
| menn0 | axw: thanks | 07:24 |
| frankban | mgz: ping, are those errors spurious? http://reports.vapour.ws/releases/3751 | 08:33 |
| frankban | mgz: (and morning) | 08:33 |
| mup | Bug #1557380 opened: help text for juju add-ssh-key needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1557380> | 09:10 |
| frobware | dimitern: ping, 1:1? Can skip if you're busy and sync later. I'm currently merging master again. | 09:17 |
| dimitern | frobware, hey, sorry got carried away | 09:21 |
| dimitern | frobware, but I'm close to getting multi-nic working | 09:21 |
| frobware | dimitern: then I will NOT disturb you. \o/ :) | 09:23 |
| dimitern | :) cheers | 09:27 |
| TheMue | morning o/ | 10:10 |
| voidspace | frobware: actually, I have coffee and some motivation - will crack on now and take a break later | 10:18 |
| voidspace | frobware: need to make a decision how to have the gomaasapi test server support 1.x *and* 2.x | 10:19 |
| voidspace | frobware: obviously the urls have the api version in them and the test server does have a version field | 10:19 |
| voidspace | frobware: but in terms of code structure | 10:19 |
| voidspace | frobware: branching inside every method isn't ideal but maybe the path of least resistance | 10:20 |
| voidspace | frobware: changing the server to an interface and having two implementations would be painful as the server have lots of fields and they would all need accessor methods | 10:20 |
| frobware | voidspace: at first blush having a branch seems easier, at least initially. You can always revise a little as you see how things pan out. | 10:32 |
| voidspace | frobware: heh, so the first problem is the change to the capabilities output | 10:33 |
| voidspace | frobware: but calling "version" from the maas command line is broken (I've filed a bug) | 10:33 |
| voidspace | frobware: so having to write gomaasapi code to see the output of the version api call (that gets us the capabilities) | 10:34 |
| frobware | voidspace: sweet | 10:34 |
| voidspace | frobware: dimitern: so, if we're dropping support for maas < 1.9 there are two choices | 10:38 |
| voidspace | frobware: dimitern: detect the unsupported version early and error out | 10:39 |
| voidspace | frobware: dimitern: or just assume we're on a supported version | 10:39 |
| voidspace | frobware: dimitern: I assume the first option is preferable | 10:39 |
| dimitern | voidspace, I think we should report an error | 10:39 |
| voidspace | dimitern: yep | 10:39 |
| frobware | voidspace: as 1.8 is around, drop out early. | 10:39 |
| voidspace | yeah, cool | 10:39 |
| voidspace | dimitern: so, supportsDevices, supportsStaticIPs and supportsNetworkDeploymentUbuntu can all go away | 10:40 |
| voidspace | and NewEnviron can just do a version check | 10:40 |
| voidspace | frobware: it looks like it might be cleaner to do that first | 10:41 |
| dimitern | voidspace, yeah - either NewEnviron or even at lower level - getMAASClient | 10:42 |
| voidspace | dimitern: that method just returns the client, which is created in SetConfig, which is called from NewEnviron | 10:43 |
| voidspace | dimitern: and NewEnviron already does the capabilities checks | 10:44 |
| voidspace | dimitern: so replacing the capabilities checks with a version check in NewEnviron seems sensible | 10:44 |
| dimitern | voidspace, sounds good, yeah | 10:46 |
| voidspace | dimitern: the client does need to change as we need to switch between 1.0 api and 2.0 api depending on maas version | 10:46 |
| voidspace | dimitern: hah, however - you need to know the maas api version in order to be able to ask maas which version it is... | 10:49 |
| voidspace | dimitern: if you call /api/1.0/version/ on a 2.0 server you get "null" back | 10:49 |
| voidspace | dimitern: shall I report a bug for that do you think? they ought to have an api version independent version endpoint | 10:50 |
| dimitern | voidspace, yes please, that should be a bug - i.e. maas should report a sensible error for /api/1.0/ requests | 10:56 |
| mup | Bug #1557470 opened: juju reads from wrong streams.canonical.com location <simplestreams> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1557470> | 11:34 |
| voidspace | dimitern: frobware: old code removed, 50 additions and 653 deletions | 11:37 |
| voidspace | dimitern: frobware: it compiles, but tests need checking & fixing | 11:37 |
| voidspace | satisfying though | 11:37 |
| voidspace | https://github.com/juju/juju/compare/maas-spaces2...voidspace:drop-maas-1.8?expand=1 | 11:38 |
| frobware | voidspace: nice | 11:38 |
| mup | Bug #1557470 changed: juju reads from wrong streams.canonical.com location <simplestreams> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1557470> | 11:46 |
| dimitern | voidspace, nice, but that's going into a feature branch first, right? | 11:49 |
| voidspace | dimitern: why not land it? | 11:50 |
| voidspace | dimitern: long lived feature branches are a pain | 11:50 |
| dimitern | voidspace, well, there's a lot to clean up, but doing now will make my life a little hell :/ | 11:51 |
| dimitern | with all the changes I'm making for multi-nic | 11:51 |
| voidspace | dimitern: so you'd rather make my life hell merging yours instead... | 11:51 |
| dimitern | voidspace, nope, I'd rather drop the legacy code later and just disable it for now ? | 11:52 |
| voidspace | if your changes conflict there's hell for someone... | 11:52 |
| dimitern | voidspace, I will happily deal with the conflicts, just if possible I'd like to do that next week | 11:54 |
| voidspace | dimitern: fine | 11:54 |
| voidspace | I don't mind dealing with them either :-) | 11:54 |
| voidspace | someone has to do them | 11:54 |
| voidspace | it should just be deleting more code | 11:54 |
| voidspace | dimitern: I really loathe long lived feature branches though and it has become our standard way of working | 11:54 |
| voidspace | down to 38 test failures :-/ | 11:55 |
| voidspace | 108 were panicing a minute ago, so that is progress | 11:55 |
| mup | Bug #1557470 opened: juju reads from wrong streams.canonical.com location <simplestreams> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1557470> | 11:55 |
| frobware | dimitern: how close are you to maas-spaces2 tip? (on your feature branch) | 11:58 |
| frobware | dimitern: seem to have lots of unit test failures today | 11:59 |
| frobware | dimitern: and the last CI run was way worse than I expected | 11:59 |
| dimitern | frobware, not so close anymore | 12:00 |
| dimitern | frobware, 5 days behind | 12:01 |
| frobware | dimitern: which coincides with when I started merging master. hmm. | 12:01 |
| frobware | dimitern, voidspace: I think we'll need to set 'juju_bridge_all_interfaces=1' to 0 in maas-spaces2. We made this 0 on master to make tests pass, but they will of course continue to fail on maas-spaces2. Can I suggest that if you need multiple bridges you set this explicitly in your feature branch until we have everything in place. | 12:15 |
| dimitern | frobware, sounds good | 12:16 |
| frobware | dimitern, voidspace: http://reviews.vapour.ws/r/4172/ | 12:29 |
| frobware | hopefully as easy as it gets | 12:29 |
| dimitern | frobware, LGTM | 12:29 |
| perrito666 | dimitern: would you please merge my goose package? I lack super powers | 12:31 |
| dimitern | perrito666, doesn't $$merge$$ work there? | 12:32 |
| mup | Bug #1556483 changed: ERROR invalid config: no addresses match <juju-core:Invalid> <https://launchpad.net/bugs/1556483> | 12:40 |
| perrito666 | dimitern: iirc, last time I tried to merge the bot did not respond to me | 12:41 |
| dimitern | perrito666, now it did - but the tests failed | 12:48 |
| * perrito666 goes check what happened | 12:49 | |
| frobware | dimitern, voidspace: master merge, http://reviews.vapour.ws/r/4173/ | 13:04 |
| dimitern | frobware, looks good | 13:13 |
| frobware | dimitern: thanks for the review | 13:13 |
| frobware | dimitern: so, devices... next :) | 13:14 |
| dimitern | frobware, I have lxc working locally | 13:15 |
| dimitern | well a bit unstable and only with lxc-clone: false, but still | 13:15 |
| frobware | dimitern: sounds interesting; want to sync before I go grab some lunch? | 13:16 |
| dimitern | one more live test and I'm pushing what I have to my PoC branch | 13:16 |
| dimitern | frobware, sure | 13:16 |
| dimitern | frobware, standup HO | 13:18 |
| frobware | omw | 13:18 |
| frobware | dimitern: well, that's weird. the master merge was quite flaky running the unit tests locally, but passed first time on the CI machines. | 13:54 |
| dimitern | frobware, I guess CI is rock solid then :) | 13:55 |
| frobware | dimitern: brings new meaning to "Ship It!" | 13:56 |
| dimitern | :D | 13:57 |
| mup | Bug #1557540 opened: Missing help for payloads <juju-core:New> <https://launchpad.net/bugs/1557540> | 13:59 |
| perrito666 | dimitern: would you give me another little push? :) I still lack the credentials to command merge bot (the error was because the patch was against liberty but proposed against v1, I fixed that) | 14:10 |
| mup | Bug #1557540 changed: Missing help for payloads <juju-core:New> <https://launchpad.net/bugs/1557540> | 14:11 |
| dimitern | perrito666, sure - done | 14:13 |
| perrito666 | tx | 14:13 |
| mup | Bug #1557540 opened: Missing help for payloads <juju-core:New> <https://launchpad.net/bugs/1557540> | 14:17 |
| katco | natefinch: ericsnow: hey | 14:21 |
| ericsnow | katco: yo | 14:22 |
| ericsnow | katco: we should get together and point those cards in our iteration backlog | 14:22 |
| katco | ericsnow: yes, unfortunately i cannot talk still | 14:23 |
| ericsnow | katco: :( | 14:23 |
| katco | ericsnow: natefinch: also, unfortunately mark did not like push-resources. he wants it to be "attach-resources" | 14:24 |
| dimitern | frobware, pushed the changes so far - https://github.com/juju/juju/compare/maas-spaces2...dimitern:maas-spaces2-multi-nic-lxc | 14:24 |
| dimitern | frobware, lxc now works | 14:24 |
| ericsnow | katco: k | 14:24 |
| dimitern | frobware, tried with 2 on the same machine, now will try a few more | 14:24 |
| frobware | dimitern: will take a look in a bit, just looking at the brokeness of maas-spaces2 | 14:25 |
| frobware | dimitern: but really cool though! \o/ | 14:26 |
| dimitern | frobware, yeah :) \o/ | 14:27 |
| dimitern | frobware, there's 2m delay at boot due to the cloud-init-nonet :/ but otherwise seems to work once only the primary NIC has a gateway set in both /e/n/i and lxc.conf | 14:28 |
| frobware | dimitern: very nice. congrats! | 14:29 |
| dimitern | frobware, thanks :) we all deserve a pat on the back | 14:30 |
| natefinch | katco: lol.. well, at least command name changes are trivial | 14:30 |
| katco | natefinch: yeah | 14:30 |
| dimitern | frobware, I'll start splitting of chunks of that branch and propose them against maas-spaces2 | 14:30 |
| frobware | dimitern: are you considering just the state changes, or more? | 14:31 |
| ericsnow | katco: are you tackling merging master into feature-resources? (bug #1557264) | 14:31 |
| mup | Bug #1557264: feature-resources is too stale to test <block-ci-testing> <ci> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1557264> | 14:31 |
| katco | ericsnow: i can definitely take care of that | 14:32 |
| dimitern | frobware, state changes definitely, and some stuff in networkingcommon | 14:32 |
| ericsnow | katco: suh-weet | 14:32 |
| dimitern | frobware, but the other bits need better testing | 14:32 |
| katco | rick_h__: so i think the last loose-end on resources is the progress indicator for fetching resources | 14:33 |
| rick_h__ | katco: ok, did you look at the current output locations and see if we can fit anything in place on the existing tabular output? | 14:33 |
| ericsnow | katco, natefinch: FYI, http://reviews.vapour.ws/r/4160/ | 14:34 |
| katco | rick_h__: we talked about maybe having it under "juju list-resources <service> --details" | 14:35 |
| katco | rick_h__: probably not in an existing column, but maybe a new section | 14:36 |
| rick_h__ | katco: do you have sample output we can peek at please? | 14:36 |
| katco | rick_h__: let me cook one up | 14:36 |
| rick_h__ | katco: ty | 14:37 |
| frobware | alexisb: see progress on multi-NIC from dimitern ^^ | 14:44 |
| katco | rick_h__: possibly this: http://pastebin.ubuntu.com/15392044/ | 14:44 |
| frobware | voidspace: this looks so much better now "has interface addresses: [local-cloud:10.17.20.215@default(id:0) local-cloud:192.168.10.102@internal(id:1) local-cloud:192.168.12.102@db(id:3) local-cloud:192.168.11.102@public(id:2)" - thanks! | 14:46 |
| alexisb | dimitern, very very cool! | 14:46 |
| dimitern | alexisb, cheers :) | 14:47 |
| === urulama_ is now known as urulama | ||
| rick_h__ | katco: looking | 14:52 |
| rick_h__ | katco: can we also track upload progress on local ones? | 14:53 |
| katco | rick_h__: isn't that kind of strange since the CLI will block when uploading? | 14:54 |
| katco | rick_h__: you'd have to flip to a new terminal and do a watch | 14:54 |
| natefinch | it's a lot easier than tracking progress on unit downloads | 14:54 |
| natefinch | katco: I assume he just means have the CLI output progress indications while it blocks | 14:55 |
| rick_h__ | katco: thoughts on http://paste.ubuntu.com/15392141/ | 14:55 |
| rick_h__ | natefinch: no, I mean if I were in another terminal or another user I'd see that status | 14:55 |
| katco | rick_h__: ah i didn't think about the multi-user implications | 14:55 |
| katco | rick_h__: what happens when we do "deploy --resources"? does that status show up as well? | 14:56 |
| natefinch | rick_h__: personally, I would find it very weird for other people to be notified when you're uploading a file. systems don't generally do that... it's just either not there or it's there | 14:56 |
| frankban | rick_h__: urulama, hatch, perrito666: for instance, this is the current unit info from master's megawatcher: http://pastebin.com/U51reeY4 (just FYI) | 14:56 |
| rick_h__ | natefinch: but that's what I'm asking, if you do it when getting a file from a remote location, why not a local location? | 14:56 |
| rick_h__ | natefinch: it's kind of the same thing to a second user "this thing is updating and in progress..." | 14:57 |
| frankban | rick_h__: urulama, hatch, perrito666: so I guess we'll need to fetch what we need from AgentStatus and WorkloadStatus | 14:57 |
| katco | rick_h__: you would still see the download progress for a local resource... the upload is to the controller, not individual units | 14:57 |
| frankban | perrito666: is AgentStatus going to be renamed there as well? | 14:57 |
| katco | rick_h__: so you wouldn't see an upload progress, but you would still see a download progress | 14:57 |
| rick_h__ | katco: ok, so download would be from the controller down, fiar enough | 14:57 |
| perrito666 | frankban: gimme a moment and ill be with you | 14:58 |
| rick_h__ | katco: ok, what are folk's thoughts on the in-line? | 14:58 |
| natefinch | rick_h__: there's two different transfers, from charmstore/local to controller, and from controller to unit. I had only been thinking of updates on the latter. | 14:58 |
| katco | rick_h__: the "REVISION" heading seems kind of strange to me now | 14:58 |
| rick_h__ | katco: yea, it says it's downloading rev9, we know that ahead of time right? | 14:58 |
| katco | rick_h__: as in "what revision? downloading" | 14:58 |
| natefinch | ditto... it's already overloaded | 14:58 |
| katco | rick_h__: yes, through the same mechanism we'll have to provide progress | 14:59 |
| katco | rick_h__: we first know about the metadata: rev, size, fingerprint, and then we download | 14:59 |
| rick_h__ | katco: right, ok so it's not completely out of place and why I made sure ot keep the revision info in the fetching messagfe | 14:59 |
| natefinch | rick_h__: the thing is, then you lose information about what that unit is actually running right now, since it's not running 9 right now, it's running whatever it downloaded previously | 14:59 |
| rick_h__ | natefinch: true, but it's for some download window of time. Is it significant? | 15:00 |
| rick_h__ | natefinch: and I'd expect the yaml/json status to be full details | 15:00 |
| natefinch | rick_h__: is the progress indicator significant, by that measure? :) | 15:00 |
| rick_h__ | natefinch: e.g. different fields | 15:00 |
| natefinch | rick_h__: also keep in mind it'll be this for downloading uploaded resources: http://paste.ubuntu.com/15392199/ | 15:01 |
| rick_h__ | natefinch: rgr, /me goes into call will slow down replies | 15:02 |
| natefinch | rick_h__: personally, I find it really hard to read having all that extra data embedded in that column. I'd much rather have a separate section like katco proposed | 15:02 |
| perrito666 | so first of all, frankban hatch urulama https://github.com/juju/juju/blob/juju-1.26-alpha1/state/status_model.go#L272 | 15:02 |
| perrito666 | that was the old translate function | 15:03 |
| perrito666 | frankban: urulama, hatch second, the change of agent-status -> juju-status is meant to be only a presentation thing, just user facing, internally we still hold the names that make sense for the internal juju terminology, so my first intuition would be to say that it will remain agent-status unless someone disagrees | 15:04 |
| hatch | perrito666: I don't really understand the 'juju-status' key in UnitStatus but ok :) | 15:05 |
| frankban | perrito666: cool, I agree | 15:06 |
| hatch | the logic doesn't 'look too complex so that's good :D | 15:06 |
| natefinch | rogpeppe1: I see a lot of calls like client.Put("/"+id.Path()+"/meta/perm/read", []string{params.Everyone, id.User}) ... how come you guys aren't wrapping that stuff in helper methods on charmrepo/csclient.Client? | 15:07 |
| frankban | perrito666: but FYI in the current master mega-watcher units have AgentStatus and WorkloadStatus, machines have JujuStatus and MachineStatus :-) | 15:07 |
| rogpeppe1 | natefinch: we could do, yeah | 15:07 |
| frankban | perrito666: so is this going to stay like that? | 15:07 |
| perrito666 | hatch: so, the differentiation between juju-status and workload-status is because the former shows information about the juju agent and the later about the charm | 15:08 |
| rogpeppe1 | natefinch: feel free to add PutId, SetPerm etc | 15:08 |
| perrito666 | frankban: aghh, then expect it to change to juju-status wil be consistent there | 15:08 |
| frankban | perrito666: for beta3? and what about Workload vs Machine? | 15:09 |
| rogpeppe1 | natefinch: it's always a trade-off between adding useful methods and adding a helper method for every single endpoint in the store | 15:09 |
| rogpeppe1 | natefinch: i'm not sure the maintenance burden of the latter is worth it | 15:09 |
| perrito666 | frankban: workload and machine remain the same, agent changes to juju, hopefully in a couple of hours tops | 15:10 |
| natefinch | rogpeppe1: I would call a helper for every single endpoint in the store useful :) As someone writing a CLI client, I really don't ever want to have to know what HTTP method I should be using.. someone should have wrapped that stuff away in a helper library, IMO. | 15:10 |
| rogpeppe1 | natefinch: especially given the way that so much of this stuff can be combined in arbitrary ways with the bulk endpoints | 15:10 |
| frankban | perrito666: ok so units will have JujuStatus and WorkloadStatus, machines will have JujuStatus and MachineStatus? | 15:10 |
| rogpeppe1 | natefinch: the way i look at it is the HTTP API really is the API - the client library is a thin (and not opaque) layer above it | 15:11 |
| perrito666 | correct | 15:13 |
| frankban | perrito666: ok, do you also have the conversions functions used for StatusInfo and StatusData? | 15:13 |
| rick_h__ | natefinch: my issue is that the other sectino isn't meaningful without trying to match unit/resource name in the first section so I find it hard to process. | 15:13 |
| perrito666 | frankban: passthrough unless there is error in workload status, there we would show the error message in info iirc | 15:15 |
| perrito666 | but I dont recall where it was | 15:15 |
| natefinch | rogpeppe1: I see what you're saying... but I think the client code is a lot easier to read and understand when I see client.Publish(id, channels, resources) rather than client.Put("/"+id.Path()+"/publish", params.PublishRequest{Channels: channels, Resources:resources}) | 15:15 |
| === mhilton-lunch is now known as mhilton | ||
| rogpeppe1 | natefinch: as i said, it's a trade-off | 15:16 |
| rogpeppe1 | natefinch: there are hundreds of endpoints | 15:16 |
| rogpeppe1 | natefinch: well... lots anyway | 15:16 |
| rogpeppe1 | natefinch: and thousands of potential combinations | 15:16 |
| frankban | perrito666: so StatusInfo was the error message and StatusData is current WorkloadStatus? | 15:16 |
| rogpeppe1 | natefinch: ok, so 60+ endpoints | 15:18 |
| rogpeppe1 | natefinch: i think that having a reasonable grasp of the HTTP API saves quite a bit of work overall | 15:18 |
| frankban | perrito666: so I think old StatusInfo was WorkloadStatus.Message | 15:19 |
| perrito666 | frankban: the exact name was StatusInfo ? | 15:19 |
| natefinch | rogpeppe1: maybe for you, not so much for me ;) | 15:19 |
| frankban | perrito666: and old StatusData was AgentStatus.Data | 15:19 |
| perrito666 | frankban: so, now I remember | 15:20 |
| perrito666 | StatusData was AgentStatus.Data | 15:20 |
| frankban | perrito666: I think the old logic is in https://github.com/juju/juju/blob/juju-1.26-alpha1/state/allwatcher.go#L294 | 15:20 |
| perrito666 | StatusInfo was AgentStatus.Message | 15:20 |
| rogpeppe1 | natefinch: come on, that call isn't hugely much more verbose than client.SetPerm(id, channels, resources) | 15:21 |
| perrito666 | frankban: yes, that was the conversion done, when error we did something different otherwise we would just agentStatus fields | 15:21 |
| frankban | perrito666: I see, let me try to formalize that | 15:21 |
| rick_h__ | natefinch: katco http://paste.ubuntu.com/15392403/ please | 15:23 |
| rick_h__ | natefinch: katco I think that's the best of both worlds as close as I can think up atm | 15:23 |
| mup | Bug # changed: 1553298, 1553299, 1553303, 1553308 | 15:26 |
| ericsnow | katco, natefinch, rick_h__: perhaps we can go with something in the middle: http://pastebin.ubuntu.com/15392433/ | 15:27 |
| rick_h__ | ericsnow: the thing is the extra column that comes/goes I think is bad for cli imo. Maybe I'm wrong on that front. | 15:28 |
| katco | rick_h__: i agree | 15:28 |
| rick_h__ | ericsnow: and I do think that the YAML has to have the data spelled out as it's machine data | 15:28 |
| ericsnow | rick_h__: I'd agree if we expected folks to be parsing the tabular output | 15:28 |
| rick_h__ | ericsnow: right, but some folks will do simple "status | grep | xxx" | 15:29 |
| rick_h__ | ericsnow: vs parsing the yaml/json | 15:29 |
| katco | ericsnow: it's some ux principal i can't remember: don't have elements of the ui appear/disappear based on state | 15:29 |
| katco | principle | 15:29 |
| rick_h__ | katco: +1, especially if it could be fast moving. "What was that blip? oh, wtf, nothing there now" | 15:29 |
| rick_h__ | as soon as download completes/etc | 15:30 |
| perrito666 | frankban: im starting with the agent->juju change now, willping you when its done | 15:31 |
| dimitern | frobware, please ping me before you're about to test the PoC branch btw | 15:35 |
| frobware | dimitern: stuck in maas-spaces2 land. I cannot bootstrap on there right now... :( | 15:35 |
| dimitern | frobware, I found a few more things to fix and will push some updates as soon as the current live test passes | 15:35 |
| dimitern | frobware, oh :/ | 15:36 |
| dimitern | frobware, xenial-related? | 15:36 |
| frobware | dimitern: yeah, going back in history. don't think so. | 15:36 |
| frankban | perrito666: ty | 15:36 |
| natefinch | rick_h__: to be fair, any progress indicator we make is going to blip away once the download is done :) | 15:36 |
| dimitern | frobware, that's before or after the last master merge? | 15:37 |
| rick_h__ | natefinch: true enough | 15:38 |
| frobware | dimitern: gone back to bc2914e5af162baa0f6ec1ffed69859fcc3e7633 (Fri Mar 11 12:00:01 2016 +0000) | 15:38 |
| ericsnow | rick_h__: here's an iteration on your last one that I find a little less busy: http://pastebin.ubuntu.com/15392511/ | 15:39 |
| rick_h__ | ericsnow: my only concern there was "is it safe to assume it's always fetching the expected"? | 15:39 |
| voidspace | frobware: cool | 15:40 |
| ericsnow | rick_h__: my gut says yes :) | 15:40 |
| ericsnow | rick_h__: that would be a pretty tight race to be otherwise | 15:41 |
| natefinch | ericsnow, rick_h__: if the problem with a separate table is mapping between the two, why not an unobtrusive indicator in the top table? http://pastebin.ubuntu.com/15392537/ | 15:41 |
| ericsnow | rick_h__: to be safe, a slight tweak: (fetching 9: 96%) | 15:42 |
| rick_h__ | ericsnow: ok, if we have verified that it's a safe assumption including in the world where we can pass arbitrarty version numbers then I'm +1 | 15:42 |
| rick_h__ | ericsnow: I think you're right, but I didn't feel comfy assuming it so I went with the 100% case, but yea...I think you're right | 15:42 |
| natefinch | I think the separate table will make it a *lot* easier to understand multiple downloads at once | 15:42 |
| ericsnow | rick_h__: we should double-check though :) | 15:42 |
| rick_h__ | ericsnow: ok, if you double check and feel safe then I'm +1 yours and if not, then I'm +1 mine | 15:43 |
| katco | ericsnow: well, expected should always list what we want to download. it may not be the latest | 15:43 |
| rick_h__ | natefinch: the issue there is when you get more than one going on, especially across units/etc | 15:43 |
| katco | ericsnow: so i think that's an accurate statement | 15:43 |
| natefinch | rick_h__: right, I think this is a lot easier to understand: http://pastebin.ubuntu.com/15392550/ | 15:44 |
| natefinch | rick_h__: although eric's appending the download info is ok too | 15:44 |
| rick_h__ | natefinch: understand, but disagree, especially if we can stick it on the end like ericsnow's | 15:45 |
| natefinch | rick_h__: I really hate munging multiple pieces of data in the same column, but I think I'm overruled on that :) | 15:45 |
| katco | rick_h__: ericsnow: natefinch: so we'll go with http://pastebin.ubuntu.com/15392511/ ? | 15:45 |
| ericsnow | katco: with or without the parens around the REVISION value? | 15:46 |
| rick_h__ | katco: the first one in there, without parens aroud revision value | 15:46 |
| katco | +1 | 15:46 |
| ericsnow | rick_h__: coolio | 15:46 |
| katco | ta rick_h__ | 15:46 |
| rick_h__ | ty ericsnow katco natefinch, appreciate the dialog/discussion. Always better hashed out :) | 15:47 |
| ericsnow | rick_h__: no, thank you! | 15:47 |
| frobware | dimitern: I created a new node, enlisted, commissioned and bootstrapped without problems. | 15:47 |
| dimitern | frobware, sweet! so problem solved? | 15:48 |
| frobware | dimitern: nope, I take that back (wrong window). :) | 15:48 |
| katco | ericsnow: so you need work right now? | 15:48 |
| ericsnow | katco: yep, though right now I'm working on getting those two bug fixes landed | 15:49 |
| katco | ericsnow: ok, eta on that? | 15:50 |
| mup | Bug #1553320 changed: TestBootstrapGUIErrorInvalidVersion os.ProcessState exit status 2 <centos> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core embedded-gui:Fix Released by frankban> <https://launchpad.net/bugs/1553320> | 15:50 |
| mup | Bug #1553322 changed: TestBootstrapGUIErrorUnexpectedArchive os.ProcessState exit status 2 on centos <centos> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core embedded-gui:Fix Released by frankban> <https://launchpad.net/bugs/1553322> | 15:50 |
| ericsnow | katco: should be merging the first one in the next little while | 15:50 |
| katco | ericsnow: cool. next up should be the revisions of resources card... we should get together and point that and the new progress indicator work | 15:50 |
| katco | ericsnow: natefinch: let's plan on doing that when ericsnow is done landing the bug cards | 15:51 |
| ericsnow | katco: sounds good; I added tasks to that card last night in preparation :) | 15:51 |
| katco | ericsnow: tyvm | 15:52 |
| === dames is now known as thedac | ||
| natefinch | rogpeppe1: Is publish not returning a value anymore? | 16:02 |
| rogpeppe1 | natefinch: that's right | 16:02 |
| rogpeppe1 | natefinch: i *think* this is documented in the API docs | 16:03 |
| rogpeppe1 | natefinch: if not, they need updating | 16:03 |
| natefinch | rogpeppe1: ahh, ok, because all my tests are failing now | 16:03 |
| rogpeppe1 | natefinch: ah | 16:03 |
| rogpeppe1 | natefinch: we reckoned it probably wasn't telling you much useful, but if you can think of a decent reason why it should return something, we could change it | 16:04 |
| natefinch | rogpeppe1: see, if a wrapper library had updated, my code wouldn't compile right now ;) | 16:04 |
| rogpeppe1 | natefinch: :) | 16:04 |
| rogpeppe1 | natefinch: luckily your tests caught it | 16:04 |
| rogpeppe1 | natefinch: in our later APIs, we auto-generate the client | 16:05 |
| natefinch | rogpeppe1: my tests printed out 150 lines of logging and showed me a json error | 16:05 |
| natefinch | rogpeppe1: autogenerating a client sounds like a wonderful solution :) | 16:05 |
| rogpeppe1 | natefinch: you don't get the nice bulk API thing though | 16:06 |
| rogpeppe1 | natefinch: roll on HTTP2 :) | 16:06 |
| natefinch | rogpeppe1: so, why aren't we returning the ID of the published charm anymore? wouldn't that be useful? | 16:07 |
| rogpeppe1 | natefinch: because it's not a newly created id | 16:08 |
| rogpeppe1 | natefinch: so it's just like using any id in any request | 16:08 |
| rogpeppe1 | natefinch: for example, do you think a PUT to meta/extra-info should return the charm id | 16:09 |
| rogpeppe1 | ? | 16:09 |
| natefinch | rogpeppe1: oh, I guess I was still thinking that publish creates a new revision, but it doesn't, does it? It just moves an existing revision to a different channel | 16:10 |
| rogpeppe1 | natefinch: yeah. well, copies rather than moves. | 16:11 |
| natefinch | rogpeppe1: right, sorry, creates a pointer in that channel to that revision :) | 16:11 |
| rogpeppe1 | natefinch: exactly | 16:11 |
| rogpeppe1 | natefinch: call me a pedant :) | 16:11 |
| natefinch | rogpeppe1: it's good to be exact, so that there's no confusion | 16:15 |
| rogpeppe1 | natefinch: ok, don't call me a pedant then. see if i care. | 16:15 |
| natefinch | rogpeppe1: lol | 16:16 |
| natefinch | rogpeppe1: I assume I can delete params.PublishResponse, then? :) | 16:17 |
| rogpeppe1 | natefinch: indeed :) | 16:17 |
| === natefinch is now known as natefinch-lunch | ||
| voidspace | Up to an 1100 line diff and down to 28 test failures. | 16:39 |
| voidspace | Feels like hand to hand combat getting these to pass though. | 16:39 |
| frobware | dimitern: you still about? | 17:01 |
| mup | Bug #1557633 opened: status has duplicate entries for relationships <juju-core:New> <https://launchpad.net/bugs/1557633> | 17:05 |
| dimitern | frobware, yeah | 17:11 |
| perrito666 | could anyone kindly share theyr /etc/os-release with me? | 17:17 |
| cmars | perrito666, https://paste.ubuntu.com/15393493/ | 17:20 |
| perrito666 | cmars: tx | 17:20 |
| perrito666 | turns out installing kdeneon will break it :p | 17:21 |
| perrito666 | and that breaks the tests heavily | 17:21 |
| frobware | dimitern: have some time to HO on sapphire standup? | 17:22 |
| cmars | perrito666, if you have a moment, could i get a review, http://reviews.vapour.ws/r/4177/ ? | 17:25 |
| perrito666 | cmars: reviewing | 17:25 |
| cmars | perrito666, thanks! | 17:25 |
| perrito666 | actually please wait 5 mins to my eye drops to settle so I stop seeing fuzzy :p | 17:26 |
| dimitern | frobware, ok | 17:29 |
| === natefinch-lunch is now known as natefinch | ||
| ericsnow | katco, natefinch: now's probably a good time to point those cards | 17:52 |
| katco | ericsnow: ok moonstone? although i can't speak | 17:52 |
| natefinch | ok | 17:53 |
| natefinch | "ok, just speak if you disagree katherine... no? ok, great!" | 17:53 |
| mup | Bug #1557679 opened: help text for juju switch needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1557679> | 17:56 |
| perrito666 | someone could make a quick review? http://reviews.vapour.ws/r/4179/ | 18:01 |
| jam | cherylj: ping. Were you the one that added status information for pending instances? | 18:05 |
| perrito666 | jam: I helped, can I help you? | 18:07 |
| jam | perrito666: so I'm wanting to give progress during Bootstrap, and I was thinking that maybe we should have a progress func passed into StartInstance | 18:07 |
| jam | there is no API server to poll during bootstrap | 18:07 |
| jam | and providers shouldn't be directly allowed to know about the database | 18:08 |
| perrito666 | well iirc, we are passing a statuscallback function, so you could use that? | 18:08 |
| jam | perrito666: there it is. I just didn't see it, buried in the params struct. | 18:09 |
| perrito666 | :) | 18:09 |
| perrito666 | bonus track, you get the same for containers | 18:10 |
| jam | perrito666: yeah. what do you think about tying that StatusCallback into Bootstrap's context so you get the progress messages from "juju bootstrap" ? | 18:11 |
| perrito666 | I think its an awesome idea | 18:11 |
| perrito666 | as long as I am not the one implementing it :p | 18:11 |
| perrito666 | no, honestly, seems like a super short and easy way to get more visibility | 18:13 |
| jam | perrito666: heh. | 18:13 |
| jam | so I'm trying to understand what the data map is for | 18:13 |
| jam | It seems the only things that actually ever call StatusCallback are containers. | 18:13 |
| jam | lxc and kvm seem to use it | 18:14 |
| jam | but that seems to be it | 18:14 |
| jam | and they don't do anything with data | 18:14 |
| perrito666 | nah, I am pretty sure startinstance calls it too, every provider reports that status | 18:14 |
| perrito666 | jam: data structure is just to comply with StatusInfo | 18:14 |
| jam | perrito666: grep StatusCallback doesn't seem to agree | 18:15 |
| jam | perrito666: as in, the only things that reference ".StatusCallback" are the lxc and kvm brokers | 18:15 |
| jam | other thincgs get it passed in, but do nothing with it. | 18:16 |
| jam | it looks like the shape of the callback is just to match Machine.SetInstanceStatus which is ok | 18:16 |
| jam | but none of the other providers are giving feedback during StartInstance that I can see. | 18:16 |
| perrito666 | maas, is (should be) | 18:17 |
| perrito666 | lemme do a quick dig | 18:18 |
| perrito666 | jam: you are right, how could I miss that | 18:26 |
| perrito666 | mm something does not add up here | 18:27 |
| frobware | dimitern, voidspace, mgz: fix maas-spaces2 panic: http://reviews.vapour.ws/r/4180/ | 18:27 |
| perrito666 | jam: that should be implemented for maas only, it escapes a bit why is it not now | 18:28 |
| perrito666 | jam: I would like cherylj input here in case I am missing something | 18:29 |
| frobware | cherylj: ^^ | 18:30 |
| mgz | frobware: looks good. did you run the maas provider tests? | 18:31 |
| perrito666 | jam: in any case, fixing that should be as trivial as adding a few calls to the callback to startinstance | 18:32 |
| frobware | mgz: yep. the live one escaped me when I did the original merge, hence this panic. | 18:32 |
| frobware | mgz: I've run them post that commit | 18:32 |
| === tinwood is now known as tinwood-dinner | ||
| mgz | and the instance_test.go errors from that got fixed earlier | 18:35 |
| frobware | mgz: as in the same fix was applied previously? | 18:35 |
| mgz | as in, that borked rev has bad construction of maasInstance in tests but that's already fixed in maas-spaces2 | 18:36 |
| mgz | frobware: shipit | 18:36 |
| frobware | mgz: the diffs between original and maas-spaces2: http://pastebin.ubuntu.com/15394092/ | 18:38 |
| frobware | mgz: I don't recall seeing a bad construction in the original | 18:39 |
| mgz | frobware: yeah, that's fine | 18:39 |
| frobware | mgz: ok, thanks. going to merge and let's see if things are better throughout. | 18:40 |
| * natefinch is in dependendency hell | 18:44 | |
| natefinch | with an extra end just in case | 18:45 |
| katco | ericsnow: natefinch: fyi they're digging up the sidewalk again. if i drop out, that's why | 18:46 |
| ericsnow | katco: k | 18:46 |
| natefinch | katco: k | 18:47 |
| kwmonroe | could someone help me configure azure correctly for 2.0-beta2? i've followed this https://jujucharms.com/docs/devel/config-azure and created what i think are valid creds in my $JUJU_DATA/credentials.yaml (app-id, app-password, sub-id, tenant-id), but bootstrapping gets me this: http://paste.ubuntu.com/15394344/ | 19:01 |
| kwmonroe | i don't have anything in clouds.yaml that describes azure at all. do i need that with some config for the virtual network? | 19:02 |
| rick_h__ | kwmonroe: sure thing, the release notes leads you down a long path for the username/password version | 19:03 |
| rick_h__ | kwmonroe: are you using the user/pass or the key file? | 19:03 |
| perrito666 | kwmonroe: that might be a bug you just found, perhaps that viertual netwrok already? | 19:03 |
| kwmonroe | rick_h__: i'm auth-type: userpass | 19:03 |
| kwmonroe | perrito666: i'll check if i can navigate the azure portal to look for pre-existing virt networks. | 19:04 |
| kwmonroe | rick_h__: the release notes said this "To use the new Azure support, you need the following configuration in environments.yaml", but i didn't find an env.yaml to modify, so i wasn't sure if/where those opts should go. | 19:05 |
| kwmonroe | clouds.yaml? | 19:05 |
| rick_h__ | kwmonroe: sorry, there's a section on the new arm provider in there and this needs to go into credentials.yaml | 19:06 |
| rick_h__ | kwmonroe: clouds.yaml is just the api endpoints/regions/cloud data that you can reuse with many credentials/etc | 19:06 |
| kwmonroe | ahhh, roger that | 19:06 |
| rick_h__ | kwmonroe: sent you a PM with step by step | 19:06 |
| rick_h__ | kwmonroe: I got those steps from the release notes on the new ARM provider in 2.0 | 19:06 |
| kwmonroe | gracias rick_h__! | 19:06 |
| natefinch | If I set dependencies so charmstore-client tests pass, then charmrepo tests fail (which charmstore-client relies on). | 19:08 |
| katco | ericsnow: merge is up: http://reviews.vapour.ws/r/4181/ | 19:15 |
| ericsnow | katco: thanks | 19:15 |
| katco | ericsnow: pay special attention to cmd/juju/charmcmd/store.go | 19:15 |
| === tinwood-dinner is now known as tinwood | ||
| mup | Bug #1557714 opened: "juju status-history" doesn't work correctly <cli> <juju-core:Triaged> <https://launchpad.net/bugs/1557714> | 19:20 |
| voidspace | frobware: ah, oops | 19:25 |
| voidspace | frobware: LGTM | 19:25 |
| voidspace | I'm EOD | 19:25 |
| perrito666 | ok, does anyone have experience with autoload-credentials? | 19:33 |
| * perrito666 eyes at rick_h__ | 19:33 | |
| rick_h__ | perrito666: I spec'd it, not really experience with it. What's up? | 19:37 |
| perrito666 | well I want to add an openstack from my novarc | 19:38 |
| perrito666 | I run it | 19:38 |
| perrito666 | it asks me for a cloud, I have no cloud to add those credentials to | 19:38 |
| perrito666 | I try to add cloud, it asks me for a cloud.yaml | 19:38 |
| perrito666 | kind of defeats the purpose | 19:38 |
| rick_h__ | perrito666: so cloud != credential | 19:38 |
| rick_h__ | perrito666: cloud = api endpoint and metadata | 19:38 |
| rick_h__ | perrito666: so you have to add the cloud, and then when you autoload-credential it'll be attached to that cloud | 19:39 |
| rick_h__ | perrito666: imagine you've got multiple openstacks, prodstack, canonistack, serverstack... | 19:39 |
| perrito666 | oh I would have expected the add-cloud part to be wizardy too | 19:39 |
| rick_h__ | perrito666: no, there will be some cli prompting in the future | 19:39 |
| rick_h__ | perrito666: but for now, it's "pass me some yaml looking info I can use to ping that clooud" | 19:39 |
| perrito666 | or even more inteligent, autoload to just make me the proper questions to create the cloud | 19:39 |
| rick_h__ | perrito666: one day | 19:40 |
| jam | perrito666: http://reviews.vapour.ws/r/4182/ | 19:40 |
| jam | if you're interested | 19:40 |
| perrito666 | jam: I definitely am, reviewing | 19:41 |
| perrito666 | I also am OCR so not a chance to skip it :p | 19:41 |
| jam | perrito666: having actual progress information when bootstrapping lxd is pretty darn nice | 19:41 |
| jam | rather than it just hanging for 5 minutes and you're wondering WTF is going on. | 19:42 |
| perrito666 | it is, I dont know dubai, but in south america is really useful :p | 19:42 |
| jam | ye old "juju bootstrap local" problem. | 19:42 |
| kwmonroe | rick_h__: perrito666: looks like i missed "azure provider register Microsoft.Network" first time around.. all looks good now. thanks!! | 19:47 |
| perrito666 | kwmonroe: great to hear that | 19:48 |
| rick_h__ | kwmonroe: awesome, if there's suggestions to the docs to clear it up please let us know | 19:48 |
| kwmonroe | will do rick_h__ | 19:48 |
| perrito666 | jam: got reviewed | 19:54 |
| jam | thx perrito666 | 19:54 |
| perrito666 | jam: definitely in need of testing | 19:54 |
| perrito666 | but nothing that cant wait to after beta3 | 19:55 |
| jam | agreed. this was mostly about proof-of-concept, but I wanted to get that pushed up to make sure it was going in a good direction | 19:55 |
| jam | thanks for the StatusCallback pointer. | 19:55 |
| perrito666 | jam: we are even, I saw you fixed a couple of typos I introduced | 19:57 |
| katco | ericsnow: natefinch: do we need to do a standup? is wallyworld coming to the earlier (for him) time? | 20:12 |
| ericsnow | katco: not sure what his specific plans are | 20:12 |
| katco | ericsnow: natefinch: well, we already kind of did a standup earlier, so only reason is to catch him up | 20:13 |
| ericsnow | katco: as far as I'm concerned we got everything covered standup-wise | 20:13 |
| natefinch | katco, ericsnow: ditto | 20:13 |
| katco | ericsnow: natefinch: agree.. ok then i've hit my limit i need to go lay down | 20:13 |
| ericsnow | katco: hope you feel better | 20:13 |
| katco | ericsnow: ty | 20:13 |
| natefinch | ericsnow: I have a small PR I need reviewed before I can land the bigger PR for adding --resources to publish: https://github.com/juju/charmrepo/pull/72 | 20:14 |
| ericsnow | natefinch: I'll take a look | 20:14 |
| natefinch | katco: btw, figured out the rpoblems I was having, just dependency issues | 20:14 |
| mup | Bug #1557726 opened: Restore fails on some openstacks <backup-restore> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1557726> | 20:15 |
| natefinch | ericsnow: I'm reviewing your deploy w/ revisions review | 20:15 |
| ericsnow | natefinch: LGTM; you still need one from the UI team, no? | 20:16 |
| natefinch | ericsnow: probably | 20:23 |
| natefinch | ericsnow: when you get an hour, this is good, and I think you'll like it: https://vimeo.com/80533536 | 20:37 |
| ericsnow | natefinch: cool; I'll take a look | 20:38 |
| === natefinch is now known as natefinch-afk | ||
| ericsnow | katco: FYI, I've finished reviewing your merge-from-master patch | 20:56 |
| mup | Bug #1557747 opened: [LXD provider] Trusty container is used by default on Xenial host <docteam> <juju-core:New> <https://launchpad.net/bugs/1557747> | 20:57 |
| menn0 | davecheney: review please: http://reviews.vapour.ws/r/4183/ | 21:02 |
| cmars | menn0, quick review please? http://reviews.vapour.ws/r/4184/ | 21:59 |
| menn0 | cmars: will do | 22:02 |
| cmars | menn0, thanks | 22:02 |
| menn0 | davecheney: thanks for that review. here's the next one (small): http://reviews.vapour.ws/r/4185/diff/ | 22:03 |
| menn0 | cmars: ship it | 22:04 |
| roryschramm | is it possible to specify a custom apt repository when juju deploys an app to an lxc container? ie the lxc container will use http://myrepo/ubuntu in /etc/apt/sources.list | 22:08 |
| mup | Bug #1557769 opened: private-address returns name, not ip, under 1.25.4 <juju-core:New> <https://launchpad.net/bugs/1557769> | 22:18 |
| menn0 | davecheney: just responded to your review comments for http://reviews.vapour.ws/r/4185/ | 22:29 |
| menn0 | davecheney: I think you're missing what that type assertion is doing | 22:33 |
| menn0 | davecheney: it's pretty awful | 22:33 |
| menn0 | davecheney: it's taking very limited interface and with the knowledge that the thing underneath is actually a *state.State is converting it | 22:33 |
| menn0 | davecheney: saying it out loud, I really don't like the way it's done :) | 22:37 |
| menn0 | davecheney: I'll try a different approach | 22:37 |
| davecheney | i don't understand why the interface value passed into the method cannot be used | 22:41 |
| davecheney | is it the wrong type ? | 22:41 |
| menn0 | davecheney: basically yes. | 22:41 |
| menn0 | davecheney: migration.ExportModel requires a *state.State, not the Backend interface | 22:41 |
| menn0 | davecheney: I'm trying to avoid requiring the use of *state.State in the tests | 22:42 |
| davecheney | why can't you use an interface | 22:42 |
| menn0 | davecheney: I'm changing ExportModel to take an interface | 22:42 |
| davecheney | you just want the behvaiour | 22:42 |
| menn0 | davecheney: easier said than done when you have a monster like state.State | 22:43 |
| menn0 | davecheney: but for export it's actually doable | 22:43 |
| davecheney | how many methods does it expect ? | 22:44 |
| menn0 | davecheney: in this case 1 | 22:44 |
| menn0 | davecheney: for import 10's if not 100's (the tests use StateSuite there) | 22:45 |
| menn0 | davecheney: actually I lie, it's not too bad for import eithger | 22:45 |
| menn0 | davecheney: let me fix this | 22:45 |
| davecheney | menn0: cherylj bogdanteleaga https://github.com/juju/juju/pull/4749 | 23:01 |
| wallyworld | axw: let me know when you've got a moment so i can chat about the schema stuff | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!