Re: [Openstack-operators] [nova] FYI: live_migration_progress_timeout will default to 0 and be deprecated in Ocata

[Belmiro Moreira]

+1
We use "block-migration" and we needed to disable this timeout.

Belmiro
CERN

On Thu, Feb 9, 2017 at 5:29 PM, Matt Riedemann  wrote:

> This is just a heads up to anyone running with this since Liberty, there
> is a patch [1] that will go into Ocata which deprecates the
> live_migration_progress_timeout config option used in the libvirt driver.
> The default value will also change to 0, effectively disabling the feature.
> See the patch and related bug report for more details.
>
> If you've seen issues trying to use this feature, and can confirm this or
> think it's actually wrong, please speak up soon (final Nova ocata tag is on
> 2/16).
>
> [1] https://review.openstack.org/#/c/429798/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [nova] Next minimum libvirt version

[Steve Gordon]

- Original Message -
> From: "Matt Riedemann" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> ,
> openstack-operators@lists.openstack.org
> Sent: Thursday, February 9, 2017 6:29:22 PM
> Subject: [openstack-dev] [nova] Next minimum libvirt version
> 
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
> had 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.

This would also kill off RHEL/CentOS 7.1 support but that would also seem to be 
OK at this point.

> There is also the distro support wiki [1] which hasn't been updated in
> awhile.

I've added the details I have for Fedora 25 and RHEL/CentOS 7.3, TL;DR:

Fedora 25:
Libvirt 2.2.0
Qemu 2.7.1
Libguestfs 1.34.3

RHEL 7.3:
Libvirt 2.0.0
Qemu 2.6.0
Libguestfs 1.32.7
 

> I'm wondering if 1.2.9 is a safe move for the next required minimum
> version and if so, does anyone have ideas on the next required version
> after that?
> 
> I'm hoping some of the Red Hat people can chime in here.

I just play someone intelligent on TV so adding Sahid and Vladik who might be 
better placed to comment in Dan's absence.

Thanks,

Steve

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] Next minimum libvirt version

[Matt Riedemann]

Since danpb hasn't been around I've sort of forgotten about this, but we 
should talk about bumping the minimum required libvirt version in nova.


Currently it's 1.2.1 and the next was set to 1.2.9.

On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04 
had 1.2.2).


If we move to require 1.2.9 that effectively kills 14.04 support for 
devstack + libvirt on master, which is probably OK.


There is also the distro support wiki [1] which hasn't been updated in 
awhile.


I'm wondering if 1.2.9 is a safe move for the next required minimum 
version and if so, does anyone have ideas on the next required version 
after that?


I'm hoping some of the Red Hat people can chime in here.

[1] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

--

Thanks,

Matt Riedemann

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] FYI: live_migration_progress_timeout will default to 0 and be deprecated in Ocata

[David Medberry]

On Thu, Feb 9, 2017 at 9:29 AM, Matt Riedemann  wrote:

>
Thanks for the heads up Matt, ops appreciate.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [LCOO] Intro to Large Contributing

[Hayes, Graham]

On 09/02/2017 16:37, Jeremy Stanley wrote:
> On 2017-02-09 00:59:52 + (+), UKASICK, ANDREW wrote:
> [...]
>> I'm the mysterious "AndyU" who was chatting with you about a year
>> ago in IRC with questions about how to go about donating hosted
>> cloud resources for use by the Infra team. It's nice to bump into
>> you again! ;-) That idea is still stirring btw, but has been much
>> slower moving than I'd hoped.
> [...]
>
> Always appreciated, and happy to pick that back up if and when
> you're ready.
>
>> I've been having a pretty lengthy conversation with jay Pipes
>> regarding similar questions. You can catch up on that in the
>> thread below this one.
>
> I've been following it closely, and tried not to duplicate
> questions/comments as much as possible.
>
>> LCOO is unlike any other working groups that I'm familiar with in
>> some significant ways. You zero'd in on one of those in your
>> statements above about companies joining as opposed to
>> individuals. In that regard, LCOO is similar to an entity like
>> OSIC.org as opposed to a traditional working group.
> [...]
>
> This is probably where some of the confusion comes in for me; I
> expect it's just one of terminology/semantics. The OpenStack User
> Committee has specifically tied "Active members and contributors to
> functional teams and/or working groups" to its electorate in their
> charter, and also defines working groups as "teams" (which to me
> implies they're made up of individuals, not organizations):
>
> https://governance.openstack.org/uc/reference/charter.html
>
> Maybe LCOO is something other than a "working group" in the formal
> UC sense? Or maybe the organizations who participate in the LCOO
> designate representatives (those LCOO "organization coordinators"
> and "governance board" mentioned in your wiki article) who are the
> actual working group as far as the UC is concerned? I'm just
> concerned if, for example, all employees within AT suddenly become
> part of the UC electorate by way of AT as an organization being an
> active "member" of an official UC working group. The only way I can
> really see this working is if the UC insists that its working groups
> are made up of individuals and not whole organizations.
>
>> Jira provides Kanban boards that can serve as a kind of dashboard
>> allowing us to visualize activity and current status of Community
>> activity. But that activity is still happening in Launchpad,
>> Gerrit, etc.
> [...]
>
> Cool, so it sounds like StoryBoard may work out for you in the
> long-run. It already has kanban and worklist support with optional
> automation tied directly to defect/feature tracking and code review.
> As the current effort to move our community from launchpad.net to
> storyboard.openstack.org progresses over the next couple of
> development cycles, I encourage you to check it out and start
> thinking about whether its features address your needs (or consider
> pitching in on further development there).
>
>> Automating the status updating is something I've begun to discuss
>> within the PWG's "Story Tracker" team. We have the same challenge
>> there.
> [...]
>
> Our hope is that once we get further along with the current
> migration blockers for StoryBoard, we'll implement an "epics"
> concept in it which ties individual stories and their tasksets to
> over-arching efforts where their progress can be tracked more
> holistically.
>
>> BTW, Atlassian has always made their tools free for use by open
>> source projects. Also, although they're commercial products they
>> do provide the source code and allow users to modify it freely
>> which makes them much more open-source-ish than most.
> [...]
>
> 
> Yes, I saw you mention it in the other ML thread. "Free as in beer"
> is a somewhat dirty concept in free software development circles,
> and our community infrastructure similarly eschews gratis services
> like GitHub in favor of libre alternatives (we provide read-only
> mirrors there on request, but don't rely on it in any of our
> automation and officially recommend git.openstack.org which runs
> entirely on free software).
>
> As an author of free software myself I prefer when people use and
> help improve OpenStack rather than supporting commercial/proprietary
> solutions to accomplish the same tasks, and so think it hypocritical
> to not extend the same courtesy to other free software communities
> who are attempting to overcome similar hurdles in their respective
> problem spaces. To quote Harry Tuttle, "We're all in it together."
> 
>
> I understand you'll probably end up using whatever tools you're
> familiar/comfortable with and which help you accomplish your goals,
> I just ask that you keep in mind that publicly recommending non-free
> tools in the service of free software development sets an example.
> OpenStack already has a slightly negative reputation as "not really
> free" in the wider community... one which we're desperately trying
> to overcome, bit by bit.
>

I 

[Openstack-operators] [nova] FYI: live_migration_progress_timeout will default to 0 and be deprecated in Ocata

[Matt Riedemann]

This is just a heads up to anyone running with this since Liberty, there 
is a patch [1] that will go into Ocata which deprecates the 
live_migration_progress_timeout config option used in the libvirt 
driver. The default value will also change to 0, effectively disabling 
the feature. See the patch and related bug report for more details.


If you've seen issues trying to use this feature, and can confirm this 
or think it's actually wrong, please speak up soon (final Nova ocata tag 
is on 2/16).


[1] https://review.openstack.org/#/c/429798/

--

Thanks,

Matt Riedemann

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [LCOO] Intro to Large Contributing

[Jeremy Stanley]

On 2017-02-09 00:59:52 + (+), UKASICK, ANDREW wrote:
[...]
> I'm the mysterious "AndyU" who was chatting with you about a year
> ago in IRC with questions about how to go about donating hosted
> cloud resources for use by the Infra team. It's nice to bump into
> you again! ;-) That idea is still stirring btw, but has been much
> slower moving than I'd hoped.
[...]

Always appreciated, and happy to pick that back up if and when
you're ready.

> I've been having a pretty lengthy conversation with jay Pipes
> regarding similar questions. You can catch up on that in the
> thread below this one.

I've been following it closely, and tried not to duplicate
questions/comments as much as possible.

> LCOO is unlike any other working groups that I'm familiar with in
> some significant ways. You zero'd in on one of those in your
> statements above about companies joining as opposed to
> individuals. In that regard, LCOO is similar to an entity like
> OSIC.org as opposed to a traditional working group.
[...]

This is probably where some of the confusion comes in for me; I
expect it's just one of terminology/semantics. The OpenStack User
Committee has specifically tied "Active members and contributors to
functional teams and/or working groups" to its electorate in their
charter, and also defines working groups as "teams" (which to me
implies they're made up of individuals, not organizations):

https://governance.openstack.org/uc/reference/charter.html

Maybe LCOO is something other than a "working group" in the formal
UC sense? Or maybe the organizations who participate in the LCOO
designate representatives (those LCOO "organization coordinators"
and "governance board" mentioned in your wiki article) who are the
actual working group as far as the UC is concerned? I'm just
concerned if, for example, all employees within AT suddenly become
part of the UC electorate by way of AT as an organization being an
active "member" of an official UC working group. The only way I can
really see this working is if the UC insists that its working groups
are made up of individuals and not whole organizations.

> Jira provides Kanban boards that can serve as a kind of dashboard
> allowing us to visualize activity and current status of Community
> activity. But that activity is still happening in Launchpad,
> Gerrit, etc.
[...]

Cool, so it sounds like StoryBoard may work out for you in the
long-run. It already has kanban and worklist support with optional
automation tied directly to defect/feature tracking and code review.
As the current effort to move our community from launchpad.net to
storyboard.openstack.org progresses over the next couple of
development cycles, I encourage you to check it out and start
thinking about whether its features address your needs (or consider
pitching in on further development there).

> Automating the status updating is something I've begun to discuss
> within the PWG's "Story Tracker" team. We have the same challenge
> there.
[...]

Our hope is that once we get further along with the current
migration blockers for StoryBoard, we'll implement an "epics"
concept in it which ties individual stories and their tasksets to
over-arching efforts where their progress can be tracked more
holistically.

> BTW, Atlassian has always made their tools free for use by open
> source projects. Also, although they're commercial products they
> do provide the source code and allow users to modify it freely
> which makes them much more open-source-ish than most.
[...]


Yes, I saw you mention it in the other ML thread. "Free as in beer"
is a somewhat dirty concept in free software development circles,
and our community infrastructure similarly eschews gratis services
like GitHub in favor of libre alternatives (we provide read-only
mirrors there on request, but don't rely on it in any of our
automation and officially recommend git.openstack.org which runs
entirely on free software).

As an author of free software myself I prefer when people use and
help improve OpenStack rather than supporting commercial/proprietary
solutions to accomplish the same tasks, and so think it hypocritical
to not extend the same courtesy to other free software communities
who are attempting to overcome similar hurdles in their respective
problem spaces. To quote Harry Tuttle, "We're all in it together."


I understand you'll probably end up using whatever tools you're
familiar/comfortable with and which help you accomplish your goals,
I just ask that you keep in mind that publicly recommending non-free
tools in the service of free software development sets an example.
OpenStack already has a slightly negative reputation as "not really
free" in the wider community... one which we're desperately trying
to overcome, bit by bit.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

Re: [Openstack-operators] Sharing fernet tokens

[Matt Fischer]

Please reply all to the list rather than emailing me directly.

Key rotation is done with a keystone-manage command or we just end up
effectively renumbering the keys with our deploy process.

I'd recommend you watch our presentation from the Austin summit or read my
blog posts on this.

http://www.mattfischer.com/blog/?p=648
https://www.youtube.com/watch?v=702SRZHdNW8


On Wed, Feb 8, 2017 at 8:14 AM, Matt Fischer  wrote:

> I think that you just replied to me directly. But you are asking about
> sharing keys.
>
> Since keys do not need to be in-sync on all nodes at the same time you can
> use any number of sharing mechanisms. We used puppet + ansible (our normal
> deploy process). Key rotation allows them to be out of sync which
> simplifies the problem for you.
>
> On Tue, Feb 7, 2017 at 9:25 PM, Matt Fischer  wrote:
>
>> Do you mean sharing tokens or keys?
>>
>> On Feb 7, 2017 11:34 AM, "Ignazio Cassano" 
>> wrote:
>>
>>> Hi everybody,
>>> Can anyone talk me about Sebring fernet tokens in an openstack with more
>>> than one controller?
>>> Regards
>>> Ignazio
>>>
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators