From mburns at redhat.com  Fri Nov  2 01:19:58 2012
From: mburns at redhat.com (Mike Burns)
Date: Thu, 1 Nov 2012 21:19:58 -0400 (EDT)
Subject: [node-devel] Cancelled: oVirt Node weekly meeting
Message-ID: <1299738178.3802701.1351819198150.JavaMail.root@redhat.com>

A single instance of the following meeting has been cancelled:

Subject: oVirt Node weekly meeting 
Organizer: "Mike Burns" <mburns at redhat.com> 

Location: #ovirt on irc.oftc.net 
Time: Tuesday, November 6, 2012, 9:00:00 AM - 9:30:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: aliguori at linux.vnet.ibm.com; anthony at codemonkey.ws; node-devel at ovirt.org; whenry at redhat.com 


*~*~*~*~*~*~*~*~*~*

Cancelled due to oVirt Workshop in Barcelona
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20121101/b94cb0e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 2807 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20121101/b94cb0e8/attachment.ics>

From fabiand at redhat.com  Wed Nov 14 11:10:05 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Wed, 14 Nov 2012 12:10:05 +0100
Subject: [node-devel] Reworking our TUI installer
Message-ID: <1352891405.3091.13.camel@fdeutsch-laptop.local>

Hey,

I've been working on the TUI rework - which is going on quite well.
The TUI is build around "UI page plugins". Those are python modules (.py
files) which put into a predefined directory and are picked up by the UI
infrastructure and displayed in the main UI. All pages of the new TUI
are implemented as "UI page plugins".
Now, while working on this I realized that we could easily build other
TUI applications around this concept. Our TUI installer for example
could be just the same TUI base, with a different plugin path and thus a
different set of UI page plugins. This way we are using the same
infrastructure and principles for the setup and installer.

I just to share this idea, because I'm still busy with getting the setup
into a usable state.

Greetings
fabian

[1] https://www.gitorious.org/ovirt/ovirt-node-config-molch

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20121114/797dd50b/attachment.sig>

From Charles_Rose at Dell.com  Tue Nov 20 10:58:01 2012
From: Charles_Rose at Dell.com (Charles_Rose at Dell.com)
Date: Tue, 20 Nov 2012 16:28:01 +0530
Subject: [node-devel] RFE: Plugin validation after minimizing
Message-ID: <50AB6239.3040308@dell.com>

Hello,

We have an existing software developed for popular Linux distributions and satisfies some of the
requirements to be a node plug-in, like files present in /opt/<vendor>/<plugin>, etc.

There are some files present outside of /opt and that fails validation in
edit_node:_validate_installed_files. These files are not critical for the functionality of the
plugin and can be removed via /etc/ovirt-plugins.d/<plugin>.minimizer. But the minimizer runs
*after* _validate_installed_files. So the validation fails anyway.

The other way to address this might be with a separate set of packages that have the offending
files/directories cleaned up and plug-in-ready. We would very much like to avoid taking this route
for efficiency reasons.

We would like to have a mechanism that can remove files/directories that are non-critical for the
plug-in and *then* invoke _validate_installed_files. Since the minimizer would anyway remove some
files/directories, it seems like validating the installed files makes more sense after unwanted
files are removed, not before.

Any thoughts/comments?

-- 
Thanks,
Charles Rose
Linux Engineering
Dell Inc.

From jboggs at redhat.com  Tue Nov 20 13:21:10 2012
From: jboggs at redhat.com (Joey Boggs)
Date: Tue, 20 Nov 2012 08:21:10 -0500
Subject: [node-devel] RFE: Plugin validation after minimizing
In-Reply-To: <50AB6239.3040308@dell.com>
References: <50AB6239.3040308@dell.com>
Message-ID: <50AB83C6.2090804@redhat.com>

On 11/20/2012 05:58 AM, Charles_Rose at Dell.com wrote:
> Hello,
>
> We have an existing software developed for popular Linux distributions and satisfies some of the
> requirements to be a node plug-in, like files present in /opt/<vendor>/<plugin>, etc.
>
> There are some files present outside of /opt and that fails validation in
> edit_node:_validate_installed_files. These files are not critical for the functionality of the
> plugin and can be removed via /etc/ovirt-plugins.d/<plugin>.minimizer. But the minimizer runs
> *after* _validate_installed_files. So the validation fails anyway.
>
> The other way to address this might be with a separate set of packages that have the offending
> files/directories cleaned up and plug-in-ready. We would very much like to avoid taking this route
> for efficiency reasons.
>
> We would like to have a mechanism that can remove files/directories that are non-critical for the
> plug-in and *then* invoke _validate_installed_files. Since the minimizer would anyway remove some
> files/directories, it seems like validating the installed files makes more sense after unwanted
> files are removed, not before.
>
> Any thoughts/comments?
>
What directories are those files located under that would trigger the 
failure? The current list of valid locations was just a first pass at it 
and we can alter that list based on feedback.


From jboggs at redhat.com  Tue Nov 20 19:18:16 2012
From: jboggs at redhat.com (Joey Boggs)
Date: Tue, 20 Nov 2012 14:18:16 -0500
Subject: [node-devel] RFE: Plugin validation after minimizing
In-Reply-To: <50AB83C6.2090804@redhat.com>
References: <50AB6239.3040308@dell.com> <50AB83C6.2090804@redhat.com>
Message-ID: <50ABD778.3090101@redhat.com>

On 11/20/2012 08:21 AM, Joey Boggs wrote:
> On 11/20/2012 05:58 AM, Charles_Rose at Dell.com wrote:
>> Hello,
>>
>> We have an existing software developed for popular Linux 
>> distributions and satisfies some of the
>> requirements to be a node plug-in, like files present in 
>> /opt/<vendor>/<plugin>, etc.
>>
>> There are some files present outside of /opt and that fails 
>> validation in
>> edit_node:_validate_installed_files. These files are not critical for 
>> the functionality of the
>> plugin and can be removed via 
>> /etc/ovirt-plugins.d/<plugin>.minimizer. But the minimizer runs
>> *after* _validate_installed_files. So the validation fails anyway.
>>
>> The other way to address this might be with a separate set of 
>> packages that have the offending
>> files/directories cleaned up and plug-in-ready. We would very much 
>> like to avoid taking this route
>> for efficiency reasons.
>>
>> We would like to have a mechanism that can remove files/directories 
>> that are non-critical for the
>> plug-in and *then* invoke _validate_installed_files. Since the 
>> minimizer would anyway remove some
>> files/directories, it seems like validating the installed files makes 
>> more sense after unwanted
>> files are removed, not before.
>>
>> Any thoughts/comments?
>>
> What directories are those files located under that would trigger the 
> failure? The current list of valid locations was just a first pass at 
> it and we can alter that list based on feedback.

You can also use --install which is unrestricted on what can be installed


From fabiand at redhat.com  Thu Nov 22 12:18:47 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 22 Nov 2012 13:18:47 +0100
Subject: [node-devel] Integrating the reworked TUI
Message-ID: <1353586727.2489.3.camel@fdeutsch-laptop.local>

Hey,

the reworked setup TUI has is approaching a state where it is not
completely destructive and could be integrated into ovirt-node.

I just wonder how we can do this i nthis early stage. The code still
changing a lot and I'd like to keep the reworked TUI out of the main
repo, but on the other side I'd like to have builds containing the
reworked TUI.

For now I'd like to create a Node plugin which adds the reworked TUI. On
the long run I'd like to do a sub-tree merge, but only at a point where
the development of the TUI slowed down.

Opinions or other suggestions?

Greetings
fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20121122/53d5c60c/attachment.sig>

From fabiand at redhat.com  Mon Nov 26 17:06:37 2012
From: fabiand at redhat.com (Fabian Deutsch)
Date: Mon, 26 Nov 2012 18:06:37 +0100
Subject: [node-devel] Reworking our TUI installer
In-Reply-To: <1352891405.3091.13.camel@fdeutsch-laptop.local>
References: <1352891405.3091.13.camel@fdeutsch-laptop.local>
Message-ID: <1353949597.2828.29.camel@fdeutsch-laptop.local>

Am Mittwoch, den 14.11.2012, 12:10 +0100 schrieb Fabian Deutsch:
> Hey,
> 
> I've been working on the TUI rework - which is going on quite well.
> The TUI is build around "UI page plugins". Those are python modules (.py
> files) which put into a predefined directory and are picked up by the UI
> infrastructure and displayed in the main UI. All pages of the new TUI
> are implemented as "UI page plugins".
> Now, while working on this I realized that we could easily build other
> TUI applications around this concept. Our TUI installer for example
> could be just the same TUI base, with a different plugin path and thus a
> different set of UI page plugins. This way we are using the same
> infrastructure and principles for the setup and installer.
> 
> I just to share this idea, because I'm still busy with getting the setup
> into a usable state.

Hey,

for now I've prepared an RPM which can be installed using the edit-node
tool (see below). After editing an ISO, install it, login, drop to shell
using F2 and run /usr/bin/ovirt-config-setup to run the new TUI.
The TUI is not very functional yet.
- It runs and picks up the network config defined in /etc/default/ovirt.
In general is the TUI generally manipulating the defaults file (there is
one mechanism for it, which is working), and afterwards (component
specific) applying these configurations.
- All Pages can be displayed
- It has been tested over ssh
- It reacts to screen resizes (try below 80x23)
- The mouse can be used to navigate

It also offers the following functionality:
- Easy creation of pages and dialogs
- Simple model+changes based approach (initial model, and UI adds
changes to this)
- UI can be updated through other threads
- UTF8 support

Additionally it has ton's of issues but it's one a good way.

Greetings
fabian

# wget "http://fabiand.fedorapeople.org/molch/
ovirt-node-molch-plugin-0.0.1-1.gitdffca6d.fc16.noarch.rpm"

# createrepo .

# cat > plugin.repo <<EOF
[plugin_repo]
name=plugin repo
gpgcheck=0
baseurl=http://127.0.0.1:8080/
enabled=1
[fedora2]
name=Fedora $releasever - $basearch
baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/17/Everything/x86_64/os/
enabled=1
metadata_expire=7d
gpgcheck=0
[updates2]
name=Fedora $releasever - $basearch - Updates
baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/17/x86_64/
enabled=1
gpgcheck=0
EOF

# python -m SimpleHTTPServer 8080
# and open your firewall ..

# sudo edit-node -n node-w-molch --repo=plugin.repo --install
ovirt-node-molch-plugin --nogpgcheck -vd
ovirt-node-iso-2.5.5-0.1.fc17.iso

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20121126/7fdfc241/attachment.sig>