[03:01] Bug #1673091 changed: Tags with dots are not saved [04:10] Bug #1677444 opened: [2.2b4] Cannot select composed machines from POD details to perform actions (e.g. deploy) [08:45] Hi all, I am very new to MAAS…. I was wondering if there were plans to include a ZFS as part of a booting file system that MAAS could manage ? [08:57] or has anyone done an network install using preseed, dhcp, tftp, http and live image where ZFS was the target root file system? [11:53] Bug #1677573 opened: [2.2] Static addresses can be allocated in dynamic range === frankban|afk is now known as frankban [14:26] Bug #1677631 opened: [2.2r5880, UI] Cannot scroll down to the bottom of the page [14:32] Bug #1677631 changed: [2.2r5880, UI] Cannot scroll down to the bottom of the page [14:35] Bug #1677631 opened: [2.2r5880, UI] Cannot scroll down to the bottom of the page [15:38] Bug #1677658 opened: [2.2, UI] Firefox selection of subtabs yields a big box === cmagina_ is now known as cmagina [17:01] With MaaS 2.2 (beta4), how to mark an "Interface" as "disconnected" again? [17:02] once you connect it to something, it is not possible to disconnect it agai, this works on MaaS Stable. [17:09] ThiagoCMC, how are you "connecting/disconnecting"? works for me using the web UI and editing the subnet === frankban is now known as frankban|afk [17:24] pmatulis, I'm going into MaaS 2.2 -> Nodes -> Interface -> Edit, there is no "disconnect" under "Fabrics". [17:29] ThiagoCMC: working on fixing that [17:29] ^_^ [17:29] ThiagoCMC: just to confirm, you were able to do that in 2.1 ? [17:29] yep [17:30] I just upgraded from MaaS 2.1, to 2.2, because it have better VLAN management but, when I tried to disconnect an interface, like I did many times last week, the option wasn't there anymore... [17:31] A workaround is to trash it, and re-commision, which takes a lot of time and headache... [17:32] ThiagoCMC: or do it via the APIAPI [17:33] Oh, cool! I'm not familiar with API, is it via maas CLI? [17:34] ThiagoCMC: yes [17:34] ThiagoCMC: next iteration of tmaas 2.2 will have that fixed [17:34] Awesome, I'll configure it, thanks! [17:34] Nice! :-D [17:55] How to link a new DNS domain, to a specific fabric/subnet/space ? [17:55] Is it possible? [17:57] Looks like that maas relies too much on top of the PXE network, but, I want to make the PXE network to be very minimalistic, only for PXE, nothing else... [18:13] ThiagoCMC: you can only link a domian to the machine [18:14] its IP on the DNS will still be the one from the PXE network? [18:15] Yep, it is... Just tested it... :-( [18:17] ThiagoCMC: all IP's a machine gets will be on the DNS [18:17] Hmm... [18:17] But if a machine have many fabrics, how to create a domain / subdomain for each fabric? [18:18] For example: eth0 - 192.168.0.1 - openstack-1.pub.mydomain.com, eth1 - 192.168.1.1 - openstack-1.admin.mydomain.com ? [18:32] ThiagoCMC: so basically, you want to have the ability to select what domain gets assigned per subnet ? [18:32] yep [18:32] how would that work on situations where you have 2 different machines in the same subnet and want to assign a different domain name [18:32] i.e. machine02.exaple.com [18:32] machine3.production.com [18:33] Right, well, I think that it should / can be flexible enough to do that... [18:34] however, since you said that all IPs of a server ends up on its DNS, I'll what is in there, so I can try to use it... [18:34] ThiagoCMC: well you can create a dns record against IP address [18:44] Mmm... Sounds cool! I'll dive into DNS / MaaS today... [19:03] is there any mechanism within MaaS to limit DNS zone transfers [19:03] I know that this can be done directly through bind, but was not sure whether the configuration would be overwritten by MaaS [19:06] Bug #1677713 opened: [2.2, trunk] Logout page is blank [19:47] Anyone else experiencing this error on the dashboard page? 'relation "maasserver_discovery" does not exist LINE 1: ...", "maasserver_discovery"."is_external_dhcp" FROM "maasserve... ^' I've change the postgresdb to live in AWS instead of locally and I start to see these issues [19:56] Anyone else experiencing this error on the dashboard page? 'relation "maasserver_discovery" does not exist LINE 1: ...", "maasserver_discovery"."is_external_dhcp" FROM "maasserve... ^' I've change the postgresdb to live in AWS instead of locally and I start to see these issues [20:24] mpontillo: ^^ strange error [20:26] cmd_pancakes: how did you move it to AWS? are you sure you preserved everything? that data is coming from a view that should exist; the MAAS region creates it when it starts [20:27] cmd_pancakes: does MAAS have sufficient administrative privileges on the AWS DB to create triggers and views? both are very important to the operation of MAAS. [20:36] Bug #1677573 changed: [2.2] Static addresses can be allocated in dynamic range [20:39] mpontillo: I basically just changed the settings in regiond.conf. Then I used maas-region syndb to have the migrations created [20:39] it was seemingly able to create all the required tables without any problems [20:40] mpontillo: i'm also using the MAAS region server in a docker container....so basically my dockerfile will install MAAS (which creates the local DB) then I copy over the modified regiond.conf that points to AWS [20:40] cmd_pancakes: I would restart maas-regiond while tailing /var/log/maas/regiond.log and see if there are any exceptions raised. MAAS is supposed to create the maasserver_discovery view when it starts up. [20:41] great, i'll give that a try now [20:46] mpontillo: tailing the logs on reboot more or less look good, rack controllers reconnect, etc...This is the only line that seems to be a related error: [20:46] mpontillo: 2017-03-30 20:42:08 maasserver.api.support: [warn] maasserver.api.domains.AnonDomainHandler does not have `resource_uri`. This means it may be omitted from generated documentation. Please investigate. 2017-03-30 20:42:08 maasserver.api.support: [warn] maasserver.api.zones.AnonZoneHandler does not have `resource_uri`. This means it may be omitted from generated documentation. Please investigate. [20:47] also this: [20:47] 2017-03-30 20:42:09 maasserver.regiondservices.active_discovery: [info] Active network discovery: Discovery interval set to 10800 seconds. 2017-03-30 20:42:09 maasserver.listener: [error] Unable to connect to database: dictionary changed size during iteration [20:48] this is the full exception of the error [20:48] cmd_pancakes: maasserver.listener: [error] Unable to connect to database: dictionary changed size during iteration [20:48] ^ that seems to be the relevant bit [20:49] cmd_pancakes: seems like something went wrong while MAAS was trying to update the triggers and views [20:49] yeah, that looked suspicious [20:50] cmd_pancakes: can you give more details about how you set up the postgres database? it seems using an amazon-hosted postgres DB would need to be further tested and validated [20:50] i couldn't seem to find any docs on setting up an external postgresDB. Yeah for sure! [20:50] cmd_pancakes: personally I would not recommend that approach; MAAS expects the postgres DB to be local and fast. the main reason I wouldn't suggest this is because MAAS stores OS images in the database. so having it somewhere on the internet could introduce serious slowdowns [20:51] yeah that makes sense...i was mostly trying this so that it could be more resilient to the container moving, but if thats not possible or the best method, thats probably working we can work with [20:52] but yeah basically i just started maas in a docker container with a regiond.conf file that points to aws [20:52] then in the container, i ran maas-region syndb, and it detects that the aws db is empty and starts running all the required migrations [20:52] and they all ran successfully so figured it should work fine [20:53] Hi, I have one node failed commissioning and the console shows failed posting event. I have another node which commissioned successfully around the same time. [20:53] cmd_pancakes: MAAS uses event-driven triggers to do things like live-update the UI, plus some server-side tasks, which will also fail if we aren't able to insert/update the triggers [20:54] 2.1.4+bzr5591-0ubuntu1 (16.04.1). the node will fail commissioning after the 20min timeout. [20:54] yep, i noticed the UI was not actively updating when i changed things also...had to reload the page for changes to occur [20:54] but alright cool, as long as i wasn't overlooking something easy...any change external databases would be supported in the future? [20:54] chance* [20:55] cmd_pancakes: it's definitely supported. I would just try using an Ubuntu server on your local LAN, not AWS [20:57] the region controller is also an EC2 instance if thats any better [20:57] and i have local rack controllers in each site handling dhcp/deployments and the region controller in the cloud [20:58] mpontillo: so you think the 'maasserver.listener: [error] Unable to connect to database: dictionary changed size during iteration' error is caused by latency? [20:58] im fine if things are slower than usual, this seems to be something actually preventing the updates [20:59] I checked the ssh access checkbox but ubuntu/ubuntu doesn't work to login. [20:59] cmd_pancakes: interesting approach! I would try using the same EC2 instance for the DB first [21:00] catbus1: allowing SSH access during commissioning uses the commissioning user's SSH keys. I don't think it works with username/password auth [21:01] oh [21:01] ok yeah i can give that a try...i mostly was looking to leverage the auto db backups of aws since the actual region/rack controllers may be ephemeral and didn't want to have to backup the DB manually [21:01] cmd_pancakes: well, I don't know the full details of how postgres is set up in your case. it might be a permission issue, not a latency issue. if it's a latency issue, I would expect it's some sort of race condition. I'm not aware of anything that depends on timing for that feature [21:02] cmd_pancakes: what I would to to triage this would be to isolate the "dictionary changed size during iteration" problem [21:02] makes sense...considering its coming from the same process thats probably related [21:03] cmd_pancakes: so I imagine you're using https://aws.amazon.com/rds/postgresql/? [21:03] Bug #1677741 opened: DNS resources with addresses that are assigned to interfaces on nodes do not get those addresses in the DNS [21:03] mpontillo: that is correct [21:04] getting more details now [21:04] cmd_pancakes: I strongly suspect it's something specific to that postgresql server and how it's set up. I bet it's highly customized and not exactly like the one that Ubuntu ships with. I bet there's a subtle difference there that causes the bug [21:04] definitely possible...this is also 9.5.4 and i believe the default maas uses is 9.5.6? [21:06] cmd_pancakes: good point, but MAAS has been tested with a wide range of postgres releases, way back to the ones that shipped with Ubuntu 14.04. So I doubt that's the problem. [21:08] cool...well i can go back to just using it locally in the ec2 instance...not really ideal since i'll have to do manual backups of the DB but not the end of the world. do you want me to make a ticket/follow up somewhere else with more details? this might be something others want to do in the future [21:12] mpontillo: ^ [21:14] cmd_pancakes: you could file a bug in MAAS asking to support Amazon RDS for PostgreSQL. https://bugs.launchpad.net/maas/+filebug -- I expect it will go onto the wishlist. or you could isolate the bug and follow up using amazon's support process [21:15] great, sounds good...thanks for the help mpontillo! [21:16] cmd_pancakes: np, good luck with MAAS! [21:17] thanks! i really love it so far...i basically wrote all this automation at my last position and to have it already as a project is awesome [21:17] cmd_pancakes: MAAS *is* pretty awesome ;-) [21:36] turns out the node wasn't pxe booting (no nic selected for network boot in bios) the whole time.