On Friday, March 31, The Linux Foundation will kick off a new initiative. No, it’s not a new project, event, or training course, although there are plenty of those in store. Instead, the foundation will begin a monthly Twitter chat, called #AskLF, with leaders at the organization.
Arpit Joshipura
With #AskLF, we aim to increase access to the bright minds and community organizers within The Linux Foundation. While there are many opportunities to interact with staff at Linux Foundation global events, which bring together over 25,000 open source influencers, a live Twitter Q&A will give participants a direct line of communication to the designated hosts.
The first host will be Arpit Joshipura, the General Manager of Networking & Orchestration appointed in late 2016. His #AskLF session will take place in advance of Open Networking Summit, where he will speak on two keynote panels alongside Linux Foundation Executive Director Jim Zemlin, ON.Lab/ONF Executive Director Guru Parulkar, and others. @linuxfoundation followers are encouraged to ask Joshipura questions related to the open source networking ecosystem.
Sample questions might include:
What is the goal of SDN? What can a network admin do in an SDN environment?
How can my company investigate the benefits of SDN/NFV?
How does The Linux Foundation help the open source community implement open networking at the individual and corporate level?
Here’s how you can participate in the first #AskLF:
Follow @linuxfoundation on Twitter: Hosts will take over The Linux Foundation’s account during the session.
Save the date:March 31, 2017 at 10 a.m. PT.
Use the hashtag #AskLF: To ask Joshipura your questions while he hosts, simply tweet it with the hashtag #AskLF on 3/31 between 10 am & 10:45 am PDT.
Draft questions in advance:Read about The Linux Foundation’s open networking strategy, Joshipura’s background, and upcoming speaking engagements in the links below. We can’t guarantee that he will have time to answer every inquiry, but every attempt will be made!
Consider attending Open Networking Summit in Santa Clara next month: This #AskLF session will prepare you to engage in the topics at ONS and you’ll get a chance to hear Joshipura speak live. Click here for registration details and discount info (that means you, students and academics!)
More dates and details for future #AskLF sessions to come! We’ll see you on Twitter, March 31st at 10 a.m. PT.
*Note: Unlike Reddit-style AMAs, #AskLF is not focused around general topics that might pertain to the host’s personal life. To participate, please focus your questions around open source networking and Arpit Joshipura’s career.
DevOps is a great concept — but many enterprises are still struggling to get out the starting gate with it.
That’s the key takeaway from a recent survey of 2,045 IT managers and professionals, released by Quali, an IT automation solutions provider. While most people in enterprises would say at this point that they have DevOps underway in some shape or form, achieving agility is another story.
For example, the majority of IT managers, 59%, say it takes more than a week to make needed changes or to get employees and other end-users on board with infrastructure.
In the previous article, I looked at the Intel Edison — how fast it was, and how much power it needed. This time, I will show how to start getting the Edison board to interact with surrounding electronics with the help of SparkFun Blocks (Figure 1).
Figure 1: SparkFun Blocks.
GPIO Block
The SparkFun GPIO Block breaks out various power and ground, along with a UART and four GPIO that can perform PWM output, and eight additional GPIO pins from the Edison. There is level shifting, which is enabled by default on the GPIO block to move things to a more convenient 3.3 volts. You cannot draw a great amount of current from the level shifted GPIO — it’s probably plenty if you are talking to an IC, but maybe not enough if you want to light up an LED.
The great part about the Edison running Linux is that the GPIO is exposed from the Linux kernel just as on other machines. If you have an application that can communicate with GPIO on the BeagleBone Black, porting it to run on the Edison might only require changing the paths to the GPIO pins you want to use. Below I expose pin 14, which is at the far end of the SparkFun GPIO block and toggle its state to a high voltage.
root@edison:/sys/class/gpio# echo 14 > export root@edison:/sys/class/gpio# cd ./gpio14root@edison:/sys/class/gpio/gpio14# cat value 0root@edison:/sys/class/gpio/gpio14# echo out > direction root@edison:/sys/class/gpio/gpio14# echo 1 > valueroot@edison:/sys/class/gpio/gpio14# cat value1
You can set the GPIO to ‘in’ and the ‘edge’ file to read the state of the pin instead. I tried a few ways to use tools liketail and inotify to monitor the ‘value’ file for changes when the value on the GPIO changed. Things got a little tricky, tail expects new data to become available on the file. Instead of that, the new value replaces the old one at the start of the file. I didn’t get inotify to notify me of changes either. A plain C file that I developed years ago for reading interrupts on the BeagleBone Black worked just fine on the GPIO pin of the Edison. I only had to change the path to the GPIO to pin 14, and then I got a message on the console as I applied ground and 3.3 volts to pin 14 on the SparkFun block.
The mraapackage provides a tool to list, set, get, and monitor GPIO pins. The two push buttons on the OLED screen block mentioned below are 47 and 32 and can be monitored as shown below.
Given the Linux kernel support, the microSD Block is one of the easiest things to use with the Edison (Figure 2).
Figure 2: MicroSD Block.
You might want to use a microSD card, for example, if you want to log data over time and do not want to run into limitations of using the main flash storage for logs.
The most time-consuming part of using the microSD Block was turning off the Edison and connecting the block into the stack. When I booted up and inserted a microSD card, it appeared in the dmesg output. From there I could mount and use the card using the same commands that are used on a desktop Linux machine.
# dmesg...[ 60.303228] mmc1: new high speed SDHC card at address 1234[ 60.304193] mmcblk1: mmc1:1234 SA04G 3.63 GiB [ 60.306139] mmcblk1: p1root@edison:~# ls -l /dev/disk/by-id...lrwxrwxrwx 1 root root 13 Feb 19 02:14 mmc-SA04G_0x3534550a -> ../../mmcblk1lrwxrwxrwx 1 root root 15 Feb 19 02:14 mmc-SA04G_0x3534550a-part1 -> ../../mmcblk1p1root@edison:~# mkdir /mnt/testroot@edison:~# mount /dev/mmcblk1p1 /mnt/testroot@edison:~# ls -l /mnt/test-rwxr-xr-x 1 root root 30 Feb 19 2017 df.txtroot@edison:~# cat /mnt/test/df.txtMon Feb 20 08:56:25 2017
Because the operating system runs entirely from the onboard flash inside the Edison, you don’t have to take the operating system into consideration when exchanging the microSD card on the Edison.
IMU Block
An Inertial Measurement Unit (IMU) is a system that records information about how something moves around. Depending on the IMU you can see how fast it is turning, if it is accelerating in a given direction and perhaps a compass heading, you know how things are rotated.
The sample code allows you to get up and running, seeing the rotation and acceleration of the block as you move it around. Compilation is fairly simple once you have the mraa development package installed.
The chip on the SparkFun IMU Block is a LSM9DS0 (Figure 3). There is another driver for this chip in the st_lsm9ds0 project. I tried to install the kernel-dev package on the Intel Edison but that process ran out of space. I assume this is because /boot was full. To try to get around that I downloaded the source ipk file and expanded the kernel to a subdirectory of the root user with the following commands.
As you can see this allows access to not only the kernel files but also the config file used to make that kernel.
edison:~/bak# wget http://iotdk.intel.com/repos/3.5/iotdk/edison/edison/kernel-dev_1.0-r2_edison.ipkedison:~/bak# ar x kernel-dev_1.0-r2_edison.ipk edison:~/bak# tar tzvf data.tar.gz edison:~/bak# cd ./bootedison:~/bak# cp config-3.10.98-poky-edison+ ../usr/src/kernel/edison:~/bak# cd ./usr/srcedison:~/bak/usr/src# ln -s `pwd`/kernel /usr/src/kernel
Unfortunately, after many attempts I did not manage to get the st_lsm9ds0 project to compile against the kernel-dev installation. I hope to cover module compilation in a future article, which covers setting up a Yocto compile environment on a desktop Linux machine to compile code including kernel modules for the Edison.
OLED Block
The SparkFun OLED block features a small 64×48 single color OLED screen (Figure 4). There is a small pong game as an example of using the screen that is quite cute.
Figure 4: SparkFun OLED Block.
Instead of using the lower level SPI or little screen library directly, it can be useful to have your application use Cairo as the rendering backbone and just ship the image off to the screen when needed. There are many advantages to doing this; the Cairo API is likely to be more widely known than the library for any specific screen, and you can change the screen out to something else without major changes to your program. Cairo also has access to great font rendering so you can browse free fonts such as those on Google Fonts and quickly start using them on your screen.
I’ll show how to do this from Node.js on the Edison. First, you’ll want to install a few modules including the interface to Cairo and the edison-oled node module as shown below.
There are a few abstractions to set up as shown below. The Edison and OLED objects drive the particular screen and shouldn’t be used directly by your application. After objects are declared, the screen is cleared so that there is no unexpected data displayed before the application does any explicit screen update.
The mydraw function is the core function where your application updates the screen to show what is going on. It is cairo only and doesn’t need to know anything about how to drive the OLED screen. In this case, I take advantage of the Edison to load and use an open font file to render the message “Linux!” at almost full screen.
var mydraw = function( cc, cb ) { var ctx = cc.getContext('2d'); var myfont = new Font('CaveatBrush', fontFile('CaveatBrush-Regular.ttf')); ctx.addFont(myfont); ctx.font = 'normal 32px CaveatBrush'; ctx.antialias = 0; ctx.fillStyle = '#000000' ctx.fillRect(0,0,canvas_width,canvas_height); if( forceBlackScreen ) {cb();return; } var msg = 'Linux!'; var te = ctx.measureText(msg); ctx.fillStyle = '#FFFFFF'; ctx.fillText(msg, 0, te.actualBoundingBoxAscent); cb();}
The screen update is done every 200ms in an idle function. This idle function uses the mydraw function above to actually populate the Cairo Canvas with something interesting. The data from the Cairo Canvas is then converted over to binary pixel data using the oled object and the physical screen is updated. Notice that the r, g, b, and alpha values are all available to this idle function, so if you update to a color OLED screen then you can start taking advantage of that by updating this idle function copy out loop. The SIGINT callback clears the OLED screen to prevent junk from being left on it if the application is closed.
setInterval( function() { canvasToPixels({width: canvas_width,height: canvas_height,js: mydraw, }, function receivePixels( err, pixels ) {oled.clear();var normalArray = Array.prototype.slice.call(pixels);var len = normalArray.length;var i = 0, x = 0, y = 0;for( i=0; i < len; i+=4 ) { var r = normalArray[i+0]; var g = normalArray[i+1]; var b = normalArray[i+2]; var a = normalArray[i+3]; if( r > 1 || g > 1 || b > 1 ) {oled.pixel( x, y ); } x++; if( x >= canvas_width ) {x = 0;y++; }}oled.display(); });}, 200 );process.on('SIGINT', function() { // clean off the screen. no junk left. oled.clear(); oled.display(); process.exit();});
Final Thoughts
The SparkFun blocks allow you to quickly snap together functionality and avoid having loose wires or making sure your connections do not accidentally put power to ground or other nasty things. There are pads on some Blocks to expose interrupts and configure the Block functionality by adding a dab of solder over some connections.
Open source projects are by their nature intended to be welcoming, pulling in contributions from many different volunteers. But in reality, open source and the tech industry in general often lack diversity. Speaking at the Open Source Leadership Summit in February, Mozilla’s Chief Innovation Officer Katharina Borchert told the crowd that working to bring ethnic, gender, and skill diversity to open source projects isn’t just the right thing to do because of moral grounds, it’s the right thing to do to make projects more successful.
“The next generation of people coming online and potentially willing — even eager — to engage with us, to contribute to our work, they’re not going to look like us, they’re not going to talk like us, and they’re going to have different expectations,” Borchert said.
“If we want to future-proof our communities, if we want to future-proof our work and everything that we really care about, we need to engage those people. We need to understand those people, and we need to be able to open up our communities and embrace those people,” she continued.
Several studies have outlined the benefits of bringing diverse viewpoints and backgrounds into an organization, and Borchert drew from a handful of those in her presentation. A study from McKinsey Research, for example, showed that across industry, gender diversity on a leadership team brough 15 percent higher financial returns than those without; those with ethnic diversity brought 35 percent higher returns.
Borchert also highlighted work from Karim Lakhani, a professor at Harvard Business School and a member of the Mozilla board of directors, who has dedicated his career to researching open innovation and Open Source communities.
“Open Source is really, really good at taking big problems and breaking them down into small tasks, which in turn allows a much larger pool of potential contributors to join,” Borchert said. “[Lakhani] has also identified some things that we’re not really good at. The main thing is we’re still not very good at avoiding group think and avoiding monocultures by bringing very different disciplines to the table. This is really, really important in the problem solving process.”
According to Borchert, open source projects tend to favor code over software and engineering over product. But, by excluding — whether consciously or not — contributors from other disciplines, projects are stunting their own growth potential.
“[Undervaluing non-coders] leads to undervaluing other roles that are also really important in the work that we do and that you need to have at the table if you do want to build really good products,” she said. “That’s researchers, UX designers, marketers, all the people that you do need if you really, really want to reach your customers. This actually has impact on our work.”
The solution is to deliberately design communities that are inclusive of people with varied backgrounds and skillsets. That doesn’t have to be a dreary exercise in forced cooperation, she said; the best results come from a fun, creative process that brings people on board and then retains them.
The key, she emphasized, is designing with specific inclusionary intentions in mind. “It is so hard to fix problems that have manifested overtime in established communities. We clearly need to do that, and we need to address the issues we have. We can avoid so much of the problems if we are very intentional about our values, our principles upfront.”
Borchert urged projects to publish their efforts and their findings and shine light on their mistakes as well as their successes, so that the community could start learning from each other. Such sharing of information, she said, is fundamental to success. “I have usually learned way more from the dramatic failures in my life than the great successes. It’s really important to share the lighthouses, to share the best practices, and to celebrate together.”
Learn how successful companies gain a business advantage with open source software in our online, self-paced Fundamentals of Professional Open Source Management course. Download a free sample chapter now!
At the same time that Docker offered to donate its containerd technology to the Cloud Native Computing Foundation (CNCF), CoreOS did the same with its competing rkt. Containerd (pronounced “container dee”) and rkt (say “rocket”) are both container runtime facilities, managing container images, a key component of cloud native computing.
Both can work for any number of container managers, but the CNCF is probably best known as the open forum overseeing the development of Kubernetes, the container manager that Google devised in 2014 and donated to the CNCF in 2015.
3 suggestions on how to stay simple and avoid complexity.
“You don’t understand — as soon as I install consul, set up service discovery for my microservices, build my own containerized continuous integration pipeline to build my code from source using my custom language-specific Dockerfile and set up my highly available production database my system for deploying code to production will be so simple.”
“How many people are in my team? Oh, it’s just me. But one day..”
Sigh ;-).
There’s a lot of complexity in things we use to reduce complexity. This is worth noticing. Three examples:
The HPC community is trying to solve the critical compute challenges of next generation high performance computing and ARM considers itself well-positioned to act as a catalyst in this regard. Applications like machine learning and scientific computing are driving demands for orders of magnitude improvements in capacity, capability and efficiency to achieve exascale computing for next generation deployments.
ARM has been taking a co-design approach with the ecosystem from silicon to system design to application development to provide innovative solutions that address this challenge.
This morning IBM announced the next logical step in its work with Docker containers: Kubernetes support on its Bluemix Container Service. Currently available in a limited beta, its feature set should match Google’s and Microsoft’s offerings.
Kubernetes, the Bluemix way
Previously, the default for managing Docker containers on Bluemix Container Service was to spin them up individually by hand or to use Bluemix’s container groups metaphor, where Bluemix directly managed multiple containers running the same image.
The Apache Camel community introduced a new release a few months ago with a set of components for building microservices. The new key component for microservices support is ServiceCall EIP, which allows calling a remote service in a distributed system where the service is looked up from a service registry on Kubernetes, Openshift, Cloud Foundry, Zuul, Consul, Zookeeper, etc. In addition, it is worth mentioning that now Apache Camel compiles against Java 8 and has improved support for Spring Boot. A full list of changes is available on Camel community site.
The main purpose of this article is to show how to create microservices with Apache Camel in the most common way using its new features available from release 2.18.
IT virtualization has radically changed the face of compute, storage, and network services in data centers and beyond. In response, Colt — a network and communications service provider — back in 2015 began developing a program that has transformed the way the company offers network services to customers, says Javier Benitez, Senior Network Architect, Colt Technology Services, who will be speaking at Open Networking Summit.
According to Benitez, the aim was to move away from a traditional consumption model to one where network services are consumed through an on-demand model based on software defined networking (SDN) and network function virtualization (NFV) technologies. Here, Benitez explains more about Colt’s SDN and NFV solutions, focusing on current development efforts and future plans.
Linux.com: What prompted Colt’s adoption of NFV and SDN?
Javier Benitez: Our transformation toward network virtualization started long ago, in 2010, when we defined Colt’s Ethernet and IP integration strategy which included the virtualization of the L3 CPE router used to deliver managed Internet access and IPVPN services. This virtualization was launched in production early 2012 and pre-dated the ETSI NFV group. The same year Colt joined the Open Networking Foundation (ONF) with special interest in the potential use of OpenFlow in the data center (DC) as well as in the transport network.
Javier Benitez, Senior Network Architect, Colt Technology Services
In a very organic way, we began to evaluate these new technologies whenever an area of the network needed to be replaced or evolved. This was the case with Colt data centers when in 2012 we evaluated a new architecture for the next generation switching infrastructure. OpenFlow technology and SDN overlay approaches were considered and, following a trial in one of our DCs in Paris, we deployed a Nicira SDN overlay solution in 2014. Around the same time, we also launched an RFI to evaluate NFV vendors capable of delivering virtual CPE solutions, and selected Versa Networks.
From 2014/2015, we started to observe a real interest and demand from customers, first to understand what the new technology was capable of, and second to request new services to be developed that would make use of SDN and NFV to solve some of their business requirements. Following several focused workshops with key Colt customers, we identified that their top priority was for a new on-demand consumption model, initially for basic Ethernet connectivity with the view to extend to other technology domains (e.g., IPVPN, Internet access, optical) in the future and up the stack to deliver added value services (e.g., virtualized firewall, DPI, application optimization, etc.) on demand on top of basic connectivity. This led to the creation of Colt’s Novitas program.
Linux.com: What is Novitas, and what role does it play within Colt?
Benitez: Novitas, branded Colt On Demand, is a company transformation programme created in 2015 with strong support from Colt’s executive team to completely change the way network services are offered and consumed by our customers. The vision is to move away from a traditional, slow, manual and paper-work based consumption model to one aligned with the IT/Cloud world where network services are consumed through an on-demand model, in real time, either through a web portal or API and based on the use of SDN and NFV technologies.
Novitas is having a profound impact internally, as it is transforming the entire organization. One of the most significant changes has been the need to adapt an agile development process as opposed to the traditional waterfall approach. The development framework is based on rapid development cycles, with a dynamic roadmap that is frequently updated based on both internal and customer feedback. At the same time, new product development processes, new operating models and new commercial models have been defined as new services and products are targeted by the On Demand roadmap.
Linux.com: Can you give us some examples of Colt’s development efforts? What issues are you currently focusing on?
Benitez: Based on the feedback received from our customers, our initial focus was delivering Ethernet On Demand. The value proposition gives customers a portal and/or an API so that they can reserve ports, create point to point Ethernet services, change the bandwidth of an existing service, and finally cease a service, all in real-time. And, all of that can happen across Colt’s Ethernet network deployed across more than 40 metro networks in Europe, to be expanded worldwide (US and Asia) in subsequent phases. The technical solution is based on Cyan (today Ciena) BluePlanet SDN controller controlling Colt’s Modular MSP, an integrated IP/Ethernet, multi-vendor packet network. We initially focused on a service proposition known as DCNet delivering the capability between key data centers in Europe, but it has now been extended and launched to cover any business on-net site, as well as Direct Cloud Access On Demand to Microsoft Azure as well as Amazon AWS.
The second development, also based on customers’ priorities, is the introduction of SD WAN as an evolution to the traditional MPLS IPVPN technology. Customers are interested in a new IPVPN proposition that would allow seamless support of multiple access technologies (MPLS, Internet), dynamic patch selection based on customer on demand configuration and value-added services activation. Another key development is Colt’s SD WAN proposition, based on Versa Networks and an initial NFV platform to virtualize some of the components (e.g., SD VPN-MPLS Gateway, SDN Controller).
At the moment, the Novitas Programme continues with both the Ethernet On Demand development as well as SD WAN, delivering features in a phased approach. At the same time, new products are being added into the roadmap, such as Internet Access On Demand.
Linux.com: What are some challenges you’ve encountered in deploying SDN & NFV solutions and how have you handled them?
Benitez: Probably the biggest challenge initially when trying to bring SDN/NFV services in production has been dealing with the integration to existing OSS and BSS systems. Those systems will obviously evolve and potentially be replaced as we progress the development, but in the initial phases we have to use the systems already in place, and that integration task has been quite important.
Another industry wide challenge is the lack of standards, or maybe even better these days, de facto standards of reference implementations. Some of the areas are quite new and there is still a lot of work and industry convergence that needs to happen. A clear example is NFV orchestration, where a number of open source initiatives as well as commercial solutions are trying to lead the way following the directions given by the ETSI NFV ISG. Standards are also missing when we try to interoperate SDN commercial vendors, as we initially see vendor-proprietary implementations, as well when it comes to interconnecting service providers to extend SDN/NFV services beyond a single operator’s domain. Colt is trying to address this last challenge by actively collaborating in industry forums and engaging with other operators.
Another challenge is product maturity and performance. Unfortunately, here there is no other alternative than testing, testing, and feeding back to vendors to work together in improving the initial products.
Linux.com: What development areas would you like to address in the future?
Benitez: There are three research areas that we are working on at the moment in the context of the Novitas program:
1. Target NFV Platform: Further to the initial deployment of an NFV platform to support the SD WAN development, plus other individual network virtualization needs, we are now evaluating a complete, unified, and distributed NFV platform across Colt including NFV Infrastructure and MANO.
2. Standard SDN/NFV API: Colt is fully committed to help the industry agree on standard APIs that can be used to extend SDN and NFV services across different service providers. We are currently engaged in a collaboration with MEF, TM Forum, and other service providers like AT&T and Orange to deliver an initial set of standard APIS for Ethernet On Demand. This initiative uses MEF’s LSO (Lifecycle Service Orchestration) framework and TM Forum’s Open API framework
3. Optical SDN: We have started to research Optical SDN technologies that could extend Colt’s on demand offering to our optical portfolio. The main objective here is to explore SDN for the Optical layer to enable a fully disaggregated, software-controllable optical transport network, both at the Photonic/WDM layer as well as OTN.
Open Networking Summit April 3-6 in Santa Clara, CA features over 75 sessions, workshops, and free training! Get in-depth training on up-and-coming technologies including AR/VR/IoT, orchestration, containers, and more.
Linux.com readers can register now with code LINUXRD5 for 5% off the attendee registration. Register now!