Re: [Openstack-operators] [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Looks Great, Thanks!

-Julia

PS - Indeed :(

On Tue, Oct 16, 2018 at 4:05 PM Jimmy McArthur  wrote:

> OK - I think I got this fixed.  I had to move a couple of things around.
> Julia, please let me know if this all works for you:
>
>
> https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=Kreger
>
> PS - You're going to have a long week :|
>
> Julia Kreger 
> October 16, 2018 at 4:44 PM
> Greetings Jimmy,
>
> Looks like it is still showing up on the schedule that way. I just
> reloaded the website page and it still has both sessions scheduled for 4:20
> PM local. Sadly, I don't have cloning technology. Perhaps someone can help
> me with that for next year? :)
>
> -Julia
>
>
> __
> 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/openstack-dev
> Jimmy McArthur 
> October 16, 2018 at 12:15 PM
> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
>
> __
> 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/openstack-dev
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "OpenStack-operators@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> Cheers,
> Jimmy
>
>
> __
> 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/openstack-dev
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> 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/openstack-dev
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[Jay Pipes]

On 10/16/2018 10:11 AM, Sylvain Bauza wrote:
On Tue, Oct 16, 2018 at 3:28 PM Ignazio Cassano 
mailto:ignaziocass...@gmail.com>> wrote:


Hi everybody,
when on my ocata installation based on centos7 I update (only update
not  changing openstack version) some kvm compute nodes, I
diescovered uuid in resource_providers nova_api db table are
different from uuid in compute_nodes nova db table.
This causes several errors in nova-compute service, because it not
able to receive instances anymore.
Aligning uuid from compute_nodes solves this problem.
Could anyone tel me if it is a bug ?


What do you mean by "updating some compute nodes" ? In Nova, we consider 
uniqueness of compute nodes by a tuple (host, hypervisor_hostname) where 
host is your nova-compute service name for this compute host, and 
hypervisor_hostname is in the case of libvirt the 'hostname' reported by 
the libvirt API [1]


If somehow one of the two values change, then the Nova Resource Tracker 
will consider this new record as a separate compute node, hereby 
creating a new compute_nodes table record, and then a new UUID.
Could you please check your compute_nodes table and see whether some 
entries were recently created ?


The compute_nodes table has no unique constraint on the 
hypervisor_hostname field unfortunately, even though it should. It's not 
like you can have two compute nodes with the same hostname. But, alas, 
this is one of those vestigial tails in nova due to poor initial table 
design and coupling between the concept of a nova-compute service worker 
and the hypervisor resource node itself.


Ignazio, I was tempted to say you may have run into this:

https://bugs.launchpad.net/nova/+bug/1714248

But then I see you're not using Ironic... I'm not entirely sure how you 
ended up with duplicate hypervisor_hostname records for the same compute 
node, but some of those duplicate records must have had the deleted 
field set to a non-zero value, given the constraint we currently have on 
(host, hypervisor_hostname, deleted).


This means that your deployment script or some external scripts must 
have been deleting compute node records somehow, though I'm not entirely 
sure how...


Best,
-jay



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

Re: [Openstack-operators] [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Jimmy McArthur]

Doh! You seriously need it!  Working on a fix :)


Julia Kreger 
October 16, 2018 at 4:44 PM
Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just 
reloaded the website page and it still has both sessions scheduled for 
4:20 PM local. Sadly, I don't have cloning technology. Perhaps someone 
can help me with that for next year? :)


-Julia


__
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/openstack-dev
Jimmy McArthur 
October 16, 2018 at 12:15 PM
I think you might have caught me while I was moving sessions around.  
This shouldn't be an issue now.


Thanks for checking!!


__
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/openstack-dev
Tim Bell 
October 16, 2018 at 1:37 AM
Jimmy,

While it's not a clash within the forum, there are two sessions for 
Ironic scheduled at the same time on Tuesday at 14h20, each of which 
has Julia as a speaker.


Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
"OpenStack-operators@lists.openstack.org" 
, 
"commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 


If you see a glaring content conflict within the Forum itself, please
let me know.

You can also view the Full Schedule in the attached PDF if that makes
life easier...

NOTE: BoFs and WGs are still not all up on the schedule. No need to let
us know :)

Cheers,
Jimmy


__
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/openstack-dev
Jimmy McArthur 
October 15, 2018 at 3:01 PM
Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to 
let us know :)


Cheers,
Jimmy
___
Staff mailing list
st...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/staff


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

Re: [Openstack-operators] [openstack-dev] [openstack-community] Forum Schedule - Seeking Community Review

[Julia Kreger]

Greetings Jimmy,

Looks like it is still showing up on the schedule that way. I just reloaded
the website page and it still has both sessions scheduled for 4:20 PM
local. Sadly, I don't have cloning technology. Perhaps someone can help me
with that for next year? :)

-Julia


On Tue, Oct 16, 2018 at 11:15 AM Jimmy McArthur  wrote:

> I think you might have caught me while I was moving sessions around.  This
> shouldn't be an issue now.
>
> Thanks for checking!!
>
> Tim Bell 
> October 16, 2018 at 1:37 AM
> Jimmy,
>
> While it's not a clash within the forum, there are two sessions for Ironic
> scheduled at the same time on Tuesday at 14h20, each of which has Julia as
> a speaker.
>
> Tim
>
> -Original Message-
> From: Jimmy McArthur  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  
> Date: Monday, 15 October 2018 at 22:04
> To: "OpenStack Development Mailing List (not for usage questions)"
>  ,
> "OpenStack-operators@lists.openstack.org"
> 
> 
> , "commun...@lists.openstack.org"
>  
> 
> Subject: [openstack-dev] Forum Schedule - Seeking Community Review
>
> Hi -
>
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
>
> If you see a glaring content conflict within the Forum itself, please
> let me know.
>
> You can also view the Full Schedule in the attached PDF if that makes
> life easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule. No need to let
> us know :)
>
> Cheers,
> Jimmy
>
>
> ___
> Community mailing list
> commun...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/community
> Jimmy McArthur 
> October 15, 2018 at 3:01 PM
> Hi -
>
> The Forum schedule is now up (
> https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let
> me know.
>
> You can also view the Full Schedule in the attached PDF if that makes life
> easier...
>
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let
> us know :)
>
> Cheers,
> Jimmy
> ___
> Staff mailing list
> st...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/staff
>
>
> __
> 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/openstack-dev
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Ops Meetups - Call for Hosts

[Erik McCormick]

Hello all,

The Ops Meetup team has embarked on a mission to revive the
traditional Operators Meetup that have historically been held between
Summits. With the upcoming merger of the PTG into the Summit week, and
the merger of most Ops discussion sessions at Summits into the Forum,
we felt that we needed to get back to our original format.

With that in mind, we are beginning the process of selecting venues
for both 2019 Meetups. Some guidelines for what is needed to host can
be found here:
https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection

Each of the etherpads below contains a template to collect information
about the potential host and venue. If you are interested in hosting a
meetup, simply copy and paste the template into a blank etherpad, fill
it out, and place a link above the template on the original etherpad.

Ops Meetup 2019 #1 - Late February / Early March - Somewhere in Europe
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019

Ops Meetup 2019 #2 - Late July / Early August - Somewhere in North America
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-2nd-2019

Reply back to this thread with any questions or comments. If you are
coming to the Berlin Summit, we will be having an Ops Meetup Team
catch-up Forum session. We encourage all of you to join in making
these events a success.

Cheers,
Erik

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

Re: [Openstack-operators] [openstack-community] [openstack-dev] Forum Schedule - Seeking Community Review

[Jimmy McArthur]

I think you might have caught me while I was moving sessions around.  
This shouldn't be an issue now.


Thanks for checking!!


Tim Bell 
October 16, 2018 at 1:37 AM
Jimmy,

While it's not a clash within the forum, there are two sessions for 
Ironic scheduled at the same time on Tuesday at 14h20, each of which 
has Julia as a speaker.


Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, 
"OpenStack-operators@lists.openstack.org" 
, 
"commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262). 


If you see a glaring content conflict within the Forum itself, please
let me know.

You can also view the Full Schedule in the attached PDF if that makes
life easier...

NOTE: BoFs and WGs are still not all up on the schedule. No need to let
us know :)

Cheers,
Jimmy


___
Community mailing list
commun...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/community
Jimmy McArthur 
October 15, 2018 at 3:01 PM
Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.


You can also view the Full Schedule in the attached PDF if that makes 
life easier...


NOTE: BoFs and WGs are still not all up on the schedule.  No need to 
let us know :)


Cheers,
Jimmy
___
Staff mailing list
st...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/staff


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

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[Ignazio Cassano]

hello Iain, it is not possible.
I checked hostnames several times.
No changes .
I tried same procedure on  3 different ocata installations because we have
3 distinct openstack . Same results.
Regards
Ignazio

Il Mar 16 Ott 2018 17:20 iain MacDonnell  ha
scritto:

>
> Is it possible that the hostnames of the nodes changed when you updated
> them? e.g. maybe they were using fully-qualified names before and
> changed to short-form, or vice versa ?
>
>  ~iain
>
>
> On 10/16/2018 07:22 AM, Ignazio Cassano wrote:
> > Hi Sylvain,
> > I mean launching "yum update" on compute nodes.
> > Now I am going to describe what happened.
> > We had an environment made up of 3 kvm nodes.
> > We added two new compute nodes.
> > Since the addition has been made after 3 or 4 months after the first
> > openstack installation, the 2 new compute nodes are updated to most
> > recent ocata packages.
> > So we launched a yum update also on the 3 old compute nodes.
> > After the above operations, the resource_providers table contains wrong
> > uuid for the 3 old nodes and they stooped to work.
> > Updating resource_providers uuid getting them from compute_nodes table,
> > the old 3 nodes return to work fine.
> > Regards
> > Ignazio
> >
> > Il giorno mar 16 ott 2018 alle ore 16:11 Sylvain Bauza
> > mailto:sba...@redhat.com>> ha scritto:
> >
> >
> >
> > On Tue, Oct 16, 2018 at 3:28 PM Ignazio Cassano
> > mailto:ignaziocass...@gmail.com>> wrote:
> >
> > Hi everybody,
> > when on my ocata installation based on centos7 I update (only
> > update not  changing openstack version) some kvm compute nodes,
> > I diescovered uuid in resource_providers nova_api db table are
> > different from uuid in compute_nodes nova db table.
> > This causes several errors in nova-compute service, because it
> > not able to receive instances anymore.
> > Aligning uuid from compute_nodes solves this problem.
> > Could anyone tel me if it is a bug ?
> >
> >
> > What do you mean by "updating some compute nodes" ? In Nova, we
> > consider uniqueness of compute nodes by a tuple (host,
> > hypervisor_hostname) where host is your nova-compute service name
> > for this compute host, and hypervisor_hostname is in the case of
> > libvirt the 'hostname' reported by the libvirt API [1]
> >
> > If somehow one of the two values change, then the Nova Resource
> > Tracker will consider this new record as a separate compute node,
> > hereby creating a new compute_nodes table record, and then a new
> UUID.
> > Could you please check your compute_nodes table and see whether some
> > entries were recently created ?
> >
> > -Sylvain
> >
> > [1]
> >
> https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Connections-Host_Info.html
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__libvirt.org_docs_libvirt-2Dappdev-2Dguide-2Dpython_en-2DUS_html_libvirt-5Fapplication-5Fdevelopment-5Fguide-5Fusing-5Fpython-2DConnections-2DHost-5FInfo.html=DwMFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=_TK1Um7U6rr6DWfsEbv4Rlnc21v6RU0YDRepaIogZrI=-qYx_DDcBW_aiXp2tLBcR4pN0VZ9ZNclcx5LfIVor_E=
> >
> >
> > Regards
> > Ignazio
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > 
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwMFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=_TK1Um7U6rr6DWfsEbv4Rlnc21v6RU0YDRepaIogZrI=COsaMeTCgWBDl9EQVZB_AGikvKqCIaWcA5RY7IcLYgw=
> >
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=_TK1Um7U6rr6DWfsEbv4Rlnc21v6RU0YDRepaIogZrI=COsaMeTCgWBDl9EQVZB_AGikvKqCIaWcA5RY7IcLYgw=
> >
>
> ___
> 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] [SIGS] Ops Tools SIG

[Melvin Hillsman]

Additional comments in-line.

I am open to restructuring things around the tools and repos that they are
managed in. As previously mentioned please include me in the list of folks
who want to be a part of the team.

On Tue, Oct 16, 2018 at 8:45 AM Erik McCormick 
wrote:

> On Tue, Oct 16, 2018 at 5:19 AM Miguel Angel Ajo Pelayo
>  wrote:
> >
> > Hi,
> >
> > Matthias and I talked this morning about this topic, and we came to
> realize
> > that there's room for/would be beneficial to have a common place for:
> >
> > a) Documentation about second day operator tools which can be
> > useful with OpenStack, links to repositories or availability for
> every distribution.
> >
> Sounds like a Natural extension to the Ops Guide [1] which we've been
> working to return to relevance. I suppose this could also be a wiki
> like [2], but we should at least reference it in the guide. In any
> event, massive cleanup of old, outdated content really needs to be
> undertaken. That should be the other part of the mission I think.
>

https://wiki.openstack.org/wiki/Operation_Docs_SIG


>
> > b) Deployment documentation/config snippets/deployment scripts for those
> tools
> > in integration with OpenStack.
> >
> > c)  Operator tools and bits which are developed or maintained on
> OpenStack repos,
> > specially the OpenStack related bits of those tools (plugins, etc),
> >
> We should probably try and revive [3] and make use of that more
> effectively to address b and c. We've been trying to encourage
> contribution to it for years, but it needs more contributors and some
> TLC
>

Ops Tools SIG could facilitate this. Being involved particularly here I
think it would be great to have more folks involved and with the addition
of OpenLab we have a space to do a bit more around e2e and integration
testing of the tools.


>
> > d) Home the organisation of ops-related rooms during OpenStack events,
> general
> >  ones related to OpenStack, and also the distro-specific ones for
> the distros interested
> >  in participation.
> >
> I'm not exactly sure what you mean by this item. We currently have a
> team responsible for meetups and pushing Ops-related content into the
> Forum at Summits. Do you propose merging the Ops Meetup Team into this
> SIG?
>

Yes, there is already the Ops Meetup Team which facilitates this and of
course anyone is encouraged to join and get involved:
https://wiki.openstack.org/wiki/Ops_Meetups_Team


> >
> > Does this scope for the SIG make sense to everyone willing to
> participate?
> >
> >
> > Best regards,
> > Miguel Ángel.
> >
> [1] https://docs.openstack.org/operations-guide/
> [2] https://wiki.openstack.org/wiki/Operations
> [3] https://wiki.openstack.org/wiki/Osops#Code
>
> -Erik
>
> >
> > On Mon, Oct 15, 2018 at 11:12 AM Matthias Runge 
> wrote:
> >>
> >> On 12/10/2018 14:21, Sean McGinnis wrote:
> >> > On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote:
> >> >> Greetings guys,
> >> >>
> >> >> On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo <
> >> >> majop...@redhat.com> wrote:
> >> >>
> >> >>> Adding the mailing lists back to your reply, thank you :)
> >> >>>
> >> >>> I guess that +melvin.hills...@huawei.com <
> melvin.hills...@huawei.com> can
> >> >>> help us a little bit organizing the SIG,
> >> >>> but I guess the first thing would be collecting a list of tools
> which
> >> >>> could be published
> >> >>> under the umbrella of the SIG, starting by the ones already in
> Osops.
> >> >>>
> >> >>> Publishing documentation for those tools, and the catalog under
> >> >>> docs.openstack.org
> >> >>> is possibly the next step (or a parallel step).
> >> >>>
> >> >>>
> >> >>> On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister  >
> >> >>> wrote:
> >> >>>
> >>  Hi Miguel,
> >> 
> >>  I would love to join this. What do I need to do?
> >> 
> >>  Sent from my iPhone
> >> 
> >>  On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo <
> majop...@redhat.com>
> >>  wrote:
> >> 
> >>  Hello
> >> 
> >>   Yesterday, during the Oslo meeting we discussed [6] the
> possibility
> >>  of creating a new Special Interest Group [1][2] to provide home
> and release
> >>  means for operator related tools [3] [4] [5]
> >> 
> >> 
> >> >>all of those tools have python dependencies related to openstack
> such as
> >> >> python-openstackclient or python-pbr. Which is exactly the reason
> why we
> >> >> moved osops-tools-monitoring-oschecks packaging away from OpsTools
> SIG to
> >> >> Cloud SIG. AFAIR we had some issues of having opstools SIG being
> dependent
> >> >> on openstack SIG. I believe that Cloud SIG is proper home for tools
> like
> >> >> [3][4][5] as they are related to OpenStack anyway. OpsTools SIG
> contains
> >> >> general tools like fluentd, sensu, collectd.
> >> >>
> >> >>
> >> >> Hope this helps,
> >> >> Martin
> >> >>
> >> >
> >> > Hey Martin,
> >> >
> >> > I'm not sure I understand the issue with these tools have

Re: [Openstack-operators] Forum Schedule - Seeking Community Review

[Sean McGinnis]

On Mon, Oct 15, 2018 at 03:01:07PM -0500, Jimmy McArthur wrote:
> Hi -
> 
> The Forum schedule is now up
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).
> If you see a glaring content conflict within the Forum itself, please let me
> know.
> 

I have updated the Forum wiki page in preparation for the topic etherpads:

https://wiki.openstack.org/wiki/Forum/Berlin2018

Please add your working session etherpad links once they are available so
everyone has one spot to go to to find all relevant links.

Thanks!
Sean

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

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[iain MacDonnell]

Is it possible that the hostnames of the nodes changed when you updated 
them? e.g. maybe they were using fully-qualified names before and 
changed to short-form, or vice versa ?


~iain


On 10/16/2018 07:22 AM, Ignazio Cassano wrote:

Hi Sylvain,
I mean launching "yum update" on compute nodes.
Now I am going to describe what happened.
We had an environment made up of 3 kvm nodes.
We added two new compute nodes.
Since the addition has been made after 3 or 4 months after the first 
openstack installation, the 2 new compute nodes are updated to most 
recent ocata packages.

So we launched a yum update also on the 3 old compute nodes.
After the above operations, the resource_providers table contains wrong 
uuid for the 3 old nodes and they stooped to work.
Updating resource_providers uuid getting them from compute_nodes table, 
the old 3 nodes return to work fine.

Regards
Ignazio

Il giorno mar 16 ott 2018 alle ore 16:11 Sylvain Bauza 
mailto:sba...@redhat.com>> ha scritto:




On Tue, Oct 16, 2018 at 3:28 PM Ignazio Cassano
mailto:ignaziocass...@gmail.com>> wrote:

Hi everybody,
when on my ocata installation based on centos7 I update (only
update not  changing openstack version) some kvm compute nodes,
I diescovered uuid in resource_providers nova_api db table are
different from uuid in compute_nodes nova db table.
This causes several errors in nova-compute service, because it
not able to receive instances anymore.
Aligning uuid from compute_nodes solves this problem.
Could anyone tel me if it is a bug ?


What do you mean by "updating some compute nodes" ? In Nova, we
consider uniqueness of compute nodes by a tuple (host,
hypervisor_hostname) where host is your nova-compute service name
for this compute host, and hypervisor_hostname is in the case of
libvirt the 'hostname' reported by the libvirt API [1]

If somehow one of the two values change, then the Nova Resource
Tracker will consider this new record as a separate compute node,
hereby creating a new compute_nodes table record, and then a new UUID.
Could you please check your compute_nodes table and see whether some
entries were recently created ?

-Sylvain

[1]

https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Connections-Host_Info.html



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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=_TK1Um7U6rr6DWfsEbv4Rlnc21v6RU0YDRepaIogZrI=COsaMeTCgWBDl9EQVZB_AGikvKqCIaWcA5RY7IcLYgw=



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

Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names

[Lance Bragstad]

It happened. Documentation is hot off the press and ready for you to read
[0]. As always, feel free to raise concerns, comments, or questions any
time.

I appreciate everyone's help in nailing this down.

[0]
https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies

On Sat, Oct 13, 2018 at 6:07 AM Ghanshyam Mann 
wrote:

>   On Sat, 13 Oct 2018 01:45:17 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote 
>  > Sending a follow up here quick.
>  > The reviewers actively participating in [0] are nearing a conclusion.
> Ultimately, the convention is going to be:
>  >
>  
> :[:][:]:[:]
>  > Details about what that actually means can be found in the review [0].
> Each piece is denoted as being required or optional, along with examples. I
> think this gives us a pretty good starting place, and the syntax is
> flexible enough to support almost every policy naming convention we've
> stumbled across.
>  > Now is the time if you have any final input or feedback. Thanks for
> sticking with the discussion.
>
> Thanks Lance for working on this. Current version lgtm. I would like to
> see some operators feedback also if  this standard policy name format is
> clear and easy understandable.
>
> -gmann
>
>  > Lance
>  > [0] https://review.openstack.org/#/c/606214/
>  >
>  > On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad 
> wrote:
>  >
>  > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann 
> wrote:
>  >   On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote 
>  >   >
>  >   > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki 
> wrote:
>  >   > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>  >   >   wrote:
>  >   >  >
>  >   >  > Ideally I would like to see it in the form of least specific to
> most specific. But more importantly in a way that there is no additional
> delimiters between the service type and the resource. Finally, I do not
> like the change of plurality depending on action type.
>  >   >  >
>  >   >  > I propose we consider
>  >   >  >
>  >   >  > ::[:]
>  >   >  >
>  >   >  > Example for keystone (note, action names below are strictly
> examples I am fine with whatever form those actions take):
>  >   >  > identity:projects:create
>  >   >  > identity:projects:delete
>  >   >  > identity:projects:list
>  >   >  > identity:projects:get
>  >   >  >
>  >   >  > It keeps things simple and consistent when you're looking
> through overrides / defaults.
>  >   >  > --Morgan
>  >   >  +1 -- I think the ordering if `resource` comes before
>  >   >  `action|subaction` will be more clean.
>  >   >
>  >   > ++
>  >   > These are excellent points. I especially like being able to omit
> the convention about plurality. Furthermore, I'd like to add that I think
> we should make the resource singular (e.g., project instead or projects).
> For example:
>  >   > compute:server:list
>  >   >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
>  >
>  >  Do we need "action" word there? I think action name itself should
> convey the operation. IMO below notation without "äction" word looks clear
> enough. what you say?
>  >
>  >  compute:server:reboot
>  >  compute:server:confirm_resize
>  >
>  > I agree. I simplified this in the current version up for review.
>  >  -gmann
>  >
>  >   >
>  >   > Otherwise, someone might mistake compute:servers:get, as "list".
> This is ultra-nick-picky, but something I thought of when seeing the usage
> of "get_all" in policy names in favor of "list."
>  >   > In summary, the new convention based on the most recent feedback
> should be:
>  >   > ::[:]
>  >   > Rules:service-type is always defined in the service types authority
>  >   > resources are always singular
>  >   > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
>  >   >  /R
>  >   >
>  >   >  Harry
>  >   >  >
>  >   >  > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad <
> lbrags...@gmail.com> wrote:
>  >   >  >>
>  >   >  >> Bumping this thread again and proposing two conventions based
> on the discussion here. I propose we decide on one of the two following
> conventions:
>  >   >  >>
>  >   >  >> ::
>  >   >  >>
>  >   >  >> or
>  >   >  >>
>  >   >  >> :_
>  >   >  >>
>  >   >  >> Where  is the corresponding service type of the
> project [0], and  is either create, get, list, update, or delete. I
> think decoupling the method from the policy name should aid in consistency,
> regardless of the underlying implementation. The HTTP method specifics can
> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>  >   >  >>
>  >   >  >> I think the plurality of the resource should default to what
> makes sense for the operation being carried out (e.g., list:foobars,
> create:foobar).
>  >   >  >>
>  >   >  >> I don't mind the first one because it's clear about what the
> delimiter is and it doesn't look weird when projects have 

[Openstack-operators] Ops Meetups team meeting 2018-10-16

[Chris Morgan]

The OpenStack Ops Meetups team met today on #openstack-operators, meeting
minutes linked below.

As discussed previously the ops meetups team intends to arrange two ops
meetups in 2019, the first aimed for February or March in Europe, the
second in August or September in North America. A Call for Proposals (CFP)
will be issued shortly.

For those of you attending the OpenStack Summit in Berlin next month,
please note we'll arrange an informal social events for openstack operators
(and anyone else who wants to come) on the Tuesday night. Several of the
meetups team are also moderating sessions at the forum. See you there!

Chris

Minutes :
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-10-16-14.04.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-10-16-14.04.txt
Log   :
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_team.2018-10-16-14.04.log.html

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

[Openstack-operators] [publiccloud-wg] Reminder weekly meeting Public Cloud WG

[Tobias Rydberg]

Hi everyone,

Time for a new meeting for PCWG - tomorrow Wednesday 0700 UTC in 
#openstack-publiccloud! Agenda found at 
https://etherpad.openstack.org/p/publiccloud-wg


Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


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

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[Ignazio Cassano]

Hi Sylvain,
I mean launching "yum update" on compute nodes.
Now I am going to describe what happened.
We had an environment made up of 3 kvm nodes.
We added two new compute nodes.
Since the addition has been made after 3 or 4 months after the first
openstack installation, the 2 new compute nodes are updated to most recent
ocata packages.
So we launched a yum update also on the 3 old compute nodes.
After the above operations, the resource_providers table contains wrong
uuid for the 3 old nodes and they stooped to work.
Updating resource_providers uuid getting them from compute_nodes table, the
old 3 nodes return to work fine.
Regards
Ignazio

Il giorno mar 16 ott 2018 alle ore 16:11 Sylvain Bauza 
ha scritto:

>
>
> On Tue, Oct 16, 2018 at 3:28 PM Ignazio Cassano 
> wrote:
>
>> Hi everybody,
>> when on my ocata installation based on centos7 I update (only update not
>> changing openstack version) some kvm compute nodes, I diescovered uuid in
>> resource_providers nova_api db table are different from uuid in
>> compute_nodes nova db table.
>> This causes several errors in nova-compute service, because it not able
>> to receive instances anymore.
>> Aligning uuid from compute_nodes solves this problem.
>> Could anyone tel me if it is a bug ?
>>
>>
> What do you mean by "updating some compute nodes" ? In Nova, we consider
> uniqueness of compute nodes by a tuple (host, hypervisor_hostname) where
> host is your nova-compute service name for this compute host, and
> hypervisor_hostname is in the case of libvirt the 'hostname' reported by
> the libvirt API [1]
>
> If somehow one of the two values change, then the Nova Resource Tracker
> will consider this new record as a separate compute node, hereby creating a
> new compute_nodes table record, and then a new UUID.
> Could you please check your compute_nodes table and see whether some
> entries were recently created ?
>
> -Sylvain
>
> [1]
> https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Connections-Host_Info.html
>
> 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

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[Sylvain Bauza]

On Tue, Oct 16, 2018 at 3:28 PM Ignazio Cassano 
wrote:

> Hi everybody,
> when on my ocata installation based on centos7 I update (only update not
> changing openstack version) some kvm compute nodes, I diescovered uuid in
> resource_providers nova_api db table are different from uuid in
> compute_nodes nova db table.
> This causes several errors in nova-compute service, because it not able to
> receive instances anymore.
> Aligning uuid from compute_nodes solves this problem.
> Could anyone tel me if it is a bug ?
>
>
What do you mean by "updating some compute nodes" ? In Nova, we consider
uniqueness of compute nodes by a tuple (host, hypervisor_hostname) where
host is your nova-compute service name for this compute host, and
hypervisor_hostname is in the case of libvirt the 'hostname' reported by
the libvirt API [1]

If somehow one of the two values change, then the Nova Resource Tracker
will consider this new record as a separate compute node, hereby creating a
new compute_nodes table record, and then a new UUID.
Could you please check your compute_nodes table and see whether some
entries were recently created ?

-Sylvain

[1]
https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/libvirt_application_development_guide_using_python-Connections-Host_Info.html

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

Re: [Openstack-operators] [openstack-dev] [SIGS] Ops Tools SIG

[Erik McCormick]

On Tue, Oct 16, 2018 at 5:19 AM Miguel Angel Ajo Pelayo
 wrote:
>
> Hi,
>
> Matthias and I talked this morning about this topic, and we came to 
> realize
> that there's room for/would be beneficial to have a common place for:
>
> a) Documentation about second day operator tools which can be
> useful with OpenStack, links to repositories or availability for every 
> distribution.
>
Sounds like a Natural extension to the Ops Guide [1] which we've been
working to return to relevance. I suppose this could also be a wiki
like [2], but we should at least reference it in the guide. In any
event, massive cleanup of old, outdated content really needs to be
undertaken. That should be the other part of the mission I think.

> b) Deployment documentation/config snippets/deployment scripts for those tools
> in integration with OpenStack.
>
> c)  Operator tools and bits which are developed or maintained on OpenStack 
> repos,
> specially the OpenStack related bits of those tools (plugins, etc),
>
We should probably try and revive [3] and make use of that more
effectively to address b and c. We've been trying to encourage
contribution to it for years, but it needs more contributors and some
TLC

> d) Home the organisation of ops-related rooms during OpenStack events, general
>  ones related to OpenStack, and also the distro-specific ones for the 
> distros interested
>  in participation.
>
I'm not exactly sure what you mean by this item. We currently have a
team responsible for meetups and pushing Ops-related content into the
Forum at Summits. Do you propose merging the Ops Meetup Team into this
SIG?
>
> Does this scope for the SIG make sense to everyone willing to participate?
>
>
> Best regards,
> Miguel Ángel.
>
[1] https://docs.openstack.org/operations-guide/
[2] https://wiki.openstack.org/wiki/Operations
[3] https://wiki.openstack.org/wiki/Osops#Code

-Erik

>
> On Mon, Oct 15, 2018 at 11:12 AM Matthias Runge  wrote:
>>
>> On 12/10/2018 14:21, Sean McGinnis wrote:
>> > On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote:
>> >> Greetings guys,
>> >>
>> >> On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo <
>> >> majop...@redhat.com> wrote:
>> >>
>> >>> Adding the mailing lists back to your reply, thank you :)
>> >>>
>> >>> I guess that +melvin.hills...@huawei.com  can
>> >>> help us a little bit organizing the SIG,
>> >>> but I guess the first thing would be collecting a list of tools which
>> >>> could be published
>> >>> under the umbrella of the SIG, starting by the ones already in Osops.
>> >>>
>> >>> Publishing documentation for those tools, and the catalog under
>> >>> docs.openstack.org
>> >>> is possibly the next step (or a parallel step).
>> >>>
>> >>>
>> >>> On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister 
>> >>> wrote:
>> >>>
>>  Hi Miguel,
>> 
>>  I would love to join this. What do I need to do?
>> 
>>  Sent from my iPhone
>> 
>>  On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo 
>>  wrote:
>> 
>>  Hello
>> 
>>   Yesterday, during the Oslo meeting we discussed [6] the possibility
>>  of creating a new Special Interest Group [1][2] to provide home and 
>>  release
>>  means for operator related tools [3] [4] [5]
>> 
>> 
>> >>all of those tools have python dependencies related to openstack such 
>> >> as
>> >> python-openstackclient or python-pbr. Which is exactly the reason why we
>> >> moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to
>> >> Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent
>> >> on openstack SIG. I believe that Cloud SIG is proper home for tools like
>> >> [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains
>> >> general tools like fluentd, sensu, collectd.
>> >>
>> >>
>> >> Hope this helps,
>> >> Martin
>> >>
>> >
>> > Hey Martin,
>> >
>> > I'm not sure I understand the issue with these tools have dependencies on 
>> > other
>> > packages and the relationship to SIG ownership. Is your concern (or the 
>> > history
>> > of a concern you are pointing out) that the tools would have a more 
>> > difficult
>> > time if they required updates to dependencies if they are owned by a 
>> > different
>> > group?
>> >
>> > Thanks!
>> > Sean
>> >
>>
>> Hello,
>>
>> the mentioned sigs (opstools/cloud) are in CentOS scope and mention
>> repository dependencies. That shouldn't bother us here now.
>>
>>
>> There is already a SIG under the CentOS project, providing tools for
>> operators[7], but also documentation and integrational bits.
>>
>> Also, there is some overlap with other groups and SIGs, such as
>> Barometer[8].
>>
>> Since there is already some duplication, I don't know where it makes
>> sense to have a single group for this purpose?
>>
>> If that hasn't been clear yet, I'd be absolutely interested in
>> joining/helping this effort.
>>
>>
>> Matthias
>>
>>
>>
>> [7] 

[Openstack-operators] nova_api resource_providers table issues on ocata

[Ignazio Cassano]

Hi everybody,
when on my ocata installation based on centos7 I update (only update not
changing openstack version) some kvm compute nodes, I diescovered uuid in
resource_providers nova_api db table are different from uuid in
compute_nodes nova db table.
This causes several errors in nova-compute service, because it not able to
receive instances anymore.
Aligning uuid from compute_nodes solves this problem.
Could anyone tel me if it is a bug ?

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

Re: [Openstack-operators] [goals][upgrade-checkers] Week R-26 Update

[Ghanshyam Mann]

  On Sat, 13 Oct 2018 07:05:53 +0900 Matt Riedemann  
wrote  
 > The big update this week is version 0.1.0 of oslo.upgradecheck was 
 > released. The documentation along with usage examples can be found here 
 > [1]. A big thanks to Ben Nemec for getting that done since a few 
 > projects were waiting for it.
 > 
 > In other updates, some changes were proposed in other projects [2].
 > 
 > And finally, Lance Bragstad and I had a discussion this week [3] about 
 > the validity of upgrade checks looking for deleted configuration 
 > options. The main scenario I'm thinking about here is FFU where someone 
 > is going from Mitaka to Pike. Let's say a config option was deprecated 
 > in Newton and then removed in Ocata. As the operator is rolling through 
 > from Mitaka to Pike, they might have missed the deprecation signal in 
 > Newton and removal in Ocata. Does that mean we should have upgrade 
 > checks that look at the configuration for deleted options, or options 
 > where the deprecated alias is removed? My thought is that if things will 
 > not work once they get to the target release and restart the service 
 > code, which would definitely impact the upgrade, then checking for those 
 > scenarios is probably OK. If on the other hand the removed options were 
 > just tied to functionality that was removed and are otherwise not 
 > causing any harm then I don't think we need a check for that. It was 
 > noted that oslo.config has a new validation tool [4] so that would take 
 > care of some of this same work if run during upgrades. So I think 
 > whether or not an upgrade check should be looking for config option 
 > removal ultimately depends on the severity of what happens if the manual 
 > intervention to handle that removed option is not performed. That's 
 > pretty broad, but these upgrade checks aren't really set in stone for 
 > what is applied to them. I'd like to get input from others on this, 
 > especially operators and if they would find these types of checks useful.
 > 
 > [1] https://docs.openstack.org/oslo.upgradecheck/latest/
 > [2] https://storyboard.openstack.org/#!/story/2003657
 > [3] 
 > http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
 > [4] 
 > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html

Other point is about policy change and how we should accommodate those in 
upgrade-checks.

There are below categorization of policy changes:
1. Policy rule name has been changed. 
Upgrade Impact: If that policy rule is overridden in policy.json then, yes 
we need to tell this in upgrade-check CLI. If not overridden which means 
operators depends on policy in code then, it would not impact their upgrade. 
2. Policy rule (deprecated) has been removed
Upgrade Impact: YES, as it can impact their API access after upgrade.  This 
needs to be cover in upgrade-checks
3. Default value (including scope) of Policy rule has been changed
Upgrade Impact: YES, this can change the access level of their API after 
upgrade. This needs to be cover in upgrade-checks
4. New Policy rule introduced
Upgrade Impact: YES, same reason. 

 I think policy changes can be added in upgrade checker by checking all the 
above category because everything will impact upgrade? 

For Example, cinder policy change [1]:

"Add granularity to the volume_extension:volume_type_encryption policy with the 
addition of distinct actions for create, get, update, and delete:

volume_extension:volume_type_encryption:create
volume_extension:volume_type_encryption:get
volume_extension:volume_type_encryption:update
volume_extension:volume_type_encryption:delete
To address backwards compatibility, the new rules added to the volume_type.py 
policy file, default to the existing rule, 
volume_extension:volume_type_encryption, if it is set to a non-default value. "

[1] https://docs.openstack.org/releasenotes/cinder/unreleased.html#upgrade-notes

-gmann

 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > ___
 > 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] [SIGS] Ops Tools SIG

[Miguel Angel Ajo Pelayo]

Hi,

Matthias and I talked this morning about this topic, and we came to
realize
that there's room for/would be beneficial to have a common place for:

a) Documentation about second day operator tools which can be
useful with OpenStack, links to repositories or availability for every
distribution.

b) Deployment documentation/config snippets/deployment scripts for those
tools
in integration with OpenStack.

c)  Operator tools and bits which are developed or maintained on OpenStack
repos,
specially the OpenStack related bits of those tools (plugins, etc),

d) Home the organisation of ops-related rooms during OpenStack events,
general
 ones related to OpenStack, and also the distro-specific ones for the
distros interested
 in participation.


Does this scope for the SIG make sense to everyone willing to participate?


Best regards,
Miguel Ángel.


On Mon, Oct 15, 2018 at 11:12 AM Matthias Runge  wrote:

> On 12/10/2018 14:21, Sean McGinnis wrote:
> > On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote:
> >> Greetings guys,
> >>
> >> On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo <
> >> majop...@redhat.com> wrote:
> >>
> >>> Adding the mailing lists back to your reply, thank you :)
> >>>
> >>> I guess that +melvin.hills...@huawei.com 
> can
> >>> help us a little bit organizing the SIG,
> >>> but I guess the first thing would be collecting a list of tools which
> >>> could be published
> >>> under the umbrella of the SIG, starting by the ones already in Osops.
> >>>
> >>> Publishing documentation for those tools, and the catalog under
> >>> docs.openstack.org
> >>> is possibly the next step (or a parallel step).
> >>>
> >>>
> >>> On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister 
> >>> wrote:
> >>>
>  Hi Miguel,
> 
>  I would love to join this. What do I need to do?
> 
>  Sent from my iPhone
> 
>  On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo <
> majop...@redhat.com>
>  wrote:
> 
>  Hello
> 
>   Yesterday, during the Oslo meeting we discussed [6] the
> possibility
>  of creating a new Special Interest Group [1][2] to provide home and
> release
>  means for operator related tools [3] [4] [5]
> 
> 
> >>all of those tools have python dependencies related to openstack
> such as
> >> python-openstackclient or python-pbr. Which is exactly the reason why we
> >> moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG
> to
> >> Cloud SIG. AFAIR we had some issues of having opstools SIG being
> dependent
> >> on openstack SIG. I believe that Cloud SIG is proper home for tools like
> >> [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains
> >> general tools like fluentd, sensu, collectd.
> >>
> >>
> >> Hope this helps,
> >> Martin
> >>
> >
> > Hey Martin,
> >
> > I'm not sure I understand the issue with these tools have dependencies
> on other
> > packages and the relationship to SIG ownership. Is your concern (or the
> history
> > of a concern you are pointing out) that the tools would have a more
> difficult
> > time if they required updates to dependencies if they are owned by a
> different
> > group?
> >
> > Thanks!
> > Sean
> >
>
> Hello,
>
> the mentioned sigs (opstools/cloud) are in CentOS scope and mention
> repository dependencies. That shouldn't bother us here now.
>
>
> There is already a SIG under the CentOS project, providing tools for
> operators[7], but also documentation and integrational bits.
>
> Also, there is some overlap with other groups and SIGs, such as
> Barometer[8].
>
> Since there is already some duplication, I don't know where it makes
> sense to have a single group for this purpose?
>
> If that hasn't been clear yet, I'd be absolutely interested in
> joining/helping this effort.
>
>
> Matthias
>
>
>
> [7] https://wiki.centos.org/SpecialInterestGroup/OpsTools
> [8] https://wiki.opnfv.org/collector/pages.action?key=fastpath
>
> --
> Matthias Runge 
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham,
>  Michael O'Neill, Eric Shander
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] Forum Schedule - Seeking Community Review

[Tim Bell]

Jimmy,

While it's not a clash within the forum, there are two sessions for Ironic 
scheduled at the same time on Tuesday at 14h20, each of which has Julia as a 
speaker.

Tim

-Original Message-
From: Jimmy McArthur 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 15 October 2018 at 22:04
To: "OpenStack Development Mailing List (not for usage questions)" 
, "OpenStack-operators@lists.openstack.org" 
, "commun...@lists.openstack.org" 

Subject: [openstack-dev] Forum Schedule - Seeking Community Review

Hi -

The Forum schedule is now up 
(https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
If you see a glaring content conflict within the Forum itself, please 
let me know.

You can also view the Full Schedule in the attached PDF if that makes 
life easier...

NOTE: BoFs and WGs are still not all up on the schedule.  No need to let 
us know :)

Cheers,
Jimmy


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