The kitchenplanner.net kitchenplanner

The free kitchenplanner.net online planner is a 3D online kitchen planner that can help you with your kitchen planning. The kitchen planner is an easy-to-use software that runs smoothly on your computer without downloading.

It is that easy

After starting, read the introductory text and the instructions and you’ll be guided safely through our virtual kitchen planner. You have many planning options here to ensure that your dream kitchen becomes a reality: The floor plan can be freely designed, no matter what you hope to achieve, whether you’re planning a kitchenette, an L-kitchen, a U-kitchen or a G-kitchen with kitchen counter. The kitchen door and the kitchen windows can be freely placed.

You can make your kitchen dream come true with the versatile selection of kitchen furniture: When it comes to kitchen furniture, the base units are available in two cabinet heights, the tall units in four heights and the wall units or wall units in four heights. In addition, there are equipment cabinets, such as tall cabinets for a refrigerator or an oven, sink and hob cabinets; but also stainless steel refrigerators are available as standalone units.

After entering the furniture, you can design the kitchen design in your kitchen planning. There is an extensive selection of designs, colours and kitchen materials: Design wood kitchens, country kitchens, modern design kitchens, glossy kitchens or timeless classic kitchens — the matching kitchen fronts are available in a variety of colours.

You can go to the 3D view of the kitchen planner under menu item 5. Here you can position the camera yourself and then view and print your kitchen at your own leisure. Also, a view from above is possible, with the 3D kitchen planner taking you to the so-called bird’s eye view.

In addition, you can use our buttons to contact a dealer in your area: Ask your kitchen designer questions about a kitchen professional in your area, make an appointment with one in your area or request an offer for your kitchen planning.

Run kitchen on windows

A Test Kitchen Driver and Transport for Docker.

MAINTAINERS WANTED: This Test-Kitchen driver is currently without a maintainer and has many known issues. If you’re interested in maintaining this driver for the long run including expanding the CI testing please reach out on Chef Community Slack: #test-kitchen. Until such a time that this driver is maintained we highly recommend the kitchen-dokken for Chef Infra testing with Docker containers.

Installation and Setup

Please read the Test Kitchen docs for more details.

Example (Linux) .kitchen.local.yml :

Example (Windows) .kitchen.local.yml :

This driver can determine an image and platform type for a select number of platforms.

This will effectively generate a configuration similar to:

The Docker binary to use.

The default value is docker .

The Docker daemon socket to use. By default, Docker will listen on unix:///var/run/docker.sock (On Windows, npipe:////./pipe/docker_engine ), and no configuration here is required. If Docker is binding to another host/port or Unix socket, you will need to set this option. If a TCP socket is set, its host will be used for SSH access to suite containers.

If you are using the InSpec verifier on Windows, using named pipes for the Docker engine will not work with the Docker transport. Set the socket option with the TCP socket address of the Docker engine as shown below:

The Docker engine must be configured to listen on a TCP port (default port is 2375). This can be configured by editing the configuration file (usually located in C:\ProgramData\docker\config\daemon.json ) and adding the hosts value:

Example configuration is shown below:

If you use Boot2Docker or docker-machine set your DOCKER_HOST environment variable properly with export DOCKER_HOST=tcp://192.168.59.103:2375 or eval «$(docker-machine env $MACHINE)» then use the following:

The Docker image to use as the base for the suite containers. You can find images using the Docker Index.

The default will be computed, using the platform name (see the Default Configuration section for more details).

The isolation technology for the container. This is not set by default and will use the default container isolation settings.

For example, the following driver configuration options can be used to specify the container isolation technology for Windows containers:

The platform of the chosen image. This is used to properly bootstrap the suite container for Test Kitchen. Kitchen Docker currently supports:

• arch
• debian or ubuntu
• amazonlinux , rhel , centos , fedora or oraclelinux
• gentoo or gentoo-paludis
• opensuse/tumbleweed , opensuse/leap , opensuse or sles
• windows

The default will be computed, using the platform name (see the Default Configuration section for more details).

Determines whether or not a Chef Omnibus package will be installed. There are several different behaviors available:

• true — the latest release will be installed. Subsequent converges will skip re-installing if chef is present.
• latest — the latest release will be installed. Subsequent converges will always re-install even if chef is present.
• (ex: 10.24.0 ) — the desired version string will be passed the the install.sh script. Subsequent converges will skip if the installed version and the desired version match.
• false or nil — no chef is installed.

The default value is true .

Disables upstart on Debian/Ubuntu containers, as many images do not support a working upstart.

The default value is true .

Custom command(s) to be run when provisioning the base for the suite containers.

Jenkins running Test-Kitchen via Vagrant. On Windows.

If you’re like me and for various reasons (we’ll not discuss) the physical hardware you have access to right now must run Windows, you might think you’re out of luck as far as getting Jenkins running Test-Kitchen jobs as Joshua Timberman shows in Test Kitchen and Jenkins 1 . But there’s hope if you have patience. I’ll show how I got it working, and I’m looking forward to ideas from you on how to develop better solutions to some of the kludges. There’s not much original material here, but instead of mentioning just my piece of things and linking you coldly to 2 other places for the rest of the info, I figured I would write up as much of the whole experience as I felt up to.

Prerequisites

Windows Add-Ons

It is assumed that you have the following installed. If not, do so.

1. Ruby 1.9.3 from rubyinstallers.org
2. Git 1.8.x for Windows from git-scm.com/download. All commands shown below are run under a “Git Bash” session and not Windows’ cmd.exe! unless explicitly stated as such.
3. Jenkins

Ruby Gems

At this point, you should open a Git-Bash shell and ensure that which gem indicates the one found in the Ruby 1.9.3 install you did previously. For me, that was /c/Ruby193/bin/gem .

Start with: gem install bundler

Then, in the directory containing the cookbook you want to test, create a Gemfile with the following contents:

Run: bundle install

Run: kitchen init

Run: bundle install (yes, again)

Run: kitchen help to ensure Test Kitchen can at least run.

Edit .kitchen.yml to look like the following (configure later how you want):

At this point you should be able to run kitchen test and see something success-like.

Jenkins

The Windows installer for Jenkins is nice in that it configures Jenkins to run as a Windows service. So go get and install that from jenkins-ci.org/windows/latest. Once installed, you should be able to hit http://localhost:8080 and see the Jenkins web UI.

Use the web UI to install the “Git” plugin.

Configure a new Jenkins job. For my case, it looked like the following.

• Source Code Management, Git Repositories, Repository URL: git://github.com/jblaine/resolver.git (use the Git read-only URL to the repo, not SSH, or you’ll have to mess with copying your SSH stuff similar to the problem section below regarding Vagrant)
• Build Triggers, Poll SCM, Schedule: H 9-16/2 * * 1-5
• Excute a Windows Batch Command: kitchen test

And click “Build now” at left to start the troubleshooting process below.

Problem: Jenkins can’t find Git

If you see in your job’s console output that Jenkins is not able to find Git, set the full path to the executable binary (regardless of the setting being called “Installation Directory”) as I did. This is the only thing that worked for me after trying a few other things found on the net.

Oh, and you apparently have to use the old 8dot3 naming. No spaces allowed. What is this, 1999?

Manage Jenkins, Configure System, Git, Git Installations, Installation Directory: C:\Progra

Problem: Vagrant can’t import Boxes

Perhaps this is the next roadblock you hit:

What’s telling here is that Vagrant is looking for boxes in C:\Windows\System32 and not C:\Windows\SysWOW64 . My wildly speculative guess is that this is because Vagrant is a 32-bit application and somehow this ties it to the different directory, even though the Jenkins service is tied to C:\Windows\SysWOW64 by nature of the LocalSystem account.

I’m pretty Windows-guts clueless as you can see. Any explanation you can share here, please do in the comments.

At any rate, we persist. Using a cmd.exe that is run as Administrator, we look around:

Okay, so some VirtualBox stuff happened in C:\Windows\System32 . But we can see that Vagrant has set up shop in C:\Windows\SysWOW64 :

Welp, I’m unaware of any environment variable that would allow me to tell Vagrant to use C:\Windows\SysWOW64\config\systemprofile\.vagrant.d , so I just copied everything over to C:\Windows\System32\config\systemprofile\.vagrant.d .

Success!

Rerunning the Jenkins build, you should now succeed, and at this point you would want to go back into your cookbook’s .kitchen.yml file to actually establish some tests to run in the suites section.

References

2 thoughts on “Jenkins running Test-Kitchen via Vagrant. On Windows.”

You could use mklink to symlink the files together

mklink link target

ie:
mklink “C:WindowsSystem32configsystemprofile.vagrant.d” “C:WindowsSysWOW64configsystemprofile.vagrant.d”

Makes a link in system32 pointing to the file in syswow64, like normal unix symlinks

Kitchen User Documentation

This page is superseded by the InfoCenter

What is Kitchen?

Kitchen is a program that can execute jobs designed by Spoon in XML or in a database repository. Usually jobs are scheduled in batch mode to be run automatically at regular intervals.

Installation

The first step is the installation of Sun Microsystems Java Runtime Environment version 1.5 or higher. You can download a JRE for free at http://www.java.com/.

After this, you can simply unzip the distribution zip-file in a directory of your choice.
In the Kettle directory where you unzipped the file, you will find a number of files.
Under Unix-like environments (Solaris, Linux, OSX, . ) you will need to make the shell scripts executable. Execute these commands to make all shell scripts in the Kettle directory executable:

Launching Kitchen

To launch Kitchen on the different platforms these are the scripts that are provided:

• Kitchen.bat: run Kitchen on the Windows platform.
• kitchen.sh: run Kitchen on Unix platforms and Mac OSX

Kitchen can be run on any platform that has a version of the Java Runtime Environment version 1.5 or higher.

Command line options

These are the command line options that you can use.

IMPORTANT NOTES:
On Windows system, the use of the minus («-«) in the options causes problems as well as the equal sign («=»). Because of this, from version 2.2.2 on, you can also use this format or any combination of /,- and :,=
Fields in italic represent the values that the options use.
It’s important that if spaces are present in the option values, you use quotes or double quotes to keep them together. Take a look at the examples below for more info.

Below are the valid options.

Display version information

This option displays the version of the Kettle core library (kettle.jar).
The build version number and build date are shown as well.

Named parameters

You can set the value of a named parameter, for example: -param:FOO=value

List the named parameters (their name, default value and description) that are defined in the specified job.

Launch XML File

This option runs the job defined in the XML file. (.kjb : Kettle Job)

Specify named parameters

Specifies the value of a named parameter. For example:»-param:MASTER_HOST=192.168.1.3″ «-param:MASTER_PORT=8181»

Set the logging file

Specifies the log file. The default is the standard output.

Set the logging level

The level option sets the log level for the job that’s being run.
These are the possible values:

• Error: Only show errors
• Nothing: Don’t show any output
• Minimal: Only use minimal logging
• Basic: This is the default basic logging level
• Detailed: Give detailed logging output
• Debug: For debugging purposes, very detailed output.
• Rowlevel: Logging at a row level, this can generate a lot of data.

Choose a repository

Connect to the repository with name «Repository name».
You also need to specify the options -user, -pass, -dir and -job.
You can also specify this option in the form of environment variable KETTLE_REPOSITORY.

Set the repository user name

This is the username with which you want to connect to the repository.
You can also specify this option in the form of environment variable KETTLE_USER.

Set the repository password

The password to use to connect to the repository
You can also specify this option in the form of environment variable KETTLE_PASSWORD.

Select the repository job to run

Use this option to select the job to run from the repository. Please also select the directory with the «-dir» option.

List the directories in the repository

Print a listing of all the sub-directories in the repository directory specified with the option «-dir».

Set the repository directory

Specifies the directory in the repository to use. Repository directories are specified like this:

• The root directory: /
• A subdirectory: /production/Dimensions

From version 2.2.2 on, a / (slash) is used to separate directories on all platforms.

List the repository jobs

Show a list of all the jobs in the repository directory specified with the option «-dir».

List the available repositories

Print a listing of all the defined repositories.

Don’t log in to the repository

If you have set environment variables KETTLE_REPOSITORY, KETTLE_USER, KETTLE_PASSWORD, you can prevent Kitchen from logging into the repository. For example if you want to launch a job from an XML file.

Please make sure that you are positioned in the Kettle directory before running the samples below. If you put these scripts into a batch file or shell script, simply do a change directory to the installation directory:

If Kettle was installed on windows on the D:\ drive

If Kettle was installed in the /product directory on a Unix system:

Run a job from file

This example runs a job from file on a windows platform:

This example runs a job from file on a Linux box:

Run a job from Repository

This example runs a job from the repository on a windows platform:
(Enter on a single line without returns. )

Redirecting output

If you don’t want the output of the file to appear on the screen but rather be put into a log file, you can use redirection.

This example adds the Kitchen output to an ever-growing log file:

This example writes the Kitchen output to a file that gets overwritten every time:

Return codes

Kitchen returns an error code based on how the execution went:

• 0 : The job ran without a problem.
• 1 : Errors occurred during processing
• 2 : An unexpected error occurred during loading / running of the job
• 7 : The job couldn’t be loaded from XML or the Repository
• 8 : Error loading steps or plugins (error in loading one of the plugins mostly)
• 9 : Command line usage printing

Scheduling

Schedule a job on windows

The best way to go at it is to test the command first at the dos prompt.
Then you can use the windows scheduler to launch this command.
Windows versions since Windows 2000 have a GUI for doing this accessible through the control panel. However it’s also possible to use the command line to do this:

To see a list of the scheduled commands simply type:

Schedule a job on Unix

First create a shell script that runs all the jobs you need. Then you can schedule this script to run.
On Unix like systems the easiest way to schedule a command is by using the «cron table». You can do this by entering the following command:

Then you can enter the time at which the command needs to be run as well as the command on a single line in the text file that is presented.
The first options are:

• Minute: The minute of the hour, 0-59
• Hour: The hour of the day, 0-23
• Month day: The day of the month, 1-31
• Month: The month of the year, 1-12
• Weekday: The day of the week, 0-6, 0=Sunday

You can specify more then 1 number for each of these values by separating 2 number with a hyphen -. This means an inclusive number range. If you separate the number by commas (,), it means distinct values. If you use * instead of a number, it means: every possible hour, minute, day, month or weekday.

So, if you want to update the dimensions every hour, at 15 and 45 minutes past the hour during the weekdays, you might enter these lines in a crontab: