Empty OMC after installing OpenNode 6rc1 + OMS

[lvazquez]

Hello everybody, this is my first post in this Forum.
I am new to OpenNode but not to Linux Virtualization.
I've worked for years via command line with kvm+openvz on CentOS/RedHat. In search of a Management Console I recently started to use Proxmox and now I'm trying with OpenNode because I work mostly with redhat based systems, I'm a RPM based man, I like libvirt and OpenNode seems a more modular/open project.

I was able to install OpenNode 6rc1 without problems, first by migrating a Centos server with kvm/libvirt/virt-manager and later (a second try) using the OpenNode ISO installer on a barebone server.

But in both cases I have problems with the installation of OMS.

I followed the steps in the (a bit outdated?) documentation complemented with the tips and suggestions in this forum (as fixing the certmaster hostname in OMS) but after downloading installing the OMS container via TUI, setting the oms ip/hostname in the /etc/hosts on both machines, registering with OMS, and accepting/signing the cert request; nothing ever shows in the OMS web console (OMC).

In the certmaster.log I can see the cert signing requested and accepted in both sides but after login to the console with opennode/changeme the only thing I see is the OMS shell and an empty "VM Map" tab.

Something strange I noted is:  after the registration request I see the node hostame  under /machines/incoming/; but when I accept the request (via .../action/accept or by using certmaster-ca --sign) the node disappears from /incoming (I guess it's correct), but it doesn't appears under /machines/by-name as shown in some documentation I've seen.

Does anybody installing OpenNode 6rc1 experienced this problem?
Do exist some know fix or something I'm missing?
I was very hopeful with OpenNode but after 3 days fighting and searching documentation/googling without results I'm becoming a bit disappointed.

I really want to test and get involved with this very promising project, so any help to make it work (or more detailed/up to date documentation to better understand why it's not working) will be greatly appreciated.

Best regards
Luis

 

[activesys]

Did you verify that both OMS VM and OpenNode hostnames resolv correctly both on OMS and on OpenNode? Eg usually it means that you have to add hostnames into /etc/hosts files - if you dont have DNS server you manage ofcourse.

[lvazquez]

Thank you very much for your reply.
Yes I have checked carefully that the OMS server's IP and hostname can be resolved from both  the node and the OMS itself.

Here is a sample bash session from opennode (node01) showing /etc/hosts content in both nodes:


[root@node01 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.160.20 node01.sample.com node01
192.168.160.21 oms.sample.com oms

[root@node01 ~]# vzctl enter 101
entered into CT 101
[root@oms /]# cat /etc/hosts
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.67 testvirt5.active.ee
192.168.160.20 node01.sample.com node01

127.0.0.1 localhost.localdomain localhost localhost4.localdomain4 localhost4
# Auto-generated hostname. Please do not remove this comment.
192.168.160.21 oms.sample.com  oms


Do you know if is there any omsdrc log file (everything is ok in certmaster.log) I could look at, or any debug setting in OMS I may enable to find out what is going wrong?

[lvazquez]

Just  to complement the information, the /etc/certmaster//minion.conf is the same in both servers (node & oms) as follows:


[main]
certmaster = oms.sample.com
cert_dir = /etc/pki/certmaster
log_level = DEBUG
certmaster_port = 51235


The certmaster.conf content in oms is:

[main]
autosign = no
listen_addr = oms.sample.com
listen_port = 51235
cadir = /etc/pki/certmaster/ca
cert_dir = /etc/pki/certmaster
certroot = /var/lib/certmaster/certmaster/certs
csrroot = /var/lib/certmaster/certmaster/csrs
cert_extension = cert
sync_certs = False

and the same in node01 with listen_addr = (empty).

Best regards.

[ilja_l]

Dear Luis,

thank you for your interest in OpenNode and sorry if OMS/ONC are not stable enough, we are working on making it better.

Regarding your problem, could you please try the following from OMS VM:

Code: [Select]

func '*' call onode.vm list_vms openvz:///system

This commands tests several things:
- if trust between certmaster and func is there;
- if funcd is running on the HN;
- if opennode extension modules are visible in func;
- if libvirt/openvz work in rdonly mode.

thanks,
Ilya

[lvazquez]

Hello ilja, thank you very much for your support.
Me and all the other people using great free software are the ones to thank you and all the people working and contributing in great open source projects like this.
I have been supporting and working with free software solutions (both as sysadmin and developer) for 15 years and besides enjoying great software and I feel is also our duty to help, so far as we can, with the growing of nice projects like this.  If in the meantime we are able to learn to use a new solution it's still better

Regarding your suggestion, this is the output of the command from OMS VM:

[root@oms ~]# func '*' call onode.vm list_vms openvz:///system
{'node01.sample.com': [{'consoles': [{'cid': '101', 'type': 'openvz'}],
                        'diskspace': {'/': 11264.0},
                        'interfaces': [{'ipv4_address':
                        '192.168.160.21/24',
                                        'mac': '00:00:00:00:00:00',
                                        'name': 'eth0',
                                        'type': 'ethernet'}],
                        'memory': 512,
                        'name': 'oms.sample.com',
                        'run_state': 'running',
                        'state': 'active',
                        'swap': 512,
                        'template': 'centos',
                        'uptime': 154768.70000000001,
                        'uuid':
                        '7958a941-dfa4-bb0a-f196-5ecca1caea91',
                        'vcpu': 1,
                        'vm_type': 'openvz',
                        'vm_uri': 'openvz:///system'}]}

From the output It seems OMS is able to connect and getting the info from node01, but It doesn't appear in '/machines/by-name' and is not shown in ONC!??

[ilja_l]

Hi, Luis

thank you for your support, if you are interested in a more "low level" progress of opennode, you are always welcome to check https://github.com/opennode . We might be opening internal Jira in some time too.

Regarding the issue: it seems that it's indeed a problem of OMS - communication layer works fine. So, the first approach is to update oms/onc and refresh db. So far OMS is more or less stateless, so simply doing the following steps should be ok:

• Stop OMS: /etc/init.d/omsd stop
• Clean DB: rm -f /opt/oms/db/*
• Update OMS: /opt/oms/update.sh
• Start OMS:/etc/init.d/omsd start

It will pickup registered HNs automatically. If not, could you please post last output of /var/log/omsd ?

thanks,
Ilya

[lvazquez]

Hi ilja,
sorry for the delay but I was on very busy time this weekend.

I will try to take a look and checkout the Opennode projects under github.com (as soon as I am able to make it work   It would be of great help If somebody could point me to some document explaining the architectural and/or functional relationship between the component parts in an Open Managemen Server (oms.core, oms.knot, oms.onc, wsproxy). I have checked the "OMS (v2) DEV docs" but it seems kind of minimal and mostly enumerative for my understanding.

Regarding my problem with OMS, I followed your suggested steps.

• First thing I note is the service name installed in the OMS VM is named "omsdrc" and not "omsd" (even it seems it would be more appropriate).
• Second, after I made the update I ended with a wrong symbolic link at /opt/console pointing to the old version of opennode.oms.onc:
  lrwxrwxrwx 1 root root  /opt/console -> /opt/oms/eggs/opennode.oms.onc-0.0_477_gb74e-py2.7.egg/opennode/onc/../..
  So I fixed it to read:
  lrwxrwxrwx 1 root root /opt/console -> /opt/oms/eggs/opennode.oms.onc-0.0_482_g49b7-py2.7.egg
  May be this issue should be handled for the update.sh script.

But after doing this and restarting the service I connect to OMS Console and I CAN FINALLY SEE THAT NICE GREEN ICON on the left side. So it seems the main problem was with the OMS db initialization.

The information in the node01 tab doesn't seems to be too accurate (see the attachment) but at least things are starting to fit.

Thanks,
Luis

[ilja_l]

Hi ilja,
sorry for the delay but I was on very busy time this weekend.

I will try to take a look and checkout the Opennode projects under github.com (as soon as I am able to make it work   It would be of great help If somebody could point me to some document explaining the architectural and/or functional relationship between the component parts in an Open Managemen Server (oms.core, oms.knot, oms.onc, wsproxy). I have checked the "OMS (v2) DEV docs" but it seems kind of minimal and mostly enumerative for my understanding.

Regarding the general structure: OMS is a core providing central services. It was extracted into a more stand-alone framework as we wanted to be able to have easy way for customization/closed-source plugins. The plugin (bringing in models, views and business logic) for managing ON6 OS is KNOT. The idea is described here:
http://opennodecloud.com/docs/opennode.oms.core/developers.html

Regarding my problem with OMS, I followed your suggested steps.

• First thing I note is the service name installed in the OMS VM is named "omsdrc" and not "omsd" (even it seems it would be more appropriate).
• Second, after I made the update I ended with a wrong symbolic link at /opt/console pointing to the old version of opennode.oms.onc:
  lrwxrwxrwx 1 root root  /opt/console -> /opt/oms/eggs/opennode.oms.onc-0.0_477_gb74e-py2.7.egg/opennode/onc/../..
  So I fixed it to read:
  lrwxrwxrwx 1 root root /opt/console -> /opt/oms/eggs/opennode.oms.onc-0.0_482_g49b7-py2.7.egg
  May be this issue should be handled for the update.sh script.

Heh, the update of the symlinks is done on the startup of the service. So if you'd run the updated OMS first, you wouldn't spot it   The reason for that is that depending on the configuration ONC can be served either from python eggs or from static folders (for dev mode). We get that only once we have the runtime. In a normal scenario it's completely transparent.

Anyway, current status of ONC is a bit unbalanced, there are several stabilization fixes in progress, hopefully will be finished quite soon. Once it's more stable, the word 'beta' will be gone

cheers,
Ilya

[lvazquez]

Regarding the general structure: OMS is a core providing central services. It was extracted into a more stand-alone framework as we wanted to be able to have easy way for customization/closed-source plugins. The plugin (bringing in models, views and business logic) for managing ON6 OS is KNOT. The idea is described here:
http://opennodecloud.com/docs/opennode.oms.core/developers.html

Nice, this is more or less what I was looking for; thanks.

Heh, the update of the symlinks is done on the startup of the service. So if you'd run the updated OMS first, you wouldn't spot it

Hehe, it seems I was a step ahead on time

Once it's more stable, the word 'beta' will be gone

Aha!, so this was the meaning on "beta"  
I'll make clear the intention on pointing out those details was no complaining, but helping to find them out (just in case).
Now that the ONC is showing nodes information I have new problems, but it's nice at least to be able to run the application, even in "beta" stage

More to follow  ...

Best regards,
Luis

[ilja_l]

Hi, Lois

don't get me wrong, I'm very thankful for the feedback The problem is that we've initially targeted more at 'oms shell' aka 'omsh' for UI, and ONC was lagging behind. Now it's slowly but definitely getting better. Your feedback is very valuable, and will also be used as a steering for documentation

cheers,
Ilya