Re: [openstack-dev] [Nova] Future meeting times

+1 here too - I'd love to be able to attend alternate weeks. Bob -Original Message- From: Gary Kotton [mailto:gkot...@vmware.com] Sent: 18 December 2013 14:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Future meeting times

Re: [openstack-dev] XenAPI / XCP going away from Debian Ubuntu

Hi Thomas, This means that it will also be impossible to support XCP support in OpenStack, unfortunately (the support for XCP was removed a few months ago because that was blocking migration to Debian testing anyway). Just a quick note - there are two separate issues here which some might

Re: [openstack-dev] [Nova] Meetup Summary

From: Russell Bryant [rbry...@redhat.com] Sent: 17 February 2014 22:41 To: OpenStack Development Mailing List Subject: [openstack-dev] [Nova] Meetup Summary 5) Driver CI - We talked about the ongoing effort to set up CI for all of the compute drivers. The discussion was mostly a status

Re: [openstack-dev] [qa] Can't interpret failure from XenServer CI

Hi David, That's a very strange error - it basically means the node has been used for running a test already (both the first error in run_tests.log about the git repository also existing, and the more fatal error about vif 3 existing) I believe this was my fault - I should have purged all

Re: [openstack-dev] [qa] Can't interpret failure from XenServer CI

- thanks for letting us know. Bob From: Bob Ball Sent: 23 February 2014 20:29 To: David Kranz; #OpenStack External Email Cc: OpenStack Development Mailing List Subject: RE: [qa] Can't interpret failure from XenServer CI Hi David, That's a very strange error

Re: [openstack-dev] [qa] Can't interpret failure from XenServer CI

...@redhat.com] Sent: 23 February 2014 21:17 To: Bob Ball; #OpenStack External Email Cc: OpenStack Development Mailing List Subject: Re: [qa] Can't interpret failure from XenServer CI On 02/23/2014 03:29 PM, Bob Ball wrote: Hi David, That's a very strange error - it basically means the node has

[openstack-dev] Today's XenAPI meeting

Just a quick note to say that we're skipping the XenAPI meeting this week as a couple of key participants have other commitments. Normal service will resume next week. Bob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Hyper-V] Havana status

-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 11 October 2013 15:18 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Hyper-V] Havana status As a practical example for Nova: in our case that would simply include the following

Re: [openstack-dev] [Hyper-V] Havana status

From: Alessandro Pilotti [apilo...@cloudbasesolutions.com] Sent: 12 October 2013 20:21 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Hyper-V] Havana status 1) All the drivers will still be part of Nova. 2) One official project

Re: [openstack-dev] [nova] [tempest] [ceilometer] Looking for clarification on the diagnostics API

I'm happy with that approach - again I've not seen any discussions about how this should be done. I've added [tempest] and [ceilometer] tags so we can hopefully get input from the guys involved. Bob From: Gary Kotton [mailto:gkot...@vmware.com] Sent: 13 October 2013 05:21 To: OpenStack

Re: [openstack-dev] Setting up compute node on XenServer.

Hi Parikshit, More details can be extracted by setting debug=true in /etc/nova/nova.conf or setting default_log_levels to include nova.virt.xenapi.driver=debug. This is likely to be a mis-configured nova.conf - check

Re: [openstack-dev] [Neutron] Security groups with XenAPI

Hi Simon, Yes, I believe you are right. We were already planning to discuss this very topic at the XenAPI roadmap session at the summit. Hopefully someone will take on tying up this loose end there. Security group support is the only thing we are aware of that is missing from the XenAPI

Re: [openstack-dev] Unable to logging to guest console on XCP/xenserver

The trace below seems to be wanting to access the console log, rather than the VNC console. I believe there is a blog post about how to enable this, but basically you need a cronjob to run in dom0 to rotate the logs. This is because the Xen console logging is not ring-based, and therefore

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 25 November 2013 22:37 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan On 11/25/2013 05:19 PM, Matt Riedemann wrote: I'll play

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 26 November 2013 13:56 To: openstack-dev@lists.openstack.org Cc: Sean Dague Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan On 11/26/2013 04:48 AM, Bob Ball wrote: I

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

-Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 26 November 2013 19:33 To: OpenStack Development Mailing List Subject: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core I would like to propose that we re-add Dan Prince to the nova-core

Re: [openstack-dev] Devstack (icehouse) - XCP - enable live migration

Hi Afef, There was a regression in Icehouse that broke XenAPI aggregates. This has been fixed in Juno, however we would recommend you use live migrate with block migration (using XCP 1.6 or XenServer 6.2 – which is Free as well now, see

Re: [openstack-dev] [infra] recheck no bug and comment

-Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 25 July 2014 12:36 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [infra] recheck no bug and comment Would that still allow us to only trigger 3rd party CI ? eg if we do 'recheck xenserver' I

Re: [openstack-dev] Info on XenAPI data format for 'host_data' call

Hi Daniel, The following is an example return value from one of my hosts {host_name-description: Default install of XenServer, host_hostname: ciceronicus, host_memory: {total: 17169604608, overhead: 266592256, free: 16132087808, free-computed: 16111337472}, enabled: true, host_capabilities:

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

Images Ideation | Intellection | Activator | Relator | Responsibility Phone: (512) 788 5403 - Cell: (512) 736-7897 (Austin) Skype: rtgoodwinfile:///\\callto\::rtgoodwin - Yahoo: richardtgoodwinfile:///\\ymsgr\sendim%3Frichardtgoodwin AIM: dellovision - IRC: goody / rgoodwin From: Bob Ball bob.b

Re: [openstack-dev] There are no OpenStack talks submitted to XenCon, CFP ends this week

The CFP is at http://events.linuxfoundation.org/events/linuxcon-north-america/program/xen-project-user-summit - this is for the Xen User Summit as part of linuxcon. While it might not have OpenStack in the title, I'm aware of at least one talk which has already been submitted with a strong

Re: [openstack-dev] GPU passthrough support blueprints for OpenStack

Hi Brian, Instead of specific GPU pass-through there are blueprints for generic PCI pass through at https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base - these are being worked on for Havana and we're hopeful they will get in (possibly libvirt only) In terms of vGPU rather than

Re: [openstack-dev] General Question about CentOS

I'm running the unit tests and can confirm they do work. I'm currently developing support for xenserver-core on CentOS 6.4 and many of the tempest tests pass, and I'm working through the failures that exist. I haven't encountered anything yet which is caused by CentOS so I imagine it will all

Re: [openstack-dev] live-snapshot/cloning of virtual machines

I agree with the below from a XenServer perspective. As with vmware, XenServer supports live snapshotting and creating multiple clones from that live snapshot. I understand that there is a XenAPI equivalent in the works and therefore would argue the API changes need to be accepted as a

[openstack-dev] Clarification of XenServer versions

I've received a number of questions recently about XenServer and XCP and how they are different - particularly now that XS 6.2 has been released - so thought I should try and get the answers all in one place. XenServer: As of XS 6.2, it was announced that it will be fully open sourced[1] and

Re: [openstack-dev] [Nova] FFE Request: oslo-messaging

Puppet is failing to build the packages - which is probably understandable given it's a refactor. I'm not sure if this is something that points to a problem with the refactor or the packaging itself - hopefully Dan can review the logs, or if others want to see more of the details look at the

Re: [openstack-dev] [DevStack] Generalize config file settings

The biggest concern I have about the current implementation is that it handles conf files inconsistently - but as Dean pointed out on the review it opens a wider question. I will very often run devstack, find something not quite working unstack, change a value or two in localrc and then re-run

Re: [openstack-dev] [DevStack] Generalize config file settings

[mailto:dtro...@gmail.com] Sent: 18 September 2013 13:37 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [DevStack] Generalize config file settings On Wed, Sep 18, 2013 at 4:46 AM, Bob Ball bob.b...@citrix.commailto:bob.b...@citrix.com wrote: I understand that there are some very

Re: [openstack-dev] [DevStack] Generalize config file settings

: 18 September 2013 15:04 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [DevStack] Generalize config file settings On Wed, Sep 18, 2013 at 7:49 AM, Bob Ball bob.b...@citrix.commailto:bob.b...@citrix.com wrote: In which case, would a simple fix of adding a localrc.generated

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

The blueprint currently seems libvirt specific to me? Is there a common - perhaps abstracted - interface that we can provide through Nova / image meta-data which will be implemented by each driver in their own way? Otherwise I can see a bigger mess of metadata values where libvirt uses

Re: [openstack-dev] [Neutron] XenAPI questions

Hi Yamamoto, XenAPI and Neutron do work well together, and we have an private CI that is running Neutron jobs. As it's not currently the public CI it's harder to access logs. We're working on trying to move the existing XenServer CI from a nova-network base to a neutron base, at which point

Re: [openstack-dev] Fwd: Image Upload error while installing devstack on CI slave machine.

Hi Abhishek, This is bug https://launchpad.net/bugs/1415795 introduced by https://review.openstack.org/#/c/142967/ because Swift doesn't use olso.config. The fix is at https://review.openstack.org/#/c/151506/ which has not yet been approved, but if you can cherry-pick it for your CI it should

Re: [openstack-dev] [Neutron] XenAPI questions

Hi, The next meeting will be tomorrow @ 15:00 UTC - We'd love to see you there and we can talk about the CI and Terry's work. We're currently meeting fortnightly and skipped one due to travel, which is why there haven't been minutes recently. Thanks, Bob -Original Message- From:

Re: [openstack-dev] [OpenStack-Infra] Devstack error when running g-reg: 401 Unauthorized

This is likely https://launchpad.net/bugs/1415795 which is fixed by https://review.openstack.org/#/c/151506/ Make sure you have the above change in your devstack and it should work again. Bob From: liuxinguo [mailto:liuxin...@huawei.com] Sent: 06 February 2015 03:08 To: OpenStack Development

Re: [openstack-dev] [neutron] The future of Xen + OVS support

We certainly care about this but converting the XenServer CI to Neutron+OVS has been hitting a number of issues (notably a few concurrency ones – although there are a few missing features) that we’ve been trying to sort through. I am certainly hoping that we’ll have everything stable enough to

Re: [openstack-dev] [infra] request to disable xenserver CI account

Sorry all for this breakage; I've been on vacation and didn't set up adequate cover. Thanks for disabling it and we'll let everyone know when the job is ready to start commenting and hopefully voting on changes in the very near future. Regards, Bob

Re: [openstack-dev] [nova] Mellanox CI Issues

-Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] On 5 June 2015 at 15:29, Moshe Levi mosh...@mellanox.com wrote: I talked also with John Garbutt and it seem that the recommendation is to filter only doc and test folders, but still I would like to filter some

Re: [openstack-dev] [nova] Network issue with libvirt-xen driver, iptables race

Hi Anthony, The Xen script is simply calling those commands: ... iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in $dev -j ACCEPT iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out $dev -j ACCEPT Are you saying that these two commands aren't needed to be

[openstack-dev] [Nova] [XenAPI] New meeting time

Hi all, To be able to involve some new sub-team members in China, we've moved the meeting times as discussed in the last two XenAPI meetings. The new time is at 0930 UTC, Alternate Wednesdays, with the next meeting at 0930 UTC on 8th July. See you there! Bob

Re: [openstack-dev] [nova] xen project retrigger

Hi Gary, It should have been included in the comment - what was the changeset that failed? For reference a recheck can be triggered with xen: recheck Thanks, Bob From: Gary Kotton [mailto:gkot...@vmware.com] Sent: 25 May 2015 16:21 To: OpenStack List Subject: [openstack-dev] [nova] xen

Re: [openstack-dev] [Openstack-operators] [nova] can we deprecate the xvp console?

> I noticed today that nova.console.xvp hits the database directly for > console pools. We should convert this to objects so that the console > service does not have direct access to the database (this is the only > console I see that hits the database directly). However, rather than go > through

Re: [openstack-dev] [all][third-party][ci] Announcing CI Watch - Third-party CI monitoring tool

-Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: 25 August 2015 01:44 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][third-party][ci] Announcing CI Watch - Third-party CI monitoring tool We have a number of people working on

Re: [openstack-dev] [Nova][Glance] Xenplugin + Glance_v2 = Hate

Hi Mikhail, Unfortunately I completely agree that using Glance with the XenServer plugin is painful. As Keven pointed out, the current release of XenServer includes python 2.4 in dom0 (where the plugin runs) so having a dependency on nova.image or glanceclient is likely to introduce more pain

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky > wrote: > > What about hypervisor "Qemu", and checkbox option on Settings tab - > > "Use KVM extension"? > Qemu is not a hypervisor This will be even more confusing. > I think "Libvirt" + some tooltip which says "Qemu and

Re: [openstack-dev] [devstack]Question about using Devstack

Hi, Devstack is intended for development, so when you reboot it is not expecting to be able to preserve any information, and will give you a fresh environment to continue development on. The XenServer devstack installation uses a separate VM, but devstack is automatically run at boot, as

Re: [openstack-dev] [devstack]Question about using Devstack

Ah yes - I’d forgotten about OFFLINE=True (shows how often I use it!) If you set this in your localrc file then yes, in theory it should work offline – but will still generate a new environment when you reboot the VM. Bob From: yatin kumbhare [mailto:yatinkumbh...@gmail.com] Sent: 23 November

Re: [openstack-dev] [devstack]Question about using Devstack

mode, but you may be able to use other services if you remove tempest from ENABLED_SERVICES. @jordan.pittier @Bob Ball If I can ensure my IP address , localrc and everything else are not changed, is there any way I can achieve my goal? I don’t think I understand what your goal is – perhaps

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

There was a conversation a while ago around explicitly avoiding the empty namespace - see http://lists.openstack.org/pipermail/openstack-dev/2014-July/041238.html The approach I have used since is "xenserver: recheck" and "xen: recheck". I think the appropriate command should be "fuel:

[openstack-dev] [Nova] Virtual GPU provisioning

How should we expose Virtual GPUs to Nova? Various discussions have happened on the original spec submission for Mitaka[1] and the recent submission for Newton[2], however there are a few questions which need further discussion. But before those question (at the end), some thinking behind the

Re: [openstack-dev] [tempest] Discussion on to enable "Citrix XenServer CI" to vote openstack/tempest

Hi Masayuki, We have been running against Tempest and commenting for many months (years?) and run in the Rackspace public cloud so have no capacity issues. Indeed the execution time is longer than other jobs, because we actually have to use double nesting (Devstack running on Ubuntu in a VM

[openstack-dev] [fuel] [plugins] Requesting voting permissions

The ACL at https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/fuel-plugin-xenserver.config shows that, in order for our CI to vote on the fuel-plugins-xenserver project, we need to be in the fuel-plugins-ci group. As such, could I request that the "Citrix

Re: [openstack-dev] [nova] driver review dashboards

Hi Sean, > [section "XenServer"] > query = label:Code-Review>=1,bob.b...@citrix.com file:xenserver I believe this should be file:xenapi? Can you match multiple files here? Most files are under the xenapi trees, but it would miss some files in plugins/xenserver and not in

Re: [openstack-dev] [nova] FYI: Citrix XenServer CI is disabled from voting

The failure rate was indeed 100%; there were some requirements on packages not installed in our CI environment (libssl-dev libffi-dev) which were causing all failures. This is now fixed and the CI is back to voting on passing changes. I have re-queued all jobs which failed in less than 6

Re: [openstack-dev] Nova mascot

> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll be > missed. :-) It also seems from http://www.openstack.org/project-mascots that the majority of OpenStack projects have selected a mascot. I think it would be a great shame if the Nova project didn’t have an easily

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

> > Oslo.privsep seem try to launch a daemon process and set caps for this > daemon; but for XenAPI, there is no need to spawn the daemon. > > I guess I'm lacking some context... If you don't need special rights, why use > a > rootwrap-like thing at all ? Why go through a separate process to

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

Hi Ihar, > I am puzzled. Is Neutron the only component that need to call to dom0? No it's not. Nova has similar code to call plugins in dom0[1], and Ceilometer will also need to make the calls for some metrics not exposed through the formal API. We don't want code duplication, and are

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

>> Side note: we should first have Xen third-party CI testing running > > It already is running > Oh right. It does not validate the new change though. Would be nice to see > the new ‘daemon’-ic mode behaves in real world. 100% agreed. I'll work with Jianghua to make sure we get automated

Re: [openstack-dev] vGPUs support for Nova - Implementation

Hi Sahid, > Please consider the support of MDEV for the /pci framework which provides > support for vGPUs [0]. From my understanding, this MDEV implementation for vGPU would be entirely specific to libvirt, is that correct? XenServer's implementation for vGPU is based on a pooled device model

Re: [openstack-dev] vGPUs support for Nova - Implementation

Hi Sahid, > > a second device emulator along-side QEMU. There is no mdev > > integration. I'm concerned about how much mdev-specific functionality > > would have to be faked up in the XenServer-specific driver for vGPU to > > be used in this way. > > What you are refering with your DEMU it's

Re: [openstack-dev] [nova] reboot a rescued instance?

Hi Matt, My understanding is that this is being used by Rackspace. AFAIK the change isn't upstream because there was no sensible way to permit reboot of a rescued instance for XenAPI users but prevent it for other drivers. I'd be hesitant to permit reboot-from-rescue for all drivers as I'm not

Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

Hi Thomas, As noted on the patch, XenServer only has python 2 (and some versions of XenServer even has Python 2.4) in domain0. This is code that will not run in Debian (only in XenServer's dom0) and therefore can be ignored or removed from the Debian package. It's not practical to convert

Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

Sent: Thursday, 15 February 2018 6:39 p.m. To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens 2018-02-15 11:25 GMT+01:00 Bob Ball <bob.b...@c

Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently because of placement update

> Yeah, the nova.CONF cpu_allocation_ratio is being overridden to 0.0: The default there is 0.0[1] - and the passing tempest-full from Zuul on https://review.openstack.org/#/c/590041/ has the same line when reading the config[2]: We'll have a dig to see if we can figure out why it's not

Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently because of placement update

We're not running with [1], however that did also fail the CI in the same way - see [2] for the full logs. The first failing appeared to be around Aug 27 08:32:14: Aug 27 08:32:14.502788 dsvm-devstack-citrix-lon-nodepool-1379254 devstack@placement-api.service[13219]: DEBUG

Re: [openstack-dev] [nova][xenapi] does get_all_bw_counters driver call nova-network only?

As far as I remember this isn't a nova-network only feature; but I may be missing something. I believe the bandwidth counters may be being used at Rackspace. Bob -Original Message- From: Balázs Gibizer [mailto:balazs.gibi...@ericsson.com] Sent: 16 April 2018 13:37 To: OpenStack-dev

Re: [openstack-dev] [nova][xenapi] can we deprecate the xenapi-specific 'nova-console' service?

Hi Melanie, We recommend using novncproxy_base_url with vncserver_proxyclient_address set to the dom0's management IP address. We don't currently use nova-console, so deprecation would be the best approach. Thanks, Bob -Original Message- From: melanie witt [mailto:melwi...@gmail.com]