his implemented outside of libvirt.
Thanks in advance,
Lee
--
Lee Yarwood
Red Hat
PGP : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
Hello all,
$subject, for example with Kilo :
https://launchpad.net/nova/kilo/2015.1.2/+download/nova-2015.1.2.tar.gz
If not, should we be using http://tarballs.openstack.org/nova/
directly for these stable releases?
Thanks in advance,
Lee
--
Lee Yarwood
Senior Software Engineer
Red Hat
PGP
s in advance,
Lee
[1]
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/libvirt-qemu-native-luks.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106956.html
--
Lee Yarwood A5D1 9385 88CB 7E5F
On 25-05-17 11:38:44, Duncan Thomas wrote:
> On 25 May 2017 at 11:00, Lee Yarwood wrote:
> > This has also reminded me that the plain (dm-crypt) format really needs
> > to be deprecated this cycle. I posted to the dev and ops ML [2] last
> > year about this but received
On 25-05-17 11:00:26, Lee Yarwood wrote:
> Hello all,
>
> I'm currently working on enabling QEMU's native LUKS support within Nova
> [1]. While testing this work with Barbican I noticed that Cinder is
> creating symmetric keys for use with encrypted volumes :
>
&g
On 26-05-17 17:25:15, Duncan Thomas wrote:
> On 25 May 2017 12:33 pm, "Lee Yarwood" wrote:
>
> On 25-05-17 11:38:44, Duncan Thomas wrote:
> > On 25 May 2017 at 11:00, Lee Yarwood wrote:
> > > This has also reminded me that the plain (dm-crypt) format really
ith the native LUKS support in QEMU we can now
skip the use of the front-end encryptors entirely. We simply provide the
passphrase via a libvirt secret associated with the volume that is then
passed to QEMU in a secure fashion [1] to unlock the LUKS volume.
[1]
https://www.berrange.com/posts/2016/04/
f you were
present at the previous discussions in Boston!
https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
Thanks in advance and see you in Denver!
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33
On 21-08-17 15:56:53, Lee Yarwood wrote:
> Hello all,
>
> This is a brief announcement to highlight that there will be a skip
> level upgrades room again at the PTG in Denver. I'll be chairing the
> room and have seeded the etherpad below with a few goal and topic ideas.
fline-migration
[3]
https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html
[4]
https://governance.openstack.org/tc/reference/tags/assert_supports-accessible-upgrade.html
[5]
https://github.com/NguyenHoaiNam/Jump-Over-Release/blob/test_dynamic_section/README.md
--
Lee Yarwood
ant to reach out to him to help craft the agenda for the
session based on our discussions in Denver.
Thanks again,
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
__
OpenStack Development
sic-flow
[2]
https://github.com/openstack-dev/grenade/blob/03de9e0fc7f4fc50a00db5d547413e26cf0780dd/grenade.sh#L315-L317
[3]
https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/resources.sh#L134-L137
[4]
https://github.com/openstack-dev/grenade/blob/master/projects/70_cinder/resou
pu with
libvirt) etc upgrades that require reboots or instances to be restarted
(either hard or via live-migration). If you're unable or just unwilling
to take downtime for instances that can't be moved when these components
require an update then you have bigger problems IMHO.
Regar
ed)
FWIW I can deploy successfully on Newton with these changes and then
upgrade the undercloud to Pike just fine.
Would anyone be able to confirm *if* we could ship python-virtualbmc in
the Newton relevant repos?
Thanks in advance,
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64
e
> reason.
Yeah we appear to be shipping python-pyghmi-1.0.12-1.el7.noarch in
newton-testing and that meets the requirements of python-virtualbmc
allowing me to directly install it from the Ocata repos.
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
si
Adding rdo-list in an attempt to get more feeback regarding this
proposal, tl;dr can we ship python-virtualbmc in Newton?
On 04-10-17 12:08:25, Lee Yarwood wrote:
> Hello all,
>
> I'm currently working to get the tripleo-spec for fast-forward upgrades
> out of WIP and merged ah
On 05-10-17 09:33:29, Steven Hardy wrote:
> On Wed, Oct 4, 2017 at 1:08 PM, Lee Yarwood wrote:
> > Hello all,
> >
> > I'm currently working to get the tripleo-spec for fast-forward upgrades
> > out of WIP and merged ahead of the Queens M-1 milestone next wee
https://review.rdoproject.org/r/9981 Add python-virtualbmc to Newton
Thanks!
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP signature
__
OpenStack Development M
On 05-10-17 09:57:26, Lee Yarwood wrote:
> On 05-10-17 09:33:29, Steven Hardy wrote:
>> This sounds reasonable to me, but note another option for testing
>> fast-forward overcloud upgrades would be to deploy a trunk/pike
>> undercloud, then use it to deploy a newton
ar/log/yum.log
$
The weird thing is that the repo-setup role doesn't appear to run at all with
the above config. Something is obviously changing the repos and running `yum
update -y` prior to the overcloud instances being provisioned but I can't seem
to track it down. Any suggestions would be
On 01-11-17 18:50:23, Lee Yarwood wrote:
> Hello all,
>
> I'm attempting save future contributors to the fast forward upgrades feature
> some time by introducing a quickstart release config that deploys a Master UC
> and Newton OC:
>
> config: Provide a Master UC an
On 10-11-17 09:25:14, Lee Yarwood wrote:
> On 01-11-17 18:50:23, Lee Yarwood wrote:
> > Hello all,
> >
> > I'm attempting save future contributors to the fast forward upgrades feature
> > some time by introducing a quickstart release config that deploys a
ast few
months!
Cheers,
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
sk to backport all the way to
> Newton.
FWIW this is the master change - https://review.openstack.org/#/c/528012/
Cheers,
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP signature
ore detail, background etc. Thanks in advance,
Lee
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage
A breif progress update in-line below.
On 22-01-18 14:22:12, Lee Yarwood wrote:
> Hello,
>
> With M3 and FF rapidly approaching this week I wanted to post a brief
> overview of the QEMU native LUKS series.
>
> The full series is available on the following topic, I'll g
On 23-01-18 16:52:30, Corey Bryant wrote:
> On Tue, Jan 23, 2018 at 8:44 AM, Lee Yarwood wrote:
>> grenade-dsvm-neutron-multinode-live-migration is currently failing due
>> to our use of the Ocata UCA on stable/pike leading to the following
>> issue with the libvirt 2.
On 23-01-18 13:44:49, Lee Yarwood wrote:
> A breif progress update in-line below.
>
> On 22-01-18 14:22:12, Lee Yarwood wrote:
> > Hello,
> >
> > With M3 and FF rapidly approaching this week I wanted to post a brief
> > overview of the QEMU native LUKS se
gs
> block_device_mapping in image and one provied manually.
> But rebuilding instance from the image ignores the block_device_mapping
> attribute. Should we
> replace all origin volumes by new volumes provided byimage
> block_device_mapping attribute
> according to device name?
I *
enstack-dev/2016-July/098792.html
> [2] http://45.55.105.55:3000/dashboard/db/openstack-bugs
> [3]
> https://github.com/markuszoeller/openstack/blob/master/scripts/gerrit/bug_fix_histogram.py
Thanks for bringing this up Markus! IMHO tags against either in-progress
launchpad bugs and/or ger
fu-ptg-rocky
I'll get this added to the list now and will send a separate note to the
ML later today seeking additional input on the agenda.
Cheers,
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
is not listed in [2].
>
> Indeed, the etherpad is missing, and I realize we don't have anyone
> signed up yet to clearly lead that track...
>
> Is anyone interested in leading that track ?
I did sign up a while ago, I've just failed to follow up during the last
few week
pad, I'd really like to see some
concrete action items finally come from these discussions ahead of R.
Thanks in advance and see you in Dublin!
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP sign
could be due
to a complete lack of locking when creating the initial attachment but I
might be missing something here. I've marked this as impacting both Nova
and Cinder for now while but if I'm honest this strikes me as something
we need to resolve in c-api alone.
Cheers,
--
L
stack.org/nova/latest/cli/nova-status.html
> [3] https://review.openstack.org/#/c/575125/
Cheers,
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
__
OpenStack Development Mailing L
t the moment. I'm stating that,
> especially because we had this topic a few weeks ago.
We can bump the minimum here but then we have to play a game of working
out the oldest version the above fix was backported to across the
various distros. I'd rather see this address by the Libvir
On 20-06-18 07:32:08, Matt Riedemann wrote:
> On 6/20/2018 6:54 AM, Lee Yarwood wrote:
> > We can bump the minimum here but then we have to play a game of working
> > out the oldest version the above fix was backported to across the
> > various distros. I'd rather see t
On 20-06-18 13:54:29, Lee Yarwood wrote:
> On 20-06-18 07:32:08, Matt Riedemann wrote:
> > On 6/20/2018 6:54 AM, Lee Yarwood wrote:
> > > We can bump the minimum here but then we have to play a game of working
> > > out the oldest version the above fix was backported
_
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/op
heading off this class of bug by disabling it for non-cinder
> callers.
I'm definitely in favor of hiding this from users eventually but
wouldn't this require some form of deprecation cycle?
Warnings within the API documentation would also be useful and even
something we could backport to
week with
> no negative votes I think it's a done deal. Of course +1/-1 from existing
> nova-stable-maint [2] is also good feedback.
>
> [1] https://review.openstack.org/#/admin/groups/530,members
> [2] https://review.openstack.org/#/admin/groups/540,members
+1 from
[1] and would be
happy to help with this puppet extraction.
Cheers,
Lee
[1] https://gitlab.com/lyarwood/placement-distgit
--
Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
signature.asc
Description: PGP signature
_
On 17-09-18 08:48:01, Emilien Macchi wrote:
> On Mon, Sep 17, 2018 at 5:29 AM Lee Yarwood wrote:
>
> > FWIW I've also started work on the RDO packaging front [1] and would be
> > happy to help with this puppet extraction.
> >
>
> Good to know, thanks.
> Onc
On 30-10-18 14:29:12, Emilien Macchi wrote:
> On the TripleO side, it sounds like Lee Yarwood is taking the lead with a
> first commit in puppet-placement:
> https://review.openstack.org/#/c/604182/
>
> Lee, can you confirm that you and your team are working on it for Stein
>
Lee
[1] https://launchpad.net/bugs/1633518
[2] https://review.openstack.org/#/c/309614/
[3] https://review.openstack.org/#/c/386670/
--
Lee Yarwood
Senior Software Engineer
Red Hat
PGP : A5D1 9385 88CB 7E5F BE64 6618 BCA6
Does anyone have any thoughts on how to proceed with this issue?
>
> No particular ideas, but I wanted to point out that the scsi_id command
> shown in that stack trace has a device path that points to the raw
> iSCSI LUN, not to the dm-crypt overlay. So it looks like you're h
on and thus working
around your issue.
Lee
> From: Lee Yarwood
> Sent: 01 November 2016 14:58:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] [cinder] Issue with live migration of
> instances with encrypted volumes
>
e multiple times on the destination host.
Lee
> From: Lee Yarwood
> Sent: 02 November 2016 08:17:35
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] [cinder] Issue with live migration of
> instances with encrypted volumes
&g
On 07-11-16 17:42:02, Lee Yarwood wrote:
> Hello all,
>
> The following bug was recently discovered where encrypted volumes
> created prior to Newton use a slightly mangled passphrase :
>
> The passphrase used to encrypt or decrypt volumes was mangled prior to Newton
> https
49 matches
Mail list logo
