=== mup_ is now known as mup [10:01] How does maas compare to openstack? [10:42] are there any docs on upgrading from 2.1 to 2.2? [11:00] also with juju, with maas 2.2, how can you filter on subnets now that spaces are vlan based, instead of subnet based? [11:12] cnf: probably better to ask here how they're hoping to model those cases [11:13] hmm [11:14] cnf: I understand some of the rationale for it [11:14] it breaks things, though, with no option that i can see [11:14] I believe the underpinning is "any machine on the same vlan can pretend to be on any subnet" [11:15] as nobody from the outside could tell that they shouldn't be there [11:15] and thus the same 'space' [11:15] i find that to be very judgemental of other peoples networks [11:15] but I think there are (as you have) concrete realities around "yes, this port could be using 10.100, or 192.168, but I *want it to use 192* for these operations" [11:15] especially "routed should be good enough" [11:15] it isn't [11:16] i have "this VLAN has NO routes, at all" vlans [11:16] where you can add subnets [11:16] but one subnet in it is not the other [11:16] as there is no routing between them [11:17] cnf: so I thought vlan was supposed to be a "set of trunked switches", which if they are as you described, then they are separate vlans [11:17] jam: that's a fabric [11:18] from https://docs.ubuntu.com/maas/2.2/en/intro-concepts [11:22] so now, from what I can see, i have no way in juju to define what _subnet_ i want [11:22] at all [11:24] cnf: we upgraded our existing maas installation from 2.1 to 2.2, so far no big issue. Only find one bug https://bugs.launchpad.net/maas/+bug/1695229 [11:24] cnf: so if you can't model them as logically distinct VLANs (even if they had the same vlan-id they aren't logically the same space if they are swappable) [11:25] if they *aren't* swappable [11:25] jam: so you are saying create a different fabric for each? [11:26] but then i can't have 1 machine be in both at the same time [11:26] because an interface can only be on 1 fabric [11:27] and maas will not let you define the same vlanID twice on the same fabric [11:32] work calls, i'll be back in a bet [11:32] thanks for the help so far [11:35] mpontillo: ^^ [11:36] I'd be happy to discuss through how we might model some of these issues [12:02] ok, i'm back [12:02] cshen: good to know, but i'm guessing you didn't use spaces a lot? [12:10] cnf: what do you mean spaces? [12:10] I use maas basically as a hardware provisioning tool for our prive openstack cloud. [12:10] private openstack cloud [12:11] cshen: do you not use segmented networks for your openstack install? [12:12] you mean vlan? [12:12] we really do vlan in networking. [12:13] for instance, internal api, public api, storage, and so on. [12:15] cshen: you don't use juju? [12:16] or any automated way to get the machines from maas? [12:16] no, we don't use juju. [12:17] we write new machines into ansible inventory files. [12:17] so if you want to tell maas "i want a machine, it needs to be in this subnet / vlan" you'd use spaces [12:17] spaces where tied to subnets in 2.1 [12:17] and vlans in 2.2 [12:17] cnf: thanks for the ip. [12:17] tip [12:17] the transition is causing me problems [12:18] i have VLAN's that contain multiple non-routed subnets [12:18] and now i can no longer select which subnet needs to be used [12:19] non-routed subnets, meaning no gateway? [12:19] yep [12:21] jam: btw, a related, but different problem i have is IP assignment to LXD containers in juju [12:23] cnf: what do you mean "no longer select"? How do you "select"? [12:24] cshen: he used to be able to define 2 spaces that used the same vlan but had different subnets in them [12:24] cshen: in juju, with constraints [12:24] cshen: so i can say constraints: "spaces=admin-space,storage-space" [12:24] for example [12:25] cnf: oh, juju. I quit ;-) [12:25] well, they are maas spaces, but yes, from juju [12:28] jam: so i have subnets that really are _not_ under my control [12:28] i need to ask for IP's to use in them, and request ACL's to be changed per ip [12:28] i have no way to assign a specific IP to a specific container in juju, afaik [12:29] (also, a lot of my constraints stem from "this part is not under my control) [12:34] after Juju has registered a device, can you assign it a concrete address? [12:34] it certainly is a case of "dynamic machine allocation" which doesn't play nicely with "static IP address allocation" [12:36] jam: i don't know how to get juju to do that? [12:36] especially with containers [12:36] and yeah, i agree [12:36] but that's my reality [12:36] cnf: when you juju deploy --to lxd:X we will eventually have created a device in MAAS [12:37] I don't know if you can go to MAAS UI and play around with the IP associated with that container [12:37] no, once it's assigned, i can't [12:37] i can assign a static IP to a machine [12:37] cnf: do you have a pool that you could use, or is it "exactly this application has to use exactly that IP" ? [12:37] before it gets provisioned [12:38] jam: well, requesting "please open up all these ports for all ip's in this subnets" gets me a kind "why do you need all of those?" [12:39] a reply of "my tool doesn't let me get selective on which ip i assign" of course gets replied to with "not our problem" :P [12:39] i exaggerate, of course [13:15] Bug #1697931 opened: [2.2,snap] Proxy isn't running after installing the snap [13:51] Bug #1651165 changed: Unable to change disk name using maas gui

[14:30] Bug #1697949 opened: MAAS renames VGname back to vg0 === frankban|afk is now known as frankban [14:38] /3/win 16 [14:55] /4\win56/tab4\paragraph5 [14:55] oops, sorry [15:14] cnf: /win 4 [15:14] err [15:21] jam: interface constraints in MAAS are powerful enough to match on more than just spaces; is there a way to pass a constraint through so cnf can do this without changing the definition of a space? [15:23] jam: when the L3 -> L2 spaces issue was discussed, I remember thinking that we should have L2 spaces *and* L3 spaces so we could meet both of these use cases, but the team decided against that for simplicity sake IIRC [15:23] I guess that's coming back to bite us [15:25] on the other hand, the network setup here seems unusually difficult to model. cnf, if you can think of the simplest possible way to model your network in MAAS that would make things better for you, I'd like to hear it [15:26] Hey guys can maas provide dns/dhcp on an untagged lan or does it have to be vlans? [15:34] vlad_: untagged is fine [15:35] BjornT: Thanks man [16:37] Hey guys I just ran into an issue I have the controller connected to all the interfaces, but on one of them I have two non-tagged lans in as aliases. I can't seem to provide dhcp to all three of the subnets from the web-ui will I need to do something via the CLI to get this to work? [18:11] mpontillo: sorry had meetings [18:11] mpontillo: i'm tied with constraints from a network i consume, but don't maintain [18:12] admitedly, i'm already jumping through hoops in maas to accomodate that [18:15] cnf: Yeah I'm in the same boat as you. I've got a network that's not ideal for this maas managed set of nodes I want to deploy openstack to [18:16] yeah, doing openstack as well [18:31] jam: so is there any way in juju to place constraints on subnets, instead of spaces? [18:31] i see "networks" under legacy constraints... [18:32] cnf: Yeah most charms should have network definitions where you can specify lists of subnets [18:34] vlad_: how? [19:21] cnf: not sure how this is plumbed through to juju, but MAAS has an 'interfaces' constraint which is likely powerful enough to do what you need. it's like the legacy 'networks' constraint but lets you select individual interfaces instead of just on the whole box [19:21] jam: ^? [19:22] so my boxes only have 1 "interface" though [19:22] a bond of 2 10G links [19:22] everything else is vlans [19:23] cnf: ah, then you can probably use either the 'subnets' constraint. the 'interfaces' constraint would work if you had multiple interfaces and you needed to know which one matched which constraint [19:24] hi guys. I've noticed twice now that the MAAS API has been returning errors when using the API to provision a server, even though all of the syntax for the command is correct. Each time we've seen this, cycling maas-regiond is the only thing that fixed it. How can I collect the proper debug information to file this as a bug? [19:24] subnet constraint would work, but i don't think juju uses it? [19:24] cnf: that is, in MAAS 2.x (I think -- maybe 1.9) the 'networks' constraint was replaced with the 'subnets' constraint. [19:24] right [19:24] cnf: right, that's why I was asking jam -- I don't know how/if it's exposed in juju. vlad_ seems to think it is ;-) [19:24] well, i use subnets as constraints now, i just stick spaces to them :P [19:24] right [19:25] xygnal: I would take a look at /var/log/maas/regiond.log and check if there are any Python tracebacks [19:25] xygnal: if you find one, file a bug and include it, please! (which version of MAAS?) [19:26] xygnal: if you could pastebin it and send it to me here for a preview, I'll be able to confirm if it's enough to identify the issue [19:26] xygnal: if it is, just hit https://bugs.launchpad.net/maas/+filebug and get it logged! [19:28] mpontillo yes, there are. machine object is not iterable is the error, and there are indeed tracebacks. [19:28] oh, i see all my maas bugs where closed [19:28] unfortunately we've seen this happen both when their synatx was right, and when their syntax was wrong, so I am going to have to sort out which tracebacks were when the syntax was right [19:29] mpontillo 2.2 release FYI [19:48] mpontillo 1697986 [19:49] Bug #1697986 opened: API returns object is not iterable to valid API request for server deployment [19:50] xygnal: thanks! if you could try the "Accept:" header workaround, and/or provide example API calls that cause this problem (or share some code) that would be very helpful [19:50] xygnal: if it's the same as the "Accept" header issue, I'm not sure why restarting regiond would work around the problem [19:51] mpontillo do both of those workaround need to be in place at the same time? the way it was phrased was either or. [19:52] xygnal: it wouldn't hurt to make sure that accept header is always in place; if you do that you can remove the extra query string parameter for sure [19:52] mpontillo I tried the same request 4 times and got that error each time. THen I restarted maas-regiond, and my first repeat of the command worked. [19:52] xygnal: but I'm going to mark that bug incomplete, since we'll need the API call (or CLI equivalent) before we can reproduce this [19:53] xygnal: that's weird. if it's the "response is in a random format because it was unspecified" bug, I wouldn't expect it to be so consistent [19:54] honestly it appears to get 'worse' over time [19:54] until it reaches that point [19:54] the other day I was seeing it 'sometimes' but not every time [19:54] then today, ever time, until restart [19:55] xygnal: hm. that's bizarre. maybe there is a backlog of API calls causing datatbase transactions to thrash, or something? [19:55] not sure. I was thinking something along those lines. [19:55] xygnal: do you think you could provide a sample MAAS CLI command that reproduces the error, or does it succeed with the MAAS CLI? [19:55] I have pgsql monitored in telegraf, any particular trashing you would expect to see? [19:56] we already restarted the service so it wont come back for a while [19:56] xygnal: not really, I'm just throwing out theories =) [19:56] xygnal: but if you see anything that piques your interest, it might be worth mentioning [19:56] xygnal: but whatever insight you can give on that API calls you're making will be very helpful [19:56] I see 15 deadlocks in pgsql's statistics but those never go away even after restart [19:57] beyond that.. nothing stands out [19:57] xygnal: we use postgres for locking so it makes me wonder if the deadlocks are intentional [19:57] (though "deadlock", by definition, would indicate otherwise.) [19:57] yes, going back a month it was consistantly 14 deadlocks. recently its up to 16. [19:58] does not flux [19:59] we are not mass building dozens of boxes at once, the load is almost always low [20:06] xygnal: ok. are you able to add the "Accept" header? if so, I'm looking forward to hearing if that fixes that or not. (if not, I'd like to know which API call causes this and what parameters you're passing) [20:07] We will have to try it when we see this again. Right now it is not a top priority, but i have notes for my team to try next time we see it.