Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 27 23:44

    YanChii on master

    workaround new bootparams varia… (compare)

  • Jan 25 16:02

    YanChii on new_release_20190117

    fixed boot.manifest (compare)

  • Jan 25 16:00

    YanChii on new_release_20190117

    fixed manifest (compare)

  • Jan 25 15:42

    YanChii on new_release_20190117

    OS-7436 vminfod can be overwhel… OS-6795 illumos-joyent build to… OS-7488 vm delete fails after O… and 8 more (compare)

  • Jan 25 15:39

    YanChii on master

    removed VM.js (TSC workaround n… (compare)

  • Jan 25 15:34

    YanChii on master

    moved postboot-rc manifests (compare)

  • Jan 25 15:33

    YanChii on merge-sysinfo

    (compare)

  • Jan 25 15:33

    YanChii on master

    merge sysinfo upstream changes (compare)

  • Jan 25 15:33
    YanChii closed #10
  • Jan 25 14:46

    YanChii on new_release_20190103

    updated boot copyright year (compare)

  • Jan 23 13:48

    YanChii on master

    allow consistently reexecute he… (compare)

  • Jan 23 13:48
    YanChii closed #119
  • Jan 23 13:46
    YanChii synchronize #385
  • Jan 22 21:58
    YanChii synchronize #384
  • Jan 22 21:43
    YanChii synchronize #384
  • Jan 22 19:58
    YanChii synchronize #385
  • Jan 21 09:50

    dn0 on master

    Fixed links to issues (compare)

  • Jan 21 09:08
    YanChii synchronize #385
  • Jan 21 09:02
    YanChii review_requested #385
  • Jan 21 09:02
    YanChii milestoned #385
Jan Poctavek
@YanChii
it also might be a celery bug… but we didn't manage to replicate it yet
watch/monitor/debug log of rmq messages could help… at least to know where the messages are ignored
klebed
@klebed
so the easiest solution is to reset rmq completely and then recreate vhost, user and permissions for user
i've dropped all the federation stuff for now and it works, at least
Jan Poctavek
@YanChii
if you find a way how to replicate it, pls share
Jan Poctavek
@YanChii
does somebody use opensuse?
just wondering what image would be more helpful... Tumbleweed or Leap
klebed
@klebed

@YanChii

just wondering what image would be more helpful... Tumbleweed or Leap

Bionic Beaver

=)))
Jan Poctavek
@YanChii
@klebed maybe it's not completely lost
look what I've found
klebed
@klebed
hah! It looks like a good news!
infinity202
@infinity202
what is the best procedure to install HPE (Hewlett Packard server) firmware on a server running Danube?
The HPE Linux packages can't be installed so how do you guys run the software?
Jan Poctavek
@YanChii
what are you trying to achieve? Reflash firmware or raid
monitoring?
infinity202
@infinity202
There is a tiny little problem with HPE SSD drives: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00092491en_us
fortunately my 8 SSD's seem to have an other production number
Jan Poctavek
@YanChii
well, this is a general smartos question
I don't know how to do it from smartos, maybe try asking on smartos-discuss
or boot temporarily from some recovery usb with HP-supported OS
Jan Poctavek
@YanChii
@klebed what's wrong with Joyent's ubuntu image? Can't you use that one?
klebed
@klebed
@YanChii kvm-clock issue, first of all...
and it's not up-to-date
Jan Poctavek
@YanChii
is that kvm-clock issue still present?
balwo
@balwo

I've got a question about 4.1 to 4.2.1 upgrade.
The upgrade keeps failing with the error shown further below.
Looks like I've got a problem with a ket or so. Although I can't remember messing around with keys in the Admin DC.
What should I do to get the upgrade working ?

main* Task Log
Time Status Object Message User Detail
21:16:31 2019-12-08
FAILURE 1m1u1-16618c5e-6ece-45c8-89c7 main System Update admin

Running git fetch origin
Running git checkout to commit: 19838ddcfcc7905bca3e6228ccd8c223aac750e3

#

Repository is on commit: 19838ddcfcc7905bca3e6228ccd8c223aac750e3
Starting 2nd run of /opt/erigones/bin/esdc-git-update --esdc-service-restart v4.2.1

#

Upgrading appliances (please wait) ...

PLAY [Running appliance upgrade of hosts mgmt??] *

TASK [Extracting current appliance version] **
Sunday 08 December 2019 20:16:31 +0000 (0:00:00.131) 0:00:00.131 *
fatal: [mgmt01]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).", "unreachable": true}

NO MORE HOSTS LEFT *

PLAY RECAP *
mgmt01 : ok=0 changed=0 unreachable=1 failed=0

Sunday 08 December 2019 20:16:31 +0000 (0:00:00.213) 0:00:00.344 *

Extracting current appliance version ------------------------------------ 0.21s
Playbook run took 0 days, 0 hours, 0 minutes, 0 seconds
ERROR: Appliance upgrade failed

#

Running emergency rollback
Running git checkout to commit before upgrade: deb8f7a9b430b75980d90d26034a054fcec84dbb
Previous HEAD position was 19838dd... bump patchlevel to v4.2.1
HEAD is now at deb8f7a... v4.1 version bump

Jan Poctavek
@YanChii
@balwo it looks like for some reason you don't have installed .ssh/authorized_keys on management VM(s)
you can check/fix it by ssh-ing into mgmt01 from the first compute node and make sure the .ssh/id_rsa.pub is present in .ssh/authorized_keys
then check also other management VMs like dns01, mon01 etc… pubkey from mgmt01 must be present in all authorized keys
then you can re-run the upgrade
pls let us know how it went
balwo
@balwo
@YanChii I check authorized_hosts on all mgmt VMs. Some VMs had a different key. If key was different, then I changed it to the value of id_rsa.pub of node01 . I can now access all mgmt VMs from node01, without having to enter a password.
@YanChii However, when I restart the upgrade to 4.2.1, I'm still getting the same error.
...
TASK [Extracting current appliance version] **
Monday 09 December 2019 21:33:13 +0000 (0:00:00.422) 0:00:00.422 *
fatal: [mgmt01]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).", "unreachable": true}
...
What am I missing ?
Jan Poctavek
@YanChii
@balwo there are two different keys for two different things
  1. pubkey of node01: allows accessing the 5 man
management VMs from node01
2:
pubkey of mgmt01: allows accessing the 5 management VMs from mgmt01 - THIS IS USED FOR UPGRADES
so to sum up: all 5 management VMs should contain both keys - mgmt01 and node01
Jan Poctavek
@YanChii
these keys are added automatically during install… so if there's some other key or the key is missing, I suspect the initial DC install has either failed (and maybe re-started) or did not for some reason perform all steps
the answer probably lies in /var/log/headnode*.log file
(there's only one headnode logfile)
balwo
@balwo
@YanChii Your instructions worked like a charm ! Nodes are now running 4.2.1. Thanks for your quick responses and outstanding help !
Jan Poctavek
@YanChii
glad to help
enjoy the Danube ;)