Re: [ovirt-devel] oVirt's MoM feature list ?
by Adam Litke
On 13/06/14 11:52 +0000, Vinod, Chegu wrote:
>Cc'ng Gilad
>Vinod
>
>From: Vinod, Chegu
>Sent: Friday, June 13, 2014 4:45 AM
>To: alitke(a)redhat.com
>Subject: oVirt's MoM feature list ?
>
>Hi Adam,
>
>Where can I find some information about the future features/enhancements that are planned in MoM ? Perhaps it was discussed already in some email group or in some presentation...If yes can you please point me to the same ?
This is a great question for the devel list (added to cc:). I think
Doron and Martin (added to cc:) will be able to give some better
responses to this as well.
--
Adam Litke
10 years, 5 months
Gerrit planned downtime
by David Caro
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi!
In 15 minutes I'll start updating the gerrit machine, it will take some t=
ime and
I'll have to reboot it after, that should be the only planned downtime, b=
ut if
you might have some slowness and maybe even connection failures when
updating/rebooting, I'll send an update once finished.
Cheers!
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJToIMpAAoJEEBxx+HSYmnDpqkH/02c2SOoqc18ymenAx9rZsF1
oAkJRcty1GxE3OgsdqdzVWJP6IN4hR0DxOBmWGOBA6SlyL0gnJcPMRE7sYXcB/4j
FQBFNauytwfWEkfI2rcmBWGT91l2uzZntkEKlE+hkf9UEG4VZm7omwVqvg/wwLPt
Z0+U3oqADJUorMTQmSiRfm1tOfp2WmMbamREyTOQHxPgzTkDtd+ElnNLMpR8rQZ+
eCip16/LQ7PBTihJu2346bS/oI/zVAZcvjTkWT677JHgG/tyHETjRLfIsWAftbdD
L+MgDxXe6iFoYpEbUnAwid81xW03YR+kRXyHv+IQqgpDt09qdg6UdPcLB2Pu1n8=
=da5c
-----END PGP SIGNATURE-----
--0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB--
10 years, 5 months
oVirt.js - source control & distribution
by Vojtech Szocs
Hello,
I'd like to share my ideas on how to manage oVirt.js source code and
distribution for consumer applications. Please let me know what you
think, nothing is set in stone :)
1, Idea: separate git repo for oVirt.js, example: "ovirt-engine-sdk-js"
- using Node/Grunt for building oVirt.js distributable package
- development build: ovirt.js
- production build: ovirt.min.js
- source maps for production build: ovirt.min.js.map
- not sure we really need platform (make/RPM) build here, since
WebAdmin & UserPortal are planned to have oVirt.js injected
right into their output (GWT-generated) JavaScript code (no
need to fetch it at runtime)
2, Idea: contain GWT/Java overlay for oVirt.js in "ovirt-engine" repo
- overlay = Java facade to oVirt.js which uses JSNI [1] to delegate
calls to underlying JavaScript (oVirt.js) code
- for now, WebAdmin & UserPortal are the only GWT applications
intended to consume oVirt.js, we can extract the overlay into
different repo later if needed
3, Idea: distribute oVirt.js via Bower [2] for common audience
- just like any other JavaScript library is distributed
- this is similar to oVirt _Java_ SDK distributed via Maven Central
(in that case, common audience = Java developers using Maven)
4, Idea: integrate oVirt.js into Engine Maven build as dependency
- building oVirt.js would (also) produce ovirt-js-<version>.jar
- GWT/Java overlay project (essentially GWT module) would depend
on ovirt-js-<version>.jar, including its content into overlay's
output JAR
- WebAdmin & UserPortal would consume ovirt-js-gwt-<version>.jar
(GWT overlay) as GWT module in their <moduleName>.gwt.xml files
[1] http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html
[2] http://bower.io/
Regards,
Vojtech
10 years, 5 months
oVirt.js - API & implementation design summary
by Vojtech Szocs
Hello,
this is a follow-up to my oVirt.js announcement email, I'd like to give
you a quick summary of API & implementation design. In other words, I'll
try to describe key decisions in oVirt.js API & implementation.
1, General design
We're trying to follow best practices in JavaScript development, such as:
- containing the whole SDK in a single global variable (because until ES6
we cannot truly avoid global variables) and using IIFE/closure for better
information hiding
- using ES5 "use strict" (Strict Mode) on function level (so that Strict
Mode compliant environments will detect problems early) while not relying
on semantical differences introduced by Strict Mode (main reason = IE9)
2, API design
As presented in earlier "oVirt JavaScript SDK: Design Proposal" session,
our main goals here are API usability and readability. (If you missed
this session before, let me know and I'll forward you the slides.)
- using fluent interface concept, for example:
ovirt.api.datacenters.list().success(dcsListedCallback).run();
- separating the concept of resource (collection) vs. operation
(operation = reusable RESTful method abstraction)
- separating three logical namespaces:
* ovirt.svc -- services used by API implementation
Each service should be an object containing reusable methods.
1. existing services can be overridden to achieve SDK portability
for given runtime environment.
2. existing services can be used and new services can be added by
SDK extensions or clients.
* ovirt.util -- utilities used by API implementation
Unlike services, utilities are meant to assist with writing more
efficient JavaScript code.
* ovirt.api -- API as the main entry point to SDK functionality
3, Implementation design
I've tried to catch up with my JavaScript knowledge recently, but I'm
not an expert, I'm still learning things. Following are ideas which I
took into practice within oVirt.js API implementation:
- creating objects via mixins, each mixin is a function which gets some
object ("that") and adds new properties to that object (augmentation)
- simple dependency injection mechanism for mixins, with dependencies
resolved against "ovirt.svc" namespace, for example:
// Create new object, "spec" = information needed for object creation.
function makeSomeObject (spec) {
return mixins.mix(spec,
[mixinOne, mixinTwo], // array of mixin functions
['depNameOne', 'depNameTwo'] // array of dependency names
);
}
// "that" = object to augment.
// "spec" = information provided for object creation.
// "my" = object containing shared secrets, for more details see [1]
function mixinOne (that, spec, my) {
// Augment "that" with "quack" method, utilize closure to capture
// "spec.name" without exposing it to users of "that" object.
that.quack = function () { console.log(spec.name + ' says quack!');
// Consume "depNameOne" service, resolved from ovirt.svc namespace
that.doSomething = function () { my.depNameOne.whatever(); }
}
[1] JavaScript: The Good Parts (2008) by Douglas Crockford,
chapter "Inheritance", section "Functional" - explanation
of "my" object within functional constructor pattern
We are NOT using "new" operator in JavaScript. We are also NOT relying
on object's prototype chain. We are simply creating useful objects via
mixins, which is in my opinion the most simple and flexible way.
Regards,
Vojtech
10 years, 5 months
oVirt Node Weekly Meeting Minutes -- 2014-06-17
by Fabian Deutsch
Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.txt
Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.log.html
=================================
#ovirt: oVirt Node Weekly Meeting
=================================
Meeting started by fabiand at 13:01:20 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.log.html
.
Meeting summary
---------------
* Agenda (fabiand, 13:01:36)
* Build Status (3.0.5) (fabiand, 13:01:55)
* Feature Status (3.5) (fabiand, 13:02:01)
* Feature Status (ovirt-node-3.1) (fabiand, 13:02:13)
* Other Items (fabiand, 13:02:17)
* Action Item Review (fabiand, 13:03:35)
* LINK:
http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-06-10-13.01.txt
(fabiand, 13:04:05)
* fabiand to finish OVA builds and push (fabiand, 13:04:47)
* ovirt-appliance is pushed (sources) (fabiand, 13:05:27)
* LINK: http://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git
(fabiand, 13:06:02)
* LINK:
http://dummdida.tumblr.com/post/88944206100/say-hello-to-the-ovirt-engine...
(fabiand, 13:07:35)
* announced on devel(a)ovirt.org (fabiand, 13:07:44)
* rbarry about to post the email (fabiand, 13:10:45)
* fabiand did not yet build images for 3.4.2 and 3.5 b/c of a failing
tool (fabiand, 13:11:41)
* Build Status (3.0.5) (fabiand, 13:12:14)
* 3.0.5 is ready, just needs to be published with 3.5 packages
(fabiand, 13:12:30)
* Feature Status (3.5) (fabiand, 13:12:56)
* hosted-engine-plugin -- Merged awaits testing (fabiand, 13:13:09)
* generic-registration -- Merged and needs testing, not enabled by
default (fabiand, 13:15:08)
* generic registration needs more discussion, which will hopefully
take place on the devel@ ml (fabiand, 13:17:01)
* Engine part of generic registration is merged. (fabiand, 13:18:09)
* rbarry to also discuss how the migratoin to the genric-registration
can take place (in the TUI, and AI) (fabiand, 13:26:21)
* ovirt-appliance -- Pushed to gerrit and announced (fabiand,
13:26:46)
* needs testing (fabiand, 13:26:49)
* Feature Status (ovirt-node-3.1) (fabiand, 13:27:57)
* Considering to release ovirt-node-3.1 with all 3.5 features plus
some additional before 3.5 TestDays (fabiand, 13:29:59)
* ACTION: Node team to review and merge pending patches (as long as
the patch is in a good shape) (fabiand, 13:31:19)
* Other Items (fabiand, 13:31:33)
* Some patches in gerrit are pending and -1'ed - because they
basically go into the blivet direction, but we also consider
anaconda, they are on hold (fabiand, 13:33:33)
Meeting ended at 13:34:56 UTC.
Action Items
------------
* Node team to review and merge pending patches (as long as the patch is
in a good shape)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Node team to review and merge pending patches (as long as the patch
is in a good shape)
People Present (lines said)
---------------------------
* fabiand (125)
* rbarry (21)
* bkp (12)
* ovirtbot (5)
* doron (3)
* doron_afk (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 5 months
[oVirt 3.5 Localization Question #1] "Permissive"
by Yuko Katabami
This is a multi-part message in MIME format.
--------------000200000508080200080403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello all,
I am a Brisbane-based translator working on oVirt 3.5 localization
project along with 5 other translators, each specialized in a different
locale.
Our localization cycle is just kicked off and I would like to post our
questions to this mailing list, just as I did for 3.4.
It would be greatly appreciated if you could help us by answering
questions, so that we can ensure accuracy of our translations, based on
the context.
Here is our first question.
*File:***LocalizedEnums*
**Resource ID:*** SELinuxMode___PERMISSIVE*
**Strings:*** Permissive
*Question:* Could someone explain to us how this appears in the Admin
Portal? (we currently do not have a demo environment and cannot check it
on the screen). Translators usually leave SELinux modes untranslated as
they appear in the command line in English, however this string starts
with the uppercase letter "P". We just wonder if this is used as
descriptive or it refers exactly the "permissive" mode as shown in the
terminal.
Kind regards,
Yuko Katabami
--------------000200000508080200080403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello all, <br>
<div class="moz-signature"> <br>
I am a Brisbane-based translator working on oVirt 3.5 localization
project along with 5 other translators, each specialized in a
different locale.<br>
Our localization cycle is just kicked off and I would like to post
our questions to this mailing list, just as I did for 3.4.<br>
It would be greatly appreciated if you could help us by answering
questions, so that we can ensure accuracy of our translations,
based on the context.<br>
<br>
Here is our first question.<br>
<br>
<b>File:</b><b> </b>LocalizedEnums<b><br>
</b><b>Resource ID:</b><b> </b>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
SELinuxMode___PERMISSIVE<b><br>
</b><b>Strings:</b><b> </b>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Permissive<br>
<b>Question:</b> Could someone explain to us how this appears in
the Admin Portal? (we currently do not have a demo environment and
cannot check it on the screen). Translators usually leave SELinux
modes untranslated as they appear in the command line in English,
however this string starts with the uppercase letter "P". We just
wonder if this is used as descriptive or it refers exactly the
"permissive" mode as shown in the terminal.<br>
<br>
Kind regards,<br>
<br>
Yuko Katabami<br>
</div>
</body>
</html>
--------------000200000508080200080403--
10 years, 5 months
Announcing oVirt.js prototype
by Vojtech Szocs
------=_Part_23610907_1521630269.1403011303574
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hello everyone,
in past few weeks, we've been working on JavaScript SDK for oVirt Engine.
Today, I'm happy to announce the first prototype called oVirt.js :)
Attached, there's an "sdk-testdrive" UI plugin which:
- bundles oVirt.js prototype [ovirt.js]
- contains test code for DataCenter object [plugin.js]
To install this plugin, simply copy (or symlink) sdk-testdrive.json file and
sdk-testdrive-resources directory under /usr/share/ovirt-engine/ui-plugins.
Following is a quick recap of test code exercising oVirt.js.
To add new DataCenter:
// Obtain DataCenter resource collection.
// Resource collection is a handle to work with RESTful objects.
var dcColl = ovirt.api.datacenters;
// Obtain "add DataCenter" operation.
// Operation is a reusable, uhm, operation, backed by HTTP request.
// You can run the same operation multiple times, if necessary.
var addOp = dcColl.add({ name: 'test-dc', local: false });
// Register result handler and run the operation.
addOp.success(dcAddedCallback).run();
// Example of operation result handler that receives a single resource.
function dcAddedCallback (dc) {
console.log('Added: ' + dc.data().name);
}
In dcAddedCallback function shown above, "dc" is a resource object,
representing a handle to work with RESTful DataCenter object. It provides
access to underlying resource data:
var dcDataObj = dc.data();
// Get
var dcName = dcDataObj.name;
var dcDesc = dcDataObj.description;
// Set multiple properties at once ...
dc.data({ name: 'test-dc-updated', description: 'test' });
// ... or one by one
dcDataObj.name = 'test-dc-updated';
dcDataObj.description = 'test';
It also gives access to nested collections (if any) and supported
actions (if any):
// Obtain Cluster resource collection for given DataCenter.
var dcClusterColl = dc.clusters;
oVirt.js is currently only 445 lines of code, yey :) we're not using
any code generation at this point, we're simply relying on HATEOAS [1]
principle of REST and dynamically augmenting resource objects with
nested collections and supported actions, which are part of resource
representation.
[1] http://en.wikipedia.org/wiki/HATEOAS
I feel we'll eventually come to a point where code generation can be
useful, but for now, we're trying to keep things small and simple.
oVirt.js currently uses Lo-Dash library [2] containing various utility
functions. I think that Lo-Dash is great because it makes working with
JavaScript a bit easier.
[2] http://lodash.com/
Overall, oVirt.js will be self-contained, which means there will be
no additional dependencies from JavaScript perspective. Using oVirt.js
in HTML page will be as simple as this:
<script src="ovirt.js"></script>
This means that (build-time) dependencies such as Lo-Dash will be
inlined into resulting oVirt.js build. We're also planning to provide
minified version + Source Maps for better debugging.
oVirt.js is planned to be usable NOT ONLY in web browsers. In fact,
there's "ovirt.svc" namespace containing services used by oVirt.js API
implementation. You (or any 3rd party extension) can override these
services to achieve SDK portability for given runtime environment.
In other words, I'd love to see oVirt.js used also with Node.js :)
Finally, an important thing to mention - oVirt.js requires AT LEAST
ECMAScript 5.1 compliant environment. All modern browsers support
ES5, including IE9+. Unfortunately, IE9 doesn't support ES5 Strict
Mode, but that's not that big of a deal.
I'll send some more emails outlining implementation design and also
how to manage source control & distribution of oVirt.js.
Regards,
Vojtech
------=_Part_23610907_1521630269.1403011303574
Content-Type: application/x-compressed-tar; name=ovirt-js-sdk.tar.gz
Content-Disposition: attachment; filename=ovirt-js-sdk.tar.gz
Content-Transfer-Encoding: base64
H4sIADVAoFMAA+0873PbNrL9nL8C5w9H+VWm5F9xx4l749pO67ukztjOzZvJZDoQCVmMKUIlSDu6
nv/3t7sASYAEJaf1tL13oWcsiVzsLnYXi90FQBXfbhVCFXGe3ImtXChZ5pFQI3mX5EX4UX31BNd4
PH6+t8fgc/tgf2x/4rUHv56z7Z3dvYP9g93d8S4b74x3t59/xcZPQXzdVaqC58DKnfqXjFZ0d91z
3RlWf/6HXKMRk//UqmaLXBayWC5E+AxuX4qfywQMgp2dvDm+ivJkUbD9cJtFcr5IE54VTGRgJDKb
i6w4xBZsVhSLw9Ho/v4+FNGcbyVZIfKMF4nMeBrK/GZEt3ee74wA0wjbnJR5Du3TJcsreq/l1ilX
M5Ymk5znSwd1KmN4FAIPo2fUXGYFTzJWzAS7Ov0Hu0+KGfwMyHwDdpPKCU/ZHc8TPkmhX/CN0TN2
xH55eEE4zj4tpBJMifwuAdNnpRIxmyzZ8dtzlkBfBXaQOkFyOePRrAJmaibLFKAF4xmTk48iKkBA
xFOS3UCfSoWE2VwUMxkrQnBVEYpFlPIciFEHEsUyPhdqwQHvjN9BozItEqDPcpkKpeWwHTLxKVEF
Yq85joA4sCDvRJ4ncSwAnWTAZiLutFgWMi/4JEmTYsmmMmc3MNgzlpdZkcyFrUeisbOCBgmHZzHL
xH3nIQfaJDqkKT4VIlMgNcWAYpQmgF49035F3UWggMG0zCKUKxtssl+eMbiCEjVR5ElUBKAdvIUq
qwkZreF94PSH6+u3tSqwX0pksZb7zyU4NYVyyMVcFlq9Imd3CdfNyNgjmYYVsmvUgKtv7K1i//vm
9Q9gfZcaZ6VlVS5Qqrq/92LCJrm8ByJKI6w4DtFwkW26a0hdAZuaC8Noh8/QBg8Qx1ue87kK1lmc
g3WBbQSMQTAeCx/bYoE2yOBQN9C/kAvo8RAMc8rB9kh8wfdn10G7dZmn0PTd5WuEQKFbHXGbi/kC
bA41CswNYhmVKF024aDnd5fnm23MM8Fj4Bewd/sGFpUb7RkwHy3dro13IuMlIOXZEgwqLYWrP1fF
IfWoMk6XRlamqaMbmV2VESjaVU3dGtsk2Z28Fex+BmPO0Q+5UoE8KI1jCtiXbABTUlHCqJKxYDvj
8WbYoniW5zL/FfSmPEmBmINfguvMwf2ANbmkUAiHDd5BY4RDVncavxI3m5aFV6P20ywHy0dH4cp3
sGmGsD0keJYUyb8EML8oCxU6zxvSgM/68e9/N+6guoBoKLMc7GOJ3RQR9OxGQLuus7GvZMoG2JQa
XmFDdnR0xPZ8sFb/jBgAPTY2cv32CEXJ/vpX++ZLtjset3i1+n+udcYX4JcWMFsVOAdkcQq6qRgP
vW0N4xUjQPSnMFGvTJtBranNvp7gVUMZGagFuG1xDQMOVOVr8MBECiMYif9lJXVtHKtpE8ygkVUf
zc5d907bEiiGUTKFObDHK4YdkzWO0Lay0NwDYyNf+KLTCLyh2wJvILgH1jguF766aey53QZ9l9uA
7gA0eqNur89xKKEF4dAzvQ67g2QhsoHu2xC7MGRFXgrP0DzPorQETxFBqAK+O+GpQn81Y1xpwfKy
mMG4hQl4rqdNjA8iKW8TmD0htolyqdSWSoCjamLusoOR24lF4YjY6XJzvFiYYBF1aSTnorugGSC8
FUs1MACbIXCHkZsVc2C05TNMFLmeI44q/O8R9gOat3MjLOQVzWwDj8mSPYvC+LwfqB3RHBrsZCGt
hg8e+b+CqJjJ6ZSC3F51orseoF1YGPX4qMZFLooyz+rI5MWzh03yxE0IXBYYIibrY+B3WZrcNiHz
0GoJAS2MIkwPMAZVCuJIisrZfZ5QRDmXACGm0yTCiJD9nd9xk13gfBSaCBERuiFiRWxNqNhw4saK
74om/AVL5sSLjhWwu8RZ8imBaJW4jQUMDzDGCG0NnEhJTMxpOknUXMu/phWapq04D7ITYLCEKKaJ
1SxStWdXNGJqkojQmfHVQkRrIz97AGZCYCSOfa0Aqcv2JIKINdst1DzP+dJDYIxxPGmvxb2LE7rx
+RhNgEgDA3wGeYHpsgrlE0ySesVDgXttJwuRoxzgjkxTeU85TAEsuREwpFEkEQEyWAaGtSEQW4C2
kTg2m1FypgRAgo3wuaxtxMG10+CCMKrowcajooRU1AxC6qiDZTcEP3pDwbHFUssY0axzPaeBdnM5
r7OfOnV0kO6FGFGAvzT2CfJp8ThJdMYUYAIaUMBvAzjY9sOKfT8MELEDRrTaoaGMQfRC+YLE+dIM
1PYDJGGPYYuTlcEikoV29OGZUOuRar4AyPsPLgiyCgD0YR73BRaOZnAQ2zoMO1g/YxaaL82kc1S7
WX1j/YRx7FV5v65Dj4A8nE4zH5/TLIx4mg4Q05Dp/0bzy3WTm7EmbGRNWsNnttW90b6m9mQKayM0
oPJJUmCBiMlFyw3hoLnQN22DbJjzGaLBYkwnrH76cgyUsQ54KygsK9yIAoLKkaKPhiyN4LnIb8SW
zLbgKThF7ILMXbkjd2HDRDO3TKFrc34rvhfFlSjeIKZXmemMgX+cYJ1ooDUl3sv8FqVK3LY8u8NK
e457w2+d/BP8HGlHGXnQqDAykfW8pSOgx4gGp1GwLz0VKKyIwTdXuM10yPMbXV+4T9JUY8ZCD8wJ
FBHIqfYqBjrJaAhAI1E7M2LX8XIOKxeYLd8nWCRpNySSE2Eai7hp11Fe1yg1rrZZGj4a4HIRwzzT
l79i6qVj3wqwL+/6KSTZDDRZCN80uD/v8hpTbVQ6EfSTqVoSFU/bdvrmPniMpRqf0LbTylX4bTUW
YsGiVGYYVkN0RUse4B999hJo0QTaWMh6dEvLTjAup5uNypHECd46zmJSujMxEsFa6h5fpEkcgZ7o
2ylgM61aOjIcVPokaI86vYlALS7KBOrCrJsSYAIAYxm7OMdCOwwu8LgLmegAHwu9Vcc4qqiK3/ki
ccP3mtqa+L2en9vB9YsapNFuR+MN0LTrRRt76k4qbqzGLs+urqdlyqoFMYha01RYZZjG36lLA3NS
g/RNNeTiYSg41agkbty4f/yj/7gAm+S6pmJMvmNiJuDqDkVZTYXmy7ADgaWFN1QKONRFji4IKBQX
W8Sn4i0vZod6knRvsq9ZMArgP3Sp0x6m6kxhZH5JXtweD2CsvM9TWSKo5DzoryUhpkOHFLU4hdua
ir+w5HF8Ld+0aQ+mF06Acqk5lJWCcFikmPXWi6nsJpflQifUtM7Ta1UkKDQSQmBbyX+AhXQ0bCvt
GFPA3yRTHseN4OrhqqUaoHLrmZgc9aPEjDiPWpb4JxuNby+ufMJGmO9kvDxkf7+6+DHU+TOkzNrM
/58PPw1ROfPrih7L+X2jdCRILh7nmcmyeeDEDM26iY/rrnBq+FhMk0y81cHC8lLw+CLDtRsMH36k
Kh9++yfGuW3hmvqki8HYXtPcV5gEZIcN3q6WscaG682gXg5hWRcgktk0uSlzDYQV1i6MyCCGtiA6
OVyjpK5YchGXkXidZLeKDaju0zOM6Fmowa0wQcf4Q/Cg2a3PKPXz9/gYGqeYHtP3WS6mXTMytHSj
VjIKEu7pTBUpBkkcsAwyk0qsdnzn0/4AWwzJ8sIk3nzhQYl8fi5SamPQ4vcW4sb+MSYVOm7LhELf
6HGBVp5MS+vlpAlctN6ONCmUa7s80seig0UFQ9sOBl0S9niOBS6BNiQf0blm7Zb7usSdvtDACg0g
lvDt36G2s0f2knu7x91+1ViM8SG5tss6w5VsmKk8DguLegG4qMDOMEwBdbrOiXVmXIYT1KabBdXE
bcJDQ9TUbU2RFiJhLFenwnIKVYK0dIWOqy0gbXvtBUm/cICQkuYL9IIwYSqyG4gcca11e5P9Dfv1
Hh+8H3/4wA7d2ptd+XOYt4aQRYA+ISWmz0H9BKk0YF0Sl7XP8Ei6pVdNYs4Xg9XT6eOm0c+bPh3n
telYmNce7PSknZhU/OnSH3yY6OW9uWMV1IbejOfDZtvET+R8UcK4NuvvE1HcC9yYdC/rnMs2cBYn
06lniQATT3wkcpFFwtqsI5wWVfEFF0SxFoJlGsFwS5U0HLRGSqTZO0UcA5knNwnkr0M2l4A1EbEt
HDJchGsVo1sllwrJZrUKbu7XKHvCABoqNZCn7goAfcuU1VDEbnj2FtDyfMVXOOPq4j6r4w1E2xf2
YYEz1nu8KhJgHErpdSZwFQZngGu/EhedsAa81EUSSy/+LQsIgIMcJ++q4/T7M8tLbj0ucg0OI796
F1vdiVxEZa6SOwHMovnpSsl6lm1BA9eW9dR6px4M3Q71VNRQLzbGVdsjbGG56vZBr90j0Vc/StTZ
zyVPB0iOIiPwkjSYDokDy9X4NNJB4xtRNcLqVqc+9evrM71Fmb5SDDr6zuSrCmm2Yxq3UlNtrZ1W
cxnkiqajpzTLd+NhXAG/yXQukVsOva1yon/EbBDf6pVNrlUfpBmid6HC7egTLFegE744vQCbFHdY
cUc8qBvLZ2AJdQDsoRcuGE9pbxUzEmW0ggz2QAy5gnYnOsrUjXxWrYUYATQ2ZStb74lJV4QOjaZo
8gvb8uwpSxgP4hQcWlUGA/KnLee8ffdZFQaf8zulwUAie7rig6WRFUHRr1q1+E2VKJOxrFK5AfnT
qvz07PXZ9dlKrQe/PASPFtOxWfauxxa5kV+XhNYJaOtuyx3a4ZML+djNXqipepHdHyp7ovROIdyh
rfGtDNTXy+1R+W0tJr5ePvzzBNNj92ZfsT48oFGa7UwmMz7VVdisb2h0hN6w0SDorb/i9USjBa/1
Iwavx9RiKzivt2w65nGMeLXtifcaEl4PbX/30G9cND+bkkkhF1spzNRpKxKwpmraGSczUG6Cudba
hPIxaWS1MOlThHdFiZiCBKr+QRUvq4trk9JuKno+ZcE0CzAdbDYqDO0ZorXH2k0s6hQ1k1ty0QKt
JQPh1KvsIv9RAkhrq4wVHdc7oxHibxDOQDj8U5hBozbT3RC43ofphsD1EK15r09u0cGRoNo/1ImR
6xFkB8m0b6eV/dbbwynkbLhtntMWbutpNxBGViosA2eHedsr50vPiIVuveW5ouiNmuKqNA01b2Ks
K77AEIEssKVL1JMtu0sJ9V6TaqccJG2ZQPZ5vuwSrYoBtYLJgFuBT2++XbPra2Vq4t5VEl8nzFGC
xnWbwyUMc/QJj2673Df7/720HqBpEc3YwLv1pPI0+rwCE2QK2q+kyw40eBglUxGm8mYQaLO5nyVY
VgQlmV0+pCbwt+xr1t7w0ERuvtUHNDKN05xxOZGxb3Z7JL8Or5fuIRo9UVsHaZBbi2hfInIpbhJF
m6EeoR+KJVU99prpsgJt980eqZZHauC96X9rn1g7Au4wrEXWw64wruAxzFZu46lYLfVmnJrTYX0i
8JGn7agHOaBZdV4IfREkrLjTfeU5BPe8Bw1tNNAf+k97VKcLAszaF0WAMVKAO3iTiPoz+qhkFvS0
ock0K7aulwvxeS1fJSkomNrApFxtQhxAuEgPtBtS3dpCWwqrTtY4Z7g8211NjFVLSQdd3ZCpzNPD
FpcCIq1MfMeVeJenOAq7W1M8iY7u/GF9lLADMaFwrmYIo7t25NUWCB3s7D2mMV8SIn1Uwz5OZ82N
w8aH9a55O9GYNYn/xqp+jekDgOjQoRVLUfJBG7ssnA29OqLuDJcz0lB16vP1kLynLAsIY2CyS2h3
p0rxZLfT0lHsoQ5nDkej7Z2DcAx/24ffjL8ZtwJyPDCTcixTx2T6uFNwJvQhR8m0QZv5VhFDMdMH
ffNA4eEBKnM7KReJ3B4IZnW9Xb30CvbDZrPrrEr2cE8dTR+eoLyTIlezVR39kfEnWVJYexcwhI0T
FeEJcAhy09RCbWEkhNgcA+sId8+QZ1qb+rYj9UC/HmJL62cEj0cWRl01qJORKnxeJNY+Q9yXBwB/
9NsPvlyq5/0fT0ljPB4f7O/3vf9Dvy9je2d3n+B2dth4+/n+wc5XbP8pmei7/svf/+HoP8Qg4elp
rH7/y7h+/8v4+Q783wb97+893/ny/pff49JOfgOLTRuHbMMxhw09s25AyIXPFmkJ7n7kgIz0TYhr
5mkFXjkRnCs6OBsXs/Hs4Yv//8OvPv9v6fU301g3/ncPdsz7n/Z2xjt7+P6ng+cHX8b/73G9/Ess
I3znE0NVf/vsZfUBWdG3NJ5fQmrGcVdFrkRxtFEW061vNgBipEFeYppkIJU+x63y6GhjNIri7KPC
BeoynuJ7juitTfwj/zRKk4mqXuX0UY12wr1wu/m98e3LkcbkQVu9l2wlkDFeF+rlSHMKjFMX/2jJ
/zmuNeP/SV4At2b87+4e7Lnx3854b3f/y/j/PS5aaciSOccTJ0nE3p0zrXo2kbJQkJ0v9FvT9N1j
yv6x6JMVYX1rEDhmhC+1qJ+FuakfmnwSEs0Cbl8JSrOPI326/7Cn3IY4TxHnoK5EPLSw83hZvcbi
GrdYd19nR6sonOUJvl6iSZor1A3FZhc7z2I5P4d09kbkbDBPsiFkyZ88xZU3EOSE01TKfEBfdUvA
+D/QjH9iWwwas69xc+vX+LWzOHUxoY22uEB4Qvlz/7EV2nUUYYYOOqiP2dnJvFVrMNv3GrxDUJve
wUdrbFzh0iCg1ydoqtUkrLyKzBxe1cTwlIxVDMBQ8ZAFKL6tONrCsrcjrsF4yLZhCFjLnamMeGpX
TR42q6r2II6O8a1xJ1XVF6uv9QuimtMWLhSDZrYynEI9QerVg1ivIQ42Q1rmbgpqaPa4C21pCSjA
N/Lp2cLZ7NUgsR5jefUd7euJGS+ImBE3mGpYyPOri+6rYfAkq94LZKulKnhjFVyftFTALAviKOjs
SQRe9G6igS1Bw0hHhpalWZJsQa+UpYFdL81TveGlv19UgNfbTpw1PE8P9eYZp4ca/WN72IKGHtKN
S0O2t7emnemt08a8moo+RGcQv8bjelh2a/qvnCGE3tXpkMImjzD7Fhwq67h9qsbc8mzuiDtvOnD6
q3GvUa7p4veisJ0UuIzz09YLLnRXQduDBlkS273+XhbfLc/9atR+oU+lrZYrjRZgNX8revbwJfv8
cn25vlz/5df/AadgwuoAXAAA
------=_Part_23610907_1521630269.1403011303574--
10 years, 5 months
Fwd: [libvirt] KVM Forum 2014 Call for Participation
by Brian Proffitt
----- Forwarded Message -----
From: "Paolo Bonzini" <pbonzini(a)redhat.com>
To: "Libvirt" <libvir-list(a)redhat.com>
Sent: Monday, June 16, 2014 12:08:22 PM
Subject: [libvirt] KVM Forum 2014 Call for Participation
=================================================================
KVM Forum 2014: Call For Participation
October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany
(All submissions must be received before midnight July 27, 2014)
=================================================================
KVM is an industry leading open source hypervisor that provides an ideal
platform for datacenter virtualization, virtual desktop infrastructure,
and cloud computing. Once again, it's time to bring together the
community of developers and users that define the KVM ecosystem for
our annual technical conference. We will discuss the current state of
affairs and plan for the future of KVM, its surrounding infrastructure,
and management tools. Mark your calendar and join us in advancing KVM.
http://events.linuxfoundation.org/events/kvm-forum/
Once again we are colocated with the Linux Foundation's LinuxCon Europe,
CloudOpen Europe, Embedded Linux Conference (ELC) Europe, and this year, the
Linux Plumbers Conference. KVM Forum attendees will be able to attend
LinuxCon + CloudOpen + ELC for a discounted rate.
http://events.linuxfoundation.org/events/kvm-forum/attend/register
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2014.
http://events.linuxfoundation.org/cfp
Suggested topics:
KVM/Kernel
- Scaling and optimizations
- Nested virtualization
- Linux kernel performance improvements
- Resource management (CPU, I/O, memory)
- Hardening and security
- VFIO: SR-IOV, GPU, platform device assignment
- Architecture ports
QEMU
- Management interfaces: QOM and QMP
- New devices, new boards, new architectures
- Scaling and optimizations
- Desktop virtualization and SPICE
- Virtual GPU
- virtio and vhost, including non-Linux or non-virtualized uses
- Hardening and security
- New storage features
- Live migration and fault tolerance
- High availability and continuous backup
- Real-time guest support
- Emulation and TCG
- Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
- Testing
Management and infrastructure
- Managing KVM: Libvirt, OpenStack, oVirt, etc.
- Storage: glusterfs, Ceph, etc.
- Software defined networking: Open vSwitch, OpenDaylight, etc.
- Network Function Virtualization
- Security
- Provisioning
- Performance tuning
===============
SUBMITTING YOUR PROPOSAL
===============
Abstracts due: July 27, 2014
Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include in your
proposal
the proposal type -- one of:
- technical talk
- end-user talk
Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"
You will receive a notification whether or not your presentation proposal
was accepted by Aug 20th.
Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.
TECHNICAL TALKS
A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, it should
focus on the work that needs to be done or the difficulties that haven't yet
been solved. Summarizing recent developments is okay but it should
not be more than a small portion of the overall talk.
END-USER TALKS
One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.
If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.
HANDS-ON / BOF SESSIONS
We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups. This time can also be used for hands-on hacking
sessions if you have concrete code problems to solve.
These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at
http://www.linux-kvm.org/page/KVM_Forum_2014_BOF
Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.
PANEL DISCUSSIONS
If you are proposing a panel discussion, please make sure that you list
all of
your potential panelists in your abstract. We will request full biographies
if a panel is accepted.
===============
HOTEL / TRAVEL
===============
The KVM Forum 2014 will be held in Düsseldorf, Germany at
Congress Centre Düsseldorf
http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-and-travel
===============
IMPORTANT DATES
===============
Notification: August 20, 2014
Schedule announced: August 29, 2014
Event dates: October 14-16, 2014
Thank you for your interest in KVM. We're looking forward to your
submissions and seeing you at the KVM Forum 2014 in October!
-your KVM Forum 2014 Program Committee
Please contact us with any questions or comments.
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
10 years, 5 months
