xcatd starts conserver instead of goconserver on SNs

[kcgthb]

On Service Nodes, the xcatd service seems to start conserver instead of goconserver unconditionally. Is there a way to set a preference or to disable conserver entirely? Uninstalling the RPM is not an option, as it's a dependency for xCAT-server.

On the SN:

# service conserver status
● conserver.service - LSB: conserver
   Loaded: loaded (/etc/rc.d/init.d/conserver; bad; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

# service goconserver status
Redirecting to /bin/systemctl status goconserver.service
● goconserver.service - goconserver console daemon
   Loaded: loaded (/usr/lib/systemd/system/goconserver.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2018-07-26 10:50:41 PDT; 6min ago
     Docs: https://github.com/xcat2/goconserver
 Main PID: 27907 (goconserver)
   CGroup: /system.slice/goconserver.service
           └─27907 /usr/bin/goconserver

# service xcatd restart
Restarting xcatd (via systemctl):                          [  OK  ]

# service goconserver status
Redirecting to /bin/systemctl status goconserver.service
● goconserver.service - goconserver console daemon
   Loaded: loaded (/usr/lib/systemd/system/goconserver.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2018-07-26 10:58:02 PDT; 1min 30s ago
     Docs: https://github.com/xcat2/goconserver
 Main PID: 27907 (code=exited, status=1/FAILURE)

# service conserver status
● conserver.service - LSB: conserver
   Loaded: loaded (/etc/rc.d/init.d/conserver; bad; vendor preset: disabled)
   Active: active (running) since Thu 2018-07-26 10:58:04 PDT; 1min 32s ago
     Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/conserver.service
           ├─29152 /usr/sbin/conserver -o -O1 -d
           ├─29153 /usr/sbin/conserver -o -O1 -d
           ├─29164 /usr/sbin/conserver -o -O1 -d
           ├─29166 /usr/sbin/conserver -o -O1 -d
           ├─29178 /usr/sbin/conserver -o -O1 -d
           ├─29203 /usr/sbin/conserver -o -O1 -d
[...]

[immarvin]

hi @zet809 , any thoughts on this?thx

[zet809]

hi, @kcgthb , what is the conserver attribute set in servicenode table? As mentioned https://xcat-docs.readthedocs.io/en/latest/advanced/hierarchy/define_service_nodes.html?highlight=goconserver, it shall be 2 if goconserver want to be started.

[kcgthb]

Hi @zet809,
Ah yes, thanks for the pointer, I missed that part. That's actually the first time I'm hearing about this.

I guess it prompts a general concern with changes in xCAT lately: the changelog notes are pretty short, which is ok, but that makes finding that kind of information a bit difficult: you basically have to re-read all of the documentation pages for each version to spot the changes.

But anyway, thanks for pointing this out!

[zet809]

hi, @kcgthb , thanks very much for bring this question out, I agree with you that it is inconvenience for user to find it out.
And will you pls give us feedback about using goconserver.
If it fulfill most of the customer's console requirement, we will active goconserver by default, then, no need to set 2 to servicenode.conserver.
^_^

[kcgthb]

@zet809 So far, goconserver has been pretty great! I think it's way more powerful and flexible than the old conserver, although I mostly use it via rcons/wcons and haven't used much of the advanced features yet (web console...)
To me, it could definitely be the default for new xCAT installations.

[zet809]

Thank you very much for your feedback, @kcgthb , we will use goconserver as default in the near future.

[zet809]

hi, @kcgthb , in order not to mislead user that use 1 for console before, we can not change 1 to goconserver by default, but update the document to switch to goconserver, for more information, pls refer https://xcat-docs.readthedocs.io/en/latest/advanced/goconserver/quickstart.html
Thx!

[kcgthb]

That looks good to me! Thanks for updating the docs.

[hu-weihua]

@kcgthb, Could you help to close this issue if the fix work? thank you very much.

[kcgthb]

Absolutely! Closing this.