Thanks for you guys.
Further issue showing up: ( the instance ubuntu 12.04 is from my private
openstack )
vagrant-kubernetes-setup# ./up.sh
---> Step 0: Flush everything
==> minion-2: VM not created. Moving on...
==> minion-1: VM not created. Moving on...
==> master: VM not created. Moving on...
==> discovery: Forcing shutdown of VM...
==> discovery: Destroying VM and associated drives...
==> discovery: Running cleanup tasks for 'file' provisioner...
==> discovery: Running cleanup tasks for 'shell' provisioner...
---> Step 1: Provision vagrant
Bringing machine 'discovery' up with 'virtualbox' provider...
Bringing machine 'master' up with 'virtualbox' provider...
Bringing machine 'minion-1' up with 'virtualbox' provider...
Bringing machine 'minion-2' up with 'virtualbox' provider...
==> discovery: Importing base box 'coreos-alpha'...
==> discovery: Matching MAC address for NAT networking...
==> discovery: Checking if box 'coreos-alpha' is up to date...
==> discovery: Setting the name of the VM:
vagrant-kubernetes-setup_discovery_1420764250924_61392
==> discovery: Clearing any previously set network interfaces...
==> discovery: Preparing network interfaces based on configuration...
discovery: Adapter 1: nat
discovery: Adapter 2: hostonly
==> discovery: Forwarding ports...
discovery: 22 => 2222 (adapter 1)
==> discovery: Running 'pre-boot' VM customizations...
==> discovery: Booting VM...
==> discovery: Waiting for machine to boot. This may take a few minutes...
discovery: SSH address: 127.0.0.1:2222
discovery: SSH username: core
discovery: SSH auth method: private key
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
discovery: Warning: Connection timeout. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
---> Step 2: Setup ssh tunnel into master
The provider for this Vagrant-managed machine is reporting that it
is not yet ready for SSH. Depending on your provider this can carry
different meanings. Make sure your machine is created and running and
try again. Additionally, check the output of `vagrant status` to verify
that the machine is in the state that you expect. If you continue to
get this error message, please view
Any advice? Thanks in adv.
-D
On Thu, Jan 8, 2015 at 1:37 AM, Rajkumar Rajaratnam <[email protected]>
wrote:
> Error says "group id cannot be empty". But we do not have grouping in
> 4.1.0-m3 developer preview. It seems David is trying master branch with M3
> guide. Please follow the document Imesh shared if you trying out master
> branch.
>
> Thanks.
>
> On Thu, Jan 8, 2015 at 2:59 PM, Imesh Gunaratne <[email protected]> wrote:
>
>> Hi David,
>>
>> If you prefer you could tryout the latest Kubernetes implementation in
>> the master branch by refering the following document:
>> https://gist.github.com/imesh/b8f81fac8de39183a504
>>
>> If you need to get 4.1.0-M3 working, please send us the artifacts (json
>> files) that you are using and the carbon log file in stratos server
>> (<stratos-home>/repository/logs/wso2carbon.log) so that we could analyze
>> the problem you are facing.
>>
>> Thanks
>>
>> On Thu, Jan 8, 2015 at 2:51 PM, Rajkumar Rajaratnam <[email protected]>
>> wrote:
>>
>>> Hi David,
>>>
>>> Are you using the code base with 4.1.0-m3 tag or master branch?
>>>
>>> Thanks.
>>>
>>> On Thu, Jan 8, 2015 at 2:23 PM, david hbase <[email protected]>
>>> wrote:
>>>
>>>> Kubernetes workflow is not working!
>>>> <http://mail-archives.apache.org/mod_mbox/stratos-dev/201501.mbox/ajax/%3CCAFgrWyRTAn82oYidBztgYz3rh%2BcSNOLV-TouJz1FePEs2zC8Lg%40mail.gmail.com%3E>
>>>>
>>>> I have following all the steps in the M3, but can not "Registering
>>>> Kubernetes-CoreOS Host Cluster in Stratos"
>>>>
>>>> Error Message is:
>>>> groupid can not be empty.
>>>>
>>>> Please Advice,
>>>> Thanks
>>>>
>>>> -D
>>>>
>>>
>>>
>>>
>>> --
>>> Rajkumar Rajaratnam
>>> Committer & PMC Member, Apache Stratos
>>> Software Engineer, WSO2
>>>
>>> Mobile : +94777568639
>>> Blog : rajkumarr.com
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
>
