| kurt__ | bigjools: are you around? | 00:17 |
|---|---|---|
| bigjools | kurt__: yes | 00:17 |
| kurt__ | hi - I've been struggling with an issue with OAuthunathorized and juju-gui | 00:18 |
| kurt__ | this is with vmware, so I believe it is a clock issue | 00:18 |
| kurt__ | the clock on the vm is exactly 7 hours off | 00:18 |
| kurt__ | have you had any success with vmware and getting the clocks in the maas clients to sync? | 00:19 |
| bigjools | are you in mountain time by any chance? | 00:19 |
| kurt__ | PST | 00:19 |
| bigjools | I've never used vmware with maas | 00:19 |
| bigjools | we have previously used qemu | 00:19 |
| kurt__ | it works well, except for this clock issue | 00:19 |
| bigjools | but not for a while | 00:19 |
| bigjools | the unauth problem has been solved now for a long time, what is your exact problem? | 00:20 |
| kurt__ | after bootstrap and I go to install juju-gui, the status goes to pending and never does anything past that. | 00:21 |
| kurt__ | I look at the maas.log and its full of OAuth unauthorized errors | 00:21 |
| bigjools | is the bootstrap a VM? | 00:21 |
| bigjools | I need to go OTP, back later | 00:21 |
| kurt__ | yes | 00:22 |
| kurt__ | bigjools: see http://pastebin.ubuntu.com/5979922/ for logging of juju-debug and maas errors here http://pastebin.ubuntu.com/5978813/ | 00:29 |
| bigjools | kurt__: ok back. Is the clock on the bootstrap node also out by 7 hours? | 01:10 |
| bigjools | kurt__: so the logs don't have enough context, can you send the entire log | 01:12 |
| bigjools | ah I see where the time problem comes from now, it's not cloud-init, it's between juju and maas | 01:13 |
| kurt__ | no | 01:19 |
| kurt__ | bigjools: actually, let me check that, but I believe that is the case | 01:20 |
| kurt__ | ah, you see a problem? | 01:20 |
| bigjools | I thought you were talking about booting the nodes themselves, they talk using oauth to the maas api | 01:20 |
| bigjools | but your problem here is definitely the clock skew, you need to fix that, no way around it | 01:21 |
| kurt__ | right | 01:21 |
| kurt__ | so is there a way to do this with cloud-init? like how it was solved with kvm? | 01:21 |
| bigjools | the problem is between juju and the maas sever | 01:21 |
| bigjools | server | 01:22 |
| bigjools | at least looking at your logs | 01:22 |
| bigjools | so are the clocks out of whack between those? | 01:22 |
| kurt__ | I was just spinning the nodes up to check | 01:22 |
| bigjools | it's nothing to do with the nodes | 01:24 |
| kurt__ | eh…ok. but the time is off between the root juju node and the maas controller | 01:25 |
| bigjools | yes, that's what I meant, sorry | 01:25 |
| bigjools | the bootstrap node's time needs to be fixed | 01:25 |
| kurt__ | http://pastebin.ubuntu.com/5991152/ | 01:25 |
| kurt__ | right - but it get fubarred on boot/set up - so isn't that something that can be fixed via cloud-init? | 01:26 |
| bigjools | looks ok then | 01:26 |
| kurt__ | no - they are off | 01:26 |
| bigjools | just a different timezone, the utc stamp will be the same no? | 01:26 |
| kurt__ | its off by 7 hours no matter what | 01:27 |
| bigjools | oh got it wrong way around | 01:27 |
| bigjools | yes, so fix that :) | 01:27 |
| kurt__ | lol | 01:27 |
| kurt__ | how? | 01:27 |
| kurt__ | its happening on boot/creation of the node | 01:27 |
| bigjools | I don't know, you will need to check the vmware docs | 01:27 |
| bigjools | for now you could set it manually | 01:28 |
| bigjools | or run ntpd | 01:28 |
| kurt__ | there is an option to sync the clocks which I have tried both ways, and it has no effect | 01:28 |
| kurt__ | do you know how this problem was solved with kvm? | 01:29 |
| bigjools | I don't know if it was ever a problem with kvm | 01:29 |
| bigjools | afaik it just used the host's time | 01:29 |
| kurt__ | and if I went the ntpd route, how would I go about making it happen automatically? do I need to hack cloud-init? | 01:31 |
| kurt__ | or mount the images and hack those, ugh :( | 01:31 |
| === CyberJacob|Away is now known as CyberJacob | ||
| roaksoax | bigjools: just tested | 02:12 |
| roaksoax | in a clean install | 02:12 |
| roaksoax | no issues | 02:12 |
| roaksoax | whatsoever | 02:12 |
| roaksoax | bigjools: i'm guessing they had newer kombu/celery? | 02:12 |
| === CyberJacob is now known as CyberJacob|Away | ||
| roaksoax | bigjools: so just ttested both upgrade from cobbler based maas to newer maas, and fresh install of newer maas and went without issues | 02:25 |
| === CyberJacob|Away is now known as CyberJacob | ||
| bigjools | roaksoax: ok thanks for testing | 04:00 |
| === CyberJacob is now known as CyberJacob|Away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === racedo` is now known as racedo | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| natefinch | rvba: are you around? I have some questions about maas and azure | 13:55 |
| rvba | Hi natefinch. | 13:58 |
| rvba | Go ahead. | 14:00 |
| natefinch | rvba: hi.. I'm a new juju dev, working on a project to add IP Addresses to the info we return on instances | 14:00 |
| natefinch | rvba: starting with maas... is the IP address of a node exposed anywhere? I see they have a hostname, but I don't see IP address as something that you can get from the API | 14:02 |
| rvba | natefinch: indeed, it's not exposed on the API, but we have the hostnane <-> IP stored internally so it's something we could expose. | 14:03 |
| rvba | the hostname <-> IP correspondence* | 14:04 |
| natefinch | rvba: that would definitely be useful, save us a DNS lookup at least... but obviously we have to work with what's in the API right now. Just wanted to make sure I wasn't missing anything | 14:04 |
| rvba | natefinch: of course, we only have that information if MAAS is configured to manage the dhcp server. | 14:05 |
| natefinch | rvba: ahh, hmm, interesting point... so it's not something we would be able to rely on being there 100% anyway. OK, good to know. | 14:06 |
| rvba | Now that I think of it, I'm pretty sure the IP is displayed on the UI (on a node's page) so it really should be on the API. Let me check… | 14:06 |
| rvba | natefinch: confirmed (it's even me who added that a couple of weeks ago), the list of IP addresses attached to a node is a field on the json representation of a node you get when querying the API. | 14:09 |
| rvba | Again, it's the empty list if MAAS does not manage the dhcp server. | 14:10 |
| rvba | natefinch: https://bugs.launchpad.net/maas/+bug/1064777 | 14:11 |
| ubot5 | Launchpad bug 1064777 in MAAS "If a node's IP address is known, it's not shown anywhere" [High,Fix committed] | 14:11 |
| natefinch | rvba: nice | 14:12 |
| natefinch | rvba: now about azure.... | 14:14 |
| mgz | excellent, and the api is already multiple-ip-address aware | 14:15 |
| natefinch | rvba: the only IP Address I see exposed in azure is on RoleInstance... I'm not really very familiar with the object model of Azure, so I'm not sure if that's the correct place to be getting it from | 14:16 |
| rvba | natefinch: Azure's model allows you to do complex things. For juju, we use a simple model which is one juju node = one hosted service with one deployment in it containing one role instance. | 14:18 |
| natefinch | rvba: ahh, good, that's exactly the information I was missing | 14:19 |
| mgz | rvba, given the HostedServiceDescriptor on azureInstance, how do you get to RoleInstance? | 14:19 |
| rvba | natefinch: we really should put a tiny README file somewhere in the Azure provider code. /me writes a note about that. | 14:20 |
| rvba | mgz: just one sec, let me check something… | 14:21 |
| natefinch | rvba: this is what I had come up with: http://pastebin.ubuntu.com/5992900/ | 14:21 |
| rvba | mgz: yes, the way natefinch has done it seems right (modulo the fact that the deployment might be in progress in which case RoleInstanceList[0] will blow up). | 14:24 |
| natefinch | Good point, I'll throw in a check to make sure it's non-empty | 14:24 |
| rvba | natefinch: is that returning the internal or the external IP address by the way? | 14:24 |
| natefinch | rvba: depends on what that IP address represents :) We're planning to expose both... this was just me hacking around to figure out how the object model works | 14:25 |
| rvba | natefinch: each machine has an internal IP used for machine to machine communication (that IP belongs to the internal Virtual Network attached — conceptually — to each environment) and an external IP which is what you get when you resolve the hostname. | 14:27 |
| rvba | natefinch: the IP Address you're returning here is the internal IP. | 14:30 |
| mgz | rvba: have you guys figured out what the scope of internal ips is? | 14:31 |
| rvba | mgz: the scope of internal ips? | 14:32 |
| mgz | is it across the whole cloud, or constrained to your account or deployment? | 14:32 |
| rvba | natefinch: that's a real-world result of what you get back from a GetDeployment API request to Azure: http://paste.ubuntu.com/5992942/ | 14:34 |
| rvba | natefinch: as you can see, the external IP is also there, but in the VirtualIPs section at the bottom (AFAIK that's not something gwacl captures but that would be very easy to add). | 14:34 |
| mgz | that's probably worth doing, can be a follow up merge proposal that depends on a gwacl change | 14:37 |
| rvba | Very easy for us to do… just file the bug please :) | 14:38 |
| mgz | I was thinking we could just do it :0 | 14:38 |
| rvba | Even better :) | 14:39 |
| natefinch | mgz: we want to return both the internal and the external IP, right? | 14:40 |
| mgz | natefinch: yup, but just the (external) hostname and internal ip is fine for a start | 14:41 |
| natefinch | mgz: ok, cool | 14:41 |
| rvba | natefinch: fwiw, here is a "graphical" representation of how the Azure provider uses Azure objects: http://paste.ubuntu.com/5992973/ | 14:47 |
| natefinch | rvba: nice, thanks | 14:48 |
| rvba | natefinch: and here is the result of listing the nodes on a live MAAS server with the CLI (which uses the API): http://paste.ubuntu.com/5992978/ | 14:48 |
| natefinch | rvba: great | 14:50 |
| natefinch | rvba: one last question - are both the maas and azure addresses assumed to be IPv4? | 14:58 |
| rvba | natefinch: maas parses the lease file written by the dhcp server. Right now the dhcp server is configured to use IPv4. | 15:00 |
| natefinch | rvba: but in theory it could be IPv6 at some point, then? I guess it's safer not to assume v4 | 15:01 |
| rvba | natefinch: yes | 15:01 |
| rvba | natefinch: in Azure, gwacl treats the IP as strings. And apparently Azure only speaks IPv4. | 15:01 |
| mgz | we can detect from the string we get | 15:01 |
| natefinch | rvba: huh interesting. ok | 15:01 |
| natefinch | mgz: yeah, I was just looking at that | 15:01 |
| mgz | I've not written in every nice constructor for addresses yet | 15:02 |
| natefinch | mgz: no big deal. really, it doesn't need a constructor, the only part that you might want to calculate is the AddressType | 15:03 |
| rvba | natefinch: internally MAAS uses netaddr which is totally ready to use IPv6 addresses. | 15:04 |
| mgz | natefinch: right, and NewAddress does that (but doesn't set the other fields) | 15:05 |
| === CyberJacob|Away is now known as CyberJacob | ||
| kurt__ | If I have my internet facing network for maas controller on network A (eth0 - 192.168.1.x) and my maas clients on network B (eth1 - 172.16.118.x) with DHCP enabled - can I give internet access to my clients? Do I need to enable IP forwarding on the maas-controller and what do I need to do for routing? | 15:42 |
| === CyberJacob is now known as CyberJacob|Away | ||
| kurt__ | If I have my internet facing network for maas controller on network A (eth0 - 192.168.1.x) and my maas clients on network B (eth1 - 172.16.118.x) with DHCP enabled - can I give internet access to my clients? Do I need to enable IP forwarding on the maas-controller and what do I need to do for routing? | 17:23 |
| roaksoax | kurt__: yeah you'd need NAT for the machines to access the internet | 17:24 |
| roaksoax | (but yes ip forwarding) | 17:25 |
| roaksoax | kurt__: but nothing for rounting. SO you only need to configure your iptables for NAT and that'd be all | 17:26 |
| kurt__ | so are iptables deployed on the clients by default? | 17:28 |
| roaksoax | kurt__: iptables are only needed on the maas server because it is the gateway to the internet | 17:29 |
| kurt__ | do I need to install iptables to get the NAT'ing I need to make this happen? | 17:30 |
| roaksoax | kurt__: yes, you need to configure iptables for NAT to work obviously | 17:30 |
| roaksoax | kurt__: for example: http://ubuntuforums.org/showthread.php?t=1715735&p=10608101#post10608101 | 17:31 |
| kurt__ | Thanks. I am running in to a problem with juju-gui requiring to do an apt-get update. This is one solution. But it's a little frustrating because it breaks the cloud model for maas | 17:31 |
| kurt__ | I guess another solution would be to install a locally mirrored repository | 17:33 |
| kurt__ | and do apt-get update against that | 17:33 |
| roaksoax | kurt__: so all the nodes you deploy with maas require internet access or as you said local mirror that can be resolved by the clients | 17:34 |
| kurt__ | roaksoax: will deploying iptables in the way the guide sent require more administrative tasks in the form of constantly updating iptables for all of my access needs, or does that configuration simply configure NAT and doesn't implement the blocking features of iptables? | 17:37 |
| kurt__ | I'm trying to weigh the benefits of each solution. I would assume best practices would be to have a locally installed mirror so it doesn't break mass's cloud model | 17:38 |
| roaksoax | kurt__: what are you referring with the cloud model? | 17:40 |
| roaksoax | we do say that maas client nodes require internet access to perform package installations | 17:40 |
| kurt__ | outside world should not have access to internal clients | 17:41 |
| roaksoax | so part of maas is being able to give internet access to the nodes | 17:41 |
| roaksoax | so if you do that by NAT'ing then that's completely fine | 17:41 |
| kurt__ | ah ok | 17:41 |
| kurt__ | I was thinking more along the lines of openstack | 17:41 |
| roaksoax | when you configure a default gateway for any node, (which is possible a router) the router does NAT | 17:41 |
| kurt__ | I have all of my clients pointed at the internal IP address of my controller | 17:42 |
| kurt__ | ie. 172.16.118.10 | 17:42 |
| roaksoax | kurt__: right | 17:42 |
| kurt__ | ok, I just need to get NAT set up | 17:43 |
| kurt__ | I'm deploying on vmware and am close to getting this working | 17:43 |
| roaksoax | yeah so that the machjines can get internet access | 17:43 |
| kurt__ | dealt with the time clock issues myself | 17:43 |
| roaksoax | jamespage: ^^ | 17:43 |
| roaksoax | are you deploying aginst vmware vm's? | 17:44 |
| kurt__ | yes :) | 17:44 |
| kurt__ | most everything is there.... | 17:44 |
| kurt__ | very close to getting it all working... | 17:44 |
| kurt__ | this is actually vmware fusion on mac osx | 17:44 |
| roaksoax | ah! so that's why the clock issues might have been related to.. | 17:45 |
| roaksoax | anyway i'll brb | 17:45 |
| kurt__ | I was even going as far as to try to get libvirt working in mac osx to auto-boot the machines | 17:45 |
| kurt__ | yes, but I figured out how to handle that | 17:45 |
| === CyberJacob|Away is now known as CyberJacob | ||
| kurt__ | roaksoax: these instructions worked: http://wernerstrydom.com/2013/02/23/configure-ubuntu-server-12-04-to-do-nat/ | 18:18 |
| roaksoax | kurt__: cool | 18:37 |
| kurt__ | apt-get update still isn't working correctly on the client node :( | 18:38 |
| roaksoax | kurt__: make sure you can access the internet | 18:42 |
| kurt__ | roaksoax: http://pastebin.ubuntu.com/5993771/ | 18:42 |
| roaksoax | kurt__: and what happens when you do apt-get update ? | 18:44 |
| roaksoax | or sudo apt-get update | 18:44 |
| kurt__ | http://pastebin.ubuntu.com/5993719/ | 18:44 |
| roaksoax | kurt__: are you sure you are using a correct ppa? | 18:45 |
| roaksoax | Err http://ppa.launchpad.net quantal/main i386 Packages 404 Not Found | 18:45 |
| roaksoax | kurt__: there's no quantal ppa | 18:45 |
| roaksoax | for it | 18:46 |
| roaksoax | only precise and raring | 18:46 |
| roaksoax | kurt__: https://launchpad.net/~juju-gui-charmers/+archive/stable check there on the "Published In:" | 18:46 |
| kurt__ | I was using this guide http://ceph.com/dev-notes/deploying-ceph-with-juju/ originally, then went to the bzr branch | 18:47 |
| roaksoax | kurt__: well the PPA being used does not exist. can you pastebin your /etc/apt/source.list | 18:48 |
| kurt__ | cat: /etc/apt/source.list: No such file or directory | 18:49 |
| roaksoax | kurt__: sources.list sorry | 18:49 |
| kurt__ | http://pastebin.ubuntu.com/5993789/ | 18:50 |
| roaksoax | kurt__: what about whatever is under /etc/apt/sources.list.d/ | 18:50 |
| roaksoax | kurt__: another thing, you are using quantal for that node, while the guide says to use precise (Ubuntu 12.10 LTS) | 18:52 |
| kurt__ | http://pastebin.ubuntu.com/5993799/ | 18:53 |
| kurt__ | I thought Quantal was 12.10? | 18:54 |
| kurt__ | and Precise was 12.04? | 18:54 |
| roaksoax | where is this comming from: Failed to fetch http://ppa.launchpad.net/juju-gui-charmers/stable/ubuntu/dists/quantal/main/binary-amd64/Packages 404 Not Found | 18:54 |
| roaksoax | the juju-gui-charmers/stable in quantal ppa does not exist | 18:55 |
| roaksoax | so there should be a place where that's happening | 18:55 |
| roaksoax | or that is | 18:55 |
| kurt__ | maybe from the bzr branch I'm using for juju-gui locally? | 18:55 |
| roaksoax | maybe | 18:56 |
| roaksoax | but that is apt-get update failing | 18:56 |
| kurt__ | when I run the apt-get update...right | 18:56 |
| roaksoax | so something either in sources.list or sources.list.d/ | 18:56 |
| kurt__ | that is being run directly from the node | 18:56 |
| roaksoax | has that ppa | 18:56 |
| roaksoax | right but that ppa must have been added in sources.list.d/ somehwere for it to show up in apt-get update | 18:57 |
| kurt__ | its in the pastebin I put in I think | 18:57 |
| kurt__ | in /etc/apt/sources.list.d/juju-pkgs-quantal.list | 18:58 |
| roaksoax | yeah that's for juju | 18:58 |
| roaksoax | but not for juju-gui-charmers PPA | 18:58 |
| roaksoax | this =-> http://ppa.launchpad.net/juju-gui-charmers/stable/ubuntu/dists/quantal/main/binary-amd64/Packages is ppa:juju-gui-charmers/stable | 18:58 |
| kurt__ | ah…I should be looking on root node I think | 18:58 |
| kurt__ | I missed this one: http://pastebin.ubuntu.com/5993870/ | 19:14 |
| kurt__ | roaksoax: do I need to comment one of those out or remove that entirely? | 19:16 |
| roaksoax | kurt__: comment it out and do: sudo add-apt-repository ppa:juju-gui-charmers/devel | 19:26 |
| roaksoax | maybe the charm tries to import that ppa that doesn't exist | 19:26 |
| kurt__ | I just hacked it to point to precise -is your way better? | 19:26 |
| kurt__ | I was looking at this https://code.launchpad.net/~bac/charms/precise/juju-gui/unified-ppa/+merge/167039 | 19:27 |
| roaksoax | you could do that but that's pretty much a broken approach on how to obtain things if the systems is quantal and you are trying to install precise packages | 19:28 |
| kurt__ | are you referring to what they are doing in the url or my approach with hacking for precise? :) I assume the latter | 19:30 |
| roaksoax | yeah | 19:30 |
| roaksoax | the latter | 19:30 |
| roaksoax | check the juju-gui charm you are using, probably it is the one setting that repository (ppa) when it shouldn't | 19:31 |
| roaksoax | or maybe you need to use precise instead of quantal | 19:31 |
| roaksoax | this should relly be uncomplicated | 19:31 |
| kurt__ | isn't that the purpose of charms? :P | 19:31 |
| kurt__ | lol | 19:31 |
| roaksoax | yes | 19:31 |
| roaksoax | exactly | 19:31 |
| roaksoax | but maybe you are deploying a precise charm in quantal | 19:31 |
| roaksoax | and that's whats causing the issue | 19:32 |
| kurt__ | that is exactly what I'm doing | 19:34 |
| roaksoax | then that's why it is failing | 19:34 |
| roaksoax | you shoul;d be using precise | 19:34 |
| kurt__ | because there's no quantal charm for juju-gui, right? | 19:34 |
| roaksoax | yeah | 19:34 |
| roaksoax | there's probably a bug in that charm too | 19:35 |
| kurt__ | besides the one that is referenced in that ceph guide - which appears to be broken | 19:35 |
| roaksoax | yeah probaly things chagned since it was written (the guide) | 19:35 |
| kurt__ | so what do you suggest? | 19:35 |
| roaksoax | redeploy in precise | 19:35 |
| kurt__ | reverting to precise | 19:35 |
| kurt__ | ok | 19:35 |
| roaksoax | kurt__: or check the charm config for the juju-gui charm | 19:35 |
| roaksoax | to see if it allows you to change the ppa where to install juju-gui from | 19:36 |
| kurt__ | what part of the charm controls that, do you know? | 19:37 |
| kurt__ | or is it done in the environments.yaml? | 19:38 |
| roaksoax | maybe in config.yaml | 19:38 |
| roaksoax | i'd sugesst that the easiest is to use precise | 19:38 |
| roaksoax | the easies and fastest | 19:38 |
| kurt__ | can precise images be easily mixed with quantal maas cntrl? | 19:39 |
| roaksoax | yes | 19:39 |
| roaksoax | when you juju deploy you can specify the release you want to install IIRC | 19:39 |
| roaksoax | or you do it in environments.yaml | 19:39 |
| kurt__ | http://pastebin.ubuntu.com/5993936/ | 19:40 |
| kurt__ | will I need to destroy my maas environment then? | 19:40 |
| roaksoax | kurt__: yeah change that to precise | 19:40 |
| roaksoax | kurt__: yeah | 19:41 |
| kurt__ | darned :) | 19:41 |
| roaksoax | hold on | 19:41 |
| kurt__ | getting all of the time stuff to work correctly is a bit of a pain | 19:41 |
| roaksoax | heh not really, it is quite easy tbh | 19:42 |
| kurt__ | not with vmware ;) | 19:42 |
| roaksoax | but i guess we lack some documentation to get quick started | 19:42 |
| kurt__ | I have to set stuff manually in vmware | 19:42 |
| kurt__ | to get OAuth to work | 19:43 |
| kurt__ | roaksoax: were you checking something before I move forward? | 19:46 |
| kurt__ | you asked me to wait | 19:46 |
| roaksoax | yeah but nonne replies | 19:47 |
| roaksoax | yeah just destroy and restart | 19:51 |
| kurt__ | ok. thanks roaksoax. This has been a process trying to get this working :D | 19:59 |
| roaksoax | heh i bet ;) | 20:04 |
| kurt__ | roaksoax: what's the destroy env command for maas? | 20:35 |
| roaksoax | kurt__: juju destroy-environment | 20:36 |
| kurt__ | that's juju | 20:37 |
| kurt__ | oh, that's all I need to do then, right? | 20:37 |
| kurt__ | maas will recommission nodes | 20:37 |
| kurt__ | got it | 20:37 |
| kurt__ | do I want to get rid of that juju-origin: ppa parameter? | 20:40 |
| kurt__ | roaksoax: success! juju-gui running on vmware fusion on mac osx! :D | 22:41 |
| roaksoax | kurt__: nice!! see it wasnt so hard once you use precise ;) | 22:42 |
| kurt__ | I had a lot of problems in the beginning. I think its essential for the internal clients to have internet access. | 22:44 |
| kurt__ | Next on the agenda is to get openstack working :) | 22:44 |
| kurt__ | And to make libvirt work with OSX so maas can automatically start hosts. That part is tricky | 22:45 |
| === CyberJacob is now known as CyberJacob|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!