Version 4.0 of the oVirt Engine API will include automatically generated
documentation of the API. This will be included in the server itself,
probably in a URL like
"http://engine.example.com/ovir-engine/api/explorer". I would like to
have this same documentation available in "ovirt.org", so that users
that don't have a server installed can still use the documentation,
something like this:
The documentation and the application used to explore it require approx
20 MiB of space, for each version of the API (currently only one,
Eventually this web site should be updated by a Jenkins job as part of
the release process.
Can we host this in ovirt.org?
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
-----BEGIN PGP SIGNED MESSAGE-----
In the past months we've been working on upgrading the oVirt project
infrastructure, to better support the community contributions.
One of the main platforms for our user documentation, release
management content, and community content has been the MediaWiki site
that you all know as ovirt.org. Most of us are familiar with the wiki
site format, with all its advantages and disadvantages.
After several years of serving the community, I'm happy to announce
that we are very near to completing a full upgrade of the website
infrastructure from a wiki site to a static site, source-controlled on
GitHub and authored in Markdown.
This email is the pre-launch announcement, as we are reaching the
final stages of the migration, and there are a few actions that might
affect your work on website content in the meantime.
Why migrate the website
As mentioned, wiki sites provide an open and flexible content editing
platform. Unfortunately, as the site grows the content becomes quite
difficult to manage and curate, resulting in lots of obsolete,
outdated, and incorrect information.
By moving to a source-controlled repository and implementing GitHub's
contribution workflow, we strive to ease the work of maintaining an
up-to-date content site, employ a peer-review process for changes, and
standardize the authoring markup language to lower the contribution
The Middleman framework (Ruby-based static site generator) was chosen
based on observing successful implementation of other open-source
community websites, such as OpenStack RDO, Project Atomic, and Gluster.
What we did so far
When we started the migration, our Web design team exported all of the
wiki content from the old website and converted it to MD files. They
also set up the website config flow, auto-deploy, and upgraded the
look-and-feel of the website.
We then initiated a content review effort as well as a UX review for
the new website in a smaller forum, which caught most of the critical
issues with the new website and helped us get the new format to a
place where we can release the website in a near-GA/public-beta format.
Yesterday (Wednesday Feb 17) we exported the website one more time and
currently we're running a diff on all the files that changed since the
initial export was done, to make sure we grab all the updates and the
latest content before we launch the new website.
What is about to happen
Today we are initiating a **wiki freeze**, which means the old
MediaWiki site will become read-only. This is to ensure that all of
our diff scripts reflect the most current state of the content on the
website, and that we don't lose any content in the transition.
Barring any unexpected blockers, we will port the ovirt.org domain to
point to the new website and open the new website for contributions on
**Monday February 22** or earlier.
What do you need to do right now
If you have any wiki pages that you're actively editing, please don't
save them to the old MediaWiki site, and hold onto your pending
changes until we send the happy launch email.
We will also include instructions on how to contribute/edit/add
content to the new website, but in general the workflow will be
aligned with the standard GitHub best practices
(clone-edit-commit-pullrequest), so you can utilize all of the git
commands that you already know or work directly within the GitHub web
I'd like to thank all of the people who were involved with this
migration so far, ovirt.org is a big website with lots of content and
it was no small task to upgrade it.
Please feel free to ping me on- or off-list if you have any questions
about the next steps, and expect a happy launch email soon!
Community Lead, oVirt
"To be is to do" (Socrates)
"To do is to be" (Jean-Paul Sartre)
"Do be do be do" (Frank Sinatra)
IRC: mariel / thatdocslady
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
eyal edri [Administrator] created OVIRT-424:
Summary: Review linode01 server before decommision and backup relevant data
Project: oVirt - virtualization made easy
Issue Type: Task
Reporter: eyal edri [Administrator]
Before we decommission the server after migrating all services,
verify we don't have any relevant info on it, and if so, backup to PHX.
This message was sent by Atlassian JIRA
[ https://ovirt-jira.atlassian.net/browse/OVIRT-313?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-313:
[~sbonazzola(a)redhat.com] is this still relevant?
can you post example of job which wasn't removed when removed from yaml?
> deleting yamlized jobs from git doesn't remove them from jenkins
> Key: OVIRT-313
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-313
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Components: Jenkins
> Affects Versions: Production
> Reporter: sbonazzo
> Assignee: infra
> Labels: yaml
> we have an issue with yamlized jobs: removing them from yaml doesn't disable them and doesn't delete them from jenkins. Example is:
> that should have been disabled / removed after job dropped by yaml files with commit 7479c7cde296a6bf8b7202f7483e408470e7e58f
This message was sent by Atlassian JIRA