[00:00] is its clock out of sync? [00:00] Hi - question on this - I see an ntpd check [00:00] Julian, right? [00:01] so, would there be a way to force a check to ntpd to admin node, or make that an option? [00:01] I have seen that bug you guys had out there [00:01] 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] just set the hardware clock for now until there's a better solution for this [00:02] so, will bios clock take care of that? [00:02] this is all in vmware in case you couldn't guess [00:02] ah [00:03] is that an "ah" with a big stamp of disapproval? :) [00:03] 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] ok, I can try that [00:03] but yes I'd have thought the clock time would come from the host [00:04] clock time was definitely way off [00:04] 14 hours [00:05] do I need to do something after that to force a bootstrap of the node then? [00:06] still asking for password [00:06] I was reading about clicking on start button from MAAS interface? [00:06] are you using juju? [00:07] yup [00:07] you don't need to use the maas interface to start then [00:07] and juju passes the ssh key [00:08] since that doesn't appear to be working, how do I get the node to re-sync the ssh key? [00:08] juju bootstrap, again? [00:08] yes [00:08] I've been trying that without much luck... [00:08] destroy the juju env [00:09] eeek [00:09] fix the clock [00:09] bootstrap again [00:09] :) [00:09] well if it's not a node with the master on it then you can just release it [00:11] do I not need to use maas when using juju? I'm still learning this stuff [00:11] juju works with many providers :) [00:11] it's up to you if you want to use maas [00:11] if I want to do things in my own private cloud, then maas is the only way, right? [00:11] but for local deployments maas is good [00:12] ok, cool [00:12] it's still a bit rough around the edges [00:12] :) you guys are working throught [00:12] through it [00:12] we try :) [00:13] my purpose is create a private cloud so I can try a third party enterprise cloud management system called convirture [00:13] not sure if you are familiar with it [00:13] I'm not [00:13] they have a community version AND enterprise version [00:13] does the name xen-man ring a bell? [00:14] 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 === matsubara_ is now known as matsubara === tobin_ is now known as tobin === tobin is now known as Guest74089 === Guest74089 is now known as tobin__ === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara [13:01] rvba: howdy [13:01] roaksoax: \o [13:01] rvba: so I have raphael and yui packaged [13:01] roaksoax: \o/ [13:01] rvba: in ppa:maas-maintainers/testing for quantal [13:02] rvba: so feel free to start the migration :) [13:02] and ttest those packages [13:02] roaksoax: meanwhile I've upgraded the YUI version we use in maas to 3.5. All good. [13:03] 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] 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] rvba: awesome, so we should be able to use the packages failry easily then [13:10] 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] The structure of the files in the package that is. [13:10] 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] roaksoax: I assume the directory where the files will end up will be readable by anyone right? [13:11] rvba: can't recall but it is /usr/share/javascript [13:12] I just installed the package (on precise), seems ok. [13:17] roaksoax: will the package end up in precise at some point? [13:17] rvba: I guess we'll have to backport it [13:17] rvba: would you rather have a precise version to test against? [13:18] 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] 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] rvba: yeah, providing a precise version is simple enough as building it for precise [13:20] 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] rvba: ok hold on, you say you *don't* want 3.5.1/build in the path? [13:23] roaksoax: I *do* want it. [13:24] roaksoax: Let me give you an example. [13:24] rvba: ok, so i guess it could be done [13:24] rvba: however, I do not want ot change howthis is done in distros [13:24] i.e. maybe policy says *not* to do that [13:25] 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] rvba: let me try to see if there' [13:26] s some kind of policy [13:26] So, long story short, YUI3 has this built-in tool to load multiple js/css file all in one request. [13:26] rvba: eitherway, I do not want to differ that much from debian [13:26] 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] But it requires a component on the server side to parse the request and return the (concatenated) files. [13:27] In the Django world this component this component is called 'convoy'. [13:28] 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] Convoy works by being pointed to a root directory and serving up files from there. [13:29] But the structure needs to be {yui_version}/build/JS_files_from_the_release [13:29] Right now /usr/share/javascript/yui contains all the JS files from the release. [13:30] 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] 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] rvba: i'd rather have a symlink in //usr/share/maas/web/static [13:31] 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] 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] roaksoax: this is very YUI specific so I doubt you'll find something related to this. [13:34] 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] rvba: http://wiki.debian.org/Javascript/Policy [13:39] * roaksoax BRB [14:28] rvba: ok, so the policy doesn't mention anything about the versioning [14:29] 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] Cool, thanks for going that roaksoax. [14:49] s/going/doing/ === matsubara is now known as matsubara-afk [17:12] how does MAAS provide file storage for the Juju provider? [19:08] does maas provide a metadata service like aws? === marcoceppi_ is now known as marcoceppi === Aaton is now known as Aaton_off === Aaton_off is now known as Aaton