[00:00] <bigjools> is its clock out of sync?
[00:00] <kurt_> Hi - question on this - I see an ntpd check
[00:00] <kurt_> Julian, right?
[00:01] <kurt_> so, would there be a way to force a check to ntpd to admin node, or make that an option?
[00:01] <kurt_> I have seen that bug you guys had out there
[00:01] <bigjools> well if the clock is out of whack and ntp fails for some reason then oauth  fails, which is required to access the metadata service on boot
[00:01] <bigjools> just set the hardware clock for now until there's a better solution for this
[00:02] <kurt_> so, will bios clock take care of that?
[00:02] <kurt_> this is all in vmware in case you couldn't guess
[00:02] <bigjools> ah
[00:03] <kurt_> is that an "ah" with a big stamp of disapproval? :)
[00:03] <bigjools> check the console when it's booting up for the first time then, if it sits waiting for a long time then it's probably the oauth/clock thing
[00:03] <kurt_> ok, I can try that
[00:03] <bigjools> but yes I'd have thought the clock time would come from the host
[00:04] <kurt_> clock time was definitely way off
[00:04] <kurt_> 14 hours
[00:05] <kurt_> do I need to do something after that to force a bootstrap of the node then?
[00:06] <kurt_> still asking for password
[00:06] <kurt_> I was reading about clicking on start button from MAAS interface?
[00:06] <bigjools> are you using juju?
[00:07] <kurt_> yup
[00:07] <bigjools> you don't need to use the maas interface to start then
[00:07] <bigjools> and juju passes the ssh key
[00:08] <kurt_> since that doesn't appear to be working, how do I get the node to re-sync the ssh key?
[00:08] <kurt_> juju bootstrap, again?
[00:08] <bigjools> yes
[00:08] <kurt_> I've been trying that without much luck...
[00:08] <bigjools> destroy the juju env
[00:09] <kurt_> eeek
[00:09] <bigjools> fix the clock
[00:09] <bigjools> bootstrap again
[00:09] <kurt_> :)
[00:09] <bigjools> well if it's not a node with the master on it then you can just release it
[00:11] <kurt_> do I not need to use maas when using juju?  I'm still learning this stuff
[00:11] <bigjools> juju works with many providers :)
[00:11] <bigjools> it's up to you if you want to use maas
[00:11] <kurt_> if I want to do things in my own private cloud, then maas is the only way, right?
[00:11] <bigjools> but for local deployments maas is good
[00:12] <kurt_> ok, cool
[00:12] <bigjools> it's still a bit rough around the edges
[00:12] <kurt_> :) you guys are working throught
[00:12] <kurt_> through it
[00:12] <bigjools> we try :)
[00:13] <kurt_> my purpose is create a private cloud so I can try a third party enterprise cloud management system called convirture
[00:13] <kurt_> not sure if you are familiar with it
[00:13] <bigjools> I'm not
[00:13] <kurt_> they have a community version AND enterprise version
[00:13] <kurt_> does the name xen-man ring a bell?
[00:14] <kurt_> in any case, I'm really trying to get a private cloud going to test convirture.  I'm thinking juju may be redundant for my needs
[13:01] <roaksoax> rvba: howdy
[13:01] <rvba> roaksoax: \o
[13:01] <roaksoax> rvba: so I have raphael and yui packaged
[13:01] <rvba> roaksoax: \o/
[13:01] <roaksoax> rvba: in ppa:maas-maintainers/testing for quantal
[13:02] <roaksoax> rvba: so feel free to start the migration :)
[13:02] <roaksoax> and ttest those packages
[13:02] <rvba> roaksoax: meanwhile I've upgraded the YUI version we use in maas to 3.5.  All good.
[13:03] <roaksoax> rvba: awesome! I was looking into doing it myself blast night but there's some thing i obviously don't know about so I didn't :)
[13:04] <rvba> roaksoax: it was really simple for me to upgrade.  And I was ready to fix issues/deprecations etc but it turns out all went smoothly.
[13:05] <roaksoax> rvba: awesome, so we should be able to use the packages failry easily then
[13:10] <rvba> roaksoax: I just need to make sure the structure plays well with 'combo' (the component we use for loading tons of js files in one request.
[13:10] <rvba> The structure of the files in the package that is.
[13:10] <roaksoax> rvba: yeah I think changes are gonna be needed in order to access that directory, aren't they? i/e/ tdeal with permissions and stuff
[13:11] <rvba> roaksoax: I assume the directory where the files will end up will be readable by anyone right?
[13:11] <roaksoax> rvba: can't recall but it is /usr/share/javascript
[13:12] <rvba> I just installed the package (on precise), seems ok.
[13:17] <rvba> roaksoax: will the package end up in precise at some point?
[13:17] <roaksoax> rvba: I guess we'll have to backport it
[13:17] <roaksoax> rvba: would you rather have a precise version to test against?
[13:18] <rvba> roaksoax: well, the version you gave me installed just fine on precise.  It's just a bunch of dead JS files after all :).
[13:20] <rvba> roaksoax: the package as it is won't play nice with the way the combo loader works.  Because the typical requested path looks like this: /combo/?3.5.1/build/overlay/assets/skins/sam/overlay.css&3.5.1/build/w...
[13:20] <roaksoax> rvba: yeah, providing a precise version is simple enough as building it for precise
[13:20] <rvba> roaksoax: we obviously can strip out the "3.5.1/build" from each path but it would be much more simple if the file path could match this.
[13:23] <roaksoax> rvba: ok hold on, you say you *don't* want 3.5.1/build in the path?
[13:23] <rvba> roaksoax: I *do* want it.
[13:24] <rvba> roaksoax: Let me give you an example.
[13:24] <roaksoax> rvba: ok, so i guess it could be done
[13:24] <roaksoax> rvba: however, I do not want ot change howthis is done in distros
[13:24] <roaksoax> i.e. maybe policy says *not* to do that
[13:25] <rvba> roaksoax: I'm just telling you what would be more convenient for us.  You get to tell me if it's possible or not :).
[13:26] <roaksoax> rvba: let me try to see if there'
[13:26] <roaksoax> s some kind of policy
[13:26] <rvba> So, long story short, YUI3 has this built-in tool to load multiple js/css file all in one request.
[13:26] <roaksoax> rvba: eitherway, I do not want to differ that much from debian
[13:26] <rvba> It's very convenient because on the JS side you simply load modules and the a single request loads all the JS files in one request.
[13:27] <rvba> But it requires a component on the server side to parse the request and return the (concatenated) files.
[13:27] <rvba> In the Django world this component this component is called 'convoy'.
[13:28] <rvba> Yahoo also provide a service that does serve these files but you have to use their servers in that case and we (in MAAS) can't do that.
[13:28] <rvba> Convoy works by being pointed to a root directory and serving up files from there.
[13:29] <rvba> But the structure needs to be {yui_version}/build/JS_files_from_the_release
[13:29] <rvba> Right now /usr/share/javascript/yui contains all the JS files from the release.
[13:30] <rvba> roaksoax: Having a symblink from /usr/share/javascript/yui/3.5.1/build pointing to /usr/share/javascript/yui could do the trick.
[13:30] <roaksoax> rvba: right. So yes, let me check wehther policy mentions something about that, as if I do a change like that, it might affect many other things
[13:31] <roaksoax> rvba: i'd rather have a symlink in //usr/share/maas/web/static
[13:31] <rvba> Another benefit of this whole combo thing is the ability to use multiple versions.  With the current structure of the package we would somewhat lose that possibility.
[13:32] <rvba> roaksoax: yeah, that would be fine.  We just need to be able to access, say model.js from {YUI_ROOT}/3.5.1/build/model/model.js
[13:33] <rvba> roaksoax: this is very YUI specific so I doubt you'll find something related to this.
[13:34] <rvba> roaksoax: I think the symblink should be somewhere in the YUI package if possible.  This way convoy + libjs-yui would be fully reusable outside of MAAS.
[13:37] <roaksoax> rvba: http://wiki.debian.org/Javascript/Policy
[13:39]  * roaksoax BRB
[14:28] <roaksoax> rvba: ok, so the policy doesn't mention anything about the versioning
[14:29] <roaksoax> so symlinking might be a good thing. I'm going to try to see if I get an answer from anyone on that team or with better experience packaging javascript
[14:29] <rvba> Cool, thanks for going that roaksoax.
[14:49] <rvba> s/going/doing/
[17:12] <adam_g> how does MAAS provide file storage for the Juju provider?
[19:08] <ahasenack> does maas provide a metadata service like aws?