[openstack-dev] [all]Naming the T release of OpenStack -- Poll open

[Tony Breeds]

Hi folks,

It is time again to cast your vote for the naming of the T Release.
As with last time we'll use a public polling option over per user private URLs
for voting.  This means, everybody should proceed to use the following URL to
cast their vote:

  
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df&akey=b9e448b340787f0e

We've selected a public poll to ensure that the whole community, not just gerrit
change owners get a vote.  Also the size of our community has grown such that we
can overwhelm CIVS if using private urls.  A public can mean that users
behind NAT, proxy servers or firewalls may receive an message saying
that your vote has already been lodged, if this happens please try
another IP.

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results will 
be
posted shortly after.

[1] https://governance.openstack.org/tc/reference/release-naming.html
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the T release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria
-

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region
---

The Geographic Region from where names for the S release will come is Colorado

Proposed Names
--

* Tarryall
* Teakettle
* Teller
* Telluride
* Thomas : the Tank Engine
* Thornton
* Tiger
* Tincup
* Timnath
* Timber
* Tiny Town
* Torreys
* Trail
* Trinidad
* Treasure
* Troublesome
* Trussville
* Turret
* Tyrone

Proposed Names that do not meet the criteria (accepted by the TC)
-

* Train🚂 : Many Attendees of the first Denver PTG have a story to tell about 
the trains near the PTG hotel.  We could celebrate those stories with this name

Yours Tony.


signature.asc
Description: PGP signature
__
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-dev] [Searchlight][release] Searchlight will release Stein-1

[Trinh Nguyen]

Hi team,

I'm doing a release for Searchlight projects (searchlight, searchlight-ui,
python-searchlightclient) [1]. Please help to review and make sure
everything is ok.

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

Finally \m/ :D

Bests,

-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
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-dev] [goal][upgrade-checkers][Searchlight] Upgrade check command framework initial code

[Trinh Nguyen]

Hi team,

The initial code for upgrade-checker framework has been submitted to
Searchlight [1]. Please take some time to review.

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

Thanks,

-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
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

Re: [openstack-dev] [nova] Volunteer needed to write reshaper FFU hook

[Zhenyu Zheng]

I would like to help since I have now finished all the downstream works.
But I may need to take some time understanding all the background
information

On Mon, Oct 29, 2018 at 11:25 PM Matt Riedemann  wrote:

> Given the outstanding results of my recruiting job last week [1] I have
> been tasked with recruiting one of our glorious and most talented
> contributors to work on the fast-forward-upgrade script changes needed
> for the reshape-provider-tree blueprint.
>
> The work item is nicely detailed in the spec [2]. A few things to keep
> in mind:
>
> 1. There are currently no virt drivers which run the reshape routine.
> However, patches are up for review for libvirt [3] and xen [4]. There
> are also functional tests which exercise the ResourceTracker code with a
> faked out virt driver interface to test reshaping [5].
>
> 2. The FFU entry point will mimic the reshape routine that will happen
> on nova-compute service startup in the ResourceTracker [6].
>
> 3. The FFU script will need to run per-compute service rather than
> globally (or per cell) since it actually needs to call the virt driver's
> update_provider_tree() interface which might need to inspect the
> hardware (like for GPUs).
>
> Given there is already a model to follow from the ResourceTracker this
> should not be too hard, the work will likely mostly be writing tests.
>
> What do you get if you volunteer? The usual: fame, fortune, the respect
> of your peers, etc.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136075.html
> [2]
>
> https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/reshape-provider-tree.html#offline-upgrade-script
> [3] https://review.openstack.org/#/c/599208/
> [4] https://review.openstack.org/#/c/521041/
> [5]
>
> https://github.com/openstack/nova/blob/a0eacbf7f/nova/tests/functional/test_servers.py#L1839
> [6]
>
> https://github.com/openstack/nova/blob/a0eacbf7f/nova/compute/resource_tracker.py#L917-L940
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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 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-dev] [NOVA] nova GPU suppot and find GPU type

[Manuel Sopena Ballesteros]

Dear Nova community,

This is the first time I work with GPUs.

I have a Dell C4140 with x4 Nvidia Tesla V100 SXM2 16GB I would like to setup 
on Openstack Rocky.

I checked the documentation and I have 2 questions I would like to ask:


1.   Docs (1) says As of the Queens release, there is no upstream 
continuous integration testing with a hardware environment that has virtual 
GPUs and therefore this feature is considered experimental. Does it means nova 
will stop supporting GPUs? Is GPU support being transferred to a different 
project?

2.   I installed cuda-repo-rhel7-10-0-local-10.0.130-410.48-1.0-1.x86_64 on 
the physical host but I can't find the type of GPUs installed (2) 
(/sys/class/mdev_bus doesn't exists). What should I do then? What should I put 
in 
devices.enabled_vgpu_types?

(1) - https://docs.openstack.org/nova/rocky/admin/virtual-gpu.html
(2)- 
https://docs.openstack.org/nova/rocky/admin/virtual-gpu.html#how-to-discover-a-gpu-type

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: 
manuel...@garvan.org.au

NOTICE
Please consider the environment before printing this email. This message and 
any attachments are intended for the addressee named and may contain legally 
privileged/confidential/copyright information. If you are not the intended 
recipient, you should not read, use, disclose, copy or distribute this 
communication. If you have received this message in error please notify us at 
once by return email and then delete both messages. We accept no liability for 
the distribution of viruses or similar in electronic communications. This 
notice should not be removed.
__
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-dev] [qa] [api] [all] gabbi-tempest for integration tests

[Chris Dent]

Earlier this month I produced a blog post on something I was working
on to combine gabbi (the API tester used in placement, gnocchi,
heat, and a few other projects) with tempest to create a simple two
step process for having some purely YAML-driven and HTTP API-based
of any project that can test with tempest. That blog posting is at:

   https://anticdent.org/gabbi-in-the-gate.html

I've got it working now and the necessary patches have merged in
tempest and gabbi-tempest is now part of openstack's infra.

A pending patch in nova shows how it can work:

   https://review.openstack.org/#/c/613386/

The two steps are:

* Add a new job in .zuul.yaml with a parent of 'gabbi-tempest'
* Create some gabbi YAML files containing tests in a directory
  named in that zuul job.
* Profit.

There are a few different pieces that have come together to make
this possible:

* The magic of zuul v3, local job config and job inheritance.
* gabbi: https://gabbi.readthedocs.io/
* gabbi-tempest: https://gabbi-tempest.readthedocs.io/ and
  https://git.openstack.org/cgit/openstack/gabbi-tempest
  and the specific gabbi-tempest zuul job:
  https://git.openstack.org/cgit/openstack/gabbi-tempest/tree/.zuul.yaml#n11
* tempest plugins and other useful ways of getting placement to run
  in different ways

I hope this is useful for people. Using gabbi is a great way to make
sure that your HTTP API is usable with lots of different clients and
without maintaining a lot of state.

Let me know if you have any questions or if you are interested in
helping to make gabbi-tempest more complete and well documented.
I've been approving my own code the past few patches and that feels
a bit dirty.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [qa] patrole] Nominating Sergey Vilgelm and Mykola Yakovliev for Patrole core

[BARTRA, RICK]

+1 for both of them as well.

On 10/29/18, 2:54 PM, "MONTEIRO, FELIPE C"  wrote:



-Original Message-
From: Ghanshyam Mann [mailto:gm...@ghanshyammann.com] 
Sent: Monday, October 22, 2018 7:09 PM
To: OpenStack Development Mailing List \ 
Subject: Re: [openstack-dev] [qa] patrole] Nominating Sergey Vilgelm and 
Mykola Yakovliev for Patrole core

+1 for both of them. They have been doing great work in Patrole and will be 
good addition in team. 

-gmann


  On Tue, 23 Oct 2018 03:34:51 +0900 MONTEIRO, FELIPE C 
 wrote  
 >   
 > Hi,
 >   
 >  I would like to nominate Sergey Vilgelm and Mykola Yakovliev for 
Patrole core as they have both done excellent work the past cycle in improving 
the Patrole framework as well as increasing Neutron Patrole test coverage, 
which includes various  Neutron plugins/extensions as well like fwaas. I 
believe they will both make an excellent addition to the Patrole core team.
 >   
 >  Please vote with a +1/-1 for the nomination, which will stay open for 
one week.
 >   
 >  Felipe
 > 
__
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > 
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=X4GwEru-SJ9DRnCxhze-aw&m=Hr9uSwCAFUivOWpV_I3WfWWX2j2FaDOJgydFtf1xADs&s=tM-1KJHy12lSqbDfRmZNuc_dgRsAjBqLMZchmEVHGEo&e=
 > 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=X4GwEru-SJ9DRnCxhze-aw&m=Hr9uSwCAFUivOWpV_I3WfWWX2j2FaDOJgydFtf1xADs&s=tM-1KJHy12lSqbDfRmZNuc_dgRsAjBqLMZchmEVHGEo&e=


__
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

Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

[Doug Hellmann]

Monty Taylor  writes:

> On 10/29/18 10:47 AM, Doug Hellmann wrote:
>> Monty Taylor  writes:
>> 
>>> Heya,
>>>
>>> Tobias and I were chatting at OpenStack Days Nordic about the Public
>>> Cloud Working Group potentially taking over as custodians of the vendor
>>> profile information [0][1] we keep in openstacksdk (and previously in
>>> os-client-config)
>>>
>>> I think this is a fine idea, but we've got some dancing to do I think.
>>>
>>> A few years ago Dean and I talked about splitting the vendor data into
>>> its own repo. We decided not to at the time because it seemed like extra
>>> unnecessary complication. But I think we may have reached that time.
>>>
>>> We should split out a new repo to hold the vendor data json files. We
>>> can manage this repo pretty much how we manage the
>>> service-types-authority [2] data now. Also similar to that (and similar
>>> to tzdata) these are files that contain information that is true
>>> currently and is not release specific - so it should be possible to
>>> update to the latest vendor files without updating to the latest
>>> openstacksdk.
>>>
>>> If nobody objects, I'll start working through getting a couple of new
>>> repos created. I'm thinking openstack/vendor-profile-data, owned/managed
>>> by Public Cloud WG, with the json files, docs, json schema, etc, and a
>>> second one, openstack/os-vendor-profiles - owned/managed by the
>>> openstacksdk team that's just like os-service-types [3] and is a
>>> tiny/thin library that exposes the files to python (so there's something
>>> to depend on) and gets proposed patches from zuul when new content is
>>> landed in openstack/vendor-profile-data.
>>>
>>> How's that sound?
>> 
>> I understand the benefit of separating the data files from the SDK, but
>> what is the benefit of separating the data files from the code that
>> reads them?
>
> I'd say primarily so that the same data files can be used from other 
> languages. (similar to having the service-types-authority data exist 
> separate from the python library that consumes it.)
>
> Also - there is a separation of concerns, potentially. The review team 
> for a vendor-data repo could just be public cloud sig folks - and what 
> they are reviewing is the accuracy of the data. The python code to 
> consume that and interpret it is likely a different set of humans.

The argument about languages is more convincing but I'll accept both
answers. The plan makes sense to me, now.

Doug

__
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

Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

[Monty Taylor]

On 10/29/18 10:47 AM, Doug Hellmann wrote:

Monty Taylor  writes:


Heya,

Tobias and I were chatting at OpenStack Days Nordic about the Public
Cloud Working Group potentially taking over as custodians of the vendor
profile information [0][1] we keep in openstacksdk (and previously in
os-client-config)

I think this is a fine idea, but we've got some dancing to do I think.

A few years ago Dean and I talked about splitting the vendor data into
its own repo. We decided not to at the time because it seemed like extra
unnecessary complication. But I think we may have reached that time.

We should split out a new repo to hold the vendor data json files. We
can manage this repo pretty much how we manage the
service-types-authority [2] data now. Also similar to that (and similar
to tzdata) these are files that contain information that is true
currently and is not release specific - so it should be possible to
update to the latest vendor files without updating to the latest
openstacksdk.

If nobody objects, I'll start working through getting a couple of new
repos created. I'm thinking openstack/vendor-profile-data, owned/managed
by Public Cloud WG, with the json files, docs, json schema, etc, and a
second one, openstack/os-vendor-profiles - owned/managed by the
openstacksdk team that's just like os-service-types [3] and is a
tiny/thin library that exposes the files to python (so there's something
to depend on) and gets proposed patches from zuul when new content is
landed in openstack/vendor-profile-data.

How's that sound?


I understand the benefit of separating the data files from the SDK, but
what is the benefit of separating the data files from the code that
reads them?


I'd say primarily so that the same data files can be used from other 
languages. (similar to having the service-types-authority data exist 
separate from the python library that consumes it.)


Also - there is a separation of concerns, potentially. The review team 
for a vendor-data repo could just be public cloud sig folks - and what 
they are reviewing is the accuracy of the data. The python code to 
consume that and interpret it is likely a different set of humans.


__
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

Re: [openstack-dev] [all] We're combining the lists!

[Jeremy Stanley]

On 2018-10-29 12:58:09 -0400 (-0400), Jay Pipes wrote:
> I'm not willing to subscribe with a password over a non-TLS
> connection...
[...]

Up to you, certainly. You don't actually need to enter anything in
the password fields on the subscription page (as the instructions on
it also indicate). You can alternatively subscribe by sending E-mail
to openstack-discuss-requ...@lists.openstack.org with a subject line
of "subscribe" if you prefer.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [user-committee] UC Meeting Reminder

[Melvin Hillsman]

UC meeting in #openstack-uc  at
1800UTC

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
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-dev] [nova] FYI: change in semantics for virt driver update_provider_tree()

[Matt Riedemann]

This is a notice to any out of tree virt driver implementors of the 
ComputeDriver.update_provider_tree() interface that they now need to set 
the allocation_ratio and reserved amounts for VCPU, MEMORY_MB and 
DISK_GB inventory from the update_provider_tree() method assuming [1] 
merges. The patch below that one in the series shows how it's 
implemented for the libvirt driver.


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

--

Thanks,

Matt

__
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

Re: [openstack-dev] [all] We're combining the lists!

[Jay Pipes]

I'm not willing to subscribe with a password over a non-TLS connection...

-jay

On 10/29/2018 12:53 PM, Jeremy Stanley wrote:

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 127 subscribers so far on
openstack-discuss with 3 weeks to go before it will be put into use
(and 5 weeks now before the old lists are closed down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html



__
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 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

Re: [openstack-dev] [all] We're combining the lists! (was: Bringing the community together...)

[Jeremy Stanley]

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 127 subscribers so far on
openstack-discuss with 3 weeks to go before it will be put into use
(and 5 weeks now before the old lists are closed down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [tripleo] retirement of instack

[Alex Schultz]

With the proposed retirement of instack-undercloud[0], we will no
longer be supporting future development of the instack project as
well. As with instack-undercloud, we will continue to support the
stable branches of instack for their life but will not being doing any
future development.  Please let me know if there are any issues.

Thanks,
-Alex

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136098.html

__
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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

On Fri, Oct 26, 2018 at 10:34 AM Won  wrote:

>
> I solved the problem of not updating the Prometheus alarm.
> Alarms with the same Prometheus alarm name are recognized as the same
> alarm in vitrage.
>
> --- alert.rules.yml
> groups:
> - name: alert.rules
>   rules:
>   - alert: InstanceDown
> expr: up == 0
> for: 60s
> labels:
>   severity: warning
> annotations:
>   description: '{{ $labels.instance }} of job {{ $labels.job }} has
> been down
> for more than 30 seconds.'
>   summary: Instance {{ $labels.instance }} down
> --
> This is the contents of the alert.rules.yml file before I modify it.
> This is a yml file that generates an alarm when the cardvisor
> stops(instance down). Alarm is triggered depending on which instance is
> down, but all alarms have the same name as 'instance down'. Vitrage
> recognizes all of these alarms as the same alarm. Thus, until all 'instance
> down' alarms were cleared, the 'instance down' alarm was recognized as
> unresolved and the alarm was not extinguished.
>

This is strange. I would expect your original definition to work as well,
since the alarm key in Vitrage is defined by a combination of the alert
name and the instance. We will check it again.
BTW,  we solved a different bug related to Prometheus alarms not being
cleared [1]. Could it be related?


> Can you please show me where you saw the 2001 timestamp? I didn't find it
>> in the log.
>>
>
> [image: image.png]
> The time stamp is recorded well in log(vitrage-graph,collect etc), but in
> vitrage-dashboard it is marked 2001-01-01.
> However, it seems that the time stamp is recognized well internally
> because the alarm can be resolved and is recorded well in log.
>

Does the wrong timestamp appear if you run 'vitrage alarm list' cli
command? please try running 'vitrage alarm list --debug' and send me the
output.


> [image: image.png]
> Host name ubuntu is my main server. I install openstack all in one in this
> server and i install compute node in host name compute1.
> When i create a new vm in nova(compute1) it immediately appear in the
> entity graph. But in does not disappear in the entity graph when i delete
> the vm. No matter how long i wait, it doesn't disappear.
> Afther i execute 'vitrage-purge-data' command and reboot the
> Openstack(execute reboot command in openstack server(host name ubuntu)), it
> disappear. Only execute 'vitrage-purge-data' does not work. It need a
> reboot to disappear.
> When i create a new vm in nova(ubuntu) there is no problem.
>
Please send me vitrage-collector.log and vitrage-graph.log from the time
that the problematic vm was created and deleted. Please also create and
delete a vm on your 'ubuntu' server, so I can check the differences in the
log.

I implemented the web service of the micro service architecture and applied
> the RCA. Attached file picture shows the structure of the web service I
> have implemented. I wonder what data I receive and what can i do when I
> link vitrage with kubernetes.
> As i know, the vitrage graph does not present information about containers
> or pods inside the vm. If that is correct, I would like to make the
> information of the pod level appear on the entity graph.
>
> I follow (
> https://docs.openstack.org/vitrage/latest/contributor/k8s_datasource.html)
> this step. I attached the vitage.conf file and the kubeconfig file. The
> contents of the Kubeconconfig file are copied from the contents of the
> admin.conf file on the master node.
> I want to check my settings are right and connected, but I don't know how.
> It would be very much appreciated if you let me know how.
>
Unfortunately, Vitrage does not hold pods and containers information at the
moment. We discussed the option of adding it in Stein release, but I'm not
sure we will get to do it.

Br,
Ifat

[1] https://review.openstack.org/#/c/611258/
__
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

Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

[Doug Hellmann]

Monty Taylor  writes:

> Heya,
>
> Tobias and I were chatting at OpenStack Days Nordic about the Public 
> Cloud Working Group potentially taking over as custodians of the vendor 
> profile information [0][1] we keep in openstacksdk (and previously in 
> os-client-config)
>
> I think this is a fine idea, but we've got some dancing to do I think.
>
> A few years ago Dean and I talked about splitting the vendor data into 
> its own repo. We decided not to at the time because it seemed like extra 
> unnecessary complication. But I think we may have reached that time.
>
> We should split out a new repo to hold the vendor data json files. We 
> can manage this repo pretty much how we manage the 
> service-types-authority [2] data now. Also similar to that (and similar 
> to tzdata) these are files that contain information that is true 
> currently and is not release specific - so it should be possible to 
> update to the latest vendor files without updating to the latest 
> openstacksdk.
>
> If nobody objects, I'll start working through getting a couple of new 
> repos created. I'm thinking openstack/vendor-profile-data, owned/managed 
> by Public Cloud WG, with the json files, docs, json schema, etc, and a 
> second one, openstack/os-vendor-profiles - owned/managed by the 
> openstacksdk team that's just like os-service-types [3] and is a 
> tiny/thin library that exposes the files to python (so there's something 
> to depend on) and gets proposed patches from zuul when new content is 
> landed in openstack/vendor-profile-data.
>
> How's that sound?

I understand the benefit of separating the data files from the SDK, but
what is the benefit of separating the data files from the code that
reads them?

Doug

>
> Thanks!
> Monty
>
> [0] 
> http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors
> [1] 
> https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html
> [2] http://git.openstack.org/cgit/openstack/service-types-authority
> [3] http://git.openstack.org/cgit/openstack/os-service-types
>
> __
> 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 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-dev] [nova] Volunteer needed to write reshaper FFU hook

[Matt Riedemann]

Given the outstanding results of my recruiting job last week [1] I have 
been tasked with recruiting one of our glorious and most talented 
contributors to work on the fast-forward-upgrade script changes needed 
for the reshape-provider-tree blueprint.


The work item is nicely detailed in the spec [2]. A few things to keep 
in mind:


1. There are currently no virt drivers which run the reshape routine. 
However, patches are up for review for libvirt [3] and xen [4]. There 
are also functional tests which exercise the ResourceTracker code with a 
faked out virt driver interface to test reshaping [5].


2. The FFU entry point will mimic the reshape routine that will happen 
on nova-compute service startup in the ResourceTracker [6].


3. The FFU script will need to run per-compute service rather than 
globally (or per cell) since it actually needs to call the virt driver's 
update_provider_tree() interface which might need to inspect the 
hardware (like for GPUs).


Given there is already a model to follow from the ResourceTracker this 
should not be too hard, the work will likely mostly be writing tests.


What do you get if you volunteer? The usual: fame, fortune, the respect 
of your peers, etc.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-October/136075.html
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/reshape-provider-tree.html#offline-upgrade-script

[3] https://review.openstack.org/#/c/599208/
[4] https://review.openstack.org/#/c/521041/
[5] 
https://github.com/openstack/nova/blob/a0eacbf7f/nova/tests/functional/test_servers.py#L1839
[6] 
https://github.com/openstack/nova/blob/a0eacbf7f/nova/compute/resource_tracker.py#L917-L940


--

Thanks,

Matt

__
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

Re: [openstack-dev] [ironic] Team gathering at the Forum?

[Dmitry Tantsur]

Hi folks!

This is your friendly reminder to vote on the day. Even if you're fine with all 
days, please leave a vote, so that we know how many people are coming. We will 
need to make a reservation, and we may not be able to accommodate more people 
than voted!


Dmitry

On 10/22/18 6:06 PM, Dmitry Tantsur wrote:

Hi ironicers! :)

We are trying to plan an informal Ironic team gathering in Berlin. If you care 
about Ironic and would like to participate, please fill in 
https://doodle.com/poll/iw5992px765nthde. Note that the location is tentative, 
also depending on how many people sign up.


Dmitry



__
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

Re: [openstack-dev] [heat][nova] Does Heat support Nova micro versions

[Rabi Mishra]

On Sat, Oct 27, 2018 at 10:08 PM Gary Kotton  wrote:

> Hi,
>
> Does heat support os-compute-api-version? Say for example I am using
> queens but have a use case via heat that requires a API parameter that was
> capped in the 2.56
>

There isn't a way to specify compute microversion in the template.

Till queens, heat client plugin for nova was using the base api version[1],
unless a specific feature/property requires a higher mircoversion[2]. So
features capped in newer api versions should be usable without any change.

However, we moved to use the "max api microversion supported" as the
default[3] since rocky to support new features without much changes and not
to have too many versioned clients. As a side-effect, features/properties
capped by new nova api microversions can't be used any more.

We probably have to look for a better way to handle this in the future.


[1]
https://github.com/openstack/heat/blob/stable/queens/heat/engine/clients/os/nova.py#L61
[2]
https://github.com/openstack/heat/blob/stable/queens/heat/engine/resources/openstack/nova/server.py#L838
[3]
https://github.com/openstack/heat/blob/stable/rocky/heat/engine/clients/os/nova.py#L100


> microversion.
>
> Thanks
>
> Gary
> __
> 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
>


-- 
Regards,
Rabi Mishra
__
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