Canonical Voices

Posts tagged with 'articles'

Carmine Rimi

  • Kubeflow at OSCON 2019 – Over 10 sessions! Covering security, pipelines, productivity, ML ops and more. Some of the sessions are led by end-users, which means you’ll get the real deal about using Kubeflow in your production solution
  • Kubeflow at KubeCon Europe 2019 in Barcelona – The top Kubeflow events from Kubecon in Barcelona, 2019. Tutorials, Pipelines, and Kubeflow 1.0 ruminations. The discussion on when Kubeflow will reach 1.0 should be of interest to those waiting for that milestone.
  • Kubeflow Contributor Summit 2019 – Presentations and Slide decks, 22+ of them. Reviewing them will help you understand how the sausage is made. One of the interesting videos focuses on a panel discussion with machine learning practitioners and experts discussing the dynamics of machine learning at their workplace.
  • Kubeflow events calendar – Find a past or future event. This is a great resource for reviewing content from community leaders and leveling up on the current state of Kubeflow. If you are aware of something that is missing, feel free to add the content through github – become a community member! 
  • Use Case Spotlight: IBM’s photo-scraping scandal shows what a weird bubble AI researchers live in. This bubble is all about data – who owns it, who can monopolize it, who is monetizing it, and what the expectations around it. The expectations is the crux of the issue – people using the data may be at odds with the people supplying the data.

The post Issue #2019.07.22 – Kubeflow and Conferences, 2019 appeared first on Ubuntu Blog.

Read more
Andres Rodriguez

Canonical is happy to announce the availability of MAAS 2.6. This new release introduces a range of very exciting features and several improvements that enhances MAAS across various areas. Let’s talk about a few notable ones:

Growing support for ESXi Datastores

MAAS has expanded its support of ESXi by allowing administrators to create & configure VMFS datastores on physically connected disks.

MAAS 2.5 introduced the ability to deploy VMWare’s ESXi. This, however, was limited in its ability to configure storage devices by just being able to select the disk in which to deploy the operating system on. As of 2.6, MAAS now also provides the ability to configure datastores. This allows administrators to create one or more datastores, using one or more physical disks. More information is available in https://docs.maas.io/2.6/en/installconfig-vmfs-datastores .

More information on how to create MAAS ESX images is available in https://docs.maas.io/2.6/en/installconfig-images-vmware .

Multiple default gateways

MAAS 2.6 introduces a network configuration change (for Ubuntu), where it will leverage the use of source routing to support multiple default gateways.

As of MAAS 2.5, all deployed machines were configured with a single default gateway. By doing so, if a machine were to be configured in multiple subnets (that had gateways defined), all outgoing traffic would go out the default gateway even though the traffic was intended to go out through the subnets configured gateway.

To address this, MAAS 2.6 has changed the way it configures the network when a machine has multiple interfaces in different subnets, to ensure that all traffic that is meant to go through the subnet’s gateway actually does.

Please note that this is currently limited to Ubuntu provided that this depends on source routing using netplan, and this is only currently supported by cloud-init in Ubuntu.

Leveraging HTTP boot for most of the PXE process

MAAS 2.6 is now leveraging the use of HTTP (as much as possible) to boot machines over the PXE process rather than solely rely on TFTP. The reasons for the change are not only to support newer standards/features, but also to improve PXE boot performance. As such, you should now expect that:

  • UEFI systems that implement the 2.5 spec can now fully boot over HTTP.
  • KVM’s will rely on iPXE to perform HTTP boot
  • Other architectures that support HTTP boot, such as arm64, will prefer it over tftp.

Prometheus metrics

MAAS now exposes Prometheus data that can be used to either track statistics or performance.  For more information into what metrics are exposed, please refer to https://discourse.maas.io/t/maas-2-6-0-released/724 and to learn how to enable them, refer to https://docs.maas.io/2.6/en/manage-prometheus-metrics .

Other features and improvements

A more extensive list of features and improvements introduced in MAAS 2.6 includes:

  • Performance – Leverage HTTP for most of the PXE process
  • Performance – Track stats and metrics with Prometheus
  • User experience – Provides a more granular boot output
  • Networking – Multiple default gateways
  • Power control – Added support for redfish
  • Power control – Added support for OpenBMC
  • ESXi – Support configuring datastores
  • ESXi – Support registering to vCenter
  • User experience – Dismiss/supress failed tests
  • User experience – Clear discovered devices
  • User experience – Added note to machine
  • User experience – Added grouping to machine listing page

Please refer to https://discourse.maas.io/t/maas-2-6-0-released/724/2 for more information.

The post MAAS 2.6 – ESXi storage, multiple gateways, HTTP boot and more appeared first on Ubuntu Blog.

Read more
Alex Hung

I often need to implement tests for new ACPI tables before they become available on real hardware. Fortunately, FWTS provides a framework to read ACPI tables’ binary.

The below technique is especially convenient for ACPI firmware and OS kernel developers. It provides a simple approach to verifying ACPI tables without compiling firmware and deploying it to hardware.

Using acpidump.log as an input for FWTS

The command to read ACPI tables’ binary is

# check ACPI methods in a text file
$ fwts method --dumpfile=acpidump.log

or

# check ACPI FACP table in a text file
$ fwts facp --dumpfile=acpidump.log

where acpidump.log contains ACPI tables’ binary in a specific format as depicted below:

Format of acpidump
  • Table Signature – the 4-byte long ACPI table signature
  • Offset – data starts from 0000 and increases by 16 bytes per line
  • Hex Data- each line has 16 hex integers of the compiled ACPI table
  • ASCII Data – the ASCII presentation of the hex data

This format may look familiar because it is not specific to FWTS. In fact, it is the same format generated by acpidump. In other words, the below two code snippets generate identical results.

# reading ACPI tables from memory
$ sudo fwts method
# dumping ACPI tables and testing it
$ sudo acpidump > acpidump.log
$ fwts method --dumpfile=acpidump.log

For developers, using –dumpfile option means that it is possible to test ACPI tables before deploying them on real hardware. The following sections present how to prepare a customized log file.

Using a customized acpidump.log for FWTS

We can use acpica-tools to generate an acpidump.log. The following is an example of building a customized acpidump.log to test the fwts method command.

Generate a dummy FADT

A Fixed ACPI Description Table (FADT) contains vital information to ACPI OS such as the base addresses for hardware registers. As a result, FWTS requires a FADT in an acpidump.log so it can recognize acpidump.log as a valid input file.

$ iasl -T FACP
$ iasl facp.asl > /dev/zero
$ echo "FACP @ 0x0000000000000000" >> acpidump.log
$ xxd -c 16 -g 1 facp.aml  | sed 's/^0000/    /' >> acpidump.log
$ echo "" >> acpidump.log

Develop a Customized DSDT table

A Differentiated System Description Table (DSDT) is designed to provide OEM’s value-added features. A dummy DSDT can be generated as below, and OEM value-added features, such as ACPI battery or hotkey for airplane mode, can be added to it.

# Generate a DSDT
$ iasl -T DSDT
# Customize dsdt.asl
#  ex. adding an ACPI battery or airplane mode devices

Compile the DSDT table to binary

The customized DSDT can be compiled and appended to acpidump.log.

$ iasl dsdt.asl > /dev/zero
$ echo "DSDT @ 0x0000000000000000" >> acpidump.log
$ xxd -c 16 -g 1 dsdt.aml  | sed 's/^0000/    /' >> acpidump.log
$ echo "" >> acpidump.log

Run method test with acpidump.log

And finally, run the fwts method test.

$ fwts method --dumpfile=acpidump.log

Final Words

While we use DSDT as an example, the same technique applies to all ACPI tables. For instance, HMAT was introduced and frequently updated in recent ACPI specs, and the Firmware Test Suite includes most, if not all, changes up-to-date. As a consequence, FWTS is able to detect errors before firmware developers integrate HMAT into their projects, and therefore reduces errors in final products.

The post Analyze ACPI Tables in a Text File with FWTS appeared first on Ubuntu Blog.

Read more
Canonical

Ubuntu updates for TCP SACK Panic vulnerabilities
Issues have been identified in the way the Linux kernel’s TCP implementation processes Selective Acknowledgement (SACK) options and handles low Maximum Segment Size (MSS) values. These TCP SACK Panic vulnerabilities could expose servers to a denial of service attack, so it is crucial to have systems patched. Updated versions of the Linux kernel packages are being published as part of the standard Ubuntu security maintenance of Ubuntu releases 16.04 LTS, 18.04 LTS, 18.10, 19.04 and as part of the extended security maintenance for Ubuntu 14.04 ESM users. It is recommended to update to the latest kernel packages and consult Ubuntu Security Notices for further updates. Ubuntu Advantage for Infrastructure subscription customers can find the latest status information in our Knowledge Base and file a support case with Canonical support for any additional questions or concerns around SACK Panic. Canonical’s Kernel Livepatch updates for security vulnerabilities related to TCP SACK processing in the Linux kernel have been released and are described by CVEs 2019-11477 and 2019-11478, with details of the patch available in LSN-0052-1. These CVEs have a Livepatch fix available, however, a minimum kernel version is required for Livepatch to install the fix as denoted by the table in LSN-0052-1, reproduced here:
| Kernel                   | Version | flavors           |
|--------------------------+----------+--------------------------|
| 4.4.0-148.174            | 52.3 | generic, lowlatency      |
| 4.4.0-150.176            | 52.3 | generic, lowlatency      |
| 4.15.0-50.54             | 52.3 | generic, lowlatency      |
| 4.15.0-50.54~16.04.1     | 52.3 | generic, lowlatency      |
| 4.15.0-51.55             | 52.3 | generic, lowlatency      |
| 4.15.0-51.55~16.04.1     | 52.3 | generic, lowlatency      |
Livepatch fixes for CVEs 2019-11477 and 2019-11478 are not available for prior kernels, and an upgrade and reboot to the appropriate minimum version is necessary. These kernel versions correspond to the availability of mitigations for the MDS series of CVEs (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 and CVE-2019-11091). Additionally, a third SACK related issue, CVE-2019-11479, does not have a Livepatch fix available because it is not technically feasible to apply the changes via Livepatch. Mitigation information is available at the Ubuntu Security Team Wiki. If you have any questions and want to learn more about these patches, please do not hesitate to get in touch. The post Ubuntu updates for TCP SACK Panic vulnerabilities appeared first on Ubuntu Blog.

The post Canonical Design Blog: Ubuntu updates for TCP SACK Panic vulnerabilities appeared first on Ubuntu Blog.

Read more
Canonical

Ubuntu updates for TCP SACK Panic vulnerabilities

Issues have been identified in the way the Linux kernel’s TCP implementation processes Selective Acknowledgement (SACK) options and handles low Maximum Segment Size (MSS) values. These TCP SACK Panic vulnerabilities could expose servers to a denial of service attack, so it is crucial to have systems patched.

Updated versions of the Linux kernel packages are being published as part of the standard Ubuntu security maintenance of Ubuntu releases 16.04 LTS, 18.04 LTS, 18.10, 19.04 and as part of the extended security maintenance for Ubuntu 14.04 ESM users.

It is recommended to update to the latest kernel packages and consult Ubuntu Security Notices for further updates.

Ubuntu Advantage for Infrastructure subscription customers can find the latest status information in our Knowledge Base and file a support case with Canonical support for any additional questions or concerns around SACK Panic.

Canonical’s Kernel Livepatch updates for security vulnerabilities related to TCP SACK processing in the Linux kernel have been released and are described by CVEs 2019-11477 and 2019-11478, with details of the patch available in LSN-0052-1.

These CVEs have a Livepatch fix available, however, a minimum kernel version is required for Livepatch to install the fix as denoted by the table in LSN-0052-1, reproduced here:

| Kernel                   | Version | flavors           |
|--------------------------+----------+--------------------------|
| 4.4.0-148.174            | 52.3 | generic, lowlatency      |
| 4.4.0-150.176            | 52.3 | generic, lowlatency      |
| 4.15.0-50.54             | 52.3 | generic, lowlatency      |
| 4.15.0-50.54~16.04.1     | 52.3 | generic, lowlatency      |
| 4.15.0-51.55             | 52.3 | generic, lowlatency      |
| 4.15.0-51.55~16.04.1     | 52.3 | generic, lowlatency      |

Livepatch fixes for CVEs 2019-11477 and 2019-11478 are not available for prior kernels, and an upgrade and reboot to the appropriate minimum version is necessary. These kernel versions correspond to the availability of mitigations for the MDS series of CVEs (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 and CVE-2019-11091).

Additionally, a third SACK related issue, CVE-2019-11479, does not have a Livepatch fix available because it is not technically feasible to apply the changes via Livepatch. Mitigation information is available at the Ubuntu Security Team Wiki.

If you have any questions and want to learn more about these patches, please do not hesitate to get in touch.

The post Ubuntu updates for TCP SACK Panic vulnerabilities appeared first on Ubuntu Blog.

Read more
Alex Cattle

cloud-init logo

Private cloud, public cloud, hybrid cloud, multi-cloud… the variety of locations, platforms and physical substrate you can start a cloud instance on is vast. Yet once you have selected an operating system which best supports your application stack, you should be able to use that operating system as an abstraction layer between different clouds.

However, in order to function together an operating system and its cloud must share some critical configuration data which tells the operating system how to ‘behave’ in the particular environment. Separating out this configuration data from the operating system and the underlying cloud is the key to effortlessly launching instances across multi-cloud.

Cloud-init provides a mechanism for separating out configuration data from both the operating system and the execution environment so that you maintain the ability to change either at any time. It serves as a useful abstraction which ensures that the investments you make in your application stack on a specific operating system can be leveraged across multiple clouds.

This whitepaper will explain:

  • The background and history behind the cloud-init open source project
  • How cloud-init is invoked and how it configures an instance
  • How to get started with cloud-init

To view the whitepaper sign up using the form below:

In submitting this form, I confirm that I have read and agree to Canonical’s Privacy Notice and Privacy Policy.

The post Cloud Instance Initialisation with cloud-init appeared first on Ubuntu Blog.

Read more
Chad Smith

Hello Ubuntu Server

The purpose of this communication is to provide a status update and highlights for any interesting subjects from the Ubuntu Server Team. If you would like to reach the server team, you can find us at the #ubuntu-server channel on Freenode. Alternatively, you can sign up and use the Ubuntu Server Team mailing list or visit the Ubuntu Server discourse hub for more discussion.

Spotlight: Weekly Ubuntu Server team updates in Discourse

The Ubuntu Server team will now be sending weekly team updates to discourse to give a clear view of the projects, feature and bug work we are working on each week. Come see what we are up to and participate in driving Ubuntu Server changes with us. Here is our June 24 status update. Come discuss any topics of interest with us.

cloud-init

  • doc: indicate that netplan is default in Ubuntu now [Daniel Watkins]
  • azure: add region and AZ properties from imds compute location metadata [Chad Smith]
  • sysconfig: support more bonding options [Penghui Liao]
  • cloud-init-generator: use libexec path to ds-identify on redhat systems [Ryan Harper] (LP: #1833264)
  • tools/build-on-freebsd: update to python3 [Gonéri Le Bouder]

curtin

  • vmtests: drop skip_by_date decorators for bug 1813228 [Daniel Watkins]
  • block: Add opportunistic zkey encryption if supported [Ryan Harper]
  • vmtests: add support for CURTIN_VMTEST_APT_PROXY [Daniel Watkins]
  • vmtests: add use of CURTIN_VMTEST_ prefixed envvars to image sync [Daniel Watkins]

Contact the Ubuntu Server team

Bug Work and Triage

Ubuntu Server Packages

Below is a summary of uploads to the development and supported releases. Current status of the Debian to Ubuntu merges is tracked on the Merge-o-Matic page. For a full list of recent merges with change logs please see the Ubuntu Server report.

Proposed Uploads to the Supported Releases

Please consider testing the following by enabling proposed, checking packages for update regressions, and making sure to mark affected bugs verified as fixed.

Total: 10

Uploads Released to the Supported Releases

Total: 24

Uploads to the Development Release

Total: 25

The post Ubuntu Server development summary – 26 June 2019 appeared first on Ubuntu Blog.

Read more
Chad Smith

Hello Ubuntu Server

The purpose of this communication is to provide a status update and highlights for any interesting subjects from the Ubuntu Server Team. If you would like to reach the server team, you can find us at the #ubuntu-server channel on Freenode. Alternatively, you can sign up and use the Ubuntu Server Team mailing list or visit the Ubuntu Server discourse hub for more discussion.

Spotlight: Weekly Ubuntu Server team updates in Discourse

The Ubuntu Server team will now be sending weekly team updates to discourse to give a clear view of the projects, feature and bug work we are working on each week. Come see what we are up to and participate in driving Ubuntu Server changes with us. Here is our June 24 status update. Come discuss any topics of interest with us.

cloud-init

  • doc: indicate that netplan is default in Ubuntu now [Daniel Watkins]
  • azure: add region and AZ properties from imds compute location metadata [Chad Smith]
  • sysconfig: support more bonding options [Penghui Liao]
  • cloud-init-generator: use libexec path to ds-identify on redhat systems [Ryan Harper] (LP: #1833264)
  • tools/build-on-freebsd: update to python3 [Gonéri Le Bouder]

curtin

  • vmtests: drop skip_by_date decorators for bug 1813228 [Daniel Watkins]
  • block: Add opportunistic zkey encryption if supported [Ryan Harper]
  • vmtests: add support for CURTIN_VMTEST_APT_PROXY [Daniel Watkins]
  • vmtests: add use of CURTIN_VMTEST_ prefixed envvars to image sync [Daniel Watkins]

Contact the Ubuntu Server team

Bug Work and Triage

Ubuntu Server Packages

Below is a summary of uploads to the development and supported releases. Current status of the Debian to Ubuntu merges is tracked on the Merge-o-Matic page. For a full list of recent merges with change logs please see the Ubuntu Server report.

Proposed Uploads to the Supported Releases

Please consider testing the following by enabling proposed, checking packages for update regressions, and making sure to mark affected bugs verified as fixed.

Total: 10

Uploads Released to the Supported Releases

Total: 24

Uploads to the Development Release

Total: 25

The post Ubuntu Server development summary – 26 June 2019 appeared first on Ubuntu Blog.

Read more
Alex Cattle

An image displaying a range of devices connected to a mobile network.

Mobile operators face a range of challenges today from saturation, competition and regulation – all of which are having a negative impact on revenues. The introduction of 5G offers new customer segments and services to offset this decline. However, unlike the introduction of 4G which was dominated by consumer benefits, 5G is expected to be driven by enterprise use. According to IDC, enterprises will generate 60 percent of the world’s data by 2025.

Rather than rely on costly proprietary hardware and operating models, the use of open source technologies offers the ability to commoditise and democratise the wireless network infrastructure. Major operators such as Vodafone, Telefonica and China Mobile have already adopted such practices.

Shifting to open source technology and taking a software defined approach enables mobile operators to differentiate based on the services they offer, rather than network coverage or subscription costs.

This whitepaper will explain how mobile operators can break the proprietary stranglehold and adopt an open approach including:

  • The open source initiatives and technologies available today and being adopted by major operators.
  • How a combination of software defined radio, mobile base stations and 3rd party app development can provide a way for mobile operators to differentiate and drive down CAPEX
  • Use cases by Vodafone and EE on successful implementations by adopting an open source approach

To view the whitepaper, sign up using the form below:

The post The future of mobile connectivity appeared first on Ubuntu Blog.

Read more
Alex Cattle

An image displaying a range of devices connected to a mobile network.

Mobile operators face a range of challenges today from saturation, competition and regulation – all of which are having a negative impact on revenues. The introduction of 5G offers new customer segments and services to offset this decline. However, unlike the introduction of 4G which was dominated by consumer benefits, 5G is expected to be driven by enterprise use. According to IDC, enterprises will generate 60 percent of the world’s data by 2025.

Rather than rely on costly proprietary hardware and operating models, the use of open source technologies offers the ability to commoditise and democratise the wireless network infrastructure. Major operators such as Vodafone, Telefonica and China Mobile have already adopted such practices.

Shifting to open source technology and taking a software defined approach enables mobile operators to differentiate based on the services they offer, rather than network coverage or subscription costs.

This whitepaper will explain how mobile operators can break the proprietary stranglehold and adopt an open approach including:

  • The open source initiatives and technologies available today and being adopted by major operators.
  • How a combination of software defined radio, mobile base stations and 3rd party app development can provide a way for mobile operators to differentiate and drive down CAPEX
  • Use cases by Vodafone and EE on successful implementations by adopting an open source approach

To view the whitepaper, sign up using the form below:

In submitting this form, I confirm that I have read and agree to Canonical’s Privacy Notice and Privacy Policy.

The post The future of mobile connectivity appeared first on Ubuntu Blog.

Read more
Anthony Dillon

This was a fairly busy two weeks for the Web & design team at Canonical.  Here are some of the highlights of our completed work.

Web squad

Web is the squad that develop and maintain most of the brochure websites across the Canonical.

Getting started with AI webinar

We build a page to promote the AI webinar.

Watch the webinar

Legal page updates

There have been several minor changes to the legal pages on the site.

New telco whitepaper

Designed and built a takeover and landing page for a whitepaper on telecommunications, featuring Lime Microsystems.

Get the whitepaper

Moved blog.ubuntu.com to ubuntu.com

This was a collaborative effort between multiple squads in the team, which resulted in moving the blog from blog.ubuntu.com to ubuntu.com/blog. This is now live with redirects from the old links to the new home of blog.

Visit the blog

Brand

Brand squad champion a consistent look and feel across all media from web to social to print and logos. 

Marketing support

We completed a few documents for the Marketing team, datasheets and a whitepaper.

Suru exploration

We did some initial exploration work on how we can extend the use of Suru across the webs. We concentrated on use in the header and footer sections of bubble pages. The aim is to get consistent use across all our websites and guideline how it is to be used in order to help the development teams going forward.

Illustrations

We pushed on with the development of our illustrations, completing an audit of illustrations currently used across all our websites and putting a plan in place to update them in stages.

We designed an illustration for ‘The future of mobile connectivity’ to go in a takeover on Ubuntu.com

Iconography

Finalised a list of UI icons with the UX teams with a view to create a new complete set to go across all our products, delivering a consistent user experience.

Slide deck tutorial

We completed the first stage of a video tutorial to go alongside the Master slide deck that guides you on how to use the new deck, do’s and dont’s, and tips for creating great looking slides.

MAAS

The MAAS squad develop the UI for the maas project.

Understand network testing

As the engineers are starting to flesh out their part of the spec for network testing in MAAS – a new feature aimed at the 2.7 release, the UX team spent a significant amount of time learning and understanding what network testing implies and how it will work. We began creating initial sketches to help both the design and the engineering team think in line for what the UI could look like.

Upgrade to Vanilla 2.0 

We upgraded the MAAS application to Vanilla 2.0, making use of all the great features introduced with it. As things the new version of the framework introduces quite a few changes, there are a number of issues in the MAAS UI need to be fixed – the work for this was started and will continue in the next iteration.

Implement small graphs for KVM listing

We are introducing new small graphs within a table, that will, to begin with, be used in the KVM and RSD pages, allowing the users to at-a-glance see their used and available resources. The work for this began with implementing graphs and infotips (rich tooltips) displaying storage and will continue in the next iteration with graphs displaying cores. 

JAAS

The JAAS squad develops the UI for the JAAS store and Juju GUI  projects.

Juju status project

We gathered which pieces of information would be good to display in the new Juju status project. The new GUI will help Juju to scale up, targeting users with lots of Juju/models, stitching all bootstrapping together. Status of all models with metadata about the controllers, analytics and stats. JAAS is the intersection of Juju, CLI, models and solutions.

Jaas.ai enhancements

We have worked on an update to the homepage hero area to include a slideshow. This will help to promote different types of content at the homepage.

Vanilla

The Vanilla squad design and maintain the design system and Vanilla framework library. They ensure a consistent style throughout web assets.  

Released Vanilla 2.0

Over the past year, we’ve been working hard to bring you the next release of Vanilla framework: version 2.0, our most stable release to date.

Since our last significant release, v1.8.0 back in July last year, we’ve been working hard to bring you new features, improve the framework and make it the most stable version we’ve released.

You can see the full list of new and updated changes in the framework in the full release notes . Alternatively you can read up on high-level highlights in our recent blog post New release: Vanilla framework 2.0, and to help with your upgrade to 2.0 we’ve written a step-by-step guide to help you along the way.

Site upgrades

With the release of Vanilla 2.0 we’ve been rolling upgrades across some of our marketing sites.

Snapcraft

The Snapcraft team work closely with the snap store team to develop and maintain the snap store website.

Distro pages

Upon our release of new pages with instructions to enable snap support to users, we got some echo in the media. Check these articles:

These pages are generating an aggregated traffic around ~2000 visits per day since they launched, they keep growing without having performed any specific campaign.

Release UI drag’n’drop

The Release UI has received some love this iteration. We’ve updated the visual style to improve usability and worked on drag’n’dropping channels and releases – which will be landing soon.

There was some refactoring needed to make the right components draggable, and we took the opportunity to experiment with React hooks. This work was the foundation for a better release experience and flexibility that we’ll be working on in the coming iteration.

Commercial applications

Responsive UI layout

The UI for the base application is now responsive and has been optimised for tablet and mobile devices. The work comprised of two components:

  1. Modifying the existing CSS Grid layout at certain breakpoints, which was relatively simple, and;
  2. Migrating the react-virtualized tables to react-window (a much leaner alternative for virtualized lists) and making them responsive. This piece of work was substantially more difficult.

Candid

Candid is our service which provides macaroon-based authentication.

Multi log-in, implementation of the design

Candid has the ability to login to a selection of registered identity providers. We required an interface to select the provider you want to use to authenticate with. This task included applying Vanilla framework to the existing views with improvements on performance and maintainability.

Blog Posts

The post Design and Web team summary – 25 June 2019 appeared first on Ubuntu Blog.

Read more
Jeremie Deray

Disclosure: read the post until the end, a surprise awaits you!

Moving from ROS 1 to ROS 2 can be a little overwhelming.
It is a lot of (new) concepts, tools and a large codebase to get familiar with. And just like many of you, I am getting started with ROS 2.

One of the central pieces of the ROS ecosystem is its Command Line Interface (CLI). It allows for performing all kind of actions; from retrieving information about the codebase and/or the runtime system, to executing code and of course helping debugging in general. It’s a very valuable set of tools that ROS developers use on a daily basis. Fortunately, pretty much all of those tools were ported from ROS 1 to ROS 2.

To those already familiar with ROS, the ROS 2 CLI wording will sound very familiar. Commands such as roslaunch is ported to ros2 launch, rostopic becomes ros2 topic while rosparam is now ros2 param.
Noticed the pattern already ? Yes that’s right ! The keyword ‘ros2‘ has become the unique entry-point for the CLI.

So what ? ROS CLI keywords where broke in two and that’s it ?


Well, yes pretty much.

Every command starts with the ros2 keyword, followed by a verb, a sub-verb and possibly positional/optional arguments. The pattern is then,

$ ros2 verb sub-verb <positional-argument> <optional-arguments>

Notice that throughout the CLI, the auto-completion (the infamous [tab][tab]) is readily available for verbs, sub-verbs and most positional arguments. Similarly, helpers are available at each stage,

$ ros2 verb --help
$ ros2 verb sub-verb -h

Let us see a few examples,

$ ros2 run demo_node_cpp talker
starts the talker cpp node from the demo_nodes_cpp package.

$ ros2 run demo_node_py listener
starts the listener python node from the demo_nodes_py package.

$ ros2 topic echo /chatter
outputs the messages sent from the talker node.

$ ros2 node info /listener
outputs information about the listener node.

$ ros2 param list
lists all parameters of every node.

Fairly similar to ROS 1 right ?

Missing CLI tools

We mentioned earlier that most of the CLI tools were ported to ROS 2, but not all. We believe such missing tools is one of the barriers to greater adoption of ROS 2, so we’ve started added some that we noticed were missing. Over the past week we contributed 5 sub-verbs, including one that is exclusive to ROS 2. Let us briefly review them,

$ ros2 topic find <message-type>
outputs a list of all topics publishing messages of a given type (#271).

$ ros2 topic type <topic-name>
outputs the message type of a given topic (#272).

$ ros2 service find <service-type>
outputs a list of all services of a given type (#273).

$ ros2 service type <service-name>
outputs the service type of a given service (#274).

This tools are pretty handy by themselves, especially to debug and grasp an overview of a running system. And they become even more interesting when combined, say, in handy little scripts,

$ ros2 topic pub /chatter $(ros2 topic type /chatter) "data: Hello ROS 2 Developers"

Advertisement:
Have you ever looked for the version of a package you are using ?
Ever wondered who is the package author ?
Or which other packages it depends upon ?
All of this information, locked in the package’s xml manifest is now easily available at the tip of your fingers !

The new sub-verb we introduced allows one to retrieve any information contained in a package xml manifest (#280). The command,

$ ros2 pkg xml <package-name>
outputs the entirety of the xml manifest of a given package.
To retrieve solely a piece of it, or a tag in xml wording, use the --tag option,

$ ros2 pkg xml <package-name> --tag <tag-name>

A few examples are (at the time of writing),

$ ros2 pkg xml demo_nodes_cpp --tag version
0.7.6

$ ros2 pkg xml demo_nodes_py -t author
Mikael Arguedas
Esteve Fernandez

$ ros2 pkg xml intra_process_demo -t build_depend libopencv-dev
rclcpp
sensor_msgs
std_msgs

This concludes our brief review of the changes that ROS 2 introduced to the CLI tools.

Before leaving, let me offer you a treat.

— A ROS 2 CLI Cheats Sheet that we put together —

Feel free to share it, print and pin it above your screen but also contribute to it as it is hosted on github !

Cheers.

The post ROS 2 Command Line Interface appeared first on Ubuntu Blog.

Read more
Jeremie Deray

Disclosure: read the post until the end, a surprise awaits you!

Moving from ROS 1 to ROS 2 can be a little overwhelming.
It is a lot of (new) concepts, tools and a large codebase to get familiar with. And just like many of you, I am getting started with ROS 2.

One of the central pieces of the ROS ecosystem is its Command Line Interface (CLI). It allows for performing all kind of actions; from retrieving information about the codebase and/or the runtime system, to executing code and of course helping debugging in general. It’s a very valuable set of tools that ROS developers use on a daily basis. Fortunately, pretty much all of those tools were ported from ROS 1 to ROS 2.

To those already familiar with ROS, the ROS 2 CLI wording will sound very familiar. Commands such as roslaunch is ported to ros2 launch, rostopic becomes ros2 topic while rosparam is now ros2 param.
Noticed the pattern already ? Yes that’s right ! The keyword ‘ros2‘ has become the unique entry-point for the CLI.

So what ? ROS CLI keywords where broke in two and that’s it ?


Well, yes pretty much.

Every command starts with the ros2 keyword, followed by a verb, a sub-verb and possibly positional/optional arguments. The pattern is then,

$ ros2 verb sub-verb <positional-argument> <optional-arguments>

Notice that throughout the CLI, the auto-completion (the infamous [tab][tab]) is readily available for verbs, sub-verbs and most positional arguments. Similarly, helpers are available at each stage,

$ ros2 verb --help
$ ros2 verb sub-verb -h

Let us see a few examples,

$ ros2 run demo_node_cpp talker
starts the talker cpp node from the demo_nodes_cpp package.

$ ros2 run demo_node_py listener
starts the listener python node from the demo_nodes_py package.

$ ros2 topic echo /chatter
outputs the messages sent from the talker node.

$ ros2 node info /listener
outputs information about the listener node.

$ ros2 param list
lists all parameters of every node.

Fairly similar to ROS 1 right ?

Missing CLI tools

We mentioned earlier that most of the CLI tools were ported to ROS 2, but not all. We believe such missing tools is one of the barriers to greater adoption of ROS 2, so we’ve started added some that we noticed were missing. Over the past week we contributed 5 sub-verbs, including one that is exclusive to ROS 2. Let us briefly review them,

$ ros2 topic find <message-type>
outputs a list of all topics publishing messages of a given type (#271).

$ ros2 topic type <topic-name>
outputs the message type of a given topic (#272).

$ ros2 service find <service-type>
outputs a list of all services of a given type (#273).

$ ros2 service type <service-name>
outputs the service type of a given service (#274).

This tools are pretty handy by themselves, especially to debug and grasp an overview of a running system. And they become even more interesting when combined, say, in handy little scripts,

$ ros2 topic pub /chatter $(ros2 topic type /chatter) "data: Hello ROS 2 Developers"

Advertisement:
Have you ever looked for the version of a package you are using ?
Ever wondered who is the package author ?
Or which other packages it depends upon ?
All of this information, locked in the package’s xml manifest is now easily available at the tip of your fingers !

The new sub-verb we introduced allows one to retrieve any information contained in a package xml manifest (#280). The command,

$ ros2 pkg xml <package-name>
outputs the entirety of the xml manifest of a given package.
To retrieve solely a piece of it, or a tag in xml wording, use the --tag option,

$ ros2 pkg xml <package-name> --tag <tag-name>

A few examples are (at the time of writing),

$ ros2 pkg xml demo_nodes_cpp --tag version
0.7.6

$ ros2 pkg xml demo_nodes_py -t author
Mikael Arguedas
Esteve Fernandez

$ ros2 pkg xml intra_process_demo -t build_depend libopencv-dev
rclcpp
sensor_msgs
std_msgs

This concludes our brief review of the changes that ROS 2 introduced to the CLI tools.

Before leaving, let me offer you a treat.

— A ROS 2 CLI Cheats Sheet that we put together —

Feel free to share it, print and pin it above your screen but also contribute to it as it is hosted on github !

Cheers.

The post ROS 2 Command Line Interface appeared first on Ubuntu Blog.

Read more
wgs1

MicroK8s can be used to run Kubernetes on Mac for testing and developing apps on macOS. Follow the steps below for easy setup.

Kubernetes on Mac install and Grafana dashboard

MicroK8s is the local distribution of Kubernetes developed by Ubuntu. It’s a compact Linux snap that installs a single node cluster on a local PC. Although MicroK8s is only built for Linux, Kubernetes on Mac works by setting up a cluster in an Ubuntu VM.

It runs all Kubernetes services natively on Ubuntu and any operating system (OS) which supports snaps. This is beneficial for testing and building apps, creating simple Kubernetes clusters and developing microservices locally –  essentially all dev work that needs deployment.

MicroK8s provides another level of reliability because it provides the most current version of Kubernetes for development. The latest upstream version of Kubernetes is always available on Ubuntu within one week of official release.

Kubernetes on Mac set up steps

Kubernetes and MicroK8s both need a Linux kernel to work and require an Ubuntu VM as mentioned above. Mac users also need Multipass, the tool for launching Ubuntu VMs on Mac, Windows and Linux.

Here are instructions to set up Multipass and to run Kubernetes on Mac.

Step 1: Install a VM for Mac using Multipass

The latest Multipass package is available on GitHub. Double click the .pkg file to install it.

To start a VM with MicroK8s run:

multipass launch --name microk8s-vm --mem 4G --disk 40G
multipass exec microk8s-vm -- sudo snap install microk8s --classic
multipass exec microk8s-vm -- sudo iptables -P FORWARD ACCEPT

Make enough resources available for hosting. Above we’ve created a VM named microk8s-vm and given it 4GB of RAM and 40GB of disk.

The VM has an IP that can be checked with the following: (Take note of this IP since our services will become available here).

multipass list
Name         State IPv4            Release
microk8s-vm  RUNNING 192.168.64.1   Ubuntu 18.04 LTS

Step 2: Interact with MicroK8s on the VM

This can be done in three ways:

  • Using a Multipass shell prompt (command line) by running:
multipass shell microk8s-vm                                                                                     
  • Using multipass exec to execute a command without a shell prompt by inputting:
multipass exec microk8s-vm -- /snap/bin/microk8s.status                             
  • Using the Kubernetes API server running in the VM. Here one would use MicroK8s kubeconfig file with a local installation of kubectl to access the in-VM-kubernetes. Do this by running:
multipass exec microk8s-vm -- /snap/bin/microk8s.config > kubeconfig     

Next, install kubectl on the host machine and then use the kubeconfig:

kubectl --kubeconfig=kubeconfig get all --all-namespaces            
NAMESPACE  NAME  TYPE  CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE        
Default service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 3m12s

Step 3: Access in-VM Multipass services – enabling MicroK8s add-ons

A basic MicroK8s add-on to set up is the Grafana dashboard. Below we show one way of accessing Grafana to monitor and analyse a MicroK8s instance. To do this execute:

multipass exec microk8s-vm -- /snap/bin/microk8s.enable dns dashboard
Enabling DNS
Applying manifest
service/kube-dns created
serviceaccount/kube-dns created
configmap/kube-dns created
deployment.extensions/kube-dns created
Restarting kubelet
DNS is enabled
Enabling dashboard
secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created
service/monitoring-grafana created
service/monitoring-influxdb created
service/heapster created
deployment.extensions/monitoring-influxdb-grafana-v4 created
serviceaccount/heapster created
configmap/heapster-config created
configmap/eventer-config created
deployment.extesions/heapster-v1.5.2 created
dashboard enabled

Next, check the deployment progress by running:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl get all --all-namespaces                                                                                                                        

Which should return output similar to:

Kubernetes-on-Mac-namespaces-for-MicroK8s

Once all the necessary services are running, the next step is to access the dashboard, for which we need a URL to visit. To do this, run:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl cluster-info  
Kubernetes master is running at https://127.0.0.1:16443
Heapster is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Grafana is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
InfluxDB is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-influxdb:http/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

If we were inside the VM, we could access the Grafana dashboard by visiting: this URL But, we want to access the dashboard from the host (i.e. outside the VM). We can use a proxy to do this:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl proxy --address='0.0.0.0' --accept-hosts='.*' 
Starting to serve on [::][::]:8001

Leave the Terminal open with this command running and take note of the port (8001). We will need this next.

To visit the Grafana dashboard, we need to modify the in-VM dashboard URL by:

Kubernetes on Mac in summary

Building apps that are easy to scale and distribute has taken pride-of-place for developers and DevOp teams. Developing and testing apps locally using MicroK8s should help teams to deploy their builds faster.

Useful reading

The post Kubernetes on Mac: how to set up appeared first on Ubuntu Blog.

Read more
wgs1

MicroK8s can be used to run Kubernetes on Mac for testing and developing apps on macOS. Follow the steps below for easy setup.

Kubernetes on Mac install and Grafana dashboard

MicroK8s is the local distribution of Kubernetes developed by Ubuntu. It’s a compact Linux snap that installs a single node cluster on a local PC. Although MicroK8s is only built for Linux, Kubernetes on Mac works by setting up a cluster in an Ubuntu VM.

It runs all Kubernetes services natively on Ubuntu and any operating system (OS) which supports snaps. This is beneficial for testing and building apps, creating simple Kubernetes clusters and developing microservices locally –  essentially all dev work that needs deployment.

MicroK8s provides another level of reliability because it provides the most current version of Kubernetes for development. The latest upstream version of Kubernetes is always available on Ubuntu within one week of official release.

Kubernetes on Mac set up steps

Kubernetes and MicroK8s both need a Linux kernel to work and require an Ubuntu VM as mentioned above. Mac users also need Multipass, the tool for launching Ubuntu VMs on Mac, Windows and Linux.

Here are instructions to set up Multipass and to run Kubernetes on Mac.

Step 1: Install a VM for Mac using Multipass

The latest Multipass package is available on GitHub. Double click the .pkg file to install it.

To start a VM with MicroK8s run:

multipass launch --name microk8s-vm --mem 4G --disk 40G
multipass exec microk8s-vm -- sudo snap install microk8s --classic
multipass exec microk8s-vm -- sudo iptables -P FORWARD ACCEPT

Make enough resources available for hosting. Above we’ve created a VM named microk8s-vm and given it 4GB of RAM and 40GB of disk.

The VM has an IP that can be checked with the following: (Take note of this IP since our services will become available here).

multipass list
Name         State IPv4            Release
microk8s-vm  RUNNING 192.168.64.1   Ubuntu 18.04 LTS

Step 2: Interact with MicroK8s on the VM

This can be done in three ways:

  • Using a Multipass shell prompt (command line) by running:
multipass shell microk8s-vm                                                                                     
  • Using multipass exec to execute a command without a shell prompt by inputting:
multipass exec microk8s-vm -- /snap/bin/microk8s.status                             
  • Using the Kubernetes API server running in the VM. Here one would use MicroK8s kubeconfig file with a local installation of kubectl to access the in-VM-kubernetes. Do this by running:
multipass exec microk8s-vm -- /snap/bin/microk8s.config > kubeconfig     

Next, install kubectl on the host machine and then use the kubeconfig:

kubectl --kubeconfig=kubeconfig get all --all-namespaces            
NAMESPACE  NAME  TYPE  CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE        
Default service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 3m12s

Step 3: Access in-VM Multipass services – enabling MicroK8s add-ons

A basic MicroK8s add-on to set up is the Grafana dashboard. Below we show one way of accessing Grafana to monitor and analyse a MicroK8s instance. To do this execute:

multipass exec microk8s-vm -- /snap/bin/microk8s.enable dns dashboard
Enabling DNS
Applying manifest
service/kube-dns created
serviceaccount/kube-dns created
configmap/kube-dns created
deployment.extensions/kube-dns created
Restarting kubelet
DNS is enabled
Enabling dashboard
secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created
service/monitoring-grafana created
service/monitoring-influxdb created
service/heapster created
deployment.extensions/monitoring-influxdb-grafana-v4 created
serviceaccount/heapster created
configmap/heapster-config created
configmap/eventer-config created
deployment.extesions/heapster-v1.5.2 created
dashboard enabled

Next, check the deployment progress by running:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl get all --all-namespaces                                                                                                                        

Which should return output similar to:

Kubernetes-on-Mac-namespaces-for-MicroK8s

Once all the necessary services are running, the next step is to access the dashboard, for which we need a URL to visit. To do this, run:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl cluster-info  
Kubernetes master is running at https://127.0.0.1:16443
Heapster is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Grafana is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
InfluxDB is running at https://127.0.0.1:16443/api/v1/namespaces/kube-system/services/monitoring-influxdb:http/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

If we were inside the VM, we could access the Grafana dashboard by visiting: this URL But, we want to access the dashboard from the host (i.e. outside the VM). We can use a proxy to do this:

multipass exec microk8s-vm -- /snap/bin/microk8s.kubectl proxy --address='0.0.0.0' --accept-hosts='.*' 
Starting to serve on [::][::]:8001

Leave the Terminal open with this command running and take note of the port (8001). We will need this next.

To visit the Grafana dashboard, we need to modify the in-VM dashboard URL by:

Kubernetes on Mac in summary

Building apps that are easy to scale and distribute has taken pride-of-place for developers and DevOp teams. Developing and testing apps locally using MicroK8s should help teams to deploy their builds faster.

Useful reading

The post Kubernetes on Mac: how to set up appeared first on Ubuntu Blog.

Read more
Karl Williams

We have just released Vanilla Framework 2.0, Canonical’s SCSS styling framework, and – despite our best efforts to minimise the impact – the new features come with changes that will not be automatically backwards compatible with sites built using previous versions of the framework.

To make the transition to v2.0 easier, we have compiled a list of the major breaking changes and their solutions (when upgrading from v1.8+). This list is outlined below. We recommend that you treat this as a checklist while migrating your projects.

1. Spacing variable mapping

If you’ve used any of the spacing variables (they can be recognised as variables that start with $spv or $sph) in your Sass then you will need to update them before you can build CSS. The simplest way to update these variables is to find/replace them using the substitution values listed in the Vanilla spacing variables table.

2. Grid

2.1 Viewport-specific column names

Old class New class
mobile-col-* col-small-*
tablet-col-* col-medium-*

2.2 Columns must be direct descendants of rows

Ensure .col-* are direct descendants of .row; this has always been the intended use of the pattern but there were instances where the rule could be ignored. This is no longer the case.

Additionally, any .col-*s that are not direct descendants will just span the full width of their container as a fallback.

You can see an example of correcting improperly-nested column markup in this ubuntu.com pull request.

2.3 Remove any Shelves grid functionality

The framework no longer includes Shelves, classes starting with prefix-, suffix-, push- and pull- and no longer supported but arbitrary positioning on our new grid is achieved by stating an arbitrary starting column using col-start- classes.

For example: if you want an eight-column container starting at the fourth column in the grid you would use the classes col-8 col-start-4.

You can read full documentation and an example in the Empty Columns documentation.

2.4 Fixed width containers with no columns

Previously, a .row with a single col-12 or a col-12 on its own may have been used to display content in a fixed-width container. The nested solution adds unnecessary markup and a lone col-12 will no longer work.

A simple way to make an element fixed width, use the utility .u-fixed-width, which does not need columns.

2.5 Canonical global nav

If your website makes use of the Canonical global navigation module (If so, hello colleague or community member!) then ensure that the ensure global nav width matches the new fixed-width (72rem by default). A typical implementation would look like the following HTML:

<script src="/js/global-nav.js"></script> <script>canonicalGlobalNav.createNav({maxWidth: '72rem'});</script>

3. Renamed patterns

Some class names have been marked for renaming or the classes required to use them have been minimised.

3.1 Stepped lists

We favour component names that sound natural in English to make the framework more intuitive. “list step” wasn’t a good name and didn’t explain its use very well so we decedided to rename it to the much more explicit “stepped list”.

In order to update the classes in your project search and replace the following:

Old class name New class name
.p-list-step .p-stepped-list
.p-list-step__item .p-stepped-list__item

3.2 Code snippet

“Code snippet” was an ambiguous name so we have renamed it to “code copyable” to indicate the major difference between it and other code variants.

Change the classes your code to the following:

Old class name New class name
.p-code-snippet .p-code-copyable

If you’ve extended the mixin then you’ll need to update the mixin name as follows:

Old mixin name New mixin name
vf-p-code-snippet vf-p-code-copyable

The p-tooltips class remains the same but you no longer need two classes to use the pattern because the modified tooltips now include all required styling. Markup can be simplified as follows (this is the same for all tooltip variants):

Old markup New markup
<button class="p-tooltip p-tooltip--btm-center" …> <button class="p-tooltip--btm-center" …>

4. Breakpoints

Media queries changed due to a WG proposal. Ensure any local media queries are aligned with the new ones. Also, update any hard-coded media queries (e.g. in the markup) to the new values. The new values can be found in the docs (local link)

5. Deprecated components

5.1 Footer (p-footer)

This component is now entirely removed with no direct replacement. Footers can be constructed with a standard p-strip, row markup.

5.2 Button switch (button.p-switch)

Buttons shouldn’t be used with the p-switch component and are no longer supported. Instead, use the much more semantic checkbox input instead.

5.3 Hidden, visible (u-hidden, u-visible)

These have been deprecated and the one visibility-controlling class format is u-hide (and the more specific variants – u-hide documentation)

5.4 Warning notification (p-notification–warning)

This name for the component has been deprecated and it is now only available as p-notification--caution

5.5 p-link–no-underline

This was an obsolete modifier for a removed version underlined links that used borders

5.6 Strong link (p-link–strong)

This has been removed with no replacement as it was an under-utilised component with no clear usage guidelines.

5.7 Inline image variants

The variants p-inline-images img and p-inline-images__img have been removed and the generic implementation now supports all requirements.

5.7 Sidebar navigation (p-navigation–sidebar)

For navigation, the core p-navigation component is recommended. If sidebar-like functionality is still required then if can be constructed with the default grid components.

5.7 Float utilities (p-float*)

To move them in-line with the naming conventions used elsewhere in the framework, u-float--right and u-float--left are now u-float-right and u-float-left (One “-” is removed to make them first-level components rather than modifers. This is to allow for modifiers for screen sizes).

6. (Optional) Do not wrap buttons / anchors in paragraphs.

We have CSS rules in place to ensure that wrapped buttons behave as if they aren’t, and we would like to remove this as it is unnecessary bloat. In order to do that, we need to ensure buttons are no longer wrapped. This back-support is likely to be deprecated in future versions of the framework.

7. Update stacked forms to use the grid (p-form–stacked).

The hard-coded widths (25%/75%) on labels and inputs have been removed. This will break any layouts that use them, so please wrap the form elements in .row>.col-*.

8. Replace references to $px variable

$px used to stand for 1px expressed as a rem value. This was used, for example, to calculate padding so that the padding plus the border equals a round rem value. This could no longer work once we introduced the font size increase at 1680px, because the value of 1rem changes from 16px to 18px.

Replace instances of this variable with calc({rem value} +/- 1px).

This means you need to replace e.g.:

Before: padding: $spv-nudge - $px $sph-intra--condensed * 1.5 - ($px * 2);

After: padding: calc(#{$spv-nudge} - 1px) calc(#{$sph-intra--condensed * 1.5} - 2px);

9. Replace references to $color-warning with $color-caution

This was a backwards compatibility affordance that had been deprecated for the last few releases.

10. (Optional) Try to keep text elements as siblings in the same container

Unless you really need to wrap in different containers, e.g. (emmet notation) div>h4+div>p, use div>h4+p. This way the page will benefit from the careful adjustments of white space using <element>+<element> css rules, i.e. p+p, p+h4 etc. Ignoring this won’t break the page, but the spacing between text elements will not be ideal.

11. $font-base-size is now a map of sizes

To allow for multiple base font sizes for different screen sizes, we have turned the $font-base-size variable into a map.

A quick fix to continue using the deprecated variable locally would be:

$font-base-size: map-get($base-font-sizes, base);

But, for a more future-proof version, you should understand and use the new map.

By default, the font-size of the root element (<html>) increases on screens larger than the value of $breakpoint-x-large. This means it can no longer be represented as a single variable. Instead, we use a map to store the two font sizes ($base-font-sizes). If you are using $font-base-size in your code, replace as needed with a value from the $base-font-sizes map.

That’s it

Following the previous steps should now have your project using the latest features of Vanilla 2.0. There may be more work updating your local code and removing any temporary local fixes for issues we have fixed since the last release but this will vary from project to project.

If you still need help then please contact us on twitter or refer to the full Vanilla Framework documentation.

If, in the process of using Vanilla, you find bugs then please report them as issues on Github where we also welcome pull request submissions from the community if you want to suggest a fix.

The post Vanilla Framework 2.0 upgrade guide appeared first on Ubuntu Blog.

Read more
Karl Williams

We have just released Vanilla Framework 2.0, Canonical’s SCSS styling framework, and – despite our best efforts to minimise the impact – the new features come with changes that will not be automatically backwards compatible with sites built using previous versions of the framework.

To make the transition to v2.0 easier, we have compiled a list of the major breaking changes and their solutions (when upgrading from v1.8+). This list is outlined below. We recommend that you treat this as a checklist while migrating your projects.

1. Spacing variable mapping

If you’ve used any of the spacing variables (they can be recognised as variables that start with $spv or $sph) in your Sass then you will need to update them before you can build CSS. The simplest way to update these variables is to find/replace them using the substitution values listed in the Vanilla spacing variables table.

2. Grid

2.1 Viewport-specific column names

Old class New class
mobile-col-* col-small-*
tablet-col-* col-medium-*

2.2 Columns must be direct descendants of rows

Ensure .col-* are direct descendants of .row; this has always been the intended use of the pattern but there were instances where the rule could be ignored. This is no longer the case.

Additionally, any .col-*s that are not direct descendants will just span the full width of their container as a fallback.

You can see an example of correcting improperly-nested column markup in this ubuntu.com pull request.

2.3 Remove any Shelves grid functionality

The framework no longer includes Shelves, classes starting with prefix-, suffix-, push- and pull- and no longer supported but arbitrary positioning on our new grid is achieved by stating an arbitrary starting column using col-start- classes.

For example: if you want an eight-column container starting at the fourth column in the grid you would use the classes col-8 col-start-4.

You can read full documentation and an example in the Empty Columns documentation.

2.4 Fixed width containers with no columns

Previously, a .row with a single col-12 or a col-12 on its own may have been used to display content in a fixed-width container. The nested solution adds unnecessary markup and a lone col-12 will no longer work.

A simple way to make an element fixed width, use the utility .u-fixed-width, which does not need columns.

2.5 Canonical global nav

If your website makes use of the Canonical global navigation module (If so, hello colleague or community member!) then ensure that the ensure global nav width matches the new fixed-width (72rem by default). A typical implementation would look like the following HTML:

<script src="/js/global-nav.js"></script> <script>canonicalGlobalNav.createNav({maxWidth: '72rem'});</script>

3. Renamed patterns

Some class names have been marked for renaming or the classes required to use them have been minimised.

3.1 Stepped lists

We favour component names that sound natural in English to make the framework more intuitive. “list step” wasn’t a good name and didn’t explain its use very well so we decedided to rename it to the much more explicit “stepped list”.

In order to update the classes in your project search and replace the following:

Old class name New class name
.p-list-step .p-stepped-list
.p-list-step__item .p-stepped-list__item

3.2 Code snippet

“Code snippet” was an ambiguous name so we have renamed it to “code copyable” to indicate the major difference between it and other code variants.

Change the classes your code to the following:

Old class name New class name
.p-code-snippet .p-code-copyable

If you’ve extended the mixin then you’ll need to update the mixin name as follows:

Old mixin name New mixin name
vf-p-code-snippet vf-p-code-copyable

The p-tooltips class remains the same but you no longer need two classes to use the pattern because the modified tooltips now include all required styling. Markup can be simplified as follows (this is the same for all tooltip variants):

Old markup New markup
<button class="p-tooltip p-tooltip--btm-center" …> <button class="p-tooltip--btm-center" …>

4. Breakpoints

Media queries changed due to a WG proposal. Ensure any local media queries are aligned with the new ones. Also, update any hard-coded media queries (e.g. in the markup) to the new values. The new values can be found in the docs (local link)

5. Deprecated components

5.1 Footer (p-footer)

This component is now entirely removed with no direct replacement. Footers can be constructed with a standard p-strip, row markup.

5.2 Button switch (button.p-switch)

Buttons shouldn’t be used with the p-switch component and are no longer supported. Instead, use the much more semantic checkbox input instead.

5.3 Hidden, visible (u-hidden, u-visible)

These have been deprecated and the one visibility-controlling class format is u-hide (and the more specific variants – u-hide documentation)

5.4 Warning notification (p-notification–warning)

This name for the component has been deprecated and it is now only available as p-notification--caution

5.5 p-link–no-underline

This was an obsolete modifier for a removed version underlined links that used borders

5.6 Strong link (p-link–strong)

This has been removed with no replacement as it was an under-utilised component with no clear usage guidelines.

5.7 Inline image variants

The variants p-inline-images img and p-inline-images__img have been removed and the generic implementation now supports all requirements.

5.7 Sidebar navigation (p-navigation–sidebar)

For navigation, the core p-navigation component is recommended. If sidebar-like functionality is still required then if can be constructed with the default grid components.

5.7 Float utilities (p-float*)

To move them in-line with the naming conventions used elsewhere in the framework, u-float--right and u-float--left are now u-float-right and u-float-left (One “-” is removed to make them first-level components rather than modifers. This is to allow for modifiers for screen sizes).

6. (Optional) Do not wrap buttons / anchors in paragraphs.

We have CSS rules in place to ensure that wrapped buttons behave as if they aren’t, and we would like to remove this as it is unnecessary bloat. In order to do that, we need to ensure buttons are no longer wrapped. This back-support is likely to be deprecated in future versions of the framework.

7. Update stacked forms to use the grid (p-form–stacked).

The hard-coded widths (25%/75%) on labels and inputs have been removed. This will break any layouts that use them, so please wrap the form elements in .row>.col-*.

8. Replace references to $px variable

$px used to stand for 1px expressed as a rem value. This was used, for example, to calculate padding so that the padding plus the border equals a round rem value. This could no longer work once we introduced the font size increase at 1680px, because the value of 1rem changes from 16px to 18px.

Replace instances of this variable with calc({rem value} +/- 1px).

This means you need to replace e.g.:

Before: padding: $spv-nudge - $px $sph-intra--condensed * 1.5 - ($px * 2);

After: padding: calc(#{$spv-nudge} - 1px) calc(#{$sph-intra--condensed * 1.5} - 2px);

9. Replace references to $color-warning with $color-caution

This was a backwards compatibility affordance that had been deprecated for the last few releases.

10. (Optional) Try to keep text elements as siblings in the same container

Unless you really need to wrap in different containers, e.g. (emmet notation) div>h4+div>p, use div>h4+p. This way the page will benefit from the careful adjustments of white space using <element>+<element> css rules, i.e. p+p, p+h4 etc. Ignoring this won’t break the page, but the spacing between text elements will not be ideal.

11. $font-base-size is now a map of sizes

To allow for multiple base font sizes for different screen sizes, we have turned the $font-base-size variable into a map.

A quick fix to continue using the deprecated variable locally would be:

$font-base-size: map-get($base-font-sizes, base);

But, for a more future-proof version, you should understand and use the new map.

By default, the font-size of the root element (<html>) increases on screens larger than the value of $breakpoint-x-large. This means it can no longer be represented as a single variable. Instead, we use a map to store the two font sizes ($base-font-sizes). If you are using $font-base-size in your code, replace as needed with a value from the $base-font-sizes map.

That’s it

Following the previous steps should now have your project using the latest features of Vanilla 2.0. There may be more work updating your local code and removing any temporary local fixes for issues we have fixed since the last release but this will vary from project to project.

If you still need help then please contact us on twitter or refer to the full Vanilla Framework documentation.

If, in the process of using Vanilla, you find bugs then please report them as issues on Github where we also welcome pull request submissions from the community if you want to suggest a fix.

The post Vanilla Framework 2.0 upgrade guide appeared first on Ubuntu Blog.

Read more
Igor Ljubuncic

In Linux, testing software is both easy and difficult at the same time. While the repository channels offer great availability to software, you can typically only install a single instance of an application. If you want to test multiple instances, you will most likely need to configure the remainder yourself. With snaps, this is a fairly simple task.

From version 2.36 onwards, snapd supports parallel install – a capability that lets you have multiple instances of the same snap available on your system, each isolated from the others, with its own configurations, interfaces, services, and more. Let’s see how this is done.

Experimental features & unique identifier

The first step is to turn on a special flag that lets snapd manage parallel installs:

snap set system experimental.parallel-instances=true

Once this step is done, you can proceed to installing software. Now, the actual setup may appear slightly counter-intuitive, because you need to append a unique identifier to each snap instance name to distinguish them from the other(s). The identifier is an alphanumeric string, up to 10 characters in length, and it is added as a suffix to the snap name. This is a manual step, and you can choose anything you like for the identifier. For example, if you want to install GIMP with your own identifier, you can do something like:

snap install gimp_first

Technically, gimp_first does not exist as a snap, but snapd will be able to interpret the format of “snap name” “underscore” “unique identifier” and install the right software as a separate instance.

You have quite a bit of freedom choosing how you use this feature. You can install them each individually or indeed in parallel, e.g. snap install gimp_1 gimp_2 gimp_3. You can install a production version (e.g. snap install vlc) and then use unique identifiers for your test installs only. In fact, this may be the preferred way, as you will be able to clearly tell your different instances apart.

Testing 1 2 3

You can try parallel installs with any snap in the store. For example, let’s setup two instances of odio. Snapd will only download the snap package once, and then configure the two requested instances separately.

snap install odio_first odio_second
odio_second 1 from Canonical✓ installed
odio_first 1 from Canonical✓ installed

From here on, you can manage each instance in its own right. You can remove each one using its full name (including the identifier), connect and disconnect interfaces, start and stop services, create aliases, and more. For instance:

snap remove odio_second
odio_second removed

Different instances, different versions

It gets better. Not only can you have multiple instances, you can manage the release channel of each instance separately. So if you want to test different versions – which can really be helpful if you want to learn (and prepare for) what new editions of an application bring, you can do this in parallel to your production setup, without requiring additional hardware, operating system instances, users – or having to worry about potentially harming your environment.

snap info vlc
name:      vlc
summary:   The ultimate media player

channels:
stable:    3.0.7                      2019-06-07 (1049) 212MB -
candidate: 3.0.7                      2019-06-07 (1049) 212MB -
beta:      3.0.7.1-1-6-gdedb3bd       2019-06-18 (1071) 212MB -
edge:      4.0.0-dev-8388-gb425adb06c 2019-06-18 (1070) 329MB -

VLC is a good example, with stable version 3.0.7 available, and preview version 4.0.0 in the edge channel. If you already have multiple instances installed, you can just refresh one of them, e.g.: the aptly named vlc_edge instance:

snap refresh --edge vlc_edge

Or you can even directly install a different version as a separate instance:

snap install --candidate vlc_second
vlc_second (candidate) 3.0.7 from VideoLAN✓ installed

You can check your installed instances, and you will see the whole gamut of versions:

snap list| grep vlc
vlc         3.0.7          1049   stable     videolan*      -
vlc_edge    4.0.0-dev-...  1070 edge     videolan*      -
vlc_second  3.0.7          1049   candidate  videolan*     -

When parallel lines touch

For all practical purposes, these will be individual applications with their own home directory and data. In a way, this is quite convenient, but it can be problematic if your snaps require exclusive access to system resources, like sockets or ports. If you have a snap that runs a service, only one instance will be able to bind to a predefined port, while others will fail.On the other hand, this is quite useful for testing the server-client model, or how different applications inside the snap work with one another. The namespace collisions as well as methods to share data using common directories are described in detail in the documentation. Parallel installs do offer a great deal of flexibility, but it is important to remember that most applications are designed to run individually on a system.

Summary

The value proposition of self-contained applications like snaps has been debated in online circles for years now, revolving around various pros and cons compared to installations from traditional repository channels. In many cases, there’s no clear-cut answer, however parallel installs do offer snaps a distinct, unparalleled [sic] advantage. You have the ability to run multiple instances, multiple versions of your applications in a safe, isolated manner.

At the moment, parallel installs are experimental, best suited for users comfortable with software testing. But the functionality does open a range of interesting possibilities, as it allows early access to new tools and features, while at the same time, you can continue using your production setup without any risk. If you have any comments or suggestions, please join our forum for a discussion.

Photo by Kholodnitskiy Maksim on Unsplash.

The post Parallel installs – test and run multiple instances of snaps appeared first on Ubuntu Blog.

Read more
Igor Ljubuncic

In Linux, testing software is both easy and difficult at the same time. While the repository channels offer great availability to software, you can typically only install a single instance of an application. If you want to test multiple instances, you will most likely need to configure the remainder yourself. With snaps, this is a fairly simple task.

From version 2.36 onwards, snapd supports parallel install – a capability that lets you have multiple instances of the same snap available on your system, each isolated from the others, with its own configurations, interfaces, services, and more. Let’s see how this is done.

Experimental features & unique identifier

The first step is to turn on a special flag that lets snapd manage parallel installs:

snap set system experimental.parallel-instances=true

Once this step is done, you can proceed to installing software. Now, the actual setup may appear slightly counter-intuitive, because you need to append a unique identifier to each snap instance name to distinguish them from the other(s). The identifier is an alphanumeric string, up to 10 characters in length, and it is added as a suffix to the snap name. This is a manual step, and you can choose anything you like for the identifier. For example, if you want to install GIMP with your own identifier, you can do something like:

snap install gimp_first

Technically, gimp_first does not exist as a snap, but snapd will be able to interpret the format of “snap name” “underscore” “unique identifier” and install the right software as a separate instance.

You have quite a bit of freedom choosing how you use this feature. You can install them each individually or indeed in parallel, e.g. snap install gimp_1 gimp_2 gimp_3. You can install a production version (e.g. snap install vlc) and then use unique identifiers for your test installs only. In fact, this may be the preferred way, as you will be able to clearly tell your different instances apart.

Testing 1 2 3

You can try parallel installs with any snap in the store. For example, let’s setup two instances of odio. Snapd will only download the snap package once, and then configure the two requested instances separately.

snap install odio_first odio_second
odio_second 1 from Canonical✓ installed
odio_first 1 from Canonical✓ installed

From here on, you can manage each instance in its own right. You can remove each one using its full name (including the identifier), connect and disconnect interfaces, start and stop services, create aliases, and more. For instance:

snap remove odio_second
odio_second removed

Different instances, different versions

It gets better. Not only can you have multiple instances, you can manage the release channel of each instance separately. So if you want to test different versions – which can really be helpful if you want to learn (and prepare for) what new editions of an application bring, you can do this in parallel to your production setup, without requiring additional hardware, operating system instances, users – or having to worry about potentially harming your environment.

snap info vlc
name:      vlc
summary:   The ultimate media player

channels:
stable:    3.0.7                      2019-06-07 (1049) 212MB -
candidate: 3.0.7                      2019-06-07 (1049) 212MB -
beta:      3.0.7.1-1-6-gdedb3bd       2019-06-18 (1071) 212MB -
edge:      4.0.0-dev-8388-gb425adb06c 2019-06-18 (1070) 329MB -

VLC is a good example, with stable version 3.0.7 available, and preview version 4.0.0 in the edge channel. If you already have multiple instances installed, you can just refresh one of them, e.g.: the aptly named vlc_edge instance:

snap refresh --edge vlc_edge

Or you can even directly install a different version as a separate instance:

snap install --candidate vlc_second
vlc_second (candidate) 3.0.7 from VideoLAN✓ installed

You can check your installed instances, and you will see the whole gamut of versions:

snap list| grep vlc
vlc         3.0.7          1049   stable     videolan*      -
vlc_edge    4.0.0-dev-...  1070 edge     videolan*      -
vlc_second  3.0.7          1049   candidate  videolan*     -

When parallel lines touch

For all practical purposes, these will be individual applications with their own home directory and data. In a way, this is quite convenient, but it can be problematic if your snaps require exclusive access to system resources, like sockets or ports. If you have a snap that runs a service, only one instance will be able to bind to a predefined port, while others will fail.On the other hand, this is quite useful for testing the server-client model, or how different applications inside the snap work with one another. The namespace collisions as well as methods to share data using common directories are described in detail in the documentation. Parallel installs do offer a great deal of flexibility, but it is important to remember that most applications are designed to run individually on a system.

Summary

The value proposition of self-contained applications like snaps has been debated in online circles for years now, revolving around various pros and cons compared to installations from traditional repository channels. In many cases, there’s no clear-cut answer, however parallel installs do offer snaps a distinct, unparalleled [sic] advantage. You have the ability to run multiple instances, multiple versions of your applications in a safe, isolated manner.

At the moment, parallel installs are experimental, best suited for users comfortable with software testing. But the functionality does open a range of interesting possibilities, as it allows early access to new tools and features, while at the same time, you can continue using your production setup without any risk. If you have any comments or suggestions, please join our forum for a discussion.

Photo by Kholodnitskiy Maksim on Unsplash.

The post Parallel installs – test and run multiple instances of snaps appeared first on Ubuntu Blog.

Read more
Canonical

Canonical widens Kubernetes support with kubeadm

Canonical announces full enterprise support for Kubernetes 1.15 using kubeadm deployments, its Charmed Kubernetes, and MicroK8s; the popular single-node deployment of Kubernetes.

The MicroK8s community continues to grow and contribute enhancements, with Knative and RBAC support now available through the simple microk8s.enable command. Knative is a great way to experiment with serverless computing, and now you can experiment locally through MicroK8s. With MicroK8s 1.15 you can develop and deploy Kubernetes 1.15 on any Linux desktop, server or VM across 40 Linux distros. Mac and Windows are supported too, with Multipass.

Existing Charmed Kubernetes users can upgrade smoothly to Kubernetes 1.15, regardless of the underlying hardware or machine virtualisation. Supported deployment targets include AWS, GCE, Azure, Oracle, VMware, OpenStack, LXD, and bare metal.

“Kubernetes 1.15 includes exciting new enhancements in application, custom resource, storage, and network management. These features enable better quota management, allow custom resources to behave more like core resources, and offer performance enhancements in networking. The Ubuntu ecosystem benefits from the latest features of Kubernetes, as soon as they become available upstream“ commented Carmine Rimi, Kubernetes Product Manager at Canonical.

What’s new in Kubernetes 1.15

Notable upstream Kubernetes 1.15 features:

  • Storage enhancements:
    • Quotas for ephemeral storage: (alpha) Quotas utilises filesystem project quotas to provide monitoring of resource consumption and optionally enforcement of limits. Project quotas, initially in XFS and more recently ported to ext4fs, offer a kernel-based means of monitoring and restricting filesystem consumption. This improves performance of monitoring storage utilisation of ephemeral volumes.
    • Extend data sources for persistent volume claims (PVC): (alpha) You can now specify an existing PVC as a DataSource parameter for creating a new PVC. This results in a clone – a duplicate – of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The back end device creates an exact duplicate of the specified Volume. Clones and Snapshots are different – a Clone results in a new, duplicate volume being provisioned from an existing volume — it counts against the users volume quota, it follows the same create flow and validation checks as any other volume provisioning request, it has the same lifecycle and workflow. Snapshots, on the other hand, results in a point-in-time copy of a volume that is not, itself, a usable volume.
    • Dynamic persistent volume (PV) resizing: (beta) This enhancement allows PVs to be resized without having to terminate pods and unmount the volume first.
  • Networking enhancements:
    • NodeLocal DNSCache: (beta) This enhancement improves DNS performance by running a dns caching agent on cluster nodes as a Daemonset. With this new architecture, pods reach out to the dns caching agent running on the same node, thereby avoiding unnecessary networking rules and connection tracking.
    • Finaliser protection for service load balancers: (alpha) Adding finaliser protection to ensure the Service resource is not fully deleted until the correlating LB is also deleted.
    • AWS Network Load Balancer Support: (beta) AWS users now have more choices for AWS load balancer configuration. This includes the Network Load Balancer, which offers extreme performance and static IPs for applications.
  • Node and Scheduler enhancements:
    • Device monitoring plugin support: (beta) Monitoring agents provide insight to the outside world about containers running on the node – this includes, but is not limited to, container logging exporters, container monitoring agents, and device monitoring plugins. This enhancement gives device vendors the ability to add metadata to a container’s metrics or logs so that it can be filtered and aggregated by namespace, pod, container, etc.  
    • Non-preemptive priority classes: (alpha) This feature adds a new option to PriorityClasses, which can enable or disable pod preemption. PriorityClasses impact the scheduling and eviction of pods – pods are scheduled according to descending priority; if a pod cannot be scheduled due to insufficient resources, lower-priority pods will be preempted to make room. Allowing PriorityClasses to be non-preempting is important for running batch workloads – pods with partially-completed work won’t be preempted, allowing them to finish.
    • Scheduling framework extension points: (alpha) The scheduling framework extension points allow many existing and future features of the scheduler to be written as plugins. Plugins are compiled into the scheduler, and these APIs allow many scheduling features to be implemented as plugins, while keeping the scheduling ‘core’ simple and maintainable.
  • Custom Resource Definitions (CRD) enhancements:
    • OpenAPI 3.0 Validation: Major changes introduced to schema validation with the addition of OpenAPI 3.0 validation.
    • Watch bookmark support: (alpha) The Watch API is one of the fundamentals of the Kubernetes API. This feature introduces a new type of watch event called Bookmark, which serves as a checkpoint of all objects, up to a given resourceVersion, that have been processed for a given watcher. This makes restarting watches cheaper and reduces the load on the apiserver by minimising the amount of unnecessary watch events that need to be processed after restarting a watch.
    • Defaulting: (alpha) This features add support for defaulting to Custom Resources. Defaulting is a fundamental step in the processing of API objects in the request pipeline of the kube-apiserver. Defaulting happens during deserialisation, after decoding of a versioned object, but before conversion to a hub type. This feature adds support for specifying default values for fields via OpenAPI v3 validation schemas in the CRD manifest. OpenAPI v3 has native support for a default field with arbitrary JSON values.
    • Pruning: (alpha) Custom Resources store arbitrary JSON data without following the typical Kubernetes API behaviour to prune unknown fields. This makes CRDs different, but also leads to security and general data consistency concerns because it is unclear what is actually stored. The pruning feature will prune all fields which are not specified in the OpenAPI validation schemas given in the CRD.
    • Admission webhook: (beta) Major changes were introduced. The admission webhook feature now supports both mutating webhook and validation (non-mutating) webhook. The dynamic registration API of webhook and the admission API are promoted to v1beta1.
  • For more information, please see the upstream Kubernetes 1.15 release notes.

Notable MicroK8s 1.15 features:

  • Pure upstream Kubernetes 1.15 binaries.
  • Knative addon, try it with “microk8s.enable knative”. Thank you @olatheander.
  • RBAC support via a simple “microk8s.enable rbac”, courtesy of @magne.
  • Update of the dashboard to 1.10.1 and fixes for RBAC. Thank you @balchua.
  • CoreDNS is now the default. Thanks @richardcase for driving this.
  • Ingress updated to 0.24.1 by @JorritSalverda, thank you.
  • Fix on socat failing on Fedora by @JimPatterson, thanks.
  • Modifiable csr server certificate, courtesy of @balchua.
  • Use of iptables kubeproxy mode by default.
  • Instructions on how to run Cilium on MicroK8s by @joestringer.

For complete details, along with installation instructions, see the MicroK8s 1.15 release notes and documentation.

Notable Charmed Kubernetes 1.15 features:

  • Pure upstream Kubernetes 1.15 binaries.
  • Containerd support: The default container runtime in Charmed Kubernetes 1.15 is containerd. Docker is still supported, and an upgrade path is provided for existing clusters wishing to migrate to containerd. Both runtimes can be used within a single cluster if desired. Container runtimes are now subordinate charms, paving the way for additional runtimes to be added in the future.
  • Calico 3 support: The Calico and Canal charms have been updated to install Calico 3.6.1 by default. For users currently running Calico 2.x, the next time you upgrade your Calico or Canal charm, the charm will automatically upgrade to Calico 3.6.1 with no user intervention required.
  • Calico BGP support: Several new config options have been added to the Calico charm to support BGP functionality within Calico. These additions make it possible to configure external BGP peers, route reflectors, and multiple IP pools.
  • Custom load balancer addresses: Support has been added to specify the IP address of an external load balancer. This support is in the kubeapi-load-balancer and the kubernetes-master charms. This allows a virtual IP address on the kubeapi-load-balancer charm or the IP address of an external load balancer.
  • Private container registry enhancements: A generic images-registry configuration option that will be honored by all Kubernetes charms, core charms and add-ons, so that users can specify a private registry in one place and have all images in a Kubernetes deployment come from that registry.
  • Keystone with CA Certificate support: Kubernetes integration with keystone now supports the use of user supplied CA certificates and can support https connections to keystone.
  • Graylog updated to version 3, which includes major updates to alerts, content packs, and pipeline rules. Sidecar has been re-architected so you can now use it with any log collector.
  • ElasticSearch updated to version 6. This version includes new features and enhancements to aggregations, allocation, analysis, mappings, search, and the task manager.

For complete details, see the Charmed Kubernetes 1.15 release notes and documentation.

Contact us

If you’re interested in Kubernetes support, consulting, or training, please get in touch!

About Charmed Kubernetes

Canonical’s certified, multi-cloud Charmed Kubernetes installs pure upstream binaries, and offers simplified deployment, scaling, management, and upgrades of Kubernetes, regardless of the underlying hardware or machine virtualisation. Supported deployment environments include AWS, GCE, Azure, VMware, OpenStack, LXD, and bare metal.

Charmed Kubernetes integrates tightly with underlying cloud services and hardware – enabling GPGPU’s automatically and leveraging cloud-specific services like AWS, Azure and GCE load balancers and storage. Charmed Kubernetes allows independent placement and scaling of components such as etcd or the Kubernetes Master, providing an HA or minimal configuration, and built-in, automated, on-demand upgrades from one version to the next.

Enterprise support for Charmed Kubernetes by Canonical provides customers with a highly available, multi-cloud, flexible and secure platform for their cloud-native workloads and enjoys wide adoption across enterprise, particularly in the telco, financial and retail sectors.

The post Kubernetes 1.15 now available from Canonical appeared first on Ubuntu Blog.

Read more