There is a number of possible improvements to the architecture of SUSE Manager / Salt integration that should be investigated in order to improve the reliability and scalability of the backend: 1. Actions are currently scheduled in the minions using the schedule module of Salt. This brings problems with reliability as for instance a minion can be down at the specified schedule time which leads to actions not being executed. Scalability can be an issue as actions being scheduled for many minions might return results to the server at the same time. Instead it might be better to keep control over scheduled actions on the server to allow batching of actions as well as downtimes of minions or even the server. There is a work in progress branch to get started.

Ever left a restaurant wanting to write a review, but thinking it wasn't worth the trouble to tap out all those words on your phone -- you just want to give the place your n stars and provide a few words of praise or condemnation? If only you could press a button to generate a plausible review. If this project happens, you will. We'll use the Yelp API to grab as many reviews of certain types of restaurants as the terms of service allow (I assume "Use any robot, spider, site search/retrieval application, or other automated device, process or means to access, retrieve, scrape, or index any portion of the Site or any Site Content;" doesn't apply to API users -- otherwise it wouldn't be much of an API).

oscar is short for osc sugar, it will be a collection of little wrapper scripts on top of the openSUSE build service command-line tool that make it easier to use.

Overview

OpenFaaS - Functions as a Service Get familiar with one of the hottest topics for this year: https://www.openfaas.com/

Problem statement

Right now, we have different resources to pool videos. The goal of is to consolidate all video resources into a central place to make them easily searchable, and enable a youtube like experience, rather than a simple file list.

We have a known defect exists in Staging Project process, according to the staging project design(in-ring/non-ring), the requests of a application stack can be dispatched to letter staging and adi staging both, in case the request staged in adi staging relies the request staged in letter staging which may causes sometimes the request in adi staging will not be checked-in at the same round, this leads that application stack have different version in TW and those package had request left in adi staging may does not work well as version unmatched to other library. We see this issue happened on Qt5 stack; KDE Applications, etc. For example: a Qt5 stack update, libqt5-qtbase will be staged in a letter staging however libqt5-qtwebview will be staged in a adi staging, once libqt5-qtbase be accepted that libqt5-qtwebview won't be accept in the same round due to it can not be built before libqt5-qtbase merged to Factory but after - 2-phase update. Therefore we need a way to handle those cases to reduce the gap between Letter staging and ADI staging. The concept of this idea:

• Setup Tensorflow on OpenSUSE 42.3
• Look for a way to package it

Running openATTIC and DeepSea on Multiple Distributions