tag:blogger.com,1999:blog-8789296710216751709Tue, 29 Nov 2016 15:26:06 +0000openSUSEOpenStackpackagingSUSE CloudSUSESUSEConglibcCloudSLEdocumentationosc11CrowbargcckernelSecure BootUEFIbtrfscommunitydebugdesktoppythonsecuritytranslationAJ's Open Source, openSUSE and SUSE Ramblingshttp://jaegerandi.blogspot.com/noreply@blogger.com (Andreas Jaeger)Blogger51125tag:blogger.com,1999:blog-8789296710216751709.post-3976244720746569541Fri, 12 Aug 2016 17:33:00 +00002016-08-12T19:33:57.598+02:00OpenStackDocument Binary Package Dependencies - not only for OpenStack Python Packages<div class="ace-line" id="magicdomid66"><span class="">Python developers record their dependencies on other Python packages in requirements.txt and test-requirements</span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6">.txt</span><span class="">. But some packages havedependencies outside of python and we should document thesedependencies as well so that operators, developers, and CI systems</span></div><div class="ace-line" id="magicdomid67"><span class="">know what needs to be available for their programs.</span></div><div class="ace-line" id="magicdomid68"><br /></div><div class="ace-line" id="magicdomid73"><span class=""><a href="http://docs.openstack.org/infra/bindep/" target="_blank">Bindep</a> is a solution to this, it allows</span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6"> a repo</span><span class=""> to document binarydependencies in a single file. It even </span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6">enablies specification</span><span class=""> </span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6">of which</span><span class=""> distribution the package</span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6"> belongs to</span><span class=""> - Debian, Fedora, Gentoo, openSUSE, RHEL, SLES and Ubuntu have different package names - and allows profiles, like a test profile.</span></div><div class="ace-line" id="magicdomid74"><br /></div><div class="ace-line" id="magicdomid76"><span class="">Bindep is </span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6">one</span><span class=""> of the tools the OpenStack Infrastructure team has written and maintains. It is in use by already over 130 repositories.</span></div><div class="ace-line" id="magicdomid77"><br /></div><div class="ace-line" id="magicdomid80"><span class="">For better bindep adoption, </span><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">in the just released bindep 2.1.0</span><span class=""></span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6"> we have changed the </span><span class="">name of the default file used by bindep from other-requirements.txt to bindep.txt and have pushed <a href="https://review.openstack.org/#/q/branch:master+topic:bindep-mv">changes</a> to master branches of repositories for this.</span></div><div class="ace-line" id="magicdomid81"><br /></div><div class="ace-line" id="magicdomid87"><span class="">Projects are encouraged to create their own bindep files. Besides documenting what is required, it also gives a speedup in running tests since you install only what you need and not all packages that some other project might need and </span><span class="author-a-z122zgarlz75zz82zf1tz68zz87zk6z65z6">are installed&nbsp;</span><span class=""> by default. Each test system comes with a basic installation and then we either add the repo defined package list or the large default list.</span></div><div class="ace-line" id="magicdomid88"><br /></div><div class="ace-line" id="magicdomid88">In the OpenStack CI infrastructure, we use the "test" profile for installation of packages. This allows projects to document their run time dependencies - the default packages - and the additional packages needed for testing.</div><div class="ace-line" id="magicdomid88"><br /></div><div class="ace-line" id="magicdomid90"><span class="">Be aware that bindep is not used by devstack based tests, those have their own way to document dependencies.</span></div><div class="ace-line" id="magicdomid378"><br /></div><div class="ace-line" id="magicdomid548"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">A side effect is that your tests run faster, since they have less packages to install. A Ubuntu Xenial test node installs 140 packages and that can take between 2 and 5 minutes. With a smaller bindep file, this can change.</span></div><div class="ace-line" id="magicdomid550"><br /></div><div class="ace-line" id="magicdomid549">Let's look at the log file for a normal installation with using the default dependencies:</div><div class="ace-line" id="magicdomid552"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">2 upgraded, 139 newly installed, 0 to remove and 41 not upgraded</span></span></div><div class="ace-line" id="magicdomid555"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">Need to get 148 MB of archives.</span></span></div><div class="ace-line" id="magicdomid558"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">After this operation, 665 MB of additional disk space will be used.</span></span></div><div class="ace-line" id="magicdomid595"><br /></div><div class="ace-line" id="magicdomid652"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">Compare this with the openstack-manuals repostiry that uses bindep - this example was 20 seconds and not minutes:</span></div><div class="ace-line" id="magicdomid562"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z"></span><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">0 upgraded, 17 newly installed, 0 to remove and 43 not upgraded.</span></span></div><div class="ace-line" id="magicdomid593"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">Need to get 35.8 MB of archives.</span></span></div><div class="ace-line" id="magicdomid594"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><span class="author-a-fz84z1daz76zxyz74zxupz72z3z81zz81z">After this operation, 128 MB of additional disk space will be used.</span></span></div><div class="ace-line" id="magicdomid547"><br /></div><div class="ace-line" id="magicdomid96"><span class="">If you want to learn more about bindep, read the<a href="http://docs.openstack.org/infra/manual/drivers.html#package-requirements" target="_blank"> Infra Manual on package requirements</a>&nbsp; </span></div><div class="ace-line" id="magicdomid96"><span class=""></span><span class="">or the </span><span class=" url"><a href="http://docs.openstack.org/infra/bindep/">bindep manual.</a></span></div><div class="ace-line" id="magicdomid96"><span class=" url">&nbsp;</span></div><div class="ace-line" id="magicdomid96"><div class="ace-line" id="magicdomid93"><span class="">If you have questions about bindep, feel free to ask the Infra team on #openstack-infra.</span></div><span class=" url">&nbsp;</span></div><div class="ace-line" id="magicdomid97"><span class=" url">Thanks to Anita for reviewing and improving this blog post and to the OpenStack Infra team that maintains bindep, especially to Jeremy Stanley and Robert Collins.</span></div>http://jaegerandi.blogspot.com/2016/08/document-binary-package-dependencies.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-7274885462251534081Thu, 11 Aug 2016 17:00:00 +00002016-08-11T19:00:16.530+02:00OpenStackTesting OpenStack with always updating python package versionsWith any software package, you will need additional packages to run it. Often, there's a tight coupling: The software package will only run with specific other package versions. This dependency information is sometimes found in README files, in code, or in package metadata. If you install the package, you need to figure out the dependency and<br />handle it properly.<br /><br />The Python package installer pip uses a list of requirements to install dependent Python packages. This list not only contains the name of packages but also limits which versions to use, or not to use.<br />In OpenStack we handle these dependencies in a global requirements list and use it for most of the repositories. During initial testing a specific package version is tested but at a later point, another one might be used, or during deployment again another one.<br /><br />To document what was tested, give guidenance for deployment, and help to figure out breakage by upstream projects, the OpenStack requirements projects maintains a set of constraints with packages pinned to specific package versions that are known to be working.<br />These are in the upper-constraints.txt file.<br /><br />Devstack already handles upper-constraints.txt when installing packages and I'm happy to say that tox, the Python testing framework used in OpenStack, can now handle upper-constraints as well everywhere.<br /><br /><br /><h2>Constraints for tox based jobs</h2>To use constraints, change in tox.ini the install command to:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt} {opts} {packages}</span><br /><h3>Caveat</h3>Note that constraints are used for the installation of each packages, so if you want to install a package from source and have constraints for a specific version in the constraints file, it will not work. This happens with some of&nbsp; the OpenStack python client packages: When they install their dependencies, those might<br />have a dependency on the client package itself. And this then will cause an error since the client package should get installed from source.<br /><br />So, projects need to remove the constraints file for themselves if they run into this. Packages like python-novaclient and python-glanceclient therefore use a wrapper (tools/tox_install.sh) as<br />install command to edit the constraints file first and remove their own project from it.<br /><br />Also, be aware that this only for those jobs that have been enabled for it in the project-config repository. It's done for all the generic tox enabled targets and should be done for all custom tox targets as well. Some repositories are not using constraints like project-config<br />itself, so those jobs are not set up.<br /><h3>Constraints for DevStack jobs</h3>Devstack-gate takes care using constraints, there is nothing for a repository to do to honor constraints.<br /><br />Check the devstacklog.txt file, if constraints are in use it will use lines like:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Collecting oslo.context===2.7.0 (from -c /opt/stack/new/requirements/upper-constraints.txt (line 204))</span><br /><h3>References</h3>To learn more about constraints read the <a href="http://docs.openstack.org/developer/requirements/" target="_blank">requirements documents.</a> There is also a <a href="https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html" target="_blank">spec</a> that explains all the steps that where needed for this.<br /><br /><br /><h3>Thanks</h3>As usual in OpenStack, such work is a team work of many people. I'd like to thank especially:<br /><br /><ul><li>Robert Collins 'lifeless': For writing the initial spec, implementation work, and giving guideance on many of these details.</li><li>Sean Dague: He was bold enough to try using constraints everywhere and showing us where it failed.</li><li>Sachi King for making zuul-cloner usable in the post queue. This was a missing part in the last months.</li><li>The OpenStack infra team for many reviews and design discussions - especially to Jeremy Stanley and Jim Blair.</li></ul>http://jaegerandi.blogspot.com/2016/08/testing-openstack-with-always-updating.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-6571930349871151651Mon, 08 Feb 2016 18:42:00 +00002016-02-08T19:42:12.622+01:00OpenStackTemplates in OpenStack's ZuulThis is a followup to my post&nbsp; "<a href="http://jaegerandi.blogspot.de/2016/02/creating-new-test-jobs-in-openstack-ci.html" target="_blank">Creating new test jobs in OpenStack CI</a>". Last time I covered the basic setup of jobs by Jenkins and Zuul. Since many OpenStack projects run the same jobs, the Zuul developers have introduced templates to easily group and reuse these jobs.<br /><br />Let's look at one common example, it's the <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python-jobs</span> template. Like all examples in this article, it is defined in file <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml" target="_blank">zuul/layout.yaml</a> in the <a href="http://git.openstack.org/cgit/openstack-infra/project-config" target="_blank">openstack-infra/project-config</a> repository and to use it, you need to edit the same file.<br /><br /><h4>Defining your own templates</h4>Since you now know how to use a template, let's explain how they really look like. A template consists of a name, definitions for which jobs should run in which queue and allows to substitute the name of the repository in the job, so <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">{name}</span> gets replaced by your repository, in the example by <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">amazing-repo.</span><br /><br />Let's look at the python-jobs template:<span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><br /></span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"></span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><br /></span><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: python-jobs<br />&nbsp;&nbsp;&nbsp; check:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-pep8'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-docs'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-python27'<br />&nbsp;&nbsp;&nbsp; gate:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-docs'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-pep8'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-python27'<br />&nbsp;&nbsp;&nbsp; post:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - '{name}-branch-tarball'</span><br /><br />The template has the name <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python-jobs</span>, adds three jobs to the check queue and the same jobs also to the gate queue. An additional job is added to the post queue. Jobs in the check get queue get triggered when a change gets submitted, jobs in the gate queue get triggered when a change gets approved by a core reviewer and jobs in the post queue get triggered after a change has merged.<br />If you are adding the same class of jobs to several repositories, create a template for it. A template can contain of a single job that is associated with one queue, or contain several jobs in several queues like the example above.<br /><br /><h4>Using a template<span style="font-family: &quot;Courier New&quot;,Courier,monospace;"></span></h4>So, if your project amazing-project wants to reuse the python-jobs template as is, just add it as template:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: openstack/amazing-repo<br />&nbsp;&nbsp;&nbsp; template:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: python-jobs</span><br />You can also limit, on which branches those are jobs are triggered. For example, to run the docs job only on <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">stable/liberty</span> and newer branches, you can add a condition:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: gate-amazing-project-docs<br />&nbsp;&nbsp;&nbsp; branch: ^(?!stable/kilo).*$</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"></span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><br /></span>So, instead of saying run on liberty and newer, we block it on older supported branches, in this case kilo is the only older supported branch.<br /><br />If you're introducing jobs, best practice is to add them first to the experimental queue, and then add them as non-voting, and only finally as voting. In this case, the templates do not help you at all for the first two steps, you have to look at their definition and add them manually.<br /><br />First step, using the jobs in the experimental queue:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: openstack/amazing-repo<br />&nbsp;&nbsp;&nbsp; template:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: noop-jobs<br />&nbsp;&nbsp;&nbsp; experimental:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-pep8<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-docs<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-python27</span><br /><br />Note that we use <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">noop-jobs</span> as a template, so that both check and gate queue have at least one job. The <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">noop</span> jobs do nothing but are important since Zuul requires at least one job to run with success, otherwise you will not be able to merge anything.<br /><br />With this definition, you can now submit a change and add as review comment "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">check experimental</span>" and the jobs are run and the results are reported.<br /><br />Later, the manually triggered jobs run fine, so it's time to run them on each change but keep them non-voting to not block any merges: <br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: gate-amazing-repo-docs<br />&nbsp;&nbsp;&nbsp; voting: false<br /><br />&nbsp; - name: gate-amazing-repo-pep8<br />&nbsp;&nbsp;&nbsp; voting: false<br /><br />&nbsp; - name: gate-amazing-repo-python27<br />&nbsp;&nbsp;&nbsp; voting: false<br />....<br /><br />&nbsp; - name: openstack/amazing-repo<br />&nbsp;&nbsp;&nbsp; template:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp;&nbsp;&nbsp; check:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-pep8<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-docs<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-python27<br />&nbsp;&nbsp;&nbsp; gate:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - noop</span><br />Here we added the <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">noop</span> job to the gate since otherwise no job would run in the gate and Zuul requires at least one job to run.<br /><br />Once the jobs all run fine, you can add them to the gate as well - and for that case, let's finally use the template:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: openstack/amazing-repo<br />&nbsp;&nbsp;&nbsp; template:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: python-jobs</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"></span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"><br /></span><h4>Defining your own templates</h4>Since you now know how to use a template, let's explain how they really look like. A template consists of a name, definitions for which jobs should run in which queue and allows to substitute the name of the repository in the job, so <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">{name}</span> gets replaced by your repository, in the example by <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">amazing-repo.</span><br />Let's review the python-jobs template again:<span style="font-family: &quot;Courier New&quot;,Courier,monospace;"> </span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;"></span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp;</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">&nbsp; - name: python-jobs<br />&nbsp;&nbsp;&nbsp; check:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-pep8'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-docs'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-python27'<br />&nbsp;&nbsp;&nbsp; gate:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-docs'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-pep8'<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 'gate-{name}-python27'<br />&nbsp;&nbsp;&nbsp; post:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - '{name}-branch-tarball'</span><br /><br />The template has the name <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python-jobs</span>, adds three jobs to the check queue and the same jobs also to the gate queue. An additional job is added to the post queue. Jobs in the check get queue get triggered when a change gets submitted, jobs in the gate queue get triggered when a change gets approved by a core reviewer and jobs in the post queue get triggered after a change has merged.<br />If you are adding the same class of jobs to several repositories, create a template for it. A template can contain of a single job that is associated with one queue, or contain several jobs in several queues like the example above.<br /><h4>References</h4>For more information about templates, you can look at the file <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml" target="_blank">zuul/layout.yaml</a> on definitions and usage.&nbsp; Zuul has been written for OpenStack CI and has its own <a href="http://docs.openstack.org/infra/zuul" target="_blank">documentation</a>. For information about Zuul's OpenStack instance, read the <a href="http://docs.openstack.org/infra/system-config/zuul.html" target="_blank">Project Config Infrastructure page about Zuul</a>. The best starting place learn about using the OpenStack CI infrastructure is the <a href="http://docs.openstack.org/infra/manual/" target="_blank">Infra Manual</a>.<br /><h4>Followup? </h4>If you liked this post and like to learn more about OpenStack CI, please leave a comment with details.<br /><br />http://jaegerandi.blogspot.com/2016/02/templates-in-openstacks-zuul.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-2190550489619050696Sat, 06 Feb 2016 13:17:00 +00002016-02-08T19:43:27.785+01:00OpenStackCreating new test jobs in OpenStack CIReviewing patches for the OpenStack CI infrastructure, there's one piece that often confuse contributors: The question how Zuul and Jenkins configuration are working together.<br /><br />While we have the<a href="http://docs.openstack.org/infra/manual/c" target="_blank"> Infra Manual</a> with a whole page on <a href="http://docs.openstack.org/infra/manual/creators.html" target="_blank">how to create a project</a> - and I advise everyone to read it - , let me try to tackle the specific topic of adding new jobs from a different angle.<br /><br />What we're discussing here are job, or tests, that are run. Jenkins actually runs these jobs. <a href="http://docs.openstack.org/infra/zuul" target="_blank">Zuul</a> watches for changes in gerrit (URL for OpenStack is <a href="https://review.openstack.org/" target="_blank">review.openstack.org</a>) to trigger the appropriate jobs so that Jenkins runs them.<br /><br /><br />To understand the relationship between these two systems, let's try as an analogy programming languages: As a developer, you create a library of functions that do a variety of actions. You also write a script that uses this library to execute them. Jenkins can be considered the library of test functions. But just defining these is not enough, you have to call them. Zuul takes care of calling them, so in the analogy is your script.<br /><br />So, to actually get a job running for a repository, you first need to define it in the Jenkins "library", and then you trigger its invocation in Zuul. You can also add certain conditions to limit when the job runs or whether it is voting.<br /><br />If you dig deeper into Jenkins and Zuul, keep in mind that these are two different programming languages, even if both use YAML as format. Jenkins runs jobs and these are defined as text files using the <a href="http://docs.openstack.org/infra/jenkins-job-builder" target="_blank">Jenkins job builder</a>. To define them, you can write a job, or use a job-template and instantiate it, or group several job-template in a job-group and instantiate that job-group to create with a few lines many jobs. Zuul uses these jobs and has as syntactic sugar templates to reuse jobs and the queues they run in.<br /><br />Let's look at a simple examples, adding a new docs job to your repository called <span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">amazing-repo</span>:<br /><br /><ol><li>Check out the <a href="http://git.openstack.org/cgit/openstack-infra/project-config/" target="_blank"><span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">project-config</span></a> repository and make it ready for patch submission like creating a branch where you work on.</li><li>Since for the docs job already a template exists, you can reuse it. It is called'<span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">gate-{name}-docs</span>', so add it to your repository in file <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/projects.yaml" target="_blank">jenkins/jobs/projects.yaml:</a> <br /><span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">- project:<br />&nbsp; name: amazing-repo<br />&nbsp; node: bare-trusty<br />&nbsp; jobs:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-{name}-docs</span></li><li>Now define how to trigger the job. Edit file <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml" target="_blank">zuul/layout.yaml</a> and update your repository entry to add the job:<br /><br /><span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">- name: openstack/amazing-repo<br />&nbsp; template:<br />&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp; check:<br />&nbsp;&nbsp;&nbsp; - gate-amazing-repo-docs<br />&nbsp; gate:<br />&nbsp;&nbsp;&nbsp; - gate-amazing-repo-docs</span><br />This adds the job to both the check and gate queue. So, it will notonly be run when a patch is initially submitted for review in the check queue but also after a patch gets approved in the gate queue. Since your tree might be different when you submitted a change and when it merges, we run jobs in both situations so that the tree istested exactly as it merges.</li><li>Let's go one step back: Your repository is not ready yet to havethe docs job voting, so you only want to run it as non-voting.<br />In that case add a condition in the jobs section of zuul/layout.yaml:<br /><br /><span style="font-family: &quot;courier new&quot; , &quot;courier&quot; , monospace;">- name: gate-amazing-repo-docs<br />&nbsp;&nbsp;&nbsp; voting: false</span><br /><br />And in your repository, only add it to the check queue. Non-voting jobs should not be in the gate, they get ignored completely and just waste resources:<br /><br />&nbsp; - name: openstack/amazing-repo<br />&nbsp;&nbsp;&nbsp; template:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - name: merge-check<br />&nbsp;&nbsp;&nbsp; check:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - gate-amazing-repo-docs<br />&nbsp;&nbsp;&nbsp; gate:<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - ...</li></ol><br />So, these are simple jobs. Stay tuned for a followup article that will cover how to use templates in Zuul - and how to modify your repository in the context of templates.<br /><br />Thanks to Doug Fish for reviewing the text and giving suggestions on how to improve it - and urging me to write a follow-up.<br /><br />P.S. Follow-up article is called "<a href="http://jaegerandi.blogspot.de/2016/02/templates-in-openstacks-zuul.html" target="_blank">Templates in OpenStack's Zuul</a>". http://jaegerandi.blogspot.com/2016/02/creating-new-test-jobs-in-openstack-ci.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-8084323074041230103Fri, 18 Apr 2014 11:58:00 +00002014-04-18T13:58:05.904+02:00CloudOpenStackopenSUSEOpenStack Icehouse released - and available now for openSUSE and SUSE Linux Enterprise<a href="http://www.openstack.org/software/icehouse" target="_blank">OpenStack Icehouse</a> has been released and packages are available for openSUSE 13.1 and SUSE Linux Enterprise 11 SP3 in the <a href="http://build.opensuse.org/" target="_blank">Open Build Service</a>.<br />The packages are developed in the <a href="https://build.opensuse.org/project/show?project=Cloud:OpenStack:Icehouse" target="_blank">Cloud:OpenStack:Icehouse</a> project and can be download from the openSUSE download server:<br /><ul><li>For openSUSE 13.1, you can add the Icehouse repository with:<br /><pre class="screen">zypper addrepo -f obs://Cloud:OpenStack:Icehouse/openSUSE_13.1 Icehouse</pre></li><li>For SLES 11 SP3, add the icehouse repository with:<br /><pre class="screen">zypper addrepo -f obs://Cloud:OpenStack:Icehouse/SLE_11_SP3 Icehouse</pre></li></ul>If you like to install from packages, follow the <a href="http://docs.openstack.org/trunk/install-guide/install/zypper/content" target="_blank">OpenStack Installation Guide for openSUSE and SUSE Linux Enterprise </a>which has been updated for Icehouse.<br /><ul></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-wSP3yrlxmkE/U1EMNLXdISI/AAAAAAAABQU/5WKS6C3IVEw/s1600/Screenshot+from+2014-04-18+13:23:21.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-wSP3yrlxmkE/U1EMNLXdISI/AAAAAAAABQU/5WKS6C3IVEw/s1600/Screenshot+from+2014-04-18+13:23:21.png" height="195" width="320" /></a></div>With Icehouse, you can use the dashboard now in German and also use a new wizard for network creation.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-QbPMFAIFqTk/U1EMM1gUceI/AAAAAAAABQQ/0jXFrs1pts8/s1600/Screenshot+from+2014-04-18+13:16:01.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://2.bp.blogspot.com/-QbPMFAIFqTk/U1EMM1gUceI/AAAAAAAABQQ/0jXFrs1pts8/s1600/Screenshot+from+2014-04-18+13:16:01.png" height="196" width="320" /></a></div>Additional information about the release is available on the <a href="http://www.openstack.org/software/icehouse" target="_blank">OpenStack web page</a>.<br />My personal highlights of the new release are:<br /><ul><li>The translation of the dashboard to German and the new accordion navigation in the dashboard</li><li>The updated Installation Guides that have been greatly improved.</li><li>The new Database module (trove) that allows easy creation and manipulation of Databases for usage by virtual machines and thus gives you Database-as-a-Service.</li><li>The Compute component now allows migrations and upgrades - you can first update the controller nodes and then the compute nodes and run thus a mixture of old and new compute nodes.</li><li>The great progress that Orchestration makes with better integration of projects and giving the users now full control of manipulation of stacks.</li><li>Learning about the "most insane CI infrastructure". The more I learn about the CI infrastructure and interact with the infra team, my appreciation about their great work growth. Thanks a lot, Clark, Elizabeth, Fungi, Monty, James, Sergey, et al.!</li></ul>Also, thanks to the Documentation team, it was again a lot of fun to work together with all of you and release Icehouse documentation and improve OpenStack! Team, I look forward to drink with you the 104 beers that Gauvain promised for Atlanta ;)<br />Now on to get Icehouse integrated into SUSE Cloud for our next release...<br /><br /><br />http://jaegerandi.blogspot.com/2014/04/openstack-icehouse-released-and.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-723736260352264404Thu, 17 Apr 2014 08:14:00 +00002014-04-17T10:14:48.522+02:00OpenStacktranslationChanges for importing translations to OpenStackMost OpenStack projects send after each commit updated files for translation to <a href="http://www.transifex.com/" target="_blank">transifex</a>. Also, every morning any translated files get merged back to the projects as a "proposal" - a normal review with all the changes in it.<br />Quite a lot projects had broken translation files - files with duplicate entries that transifex rejected -, and thus no update happened for some time. The problem is that these jobs run automatically and nobody gets notified when they fail.<br /><br />Clark Boylan, Devananda van der Veen and myself have recently looked into this and produced several fixes to get this all working properly:<br /><ul><li>The broken translation files (see <a href="https://bugs.launchpad.net/keystone/+bug/1299349" target="_blank">bug 1299349</a>) have been fixed in time for the Icehouse release.</li><li>The gating has been enhanced so that no broken files can go in again.</li><li>The scripts that send the translations to and retrieve them from transifex have been greatly improved.</li></ul>The scripts have been analyzed and a couple of problems fixed so that no more obsolete entries should show up anymore. Additionally, the proposal scripts - those that download from transifex - have been changed to not propose any files where only dates or line numbers have changed. This last change is a great optimization for the projects. For example, the sahara project got every morning a proposal that contained two line changes for each .po file - just updates of the dates. Now they do not get any update at all unless there is a real change of the translation files. A real change is either a new translation or a change of strings. For example, today's update to the operations-guide contained only a single file (see this <a href="https://review.openstack.org/#/c/88157/" target="_blank">review</a>) since the only change was a translation update by the Czech translation team - and sahara did not get an update at all.<br /><h4>New User: OpenStack Proposal Bot</h4>Previously the translation jobs where run as user "Jenkins" and now have been changed to "OpenStack Proposal Bot".<br /><br />Now, another magic script showed up and welcomed the Proposal Bot to OpenStack:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-opjAcM463lQ/U0-L0VWXhSI/AAAAAAAABP4/p7dw10Gs3S8/s1600/Screenshot+from+2014-04-17+10:07:17.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-opjAcM463lQ/U0-L0VWXhSI/AAAAAAAABP4/p7dw10Gs3S8/s1600/Screenshot+from+2014-04-17+10:07:17.png" /></a></div>Unfortunately, the workflow did not work for most projects - the bot forgot to sign the contributor license agreement:<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/--6fqU0vgus4/U0-MKlb2tJI/AAAAAAAABQA/hHgQJTZgtdo/s1600/Screenshot+from+2014-04-17+10:08:48.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/--6fqU0vgus4/U0-MKlb2tJI/AAAAAAAABQA/hHgQJTZgtdo/s1600/Screenshot+from+2014-04-17+10:08:48.png" /></a></div>I'm sure the infra team will find a way to have the bot sign the CLA and starting tomorrow, the import of translations will work again.http://jaegerandi.blogspot.com/2014/04/changes-for-importing-translations-to.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-4247766634359023022Thu, 27 Mar 2014 10:28:00 +00002014-03-27T11:28:46.501+01:00OpenStackHorizon is translated to German for OpenStack Icehouse!After my<a href="http://jaegerandi.blogspot.de/2014/03/translating-openstack-dashboard-horizon.html" target="_blank"> call for help</a> two days ago, a few new people started helping with the German translations and we've achieved the goal of translating 100 per cent - that's all 2141 strings!<br />This was done by Christian Berendt, Marita Werner, Robert Simai, Sascha Peilicke, User "Schwefel", User "transistor" and myself! Thanks for getting this done!<br /><br />I'm impressed that we got this final step done so quickly!<br /><br />A special applause to Marita for doing the final 60 strings - I consider the last the hardest ones since those are the ones that we all skipped ;)http://jaegerandi.blogspot.com/2014/03/horizon-is-translated-to-german-for.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-7081515601022660264Tue, 25 Mar 2014 09:52:00 +00002014-03-25T12:37:57.665+01:00OpenStackTranslating OpenStack Dashboard (Horizon) - Let's get German in!The OpenStack 18n team has recently asked for translations of the dashboard for OpenStack Icehouse, here're two emails with details (<a href="http://lists.openstack.org/pipermail/openstack-i18n/2014-March/000420.html" target="_blank">first mail,</a> <a href="http://lists.openstack.org/pipermail/openstack-i18n/2014-March/000420.html" target="_blank">second mail</a>).<br /><br />My friend Robert suggested to do the German translations to finally have the dashboard available in German as well - and Sascha stepped up to help coordinating the German language team.<br /><br />For German, there's only one resource left to translate called "<a href="https://www.transifex.com/projects/p/horizon/resource/openstack-dashboard-translations/" target="_blank">openstack-dashboard-translations</a>" - and it's available like all other OpenStack translations at <a href="https://www.transifex.com/projects/p/horizon/resource/openstack-dashboard-translations/" target="_blank">transifex</a>.<br /><br /><br />If you want to join, just do the following (the instructions apply for other languages as well, some links go directly to the German parts):<br /><ol><li>Join Transifex at <a href="http://transifex.com/">http://transifex.com/</a>.</li><li><a href="https://www.transifex.com/projects/p/horizon/language/de/#facebox-joinmember" target="_blank">Join</a> the <a href="https://www.transifex.com/projects/p/openstack/language/de/members/" target="_blank">German OpenStack</a> translation team and wait until your request is accepted.</li><li>Go to&nbsp; the <a href="https://www.transifex.com/projects/p/horizon/language/de/" target="_blank">German Horizon</a> page</li><li>Click on "<b class="js-tablesorter-0">Openstack Dashboard Translations</b>" and start translating.</li></ol><br />A few days ago there were 860 untranslated strings for German, now we're down to 525. Who's going to help to get it down to zero until the deadline (I've heard 4th of April)?<br /><br />If you want to learn more about the OpenStack i18n team, visit this <a href="https://wiki.openstack.org/wiki/I18nTeam" target="_blank">wiki page</a>.http://jaegerandi.blogspot.com/2014/03/translating-openstack-dashboard-horizon.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-5890869103137769591Fri, 24 Jan 2014 14:53:00 +00002014-01-24T15:53:23.655+01:00documentationOpenStackpythonPython Virtualenv awesomeness - and developing openstack-doc-toolsTesting and developing the openstack-doc-tools package, I really came to love the python virtualenv package. The package allows installation of python packages in a local environment (virtualenv = virtual environment) for usage.<br /><br />Let me guide you on how I use it for openstack-doc-tools - the repo the OpenStack documentation team uses for its tools.<br /><br />First I change to the checked out openstack-doc-tools repository (get it from <a href="https://github.com/openstack/openstack-doc-tools">https://github.com/openstack/openstack-doc-tools</a>).<br /><br />Then, let's setup the virtualenv: I could setup a virtualenv manually using for example "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">virtualenv myenv</span>" and install packages. But the repository knows already about virtualenv and thus I can run "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python tools/install_venv.py</span>" and it installs a virtual python environment named '.venv' using the directory '.venv' of openstack-doc-tools. The requirements for the project as mentioned in the requirements.txt and test-requirements.txt files, will get installed into this virtualenv.<br /><br />Once the command finishes, it outputs a nice usage information, and I follow the option to "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">source .venv/bin/activate</span>" from my shell to run commands in the virtualenv.<br /><br />Next, I need to build the package via "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python setup.py build</span>" and then install the package with "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">python setup.py install</span>".<br /><br />Now I can easily execute commands for validating repositories. So, I can change my working directory to the api-site repository and run for example the command:<br />"<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">openstack-doc-test&nbsp; --api-site --check-niceness --force</span>" <br /><br />to test that the recent changes to the niceness check work fine on all files in the repository.<br />http://jaegerandi.blogspot.com/2014/01/python-virtualenv-awesomeness-and.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-6025251313766859522Sun, 19 Jan 2014 13:14:00 +00002014-01-19T14:14:03.986+01:00documentationOpenStackSetting up gating in the OpenStack intrastructureOne thing that impressed me with OpenStack, is the common <a href="https://wiki.openstack.org/wiki/GerritWorkflow" target="_blank">gerrit workflow</a> that is not only used for code but also for documentation and the infrastructure.<br />As I wrote in my last <a href="http://jaegerandi.blogspot.de/2014/01/validating-openstack-api-projects.html" target="_blank">blog post</a>, I enabled further validation of the documentation.<br />This article will describe how the validation has been done using the OpenStack CI infrastructure.<br /><br />The validation is done via Jenkins and to execute a process during review, as part of validation after it is approved, after it is merged or at periodic times, you need to create jobs for Jenkins and schedule them via Zuul, the OpenStack project gating system. Let's look at an example how this can be setup.<br /><br /><h2>An example of gating</h2>Let's look at how I setup gating for the api-sites projects. The patch I sent is <a href="https://review.openstack.org/#/c/64795/" target="_blank">https://review.openstack.org/#/c/64795/</a> and will be used as example in this blog post.<br />First, you should learn about the OpenStack Continous Integration infrastructure which is documented at <a href="http://ci.openstack.org/" target="_blank">http://ci.openstack.org/</a>.&nbsp; Then you should check out the infra repository called <a href="https://github.com/openstack-infra/config" target="_blank">config</a> since it contains all configuration files you need to modify. Instead of directly editing Jenkins configuration, YAML files are written that the <a href="http://ci.openstack.org/jjb.html" target="_blank">Jenkins Job Builder</a> then uses to create Jenkins jobs.<br /><br /><h4>Defining a job</h4>For a simple job, you can just specify it. With openstack-doc-tools, I wanted to reuse the same job not only for the api-sites but for all other projects as well. This can be done with a job template and those can be grouped as job-groups. Since my jobs can be executed by tox, I could reuse the '<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">gate-{name}-tox-{envlist}</span>' template (file modules/openstack_project/files/jenkins_job_builder/config/python-jobs.yaml). Parameters are specified in curly braces, thus it needs as parameters the "name" of the job and the "envlist" that tox will run - basically via "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e envlist</span>".<br />To save typing, I used job-groups to define all four jobs in one places in the file <span class="gwt-InlineLabel">modules/openstack_project/files/jenkins_job_builder/config/manuals-jobs.yaml:</span><br /><pre> - job-group:<br /> name: openstack-doc-jobs<br /> jobs:<br /> - gate-{name}-tox-{envlist}:<br /> envlist: checkniceness<br /> - gate-{name}-tox-{envlist}:<br /> envlist: checksyntax<br /> - gate-{name}-tox-{envlist}:<br /> envlist: checkdeletions<br /> - gate-{name}-tox-{envlist}:<br /> envlist: checkbuild<br /></pre><br />So, this creates '<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">gate-{name}-tox-checkniceness</span>' etc, the variable envlist gets substituted with checkniceness for the first gate etc.<br /><br />Now, to use this job-group, I added to modules/openstack_project/files/jenkins_job_builder/config/projects.yaml a project definition:<br /><pre>- project:<br /> name: api-site<br /> github-org: openstack<br /> node: precise<br /><br /> jobs:<br /> - openstack-doc-jobs<br /></pre><br />The name parameter in the job-group is now substituted with "api-site", thus this creates the four jobs:<br /><pre>gate-api-site-tox-checkniceness<br />gate-api-site-tox-checksyntax<br />gate-api-site-tox-checkdeletions<br />gate-api-site-tox-checkbuild<br /></pre><br />Now, the created jobs are ready to be run at specific events.<br /><br /><h4>Gating jobs</h4>The OpenStack CI infrastructure uses a tool called <a href="http://ci.openstack.org/zuul.html" target="_blank">Zuul</a> to launch jobs in response to specific gerrit events. The configuration happens via a central YAML file, it is modules/openstack_project/files/zuul/layout.yaml.<br />Since I like to use the same jobs for several projects, I made use of a very recent feature of Zuul called project-template. I created a template with the name "openstack-doc-gate":<br /><pre>project-templates:<br />...<br /> - name: openstack-doc-gate<br /> check:<br /> - gate-{name}-tox-checkniceness<br /> - gate-{name}-tox-checksyntax<br /> - gate-{name}-tox-checkdeletions<br /> - gate-{name}-tox-checkbuild<br /> gate:<br /> - gate-{name}-tox-checkniceness<br /> - gate-{name}-tox-checksyntax<br /> - gate-{name}-tox-checkdeletions<br /> - gate-{name}-tox-checkbuild<br /></pre><br />The jobs are setup to be run for each review (check) and once a patch has been approved (gate).<br /><br />This template is then used in the configuration of "api-site". The name here is the name of the git repository (api-site in project openstack) and the last component (api-site) is passed as parameter to the template which results in the four jobs created in projects.yaml:<br /><pre> - name: openstack/api-site<br /> template:<br /> - name: openstack-doc-gate<br /> post:<br /> - openstack-api-quick-start<br /> - openstack-api-site<br /> - openstack-api-ref<br /><br /></pre>The post jobs are unchanged, these are the jobs that will be run after a patch is merged.<br /><br />Additionally, I marked the checkniceness job as non-voting: <br /><pre> - name: gate-api-site-tox-checkniceness<br /> voting: false<br /></pre><br />As mentioned in my previous post, the patch has been merged and is running just fine.<br />If you want to see Zuul in action, check its great <a href="http://status.openstack.org/zuul" target="_blank">status page</a>.<br /><h4>Further work</h4>I've written a followup patch to gate the API projects and operations-guide repository, it is currently up for review at <a href="https://review.openstack.org/#/c/64795/" target="_blank">https://review.openstack.org/#/c/64795/</a>. Once this is in, the openstack-manuals can get similiar treatment. I've decided to use a separate patch for easier review since the openstack-manuals patch will remove some existing configuration.<br />Writting this up, I noticed that the checkniceness job is run also as non-voting gating job. This is not needed, so I wrote a simple patch to remove it: <a href="https://review.openstack.org/67702">https://review.openstack.org/67702</a>.http://jaegerandi.blogspot.com/2014/01/setting-up-gating-in-openstack.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-6554633813608886813Fri, 17 Jan 2014 09:47:00 +00002014-01-17T10:47:09.444+01:00documentationOpenStackValidating OpenStack API projectsThe OpenStack documentation team has validated the manuals in the openstack-manuals repository using a python tool. We now have moved this and other tools into a new <a href="https://github.com/openstack/openstack-doc-tools" target="_blank">openstack-doc-tools</a> repository. The goal is to have a single place for the tools that are needed for different documentation repositories.<br /><br />During the last weeks, I expanded the tools so that they handle also the API project repositories like api-sites and volume-api (the published versions are found via <a href="http://api.openstack.org/">http://api.openstack.org/</a>). The tools found many problems in the current API projects, including some projects that did not even built. The errors found by these are a clear sign that we do need these gating jobs. Diane Fleming and myself fixed the problems that the validation tool found. A small number of problems are still being worked on but all repositories build again and are setup for using the new gates.<br />Since yesterday, the api-sites repository uses this new tool for gating!<br /><br /><h3>Validating your changes</h3>If you like to run the gates locally: Install the python tox package and run '<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox</span>' from the top-level directory to use the same tests that are done as part of our Jenkins gating jobs. If you like to run individual tests, run:<br /><ul><li>'<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e checkniceness</span>' - to run the niceness tests</li><li>'<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e checksyntax</span>' - to run syntax checks</li><li>'<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e checkdeletions</span>' - to check that no deleted files are referenced</li><li>'<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e checkbuild</span>' - to actually build the manual(s)</li></ul>&nbsp;Note that these checks only test the files of the most recent commit, so first 'git commit' everything, then run '<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox</span>'. To check all files, pass '--force' as parameter to the tox command, for example '<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">tox -e checkniceness -- --force</span>'. The '--' is important, it passes the option down to the validation tool.<br /><br />Note that the tools need the maven package as requirement, so install that one as well.<br /><h3>Repositories gating</h3><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-_DcsZfWBvQI/Utj7XQ1E1TI/AAAAAAAABPU/fMPCT0omYxE/s1600/Screenshot+from+2014-01-17+10:43:27.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-_DcsZfWBvQI/Utj7XQ1E1TI/AAAAAAAABPU/fMPCT0omYxE/s1600/Screenshot+from+2014-01-17+10:43:27.png" height="144" width="640" /></a></div>As a first step, api-sites is gating now with these four checks. The niceness check is optional (non-voting). The other api projects (compute-api, database-api, identity-api, image-api, netconn-api, object-api, and volume-api) will soon be setup as well for this.<br />Additionally, these gates will replace the existing gates for the openstack-manual and operations-guide repositories. Once this is done via have for all repositories the same setup and just a single repository with all the validation tools.<br /><br /><h3>openstack-doc-tools repository</h3>The repository can be downloaded as a Python package from pypi and currently contains tools for:<br /><ul><li>validation/gating: as explained above</li><li>translated documents: Tom Fifieldt is looking on enhancing and using these now.</li><li>Autogeneration of tables: Shaun McCance is enhancing these to nicely generate configuration tables of options specified in the various conf files like nova.conf.<a class="gwt-InlineHyperlink GJEA35ODE" href="https://review.openstack.org/#/dashboard/8369" title="Shaun McCance &lt;shaunm@gnome.org&gt;"></a></li><li>cleanup tools: Those can be used to remove some whitespace.</li></ul>Help in improving the tools is always welcome. If you have questions, join the documentation team on the #openstack-doc IRC channel or on the <a href="http://lists.openstack.org/pipermail/openstack-docs/" target="_blank">openstack-docs</a> mailing list <br /><br /><h3>Thanks</h3>Thanks especially to Fungi and Clark for guidance and review on how to do this in the best way, to Diane for fixing many problems, for Tom, Anne and others for reviews and comments!<br /><br />http://jaegerandi.blogspot.com/2014/01/validating-openstack-api-projects.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-5560139935707922681Sat, 16 Nov 2013 01:33:00 +00002013-11-16T12:12:14.206+01:00OpenStackSUSE CloudSUSEConSUSECon '13 - Final dayIt's Friday - the final day of SUSECon. The closing keynote was by Lew Tucker from Cisco who's also the OpenStack Vice Chairperson.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-djBv7tx/0/S/ajs_6491-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-djBv7tx/0/S/ajs_6491-S.jpg" width="320" /></a></div><br />He gave a great overview of cloud computing and OpenStack - and how Cisco plays a role in it. He also cited some impressive numbers on network traffic world wide.<br />It was interesting to see that Cisco UCS has an API that you can use to manage the Cisco hardware.<br />Also a demo was shown that showed the integration of Cisco UCS together with SUSE Cloud - and SUSE Manager and SUSE Studio for a complete lifecyle management.<br /><br />At the end of the keynote the video "<span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="What's the Chameleon Say - Lip Sync with Attendees">What's the Chameleon Say" was shown.</span> SUSE's Russ Dastrup wrote a great script and filmed the&nbsp;<a href="http://www.youtube.com/watch?v=VNkDJk5_9eU" target="_blank"> initial version</a>&nbsp; with his kids and some friends - and then during SUSECon filmed the version below with participants.<iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/Rg6ksPA7SAc" width="560"></iframe><br /><br />Btw. additional videos are available from the <a href="http://www.youtube.com/user/susevideo/" target="_blank">SUSEvideo</a> channel on YouTube.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-Cf9mBXB/0/S/ajs_6619-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-Cf9mBXB/0/S/ajs_6619-S.jpg" width="320" /></a></div><br /><br />I attended then the session called "wicked trip into wicket network management". Olaf Kirch and Matthias Eckermann explained the complexities of networking on Linux and how the ifcfg framework will be replaced for SUSE Linux Enterprise 12 by a new concept called "wicked". Wicked uses a wickedd daemon and a wicked command line utility to manage complex network setup.&nbsp; It handles renames of interfaces and can be configured by both config files and via dbus. The package wicked is available for installation in openSUSE 13.1 from the Open Build Service.<br /><br />Thus ends my report from SUSECon '13. If you like to see more photos, check my <a href="http://ajaeger.smugmug.com/Events/SUSECon-13" target="_blank">updated gallery</a>. http://jaegerandi.blogspot.com/2013/11/susecon-13-final-day.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-777166179602166379Fri, 15 Nov 2013 02:38:00 +00002013-11-15T03:38:48.233+01:00SUSE CloudSUSEConSUSECon '13 - third dayThursday morning started for me with a presentation titled "Intel and OpenStack: Contributions and challenges". Krish Raghuram explained not only how Intel helps OpenStack to work great on Intel hardware but also how Intel uses OpenStack internally. For example, they have their own OpenStack private cloud where they run 1,500,000 (hope I got all the zeros right;-) VMs across data centers. Interesting was the concept of geolocation in the cloud: With trusted computing, an image can be encrypted and then will only run in certain geos, e.g. countries. If only the diagram wouldn't look that complex...<br /><br />The next presentation I attended was by Udo Seidel about "Petabyte scale out Rocks - Ceph as Replacement for Openstack's Swift and Co". He first introduced ceph and explained how it's scalable, has a flexible configuration and not a single point of failure. Ceph can also be used in OpenStack as an alternative to OpenStack Object Storage (Swift), as backend for OpenStack Block Storage (cinder) and<br />also as storage for OpenStack Image Service (glance).&nbsp; A single backend for these kinds of storage is a quite clever idea.<br /><br />I listened again into our SLE 12 systems management outlook session and was happy that I had the evening off - and concluded the evening with a good time at the pool looking at the moon, swimming, sliding and talking.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-8NctRvs/0/S/ajs_6462-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-8NctRvs/0/S/ajs_6462-S.jpg" width="320" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-WmjBVhx/0/S/ajs_6457-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-WmjBVhx/0/S/ajs_6457-S.jpg" width="320" /></a></div><br />Photos from the day have been added again to my <a href="http://ajaeger.smugmug.com/Events/SUSECon-13" target="_blank">gallery</a>.http://jaegerandi.blogspot.com/2013/11/susecon-13-third-day.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-7999173848745612680Thu, 14 Nov 2013 03:53:00 +00002013-11-14T04:53:59.490+01:00OpenStackSUSE CloudSUSEConSUSECon '13 - second day<div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-6Gtv2Q5/0/S/ajs_6147-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-6Gtv2Q5/0/S/ajs_6147-S.jpg" width="320" /></a></div><br />Today's program at <a href="http://www.susecon.com/" target="_blank">SUSECon</a> '13 had one major topic: <a href="http://www.suse.com/cloud/" target="_blank">SUSE Cloud</a> and thus <a href="http://www.openstack.org/" target="_blank">OpenStack</a>: First I listened to two presentations about Apache Stratos, an PaaS solution that can be used on top of OpenStack. I was impressed by the level of process integration they have, how they can support devops and how they integrated java. Then, I listened to a presentation about the Cisco and OpenStack. A SUSE Cloud installation is nicely integrated with Cisco UCS and then there's the option to scale OpenStack networking with Cisco Nexus routers. Next was the exception to the rule: A presentation about SUSE's changes for system management in SUSE Linux Enterprise 12. Afterwards it was back to OpenStack - this time the VMware story where networking with NXS (formerly Nicira) and VMware vSphere integration was presented - and the SUSE Cloud integration using VMware as hypervisor was demoed.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-g7dNtdw/0/S/ajs_6280-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-g7dNtdw/0/S/ajs_6280-S.jpg" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><br />The day closed with a visit to Disney's Epcot park where we even did a test drive of a "self designed" car.<br />Photos from the day have been added to my <a href="http://ajaeger.smugmug.com/Events/SUSECon-13" target="_blank">gallery</a>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-vb7PhqH/0/S/ajs_6282-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-vb7PhqH/0/S/ajs_6282-S.jpg" width="320" /></a></div><br />http://jaegerandi.blogspot.com/2013/11/susecon-13-second-day.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-1275557130554736104Wed, 13 Nov 2013 03:51:00 +00002013-11-13T04:51:34.537+01:00OpenStackSUSESUSE CloudSUSEConSUSECon '13Yesterday I flew to Orlando, Florida for <a href="http://www.susecon.com/" target="_blank">SUSEcon '13</a> and today the conference started.<br /><div class="separator" style="clear: both; text-align: center;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-FCLMHhH/0/S/ajs_5830-S.jpg" width="320" /></div><br /><div class="yt" id="watch-headline-title">The opening keynote had two fun videos: "<span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="What Does the Chameleon Say?"><a href="http://www.youtube.com/watch?v=VNkDJk5_9eU" target="_blank">What Does the Chameleon Say?</a>" and "</span><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><a href="http://www.youtube.com/watch?v=wcYnjUMm8oM" target="_blank">Chameleon Dance</a>". At the end of the second video most people turned their heads to the entrance of the hall to expect the chameleon to come in - but that did not happen. But the chameleon showed up at the evening pirate party.</span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013">In the exhibition hall I showed and discussed SUSE Cloud 2.0 - our OpenStack based cloud product - and <a href="http://www.susestudio.com/" target="_blank">SUSE Studio</a> - the great image/appliance building tool with customers.</span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013">I attended two presentations: Jos Poortvliet and Robert Schweikert gave a view "behind the scenes: How SUSE and openSUSE collaborate". They explained the interaction between openSUSE community and its corporate sponsors and the sometimes conflicting interests.</span></div><div class="yt" id="watch-headline-title"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-zrCn6fg/0/S/ajs_5859-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-zrCn6fg/0/S/ajs_5859-S.jpg" width="320" /></a></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013">Later I listed to Alan Clark to give some "OpenStack insights: the disruptive nature of open source cloud". He introduced OpenStack from the community and foundation site - not going into technical details of the implementation but more into the principles that are important for OpenStack and showed the great momentum that it has.</span><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"> From the discussions at the end, it looked that he might have recruited a new OpenStack contributor ;)</span></div><div class="separator" style="clear: both; text-align: center;"><a href="http://ajaeger.smugmug.com/Events/SUSECon-13/i-j5n4qjK/0/S/ajs_5870-S.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://ajaeger.smugmug.com/Events/SUSECon-13/i-j5n4qjK/0/S/ajs_5870-S.jpg" /></a></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div><div class="yt" id="watch-headline-title"><br /></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013">I also shot quite some photos and uploaded them to my <a href="http://ajaeger.smugmug.com/Events/SUSECon-13" target="_blank">gallery</a>. </span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div><div class="yt" id="watch-headline-title"><span class="watch-title yt-uix-expander-head" dir="ltr" id="eow-title" title="Chameleon Dance - Opening video for SUSECon 2013"><br /></span></div>http://jaegerandi.blogspot.com/2013/11/susecon-13.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-6556681999954637468Wed, 09 Oct 2013 13:39:00 +00002013-10-09T16:54:09.356+02:00documentationOpenStackEasily read locally built OpenStack manualsWriting and reviewing the OpenStack documentation, I often navigated through directory after directory to finally open a guide in my browser and see it. I considered bookmarking some links but then wrote a local "index.html" file that I can open in my browser and easily click on any guide.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-x7DJLiViXJs/UlVVx6MEeuI/AAAAAAAABL8/PV5cqPdh3hI/s1600/Screenshot+from+2013-10-09+14:47:19.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="195" src="http://3.bp.blogspot.com/-x7DJLiViXJs/UlVVx6MEeuI/AAAAAAAABL8/PV5cqPdh3hI/s400/Screenshot+from+2013-10-09+14:47:19.png" width="400" /></a></div><br />This index file - called now&nbsp; "local-files.html" is now part of the OpenStack documentation repository openstack-manuals in the doc directory. I've added also a few links to online OpenStack Documentation resources.<br />I hope this will make reviewing contents easier.http://jaegerandi.blogspot.com/2013/10/easily-read-locally-build-openstack.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-2054512361629151325Tue, 08 Oct 2013 11:14:00 +00002013-10-08T13:19:25.290+02:00OpenStackImproving the OpenStack Documentation Build ToolsDuring the last weeks, the tool for building and checking the OpenStack Documentation manuals has been improved.<br /><br />Now we have one new tool with a few different options for fine-grained control. It is run as part of the gates and can be run locally as well. If you used <code>tools/validate.py</code> to test your changes locally, you should now use <code>tools/test.py</code>. <br />Instead, of a single gate job, there are now four checking gates, you'll see now something like the following from Jenkins:<br /><pre>Build succeeded.<br /><br /> gate-openstack-manuals-validate-niceness SUCCESS in 4s (non-voting)<br /> gate-openstack-manuals-validate-syntax SUCCESS in 2s<br /> gate-openstack-manuals-validate-deletions SUCCESS in 4s<br /> gate-openstack-manuals-validate-build SUCCESS in 8m 47s </pre><br />The advantage of all of these changes are that a writer submitting a patch gets quickly an overview about what fails. This is due to the separate jobs. These jobs only check what has changed and thus do not build all books but only those impacted by the change under review. <br /><h2>Description of Checks</h2>Note that all checks parse the git output to record the modified files in a review and only look at these files. If you want to run checks locally on all files, use the <code>--force</code> option. <br /><h3>Niceness check</h3>This tests for extra whitespace. It is non-voting for now and thus not run as part of the final gate. <br /><h3>Syntax check</h3>This check validates the docbook XML code for each file against DocBook 5.1 (actually candidate release 1 - 5.1CR1). <br /><h3>Deletions check</h3>This check tests whether any files have been removed and if those are still referenced anywhere. It handles images and include files. <br /><h3>Build Check</h3>This check will build all books that might be modified by the commit. It checks which files are modified and which books include these files and runs a check of all books where one file was changed. The books are build in parallel to speed up building.<br /><br />For the Install Guide, it builds all three variants of the Guide - the Fedora/RHEL/Centos Install Guide, the Ubuntu Install Guide and the openSUSE Install Guide. It now also builds the High Availability Guide (which is not using DocBook but asciidoc) if one of its files has changed.Thus, everything is build the same way as we do for publishing the manuals to the <a href="http://docs.openstack.org/trunk" target="_blank">OpenStack docs</a> site.<br /><br />Since we only build the modified books and build them in parallel, you might get now a comment from Jenkins in a minute or two while you had to work 30 minutes in August for this. Jenkins currently needs around 10 minutes to build all books.<br /><h3>Options</h3>The tool is <code>tools/test.py</code> and has the following options: <br /><pre>tools/test.py --help<br />usage: test.py [-h] [--force] [--check-build] [--check-syntax]<br /> [--check-deletions] [--check-niceness] [--check-all]<br /> [--non-voting] [--verbose]<br /> [path]<br /><br />Validate XML files against the DocBook 5 RELAX NG schema<br /><br />positional arguments:<br /> path Root directory that contains DocBook files, defaults to<br /> `git rev-parse --show-toplevel`/doc<br /><br />optional arguments:<br /> -h, --help show this help message and exit<br /> --force Force the validation of all files and build all books<br /> --check-build Try to build books using modified files<br /> --check-syntax Check the syntax of modified files<br /> --check-deletions Check that deleted files are not used.<br /> --check-niceness Check the niceness of files, for example whitespace.<br /> --check-all Run all checks (default if no arguments are given)<br /> --non-voting Do not exit on failures<br /> --verbose Verbose execution<br /></pre><br /><br />I'd like to thank <a href="http://www.cberendt.de/" target="_blank">Christian Berendt</a> for starting this with the creation of test.py (as a modified copy of validate.py) and all the reviewers that helped moving this forward.http://jaegerandi.blogspot.com/2013/10/improving-openstack-documentation-build.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-4584876925998209184Fri, 12 Jul 2013 12:08:00 +00002013-07-12T14:08:14.084+02:00openSUSESLESUSENIS and Password Length FunI have seen a request to "extend NIS/YP maximum password length" for SUSE Linux and openSUSE and digging into this further, found that there's really nothing to do but a lot of confusion.<br /><br />NIS itself stores passwords and does not have limitations on the password implementation and on the used ciphers. Password authentification happens at login time on a client, at the imap server when connecting (if the imap server uses the NIS database) etc - and on the NIS server when changing the password (more below).<br /><br />All systems that do authentication, do the password check locally and thus all systems, need to implement the same ciphers for encryption. The common lowest denominator is DES which only supports 8 characters. But if you know that all systems support e.g. SHA-512, you can use that one.<br /><br />To change the cipher used for encryption on an openSUSE or SUSE Linux Enterprise 11 system, there are two different ways, depending on whether you use <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix2</span> or <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix</span> in <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">/etc/pam.d/common-password</span>. <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix</span> will be the default in new openSUSE 13.1 installations, <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix2</span> has been setup so far by default on openSUSE and SUSE Linux Enterprise.&nbsp; If you use <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix2</span>, edit<span style="font-family: &quot;Courier New&quot;,Courier,monospace;"> /etc/default/passwd</span> and change <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">CRYPT_YP</span> to the desired cipher. If you use <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">pam_unix</span>, edit <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">/etc/login.defs</span> and edit <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">ENCRYPT_METHOD</span> - and then run "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">passwd</span>".<br /><br />Regarding compatibility of systems, here's some uncomplete information on ciphers available besides DES that I quickly gathered:<br /><br /><ul><li>SLES 10: blowfish</li><li>SLES 11: md5, sha-256, sha-512, blowfish</li><li>openSUSE 13.1: md5, sha-256, sha-512, blowfish</li><li>Solaris 11: sha-256, md5</li><li>RHEL 6: sha-256, sha-512, md5</li></ul><br />Testing this, I stumpled upon one problem: When changing the NIS password, the old password is verified locally and then the old password is send <i><b>unencrypted</b></i> together with the encrypted new password to the NIS server. The NIS server then tests that the old password is correct (it cannot trust your client) and saves the encrypted new password in its database. When you now specify a cipher for encryption that is not known to the server, it will happily save the new encyrpted password - but once you change the next time, it will fail since it does not understand the new cipher and thus cannot check that the old password is correct. So, time to ask your admins to reset your NIS password...<br /><br />Thanks for my colleague - and Linux NIS developer - Thorsten Kukuk for shedding some lights on these questions.<br />http://jaegerandi.blogspot.com/2013/07/nis-and-password-length-fun.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-5564478469927574593Fri, 12 Apr 2013 10:16:00 +00002013-04-12T12:16:49.752+02:00CrowbarOpenStackopenSUSESLESUSE CloudChef and Crowbar for setting up OpenStack clouds - with openSUSE and SUSE CloudTo easily setup an OpenStack-based cloud on server hardware, we at SUSE use the open source <a href="https://github.com/crowbar">Crowbar</a> project. Crowbar eases the setup of all the different OpenStack components and thus reduces the time spent deploying and managing an OpenStack-based cloud.<br /><br /><a href="https://raw.github.com/crowbar/barclamp-crowbar/master/crowbar_framework/public/images/crowbar-logo.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://raw.github.com/crowbar/barclamp-crowbar/master/crowbar_framework/public/images/crowbar-logo.png" /></a>Crowbar is a platform for server provisioning and deployment from bare metal. It provides server discovery, firmware upgrades, and operating system installation using PXE Boot, and it deploys applications on top of functioning operating systems using Chef.<br /><br />Currently development is happening on Crowbar 2 and I'd like to give a short overview of a few things that are done here to make this work useable for openSUSE and <a href="http://www.suse.com/products/suse-cloud/">SUSE Cloud</a> - SUSE's OpenStack based cloud offering.<br /><h3> Moving to a common Chef cookbase base</h3>So far, Crowbar comes with its own Chef cookbooks to setup OpenStack, a forked and heavily adapted version.<br /><br />We'd like to have one common set of Chef cookbooks that are shared between Crowbar and administrators using Chef directly. As Rob Hirschfeld <a href="http://robhirschfeld.com/2013/03/08/devops-plawith-others-chef-crowbar-upstream">said</a>: "The real victory comes when multiple deployments use the same trunk instead of forking".<br />The additional benefit here is that these cookbooks will then also work without Crowbar on e.g. openSUSE and SUSE Linux Enterprise.<br /><br />Right now it looks like the awesome cookbooks done by AT&amp;T and Rackspace (e.g. <a href="https://github.com/att-cloud/cookbook-keystone/blob/master/README.md%29">https://github.com/att-cloud/cookbook-keystone/blob/master/README.md)</a> are the best option for going forward. But these cookbooks have two limitations for our usage: they do not handle openSUSE and SUSE Linux Enterprise and are not ported for Grizzly yet. So, this gives us the next tasks:<br /><h3>Enhance existing Chef cookbooks to know about openSUSE and SUSE - and for Grizzly</h3>We're enhancing these cookbooks now so that they support OpenStack Grizzly and we're also adding support for servers running openSUSE and SUSE Linux Enterprise.<br /><br />Once the cookbooks are usuable on their own, they can be integrated into Crowbar.<br /><h3> Integrate the Chef cookbooks into Crowbar</h3>To use the cookbooks from Crowbar, Crowbar needs to pass parameters to<br />them. This concept is called "Attribute Injection" and Judd Maltin has explained this in detail in a <a href="http://newgoliath.wordpress.com/2013/03/08/orchestration-consistency-and-community-cookbooks/">great blog post</a>.<br /><h3>Crowbar 2 and Chef / Puppet</h3>Of interest to some might be that in the coming Crowbar 2, the Chef usage has been hidden behind an extra layer called "Jig". Jig was introduced to overcome some design limitations of Crowbar, the extra abstraction also gives a more flexible framework. Now other configuration management options can be added besides Chef. Puppet is one framework that the Crowbar team would like to support as backend and this work is currently postponed after the initial Crowbar 2 release.http://jaegerandi.blogspot.com/2013/04/chef-and-crowbar-for-setting-up.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-3034542377040863711Tue, 09 Apr 2013 07:02:00 +00002013-04-09T09:02:37.534+02:00CloudOpenStackSUSE CloudOpenStack Grizzly Packages for openSUSE and SUSE Linux EnterpriseLast week the OpenStack project released its 7th release named <a href="http://www.openstack.org/blog/2013/04/openstack-grizzly/">Grizzly</a> and the packages are now available for openSUSE and SUSE Linux Enterprise via the <a href="https://build.opensuse.org/project/show?project=Cloud%3AOpenStack%3AGrizzly">openSUSE Build Service</a>. Packages can be downloaded from the <a href="http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/">download server</a>.<br /><br />The repositories contain all the core OpenStack packages plus incubated projects that will be part of core in the Havana release (Heat for VM orchestration and Ceilometer for metering). Additional package dependencies are included as well.<br /><br />For discussion about these packages, use the opensuse-cloud at opensuse.org mailing list and the freenode channel #opensuse-cloud. To learn more about OpenStack on openSUSE, see also <a href="http://en.opensuse.org/Portal:OpenStack">our wiki page</a>. http://jaegerandi.blogspot.com/2013/04/openstack-grizzly-packages-for-opensuse.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-3862403006334245713Mon, 11 Mar 2013 11:00:00 +00002013-03-11T22:05:36.839+01:00CloudCrowbarOpenStackopenSUSESUSE CloudMoving to open development: OpenStack / Crowbar / Chef on SUSE<i>This blog post was written by <a href="http://adamspiers.org/" target="_blank">Adam Spiers</a> and Andreas Jaeger.</i><br /> Here at SUSE we have based our business on Free and Open Source Software for <a href="https://www.suse.com/company/press/2012/4/suse-showcases-20-years-of-commercializing-open-source-software.html">over 20 years</a>, so it is nothing new to say that we strongly believe in open development and collaboration as a way of producing software of the highest quality.<br />Therefore we are pleased to announce that we have opened up our work on development and packaging of OpenStack, Crowbar, and Chef, for both openSUSE and SUSE Linux Enterprise. This work is happening publically in the Open Build Service, and we warmly invite everyone to use the results and also join in with development, testing, documentation and packaging.<br />Open development is a process that does not end with code on public servers, but involves ongoing open communication as well. Please speak up on the <a href="http://lists.opensuse.org/opensuse-cloud/">opensuse-cloud mailing list</a>if you see any areas where we could improve further! <h2>OpenStack</h2> <a href="http://openstack.org/">OpenStack</a> is our preferred cloud management platform, due to its open nature and backing from <a href="http://www.openstack.org/community/">an already huge and rapidly growing community</a>. We have packaged both OpenStack's <a href="https://build.opensuse.org/project/show?project=Cloud:OpenStack:Folsom">Folsom release</a>and the beta packages for the upcoming <a href="https://build.opensuse.org/project/show?project=Cloud%3AOpenStack%3AMaster">Grizzly release</a> and have made them available in the Open Build Service. <h2>Crowbar</h2><img src="https://raw.github.com/crowbar/barclamp-crowbar/master/crowbar_framework/public/images/crowbar-logo.png" style="float: right;" />OpenStack's incredible flexibility can also make it difficult to deploy. Therefore to ease the set-up of all the different OpenStack components out of the box, we are supporting the open source Crowbar project.&nbsp; Our partners and customers find that using Crowbar dramatically reduces the time spent deploying and managing an OpenStack-based cloud. <br />Crowbar is a platform for server provisioning and deployment from bare metal. It provides server discovery, firmware upgrades, and operating system installation using PXE Boot, and it deploys applications on top of functioning operating systems using Chef. <h3>Opening up Crowbar development</h3>Similarly to how OpenStack was born at RackSpace and later grew into an independent entity in the form of the <a href="https://www.openstack.org/foundation/">OpenStack Foundation</a>, Crowbar was originally developed by Dell engineers, and is now a fully-fledged Open Source project involving close collaboration with SUSE and others. There are <a href="https://github.com/crowbar/crowbar/wiki/Meetings">weekly public meetings</a>, a <a href="https://lists.us.dell.com/mailman/listinfo/crowbar">public mailing list</a>, a <a href="https://github.com/crowbar/crowbar/wiki/IRC-channel"><code>#crowbar</code> IRC channel</a>, <a href="https://github.com/crowbar/crowbar/wiki/Development">public Trello boards</a> and so on. As an indication of the project's independent nature, the authoritative location for the git repositories has changed from https://github.com/dellcloudedge to <a href="https://github.com/crowbar">https://github.com/crowbar</a>, and <a href="http://crowbar.github.com/">a new homepage</a>is currently under construction. <h3>Crowbar 2.0</h3>Work on the upcoming 2.0 release of Crowbar is proceeding at a furious pace, and packages for openSUSE and SUSE Linux Enterprise are <a href="https://build.opensuse.org/project/show?project=systemsmanagement:crowbar:2.0">available from the OBS</a>. You are very welcome to <a href="https://github.com/crowbar/crowbar/wiki/Development">join in</a> and find out more! <h2>Chef packages</h2><img src="http://www.opscode.com/images/OC_Chef_Logo.png" style="float: right;" width="100px" /><a href="http://www.opscode.com/chef/">Chef</a> is an Open Source configuration management tool that allows remote administration of systems at scale. It has <a href="http://community.opscode.com/">a thriving community</a>which has a large overlap with the OpenStack community. We have packaged both <a href="https://build.opensuse.org/project/show?project=systemsmanagement%3Achef%3A10">Chef 10</a>and <a href="https://build.opensuse.org/project/show?project=systemsmanagement%3Achef%3Amaster">Chef 11</a>for openSUSE and SUSE Linux Enterprise. <h2>Tying it all together</h2><a href="https://en.opensuse.org/OpenStack_and_Crowbar_development_process"><img src="https://en.opensuse.org/images/6/62/Opensuse_cloud_ci.png" style="float: right; margin: 25px;" width="500px" /></a>Since each major release of these projects is packaged separately in the Open Build Service, you are free to "mix'n'match" which of these components you want to use together: <ul><li>OpenStack Essex</li><li>OpenStack Folsom</li><li>OpenStack Grizzly</li><li>Crowbar 2.0</li><li>Chef 10</li><li>Chef 11</li></ul>Of course, each combination will work differently. To try any of them out, simply navigate to <a href="https://build.opensuse.org/project/repositories?project=Cloud%3AOpenStack%3AFolsom">one of the project's Repository tab</a>to obtain the link to the relevant download repository. Then you can add that to your host's list of software repositories in the normal way via YaST2 or <code>zypper</code>, and start installing packages from it. Alternatively, you can install directly via <a href="http://en.opensuse.org/openSUSE:One_Click_Install">one-click install</a>. <h2>Automation and Continuous Integration</h2>We use <a href="http://jenkins-ci.org/">Jenkins</a> to automatically package changes from upstream git repositories into rpms within an openSUSE environment, and if they successfully build and install, Jenkins commits those changes to the Open Build Service (OBS) which then automatically builds and publishes packages and images. Jenkins also does unit tests as well as full stack tests. By automating the packaging and testing process, we can spend more time on development while maintaining high quality, and gain more clarity around where problems exist.<br />You can also read in more detail about our <a href="https://en.opensuse.org/OpenStack_and_Crowbar_development_process">development model using the Open Build Service</a>. <h2>Finding out more</h2>If you have questions, ask them on the <a href="http://lists.opensuse.org/opensuse-cloud/"><code>opensuse-cloud</code> mailing list</a> or on the recently launched #opensuse-cloud freenode IRC channel.<br />You can also find more details via the openSUSE wiki: <ul><li><a href="http://en.opensuse.org/Portal:OpenStack">http://en.opensuse.org/Portal:OpenStack</a></li><li><a href="http://en.opensuse.org/Portal:Crowbar">http://en.opensuse.org/Portal:Crowbar</a></li><li><a href="http://en.opensuse.org/Portal:Chef">http://en.opensuse.org/Portal:Chef</a></li></ul>This is work in progress, so feel free to help improve anything!http://jaegerandi.blogspot.com/2013/03/moving-to-open-development-openstack.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-1398592452601394681Mon, 25 Feb 2013 13:41:00 +00002013-02-25T14:41:52.087+01:00OpenStackopenSUSESUSESUSE CloudCoordinating efforts to create OpenStack packages for openSUSE and SUSE Linux Enterprise ServerEngineers from <a href="http://www.b1-systems.de/" target="_blank">B1 Systems</a> and <a href="http://www.suse.com/" target="_blank">SUSE</a> have now joined forces to package <a href="http://www.openstack.org/" target="_blank">OpenStack</a> in the Open Build Service for <a href="http://www.opensuse.org/" target="_blank">openSUSE</a> and SUSE Linux Enterprise. The B1 Systems engineers bring in their OpenStack consulting and packaging expertise, the SUSE team their packaging and hardening expertise from building a commercial OpenStack based release with SUSE Cloud.<br /><br />The work is done in the <a href="http://build.opensuse.org/" target="_blank">Open Build Service</a> which allows building of packages for various distributions and versions of it. There are stable packages available from the latest OpenStack release, Folsom, and beta packages of the upcoming Grizzly release. These OpenStack packages are build now for openSUSE 12.2, openSUSE 12.3 and SUSE Linux Enterprise 11 SP2.<br />The joint development project is contained in the <a href="https://build.opensuse.org/project/show?project=Cloud%3AOpenStack" target="_blank">Cloud:OpenStack</a> and its subprojects.<br /><br />Additionally, OpenStack Folsom is part of the upcoming openSUSE 12.3 release. Thus, you can build, administrate and use an OpenStack cloud within openSUSE.<br /><br />If you like to use OpenStack packages or join the team, please join us on the mailing list opensuse-cloud@opensuse.org (subscribing information is <a href="http://en.opensuse.org/Portal:OpenStack" target="_blank">here</a>).<br /><br />I'll talk in future posts on the development progress of these packages in the Open Build Service. In the meantime, to get more information about OpenStack on openSUSE, see the <a href="http://en.opensuse.org/Portal:OpenStack" target="_blank">openSUSE OpenStack Portal</a>.<br /><br />Some background: B1 Systems is a consulting partner of SUSE and offers support for OpenStack on openSUSE and SUSE Linux Enterprise.&nbsp; Some of their engineers have been packaging OpenStack for over two years now (starting with Bexar) and made those packages available through the Open Build Service for both openSUSE and SUSE Linux Enterprise. SUSE has delivered last year its <a href="https://www.suse.com/products/suse-cloud/" target="_blank">SUSE Cloud</a> 1.0 release that is based on OpenStack Essex.<br /><br />http://jaegerandi.blogspot.com/2013/02/coordinating-efforts-to-create.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-7907767042487436289Fri, 21 Dec 2012 10:21:00 +00002012-12-21T11:21:40.091+01:00openSUSEEasy way to install TeX packages for openSUSE 12.3With the upcoming openSUSE 12.3, the TeX installation is much more modular - but contains now all of TeXlive. Werner added a nice trick to install packages.<br />If you get an error like: <br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">LaTeX Error: File `multirow.sty' not found.</span><br />You can now easily install the missing package with just saying "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">zypper in 'tex(multirow.sty)'</span>".<br />Similar, if a font file is missing, e.g. you get a message like this:<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">! Font U/pzd/m/n/10=pzdr at 10.0pt not loadable: Metric (TFM) file not found.</span>you can install the file with "<span style="font-family: &quot;Courier New&quot;,Courier,monospace;">zypper in 'tex(pzdr.tfm)'</span>".<br /><br /><br />So, with the new capability 'tex', you can easily install missing files.http://jaegerandi.blogspot.com/2012/12/easy-way-to-install-tex-packages-for.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-8655277595493837816Tue, 20 Nov 2012 20:57:00 +00002012-11-20T21:59:16.204+01:00glibcopenSUSEpackagingGlibc 2.17 on the finishing lineIn the next few days David Miller as GNU C Library (glibc) 2.17 release manager will call a freeze for glibc development and I've packaged glibc for openSUSE and compiled the whole distribution with it - and it looks fine.<br />For those curious, what's in the new glibc, here's an incomplete list of the major changes. For the full list, see <a href="http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=ChangeLog;hb=HEAD" target="_blank">ChangeLog</a> file and the <a href="http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD" target="_blank">NEWS</a> file. The list comes from the current NEWS file and I've only copied entries relevant to openSUSE:<br /><ul><li>Port to ARM AArch64 contributed by Linaro.</li><li>The new function secure_getenv allows secure access to the environment, returning NULL if running in a SUID/SGID process.&nbsp; This function replaces&nbsp; the internal function __secure_getenv.</li><li>SystemTap static probes have been added into the dynamic linker. Implemented by Gary Benson.</li><li>Optimizations of string functions strstr, strcasestr and memmem. Implemented by Maxim Kuvyrkov.</li><li>The ttyname and ttyname_r functions on Linux now fall back to searching for the tty file descriptor in /dev/pts or /dev if /proc is not available.&nbsp; This allows creation of chroots without the procfs mounted on /proc.</li><li>The `crypt' function now fails if passed salt bytes that violate the&nbsp; specification for those values.&nbsp; On Linux, the `crypt' function will consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is enabled, and fail on encrypted strings using the MD5 or DES algorithm when the mode is enabled.</li><li>The `clock_*' suite of functions (declared in &lt;time.h&gt;) is now available directly in the main C library.&nbsp; Previously it was necessary to link with -lrt to use these functions.&nbsp; This change has the effect that a single-threaded program that uses a function such as `clock_gettime' (and is not linked with -lrt) will no longer implicitly load the pthreads library at runtime and so will not suffer the overheads associated with multi-thread support in other code such as the C++ runtime library.</li></ul>Also, 125 bugreports have been marked as fixed, a couple of changes from eglibc got merged (especially for cross-testing) and some cleanups of the code were done. <br /><br />With the current git development version packaged as rpm, the openSUSE Build Service compiled the whole distribution on x86-64. There were three different kind of problems in packages which showed up as build errors:<br /><ol><li>Some packages had missing includes (e.g. signal.h or stdint.h). Those are easily fixed by including the header defining the missing types.</li><li>The functions&nbsp;setfsgid() and setfsuid() produce warnings when the return value is not checked and thus fail to when -Werror is used. The proper fix is to check whether these functions have a return value less than 0.</li><li>clock_gettime() was moved from librt to libc. Some configure scripts check only whether clock_gettime is in librt and assume that other functions like mq_gettattr() are in the same library. So, the configure check for clock_gettime() in librt needs to be extended to look for other functions as well.</li></ol>I did not noticed directly any problems in glibc itself, just these three kind of problems in packages - and had to fix around 10 packages at all.<br />This was all done with the git version from the 9th of November, I've updated now to the current git version and will retest.<br />My plan is to push the current glibc package soon to the openSUSE development tree called openSUSE Factory.<br /><ol></ol>http://jaegerandi.blogspot.com/2012/11/glibc-217-on-finishing-line.htmlnoreply@blogger.com (Andreas Jaeger)0tag:blogger.com,1999:blog-8789296710216751709.post-7292942523583261952Wed, 07 Nov 2012 09:10:00 +00002012-11-07T10:10:53.847+01:00openSUSEpackagingUpdates to openSUSE Packaging GuidelinesOn the opensuse-packaging mailing list, we've recently formed a team that will take care of the packaging guidelines and introduced a <a href="http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process" target="_blank">small process </a>to change them.<br /><br />As part of that process, we're announcing regularly the changes to the packaging guidelines. Since this is a first such announcement, it is not a complete change but just points out a few things from the past few months. In the future, we will send out this email once a month.<br /><br />The Packaging guidelines can be found in the openSUSE wiki at <a href="http://en.opensuse.org/openSUSE:Packaging_guidelines">http://en.opensuse.org/openSUSE:Packaging_guidelines</a>.<br /><br /><br />The list of changes that I'd like to mention are:<br /><ul><li>New Lua Guidelines</li><li>Reworked font guidelines</li><li>Documenting changes in packages</li><li>Teams involved</li></ul><h3>New Lua Guidelines</h3>We now have guidelines for lua at <a href="http://en.opensuse.org/openSUSE:Packaging_Lua">http://en.opensuse.org/openSUSE:Packaging_Lua</a>.<br /><br /><h3>Reworked font guidelines</h3>The packaging of fonts has been completely changed, and is documented at <a href="http://en.opensuse.org/openSUSE:Packaging_Fonts">http://en.opensuse.org/openSUSE:Packaging_Fonts</a>.<br /><br /><h3>Documenting changes in packages</h3>The openSUSE review team is now also enforcing proper documenting<br />changes in packages:<br /><br />First, the .changes entry (rpm changelog) surves two purposes:<br /><ul><li>News for the user</li><li>History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixes).</li></ul><h4>Information about updates</h4>A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed.<br />&nbsp; <br />Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will.<br /><br /><h4>Documenting patch life cycle</h4>The rules about patches are listed at <a href="http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines">http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines</a> . <br /><br />Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed).<br /><br />The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the openSUSE Factory Review team:<br /><br /><blockquote class="tr_bq">The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that...</blockquote>Note: The review team is not enforcing the usage of patch markup unless the package already follows this convention.<br /><br /><h3>Teams involved, contact</h3>I mentioned two teams previously, these are the <a href="http://en.opensuse.org/openSUSE:OpenSUSE_review_team" target="_blank">openSUSE review team</a><br />and the<a href="http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process#Team_members" target="_blank"> team taking care of the guidelines</a>. You can reach both via the opensuse-packaging mailing list.http://jaegerandi.blogspot.com/2012/11/updates-to-opensuse-packaging-guidelines.htmlnoreply@blogger.com (Andreas Jaeger)1