When configuring an LDAP connection in Velum, the form requires a certificate, despite the "StartTLS" option being off.

As soon as you hit "test connection": Missing form data

https://github.com/kubic-project/velum/blob/b67a614f1900c58674e0de37797339511f040afe/packaging/suse/make_spec.sh#L33

@MaximilianMeister This line introduces a quite complex version of the package. I am wondering if we could simplify it. I have seen + is used in other openSUSE package versions, thus I am wondering if this format of <version>+gir_r<revision_num>_<commit> is some kind of policy. If not, couldn't we make it more simple? something like <version>_git_<short commit hash>?

All this came across while trying to tag the velum image with the velum package version. Umoci only supports a limited subset of characters for tags.

In

https://github.com/openSUSE/umoci/blob/8b89fabfac6c176b95078cb106c2704303564e6d/cmd/umoci/utils_ux.go#L30

umoci states the limited character set available for image names and tags. @cyphar is there any mandatory reason for that limited subset of characters for tags? Anyway, I'd prefer to simplify our version numbers rather than enabling insane tags in umoci.

can someone tell me what diz little piece of code does and if it can it be removed?
https://github.com/kubic-project/velum/blob/master/app/views/setup/worker_bootstrap.html.slim#L2-L8
i have trouble understanding what exactly it's doing there, and why it's lore ipsum.
cc @mssola @ereslibre @vitoravelino

It looks like we're early enough in the project to switch to Postgres, instead of some version of MySQL.

Postgres, in general, is going to ensure a more stable environment (no risk of configuring with MyISAM ;-) - make deployment in other cloud services easier (like Heroku, for example), and ensure we have no licensing issues around 'community editions', etc., depending on how this project is eventually productized.

I'd be happy to submit a PR making the change.

in the bootstrap confirmation where the user needs to enter an external dashboard fqdn it could be that the field is not filled because @dashboard_external_fqdn is empty

the user can still click bootstrap, which renders a pop up in the frontend validator

Per the discussion with @vitoravelino around the OIDC connector layout at #665 (comment), there need to be some hr tags removed from the LDAP connector for consistency.

I know it's feature freeze, but i was wondering if we can add like a spinner for Accept Node.

Mostly because it takes some time for the node to move to nodes found and it doesn't let me know if it's doing something. I'm just looking at it and i have the impulse to keep clicking Accept node.
I think it would be better to have some feedback, even if it's a short operation.

bootstraping a new cluster will fail if any of the fields in the Initial CaaSP configuration section is a single int.

vpalade:terraform-1$ docker logs -f k8s_salt-minion-ca_velum-public-127.0.0.1_default_035a4bf0fee4f89e6cbea2f67f0ecbaf_0                                                                                   [67/504]
..................................++
...................................................................................................................................................................................................................
...................................................................................................................................................................................................................
.........................++
[ERROR   ] An exception occurred in this state: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/salt/state.py", line 1733, in call
    **cdata['kwargs'])
  File "/usr/lib/python2.7/site-packages/salt/loader.py", line 1653, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/salt/states/x509.py", line 432, in certificate_managed
    new = __salt__['x509.create_certificate'](testrun=True, **kwargs)
  File "/usr/lib/python2.7/site-packages/salt/modules/x509.py", line 1167, in create_certificate
    setattr(subject, entry, kwargs[entry])
  File "/usr/lib64/python2.7/site-packages/M2Crypto/X509.py", line 260, in __setattr__
    return m2.x509_name_set_by_nid(self.x509_name, self.nid[attr], value)
TypeError: expected string or Unicode object, int found

Installed

openSUSE-Tumbleweed-Kubic
20170909

After successful install of Administration Dashboard node (no license, default settings)
Am unable to connect from another machine to https://kubic_machine_IP_address.
Am able to ping back and forth between the two machines.

Indeed, further investigation based on documentation suggests Velum is deployed on Puma webserver. According to the Puma project, the following is supposed to start/restart the webserver but "command not found"

pumactl restart

Seems that locate and other utilities which might be useful for trying to locate puma are not in the kubic TW repository.

The introduction of the pillar endpoint #315 removes support for lists in pillar data, which used to be available through the external SQL pillar in salt master. For public cloud adaption, we want to store salt cloud specific data in the pillar, which requires a structure like this:

  profiles:
    cluster_node:
      block_device_mappings:
      - DeviceName: /dev/sda1
        Ebs.VolumeSize: 30
      image: ami-12345678
      network_interfaces:
      - AssociatePublicIpAddress: false
        DeviceIndex: 0
        SecurityGroupId: sg-1234abcd
        SubnetId: subnet-1234abcd
      provider: ec2

In this example, network_interfaces is an array consisting of one multi-key dictionary. It would be extremely helpful if structures like those could be served through the velum pillar.

From the start script mentioned in README, resources are pulled from 'docker-testing-registry.suse.de', which is not publicly available; this renders development outside of 'suse.de' impossible.

On the download page for kubeconfig there is a missing space between automatically and read.
It says automaticallyread.

Once the cluster has been deployed, users can currently download the kubeconfig file from the Dahboard. However, some users could also want to download the ca.crt file for connecting to etcd or the master in some other ways. We should show a link for downloading this ca.crt file from the Dashboard.

I seem not to find a way to change the password for the admin user in velum. IS that possible, and if it is - how can it be done?

When clicking the "Bootstrap cluster" button and there are no Minions this error gets raised:

We shouldn't let the user click on a button that will raise an error. I suggest that we disable the button showing a tooltip explaining the reason why it is disabled (no minions present).

The README is completely outdated nowadays, and could use some screenshots of the app itself

technically with kubernetes 1.6.1 the --config flag changed to --kubeconfig
So the kube script will not work with said version.
https://github.com/kubic-project/velum/blob/master/kubernetes/start#L73

Random tests break on random builds for random versions of Ruby. That's pretty bad as a reliable CI is our backbone.

Let's use this issue to track progress on this topic.

Improve the README with more information on what this repo is actually about.

the notifications on the login page, and on the other pages as well need some work.

there are validation messages in form of html popups (email field), but also server sent validation errors from devise, and our backend code.

• we need to know how the notifications need to look like (icons, no icons within etc)
• where they are placed (might be different between pages)
• and then have a look at all pages, test and fix the notifications

Line 16 - 17 are rendered without a space between the words "automatically read".

The proxy settings, while saved in the database do not match the visual page when it is refreshed, in particular:

• Enable it, go to next step and back again -- looks like it is disabled
• Same for "systemwide" proxy selection

The dashboard page appears to query all minions for grains, which, in case a minion is unresponsive, can lead to a salt API call time-out. A Net::ReadTimeout exception is thrown as the log shows, and I assume not caught, and results in the generic "We're sorry, something went wrong" error message.

It seems the timeout for waiting for a response from the minion is 30 seconds:

bash-4.3# time salt '*' grains.get tx_update_failed
ca:
admin:
testnode1:
    Minion did not return. [No response]

real    0m30.671s
user    0m0.804s
sys     0m0.118s

This happens to be the same as the API call timeout, which was recently reduced to 30 secs, and hence is probably now triggered, unlike before. Slightly increasing the API timeout again, or reducing the timeout for the minion query could work around this. About the latter, if I reduce the timeout to 1 second, it still takes about 11 seconds to time out:

bash-4.3# time salt -t 1 '*' grains.get tx_update_failed
admin:
ca:
testnode1:
   Minion did not return. [No response]

real    0m11.863s
user    0m0.567s
sys     0m0.131s

I'm not sure where that 10 second base delay comes from. There's none when all minions are responsive.

Let's document why https://github.com/kubic-project/velum/pull/95/files is at all necessary in the best place we think it belongs.

files cannot be used because this belongs to the 2nd stage of the YaST installation that isn't executed in a CaaSP environment. For this reason we need to use chroot-scripts that will run in the context of the chrooted environment (because of chrooted true).

We should make sure nobody has the temptation somehow to move this back to a files XML attribute in the future and document it properly.

Hi, how can I activate the Velum dashboard in Kubic?

This error gets triggered by Minion.where(role: nil).count > 1 on nodes_controller.rb:25 explicitly, but we should avoid this check here and just rescue from Minion::NotEnoughMinions when calling Minion.assign_roles.

I noticed the product name 'CaaSP' is hardcoded in various places. This name is not to be used (in public), it's 'CaaS Platform' now. Given that this may change again, we better not hardcode it. I would even suggest to not hardcode 'SUSE' either.

Having issues with dependencies might become a problem in the future. We never know. I thought it would be a good idea since we always try to deliver stable products.

I look around and found three services that do some checks:

• https://snyk.io/
• https://hakiri.io/
• https://www.deppbot.com/

They are free for open source projects.

We currently have 3 issues because nokogiri < 1.7.2:

• CVE-2017-5029
• CVE-2016-4738
• CWE-611

Snyk reported those 3 issues and Hakiri and Deppbot the CVE ones only.

What do you think?

The machines in the cluster need to have some reference (ie, IP or DNS name) to the controller node. This is used, for example, for setting the salt minion configuration file with something like master: <%= @controller_node %>.

We are currently setting this @controller_node from the IP/address obtained in Velum (from the remote end IP/name in the client's request), but this can change depending on how the user reached Velum.

We should:

• show this reached name/IP as a suggested value for the @controller_node
• suggest to change it for a better name/IP, warning that it should be reachable by the rest of the machines in the cluster.

From the web application we should:

• Validate that the given no_proxy settings follow the proper format.
• Describe somewhere what's the proper format.

If a user has a system-wide cert installed, selecting "edit" in order to change the name of the cert will not allow the change to be saved until a new file is also selected, despite the cert file contents being visible on-screen. This works as expected in the LDAP connector form, so that behavioral change should be propagated up to system certificates as well.

many things are done in controller instead of model.
Best practice would be to move business logic to a model and just call one or two model methods, from controllers. That is a clear separation of responsibilities

We can make caasp-devenv use the specified PhantomJS version specified on this file, as well as the travis configuration can take it.

It would be good to have a set-pillar somewhere, so we could very easily run docker exec velum set-pillar some-key some-value from the outside...