I am following the CoreOS in Action book (and also CoreOS online instruction) to bring up a 3-node cluster using Vagrant and VirtualBox on MacOS.
It all goes fine, machines come up & running and I can ssh into one of them, but it looks like the boxes brought up are missing fleetctl (which makes no sense, as it's such a core component of CoreOS):
$ vagrant ssh core-01 -- -A
Last login: Thu Mar 1 21:28:58 UTC 2018 from 10.0.2.2 on pts/0
Container Linux by CoreOS alpha (1702.0.0)
core#core-01 ~ $ fleetctl list-machines
-bash: fleetctl: command not found
core#core-01 ~ $ which fleetctl
which: no fleetctl in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/bin)
What am I doing wrong?
I have changed the number of instances to 3, created a new "discovery token URL" and updated the user.data file; Googling around I seem to be the one and only person having this problem.
Thanks in advance for any suggestions you may have!
PS -- yes, I have tried (several times!) to vagrant destroy and rebuild the cluster: even nuked the repo and re-cloned it. Same issue every time.
The answer is going to make you a bit sad, here it is:
CoreOS no longer support fleet. It's gone. Ciao :(
https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html
To this end, CoreOS will remove fleet from Container Linux on February 1, 2018, and support for fleet will end at that time. fleet has already been in maintenance mode for some time, receiving only security and bugfix updates, and this move reflects our focus on Kubernetes and Tectonic for cluster orchestration and management.
You are using Coreos 1702.0.0, fleet has been removed since Coreos 1675.0.1 https://coreos.com/releases/
Related
Trying again & again with all required steps completed but cluster Installation when install selected Parcels, always shows every host with bad health. setup never completed at full.
i am installing cm 5.5 on CentOS 6.7 using virtualbox.
The Error
Host is in bad health cm.feuni.edu
Host is in bad health dn1.feuni.edu
Host is in bad health dn2.feuni.edu
Host is in bad health nn1.feuni.edu
Host is in bad health nn2.feuni.edu
Host is in bad health rm.feuni.edu
above error are shown on step 6 where setup says
The selected parcels are being downloaded and installed on all the hosts in the cluster
in previous step 5 all hosts were completed with heartbeat checks in the end
memory distributions
cm 8GB
all others with 1GB
i could not find proper answer anywhere else. What reason could be for the bad health?
I don't know if it will help you...
For me, after a few days I struggled with it,
I found the log files (at )
It had a comment there is a mismatch of the guid,
so I uninstalled everything from both machines (using the script they give,/usr/share/cmf/uninstall-cloudera-manager.sh , yum remove 'cloudera-manager-*' and deletion of every directory related to cloudera I found...)
and then removed the guid file:
rm /var/lib/cloudera-scm-agent/cm_guid
Afterwards I re-installed everything, and that fixed that issue for me...
I read online that there can be issues with the hostname and things like that, but I guess that if you get to this part of the installation, you already fixed all the domain/FDQN/hosname/hosts issues.
It saddens me there is no real manual/FAQ for this product.. :(
Good luck!
I faced the same problem. This is my solution:
First I edited config.ini
$ nano /etc/cloudera-scm-agent/config.ini
so that the hostname where the same as the command $ hostname returned.
then I restarted the agent and the server of cloudera:
$ service cloudera-scm-agent restart
$ service cloudera-scm-server restart
then in cloudera manager I deleted the cluster and added again. The wizard continued to run normally.
This is my first attempt to install and use Kubernetes. I am trying to install an environment on Mac for developing my own apps and deploying them for test locally with Kubernetes. I am familiar with using Vagrant, VirtualBox and Docker for the same purpose. When I saw this page https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/vagrant.md I assumed it would be trivial. I executed these lines:
export KUBERNETES_PROVIDER=vagrant
curl -sS https://get.k8s.io | bash
This created a master VM and a Minion, but Kubernetes seems to have failed to start on the master. On the master /var/log/salt/master is full of python Traceback errors, like this:
2015-07-17 22:14:42,629 [cherrypy.error ][INFO ][3252] [17/Jul/2015:22:14:42] ENGINE Started monitor thread '_TimeoutMonitor'.
2015-07-17 22:14:42,736 [cherrypy.error ][ERROR ][3252] [17/Jul/2015:22:14:42] ENGINE Error in HTTP server: shutting down
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cherrypy/process/servers.py", line 187, in _start_http_thread
self.httpserver.start()
File "/usr/lib/python2.7/site-packages/cherrypy/wsgiserver/wsgiserver2.py", line 1824, in start
raise socket.error(msg)
error: No socket could be created
Vagrant is version 1.7.3. VirtualBox is version 4.3.30
Have I made an obvious stupid mistake?
I don't yet know the fix but I know what is going wrong since it happens to me as well:
OS X 10.10.3
Vagrant 1.7.4
VirtualBox 4.3.30
Kubernetes 1.0.1
When I run the default configuration of this (which creates one "master" and one "minion" VM) I see that the static IP address is not being assigned to the "eth1" interface, and I also see that the Salt API server is sitting in what appears to be an infinite retry loop because it is trying to listen on that IP address.
Also, the following message happened during boot:
[vagrant#kubernetes-master ~]$ dmesg | grep eth1
[ 9.321496] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
So basically, the static IP address didn't get assigned because eth1 wasn't ready when the system first booted, and Salt is waiting for it to get assigned.
I could fix this after boot by sshing to the box using "vagrant ssh" and running the command:
sudo /etc/init.d/network restart
on each host.
This "fixes" eth1 by assigning the static IP address, and after that Salt begins to do its thing, installs Docker, boots various containers, and so on.
What I don't know is how to make this work every time without manual intervention. It appears to be some sort of a race condition between Vagrant and VirtualBox.
If you just want to kick the tires with Kubernetes, I'd recommend installing boot2docker and then following the Running kubernetes locally via Docker getting started guide. Once you are comfortable interacting with the Kubernetes API and want a more complex local setup, you can then work on installing Vagrant.
If the Vagrant instructions aren't working, you should also feel free to file a bug in the github repository.
The tutorial pointed by Robert is realy easy to run. Just change the version to 0.21.2 (maybe 0.21.3 works too).
Else, if you prefer a vagrant solution, try with pires cluster on vagrant. It runs with almost nothing to change.
Running Kubernetes inside VirtualBox requires 4 networks and some adjustments to the configuration:
The VirtualBox HOST ONLY network will be the network used to access the Kubernetes master and nodes from the Mac or PC.
The NAT Network to download packages from the Internet.
The internal connections between Kubernetes PODs uses a tunnel network TUN
The Kubernetes Cluster IP Network is a private IP range used inside the cluster to give each Kubernetes service a dedicated IP
Vagrantfile needs to pass the node public IPs to the Ansible roles that configure Kubernetes to set KUBELET_EXTRA_ARGS environment variable with the public IP of each node (required for reading logs using kubectl).
NodePort needs to be used to publish applications running inside the Kubernetes cluster as Load Balancers are not available in VirtualBox.
See the full example and download the code at Building a Kubernetes Cluster with Vagrant and Ansible (without Minikube), it has been tested in Ubuntu but should work on a MAC as well.
I really don't understand here when I entered vagrant ssh for the first time in the terminal. I'm using laravel Homestead.
output was:
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-30-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information disabled due to load higher than 1.0
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
Last login: Fri Oct 3 01:24:38 2014 from 10.0.2.2
I really don't understand:
Last login: Fri Oct 3 01:24:38 2014 from 10.0.2.2 //because its first time I entered vagrant ssh
and this:
System information disabled due to load higher than 1.0
The last login you see may come from when the Vagrant Box was originally created. For example I just launched a new Vagrant VM based on hashicorp/precise64 and the "last login" showed as September 2012. Subsequent logins will show the last time that you logged in.
Regarding the system information being disabled, see this ServerFault question: System information disabled due to load higher than 1.0 amazon ec2.
Both of the above can safely be considered normal behavior.
I don't want to run provision on my vagrant (VirtualBox) machine. I want to vagrant up and the machine marked as "provisioned", even though actually the machine is not provisioned yet. I just want to mark it as "provisioned".
Is this possible? Perhaps, is there some file i can edit in .vagrant?
It seems vagrant looks for the existence of a file :
.vagrant/machines/[machine-name]/[provider]/action_provision
However, it seems that there is more logic to that in
[vagrant-install-path]/lib/vagrant/action/builtin/provision.rb
You can start investigating from there to what exactly vagrant needs to consider a machine as provisioned.
I personally didn't have time to look more into it since I fixed my issue with a workaround :).
Started the machine with vagrant up, so that chef_solo provisioner started running, and then hitting CTRL+C twice (so that chef says "exiting without cleanup") helped making the VM be marked as provisioned, so that it could be started without the --no-provision flag.
Hoping this comes of any help.
Using a free 'micro' instance from Amazon to fire up a quick demo of MarkLogic. The rpm installs fine with no errors.
Some information that may be helpful:
[user#aws ~]$ rpm -qa | grep release
redhat-release-server-6Server-6.4.0.4.el6.x86_64
[user#aws ~]$ rpm -qa | grep MarkLogic
MarkLogic-7.0-1.x86_64
Starting the MarkLogic server for the very first time shows this:
[user#aws ~]$ sudo /etc/init.d/MarkLogic start
Initialize Configuration
Region: us-west-2 ML_NAME:
Set configuration: MARKLOGIC_ZONE="us-west-2c"
Instance is not managed
Waiting for device mounted to come online : /dev/xvdj
And here it sits with no other messages anywhere including /var/opt/MarkLogic/Logs which doesn't exist yet.
Even though Micro instances aren't officially supported, you can usually start one up. But, reports are that you will be quickly wishing you didn't.
That said, see the precise instructions at http://developer.marklogic.com/products/aws and, in particular, a disk at mounting /dev/sdf ; the server init script will wait forever to come up if you don't do that.
If the above didn't help, I've dug into the RPM enough to discover some issues on AWS.
For one, they use some sysconfig scripts to detect if they're on AWS. If you're running MarkLogic 6, these sysconfigs have a hardcoded drive and will wait indefinitely since it probably won't exist. Yours is 7, and still has some issues on AWS. To bypass this, you can make a /usr/bin/is-ec2.sh that contains:
#!/bin/bash
exit 1
That will prevent it from doing any ec2 detection. More details can be found on my write-up at this github post