[00:43] <rick_h_> hatch: cool, yea and we might have links from readme's and such that should work. Thanks for dbl checking/updating
[02:25] <hatch> rick_h_: new (better) fix proposed....much simpler ;)
[02:35] <rick_h_> hatch: cool, will look in a bit. link me please
[02:35] <hatch> https://codereview.appspot.com/21430043/
[02:36] <hatch> 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] <rick_h_> hatch: no tests? comments on why replacing the cs:?
[02:37] <hatch> impossible to test
[02:37] <hatch> at least in js
[02:37] <rick_h_> at least verify that the urls output are fully qualitifed
[02:37] <rick_h_> ?
[02:37] <hatch> like the ones in the href?
[02:37] <rick_h_> something has to be accessing or testing this serviceUpgradeLi
[02:38] <rick_h_> ?
[02:38] <hatch> hmm
[02:39] <hatch> ahh looks like I might be able to stick a small assertion in the upgrade tests
[02:42] <rick_h_> hatch: +1
[02:43] <hatch> I can't believe that this bug in YUI hasn't been reported yet
[02:44] <hatch> that just seems to me like a common thing haha
[02:48] <hatch> 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] <hatch> e
[12:33] <bac> hi evilnickveitch
[12:43] <rick_h_> 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] <bac> rick_h_: paste?
[12:43] <rick_h_> bac: sorry, meant to have the link in there http://<IP_ADDRESS>:8080/job/charmworld-autoland-lxc/54/console
[12:45] <benji> 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] <rick_h_> oh, /me missed that change
[12:50] <gary_poster> hey alejandraobregon, Thursday jaas meeting doesn't work for me.  half hour later?
[12:59] <benji> 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] <rick_h_> benji: yea, hunted and found nadda
[12:59] <benji> k
[12:59] <bac> benji: are you suggesting the change is in charmworld or the lander?
[13:00] <rick_h_> bac: managed to land just ahead of me by hours. So maybe something in my branch is the issue but not seeing
[13:00] <benji> bac: charmworld
[13:00] <benji> I would also suspect a dirty lander (sans evidence).
[13:00] <rick_h_> 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] <benji> Unfortunately we keep a dirty checkout around forever instead of getting a fresh one every time
[13:00] <rick_h_> if that lands then I know it's my branch, if not, then it must be the lander/lxc stuff
[13:01] <benji> sounds good
[13:05] <gary_poster> thanks benji.  Should I go so far as to suggest that they run make devel & :-)
[13:06] <bac> 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] <bac> s/i work/i'm work/
[13:06] <benji> gary_poster: closing the terminal would still kill it; they could run "nohup make devel"
[13:06] <gary_poster> ah ok
[13:07] <rick_h_> bac: it doesn't? It should. jcastro was using it on friday
[13:07] <marcoceppi> bac: uh, it should
[13:07] <marcoceppi> bac: make sure you're using charm-tools
[13:07] <marcoceppi> not charmtools
[13:07]  * bac looks
[13:08]  * marcoceppi spins up a clean vm to test
[13:13] <rick_h_> marcoceppi: did you not sdist upload the package? https://pypi.python.org/pypi/charm-tools/1.1.0
[13:14] <marcoceppi> rick_h_: I'm pretty sure I did
[13:14] <rick_h_> marcoceppi: there's no download there
[13:14] <marcoceppi> rick_h_: right, I see that now
[13:16] <marcoceppi> pypi is a whole new world for me
[13:17] <rick_h_> 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] <rick_h_> is all you need
[13:17] <marcoceppi> rick_h_: ah, never ran the upload
[13:17] <marcoceppi> I did the publish though
[13:17] <marcoceppi> figured that did it
[13:18] <bac> thanks rick_h_ & marcoceppi.  i'm set now.
[13:18] <rick_h_> bac: cool
[13:18] <marcoceppi> rick_h_: upload:
[13:18] <marcoceppi> python setup.py upload
[13:18] <marcoceppi> running upload
[13:18] <marcoceppi> error: No dist file created in earlier command
[13:18] <rick_h_> 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] <rick_h_> marcoceppi: yea, you need sdist and upload
[13:19] <rick_h_> "make this sdist and upload it"
[13:19] <marcoceppi> rick_h_: I did an sdist :\
[13:19] <rick_h_> python setup.py sdist upload
[13:19] <bac> marcoceppi: adding the steps to a hacking doc would be great!
[13:19] <marcoceppi> oh
[13:19] <marcoceppi> uploadede
[13:20] <marcoceppi> bac: what hacking doc ;)
[13:20] <rick_h_> marcoceppi: awesome, there we go. Pretty readme and all there
[13:20] <marcoceppi> rick_h_: lame, no markdown support
[13:20] <rick_h_> 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] <rick_h_> marcoceppi: yea, python is a rst world man
[13:21] <marcoceppi> rick_h_: mega lame
[13:21] <rick_h_> :P
[13:21] <marcoceppi> anyways, that readme is out of date now that I read it
[13:21] <marcoceppi> should probably update it
[13:21] <rick_h_> time for a 1.1.1 release! :)
[13:23] <marcoceppi> rick_h_: ehhhhhhhh, I think it can wait for 1.2
[13:23] <marcoceppi> I hate patch releases
[13:23] <rick_h_> marcoceppi: docs is backward compat :)
[13:23] <rick_h_> but cool
[13:23] <bac> marcoceppi: were you referring to this: https://pastebin.canonical.com/99786/
[13:23] <marcoceppi> 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 <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1247839>
[13:24] <rick_h_> bac: that looks like a missing dep in the package
[13:24] <marcoceppi> damnit. Now I have to patch release
[13:25] <marcoceppi> could have sworn I had markdown in there
[13:25] <rick_h_> marcoceppi: locked version numbers too please :)
[13:25] <marcoceppi> yeah, it's in the setup.py
[13:25]  * marcoceppi is installing in vm
[13:25] <rick_h_> marcoceppi: right, but they're not locked to a version number
[13:26] <marcoceppi> rick_h_: so?
[13:26] <marcoceppi> I mean that shouldn't stop it from installing
[13:26] <rick_h_> 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] <marcoceppi> rick_h_: bah, this is actually making me like debian packaging
[13:26] <rick_h_> 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] <bac> marcoceppi: paramiko too
[13:26] <marcoceppi> rick_h_: why not just add the ppa?
[13:26] <rick_h_> bac: right, those are new deps
[13:26] <marcoceppi> it's packaged in the ppa
[13:27] <rick_h_> marcoceppi: we can't hit LP either
[13:27] <marcoceppi> prodstack should be able to, wtf!
[13:27] <marcoceppi> bahhhhhhhhhhhhhhh
[13:27] <rick_h_> marcoceppi: hmm, does a ppa count as LP?
[13:27] <marcoceppi> rick_h_: check with #is
[13:27] <rick_h_> marcoceppi: looking to see if we pull a ppa already. Thought we might have.
[13:27] <bac> rick_h_: ok, so i needed markdown paramiko and cheetah
[13:28] <rick_h_> marcoceppi: yea, we do add a ppa. We just can't pull LP branches down in prodstack
[13:28] <marcoceppi> rick_h_ bac I recommend the package then
[13:28] <marcoceppi> pypi is just a stop gap for brew stuff
[13:28] <bac> ok
[13:28] <rick_h_> bac: looks like it.
[13:29] <rick_h_> bac: but if ingest runs off our virtualenv it'll break
[13:29] <rick_h_> bac: so hold on a sec, looking
[13:30] <marcoceppi> 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] <rick_h_> 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] <rick_h_> 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] <marcoceppi> rick_h_: so I should move the requirements out of setup.py and in to requirements.txt?
[13:33] <rick_h_> 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] <marcoceppi> I'll let you guys figure out what's needed. Just let me know if/what you need me to change
[13:35] <rick_h_> marcoceppi: thanks, uploading the pacakge was helpful
[13:35] <bac> marcoceppi:  is there a ppa with a released version of charm-tools?
[13:36] <marcoceppi> bac: ppa:juju/stable
[13:36] <bac> ah, great
[13:36] <rick_h_> marcoceppi: the LP landing page has sudo add-apt-repository ppa:juju/pkgs
[13:36] <rick_h_> https://launchpad.net/charm-tools
[13:36] <marcoceppi> rick_h_: thanks
[13:36] <rick_h_> marcoceppi: is that still valid?
[13:36] <marcoceppi> rick_h_: no
[13:37] <marcoceppi> rick_h_: updated
[13:37] <rick_h_> marcoceppi: thanks
[13:37] <marcoceppi> rick_h_: still trying to get this project up-to-date
[13:38] <rick_h_> marcoceppi: we, your users, are here to help :)
[13:38] <rick_h_> appeciate it
[13:41] <bac> rick_h_: so you agree on moving charm-tools to SYSTEM_DEPS in the Makefile and install from ppa?
[13:41] <rick_h_> bac: sounds like a plan to me if that works.
[13:41] <bac> we'll lose version locking...
[13:41] <rick_h_> bac: otherwise we'll have to manage his deps in the download-cache
[13:43] <rick_h_> 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] <bac> rick_h_: but we can only hope things moved to juju/stable are, you know, stable
[13:43] <benji> 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] <gary_poster> benji, I know about that, thanks :-).
[13:44] <benji> k
[13:44] <bac> benji: is he cold-calling you?  :)
[13:44] <rick_h_> 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] <benji> bac: yes! he's trying to sell me leaf guards for my gutters
[13:45] <bac> 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] <marcoceppi> 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] <bac> rick_h_: got a sec to chat?
[13:55] <rick_h_> bac: sure thing
[13:56] <gary_poster> 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] <benji> k
[14:00] <gary_poster> 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] <gary_poster> (benji, 'cause I'm going to suggest "hey, postgres is fine" if so :-) )
[14:01] <benji> 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] <gary_poster> 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] <gary_poster> I'll go talk on #webops
[14:03] <benji> 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] <gary_poster> benji, it looks like he understands to me
[14:04] <gary_poster> the expensive tasks are peripheral but reasonable
[14:04] <benji> gary_poster: send james after him
[14:05] <benji> PG would be OK I guess, but it means adding another technology to the system
[14:05] <gary_poster> :-)
[14:05] <gary_poster> yeah I know.
[14:05] <gary_poster> I still am in favor of something in front of it that only gives us the API we need
[14:06] <rick_h_> gary_poster: heh, a little roughly, but moving forward.
[14:06] <rick_h_> 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] <abentley> rick_h_: hi.
[14:07] <rick_h_> oh, abentley is around, morning. Can I still some time when you have a sec?
[14:07] <abentley> rick_h_: Sure.  Haven't really got started yet.  What's up?
[14:07] <gary_poster> 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] <rick_h_> abentley: http://<IP_ADDRESS>: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] <benji> gary_poster: yeah, I wouldn't change our proposed architechure
[14:08] <gary_poster> cool benji
[14:08] <abentley> rick_h_: looking...
[14:09] <gary_poster> 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] <gary_poster> I mean software behind the firewall
[14:11] <benji> 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] <abentley> 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] <rick_h_> abentley: can I log into it? Just SSO?
[14:12] <gary_poster> 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] <gary_poster> benji ^^
[14:13] <abentley> rick_h_: No, you have to log in as "admin" with the password specified in the juju config.
[14:14] <rick_h_> abentley: ah, ok.
[14:15] <benji> k
[14:23] <rick_h_> bah, my offlineimap hung up. No wonder email seemed quiet this morning
[14:59] <gary_poster> rick_h_, congratulations on successfully convincing the landing bot of your worthiness :-)
[15:02] <rick_h_> gary_poster: yea, thankfully abentley applied a giant hammer of doom to it
[15:02] <hatch> hello all
[15:02] <gary_poster> lol cool
[15:02] <gary_poster> hey hatch
[15:02] <hatch> oops I forgot to mute my laptop
[15:02] <hatch> that was embarrassing
[15:02] <rick_h_> lmao
[15:02] <hatch> haha
[15:03] <hatch> hotel wifi here is so bad that I had to hotspot
[15:03] <gary_poster> lol
[15:04] <gary_poster> on the train sound
[15:16] <rick_h_> benji: bac either of you have time for an api docs update sometime? https://codereview.appspot.com/18600046
[15:17] <benji> rick_h_: I don't at the moment.
[15:17] <rick_h_> benji: k, thanks.
[15:17] <bac> rick_h_: soon
[15:18] <rick_h_> bac: cool, no rush. The landing issue is fixed so this is pure docs for some point in time
[15:22] <bac> rick_h_: done
[15:22] <rick_h_> bac: thanks
[15:37] <benji> rick_h_: what was the landing issue?
[15:37] <rick_h_> 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] <rick_h_> :)
[15:39] <rick_h_> 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] <gary_poster> benji, we are off the hook for now in #webops?
[15:39] <gary_poster> LP bug?
[15:40] <benji> 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] <benji> gary_poster: There is at least enough fog of war that we can demote it to non-emergent status.
[15:40] <gary_poster> benji, heh ok
[15:41] <benji> I'll tell the webops such so we don't violate their expectations.
[15:41] <gary_poster> thanks benji.
[15:41] <benji> np
[15:42] <gary_poster> 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] <gary_poster> 's a bug
[15:43] <gary_poster> it should be ~benji/bundle/wiki/5/wiki
[15:44] <gary_poster> (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] <rick_h_> 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] <gary_poster> rick_h_, ah ok
[15:44] <rick_h_> 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] <rick_h_> gary_poster: and doesn't follow the same rules as apis
[15:44] <gary_poster> rick_h_, but it does follow rules of charmworld page
[15:44] <gary_poster> rick_h_, which is my concern about the id
[15:45] <rick_h_> gary_poster: right, I think there's a bug in there, but that id is "correct"
[15:45] <gary_poster> because I think the charm id does correspond to the charmworld user visible page
[15:45] <gary_poster> :-/
[15:45] <rick_h_> gary_poster: it just doesn't match the json url expectations which is probably more the bug
[15:45] <gary_poster> 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] <gary_poster> IOW...
[15:46] <rick_h_> 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] <gary_poster> rick_h_, a charm id is the charmworld user visible url
[15:46] <gary_poster> so
[15:46] <gary_poster> precise/haproxy-21
[15:46] <gary_poster> becomes https://manage.jujucharms.com/precise/haproxy-21
[15:46] <gary_poster> and works
[15:47] <gary_poster> a bundle id does not have that characteristic
[15:47] <rick_h_> 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] <rick_h_> the world "bundle" isn't part of any bundle id and I'd hate to see it become part of it
[15:48] <gary_poster> rick_h_, I would buy that.  Pretty late in the game though. :-/
[15:49] <gary_poster> rick_h_, that's a small routing change with big test ramifications, yeah?
[15:49] <gary_poster> rick_h_, but if we did that then simply adding json after the url ought to work
[15:49] <rick_h_> 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] <gary_poster> well it is not bundle/~id but bundle/id, for promulgated charms--do we have any of those yet?
[15:50] <Makyo> jujugui call in10
[15:50] <gary_poster> :-)
[15:50] <gary_poster> thanks
[15:50]  * Makyo whew, made it!
[15:50] <gary_poster> bah I meant promulgated bundles
[15:50] <rick_h_> gary_poster: not sure on promulgated bundles. There was all that controversy around policy on those last week
[15:50] <marcoceppi> can someone confirm a bug in charmworld/the review queue for me?
[15:51] <rick_h_> marcoceppi: maybe, crazy day. What's up?
[15:51] <marcoceppi> 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] <rick_h_> 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] <rick_h_> 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] <marcoceppi> thanks
[15:59] <gary_poster> jujugui call in 1
[16:02] <evilnickveitch> bac, hi
[16:02] <bac> hi evilnickveitch, otp right now
[16:02] <bac> you be around in 20 min?
[16:02] <evilnickveitch> ok
[16:03] <evilnickveitch> bac, yes indeed
[16:04] <jcastro> hey rick_h_
[16:04] <jcastro> have you tried to deploy any of my bundles?
[16:05] <jcastro> I can only get bootstrap up and the GUI
[16:05] <jcastro> then it exits saying it's deploying the other services, but they actually don't fire up
[16:05] <rick_h_> jcastro: no, on call atm but haven't tried them out
[16:05] <jcastro> 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] <jcastro> ok
[16:10] <jcsackett> 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] <rick_h_> jcsackett: what's with all the N/A in there?
[16:10] <marcoceppi> jcsackett: cool, I'll open a bug
[16:10] <jcsackett> N/A means no date.
[16:10] <jcsackett> those are in the date fields.
[16:10] <jcsackett> 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] <jcsackett> so merge proposals, bugs, askubuntu questions &c have dates; proof errors, store errors, missing qa data don't.
[16:17] <hatch> Learning a lot about Azure stuff
[16:17] <hatch> no bash scripting
[16:17] <hatch> lol
[16:18] <rick_h_> jcastro: what bundles are failing? Hit me up witht he url please
[16:23] <rick_h_> 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] <marcoceppi> jcsackett: https://bugs.launchpad.net/charmworld/+bug/1247891
[16:28] <_mup_> Bug #1247891: Proof list in review-queue does not get updated <charmworld:New> <https://launchpad.net/bugs/1247891>
[16:30] <gary_poster> alejandraobregon, where are we meeting for jaas thing?
[16:31] <gary_poster> luca__, ^^
[16:31] <luca__> gary_poster: heya
[16:31] <gary_poster> hey
[16:31] <luca__> gary_poster: can we use gui chat?
[16:31] <gary_poster> luca__, gui chat has died because google did not like us, but we can use
[16:32] <gary_poster> luca__, mm, nm :-) why don't you all start a hangout
[16:32] <gary_poster> or I can
[16:32] <gary_poster> adding it to calendar is easiest
[16:32] <luca__> gary_poster: go ahead :)
[16:32] <gary_poster> oh ok
[16:32] <luca__> gary_poster: Ale isn't here at the moment
[16:32] <luca__> gary_poster: so she can't add it
[16:32] <luca__> gary_poster: She'll be joining in 2 mins
[16:33] <gary_poster> luca__, no video from me but https://plus.google.com/hangouts/_/76cpjflh89tfksavch1qeigoj8?hl=en
[16:46] <jcastro> rick_h_, http://manage.jujucharms.com/~jorge/bundle/wordpress/wordpress-simple
[16:46] <jcastro> any of the ones I pushed
[16:46] <rick_h_> 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] <bac> 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] <marcoceppi> bac: how are you trying to run the test suite?
[16:50] <marcoceppi> I don't know if I include the tests in the package (or if I was supposed to)
[16:52] <bac> marcoceppi: i've checked out a branch and ran 'make check
[16:52] <marcoceppi> bac: that should work, I constantly run the tests here
[16:53] <marcoceppi> yeah, they pass here
[16:53] <bac> marcoceppi: it fails with http://paste.ubuntu.com/6359716/
[16:54] <marcoceppi> bac: hum
[16:55] <bac> 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] <marcoceppi> bac: doesn't look like it's being run
[16:55] <bac> marcoceppi: unfortunately i've got to be afk now for an hour or so.
[16:56] <marcoceppi> 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] <marcoceppi> bac: test_proof will fail spectacularly because of the bundles re-org
[16:57] <bac> yep
[16:58] <marcoceppi> 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] <luca__> gary_poster: In the simulator I can't see machine restart and security updates in the inspector, do you know why?
[17:04] <gary_poster> luca__, not off hand.  will look
[17:07] <gary_poster> rick_h_, do you know anything by chance?  Confirmed & investigating ^^^
[17:07] <rick_h_> gary_poster: I thought that the simulator didn't simulate landscape stuff?
[17:07] <gary_poster> rick_h_, it does
[17:08] <rick_h_> gary_poster: I remember that question coming up at the table during sprints and not sure what came of it
[17:08] <gary_poster> ok cool
[17:10] <luca__> gary_poster: I submitted a bug for it
[17:10] <gary_poster> thanks luca__
[17:11] <luca__> gary_poster: I think potentially this could be a problem from removing that bottom bar
[17:11] <gary_poster> luca__, that's what I'm thinking as well.  no smoking gun yet though
[17:11] <luca__> gary_poster: because the simulator shows the notifications in jujucharms.com
[17:11] <luca__> gary_poster: but not coming soon
[17:11] <gary_poster> luca__, sure; jujucharms is pretty old code now though :-P
[17:11] <luca__> gary_poster: ah
[17:14] <gary_poster> I have to run.  biab
[17:42] <rick_h_> cursed npm...ugh
[17:49] <bac> marcoceppi: i do
[17:49] <bac> marcoceppi: i mean, yes i do have python-markdown
[17:50] <marcoceppi> bac: I can't seem to replicate that failure :\
[17:50] <bac> 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] <marcoceppi> bac: yeah, I can roll a patch quickly
[17:51] <marcoceppi> bac: make sure you propose against lp:~charmers/charm-toosl/1.0
[17:51] <marcoceppi> err
[17:51] <marcoceppi> bac: make sure you propose against lp:~charmers/charm-toosl/1.1
[17:51] <bac> ok
[17:59] <rick_h_> 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] <bac> marcoceppi: here is the merge proposal: https://code.launchpad.net/~bac/charm-tools/proof-lib/+merge/193829
[18:08] <marcoceppi> bac: this LGTM, let me test but I can cut a 1.1.1 within the hour (depending on lp builds)
[18:08] <bac> marcoceppi: perfect
[18:10] <marcoceppi> I'll take this opportunity to slide in a few other small changes
[18:19] <rick_h_> 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] <marcoceppi> bac: are you on a windows machine?
[18:26] <gary_poster> rick_h_, ok cool
[18:28]  * benji fights with rv-submit
[18:35] <jcastro> rick_h_, did you get the bundle to work?
[18:37] <rick_h_> jcastro: no, having lxc issues and npm is hating me to test it on aws
[18:37] <rick_h_> 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] <marcoceppi> bac: 1.1.1 submitted to the PPA, uploaded to pypi
[18:49] <gary_poster> marcoceppi, bac does some of his work on OS X.  Not windows.
[18:49] <gary_poster> and on his behalf, thank you :-)
[18:50] <marcoceppi> np! Happy you guys are using the product :)
[18:51] <gary_poster> :-)
[18:53]  * benji lunches
[18:54] <bac> marcoceppi: no, i am running on a saucy vm
[18:54] <marcoceppi> bac: I was trying to figure out why your merge request removed +x on the proof file
[18:55] <bac> huh, i didn't do that intentionally
[18:55] <marcoceppi> I figured, so I assumed it was a system level thing
[19:32]  * benji is back from lunch
[19:44] <rick_h_> 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] <gary_poster> 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] <rick_h_> 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] <benji> +1 on stupid
[19:47] <gary_poster> 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] <rick_h_> gary_poster: hmmm, https://manage.jujucharms.com/api/3/bundle/~bac/wiki/wiki/file/bundles.yaml is the file url.
[19:48] <rick_h_> gary_poster: oh hmm, is that /json the bundle or the basket /me goes to dbl check
[19:48] <gary_poster> rick_h_, no, that's the basket, or it better be :-)
[19:49] <gary_poster> btw, the landscape issue is a bug in simulator, but fixing it exposes a bug in landscape-in-inspector changes
[19:50] <rick_h_> gary_poster: wheee
[19:50] <gary_poster> :-)
[19:50] <rick_h_> 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] <gary_poster> that's the file from the branch
[19:51] <gary_poster> or should be
[19:51] <rick_h_> gary_poster: right, but in this view it's generating a dict and then json'ing it back. No basket in there.
[19:52] <gary_poster> rick_h_, that's yaml
[19:52] <rick_h_> gary_poster: so that url manage/bundle/~bac/xxx/yyy is just the bundle requested. Not a deployer file
[19:52] <rick_h_> gary_poster: so for instance, that'll never have a series in it from what I can tell
[19:52] <rick_h_> :/
[19:53] <benji> 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] <bac> 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] <gary_poster> benji, a basket file is conceptually an unprocessed deployer file--the deployer file from the branch
[19:53] <gary_poster> agreed I'm making that name up
[19:54] <rick_h_> 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] <marcoceppi> bac: bah, 1.1.2 it is then
[19:54] <benji> gary_poster: sure, "conceptually", "for reals" we don't treat them as first-class entities and don't expose them
[19:54] <marcoceppi> bac: I may have split the proof file a little too hastily
[19:54] <gary_poster> benji +1
[19:54] <marcoceppi> bac: can you open a bug while I patch?
[19:54] <bac> marcoceppi: sure
[19:58] <bac> marcoceppi: bug 1247951 filed
[19:58] <_mup_> Bug #1247951: proof calls sys.exit <Juju Charm Tools:New for marcoceppi> <https://launchpad.net/bugs/1247951>
[19:58] <marcoceppi> bac: thanks!
[20:14] <benji> gary_poster: what does "Add version file in charmworld?" mean?
[20:14] <gary_poster> benji, it means, "ask Gary!" Congratulations! ;-)
[20:15] <benji> heh
[20:15]  * benji jumps around as confetti falls down.
[20:16] <gary_poster> heh.  benji, so...Kapil mentioned that he wanted the bundles to have a version file.  For charms, the charm store does that.  As long as we serve upindividual files and not zipfiles for bundles, I don't think we actually care about version files.
[20:16] <gary_poster> but if we do, charmworld would supply them, ATM
[20:16] <benji> k
[20:17] <gary_poster> benji, so the question is, would a version file make any sense at all now?  Or should we postpone them till zipfile bundles?
[20:17] <gary_poster> AFAIK the answer is #2, but I wanted to ask, since Kapil had mentioned it
[20:18] <benji> gary_poster: what is the point of a version?  to just keep up with it in case you forget?
[20:19] <rick_h_> why does it matter for zip files even. Just because the deployer needs to know to redo the work vs ignore it due to a cache or something? It's the only thing it's used for in charms in  deploying over and over the same charm
[20:19] <gary_poster> benji, uh-oh, koan territory.  If I knew, I might be more excited asking for it ;-)
[20:20] <gary_poster> rick_h_, yeah, that's it
[20:20] <bac> rick_h_: quick call?
[20:20] <rick_h_> bac: sure thing
[20:20] <gary_poster> benji ^^^ versions would let the deployer know "oh, it was version foo"
[20:20] <rick_h_> gary_poster: so ftr I'm not a fan. It's a lie to the user. That revision is not respected anywhere.
[20:20] <benji> heh, "koan territory"
[20:20] <gary_poster> so it could upgrade
[20:20] <gary_poster> rick_h_, ?
[20:20] <benji> does the deployer do that?
[20:20] <gary_poster> rick_h_, this would be so that the deployer could do that.
[20:21] <gary_poster> benji ^^^
[20:21] <gary_poster> it's a pre-requisite
[20:21] <gary_poster> step 1: we provide a version
[20:21] <gary_poster> step 2: deployer annotates version at deployment time
[20:21] <gary_poster> step 3: <magic happens> bundles are upgradable!
[20:24] <marcoceppi> bac: Does this look okay?
[20:24] <marcoceppi> https://code.launchpad.net/~marcoceppi/charm-tools/fix-sys-exit/+merge/193844
[20:25] <benji> gary_poster: we could do something I suppose, but this whole thing seems painfully underspecified
[20:29] <rick_h_> +1 ^^
[20:29] <marcoceppi> step 4: profit!
[20:30] <rick_h_> gary_poster: what I was saying is that we've got this revision file, but any UI we show is either the store revision or bzr revision which are different
[20:30] <rick_h_> gary_poster: and it bugs me we have it around, so duping that for bundles is just more itching to get annoyed with :)
[20:30]  * marcoceppi chimes in
[20:30] <marcoceppi> Could we just use revno for version?
[20:30]  * marcoceppi uses the royal we, and means you guys
[20:31] <rick_h_> marcoceppi: well I guess I'm with benji on getting the use case. Right now you can't deploy the same bundle twice in the gui because it'll fail that the charm is already deployed into the environment
[20:31] <gary_poster> benji, uh-huh.  I guess that's another way at looking at my point.  (1) Kapil wants to support bundle upgrades.  To do that, he needs a concept of version.  (2) Kapil can't use the version until it is delivered to the deployer. At that point he can start annotating versions, which is a prerequisite for supporting upgrades.  (3) The deployer file currently has no way to specify a version. (4) He thinks it would be ni
[20:31] <gary_poster> ce to have it in a separate file, to match the way it is done in charms.  (5) That solution only helps #2 if the deployer gets a zip file.  (6) There could be many other solutions, but Kapil is requesting a feature, not a design discussion. (7) we can say too bad. :-)
[20:31] <rick_h_> marcoceppi: if the goal is to re-run your bundle at the time you write it, there's no bzr reno to update
[20:31] <marcoceppi> oh, good point :(
[20:34] <gary_poster> benji, rick_h_ so, the card is to try and get your thoughts on this.  your thoughts have been kinda grumpy so far, tbh :-P but if I can cast them in a brighter color, they would be "we can implement versions or something similar, but we need to all agree on their utility, across the deployer, the GUI, and charmworld, and not have one part of the chain drive the other two."  Of course, Kapil can push back on that, si
[20:34] <gary_poster> nce we've wanted to follow the deployer so far, but I think that's a reasonable position.  Is that how you'd suggest I cast it?
[20:35] <bac> marcoceppi: what does proof return for exit_code when it successfully calls remote_proof?  is it 0 or 200?
[20:35] <rick_h_> gary_poster: I'd suggest it get cast as "If the goal is to support bundle upgrading we should discuss how that would work and if we need to be able to diff the json configs and handle that. Versioning doesn't help with an upgrade. It just tells us to --force. If that's the only use case then let's find a way to add a --force flag to things vs versions that don't mean anything
[20:35] <marcoceppi> bac: it doesn't return anything, it updates the Linter via calls to err, warn, info, etc
[20:36] <marcoceppi> bac: ideally if all is peachy, it should be 0
[20:36] <benji> gary_poster: +1 on the "we can implement versions or something similar"; re. the second part, I don't really care who drives what
[20:36] <gary_poster> rick_h_, I think he believes that versioning can help with an upgrade, and I suspect he has a point.
[20:36] <marcoceppi> ohhh, I think I see a bug bac
[20:37] <rick_h_> gary_poster: right, but the only way I can see it helping is if you've got the old/new and know how to deal with the difference. Otherwise I think it's more of a --force-deploy new_bundle.yaml feature.
[20:37] <bac> marcoceppi: so if i want to reject the entire thing, i can rely on err_code != 0?
[20:37] <marcoceppi> bac: which method are you running, proof?
[20:37] <bac> marcoceppi: yes
[20:38] <rick_h_> gary_poster: but yea, grumpy about it actually fitting the use case. It can be added just fine. We do it for charms, though we've worked hard to back out of it for most use cases.
[20:38] <marcoceppi> bac: cool, you should get err_code 0 for everything okay, error is 200, warn is 100
[20:38] <marcoceppi> bac: I just realized it's not respecting the offline flag, which you guys will need
[20:39] <benji> I can't see how a version number helps upgrades, other than to know when they aren't neccesary (equal version numbers).
[20:39] <rick_h_> benji: right, and a --flag can do that
[20:39] <rick_h_> how does an upgrade work? If a service is deployed, and the config values in the bundle are changed, how are those applied? Remove all old config and set new, merge the two overriding as necessary?
[20:40] <gary_poster> rick_h, benji, aiee, you guys are being grumpy. :-)  let's have a hangout.  https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
[20:41] <marcoceppi> bac: okay, offline checks added, but yes, after running proof you should get an list of messages and a code >= 0
[20:42] <bac> marcoceppi: review done but i sprung a new issue on you.  :)
[20:42] <marcoceppi> bac: that's fine, might as well get them out now before the new release :)
[20:44] <marcoceppi> bac: so if you run proof with offline you'll get this: http://paste.ubuntu.com/6360893/
[20:44] <marcoceppi> I'm guessing you're not going to want to show that message every single time
[20:49] <benji> might aught to make that a warning at least
[20:50] <benji> BTW, marcoceppi, have you been working on juju-core? those one letter abbreviations make me think you have
[20:50] <marcoceppi> benji: no, these one letter messages have been around since before I was even a charmer
[20:51] <marcoceppi> legacy code, and all that
[20:51] <bac> marcoceppi: charmworld won't ever be running with --offline
[20:51] <marcoceppi> bac: oh, might want to check with rick_h_ I put that in there for him
[20:51] <rick_h_> marcoceppi: well that's for you in case people want to proof sans-network activity
[20:51] <rick_h_> airplanes and all that
[20:52] <marcoceppi> rick_h_: oh, I though you guys were going to do it to prevent another look up against your API endpoint
[20:52] <bac> whee, we're going 'round and 'round
[20:52] <marcoceppi> since it's pingin charmworld
[20:52] <rick_h_> lol
[20:52] <marcoceppi> ha, I don't always proof bundles on an airplane, but when I do, I do it from memory
[20:57] <marcoceppi> bac: okay, updated the merge
[20:59] <marcoceppi> fudge
[21:00] <bac> great marcoceppi.  will that be 1.1.2?
[21:00] <marcoceppi> bac: yeah, this will be 1.1.2
[21:00] <bac> yay
[21:07] <marcoceppi> bac: it's up on pypi and via tarbal https://launchpad.net/charm-tools/1.1/1.1.2 the ppa should have it built in about an hour
[21:07] <benji> gary_poster: should I work on the charm killer next or something more pressing for the release?
[21:07] <bac> marcoceppi: great
[21:07] <rick_h_> go marcoceppi go!
[21:08] <gary_poster> rick_h_, did you determine that Jorge's bundles work fine in the GUI on a real environment--it is just quickstart, for some reason?
[21:08] <rick_h_> gary_poster: so it did not work from the gui, but I could not use anything but the default stable branch in the charm due to npm issues. It did work via a manual deployer call.
[21:09] <rick_h_> gary_poster: so it's either gui or quickstart, I can't be 100% sure if any changes to the version fo the gui since the last release help
[21:10] <gary_poster> rick_h_, ack thanks.  benji, ok that is emergency status if it is the GUI.  hangout in https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0 ?
[21:10] <benji> gary_poster: on may way
[21:31] <gary_poster> Hey Makyo do you have a few minutes to talk me through a basic d3-ism, so I can fix a bug, please?
[21:32] <Makyo> gary_poster, yep
[21:32] <gary_poster> thanks Makyo https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0
[21:36] <bac> jujugui: review of bundle proofing: https://codereview.appspot.com/21610044/
[21:36] <bac> i've got to walk the dog but can respond later
[21:36]  * bac -> out
[21:37] <benji> gary_poster: the quickstart doesn't appear to take a bundle as a parameter (this is a branch of lp:juju-gui/juju-quickstart)
[21:37] <gary_poster> benji it takes a file
[21:37] <benji> % .venv/bin/python juju-quickstart -e ec2 --debug bundle.json
[21:37] <benji> usage: juju-quickstart [-h] [-e ENV_NAME] [--environments-file ENV_FILE]
[21:37] <benji>                        [--version] [--debug] [--description]
[21:37] <benji> juju-quickstart: error: unrecognized arguments: bundle.json
[21:38] <gary_poster> benji when you say juju-quickstart --help does it say that it takes a bundle?
[21:39] <benji> gary_poster: nope
[21:39] <benji> could this be the wrong branch
[21:39]  * benji looks at frankban's recent branches
[21:40] <Makyo> quickstart-bundle-file
[21:40] <Makyo> Is the branch
[21:40] <Makyo> benji,  ^^^
[21:40] <benji> ah!  thanks
[21:40] <gary_poster> benji, no
[21:40] <Makyo> Should have been merged, though
[21:40] <gary_poster> been merged
[21:40] <gary_poster> benji http://pastebin.ubuntu.com/6361207/
[21:41] <gary_poster> benji bzr branch lp:juju-quickstart should work
[21:41] <gary_poster> I will try that too
[21:41] <rick_h_> bac: done with notes
[21:41] <gary_poster> benji, yup
[21:42] <benji> gary_poster: ah, I was tricked by the decoy at lp:juju-gui/juju-quickstart
[21:44] <gary_poster> benji, I dunno what you did but that is trunk.  can't worry about it now, glad it is working, doing something else
[21:46] <rick_h_> jujugui need a charmworld review for the deployer_file_url please. https://codereview.appspot.com/21370044/
[21:47] <rick_h_> and I'm outta here to get the boy from school. Let me know if there's anything I can pick up in the morning
[22:05] <bac> thanks rick_h_
[22:05] <bac> i should've been more specific about that node link.  the old version was actually a syntax error
[22:06] <huwshimi> Morning
[22:18] <gary_poster> morning huwshimi
[22:18] <gary_poster> benji, any news?  past your EoD, but if you have any info before you depart it might help me if I stare at it
[22:18] <huwshimi> gary_poster: Hey
[22:20] <huwshimi> rick_h_: Hey, if you happen to be around at some stage, I'm building the dropdown widget but I can't get it to load in app.js http://paste.ubuntu.com/6361408/
[22:20] <benji> gary_poster: nothing useful; findings thus far: 1) the quckstart gives you cryptic error messages if you have python-juju installed instead of go-juju, 2) lxc won't create a saucy container for me complaining about 404s
[22:21] <huwshimi> rick_h_: I've done a bunch of copy and paste to build the framework of that widget, but it's not giving me any errors, it's just not finding it...
[22:21] <gary_poster> ack benji.  I saw lore local provider bugs flying around today.  I plan to stay away from it until it seems to settle down.  apparently broken in precise
[22:21] <gary_poster> s/lore/more/
[22:22] <benji> gary_poster: I wasn't using juju-local, I just wanted a way to install juju-core; the instructions on the web site don't work on "rabid" or whatever the R one is
[22:23] <gary_poster> benji, ack, I think
[22:24] <gary_poster> oh, you were trying to create an lxc container in which you would install juju
[22:24] <gary_poster> and stuff
[22:26] <benji> right
[22:26] <gary_poster> gotcha
[22:31] <huwshimi> rick_h_: Oh, modules-debug. I forgot to add it there :(
[22:51] <rick_h_> huwshimi: yea, modules-debug
[22:51] <rick_h_> huwshimi: and is widgets already the right place?
[22:51] <rick_h_> new widgets.Dropdown (widgets = Y.juju.widgets?)
[22:52] <rick_h_> looks like it
[22:52] <rick_h_> huwshimi: I'd suggest doing juju-dropdown vs just dropdown
[22:52] <rick_h_> but meh, it could be more reusable I guess. But then I'd ditch the rest of the juju namespace bits
[22:52] <huwshimi> rick_h_: Yeah, it is, thanks. As soon as I wrote out the question to you it made me think that something external needed to be hooked up and a grep found modules-debug
[22:52] <huwshimi> silly things
[22:53] <rick_h_> huwshimi: all good, been there/done that
[22:53] <huwshimi> :)
[23:05] <huwshimi> rick_h_: Is there something I have to do to reference Y.namespace('juju.widgets').Templates? Templates is undefined...
[23:05] <huwshimi> rick_h_: The widget requires 'juju-templates'