| === vladk|offline is now known as vladk | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === gmb is now known as breakum-binns | ||
| rvba | bigjools: I think the logic inside reserve() (w.r.t. your branch api-reserve-user-ip) should be done inside a form. Better encapsulation = easier testing, easier reuse (in the UI someday). | 09:33 |
|---|---|---|
| dimitern | hey guys | 09:52 |
| dimitern | i've just filed a wishlist bug for an api/networking changes juju needs from maas | 09:52 |
| dimitern | https://bugs.launchpad.net/maas/+bug/1336217 | 09:52 |
| ubot5 | Ubuntu bug 1336217 in MAAS "MAAS should always create a default private network all nodes are on" [Undecided,New] | 09:52 |
| breakum-binns | jtv, allenap, rvba: In the case of guess_server_address(), what do we want to do when an interface has multiple addresses? | 10:05 |
| === breakum-binns is now known as gmb | ||
| gmb | Grr | 10:05 |
| * gmb looks at the usage… | 10:06 | |
| bigjools | rvba: I knew you were going to say that | 10:06 |
| gmb | Emphatically not, actually… | 10:06 |
| jtv | gmb: it might be best to prefer IPv4 if there is an IPv4 address, and use an IPv6 address otherwise. | 10:19 |
| gmb | jtv: Right, that’s what I think too. | 10:20 |
| jtv | There's not all that much we can, or need to, do about policy on top of that. | 10:20 |
| gmb | Agreed. Thanks. | 10:20 |
| dimitern | gmb, jtv, bigjools, what do you think about that bug? ^^ | 10:23 |
| gmb | dimitern: “As the Juju networking model gets closer to completion, we realized for it to work with MAAS, some changes are needed:” Doesn’t look very wishlist :) | 10:24 |
| dimitern | gmb, it's not :) but usually such bugs get triaged as wishlist | 10:25 |
| jtv | "Should" | 10:25 |
| gmb | dimitern: Ah, cynicism :) You’re learning… | 10:26 |
| bigjools | dimitern: "Juju model assumes..." There's your bug. | 10:26 |
| gmb | jtv: I noticed that too. | 10:26 |
| dimitern | bigjools, we have a fallback for uncooperative providers or those yet to implement a way to discover the default private network - using 0.0.0.0/0 as CIDR | 10:27 |
| jtv | dimitern: the bug isn't very clear to me... it's all things you want us to do, which may or may not fit with maas design. Better to start with what the actual problem is. | 10:27 |
| dimitern | but that kinda sucks and it's best to avoid it | 10:27 |
| bigjools | dimitern: this is bare metal, it cannot conjure a network like you can in openstack | 10:27 |
| dimitern | bigjools, jtv, so let me try to explain | 10:28 |
| bigjools | and what jtv said - please state the problem, not the solution :) | 10:28 |
| dimitern | bigjools, jtv, you always *have* at least one network all nodes are on and get their IPs for br0, right? | 10:28 |
| bigjools | it depends on how the network admin configured it | 10:29 |
| jtv | I don't know about br0, but all allocated nodes will be on a network. | 10:29 |
| bigjools | not necessarily the same network | 10:29 |
| dimitern | jtv, right - the request is to make this explicitly accessible over the API | 10:29 |
| bigjools | this is why networks are a placement constraint | 10:29 |
| jtv | Make what exactly accessible over the API? | 10:29 |
| jtv | What aspect of the networks? | 10:29 |
| dimitern | i can simulate this now but creating a network with the same CIDR MAAS uses for the instances' IPs | 10:30 |
| dimitern | and connect each node's primary interface's mac to it | 10:31 |
| dimitern | then, i can use the api to get that network's info from maas | 10:31 |
| AskUbuntu_ | Adding Nodes to MAAS without internet connection | http://askubuntu.com/q/490297 | 10:31 |
| jtv | Can we take a step back and go into what the assumption is that juju needs to be able to make? | 10:32 |
| dimitern | bigjools, jtv, so all i'm asking is for better ux, maas to create this network automatically | 10:32 |
| jtv | Wow, I didn't get that from the bug report. | 10:32 |
| bigjools | dimitern: maas is unable to make physical networks automatically | 10:32 |
| jtv | I think this means "discover networks automatically." Right? | 10:32 |
| dimitern | i'm not talking about *creating* networks, just *describing* what's already there | 10:33 |
| bigjools | there is an api for that then :) | 10:33 |
| bigjools | anyway I am EOD | 10:33 |
| dimitern | bigjools, have a good evening then :) | 10:34 |
| jtv | dimitern: so is what you want simply "automatically discover networks"? | 10:34 |
| dimitern | jtv, ideally, yes | 10:34 |
| bigjools | dimitern: thanks : | 10:34 |
| bigjools | ) | 10:34 |
| dimitern | jtv, but we don't need all of them to be created automatically, just the default one | 10:34 |
| jtv | "The default" is hard to tell... there may be several. | 10:35 |
| dimitern | jtv, so that juju can know what IP range instances get their addresses from and what network id to use when starting instances | 10:35 |
| jtv | You can use the API to see what networks are available. | 10:36 |
| jtv | Including IP ranges. | 10:36 |
| jtv | Right? | 10:36 |
| dimitern | we're moving towards being explicit about networks, without breaking the UX (now we just assume there is a private and perhaps public network, we just don't know for sure) | 10:36 |
| dimitern | jtv, right, but if the admin did not create any networks, while in fact there is at least one | 10:37 |
| dimitern | jtv, juju won't know about it and must resort to some ugly hacks | 10:37 |
| jtv | Well what you need for this is the NodeGroupInterface class. | 10:37 |
| jtv | Its naming suffers from Legacy, but the information is already available. | 10:38 |
| dimitern | jtv, let me check that quickly | 10:38 |
| jtv | Under nodegroups/<uuid>/interfaces/ | 10:38 |
| dimitern | jtv, great! it seems that's what juju needs - we can list what interfaces are there in a nodegroup, and assume there is always at least one node group, possibly named default? | 11:29 |
| dimitern | erm.. named with some random uuid | 11:35 |
| rvba | dimitern: right, there is always at least one nodegroup; so you can always fetch the list of get the first one. | 11:42 |
| dimitern | rvba, does maas distribute instances by default across node groups? (i.e. when starting an instance without placement specified) | 11:43 |
| rvba | dimitern: no, when there are multiple matches, one at random is selected. | 11:44 |
| dimitern | rvba, and more importantly, are all node groups' primary network interface (eth0) guaranteed to be on the same subnet? | 11:44 |
| dimitern | rvba, right, ok | 11:45 |
| rvba | dimitern: there is no guarantee, remember this is a view of existing physical networks. | 11:45 |
| rvba | But of course, if you want your nodes to be able to talk to each other, you need proper routing setup. | 11:45 |
| dimitern | rvba, that's what I thought yeah | 11:46 |
| jtv | dimitern: the admin gets to choose what networks there are, and on which clusters. Each cluster can manage multiple networks. A network can only be managed by one cluster. | 11:46 |
| dimitern | rvba, so for all sane deployments we can assume nodegroups are on the same (or mutually accessible) subnets | 11:47 |
| dimitern | aah | 11:47 |
| dimitern | "a network can only be managed by one cluster", means for Juju different clusters can be like different regions/AZs | 11:48 |
| dimitern | this might have some interesting implications.. | 11:51 |
| jtv | Could be. Though we also have "physical zones" which are not tied to the topology in any way. | 11:51 |
| jtv | But you can think of a maas of "containing" a set of clusters (a.k.a. nodegroups), and each of those "containing" some networks. | 11:51 |
| jtv | This doesn't tell you which networks actually have nodes, of course. To do that, I think you'd have to match node IP addresses to networks. | 11:52 |
| jtv | Unfortunately we have two kinds of network that still live completely separate lives: "nodegroupinterfaces" are basically network definitions, with optionally the settings to control a DHCP server on that network. And "networks" are user-defined entries that are only used for constraints. | 11:53 |
| jtv | Yes, we would like to unify those — but that'd take time to do, so has to be scheduled in. | 11:53 |
| dimitern | thanks for the detailed explanation jtv | 12:05 |
| dimitern | it definitely helps me to understand the internals and map them better to juju's model | 12:06 |
| === Solution-X is now known as Solution-X|AFK | ||
| === vladk is now known as vladk|offline | ||
| === karltk_ is now known as karltk | ||
| === jfarschman is now known as MilesDenver | ||
| jtv | I wonder how I tell South to add a required field whose value defaults to another field's value (with perhaps a backstop for blanks). | 14:18 |
| jtv | The only way I can think of so far is: | 14:18 |
| jtv | 1. Schema migration to add field, but optional. | 14:18 |
| jtv | 2. Data migration to populate field. | 14:18 |
| jtv | 3. Schema migration to make field required. | 14:18 |
| jtv | rvba, any ideas? ^ | 14:23 |
| jtv | Ah, this blog post has advice: http://www.brankovukelic.com/2013/02/south-migration-with-dynamically.html | 14:30 |
| jtv | Basically "lie to South." | 14:30 |
| rvba | jtv: the solution with the data migration seems good to me. (I think we've done that in the past.) | 14:48 |
| jtv | Looks like I can combine migrations. | 14:49 |
| === vladk|offline is now known as vladk | ||
| jtv | Argh. WHY does the NodeGroup constructor still create a NodeGroupInterface? Now there are two parameters called "name"! | 15:25 |
| luflores | Hi all, is there is a way I have a managed interface with DHCP that I can nailed the IPs that particular MAC ? | 15:34 |
| luflores | I want to have a deterministic way to assign IP address via DHCP | 15:34 |
| === luflores is now known as Caguax | ||
| schegi_ | someone here who cloud help with an cloud-inint problem during machine boot?? | 15:58 |
| jtv | schegi_: smoser is the one who knows about cloud-init. Doesn't seem to be here just now though. | 16:02 |
| schegi_ | actually maybe some already encounter this issue. i got a maas master installend and then a juju node bootstrapped. when i now change the network settings on the juju knode. especially changing the main interface (putting it into a bond) manually and then reboot the system it always stucks for a couple of minutes in cloud-init-nonet[16.98] | 16:05 |
| schegi_ | Finally it aborts with cloud-init-nonet[136.98]: gave up waiting for a network device. But afterwards all networks are up and the machine is reachable | 16:05 |
| === vladk is now known as vladk|offline | ||
| === matsubara is now known as matsubara-lunch | ||
| schegi_ | jtv, any idea where else i can ask for a solution. to me it seems like cloudinit still tries to do something with the old interface and that just does no work. | 16:23 |
| lutostag | does trusty maas support installing utopic as a deployment distro yet? | 16:49 |
| jtv | schegi_: it does sound like it... people in #juju would know more about how juju drives cloud-init. | 16:56 |
| jtv | lutostag: I don't think we've tried that yet, but you'd have to import images with the "daily" label. | 16:57 |
| lutostag | jtv: thanks, I thought all I would need is the correct streams | 16:58 |
| jtv | You need the right stream, but then AFAIK we only import releases by default. | 17:01 |
| === vladk|offline is now known as vladk | ||
| === gmb is now known as breakum-binns | ||
| === jfarschman is now known as MilesDenver | ||
| === jfarschman is now known as MilesDenver | ||
| === breakum-binns is now known as gmb | ||
| === vladk is now known as vladk|offline | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === jfarschman is now known as MilesDenver | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!