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]
> 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
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
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
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
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
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
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
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
>> 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
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
> > 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
> 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
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
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
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
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
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
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
> 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
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
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
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
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:
> 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
-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
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
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
-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
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
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
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
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
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:
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
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
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:
-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
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
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
- 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
...@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
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
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
+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
-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
-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
-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
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
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
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
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
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
-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
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
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
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
[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
: 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
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
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
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
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
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
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
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
66 matches
Mail list logo