[00:43] hatch: cool, yea and we might have links from readme's and such that should work. Thanks for dbl checking/updating [02:25] rick_h_: new (better) fix proposed....much simpler ;) [02:35] hatch: cool, will look in a bit. link me please [02:35] https://codereview.appspot.com/21430043/ [02:36] I'm at a conference tomorrow and Tuesday but I'll try and pop in if I have some downtime tomorrow to land it [02:37] hatch: no tests? comments on why replacing the cs:? [02:37] impossible to test [02:37] at least in js [02:37] at least verify that the urls output are fully qualitifed [02:37] ? [02:37] like the ones in the href? [02:37] something has to be accessing or testing this serviceUpgradeLi [02:38] ? [02:38] hmm [02:39] ahh looks like I might be able to stick a small assertion in the upgrade tests [02:42] hatch: +1 [02:43] I can't believe that this bug in YUI hasn't been reported yet [02:44] that just seems to me like a common thing haha [02:48] rick_h_: ok I don't have enough time to get these tests done right now - but you can review/qa with a lgtm pending the tests if you lik [02:49] e === jamie___ is now known as Guest9680 === jamie___ is now known as Guest75798 [12:33] hi evilnickveitch [12:43] benji: bac I got a nice failure to land with what looks like some sort of lxc/python path error. Anything look obvious to you guys? [12:43] rick_h_: paste? [12:43] bac: sorry, meant to have the link in there http://162.213.35.27:8080/job/charmworld-autoland-lxc/54/console [12:45] that's a strange one; my first guess would be to look for recent Makefile changes in which someone fiddled with the PWD [12:45] oh, /me missed that change === gary_poster|away is now known as gary_poster [12:50] hey alejandraobregon, Thursday jaas meeting doesn't work for me. half hour later? [12:59] rick_h_: I'm not saying there was a recent change like that, I'm saying that looking for such a change would be the first thing I would do. [12:59] benji: yea, hunted and found nadda [12:59] k [12:59] benji: are you suggesting the change is in charmworld or the lander? [13:00] bac: managed to land just ahead of me by hours. So maybe something in my branch is the issue but not seeing [13:00] bac: charmworld [13:00] I would also suspect a dirty lander (sans evidence). [13:00] I'm working on a branch of docs for all the api changes made and will try to get that reviewed/landed before abentley arrives to bug [13:00] Unfortunately we keep a dirty checkout around forever instead of getting a fresh one every time [13:00] if that lands then I know it's my branch, if not, then it must be the lander/lxc stuff [13:01] sounds good [13:05] thanks benji. Should I go so far as to suggest that they run make devel & :-) [13:06] marcoceppi: i working on incorporating bundle proofing into the ingest job. i'd thought charmtoolsv1.1.0 on pypi would have the bundles work but it doesn't. do you plan a release soonish? [13:06] s/i work/i'm work/ [13:06] gary_poster: closing the terminal would still kill it; they could run "nohup make devel" [13:06] ah ok [13:07] bac: it doesn't? It should. jcastro was using it on friday [13:07] bac: uh, it should [13:07] bac: make sure you're using charm-tools [13:07] not charmtools [13:07] * bac looks [13:08] * marcoceppi spins up a clean vm to test [13:13] marcoceppi: did you not sdist upload the package? https://pypi.python.org/pypi/charm-tools/1.1.0 [13:14] rick_h_: I'm pretty sure I did [13:14] marcoceppi: there's no download there [13:14] rick_h_: right, I see that now [13:16] pypi is a whole new world for me [13:17] marcoceppi: cool, happy to help if you need anything. Once you get logged in and registered the project normally a python setup.py sdist upload [13:17] is all you need [13:17] rick_h_: ah, never ran the upload [13:17] I did the publish though [13:17] figured that did it [13:18] thanks rick_h_ & marcoceppi. i'm set now. [13:18] bac: cool [13:18] rick_h_: upload: [13:18] python setup.py upload [13:18] running upload [13:18] error: No dist file created in earlier command [13:18] marcoceppi: yea, can you see if it'll let you switch your branch back to 1.1.0 and do an sdist upload? [13:19] marcoceppi: yea, you need sdist and upload [13:19] "make this sdist and upload it" [13:19] rick_h_: I did an sdist :\ [13:19] python setup.py sdist upload [13:19] marcoceppi: adding the steps to a hacking doc would be great! [13:19] oh [13:19] uploadede [13:20] bac: what hacking doc ;) [13:20] marcoceppi: awesome, there we go. Pretty readme and all there [13:20] rick_h_: lame, no markdown support === rogpeppe1 is now known as rogpeppe [13:20] bac: cool, let me know if there's anything else we need to help. We'll have to check any deps that aren't updated/part of the download cache as it installs [13:20] marcoceppi: yea, python is a rst world man [13:21] rick_h_: mega lame [13:21] :P [13:21] anyways, that readme is out of date now that I read it [13:21] should probably update it [13:21] time for a 1.1.1 release! :) [13:23] rick_h_: ehhhhhhhh, I think it can wait for 1.2 [13:23] I hate patch releases [13:23] marcoceppi: docs is backward compat :) [13:23] but cool [13:23] marcoceppi: were you referring to this: https://pastebin.canonical.com/99786/ [13:23] rick_h_: https://bugs.launchpad.net/charm-tools/+bug/1247839 [13:23] <_mup_> Bug #1247839: README is out of date. Should also provide plaintext and RST version [13:24] bac: that looks like a missing dep in the package [13:24] damnit. Now I have to patch release [13:25] could have sworn I had markdown in there [13:25] marcoceppi: locked version numbers too please :) [13:25] yeah, it's in the setup.py [13:25] * marcoceppi is installing in vm [13:25] marcoceppi: right, but they're not locked to a version number [13:26] rick_h_: so? [13:26] I mean that shouldn't stop it from installing [13:26] bac: so this is what I mean on the deps. We need to download those and get them into the download cache. Any we don't already have in there [13:26] rick_h_: bah, this is actually making me like debian packaging [13:26] marcoceppi: right, this is because of prodstack. We can't hit the interwebs due to egress filtering. So we keep a download-cache of the packages needed and we version lock them to keep pip from going and fetching [13:26] marcoceppi: paramiko too [13:26] rick_h_: why not just add the ppa? [13:26] bac: right, those are new deps [13:26] it's packaged in the ppa [13:27] marcoceppi: we can't hit LP either [13:27] prodstack should be able to, wtf! [13:27] bahhhhhhhhhhhhhhh [13:27] marcoceppi: hmm, does a ppa count as LP? [13:27] rick_h_: check with #is [13:27] marcoceppi: looking to see if we pull a ppa already. Thought we might have. [13:27] rick_h_: ok, so i needed markdown paramiko and cheetah [13:28] marcoceppi: yea, we do add a ppa. We just can't pull LP branches down in prodstack [13:28] rick_h_ bac I recommend the package then [13:28] pypi is just a stop gap for brew stuff [13:28] ok [13:28] bac: looks like it. [13:29] bac: but if ingest runs off our virtualenv it'll break [13:29] bac: so hold on a sec, looking [13:30] rick_h_: is there an easy way to just say like "yo dawg, tell me what versions pip just dl'd" so I can add it to easy_install? [13:32] marcoceppi: I've got a script that would fetching locked versions of things from a requirements.txt and build a download-cache. Normally I'd install your package, then pip freeze > requirements.txt and get the versions/etc [13:32] bac: I guess it looks like ingest doesn't run from the virtualenv that I can tell so I guess the package from the ppa might work [13:33] rick_h_: so I should move the requirements out of setup.py and in to requirements.txt? [13:33] marcoceppi: no, not for a library like this. Just saying normally you can generate it from a clean virtualenv with the package + deps installed [13:35] I'll let you guys figure out what's needed. Just let me know if/what you need me to change [13:35] marcoceppi: thanks, uploading the pacakge was helpful [13:35] marcoceppi: is there a ppa with a released version of charm-tools? [13:36] bac: ppa:juju/stable [13:36] ah, great [13:36] marcoceppi: the LP landing page has sudo add-apt-repository ppa:juju/pkgs [13:36] https://launchpad.net/charm-tools [13:36] rick_h_: thanks [13:36] marcoceppi: is that still valid? [13:36] rick_h_: no [13:37] rick_h_: updated [13:37] marcoceppi: thanks [13:37] rick_h_: still trying to get this project up-to-date [13:38] marcoceppi: we, your users, are here to help :) [13:38] appeciate it [13:41] rick_h_: so you agree on moving charm-tools to SYSTEM_DEPS in the Makefile and install from ppa? [13:41] bac: sounds like a plan to me if that works. [13:41] we'll lose version locking... [13:41] bac: otherwise we'll have to manage his deps in the download-cache [13:43] bac: ugh, yea. I mean we want to keep up to date, but managing things on several different versions would suck (when would be apt-get update/upgrade prodstack?) [13:43] rick_h_: but we can only hope things moved to juju/stable are, you know, stable [13:43] gary_poster: you might be interested that Maarten Ectors is using comingsoon in cold-call emails. We might want something more stable than that. [13:44] benji, I know about that, thanks :-). [13:44] k [13:44] benji: is he cold-calling you? :) [13:44] bac: right, but there's been what, 3 new releases this past month of juju? And so prodstack would be stuck at the one at deploy time, unless we make sysdeps on every deploy to charmworld? [13:44] bac: yes! he's trying to sell me leaf guards for my gutters [13:45] i hope he's got a better price than Chimneys Plus [13:45] * bac is now worried about his clogged gutters 1500 miles away [13:48] bac: rick_h_: I subscribe to semantic versioning and do test backwards compat. Minor releases should not break and I have no plans for a 2.0 release at this time [13:50] * marcoceppi introduces the "im only human" caveat though ;) [13:55] rick_h_: got a sec to chat? [13:55] bac: sure thing [13:56] bac, proof integration going smoothly? rick_h_ , +1 on getting the quicksearch deploy button out the door via the cache fix, thank you. benji, bac, rick_h_, after those, getting "Add key to charmworld API linking to deployer file URL (see description)" in quickly would be fabulous; let me know if you can start that and I'd like to have a pre-imp discussion [13:57] k [14:00] benji, do you remember james troup saying that getting encryption on postgres would be...much easier? trivial? I am about to ask on #webops but wanted to see if you remembered that part of the conversation [14:00] (benji, 'cause I'm going to suggest "hey, postgres is fine" if so :-) ) [14:01] gary_poster: he said that they were doing it at the filesystem level, that's what made it easy; I don't recall him stating a difference between postgres and mongodb [14:02] benji, ok, thanks. You saw jjo's RT reply, right? My understanding from that is that he considered it to be a big job. [14:02] I'll go talk on #webops [14:03] gary_poster: I saw it but didn't pay much attention. I wonder if he knows we meant "deploy it on an encrypted FS" vs. "add encryption to mongodb" [14:03] benji, it looks like he understands to me [14:04] the expensive tasks are peripheral but reasonable [14:04] gary_poster: send james after him [14:05] PG would be OK I guess, but it means adding another technology to the system [14:05] :-) [14:05] yeah I know. [14:05] I still am in favor of something in front of it that only gives us the API we need [14:06] gary_poster: heh, a little roughly, but moving forward. [14:06] gary_poster: yea, having a landing problem with my proof stuff so trying to do a docs branch to test if the issue is my branch or the lander until abentley is around [14:07] rick_h_: hi. [14:07] oh, abentley is around, morning. Can I still some time when you have a sec? [14:07] rick_h_: Sure. Haven't really got started yet. What's up? [14:07] rick_h_, ah ok. so you are blocked on that; bac can make progress on the integration; but we don't know when we can land. Is the integration looking theoretically landable today? tomorrow? [14:08] abentley: http://162.213.35.27:8080/job/charmworld-autoland-lxc/54/console is failing in a really strange way on pip install and python path issues. I've started a docs branch I'll try to land to try to tell if it's something my code introduces or a lander issue, but curious about your thoughts. [14:08] gary_poster: yeah, I wouldn't change our proposed architechure [14:08] cool benji [14:08] rick_h_: looking... [14:09] benji, I think you and I are talking about differnt things, maybe though. we definitely need two pieces of software in front of the firewall and a DB behind the firewall. I am talking about the DB behind the firewall that abstracts the DB operations only [14:09] I mean software behind the firewall [14:11] gary_poster: right (I assumed there was some suggestion to change the software behind the firewall because PG has all kinds of security/mediation features) [14:12] rick_h_: I've never seen anything like that before. I guess the virtualenv is borked? Maybe you should just delete the workspace and try again. [14:12] abentley: can I log into it? Just SSO? [14:12] oh ok cool, yay for being on same page :-) ,. Looks like Mongo is AOK with them though. they think it is 1 IS engineer 1 week, roughly, to do all the various bits described, which sounds reasonable to me [14:13] benji ^^ [14:13] rick_h_: No, you have to log in as "admin" with the password specified in the juju config. [14:14] abentley: ah, ok. [14:15] k [14:23] bah, my offlineimap hung up. No wonder email seemed quiet this morning === matsubara is now known as matsubara-lunch [14:59] rick_h_, congratulations on successfully convincing the landing bot of your worthiness :-) [15:02] gary_poster: yea, thankfully abentley applied a giant hammer of doom to it [15:02] hello all [15:02] lol cool [15:02] hey hatch [15:02] oops I forgot to mute my laptop [15:02] that was embarrassing [15:02] lmao [15:02] haha [15:03] hotel wifi here is so bad that I had to hotspot [15:03] lol [15:04] on the train sound [15:16] benji: bac either of you have time for an api docs update sometime? https://codereview.appspot.com/18600046 [15:17] rick_h_: I don't at the moment. [15:17] benji: k, thanks. [15:17] rick_h_: soon [15:18] bac: cool, no rush. The landing issue is fixed so this is pure docs for some point in time [15:22] rick_h_: done [15:22] bac: thanks [15:37] rick_h_: what was the landing issue? [15:37] benji: the workspace got corrupt in some way. I was going to bring it up on the call [15:38] * benji recruits rick_h_ into the clean builds for CI cabal [15:38] :) === jamie___ is now known as Guest25217 [15:39] benji: ftr I'm a fan of both ends. Prodstack isn't a clean env so we need to know on that end as well. So clean + upgrade-ish [15:39] benji, we are off the hook for now in #webops? [15:39] LP bug? [15:40] gary_poster: I think it is at least partially a LP bug. There is the open question of how CW is able to actually check out the branches in question. [15:40] gary_poster: There is at least enough fog of war that we can demote it to non-emergent status. [15:40] benji, heh ok [15:41] I'll tell the webops such so we don't violate their expectations. [15:41] thanks benji. [15:41] np [15:42] benji, bac, rick_h_ unrelated question for you . If I look at https://manage.jujucharms.com/api/3/bundle/~benji/wiki/wiki/ , it says, near the bottom, "id": "~benji/wiki/5/wiki". AFAICT, that [15:42] 's a bug [15:43] it should be ~benji/bundle/wiki/5/wiki [15:44] (at which point we could simply tack on a "json" at the end to get the deployer file, and we wouldn't need a "deployer_file_url" added to the data) [15:44] gary_poster: hmm, no, that's the id you use in the charm as the bundle-id. api/3/bundle/~benji/wiki/5wiki/ [15:44] rick_h_, ah ok [15:44] gary_poster: the deployer file original json thing is why I'm not a fan. It's a special user facing url that's been created to send the json back [15:44] gary_poster: and doesn't follow the same rules as apis [15:44] rick_h_, but it does follow rules of charmworld page [15:44] rick_h_, which is my concern about the id [15:45] gary_poster: right, I think there's a bug in there, but that id is "correct" [15:45] because I think the charm id does correspond to the charmworld user visible page [15:45] :-/ [15:45] gary_poster: it just doesn't match the json url expectations which is probably more the bug [15:45] rick_h_, but do you follow that it also does not follow the https://manage.jujucharms.com/~benji/bundle/wiki/5/wiki expectation? [15:45] IOW... [15:46] gary_poster: hmmm, yea. That's based off the branch you push to? since you could have ~user/charms and ~user/bundle? [15:46] * benji regrets posting a bundle whos URL will make his IRC client beep [15:46] rick_h_, a charm id is the charmworld user visible url [15:46] so [15:46] precise/haproxy-21 [15:46] becomes https://manage.jujucharms.com/precise/haproxy-21 [15:46] and works [15:47] a bundle id does not have that characteristic [15:47] gary_poster: right, so the bundle urls weren't done in a way to follow suit. I'd argue they should be /bundle/~hatch... with the $id being everything afgter /bundle [15:48] the world "bundle" isn't part of any bundle id and I'd hate to see it become part of it [15:48] rick_h_, I would buy that. Pretty late in the game though. :-/ [15:49] rick_h_, that's a small routing change with big test ramifications, yeah? [15:49] rick_h_, but if we did that then simply adding json after the url ought to work [15:49] gary_poster: not sure? I'm not aware of why we can't change the routing to be bundle/~id vs ~user/bundle/..rest-of-id [15:50] well it is not bundle/~id but bundle/id, for promulgated charms--do we have any of those yet? [15:50] jujugui call in10 [15:50] :-) [15:50] thanks [15:50] * Makyo whew, made it! [15:50] bah I meant promulgated bundles [15:50] gary_poster: not sure on promulgated bundles. There was all that controversy around policy on those last week [15:50] can someone confirm a bug in charmworld/the review queue for me? [15:51] marcoceppi: maybe, crazy day. What's up? [15:51] http://manage.jujucharms.com/tools/review-queue proof error on appflower is still listed, but it doesn't have anything wrong in it's proof output. Does that list ever get re-generated or was it a one time thing? [15:52] marcoceppi: not sure, that seems strange with all the N/A and such. Maybe jcsackett has an idea what's up there? [15:52] * gary_poster changes computers/locations [15:53] marcoceppi: I'm not up on the review queue, but it seems have N/A on those would be bad and needs attention. Would take some chasing down to figure out wtf. I say file a bug and we'll see what we can figure out [15:53] thanks === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [15:59] jujugui call in 1 [16:02] bac, hi [16:02] hi evilnickveitch, otp right now [16:02] you be around in 20 min? [16:02] ok [16:03] bac, yes indeed [16:04] hey rick_h_ [16:04] have you tried to deploy any of my bundles? [16:05] I can only get bootstrap up and the GUI [16:05] then it exits saying it's deploying the other services, but they actually don't fire up [16:05] jcastro: no, on call atm but haven't tried them out [16:05] bcsaller was investigating it on friday, but I just want to confirm if other people are firing things up with qauickstart and it all works [16:05] ok [16:10] marcoceppi, rick_h_: it should update with every proof run on ingest; if there are no errors, and it's in the queue, that's def a bug. [16:10] jcsackett: what's with all the N/A in there? [16:10] jcsackett: cool, I'll open a bug [16:10] N/A means no date. [16:10] those are in the date fields. [16:10] things like proof errors don't have dates, as we can't tell the first time a proof error existed, only that it exists now. [16:11] so merge proposals, bugs, askubuntu questions &c have dates; proof errors, store errors, missing qa data don't. [16:17] Learning a lot about Azure stuff [16:17] no bash scripting [16:17] lol [16:18] jcastro: what bundles are failing? Hit me up witht he url please [16:23] jcastro: we need to test if they can be dragged/dropped into the gui in a real env or not. To tell if it's a quickstart bug or something bigger [16:28] jcsackett: https://bugs.launchpad.net/charmworld/+bug/1247891 [16:28] <_mup_> Bug #1247891: Proof list in review-queue does not get updated [16:30] alejandraobregon, where are we meeting for jaas thing? [16:31] luca__, ^^ [16:31] gary_poster: heya [16:31] hey [16:31] gary_poster: can we use gui chat? [16:31] luca__, gui chat has died because google did not like us, but we can use [16:32] luca__, mm, nm :-) why don't you all start a hangout [16:32] or I can [16:32] adding it to calendar is easiest [16:32] gary_poster: go ahead :) [16:32] oh ok [16:32] gary_poster: Ale isn't here at the moment [16:32] gary_poster: so she can't add it [16:32] gary_poster: She'll be joining in 2 mins [16:33] luca__, no video from me but https://plus.google.com/hangouts/_/76cpjflh89tfksavch1qeigoj8?hl=en [16:46] rick_h_, http://manage.jujucharms.com/~jorge/bundle/wordpress/wordpress-simple [16:46] any of the ones I pushed === matsubara-lunch is now known as matsubara [16:46] jcastro: cool, but I know some worked some didn't so thanks for the sample. I'll try to see if it works via the gui on aws [16:49] hi marcoceppi, i'm trying to run the charm-tool test suite and i 1) get a failure and 2) don't see the test_proof.py suite being run. [16:50] bac: how are you trying to run the test suite? [16:50] I don't know if I include the tests in the package (or if I was supposed to) [16:52] marcoceppi: i've checked out a branch and ran 'make check [16:52] bac: that should work, I constantly run the tests here [16:53] yeah, they pass here [16:53] marcoceppi: it fails with http://paste.ubuntu.com/6359716/ [16:54] bac: hum [16:55] marcoceppi: also can you verify test_proof.py is being run. it doesn't look like it is and it fails due to code reorg if i run it by hand (% tests/proof/test_proof.py) [16:55] bac: doesn't look like it's being run [16:55] marcoceppi: unfortunately i've got to be afk now for an hour or so. [16:56] bac: that's fine, I've never liked the actual testing structure. I had plans to re-write it all in python unit tests but haven't gotte around to it [16:56] bac: test_proof will fail spectacularly because of the bundles re-org [16:57] yep [16:58] bac: I'll make sure it works again with re-org, not sure why your proof is failing. It looks like it's failing to make the metadata.yaml file, do you have python-markdown installed? [17:03] gary_poster: In the simulator I can't see machine restart and security updates in the inspector, do you know why? [17:04] luca__, not off hand. will look [17:07] rick_h_, do you know anything by chance? Confirmed & investigating ^^^ [17:07] gary_poster: I thought that the simulator didn't simulate landscape stuff? [17:07] rick_h_, it does [17:08] gary_poster: I remember that question coming up at the table during sprints and not sure what came of it [17:08] ok cool [17:10] gary_poster: I submitted a bug for it [17:10] thanks luca__ [17:11] gary_poster: I think potentially this could be a problem from removing that bottom bar [17:11] luca__, that's what I'm thinking as well. no smoking gun yet though [17:11] gary_poster: because the simulator shows the notifications in jujucharms.com [17:11] gary_poster: but not coming soon [17:11] luca__, sure; jujucharms is pretty old code now though :-P [17:11] gary_poster: ah [17:14] I have to run. biab [17:42] cursed npm...ugh [17:49] marcoceppi: i do [17:49] marcoceppi: i mean, yes i do have python-markdown [17:50] bac: I can't seem to replicate that failure :\ [17:50] marcoceppi: the recent re-org makes proof not very friendly to be used as a lib. i'm going to make a small patch and propose it. if you agree with the change could you make a 1.1.1 very quickly? [17:51] bac: yeah, I can roll a patch quickly [17:51] bac: make sure you propose against lp:~charmers/charm-toosl/1.0 [17:51] err [17:51] bac: make sure you propose against lp:~charmers/charm-toosl/1.1 [17:51] ok [17:59] gah, this is why we need to have a true offline npm cache. 20s requests if it completes at all and a cache does me no good when doing a charm rebuild because you changed the source branch. [18:07] marcoceppi: here is the merge proposal: https://code.launchpad.net/~bac/charm-tools/proof-lib/+merge/193829 [18:08] bac: this LGTM, let me test but I can cut a 1.1.1 within the hour (depending on lp builds) [18:08] marcoceppi: perfect [18:10] I'll take this opportunity to slide in a few other small changes [18:19] grabbing coffee, brb. gary_poster landed the removing of the feature flag. Upon closer inspection it's how it works normally when you hit the deploy button. There's things to make nicer there, but it's all in the inspector itself. [18:23] bac: are you on a windows machine? [18:26] rick_h_, ok cool [18:28] * benji fights with rv-submit [18:35] rick_h_, did you get the bundle to work? [18:37] jcastro: no, having lxc issues and npm is hating me to test it on aws [18:37] jcastro: so not been able to test it so far, hoping npm comes to its senses [18:44] * benji figures out rv-submit [18:44] bac: 1.1.1 submitted to the PPA, uploaded to pypi [18:49] marcoceppi, bac does some of his work on OS X. Not windows. [18:49] and on his behalf, thank you :-) [18:50] np! Happy you guys are using the product :) [18:51] :-) [18:53] * benji lunches [18:54] marcoceppi: no, i am running on a saucy vm [18:54] bac: I was trying to figure out why your merge request removed +x on the proof file [18:55] huh, i didn't do that intentionally [18:55] I figured, so I assumed it was a system level thing [19:32] * benji is back from lunch [19:44] benji: gary_poster any ideas on what to name this url to the bundle json in the bundle response? we've got permanent url as the bundle: url. This is deployer_json_contents or something? [19:45] rick_h_, thought 1: deployer_file_url ? thought 2: if the id is correct, you could argue that we don't need this, but I agree it is nice. [19:46] gary_poster: yea, I mean we could hard code the gui building the url but prefer to have mjc generate it and send it over the wire and keep the gui stupid about it [19:46] +1 on stupid [19:47] ack rick_h_ . If it is only "add /json to id" I think it is not too bad, but as I said, I agree it is nice [19:47] gary_poster: hmmm, https://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki/file/bundles.yaml is the file url. [19:48] gary_poster: oh hmm, is that /json the bundle or the basket /me goes to dbl check [19:48] rick_h_, no, that's the basket, or it better be :-) [19:49] btw, the landscape issue is a bug in simulator, but fixing it exposes a bug in landscape-in-inspector changes [19:50] gary_poster: wheee [19:50] :-) [19:50] benji: the way I'm reading this that url is just the json for that bundle. Does that sound right? [19:51] * benji looks [19:51] that's the file from the branch [19:51] or should be [19:51] gary_poster: right, but in this view it's generating a dict and then json'ing it back. No basket in there. [19:52] rick_h_, that's yaml [19:52] gary_poster: so that url manage/bundle/~bac/xxx/yyy is just the bundle requested. Not a deployer file [19:52] gary_poster: so for instance, that'll never have a series in it from what I can tell [19:52] :/ [19:53] rick_h_: that is a deployer file for the bundle in question; there are no basket files ("basket file" doesn't make sense in the current model of running inheritence at ingest time and storing bundles outside of baskets) [19:53] marcoceppi: darn, i've spotted some more problems. i see sys.exit is being called a few places, both inside the proof method and in BundleLinter. those will need to be excised and just return the appropriate error. [19:53] benji, a basket file is conceptually an unprocessed deployer file--the deployer file from the branch [19:53] agreed I'm making that name up [19:54] benji: ok, I guess. It's a new deployer file than what went in. Does series get flattened somehow then? since that's in the outer file? [19:54] bac: bah, 1.1.2 it is then [19:54] gary_poster: sure, "conceptually", "for reals" we don't treat them as first-class entities and don't expose them [19:54] bac: I may have split the proof file a little too hastily [19:54] benji +1 [19:54] bac: can you open a bug while I patch? [19:54] marcoceppi: sure [19:58] marcoceppi: bug 1247951 filed [19:58] <_mup_> Bug #1247951: proof calls sys.exit