Kategorie: technology

OpenShift for Operators Lab: Sneak Preview!

Back by popular demand, the OpenShift for Operators lab session is coming to Red Hat Summit with fresh new content for 2017! We get a full house every year, so if you want in, you need to get registered today. Read on to learn more about Red Hat Summit’s great lab sessions, and in particular, OpenShift for Operators.
Quelle: OpenShift

Cloud Therapy helps doctors better understand and diagnose rare diseases

For patients who have a rare disease, it can take a long time to get an accurate diagnosis. Some conditions have doctors working months or even years to try to make sense of symptoms and test results. Patients cannot afford to forgo treatment while doctors try to discern clues about their conditions. For many, there’s no time to waste, yet it can take five months to a year or more to reach a diagnosis.
Cloud Therapy was founded to help doctors distill diagnostic insights from enormous amounts of medical literature and research. The solution uses natural language processing (NLP), probabilistic reasoning and deep learning to analyze terabytes of unstructured data to assist doctors recognize rare conditions quickly and accurately.
If the solution can help medical professionals access information faster, it can mean the difference between life and death for someone with a rare disease.
A concept imagined
The predecessor to Cloud Therapy was a simple iPad app that contained information for patients to review before the doctor entered the consult room.
Throughout the day, a doctor may lose five minutes with one patient and six minutes with another while repeatedly answering the same questions. Going over the allotted time could eat up three hours, and the doctor would have to put in extra time to finish daily work. The app helped cut three down to about an hour and a half.
Around that time, IBM Watson debuted on Jeopardy!, and soon after, the technology became available for developers. This is when work began on the Cloud Therapy solution.
Cloud Therapy evolves
When the full range of Watson application programming interfaces (APIs) became available on the IBM Bluemix platform, Cloud Therapy took off.
Developing with Bluemix gives Cloud Therapy a competitive advantage because it can incorporate different services and data sources without spending time to develop custom integration logic. The company began experimenting with big data analytics and cognitive computing services. The team realized they had a noteworthy idea when the Global Mobile Innovators Tournament, enabled by IBM, chose Cloud Therapy as a finalist. The company’s prototype idea was later shared at the “4 Years From Now” (4YFN) conference in Barcelona, Spain.
Since then, the product has evolved, incorporating IBM Watson Conversation, Dialog, Natural Language Classifier, Retrieve and Rank, Speech to Text and Text to Speech services along with the IBM Cloudant noSQL database, IBM Mobile Push Notification and IBM Mobile Quality Assurance services.
Cloud Therapy relies on Cloudant because the company wants people to have the best possible experience with no lag. Delivering the solution in seconds is what makes Cloud Therapy what it is.
With IBM Bluemix Mobile Services, the Cloud Therapy solution supports mobile app capabilities, including the ability for users to offer immediate feedback within the app. It also uses Google Translate to accommodate English and Spanish language content.
Far more than a search engine
Many might wonder if they could use a regular search engine to understand the relationships of the question the way Watson does. With a search engine, people must cross your fingers that whatever results they get will be meaningful. The Cloud Therapy solution uses Watson’s brain to understand relationships and actually learn.
For each customer implementation, Cloud Therapy cleans, curates and uploads data, including clinical trials, drug research, previous case information, and genotype and phenotype patterns. The data can be both structured and unstructured. Initially, the company creates question-and-answer pairs to train the algorithms. The training process involves providing feedback to the system as it matches appropriate answers to questions. This requires input from both subject matter experts and data scientists.
After learning from the data set, the cognitive engine uses NLP to understand queries and then applies textual analysis and probabilistic reasoning to return appropriate content, ranked by confidence level. The platform can process 1.3 terabytes of data per second.
The solution also learns from user feedback. Doctors can converse with the system in natural language, and it helps provide clues to a patient’s condition.
Faster, more accurate diagnoses
For several pilot implementations, each Cloud Therapy customer brings its own data and desired use case. For one project, a customer will provide 13 years of data on 9,000 rare disease cases that doctors will want to query.
Cloud Therapy tells all its customers that this is experimental technology and they should understand that, especially because expectations in the cognitive era are enormously high. The company tries to help everyone recognize that the technology is brand new, and so far, so good.
Cloud Therapy sees the value, and its partners see the value. Understanding patient symptoms for a faster, more accurate diagnosis can be a matter of life and death.
Read more about Cloud Therapy.
The post Cloud Therapy helps doctors better understand and diagnose rare diseases appeared first on #Cloud computing news.
Quelle: Thoughts on Cloud

Steve Hardy: OpenStack TripleO in Ocata, from the OpenStack PTG in Atlanta

Steve Hardy talks about TripleO in the Ocata release, at the Openstack PTG in Atlanta.

Steve: My name is Steve Hardy. I work primarily on the TripleO project, which is an OpenStack deployment project. What makes TripleO interesting is that it uses OpenStack components primarily in order to deploy a production OpenStack cloud. It uses OpenStack Ironic to do bare metal provisioning. It uses Heat orchestration in order to drive the configuration workflow. And we also recently started using Mistral, which is an OpenStack workflow component.

So it’s kind of different from some of the other deployment initiatives. And it’s a nice feedback loop where we’re making use of the OpenStack services in the deployment story, as well as in the deployed cloud.

This last couple of cycles we’ve been working towards more composability. That basically means allowing operators more flexibility with service placement, and also allowing them to define groups of node in a more flexible way so that you could either specify different configurations – perhaps you have multiple types of hardware for different compute configurations for Nova, or perhaps you want to scale services into particular groups of clusters for particular services.

It’s basically about giving more choice and flexibility into how they deploy their architecture.

Rich: Upgrades have long been a pain point. I understand there’s some improvement in this cycle there as well?

Steve: Yes. Having delivered composable services and composable roles for the Newton OpenStack release, the next big challenge was giving operators the flexibility to deploy services on arbitrary nodes in your OpenStack environment, you need some way to upgrade, and you can’t necessarily make assumptions about which service is running on which group of nodes. So we’ve implented the new feature which is called composable upgrades. That uses some Heat functionality combined with Ansible tasks, in order to allow very flexible dynamic definition of what upgrade actions need to take place when you’re upgrading some specific group of nodes within your environment. That’s part of the new Ocata release. It’s hopefully going to provide a better upgrade experience, for end-to-end upgrades of all the OpenStack services that TripleO supports.

Rich: It was a very short cycle. Did you get done what you wanted to get done, or are things pushed off to Pike now.

Steve: I think there’s a few remaining improvements around operator-driven upgrades, which we’ll be looking at during the Pike cycle. It certainly has been a bit of a challenge with the short development timeframe during Ocata. But the architecture has landed, and we’ve got composable upgrade support for all the services in Heat upstream, so I feel like we’ve done what we set out to do in this cycle, and there will be further improvements around operator-drive upgrade workflow and also containerization during the Pike timeframe.

Rich: This week we’re at the PTG. Have you already had your team meetings, or are they still to come.

Steve: The TripleO team meetings start tomorrow, which is Wednesday. The previous two days have mostly been cross-project discussion. Some of which related to collaborations which may impact TripleO features, some of which was very interesting. But the TripleO schedule starts tomorrow – Wednesday and Thursday. We’ve got a fairly packed agenda, which is going to focus around – primarily the next steps for upgrades, containerization, and ways that we can potentially collaborate more closely with some of the other deployment projects within the OpenStack community.

Rich: Is Kolla something that TripleO uses to deploy, or is that completely unrelated?

Steve: The two projects are collaborating. Kolla provides a number of components, one of which is container definitions for the OpenStack services themselves, and the containerized TripleO architecture actually consumes those. There are some other pieces which are different between the two projects. We use Heat to orchestrate container deployment, and there’s an emphasis on Ansible and Kubernetes on the Kolla side, where we’re having discussions around future collaboration.

There’s a session planned on our agenda for a meeting between the Kolla Kubernetes folks and TripleO folks to figure out of there’s long-term collaboration there. But at the moment there’s good collaboration around the container definitions and we just orchestrate deploying those containers.

We’ll see what happens in the next couple of days of sessions, and getting on with the work we have planned for Pike.

Rich: Thank you very much.
Quelle: RDO

ASP.NET on OpenShift Part 3: Running your ASP.NET Code on OpenShift

In this part, we’re going to get your ASP.NET application (as created in Part 1 and Part 2) up and running on OpenShift. If you are new to OpenShift, here is an explanation of how it uses Containers and Kubernetes to build a platform for your to run your application.
Quelle: OpenShift

Using a standalone Nodepool service to manage cloud instances

Nodepool is a
service used by the OpenStack CI team to deploy and manage a pool of
devstack
images on a cloud server for use in OpenStack project testing.

This article presents how to use Nodepool to manage cloud instances.

Requirements

For the purpose of this demonstration, we’ll use a CentOS system and the
Software Factory
distribution to get all the requirements:

sudo yum install -y –nogpgcheck https://softwarefactory-project.io/repos/sf-release-2.5.rpm
sudo yum install -y nodepoold nodepool-builder gearmand
sudo -u nodepool ssh-keygen -N ” -f /var/lib/nodepool/.ssh/id_rsa

Note that this installs nodepool version 0.4.0, which relies on Gearman and
still supports snapshot based images. More recent versions of Nodepool require
a Zookeeper service and only support diskimage builder images. Even though the
usage is similar and easy to adapt.

Configuration

Configure a cloud provider

Nodepool uses os-client-config to define cloud providers and it needs
a clouds.yaml file like this:

cat > /var/lib/nodepool/.config/openstack/clouds.yaml <<EOF
clouds:
le-cloud:
auth:
username: “${OS_USERNAME}”
password: “${OS_PASSWORD}”
auth_url: “${OS_AUTH_URL}”
project_name: “${OS_PROJECT_NAME}”
regions:
– “${OS_REGION_NAME}”
EOF

Using the OpenStack client, we can verify that the configuration is correct
and get the available network names:

sudo -u nodepool env OS_CLOUD=le-cloud openstack network list

Diskimage builder elements

Nodepool uses disk-image-builder
to create images locally so that the exact same image can be used across
multiple clouds. For this demonstration we’ll use a minimal element to
setup basic ssh access:

mkdir -p /etc/nodepool/elements/nodepool-minimal/{extra-data.d,install.d}

In extra-data.d, scripts are executed outside of the image and the one bellow
is used to authorize ssh access:

cat > /etc/nodepool/elements/nodepool-minimal/extra-data.d/01-user-key <<‘EOF’
#!/bin/sh
set -ex
cat /var/lib/nodepool/.ssh/id_rsa.pub > $TMP_HOOKS_PATH/id_rsa.pub
EOF
chmod +x /etc/nodepool/elements/nodepool-minimal/extra-data.d/01-user-key

In install.d, scripts are executed inside the image and the following
is used to create a user and install the authorized_key file:

cat > /etc/nodepool/elements/nodepool-minimal/install.d/50-jenkins <<‘EOF’
#!/bin/sh
set -ex
useradd -m -d /home/jenkins jenkins
mkdir /home/jenkins/.ssh
mv /tmp/in_target.d/id_rsa.pub /home/jenkins/.ssh/authorized_keys
chown -R jenkins:jenkins /home/jenkins

# Nodepool expects this dir to exist when it boots slaves.
mkdir /etc/nodepool
chmod 0777 /etc/nodepool
EOF
chmod +x /etc/nodepool/elements/nodepool-minimal/install.d/50-jenkins

Note: all the examples in this articles are available in this repository:
sf-elements.
More information to create elements is available here.

Nodepool configuration

Nodepool main configuration is /etc/nodepool/nodepool.yaml:

elements-dir: /etc/nodepool/elements
images-dir: /var/lib/nodepool/dib

cron:
cleanup: ‘*/30 * * * *’
check: ‘*/15 * * * *’

targets:
– name: default

gearman-servers:
– host: localhost

diskimages:
– name: dib-centos-7
elements:
– centos-minimal
– vm
– dhcp-all-interfaces
– growroot
– openssh-server
– nodepool-minimal

providers:
– name: default
cloud: le-cloud
images:
– name: centos-7
diskimage: dib-centos-7
username: jenkins
private-key: /var/lib/nodepool/.ssh/id_rsa
min-ram: 2048
networks:
– name: defaultnet
max-servers: 10
boot-timeout: 120
clean-floating-ips: true
image-type: raw
pool: nova
rate: 10.0

labels:
– name: centos-7
image: centos-7
min-ready: 1
providers:
– name: default

Nodepool uses a gearman server to get node requests and to dispatch
image rebuild jobs. We’ll uses a local gearmand server on localhost.
Thus, Nodepool will only respect the min-ready value and it won’t
dynamically start node.

Diskimages define images’ names and dib elements. All the elements
provided by dib, such as centos-minimal, are available, here is the
full list.

Providers define specific cloud provider settings such as the network name or
boot timeout. Lastly, labels define generic names for cloud images
to be used by jobs definition.

To sum up, labels reference images in providers that are constructed
with disk-image-builder.

Create the first node

Start the services:

sudo systemctl start gearmand nodepool nodepool-builder

Nodepool will automatically initiate the image build, as shown in
/var/log/nodepool/nodepool.log: WARNING nodepool.NodePool: Missing disk image centos-7.
Image building logs are available in /var/log/nodepool/builder-image.log.

Check the building process:

# nodepool dib-image-list
+—-+————–+———————————————–+————+———-+————-+
| ID | Image | Filename | Version | State | Age |
+—-+————–+———————————————–+————+———-+————-+
| 1 | dib-centos-7 | /var/lib/nodepool/dib/dib-centos-7-1490688700 | 1490702806 | building | 00:00:00:05 |
+—-+————–+———————————————–+————+———-+————-+

Once the dib image is ready, nodepool will upload the image:
nodepool.NodePool: Missing image centos-7 on default
When the image fails to build, nodepool will try again indefinitely,
look for “after-error” in builder-image.log.

Check the upload process:

# nodepool image-list
+—-+———-+———-+———-+————+———-+———–+———-+————-+
| ID | Provider | Image | Hostname | Version | Image ID | Server ID | State | Age |
+—-+———-+———-+———-+————+———-+———–+———-+————-+
| 1 | default | centos-7 | centos-7 | 1490703207 | None | None | building | 00:00:00:43 |
+—-+———-+———-+———-+————+———-+———–+———-+————-+

Once the image is ready, nodepool will create an instance
nodepool.NodePool: Need to launch 1 centos-7 nodes for default on default:

# nodepool list
+—-+———-+——+———-+———+———+——————–+——————–+———–+——+———-+————-+
| ID | Provider | AZ | Label | Target | Manager | Hostname | NodeName | Server ID | IP | State | Age |
+—-+———-+——+———-+———+———+——————–+——————–+———–+——+———-+————-+
| 1 | default | None | centos-7 | default | None | centos-7-default-1 | centos-7-default-1 | XXX | None | building | 00:00:01:37 |
+—-+———-+——+———-+———+———+——————–+——————–+———–+——+———-+————-+

Once the node is ready, you have completed the first part of the process
described in this article and the Nodepool service should be working properly.
If the node goes directly from the building to the delete state, Nodepool will
try to recreate the node indefinitely. Look for errors in nodepool.log.
One common mistake is to have an incorrect provider network configuration,
you need to set a valid network name in nodepool.yaml.

Nodepool operations

Here is a summary of the most common operations:

Force the rebuild of an image: nodepool image-build image-name
Force the upload of an image: nodepool image-upload provider-name image-name
Delete a node: nodepool delete node-id
Delete a local dib image: nodepool dib-image-delete image-id
Delete a glance image: nodepool image-delete image-id

Nodepool “check” cron periodically verifies that nodes are available.
When a node is shutdown, it will automatically recreate it.

Ready to use application deployment with Nodepool

As a Cloud developper, it is convenient to always have access to a fresh
OpenStack deployment for testing purpose. It’s easy to break things and it
takes time to recreate a test environment, so let’s use Nodepool.

First we’ll add a new elements
to pre-install the typical rdo requirements:

diskimages:
– name: dib-rdo-newton
elements:
– centos-minimal
– nodepool-minimal
– rdo-requirements
env-vars:
RDO_RELEASE: “ocata”

providers:
– name: default
images:
– name: rdo-newton
diskimage: dib-rdo-newton
username: jenkins
min-ram: 8192
private-key: /var/lib/nodepool/.ssh/id_rsa
ready-script: run_packstack.sh

Then using a ready-script,
we can execute packstack to deploy services after the node has been created:

label:
– name: rdo-ocata
image: rdo-ocata
min-ready: 1
ready-script: run_packstack.sh
providers:
– name: default

Once the node is ready, use nodepool list to get the IP address:

# ssh -i /var/lib/nodepool/.ssh/id_rsa jenkins@node
jenkins$ . keystonerc_admin
jenkins (keystone_admin)$ openstack catalog list
+———–+———–+——————————-+
| Name | Type | Endpoints |
+———–+———–+——————————-+
| keystone | identity | RegionOne |
| | | public: http://node:5000/v3 |
…

To get a new instance, either terminate the current one, or manually delete it
using nodepool delete node-id.
A few minutes later you will have a fresh and pristine environment!
Quelle: RDO