| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| kurt_ | clock time was definitely way off | 00:04 |
| kurt_ | 14 hours | 00:04 |
| kurt_ | do I need to do something after that to force a bootstrap of the node then? | 00:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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 | 00:14 |
| === 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 | ||
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| roaksoax | rvba: awesome, so we should be able to use the packages failry easily then | 13:05 |
| 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:10 |
| 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:11 |
| rvba | I just installed the package (on precise), seems ok. | 13:12 |
| 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:17 |
| 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:18 |
| 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:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| rvba | roaksoax: this is very YUI specific so I doubt you'll find something related to this. | 13:33 |
| 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:34 |
| roaksoax | rvba: http://wiki.debian.org/Javascript/Policy | 13:37 |
| * roaksoax BRB | 13:39 | |
| roaksoax | rvba: ok, so the policy doesn't mention anything about the versioning | 14:28 |
| 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:29 |
| rvba | s/going/doing/ | 14:49 |
| === matsubara is now known as matsubara-afk | ||
| adam_g | how does MAAS provide file storage for the Juju provider? | 17:12 |
| ahasenack | does maas provide a metadata service like aws? | 19:08 |
| === marcoceppi_ is now known as marcoceppi | ||
| === Aaton is now known as Aaton_off | ||
| === Aaton_off is now known as Aaton | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!