[ovirt-devel] Engine High Availability
Hi All, In the new architecture page ( http://www.ovirt.org/documentation/architecture/architecture/), overall architecture picture shows that engine supports active-active high availability. However, as per engine HA page ( http://www.ovirt.org/develop/release-management/features/engine/engine-high-availability/), active-active HA is not supported yet and there are several implementation issues. So, could anyone give me a brief explanation about discrepancy between these two pages, and about the plan to implement this feature if not implemented yet? Sunny ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Type verification for vdsm
All, I am working on converting our vdsm schema to yaml. As part of this work [1] I added type verification for request and response data. There was a suggestion to raise an exception when there is type inconsistency but after a bit of testing I can see that there are inconsistencies for many verbs. I introduced strict mode config value which switches between raising exception and logging a warning. At the moment we log inconsistencies but there is a plan to be strict for master and log for stable branches. I would like to ask each vertical representative/maintainer to review the code and fix any inconsistencies in the schema. Thanks, Piotr [1] https://gerrit.ovirt.org/#/c/53919 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] oVirt Engine 3.6.4 branch was created + backport guide for 3.6.z
Hi everyone, The ovirt-engine-3.6.4 branch has been created following the last (hopefully) respin of 3.6.3 Note the the branch was created from the 3.6.3 branch today and contains all the content of 3.6.3 obviously. As I am asked a lot of questions questions concerning the backport flow for 3.6.z bugs, here it is: 3.6.5 bugs should be included in: - master - ovirt-engine-3.6 3.6.4 bugs should be included in: - master - ovirt-engine-3.6 - ovirt-engine-3.6.4. As for 3.6.6 only bugs i.e. those that are solved in the timeline before branching out of 3.6.5 but you do not want them to be included in 3.6.5, those should NOT be merged on ovirt-engine-3.6 until 3.6.5 will be branched out (date TBD, probably a couple of weeks before the release date). For further questions feel free to contact me. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Welcome: New ovirt.org website!
Hi Mikey, The new page looks really good. I figured out, that all of the links to presentations and templates are still pointing to the old Mediawiki url and so all presentations are unavailable: https://www.ovirt.org/community/get-involved/resources/slide-decks/ Regards, René On 02/19/2016 04:57 PM, Mikey Ariel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Following yesterday's pre-launch email[1], I'm happy to announce that the new ovirt.org[2] website is now live in **public beta** and available for community review. All the information in this email is also available in the first blog post of our shiny new oVirt blog[3]. Read on for information about new features, known issues, and a call for reviews. The old MediaWiki site is still available in read-only[4], and will be taken offline on **March 1, 2016**. This is to ensure that you can compare pages and review migrated content. What's New == The new Website is full of improvements and enhancements, check out these highlights: * Source content is now formatted in Markdown instead of MediaWiki. This means that you can create and edit documentation, blog posts, and feature pages with the same Markdown syntax you know. * The Website is deployed with Middleman and stored on GitHub. This means that you can make changes to content with the same GitHub contribution workflow that you know (fork, clone, edit, commit, submit pull request). We even have an "Edit this page on GitHub" link at the bottom of every page! * New layout and design, from breadcrumbs to sidebards and an upgraded landing page. (This is still WIP, please see known issues.) * Automatic redirects from the old MediaWiki site. This means that if the wiki page exists in the new website, previously-released URLs will redirect to that page. If the page was removed, the Search page will open with the page title auto-filled in the search box. * Hierarchical content structure. This means that instead of flat Wiki-style files, the deployed Website reflects an organized source repo with content sorted into directories and sub-directories. * Official oVirt blog! Our new blog welcomes contributions. This means that if you solved a problem with oVirt, want to share your oVirt story, or describe a cool integration, you can submit a pull request with a blog post and we will provide editorial reviews and help publish your posts. * Standardized contribution process. The GitHub repo now includes a README.md[5] file that you can use to learn about how to add and edit content on the website. We welcome pull requests! Known Issues Despite our best efforts, there are still a few kinks with the new website that you should be aware of: * Attempting to navigate to ovirt.org (without www.) leads to a redirect loop. We have a ticket open with OpenShift, our hosting service to fix this. * Only http is available. We also have a ticket with OpenShift to add SSL and enable https. * Home page and Download page are still being upgraded by our UX experts, expect some cool new changes soon! * Feature pages look-and-feel is still under construction. You can still edit and push feature pages as usual. What's Next === Even though the Website is live, the work is hardly over. We'd like to ask for your help in: * Reviewing content for anything obsolete or outdated (each page in the new website includes a header toolbar with metadata from the original wiki page for your convenience) * Submitting blog posts or any other content that you wish to share with the oVirt community * Reporting bugs and proposing enhancements, for example broken links or missing pages We hope you will enjoy the new oVirt Website, looking forward to your feedback and contributions! [1] http://lists.ovirt.org/pipermail/devel/2016-February/012372.html [2] http://www.ovirt.org/ [3] http://www.ovirt.org/blog/2016/02/welcome-to-new-ovirt-site/ [4] http://old.ovirt.org/Home [5] https://github.com/oVirt/ovirt-site/blob/master/README.md - -- Mikey Ariel Community Lead, oVirt www.ovirt.org "To be is to do" (Socrates) "To do is to be" (Jean-Paul Sartre) "Do be do be do" (Frank Sinatra) Mobile: +420-702-131-141 IRC: mariel / thatdocslady Twitter: @ThatDocsLady -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWxztZAAoJEHYPPTOszxHoOF4H/2UeK9JTspw4dYU+pUu8fKqf pSrE9ha3k9KpPnGIAx6VTnbXolNr9tHFiT8gcds1C9CVoMEPrKUxns9CTz3kPYBH /mGYCwQ+ncUNBCn+54uiKmXssaAtpVLnuxh8f1z9BDUoFjoY7ASLTzwXu9XTuH9V C9gaR0iGcRgSmBPjfPuAVWuHgimM068x5Ig2BoMSzAeCM7pO6LwiRzt3xX15xlR4 TMkUWLHdnJ1uL1GH267tMofrMnk25veDPIzuzIaPFjwIuTFgtwnUQI82ULbxcet2 NJ+y/UgwQ9JUQheoQL/oOsnSs244kFl0Vl+GuKMDGZ1FwCfoZerejnhEK+1cK0U= =KQLK -END PGP SIGNATURE- ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel smime.p7s Description: S/MIME Cryptographic Signature ___ Devel mailing list Devel@ovirt.org h
Re: [ovirt-devel] logging VDSM-generated libvirt XML properly
On Thu, Mar 3, 2016 at 4:28 PM, Martin Polednik
wrote:
> Hello developers!
>
> I've been chasing a bug that lead me to an idea of improving our XML
> logging. Now, to see a VMs generated libvirt XML, we have to rely on
> vdsm.log. The issue is that the log is rotating and therefore, it is
> easy to miss the correct XML when dealing with busy hypervisor.
>
> Since we're built on libvirt, I was thinking of doing similar thinks
> that libvirt does with qemu commandline. Each running domain(VM) has
> it's command line logged in /var/log/libvirt/qemu/${vmname}. This is
> great for debugging as you can mostly just take the cmdline and
> restart the VM.
>
> There is an issue with using the cmdline directly - networking.
> Libvirt uses additional script to create and up a bridge. Therefore,
> it is easier to use the XML and shape it to one's needs.
>
> I propose that we properly log the generated XML in a similar fashion
> as libvirt generates the cmdline. This means we would have path like
> /var/log/vdsm/libvirt/${vmname}, where generated XML would be stored.
> To minimize the logging requirements, only last definition of VM with
> that name may be stored. Additionally, exception level errors
> related to that VM could also be stored there.
>
Without history, it will much less useful, so I think we should keep this
in vdsm log.
How about creating separate log for virt?
We talked about separating the application to several parts, so we can
start by
having separate logs. In /var/log/vdsm/virt.log (or /var/log/vdsm/vms.log)
you
will see calls to the storage layer (service in the future), but you will
not see all
the noise that storage generates (e.g. resourseManager crap).
>
> What do you think, can we afford the space and additional writes per
> VM to help the debugging process?
>
We can, but the default log level should not show stuff like full xml dumps.
Nir
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] logging VDSM-generated libvirt XML properly
Hello developers!
I've been chasing a bug that lead me to an idea of improving our XML
logging. Now, to see a VMs generated libvirt XML, we have to rely on
vdsm.log. The issue is that the log is rotating and therefore, it is
easy to miss the correct XML when dealing with busy hypervisor.
Since we're built on libvirt, I was thinking of doing similar thinks
that libvirt does with qemu commandline. Each running domain(VM) has
it's command line logged in /var/log/libvirt/qemu/${vmname}. This is
great for debugging as you can mostly just take the cmdline and
restart the VM.
There is an issue with using the cmdline directly - networking.
Libvirt uses additional script to create and up a bridge. Therefore,
it is easier to use the XML and shape it to one's needs.
I propose that we properly log the generated XML in a similar fashion
as libvirt generates the cmdline. This means we would have path like
/var/log/vdsm/libvirt/${vmname}, where generated XML would be stored.
To minimize the logging requirements, only last definition of VM with
that name may be stored. Additionally, exception level errors
related to that VM could also be stored there.
What do you think, can we afford the space and additional writes per
VM to help the debugging process?
Regards,
mpolednik
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ANN] oVirt 3.6.3 Fourth Release Candidate is now available for testing
On Tue, Mar 1, 2016 at 8:02 PM, Sven Kieske wrote: > On 01.03.2016 10:32, Sandro Bonazzola wrote: > > No it isn't intentional. a bug in the migration tool dropped all bz > > references ( https://github.com/oVirt/ovirt-site/issues/98 ) > > > > > > > >> I'm talking about the "bugs fixed" section. > >> > >> furthermore it is not anymore updated what exactly was fixed in the last > >> RC etc. > >> > >> I found the old format way more helpful. > >> > > > > I agree. I'm trying to fix the release notes for today GA. > > > Thank you very much, it's much appreciated. > > Can't wait to test the GA in my dev system, but this will likely be > not this week, because I got higher priorities from my mgmt. > > kind regards > Looking forward to your feedback :-) > > Sven > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] python3-ovirt-engine-sdk4-4.0.0-0.0.20160302git42dbb0c.x86_64 missing deps on el7
On 03/03/2016 08:20 AM, Sandro Bonazzola wrote: > Hi, > > python3 is not available on el7, causing: > > * > * > > *00:17:51.028* Num Packages in Repos: 20203 > *00:17:51.028* package: > python3-ovirt-engine-sdk4-4.0.0-0.0.20160302git42dbb0c.x86_64 from > check-custom-el7 > *00:17:51.028* unresolved deps: > *00:17:51.028* python3-pycurl > *00:17:51.028* python3 > > > Please fix the spec file avoiding to build python3 modules on el7, thanks. > The .spec for this package doesn't build the Python 3 package: https://github.com/oVirt/ovirt-engine-sdk/blob/master/packaging/spec.el7.in Only the Fedora 23 .spec does: https://github.com/oVirt/ovirt-engine-sdk/blob/master/packaging/spec.fc23.in You can also verify that the Jenkins build for el7 didn't produce a Python 3 package: http://jenkins.ovirt.org/job/ovirt-engine-sdk_master_build-artifacts-el7-x86_64/29 So the problem must be somewhere else. Maybe the fact that the .rpm file doesn't contain the distribution tag? -- 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. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
