=== med_ is now known as Guest80711 | ||
=== mup_ is now known as mup | ||
mup | Bug #1520645 opened: Unable to enlist node in gMAAS <MAAS:Confirmed> <https://launchpad.net/bugs/1520645> | 09:36 |
---|---|---|
=== nagyz_ is now known as nagyz | ||
=== cpaelzer is now known as cpaelzer_afk | ||
thoms | Hello. I need help about adding a "vmware" (vcenter) node to MAAS. I added the Vcenter CA to the openssl store of the MAAS server but when I try to add a chassis, vmware I keep getting Failed to probe and enlist VMware nodes: (vim.fault.HostConnectFault) {#012 dynamicType = <unset>,#012 dynamicProperty = (vmodl.DynamicProperty) [],#012 msg = '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify faile$.. does MAAS have an alternativ | 10:14 |
=== dooferlad_ is now known as dooferlad | ||
=== cpaelzer_afk is now known as cpaelzer | ||
=== smoser` is now known as smoser | ||
=== lifeless_ is now known as lifeless | ||
=== cpaelzer is now known as cpaelzer_afk | ||
=== cpaelzer_afk is now known as cpaelzer | ||
nagyz | blake_r, are you around? | 12:45 |
=== CyberJacob is now known as zz_CyberJacob | ||
blake_r | nagyz: yeah | 13:29 |
nagyz | blake_r, I was wondering about https://bugs.launchpad.net/maas/+bug/1495779 | 13:31 |
nagyz | not sure if people get notified for closed bugs, so pinged you here. :) | 13:32 |
nagyz | does my comment make any sense? if not, I'd be happy to elaborate | 13:32 |
nagyz | currently scripting setup of nodes so they use 2 interfaces for bonding and I was hoping I wouldn't need to click through 100+ nodes :P | 13:32 |
blake_r | nagyz: unconfigured on the UI is the same a mode=link_up | 13:33 |
blake_r | nagyz: so its doing the same thing | 13:33 |
nagyz | is there actually any difference if I leave it on the subnet vs unconfigured for an interface that won't have an IP actually? | 13:34 |
blake_r | nagyz: being on a subnet with mode=link_up is just like being unconfigured | 13:34 |
blake_r | nagyz: the subnet is just meta data to say this interface has access to this subnet, so it places that interface in that space, but unconfigured in that space | 13:34 |
blake_r | nagyz: it is designed that way for running something like the neutron gateway on that node, which needs its endpoint in a space, but must not have any ip address configured on that interface | 13:35 |
nagyz | ok, let me try if setting mode=link_up actually does what I want. | 13:36 |
nagyz | in the meantime, are you aware of any DNS/DHCP related issues in 1.9? | 13:36 |
nagyz | I think I'm still seeing a behaviour where enlisting just gets broken if I enable DNS support (but would need a lot of time to reproduce in a clean setup) | 13:36 |
blake_r | nagyz: that is very strange, let me know if you can get more detail on that | 13:41 |
nagyz | ok, I can try it in a clean environment later - I'd love to use the built-in DNS functionality instead of writing a sync script to designate... :-) | 13:41 |
nagyz | so going back on how to clear an interface... | 13:41 |
nagyz | basically by default after commissioning there is an interface on the subnet with an auto assign IP | 13:42 |
nagyz | my script then goes, creates a bond from two other interfaces, and sets the bond iface to static | 13:42 |
nagyz | and now this is the part where I'd like to clear the original interface. | 13:42 |
nagyz | http://pastebin.com/X8WwbLVt | 13:43 |
nagyz | this is the current iface definition | 13:43 |
nagyz | running interface link-subnet id id mode-link_up gets me an error message | 13:43 |
nagyz | "Cannot configure interface to link up (with no IP address) while other links are already configured" | 13:44 |
=== zz_CyberJacob is now known as CyberJacob | ||
nagyz | if I click "unconfigured" on the web now, the links array becomesempty basically | 13:44 |
nagyz | I'm sure I'm missing something. | 13:50 |
nagyz | if I do an unlink-subnet, then the IP address association disappears | 13:56 |
nagyz | but even after I cannot run link-subnet ... mode=link_up | 13:57 |
nagyz | blake_r? :-) | 14:31 |
blake_r | nagyz: you need to remove all links and then it will go to LINK_UP automatically which is unconfigued | 14:39 |
blake_r | nagyz: you cannot set it to link_up with other links created | 14:39 |
nagyz | how would i do this from the cli? | 14:39 |
blake_r | nagyz: when you create the bond the parent interfaces will all go directly to configured | 14:39 |
nagyz | eg remove all links | 14:39 |
blake_r | nagyz: you need to call "unlink_subnet" with "link_id=<id>" | 14:40 |
nagyz | that doesn't work as discussed in the bug report - I just get back the same as it was just with a different id | 14:40 |
nagyz | or I really don't understand something. | 14:40 |
blake_r | nagyz: when you create a bond the parents will go to unconfigured | 14:40 |
blake_r | nagyz: you dont need to do that manually | 14:40 |
blake_r | nagyz: and by default the bond will be unconfigured as well | 14:41 |
nagyz | yes, I understand that. the bond is working fine | 14:42 |
nagyz | so by default I have 4 interfaces, eth{0,1,2,3}. by default when I enlist it's using eth0 but I want to create a bond of eth1 and eth2. | 14:47 |
nagyz | bonding works, I've managed to script that fully | 14:47 |
nagyz | however, now even though it's pxebooting from eth0, it will only need to configure bond0 (and eth1 and eth2 as slaves) in /etc/network/interfaces | 14:47 |
=== cpaelzer is now known as cpaelzer_afk | ||
nagyz | so what I want is to explain to maas that "please forget that eth0 had any networks" | 14:48 |
nagyz | unlink-subnet does clear the IP assignment (from the GUI I can see it going from "auto assign" to "unconfigured") | 14:49 |
nagyz | but I'm still looking for the CLI equivalent of setting the subnet to unconfigured on the GUI - and the referenced command in the bug (mode=link_up) is not that. | 14:50 |
nagyz | I'm not sure I can describe my issue any more clear :-) | 14:51 |
=== cpaelzer_afk is now known as cpaelzer | ||
=== cpaelzer is now known as cpaelzer_afk | ||
nagyz | is it clear now what I'd like to accomplish? | 14:52 |
=== cpaelzer_afk is now known as cpaelzer | ||
=== dannf` is now known as dannf | ||
blake_r | nagyz: if the only link on the interface is link_up, then it will be unconfigured in the WebUI | 15:20 |
blake_r | nagyz: if you need to remove other links use link_subnet | 15:21 |
nagyz | blake_r, there is only a single link there and no way to get rid of it from the CLI. | 15:27 |
nagyz | if I select "unconfigured" from the GUI then I see the links array as empty | 15:27 |
blake_r | nagyz: that is incorrect then from the UI, all links should never go away that is a bug | 15:28 |
blake_r | nagyz: the API is correct having one link is just like unconfigured | 15:28 |
blake_r | nagyz: that link needs to be LINK_UP | 15:28 |
nagyz | http://pastebin.com/BCjvCqvn | 15:29 |
nagyz | before and after clicking | 15:29 |
nagyz | mode stays link_up, but the subnet definition is totally gone | 15:29 |
nagyz | unlike with unlink-subnet, where it always stays there. | 15:30 |
blake_r | nagyz: if the link is "LINK_UP" the subnet is not used on the deployed node, it is only there for metadata and to place the node in that space "aka. the space the subnet belongs" | 15:31 |
nagyz | I understand that, but I'd really like to get rid of it - to do the exactly same thing as on the UI. | 15:32 |
nagyz | now, either the UI is faulty as I can set the subnet unconfigured (which removes the whole subnet definition for the interface) | 15:32 |
nagyz | or the CLI is inconsistent as it doesn't allow this | 15:32 |
blake_r | nagyz: then just do "link_subnet mode=link_up" on the interface once it has only that one "link_up" | 15:38 |
nagyz | I cannot do that as that raises the error that I refered to above | 15:39 |
nagyz | the point would be to replace clicking on the GUI to set the interface's subnet to "unconfigured" :-) | 15:39 |
nagyz | maybe I should have started with that | 15:39 |
blake_r | nagyz: well then that is a bug as you should be able to perform that operation | 15:40 |
nagyz | shall I open a bug? :-) | 15:44 |
blake_r | nagyz: yes please | 15:44 |
mup | Bug #1540453 opened: API doesn't indicate whether a node is deployable <kanban-cross-team> <landscape> <MAAS:New> <https://launchpad.net/bugs/1540453> | 16:31 |
mag009_ | hey | 16:43 |
mag009_ | hi I'm trying to deploy a xenial over maas but it seem that the image is not able to load the following module when deploying : nls_iso8859_1 it is required to mount the efi partition in fat32 | 18:13 |
mag009_ | boot.log show this : can't create directory '/root/lib/modules': Read-only file system | 18:17 |
mup | Bug #1540522 opened: Xenial deploy failed at efi mount <MAAS:New> <https://launchpad.net/bugs/1540522> | 18:35 |
mup | Bug #1540528 opened: [1.9] cannot scrub subnet information from interface <MAAS:New> <https://launchpad.net/bugs/1540528> | 18:47 |
roaksoax-brb | /wi/win 4 | 18:50 |
mup | Bug #1540528 changed: [1.9] cannot scrub subnet information from interface <MAAS:Confirmed> <https://launchpad.net/bugs/1540528> | 18:56 |
mup | Bug #1540528 opened: [1.9] cannot scrub subnet information from interface <MAAS:Confirmed> <https://launchpad.net/bugs/1540528> | 19:05 |
mup | Bug #1540522 changed: Xenial deploy failed at efi mount <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522> | 19:29 |
mup | Bug #1540539 opened: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539> | 19:29 |
mup | Bug #1540539 changed: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539> | 19:32 |
mup | Bug #1540522 opened: Xenial deploy failed at efi mount <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522> | 19:32 |
mup | Bug #1540522 changed: Xenial deploy failed at efi mount <curtin:New> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1540522> | 19:35 |
mup | Bug #1540539 opened: MAAS installation: bind9 chokes on duplicate dnssec-validation setting <canonical-bootstack> <MAAS:Confirmed> <https://launchpad.net/bugs/1540539> | 19:35 |
mup | Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548> | 19:35 |
mup | Bug #1540548 changed: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548> | 19:41 |
mup | Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548> | 19:44 |
mup | Bug #1540548 changed: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548> | 19:47 |
mup | Bug #1540548 opened: MAAS installation doesn't create database config <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1540548> | 19:59 |
Skaag | I'm stuck with the "Getting started" document, I have two machines both running MAAS, I have em1 and em2 on both of them (em2 being the private network) | 21:05 |
Skaag | If someone is willing to give me a few minutes to help me get up and running, that will be wonderful and much appreciated | 21:05 |
Skaag | I'm not sure how to get the two machines to cluster, for example | 21:05 |
nagyz | why do you have two machines? | 21:38 |
nagyz | for simple installations you can run one machine | 21:38 |
nagyz | I guess depends on your node size, but for my ~120 nodes in the system, 1 maas is enough | 21:38 |
Skaag | I see | 21:39 |
Skaag | I just realized yesterday that the way this works is that you can setup MAAS itself even on a relatively weak VM | 21:39 |
Skaag | and let the hardware boot via PXE | 21:39 |
Skaag | but what's not clear to me is: the physical machine boots via PXE, how do you run multiple VM's on the same metal? | 21:40 |
Skaag | does some "layer" get booted first via PXE, which then allows running multiple VM's also via PXE? | 21:41 |
nagyz | not sure I even understand the question... | 21:41 |
nagyz | do you want to provision physical servers or VMs? | 21:41 |
nagyz | for example we use maas to provision our physical nodes but we use openstack for vms | 21:41 |
nagyz | maas is not orchestrating VM creation and whatnot | 21:42 |
Skaag | I want to use openstack for VMs | 21:44 |
Skaag | I have two relatively powerful machines with tons of storage | 21:44 |
Skaag | normally I would use something like proxmox to take as much advantage of the hardware as possible | 21:45 |
Skaag | (since all VM's are private, and absolute 100% hack proof isolation is not important) | 21:45 |
nagyz | so why not use proxmox? | 21:45 |
nagyz | for 2 machines you don't need maas... | 21:45 |
nagyz | esp since you can't use maas AND proxmox together as proxmox has it's own installer | 21:46 |
Skaag | I want to create a setup that mimics as much as possible what cloud providers offer | 21:46 |
nagyz | no cloud provider tells you how they provision their infrastructure, usually | 21:47 |
nagyz | and proxmox doesn't support any "cloud". | 21:47 |
roaksoax-brb | Skaag: maas uses VM's as if they were hardware | 21:47 |
nagyz | you can use maas to deploy the hardware and then install openstack using juju for example | 21:47 |
nagyz | roaksoax-brb, a quick question re. the bcache bug in 1.9 + the official trusty image: what's the plan there? :-) | 21:47 |
roaksoax-brb | nagyz: can you point me to the bug ? maybe the issue is not actually in MAAS but curtin | 21:48 |
roaksoax-brb | Skaag: When you tell MAAS "mannage this VM" or "This chassis (which can be a host with VMs") MAAS uses it as if it were individual hardware out there | 21:49 |
nagyz | https://bugs.launchpad.net/maas/+bug/1514094 | 21:49 |
roaksoax-brb | Skaag: MAAS won't make any distinction between a VM and a baremetal machine | 21:49 |
nagyz | right it's a curtin bug actually... | 21:49 |
nagyz | but breaks using bcache via maas :) | 21:50 |
roaksoax-brb | nagyz: seems fixed thought. What cucrtin version are you using ? | 21:50 |
nagyz | roaksoax-brb, whatever is in the image that maas uses to deploy trusty from the /releases repo :-) | 21:51 |
roaksoax-brb | nagyz: curtin is not in the images. Curtin is installed in the MAAS server actually | 21:51 |
roaksoax-brb | nagyz: dpkg -l | grep curtin in the MAAS Server | 21:51 |
nagyz | on the maas node apt-cache show tells me it's 0.1.0~bzr314-0ubuntu1 | 21:51 |
roaksoax-brb | nagyz: the bug seems fixed on rev304 and rev306 | 21:53 |
roaksoax-brb | nagyz: so that fix is in curtin | 21:53 |
nagyz | I can give it a go again but we've just tried creating bcache backed drives and it didn't work out | 21:53 |
nagyz | saw a bunch of modprobe bcache errors | 21:53 |
roaksoax-brb | nagyz: try using the MAAS daily image s? | 21:54 |
roaksoax-brb | nagyz: and please pb the intsall output, and I can raise it with the curtin guys | 21:54 |
nagyz | yeah let me give that a go | 21:54 |
nagyz | that nerve-wrecking moment when you do a "cat config-generated-from-python | ssh backbone-switch-1"... :) | 22:08 |
nagyz | the switch config was actually generated by a python script from maas's lldp discovery data | 22:09 |
nagyz | and it configures over 200 ports now | 22:09 |
Skaag | roaksoax-brb: I see, so I could in theory start an instance using whatever virtualization solution I have, and just tell it to boot via PXE | 22:35 |
roaksoax-brb | Skaag: correct | 22:38 |
roaksoax-brb | Skaag: or if you have pre-created/described say, 10 VM's in say KVM or VMWare ESXi, and you can literally add them all in one go with MAAS | 22:39 |
roaksoax-brb | Skaag: with the 'Add Chassis' from the webui | 22:39 |
Skaag | understood | 22:39 |
Skaag | so then what I need to do is install openstack directly on those two ubuntu machines, and MAAS on a separate machine, just to hold the images, and control provisioning | 22:39 |
Skaag | but then if I install openstack, what is the advantage of using a tool such as MAAS, wouldn't it be a duplicate? | 22:40 |
roaksoax-brb | Skaag: you can use MAAS/juju to install openstack directly | 22:41 |
roaksoax-brb | Skaag: openstack itself will allow you to deploy instances in the cloud, you don't really need maas for that | 22:41 |
Skaag | I see | 22:41 |
roaksoax-brb | Skaag: if you want to deploy workloads in those instances, you can use Juju with the OpenStack provider | 22:41 |
Skaag | but in my case because all I have is 2 machines dedicated to openstack, there's little benefit. I guess MAAS is really for larger outfits who deploy a LOT of hardware all the time (and dynamically) | 22:42 |
Skaag | and they can take them up/down depending on demand | 22:42 |
Skaag | and everything is 100% dynamic | 22:42 |
roaksoax-brb | Skaag correct | 22:42 |
Skaag | thank you, I feel I understand the structure much better now | 22:42 |
roaksoax-brb | Skaag: if say, you don't put OpenStack on those 2 machines, but you do have 50 VM's running, you can deploy those with MAAS | 22:42 |
Skaag | I have no idea how to do that | 22:43 |
Skaag | I have MAAS right now on those two machines | 22:43 |
Skaag | the idea with creating two instances was for redundancy | 22:43 |
Skaag | but I don't know how to make them aware of each other (cluster) | 22:43 |
Skaag | and further, I don't know how to create VM instances under maas | 22:43 |
mup | Bug #1540453 changed: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453> | 22:47 |
nagyz | roaksoax-brb, would maas 1.9 be able to power on VMs on vSphere using it's API instead of WOL? | 22:48 |
nagyz | and if so, how does a "chassis" map to VMs in VMware? is it only based on prefix? or is it a folder name? | 22:49 |
roaksoax-brb | Skaag: MAAS doesn't yet have native HA | 22:52 |
roaksoax-brb | nagyz: MAAS 1.8+ IIRC supports VMWare products, but the support is based on python-pyvmomi's library, which is VMware's | 22:52 |
roaksoax-brb | nagyz: you dont really need WoL | 22:52 |
roaksoax-brb | nagyz: when you add a "chassis" you can send a prefix filter | 22:53 |
nagyz | roaksoax-brb, so if I actually want maas to start the VM, will it do it via calling the native API? | 22:54 |
roaksoax-brb | nagyz: yes | 22:56 |
roaksoax-brb | nagyz: maas never really supported VMWare until we added support on 1.8... or 1.7 even | 22:56 |
roaksoax-brb | can't recall of the top of my head :) | 22:56 |
nagyz | it would be cool to experiment with juju there instead of physical nodes:-) | 22:57 |
nagyz | (I know I know, I could use AWS or OS underneath as well) | 22:57 |
nagyz | any quick way to get back the system IDs from maas CLI sorted by the system name...? :) | 22:58 |
nagyz | tried to do it with | jq but haven't managed so far | 22:58 |
Skaag | I'd just pipe it through cut + sort | 23:01 |
Skaag | or maybe that's not very good since it would only give you the name | 23:01 |
Skaag | oh it's a json output. sorry, my bad. | 23:02 |
mup | Bug #1540453 opened: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453> | 23:03 |
nagyz | | jq '.[] | {name:.hostname,id:.system_id}' | jq -s '. | sort_by(.name)' | 23:03 |
nagyz | this works | 23:03 |
roaksoax-brb | nagyz: you can use juju too i'd think | 23:09 |
nagyz | roaksoax-brb, right it only talks to maas :-) so if maas provisioning works then I can use juju | 23:10 |
nagyz | that's the current plan | 23:10 |
nagyz | ok, thanks for the help, off to bed. | 23:10 |
nagyz | I'll open some dns bugreports tomorrow ;-) | 23:10 |
mup | Bug #1540453 changed: API doesn't indicate whether a node is deployable <landscape> <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1540453> | 23:12 |
roaksoax-brb | hehe | 23:12 |
dgrossman | can someone point me to installing centos images in maas 1.8.3? I tried 'sudo maas admin boot-resources create name=centos/centos7 architecture=amd64/generic content@=centos7-amd64-root-tgz' do I need to generate an api key before trying to do this? | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!