MAAS 2.1.0 Alpha 4 Released!
Andres Rodriguez
andres.rodriguez at canonical.com
Mon Sep 26 14:16:31 UTC 2016
I'm happy to announce that MAAS 2.1.0 Alpha 4 has been released.
*Availability*
MAAS 2.1.0 Alpha 4 has been made available in:
*ppa:maas/next*
*Filing bugs*
Users can file bugs in [1], please use a prefix for the subject, such as [
2.1].
[1] https://bugs.launchpad.net/maas/+filebug
2.1.0 Alpha 4
Important Announcements
-
MAAS Landing page - Let’s see what’s on your network!
As of MAAS 2.1 alpha 4, administrative users have a new landing page. Once
administrators log in they will be redirected to the MAAS dashboard. This
dashboard is where administrators will have some basic information and the
ability to see the observed and discovered devices.
Major new features
-
Device discovery UI
MAAS 2.1 alpha 4 introduces the MAAS Device Discovery UI. As part of the
dashboard, administrative users will be able to see all the observed and
discovered devices.
MAAS will also allow administrator to properly register those discoveries
as MAAS known devices, and be able to select the IP address allocation for
them, if MAAS is to manage them.
-
Active Device Discovery - map your network (API only)
As of MAAS 2.1 alpha 2, networks attached to rack controllers are observed
for device discovery purposes. MAAS listens to ARP requests and replies to
determine which IPv4 addresses are in-use on attached networks, and will
resolve their hostnames if possible (when advertised using the mDNS
protocol).
As of MAAS 2.1 alpha 4, MAAS now has the ability to actively probe subnets
directly attached to a rack controller. This allows MAAS to keep its
knowledge of which devices are on the network up-to-date, and discover
“quiet” devices that MAAS would not be able to observe passively. If ‘nmap’
is installed, MAAS will prefer to use it for scanning (since the scan is
faster and will transmit fewer packets). If ‘nmap’ is not installed, MAAS
will fall back to using parallel ‘ping’ requests.
Scanning is available using the API, or by running the “maas-rack
scan-network” command on a rack controller. The scanning API is available
at the following URL:
POST /MAAS/api/2.0/discovery/?op=scan
To scan using the command-line interface, you can use the following syntax:
-
maas <profile> discoveries scan [cidr=<cidr> [cidr=<cidr>....]
[force=true] [always_use_ping=true] [slow=true]
[threads=<num-concurrent-scanning-threads>]
If you want to scan particular subnets, specify one or more using the cidr
option. For example, ‘cidr=192.168.0.0/24’ would scan for neighbours on
192.168.0.0/24 on any rack controller configured with an address in that
network. The cidr option can be specified multiple times, such as ‘cidr=
192.168.0.0/24 cidr=192.168.1.0/24’.
If you want to scan all networks attached to all rack controllers, you must
specify the “force=true” option. (This is not allowed by default, since
some network operators do not allow active neighbour scanning.)
If your organization has a policy against using ‘nmap’, you will want to
use the ‘always_use_ping’ option, in case ‘nmap’ has been installed on a
rack controller by mistake.
If quickly scanning your network using ‘nmap’ may raise alerts with an
intrusion detection system, you can use the ‘slow=true’ argument to slow
down scanning. This option has no effect when using ‘ping’, since scanning
using ‘ping’ is already slower. If using ‘ping’, scans can be slowed down
or sped up, if desired, by using the threads option, such as by specifying
“threads=2”. Using the threads option has less impact on nmap threads,
which use a single thread to scan an entire network.
Minor new features
-
First User Journey - Import your SSH keys from Launchpad or Github
The ability to import SSH keys from Launchpad or Github was introduced in
MAAS alpha 3. As of alpha 4, you can do so via the Front-end.
All users will now have the ability to import their SSH keys from the UI.
All users who log-in to MAAS for the first time will be prompted to import
their SSH keys, if they so desire. Alternatively, users can do so via their
user profile page.
Other notable changes
-
NTP Improvements - MAAS NTP vs External
MAAS now provides the ability to decide between using solely an external
NTP server or a MAAS run NTP server. MAAS run NTP services is the preferred
configuration, but, in order to maintain backwards compatibility,
administrators can chose to use external NTP organizations. This will only
be suitable for scenarios where administrators have restricted
communication between their machines and the MAAS rack controllers.
Bugs fixed in this release
-
#1625668 [2.1] When trying to add SSH keys for a GH user that doesn't
exist, there's no feedback
-
#1626748 [2.1] maas admin discoveries scan API output shows rack
controller ids instead of names
-
#1626722 [2.1] DHPv6 addresses do not have netmasks: do not create
/128 subnets for them
-
#1625812 [2.1] Error message is not user friendly
-
#1625689 [2.1] default gateway cannot be set to fe80::/64 via web ui
-
#1626727 [2.1] You can define distribution or component for 'ubuntu
archive' or 'ubuntu extra architectures'
-
#1625671 [2.1] Need better error message when trying to add SSH keys
for LP/GH user that doesn't exist
-
#1623994 [2.1] DHCP configuration breaks when NTP servers are
unresolvable.
-
#1626669 [2.1] Can't logout, create users and do other actions
-
#1625674 [2.1] No feedback when there are no keys to import from LP/GH
Known issues and workaroundsUnable to cancel the image import.
When downloading images, MAAS will fail to cancel the import of all or any
of the images being imported. MAAS will first download all the images
before the user is able to remove them.
-
https://bugs.launchpad.net/maas/+bug/1623634
Rack failed to run/register on fresh install
The MAAS Rack Controller is unable to register after a fresh install due to
being unable to parse network interfaces. After manual restart of
maas-rackd, the rack was successfully registered.
-
https://bugs.launchpad.net/maas/+bug/1624693
Unable to load the WebUI due to "expected string or bytes-like object"
It some situations users have reported that they are unable to load the
WebUI. This is related to the device discovery data. However, the MAAS team
has been unable to reproduce this bug report. As such, if someone comes
across it please urgently report it with the MAAS team:
- https://bugs.launchpad.net/maas/+bug/1627362
On-going work
-
Improved IPv6 Support
-
MAAS Image Consolidation
-
Support for Low Latency Kernels
-
Support for HWE Rolling Kernels
--
Andres Rodriguez
Engineering Manager, MAAS
Canonical USA, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20160926/2de451c4/attachment-0001.html>
More information about the Maas-devel
mailing list