Re: [openstack-dev] Asking for ask.openstack.org

[Ian Wienand]

On 04/05/2018 10:23 AM, Zane Bitter wrote:

On 04/04/18 17:26, Jimmy McArthur wrote:
Here's the thing: email alerts. They're broken.


This is the type of thing we can fix if we know about it ... I will
contact you off-list because the last email to what I presume is you
went to an address that isn't what you've sent from here, but it was
accepted by the remote end.

-i

__
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] Asking for ask.openstack.org

[Ian Wienand]

On 04/05/2018 08:30 AM, Paul Belanger wrote:
> We likely need to reduce the number of days we retain database
> backups / http logs or look to attach a volume to increase storage.

We've long had problems with this host and I've looked at it before
[1].  It often drops out.

It seems there's enough interest we should dive a bit deeper.  Here's
what I've found out:

askbot
--

Of the askbot site, it seems under control, except for an unbounded
session log file.  Proposed [2]

 root@ask:/srv# du -hs *
 2.0G   askbot-site
 579M   dist

overall
---

The major consumer is /var; where we've got

 3.9G   log
 5.9G   backups
 9.4G   lib

backups
---

The backup seem under control at least; we're rotating them out and we
keep 10, and the size is pretty consistently 500mb:

 root@ask:/var/backups/pgsql_backups# ls -lh
 total 5.9G
 -rw-r--r-- 1 root root 599M Apr  5 00:03 askbotdb.sql.gz
 -rw-r--r-- 1 root root 598M Apr  4 00:03 askbotdb.sql.gz.1
 ...

We could reduce the backup rotations to just one if we like -- the
server is backed up nightly via bup, so at any point we can get
previous dumps from there.  bup should de-duplicate everything, but
still, it's probably not necessary.

The db directory was sitting at ~9gb

 root@ask:/var/lib/postgresql# du -hs
 8.9G   .

AFAICT, it seems like the autovacuum is running OK on the busy tables

 askbotdb=# select relname,last_vacuum, last_autovacuum, last_analyze, 
last_autoanalyze from pg_stat_user_tables where last_autovacuum is not NULL;
  relname  | last_vacuum |last_autovacuum| 
last_analyze  |   last_autoanalyze
 
--+-+---+---+---
  django_session   | | 2018-04-02 17:29:48.329915+00 | 2018-04-05 
02:18:39.300126+00 | 2018-04-05 00:11:23.456602+00
  askbot_badgedata | | 2018-04-04 07:19:21.357461+00 |  
 | 2018-04-04 07:18:16.201376+00
  askbot_thread| | 2018-04-04 16:24:45.124492+00 |  
 | 2018-04-04 20:32:25.845164+00
  auth_message | | 2018-04-04 12:29:24.273651+00 | 2018-04-05 
02:18:07.633781+00 | 2018-04-04 21:26:38.178586+00
  djkombu_message  | | 2018-04-05 02:11:50.186631+00 |  
 | 2018-04-05 02:14:45.22926+00

Out of interest I did run a manual

 su - postgres -c "vacuumdb --all --full --analyze"

We dropped something

 root@ask:/var/lib/postgresql# du -hs
 8.9G   .
 (after)
 5.8G   

I installed pg_activity and watched for a while; nothing seemed to be
really stressing it.

Ergo, I'm not sure if there's much to do in the db layers.

logs


This leaves the logs

 1.1G   jetty
 2.9G   apache2

The jetty logs are cleaned regularly.  I think they could be made more
quiet, but they seem to be bounded.

Apache logs are rotated but never cleaned up.  Surely logs from 2015
aren't useful.  Proposed [3]

Random offline
--

[3] is an example of a user reporting the site was offline.  Looking
at the logs, it seems that puppet found httpd not running at 07:14 and
restarted it:

 Apr  4 07:14:40 ask puppet-user[20737]: (Scope(Class[Postgresql::Server])) 
Passing "version" to postgresql::server is deprecated; please use 
postgresql::globals instead.
 Apr  4 07:14:42 ask puppet-user[20737]: Compiled catalog for ask.openstack.org 
in environment production in 4.59 seconds
 Apr  4 07:14:44 ask crontab[20987]: (root) LIST (root)
 Apr  4 07:14:49 ask puppet-user[20737]: 
(/Stage[main]/Httpd/Service[httpd]/ensure) ensure changed 'stopped' to 'running'
 Apr  4 07:14:54 ask puppet-user[20737]: Finished catalog run in 10.43 seconds

Which first explains why when I looked, it seemed OK.  Checking the
apache logs we have:

 [Wed Apr 04 07:01:08.144746 2018] [:error] [pid 12491:tid 140439253419776] 
[remote 176.233.126.142:43414] mod_wsgi (pid=12491): Exception occurred 
processing WSGI script '/srv/askbot-site/config/django.wsgi'.
 [Wed Apr 04 07:01:08.144870 2018] [:error] [pid 12491:tid 140439253419776] 
[remote 176.233.126.142:43414] IOError: failed to write data
 ... more until ...
 [Wed Apr 04 07:15:58.270180 2018] [:error] [pid 17060:tid 140439253419776] 
[remote 176.233.126.142:43414] mod_wsgi (pid=17060): Exception occurred 
processing WSGI script '/srv/askbot-site/config/django.wsgi'.
 [Wed Apr 04 07:15:58.270303 2018] [:error] [pid 17060:tid 140439253419776] 
[remote 176.233.126.142:43414] IOError: failed to write data

and the restart logged

 [Wed Apr 04 07:14:48.912626 2018] [core:warn] [pid 21247:tid 140439370192768] 
AH00098: pid file /var/run/apache2/apache2.pid overwritten -- Unclean shutdown 
of previous Apache run?
 [Wed Apr 04 07:14:48.913548 2018] [mpm_event:notice] [pid 21247:tid 
140439370192768] AH00489: Apache/2.4.7 (Ubuntu) OpenSSL/1.0.1f mod_wsgi/3.4 
Python/2.7.6 configured -- resuming normal operations
 [Wed Apr 04 0

Re: [openstack-dev] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

Thanks for the good comments.

 

It was very helpful.

 

As you said, I tested for std.ssh, and I was able to get much better
results.

 

I am confident that this is what I want.

 

We can use std.ssh to provide convenience to users with a much more
efficient way to configure shell scripts / monitoring agent automation(for
Zabbix history,etc) / other commands.

 

In addition, std_actions.py contained a number of features that could be
used for this proposal (such as HTTP).

 

So if we actively use and utilize the actions in std_actions.py, we might
be able to construct neat code without the duplicate functionality that you
worried about.

 

It has been a great help.

 

In addition, I also agree that Vitrage action is required for Mistral.

 

If possible, I might be able to do that in the future.(ASAP)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, April 4, 2018 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I discussed this issue with a Mistral contributor. 

Mistral has a long list of actions that can be used. Specifically, you can
use the std.ssh action to execute shell scripts.

 

Some useful commands:

 

mistral action-list

mistral action-get 

 

I’m not sure about the output of the std.ssh, and whether you can get it
from the action. I suggest you try it and see how it works.

The action is implemented here:
https://github.com/openstack/mistral/blob/master/mistral/actions/std_actions
.py 

 

If std.ssh does not suit your needs, you also have an option to implement
and run your own action in Mistral (either as an ssh action or as a python
code). 

And BTW, it is not related to your current use case, but we can also add
Vitrage actions to Mistral, so the user can access Vitrage information (get
topology, get alarms) from Mistral workflows. 

 

Best regards,

Ifat

 

 

From: MinWookKim mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 15:19
To: "'OpenStack Development Mailing List (not for usage questions)'"
mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.

 

Your comments have been a great help to the proposal.  (sorry, I did not
think we could use Mistral).

 

If we use the Mistral workflow for the proposal, we can get better results
(we can get good results on performance and code conciseness).

 

Also, if we use the Mistral workflow, we do not need to write any
unnecessary code.

 

Since I don't know about mistral yet, I think it would be better to do the
most efficient design including mistral after grasping it.

 

If we run a check through a Mistral workflow, how about providing users
with a choice of tools that have the capability to perform checks?

 

We can get the results of the check through the Mistral and tools, but I
think we need the least functionality to manage them. What do you think?

 

I attached a picture of the actual UI that I simply implemented. I hope it
helps you understand. (The parameter and content have no meaning and are a
simple example.) : )

 

Thanks.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 3, 2018 8:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Thanks for the explanation, I understand the reasons for not running these
checks on a regular basis in Zabbix or other monitoring tools. It makes
sense. However, I don’t want to re-invent the wheel and add to Vitrage
functionality that already exists in other projects. 

 

How about using Mistral for the purpose of manually running these extra
checks? If you prepare the script/agent in advance, as well as the Mistral
workflow, I believe that Mistral can successfully execute the check and
return the results. I’m not so sure about the UI part, we will have to
figure out how and where the user can see the output. But it will save a lot
of effort around managing the checks, running a new service, supporting a
new API, etc.

 

What do you think?

Ifat

 

 

From: MinWookKim mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 5:36
To: "'OpenStack Development Mailing List (not for usage questions)'"
mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat, 

 

I also thought about several scenarios that use monitoring tools like
Zabbix, Nagios, and Prometheus.

 

But there are some li

Re: [openstack-dev] Asking for ask.openstack.org

[Zhipeng Huang]

The email alert definitely should be the first one to get fixed :)

On Thu, Apr 5, 2018 at 8:23 AM, Zane Bitter  wrote:

> On 04/04/18 17:26, Jimmy McArthur wrote:
>
>> Hi everyone!
>>
>> We have a very robust and vibrant community at ask.openstack.org <
>> https://ask.openstack.org/>.  There are literally dozens of posts a day.
>> However, many of them don't receive knowledgeable answers.  I'm really
>> worried about this becoming a vacuum where potential community members get
>> frustrated and don't realize how to get more involved with the community.
>>
>> I'm looking for thoughts/ideas/feelings about this tool as well as
>> potential admin volunteers to help us manage the constant influx of
>> technical and not-so-technical questions around OpenStack.
>>
>
> Here's the thing: email alerts. They're broken.
>
> I have had my email alert preferences set to 'only subscribed tags' with a
> daily 'Entire forum (tag filtered)' email for several (like 4) years now. I
> am subscribed to exactly 3 tags.[1]
>
> For the first 3 years, I didn't receive any email alerts at all despite
> repeated fiddling with the settings. At the beginning of 2017 there was a
> software update and I started getting daily emails that are *not* tag
> filtered. (I know it was due to a software update, because the first emails
> started coming from the staging server.) Within a couple of days those
> emails started to go directly to spam, because GMail. I trained it not to
> do that any more for me, but it's unlikely most people did, and in any
> event all I get is a daily email that generally doesn't contain any of the
> questions I am interested in - even on days where there _are_ in fact new
> questions with tags that I am subscribed to.
>
> I've been able to make a reasonably significant contribution to answering
> questions because I've made it a habit to check the site itself regularly
> (and the tag filtering on the home page works really quite well). But
> anyone wanting to use technical means to give them notice about only the
> stuff they're interested in only when needed would be unable to do so. (And
> even if you fixed it at this point it'd all be sucked into spam filters.)
>
> There's other problems too - for example if somebody posts a question with
> not enough information and I post a comment asking for more, I won't get a
> notification when they reply unless they specifically @ me, which most
> people won't. (Sometimes I've discovered the replies only years later.) In
> fact in general the learning curve is way too high for people who just want
> to ask a casual question - for example, I'd say users are considerably more
> likely to respond to a correct answer by posting their own 'answer' that
> says 'It worked!' (or, worse, contains a totally unrelated question) than
> they are to click the 'Accepted answer' button - and there's no point
> trying to educate them because you almost never see the same user twice.
> Those are all broader problems with the design of StackExchange though; the
> alert thing is a feature that's supposedly present but doesn't work as
> advertised.
>
> It's also worth noting that the voting in general is fairly pointless
> because ~nobody has an account registered. So if people find a useful
> question and/or answer on ask.openstack from a search engine, they still
> won't bother to upvote because they'd have to create an account.
> Communities with critical mass like StackOverflow can use voting as a
> quality signal to surface the best content; we don't get enough data for
> that. (For reference, I've answered 237 questions and less than a dozen
> have ever gotten a second upvote - which is likely a good proxy for 'has
> ever been voted on by someone other than the original questioner'.)
>
> So, suggestions:
>
> * Fix the email subscription thing.
> * Ensure all devs have an account - perhaps by creating one for them using
> their IRC nickname & Foundation email? - and encourage people to @ each
> other when they see a question where they don't know the answer but they
> know who would (like you might add people to a Gerrit review). (Although
> realistically most of this will end up in the Spam folder... some might say
> deservedly ;)
> * Encourage teams to figure out a set of tags they want to watch, and
> encourage at least all core reviewers to log in once and set up their tag
> subscriptions so they'll see something useful when they visit the homepage.
> * Ask each team to come up with 1 or 2 volunteers to subscribe to
> (filtered!) email alerts and try to answer or triage incoming questions.
>
> For those of you already contributing there, Thank You!  For those that
>> are interested in becoming a moderator (instant AUC status!) or have some
>> additional ideas around fostering this community, please respond.
>>
>
> I'm not sure what else there is that I can't already do at my current
> karma level, but you're welcome to add me to the list and I'll try to do
> some of it in my travels

Re: [openstack-dev] Asking for ask.openstack.org

[Zane Bitter]

On 04/04/18 17:26, Jimmy McArthur wrote:

Hi everyone!

We have a very robust and vibrant community at ask.openstack.org 
.  There are literally dozens of posts a 
day. However, many of them don't receive knowledgeable answers.  I'm 
really worried about this becoming a vacuum where potential community 
members get frustrated and don't realize how to get more involved with 
the community.


I'm looking for thoughts/ideas/feelings about this tool as well as 
potential admin volunteers to help us manage the constant influx of 
technical and not-so-technical questions around OpenStack.


Here's the thing: email alerts. They're broken.

I have had my email alert preferences set to 'only subscribed tags' with 
a daily 'Entire forum (tag filtered)' email for several (like 4) years 
now. I am subscribed to exactly 3 tags.[1]


For the first 3 years, I didn't receive any email alerts at all despite 
repeated fiddling with the settings. At the beginning of 2017 there was 
a software update and I started getting daily emails that are *not* tag 
filtered. (I know it was due to a software update, because the first 
emails started coming from the staging server.) Within a couple of days 
those emails started to go directly to spam, because GMail. I trained it 
not to do that any more for me, but it's unlikely most people did, and 
in any event all I get is a daily email that generally doesn't contain 
any of the questions I am interested in - even on days where there _are_ 
in fact new questions with tags that I am subscribed to.


I've been able to make a reasonably significant contribution to 
answering questions because I've made it a habit to check the site 
itself regularly (and the tag filtering on the home page works really 
quite well). But anyone wanting to use technical means to give them 
notice about only the stuff they're interested in only when needed would 
be unable to do so. (And even if you fixed it at this point it'd all be 
sucked into spam filters.)


There's other problems too - for example if somebody posts a question 
with not enough information and I post a comment asking for more, I 
won't get a notification when they reply unless they specifically @ me, 
which most people won't. (Sometimes I've discovered the replies only 
years later.) In fact in general the learning curve is way too high for 
people who just want to ask a casual question - for example, I'd say 
users are considerably more likely to respond to a correct answer by 
posting their own 'answer' that says 'It worked!' (or, worse, contains a 
totally unrelated question) than they are to click the 'Accepted answer' 
button - and there's no point trying to educate them because you almost 
never see the same user twice. Those are all broader problems with the 
design of StackExchange though; the alert thing is a feature that's 
supposedly present but doesn't work as advertised.


It's also worth noting that the voting in general is fairly pointless 
because ~nobody has an account registered. So if people find a useful 
question and/or answer on ask.openstack from a search engine, they still 
won't bother to upvote because they'd have to create an account. 
Communities with critical mass like StackOverflow can use voting as a 
quality signal to surface the best content; we don't get enough data for 
that. (For reference, I've answered 237 questions and less than a dozen 
have ever gotten a second upvote - which is likely a good proxy for 'has 
ever been voted on by someone other than the original questioner'.)


So, suggestions:

* Fix the email subscription thing.
* Ensure all devs have an account - perhaps by creating one for them 
using their IRC nickname & Foundation email? - and encourage people to @ 
each other when they see a question where they don't know the answer but 
they know who would (like you might add people to a Gerrit review). 
(Although realistically most of this will end up in the Spam folder... 
some might say deservedly ;)
* Encourage teams to figure out a set of tags they want to watch, and 
encourage at least all core reviewers to log in once and set up their 
tag subscriptions so they'll see something useful when they visit the 
homepage.
* Ask each team to come up with 1 or 2 volunteers to subscribe to 
(filtered!) email alerts and try to answer or triage incoming questions.


For those of you already contributing there, Thank You!  For those that 
are interested in becoming a moderator (instant AUC status!) or have 
some additional ideas around fostering this community, please respond.


I'm not sure what else there is that I can't already do at my current 
karma level, but you're welcome to add me to the list and I'll try to do 
some of it in my travels.


cheers,
Zane.

[1] Feel free to use your admin powers to poke around in my settings to 
try to figure out what is going on: 
https://ask.openstack.org/en/users/2133/zaneb/?sort=email_subscriptions



Looking forward to your t

Re: [openstack-dev] Asking for ask.openstack.org

[Paul Belanger]

On Wed, Apr 04, 2018 at 04:26:12PM -0500, Jimmy McArthur wrote:
> Hi everyone!
> 
> We have a very robust and vibrant community at ask.openstack.org
> .  There are literally dozens of posts a day.
> However, many of them don't receive knowledgeable answers.  I'm really
> worried about this becoming a vacuum where potential community members get
> frustrated and don't realize how to get more involved with the community.
> 
> I'm looking for thoughts/ideas/feelings about this tool as well as potential
> admin volunteers to help us manage the constant influx of technical and
> not-so-technical questions around OpenStack.
> 
> For those of you already contributing there, Thank You!  For those that are
> interested in becoming a moderator (instant AUC status!) or have some
> additional ideas around fostering this community, please respond.
> 
> Looking forward to your thoughts :)
> 
> Thanks!
> Jimmy
> irc: jamesmcarthur

We also have a 2nd issue where the ask.o.o server doesn't appear to be large
enough any more to handle the traffic. A few times over the last few weeks we've
had outages due to the HDD being full.

We likely need to reduce the number of days we retain database backups / http
logs or look to attach a volume to increase storage.

Paul

__
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] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Michał Jastrzębski]

On 4 April 2018 at 14:45, Brandon Jozsa  wrote:
> I’ve been a part of the OpenStack-Helm project from the very beginning, and
> there was a lot of early brainstorming on how we could collaborate and
> contribute directly to Kolla-Kubernetes. In fact, this was the original
> intent when we met with Kolla back in Barcelona. We didn’t like the idea of
> fragmenting interested Kubernetes developers/operators in the
> OpenStack-via-Kubernetes space. Whatever the project, we wanted all the
> domain expertise concentrated on a single deployment effort. Even though
> OSH/K-k8s couldn’t reach an agreement on how to handle configmaps (our
> biggest difference from the start), there was a lot of early collaboration
> between the project cores. Early K-k8s contributors may remember Halcyon,
> which cores from both sides promoted for early development of
> OpenStack-via-Kubernetes, regardless of the project.
>
> One of the requests from the initial OSH team (in Barcelona) was to formally
> separate Kolla from Kolla-foo deployment projects, both at a project level
> and from a core perspective. Why have the same cores giving +2’s to Kolla,
> Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have
> any interest in another given discipline? We wanted reviews to be timely,
> and laser-focused, and we felt that this more atomic approach would benefit
> Kolla in the end. But unfortunately there was heavy resistance with limited
> yet very influential cores. I honestly think pushback was also because it
> would mean that any Kolla sub-projects would be subject to re-acceptance as
> big tent projects.

Limited, but very influential cores sounds like bad community, and as
it happens I was leading this community at that time, so I feel I
should comment. We would love to increase number of cores (raise a
limit) of images, but that comes with a cost. Cost being that person
who would like to become a core would need to contribute to project in
question and review other people contributions. Proper way to address
this problem would be just that - contributing to Kolla and reviewing
code. If I failed to notice contributions from someone who did that a
lot (I hope I didn't), I'm sorry. This is best and only way to solve
problem in question.

>
> There were also countless discussions about the preservation of the Kolla
> API, or Ansible + Jinja portions of Kolla-Ansible. It became clear to us
> that Kubernetes wasn’t going to be the first class citizen for the
> deployment model in Kolla-Kubernetes, forcing operators to troubleshoot
> between OpenStack, Kolla (container builds), Ansible, Kubernetes, and Helm.
> This is apparent still today. And while I understand the hesitation to
> change Kolla/Kolla-Ansible, I think this code-debt has somewhat contributed
> to sustainability of Kolla-Kubernetes. Somewhat to the point of tension, I
> very much agree with Thierry’s comments earlier.

How k8s wasn't first class citizen? I don't understand. All processes
were the same, time in PTG was generous compared to ansible etc. More
people uses Ansible due to it's maturity so it's obvious it's going to
have better testing etc, but again, solved by contributions.

> I want all of these projects to succeed but consolidation with purposeful
> and deliberate planning, which Rich has so kindly agreed to do, could be the
> right answer. So I +1 the idea, because I think it puts all like-minded
> individuals on the same focus (for the overall benefit of OpenStack and the
> overall OpenStack community). But we have to make sure there isn’t a lot of
> fallout from the decision either. To Steve Dake's previous point, there
> could be orphaned users/operators who feel “forced” into another project. I
> would hate to see that. It would be nice to at least plan this with the
> user-base and give them fair warning. And to this point, what is the active
> specific Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today?

As per election results it's Jeffrey.

> On the other hand, I think that OSH has some improvements to make as well.
> Gating could use some help and the OpenStack-Infra team has been kindly
> helping out recently (a huge "thank you" to them). Docs…I think docs could
> always use some love. Please offer your experiences to the OSH team! We
> would love to hear your user input. Ultimately, if users/operators want to
> run something that even closely resembles production, then we need some
> decent production quality docs as opposed to leveraging the nascent gate
> scripts (Zuulv3 ansible+heat). Releases and release planning should be
> addressed, as users/vendors are going to want to be closer to OpenStack
> release dates (recent versions of OpenStack, Helm and Kubernetes). Clear and
> open roadmaps, with potential use of community-led planning tools. Open
> elections for PTL. Finally, the OSH team may still be be interested in
> diversifying it’s core-base. Matt M. would have to address this. I know that
> I was active

Re: [openstack-dev] [all][infra] Upcoming changes in ARA Zuul job reports

[David Moreau Simard]

Hi,

You might have noticed that the performance (and reliability) of the
new reports aren't up to par.
If you see failures in loading content, a refresh will usually fix the issue.

We have different fixes to improve the performance and the reliability
of the reports and we hope
to be able to land them soon.

In the meantime, please let us know if there is any report that
appears to be particularly
problematic.

Thanks !


David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Thu, Mar 29, 2018 at 6:14 PM, David Moreau Simard
 wrote:
> Hi,
>
> By default, all jobs currently benefit from the generation of a static
> ARA report located in the "ara" directory at the root of the log
> directory.
> Due to scalability concerns, these reports were only generated when a
> job failed and were not available on successful runs.
>
> I'm happy to announce that you can expect ARA reports to be available
> for every job from now on -- including the successful ones !
>
> You'll notice a subtle but important change: the report directory will
> henceforth be named "ara-report" instead of "ara".
>
> Instead of generating and saving a HTML report, we'll now only save
> the ARA database in the "ara-report" directory.
> This is a special directory from the perspective of the
> logs.openstack.org server and ARA databases located in such
> directories will be loaded dynamically by a WSGI middleware.
>
> You don't need to do anything to benefit from this change -- it will
> be pushed to all jobs that inherit from the base job by default.
>
> However, if you happen to be using a "nested" installation of ARA and
> Ansible (i.e, OpenStack-Ansible, Kolla-Ansible, TripleO, etc.), this
> means that you can also leverage this feature.
> In order to do that, you'll want to create an "ara-report" directory
> and copy your ARA database inside before your logs are collected and
> uploaded.
>
> To help you visualize:
> /ara-report <-- This is the default Zuul report
> /logs/ara <-- This wouldn't be loaded dynamically
> /logs/ara-report <-- This would be loaded dynamically
> /logs/some/directory/ara-report <-- This would be loaded dynamically
>
> For more details on this feature of ARA, you can refer to the documentation 
> [1].
>
> Let me know if you have any questions !
>
> [1]: https://ara.readthedocs.io/en/latest/advanced.html
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]

__
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] [Openstack-track-chairs] Asking for ask.openstack.org

[Jimmy McArthur]

Oh that's great! I'll try to attend that talk and, in the meantime, 
gather other relevant tags.  Thanks for the info :)



Kendall Nelson 
April 4, 2018 at 5:09 PM
Hey Jimmy,

So the First Contact SIG has started looking at questions posted on 
ask.o.o with the tags of 'contributor' or 'contribution' on a weekly 
basis and discussing it in our weekly meeting as a standing item. If 
there are other relevant tags that you think we should be looking at I 
would be happy to add them to the list.


At the Summit I have proposed a talk for the Forum to get more 
operator involvement in our SIG and perhaps after we have a more 
diverse SIG we can add some more tags to our watchlist.


-Kendall (diablo_rojo)

Jimmy McArthur 
April 4, 2018 at 4:26 PM
Hi everyone!

We have a very robust and vibrant community at ask.openstack.org 
.  There are literally dozens of posts a 
day. However, many of them don't receive knowledgeable answers.  I'm 
really worried about this becoming a vacuum where potential community 
members get frustrated and don't realize how to get more involved with 
the community.


I'm looking for thoughts/ideas/feelings about this tool as well as 
potential admin volunteers to help us manage the constant influx of 
technical and not-so-technical questions around OpenStack.


For those of you already contributing there, Thank You!  For those 
that are interested in becoming a moderator (instant AUC status!) or 
have some additional ideas around fostering this community, please 
respond.


Looking forward to your thoughts :)

Thanks!
Jimmy
irc: jamesmcarthur
__
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] [Openstack-track-chairs] Asking for ask.openstack.org

[Kendall Nelson]

Hey Jimmy,

So the First Contact SIG has started looking at questions posted on ask.o.o
with the tags of 'contributor' or 'contribution' on a weekly basis and
discussing it in our weekly meeting as a standing item. If there are other
relevant tags that you think we should be looking at I would be happy to
add them to the list.

At the Summit I have proposed a talk for the Forum to get more operator
involvement in our SIG and perhaps after we have a more diverse SIG we can
add some more tags to our watchlist.

-Kendall (diablo_rojo)

On Wed, Apr 4, 2018 at 2:26 PM Jimmy McArthur  wrote:

> Hi everyone!
>
> We have a very robust and vibrant community at ask.openstack.org.  There
> are literally dozens of posts a day. However, many of them don't receive
> knowledgeable answers.  I'm really worried about this becoming a vacuum
> where potential community members get frustrated and don't realize how to
> get more involved with the community.
>
> I'm looking for thoughts/ideas/feelings about this tool as well as
> potential admin volunteers to help us manage the constant influx of
> technical and not-so-technical questions around OpenStack.
>
> For those of you already contributing there, Thank You!  For those that
> are interested in becoming a moderator (instant AUC status!) or have some
> additional ideas around fostering this community, please respond.
>
> Looking forward to your thoughts :)
>
> Thanks!
> Jimmy
> irc: jamesmcarthur
> ___
> Openstack-track-chairs mailing list
> openstack-track-cha...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs
>
__
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] [All] TC Election Season

[Kendall Nelson]

Hello!

Election details: https://governance.openstack.org/election/

Please read the stipulations and timelines for candidates and
electorate contained in this governance documentation.

There will be further announcements posted to the mailing list as
action is required from the electorate or candidates. This email
is for information purposes only.

If you have any questions which you feel affect others please reply to this
email thread.

If you have any questions that you which to discuss in private please email
any of the election officials[1] so that we may address your concerns.

Thank you,

- Kendall Nelson (diablo_rojo)

[1] https://governance.openstack.org/election/#election-officials
__
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] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Brandon Jozsa]

I’ve been a part of the OpenStack-Helm project from the very beginning, and 
there was a lot of early brainstorming on how we could collaborate and 
contribute directly to Kolla-Kubernetes. In fact, this was the original intent 
when we met with Kolla back in Barcelona. We didn’t like the idea of 
fragmenting interested Kubernetes developers/operators in the 
OpenStack-via-Kubernetes space. Whatever the project, we wanted all the domain 
expertise concentrated on a single deployment effort. Even though OSH/K-k8s 
couldn’t reach an agreement on how to handle configmaps (our biggest difference 
from the start), there was a lot of early collaboration between the project 
cores. Early K-k8s contributors may remember Halcyon, which cores from both 
sides promoted for early development of OpenStack-via-Kubernetes, regardless of 
the project.

One of the requests from the initial OSH team (in Barcelona) was to formally 
separate Kolla from Kolla-foo deployment projects, both at a project level and 
from a core perspective. Why have the same cores giving +2’s to Kolla, 
Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have 
any interest in another given discipline? We wanted reviews to be timely, and 
laser-focused, and we felt that this more atomic approach would benefit Kolla 
in the end. But unfortunately there was heavy resistance with limited yet very 
influential cores. I honestly think pushback was also because it would mean 
that any Kolla sub-projects would be subject to re-acceptance as big tent 
projects.

There were also countless discussions about the preservation of the Kolla API, 
or Ansible + Jinja portions of Kolla-Ansible. It became clear to us that 
Kubernetes wasn’t going to be the first class citizen for the deployment model 
in Kolla-Kubernetes, forcing operators to troubleshoot between OpenStack, Kolla 
(container builds), Ansible, Kubernetes, and Helm. This is apparent still 
today. And while I understand the hesitation to change Kolla/Kolla-Ansible, I 
think this code-debt has somewhat contributed to sustainability of 
Kolla-Kubernetes. Somewhat to the point of tension, I very much agree with 
Thierry’s comments earlier.

I want all of these projects to succeed but consolidation with purposeful and 
deliberate planning, which Rich has so kindly agreed to do, could be the right 
answer. So I +1 the idea, because I think it puts all like-minded individuals 
on the same focus (for the overall benefit of OpenStack and the overall 
OpenStack community). But we have to make sure there isn’t a lot of fallout 
from the decision either. To Steve Dake's previous point, there could be 
orphaned users/operators who feel “forced” into another project. I would hate 
to see that. It would be nice to at least plan this with the user-base and give 
them fair warning. And to this point, what is the active specific 
Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today?

On the other hand, I think that OSH has some improvements to make as well. 
Gating could use some help and the OpenStack-Infra team has been kindly helping 
out recently (a huge "thank you" to them). Docs…I think docs could always use 
some love. Please offer your experiences to the OSH team! We would love to hear 
your user input. Ultimately, if users/operators want to run something that even 
closely resembles production, then we need some decent production quality docs 
as opposed to leveraging the nascent gate scripts (Zuulv3 ansible+heat). 
Releases and release planning should be addressed, as users/vendors are going 
to want to be closer to OpenStack release dates (recent versions of OpenStack, 
Helm and Kubernetes). Clear and open roadmaps, with potential use of 
community-led planning tools. Open elections for PTL. Finally, the OSH team may 
still be be interested in diversifying it’s core-base. Matt M. would have to 
address this. I know that I was actively seeking cores when I was initially 
PTL, and truthfully…there’s nobody nicer or easier to work with than Matt. He’s 
an awesome PTL, and any project would be fortunate to have him. All these 
things could all be improved on, but it requires a diverse base with a lot of 
great ideas.

That said, I am in favor of consolidation…if it makes sense and if there's a 
strong argument for it. We just need to think what’s best for the OpenStack 
community as a whole, and put away the positions of the individual projects for 
a moment. To me, that makes things pretty clear, regardless of where the 
commits are going. And with the +1’s, I think we’re hearing you. Now we just 
have to plan it out and take action (on both sides).

Brandon



On April 2, 2018 at 11:14:01 AM, Martin André 
(m.an...@redhat.com) wrote:

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake)  wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com) wrote:
>
> On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) 
> wrote:
>> My viewpoin

[openstack-dev] Asking for ask.openstack.org

[Jimmy McArthur]

Hi everyone!

We have a very robust and vibrant community at ask.openstack.org 
.  There are literally dozens of posts a 
day. However, many of them don't receive knowledgeable answers.  I'm 
really worried about this becoming a vacuum where potential community 
members get frustrated and don't realize how to get more involved with 
the community.


I'm looking for thoughts/ideas/feelings about this tool as well as 
potential admin volunteers to help us manage the constant influx of 
technical and not-so-technical questions around OpenStack.


For those of you already contributing there, Thank You!  For those that 
are interested in becoming a moderator (instant AUC status!) or have 
some additional ideas around fostering this community, please respond.


Looking forward to your thoughts :)

Thanks!
Jimmy
irc: jamesmcarthur
__
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] The createBackup API

[melanie witt]

+openstack-operators

Operator feedback wanted: do you have users that pass rotation parameter 
'0' to the createBackup API in order to delete backups? Do you have 
users using the createBackup API in general?


On Fri, 30 Mar 2018 10:44:40 +0800, Alex Xu wrote:
There is spec proposal to fix a bug of createBackup API with 
microversion. (https://review.openstack.org/#/c/511825/)


When rotation parameter is '0', the createBackup API just do a snapshot, 
and then delete all the snapshots. That is meaningless behavier.


Agreed that '0' is meaningless in the context of 'createBackup' but as a 
side-effect, it allows users to purge old backups on-demand.


But there is thing hope to get wider suggestion. Since we said before 
all the nova API should be primitive, the API shouldn't be another wrap 
of another API.


So the createBackup sounds like just using the createImage API to create 
a snapshot, and upload the snapshot into the glance with index number in 
the image name, and rotation the image in after each snapshot.


So it should be something can be done by the client scrips to do same 
thing with createImage API.


We have two options here:
#1. fix the bug with a microversion. And we aren't sure any people 
really use '0' in the real life. But we use microversion to fix that 
bug, not sure it is worth.


I think this is the key point -- are there users who have been using '0' 
to the createBackup API in order to delete backups? If so, then I would 
be inclined to go ahead and fix the issue in our API with a microversion 
(disallow '0' for createBackup and then add a deleteBackups server action).


My rationale is that if people are actively using it, let's just fix it 
since it's nearly already there. The only problem with how it currently 
works is that '0' needlessly creates a backup that it will turn around 
and delete. The fix would be small and straightforward as it would just 
add schema validation for '0' on createBackup and then the new 
deleteBackups action would be an alias for deleting things (we already 
have the delete logic happening for '0').


#2. deprecate the backup API with a microversion, leave the bug along. 
Document that how the user can do that in the client script.


Looking for your comments.


If there isn't broader use of the API, then I'd be in favor of 
deprecating it.


-melanie




__
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][Tripleo] ipmitool issues HP machines

[Jim Rollenhagen]

On Wed, Apr 4, 2018 at 1:18 PM, Jim Rollenhagen 
wrote:

> On Wed, Apr 4, 2018 at 8:39 AM, Dan Prince  wrote:
>
>> Kind of a support question but figured I'd ask here in case there are
>> suggestions for workarounds for specific machines.
>>
>> Setting up a new rack of mixed machines this week and hit this issue
>> with HP machines using the ipmi power driver for Ironic. Curious if
>> anyone else has seen this before? The same commands work great with my
>> Dell boxes!
>>
>> -
>>
>> [root@localhost ~]# cat x.sh
>> set -x
>> # this is how Ironic sends its IPMI commands it fails
>> echo -n password > /tmp/tmprmdOOv
>> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
>> power status
>>
>> # this works great
>> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
>> status
>>
>> [root@localhost ~]# bash x.sh
>> + echo -n password
>> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
>> power status
>> Error: Unable to establish IPMI v2 / RMCP+ session
>> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
>> status
>> Chassis Power is on
>>
>
> Very strange. A tcpdump of both would probably be enlightening. :)
>
> Also curious what version of ipmitool this is, maybe you're hitting an old
> bug.
>

https://sourceforge.net/p/ipmitool/bugs/90/ would seem like a prime suspect
here.

// jim
__
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][Tripleo] ipmitool issues HP machines

[Jim Rollenhagen]

On Wed, Apr 4, 2018 at 8:39 AM, Dan Prince  wrote:

> Kind of a support question but figured I'd ask here in case there are
> suggestions for workarounds for specific machines.
>
> Setting up a new rack of mixed machines this week and hit this issue
> with HP machines using the ipmi power driver for Ironic. Curious if
> anyone else has seen this before? The same commands work great with my
> Dell boxes!
>
> -
>
> [root@localhost ~]# cat x.sh
> set -x
> # this is how Ironic sends its IPMI commands it fails
> echo -n password > /tmp/tmprmdOOv
> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
>
> # this works great
> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
>
> [root@localhost ~]# bash x.sh
> + echo -n password
> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
> Error: Unable to establish IPMI v2 / RMCP+ session
> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
> Chassis Power is on
>

Very strange. A tcpdump of both would probably be enlightening. :)

Also curious what version of ipmitool this is, maybe you're hitting an old
bug.

// jim
__
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] [docs] Documentation meeting minutes for 2018-04-04

[Petr Kovar]

===
#openstack-doc: docteam
===


Meeting started by pkovar at 16:02:31 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-04-04-16.02.log.html
.



Meeting summary
---

* dropdown menus on docs.o.o  (pkovar, 16:13:17)
  * design idea: re-implement dropdown menus as simple lists, as pointed
out by frank in https://review.openstack.org/#/c/556969/  (pkovar,
16:13:47)
  * to make the site more mobile friendly  (pkovar, 16:14:00)
  * LINK: https://ibb.co/coCMjx  (pkovar, 16:18:25)
  * ACTION: consider starting a thread / blueprint to discuss design
changes  (pkovar, 16:25:55)

* design ideas for docs.o.o  (pkovar, 16:30:22)
  * idea: make the landing pages with project lists more beautiful
(pkovar, 16:30:59)
  * like in https://www.openstack.org/software/project-navigator/ they
use all caps and bold for project names  (pkovar, 16:31:17)
  * idea: re-use mascot logos that would be stored in openstack-manuals
(pkovar, 16:34:10)

*   (pkovar, 16:38:37)

* vancouver summit  (pkovar, 16:38:46)
  * LINK:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=docs
(pkovar, 16:39:38)
  * summit schedule is up with two  docs talks / sessions planned
(pkovar, 16:39:58)
  * co-located with i18n  (pkovar, 16:40:11)
  * thanks to our presenters  (pkovar, 16:40:29)

* documentation builds and PTI  (pkovar, 16:41:12)
  * updating PTI wrt  https://review.openstack.org/#/c/545377/ and
https://review.openstack.org/#/c/509297/ might be needed  (pkovar,
16:47:33)
  * seeking help from infra team, will probably need to create a spec
(pkovar, 16:47:56)
  * thanks ianychoi for driving project docs translations and pdf builds
(pkovar, 16:52:25)
  * thanks stephenfin for keeping projects updated wrt
sphinxcontrib-apidoc  (pkovar, 16:55:19)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128817.html
(pkovar, 16:55:27)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128594.html
(pkovar, 16:55:34)



Meeting ended at 16:56:58 UTC.



People present (lines said)
---

* pkovar (75)
* ianychoi (30)
* openstack (3)
* openstackgerrit (2)
* mordred (2)



Generated by `MeetBot`_ 0.1.4


__
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] [openstack-helm][infra] Please consider using experimental pipeline for non-voting jobs

[Paul Belanger]

Greetings,

I've recently proposed https://review.openstack.org/558870 to the openstack-helm
project. This moves both centos / fedora jobs into the experimental pipeline.
The reason for this, the multinode jobs in helm each use 5 nodes per distro.
This this case, 10 shared between centos / fedora.

Given that this happens on every patchset propose to helm, and these jobs have
been non-voting for some time 3+ months, I think it is fair to now move them
into experimental to help conserve CI resources.

Once they have been properly fixed, I see no issue on moving them back to check
/ gate pipelines.

Thanks,
Paul

__
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] [tripleo] PTG session about All-In-One installer: recap & roadmap

[Tim Bell]

How about


  *   As an operator, I’d like to spin up the latest release to check if a 
problem is fixed before reporting a problem upstream

We use this approach frequently with packstack. Ideally (as today with 
packstack), we’d do this inside a VM on a running OpenStack cloud… inception… ☺

Tim

From: Emilien Macchi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 29 March 2018 at 23:35
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [tripleo] PTG session about All-In-One installer: 
recap & roadmap

Greeting folks,

During the last PTG we spent time discussing some ideas around an All-In-One 
installer, using 100% of the TripleO bits to deploy a single node OpenStack 
very similar with what we have today with the containerized undercloud and what 
we also have with other tools like Packstack or Devstack.

https://etherpad.openstack.org/p/tripleo-rocky-all-in-one

One of the problems that we're trying to solve here is to give a simple tool 
for developers so they can both easily and quickly deploy an OpenStack for 
their needs.

"As a developer, I need to deploy OpenStack in a VM on my laptop, quickly and 
without complexity, reproducing the same exact same tooling as TripleO is 
using."
"As a Neutron developer, I need to develop a feature in Neutron and test it 
with TripleO in my local env."
"As a TripleO dev, I need to implement a new service and test its deployment in 
my local env."
"As a developer, I need to reproduce a bug in TripleO CI that blocks the 
production chain, quickly and simply."

Probably more use cases, but to me that's what came into my mind now.

Dan kicked-off a doc patch a month ago: https://review.openstack.org/#/c/547038/
And I just went ahead and proposed a blueprint: 
https://blueprints.launchpad.net/tripleo/+spec/all-in-one
So hopefully we can start prototyping something during Rocky.

Before talking about the actual implementation, I would like to gather feedback 
from people interested by the use-cases. If you recognize yourself in these 
use-cases and you're not using TripleO today to test your things because it's 
too complex to deploy, we want to hear from you.
I want to see feedback (positive or negative) about this idea. We need to 
gather ideas, use cases, needs, before we go design a prototype in Rocky.

Thanks everyone who'll be involved,
--
Emilien Macchi
__
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] [bifrost][helm][OSA][barbican] Switching from fedora-26 to fedora-27

[Paul Belanger]

On Tue, Mar 13, 2018 at 10:54:26AM -0400, Paul Belanger wrote:
> On Mon, Mar 05, 2018 at 06:45:13PM -0500, Paul Belanger wrote:
> > Greetings,
> > 
> > A quick search of git shows your projects are using fedora-26 nodes for 
> > testing.
> > Please take a moment to look at gerrit[1] and help land patches.  We'd like 
> > to
> > remove fedora-26 nodes in the next week and to avoid broken jobs you'll 
> > need to
> > approve these patches.
> > 
> > If you jobs are failing under fedora-27, please take the time to fix any 
> > issue
> > or update said patches to make them non-voting.
> > 
> > We (openstack-infra) aim to only keep the latest fedora image online, which
> > changes aprox every 6 months.
> > 
> > Thanks for your help and understanding,
> > Paul
> > 
> > [1] https://review.openstack.org/#/q/topic:fedora-27+status:open
> > 
> Greetings,
> 
> This is a friendly reminder, about moving jobs to fedora-27. I'd like to 
> remove
> our fedora-26 images next week and if jobs haven't been migrated you may start
> to see NODE_FAILURE messages while running jobs.  Please take a moment to 
> merge
> the open changes or update them to be non-voting while you work on fixes.
> 
> Thanks again,
> Paul
> 
Hi,

It's been a month since we started asking projects to migrate to fedora-26.

I've proposed the patch to review fedora-26 nodes from nodepool[2], if your
project hasn't merge the patches above you will start to see NODE_FAILURE
results for your jobs. Please take the time to approve the changes above.

Because new fedora images come online every 6 months, we like to only keep one
of them online at any given time. Fedora is meant to be a fast moving distro to
pick up new versions of software out side of the Ubuntu LTS releases.

If you have any questions please reach out to us in #openstack-infra.

Thanks,
Paul

[2] https://review.openstack.org/558847/

__
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] [cinder][nova] about re-image the volume

[Matt Riedemann]

On 4/2/2018 6:59 AM, Gorka Eguileor wrote:

I can only see one benefit from implementing this feature in Cinder
versus doing it in Nova, and that is that we can preserve the volume's
UUID, but I don't think this is even relevant for this use case, so why
is it better to implement this in Cinder than in Nova?


With a new image, the volume_image_metadata in the volume would also be 
wrong, and I don't think nova should (or even can) update that 
information. So nova re-imaging the volume doesn't seem like a good fit 
to me given Cinder "owns" the volume along with any metadata about it.


If Cinder isn't agreeable to this new re-image API, then I think we're 
stuck with the original proposal of creating a new volume and swapping 
out the root disk, along with all of the problems that can arise from 
that (original volume type is gone, tenant goes over-quota, what do we 
do with the original volume (delete it?), etc).


--

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-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Remaining Rescue patches
- https://review.openstack.org/#/c/546919/ - Fix a bug for unrescuiing with 
whole disk image
- better fix: https://review.openstack.org/#/c/499050/  - Fix ``agent`` 
deploy interface to call ``boot.prepare_instance`` Updated
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.)
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/
- Bios interface support
- https://review.openstack.org/#/c/511162/
- https://review.openstack.org/#/c/528609/
- db api - https://review.openstack.org/#/c/511402/
- RefArch Guide
- https://review.openstack.org/#/c/556986/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
https://review.openstack.org/#/c/530838/ - OOB Raid spec for iLO5
irmc:
None - a few works are work in progress
oneview:
None at this time - No subteam at present.
xclarity:
None at this time - No subteam at present.

Subproject priorities
-
bifrost:

ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- Stats (diff between  12 Mar 2018 and 19 Mar 2018)
- Ironic: 225 bugs (+14) + 250 wishlist items (+2). 15 new (+10), 152 in 
progress, 1 critical, 36 high (+3) and 26 incomplete (+2)
- Inspector: 15 bugs (+1) + 26 wishlist items. 1 new (+1), 14 in progress, 0 
critical, 3 high and 4 incomplete
- Nova bugs with Ironic tag: 14 (-1). 1 new, 0 critical, 0 high
- critical:
- sushy: https://bugs.launchpad.net/sushy/+bug/1754514 (basic auth broken 
when SessionService is not present)
- note: the increase in bug count is probably because now the dashboard tracks 
virtualbmc and networking-baremetal
- the dashboard was abruptly deleted and needs a new home :(
- use it locally with `tox -erun` if you need to
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- status as of 2 April 2018:
- spec for deployment steps framework: 
https://review.openstack.org/#/c/549493/
- has 2x+2 and was approved, but dependent patch 
(https://review.openstack.org/#/c/557509/) needs to be approved first

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 2 April 2018:
- Spec has merged: https://review.openstack.org/#/c/496481/
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162
1x-1 (a comment about DB field size)
- Add bios_interface db field https://review.openstack.org/528609   
2x+2, WF+1
- BIOS Settings: Add DB API: https://review.openstack.org/511402
- BIOS Settings: Add RPC object https://review.openstack.org/511714
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- (april 2) hope to write spec this week

Reference architecture guide (dtantsur, jroll)
--
- story: https://storyboard.openstack.org/#!/story/2001745
- status as of 2 April 2018:
- Dublin PTG consensus was to start with small architectural building 
blocks.
- list of cases from the Denver PTG - see in the story
- First story up: https://review.openstack.org/#/c/556986/

Graphical console interface (mkrai, anup-d-na

Re: [openstack-dev] [keystone] Could keystone to keystone federation be deployed on Centos?

[John Dennis]

On 04/04/2018 02:52 AM, 何健乐 wrote:

Hi all，
Could keystone to keystone  federation be deployed on Centos. I have 
notice all the document was deployment on Ubuntu. If could, is there 
some documents that is about deploying k2k on centos.


Yes k2k should work on centos, there is nothing OS specific in the 
implementation. There is OpenStack documentation on setting up 
federation and k2k. If there are deficiencies in the doc it would be 
helpful to point them out so we can remedy that situation.


If you need more information on setting up mod_auth_mellon you might 
want to check out the Mellon User Guide I recently wrote and contributed 
to upstream Mellon (it's not part of the OpenStack doc as it's more of a 
SAML SP setup guide, not an OpenStack federation guide) 
https://github.com/UNINETT/mod_auth_mellon/blob/master/doc/user_guide/mellon_user_guide.adoc



--
John

__
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][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-03-28 18:53:03 -0400:
> 
> Because we had some communication issues and did a few steps out
> of order, when this patch lands projects that have approved
> bot-proposed requirements updates may find that their requirements
> and lower-constraints files no longer match, which may lead to job
> failures. It should be easy enough to fix the problems by making
> the values in the constraints files match the values in the
> requirements files (by editing either set of files, depending on
> what is appropriate). I apologize for any inconvenience this causes.

In part because of this, and in part because of some issues calculating
the initial set of lower-constraints, we have several projects where
their lower-constraints don't match the lower bounds in the requirements
file(s). Now that the check job has been updated with the new rules,
this is preventing us from landing the patches to add the
lower-constraints test job (so those rules are working!).

I've prepared a script to help fix up the lower-constraints.txt
based on values in requirements.txt and test-requirements.txt.
That's not everything, but it should make it easier to fix the rest.

See https://review.openstack.org/#/c/558610/ for the script. I'll work
on those pep8 errors later today so we can hopefully land it soon, but
in the mean time you'll need to check out that commit and follow the
instructions for setting up a virtualenv to run the script.

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

[openstack-dev] Openstack Deployment issue - Tripleo

[Waleed Musa]

Hi guys,


We have a problem with deploying Tripleo that the network configuration is not 
propagated to ComputeSriov nodes.

I've included my own network.yaml to be like that:

resource_registry:

  OS::TripleO::ComputeSriov::Net::SoftwareConfig: ./computesriov.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: ./controller.yaml

Now regarding the computesriov.yaml I edited the interface name only , but for 
the ./controller.yaml I keep it as the default one comes with single-vlan 
because it's a VM.

The controller propagated the network configuration and passed all the 
deployment steps but for the ComputeSriov is not propagated to the network 
configuration.

The deployment command is as following:
openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
-r ~/roles_data_new.yaml \
--libvirt-type kvm --control-flavor oooq_control --compute-flavor 
oooq_compute --ceph-storage-flavor oooq_ceph --block-storage-flavor 
oooq_blockstorage --swift-storage-flavor oooq_objectstorage --timeout 90  -e 
/home/stack/cloud-names.yaml  -e 
/usr/share/openstack-tripleo-heat-templates/environments/docker.yaml   -e 
/home/stack/containers-default-parameters.yaml  -e 
/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml 
-e 
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml
 -e /home/stack/network-environment.yaml  -e 
/usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml  
-e /home/stack/enable-tls.yaml -e 
/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-ip.yaml
 -e /home/stack/inject-trust-anchor.yaml   -e 
/usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml 
  --validation-warnings-fatal-e 
/usr/share/openstack-tripleo-heat-templates/environments/config-download-environment.yaml
 --config-download --verbose --ntp-server pool.ntp.org  \
  -e ~/nic_configs/network.yaml \
  -e 
/usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml
 \
  -e 
/usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-hw-offload.yaml
 \
${DEPLOY_ENV_YAML:+-e $DEPLOY_ENV_YAML} "$@" && status_code=0 || 
status_code=$?




Can you advice what is causing this issue, this just has happened after 
installing the latest queens.


Regards

Waleed Mousa

SW Engineer at Mellanox

__
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][Tripleo] ipmitool issues HP machines

[Dan Prince]

On Wed, Apr 4, 2018 at 9:00 AM, Noam Angel  wrote:
> Hi,
>
> First check you can ping the.
> Then open a browser and login.
> Make sure ipmi enabled.
> Make sure user has permissions for admin or other role with reboot
> capabilities.
> Check again

Hi, yeah. So like I mention in my initial email IPMI is working great
with a password like this:

ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status

It just fails when Ironic sends the similar command with a password
file. It appears that the password file is the issue. Tried it with
and without newlines even and no success.

Dan

>
> Get Outlook for Android
>
> 
> From: Dan Prince 
> Sent: Wednesday, April 4, 2018 3:39:00 PM
> To: List, OpenStack
> Subject: [openstack-dev] [Ironic][Tripleo] ipmitool issues HP machines
>
> Kind of a support question but figured I'd ask here in case there are
> suggestions for workarounds for specific machines.
>
> Setting up a new rack of mixed machines this week and hit this issue
> with HP machines using the ipmi power driver for Ironic. Curious if
> anyone else has seen this before? The same commands work great with my
> Dell boxes!
>
> -
>
> [root@localhost ~]# cat x.sh
> set -x
> # this is how Ironic sends its IPMI commands it fails
> echo -n password > /tmp/tmprmdOOv
> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
>
> # this works great
> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status
>
> [root@localhost ~]# bash x.sh
> + echo -n password
> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
> Error: Unable to establish IPMI v2 / RMCP+ session
> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
> Chassis Power is on
>
> Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev&data=02%7C01%7Cnoama%40mellanox.com%7Cb8324698c48e4fba8de408d59a293ae2%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636584424239254168&sdata=o2D26f1zFNmaM%2BOhQKD0SKaqqISRYdNzVotcR%2Fdqyhc%3D&reserved=0
>
> __
> 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] [Ironic][Tripleo] ipmitool issues HP machines

[Dan Prince]

On Wed, Apr 4, 2018 at 8:52 AM, Sanjay Upadhyay  wrote:
>
>
> On Wed, Apr 4, 2018 at 6:09 PM, Dan Prince  wrote:
>>
>> Kind of a support question but figured I'd ask here in case there are
>> suggestions for workarounds for specific machines.
>>
>> Setting up a new rack of mixed machines this week and hit this issue
>> with HP machines using the ipmi power driver for Ironic. Curious if
>> anyone else has seen this before? The same commands work great with my
>> Dell boxes!
>>
>
> Are you using ILO Drivers?
> https://docs.openstack.org/ironic/latest/admin/drivers/ilo.html
> /sanjay

No. I was using the ipmi driver. Trying to keep things simple.

Dan

>>
>> -
>>
>> [root@localhost ~]# cat x.sh
>> set -x
>> # this is how Ironic sends its IPMI commands it fails
>> echo -n password > /tmp/tmprmdOOv
>> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
>> power status
>>
>> # this works great
>> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
>> status
>>
>> [root@localhost ~]# bash x.sh
>> + echo -n password
>> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
>> power status
>> Error: Unable to establish IPMI v2 / RMCP+ session
>> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
>> status
>> Chassis Power is on
>>
>> Dan
>>
>> __
>> 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
>
>
>
>
> --
> Sanjay Upadhyay
> IRC #saneax
>
>
> __
> 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] [Ironic][Tripleo] ipmitool issues HP machines

[Noam Angel]

Hi,

First check you can ping the.
Then open a browser and login.
Make sure ipmi enabled.
Make sure user has permissions for admin or other role with reboot capabilities.
Check again

Get Outlook for Android


From: Dan Prince 
Sent: Wednesday, April 4, 2018 3:39:00 PM
To: List, OpenStack
Subject: [openstack-dev] [Ironic][Tripleo] ipmitool issues HP machines

Kind of a support question but figured I'd ask here in case there are
suggestions for workarounds for specific machines.

Setting up a new rack of mixed machines this week and hit this issue
with HP machines using the ipmi power driver for Ironic. Curious if
anyone else has seen this before? The same commands work great with my
Dell boxes!

-

[root@localhost ~]# cat x.sh
set -x
# this is how Ironic sends its IPMI commands it fails
echo -n password > /tmp/tmprmdOOv
ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
power status

# this works great
ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status

[root@localhost ~]# bash x.sh
+ echo -n password
+ ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
power status
Error: Unable to establish IPMI v2 / RMCP+ session
+ ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status
Chassis Power is on

Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev&data=02%7C01%7Cnoama%40mellanox.com%7Cb8324698c48e4fba8de408d59a293ae2%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636584424239254168&sdata=o2D26f1zFNmaM%2BOhQKD0SKaqqISRYdNzVotcR%2Fdqyhc%3D&reserved=0
__
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] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

[Andreas Scheuring]

No problem from s390x point of view. With Ubuntu we’re currently using* qemu: 2.10.1* libvirt: 3.6.0Thanks!
---Andreas Scheuring (andreas_s)

On 30. Mar 2018, at 16:26, Kashyap Chamarthy  wrote:The last version bump was in "Pike" release (commit: b980df0,11-Feb-2017), and we didn't do any bump during "Queens".  So it's timeto increment the versions (which will also makes us get rid of somebackward compatibility cruft), and pick future versions of libvirt andQEMU.  As it stands, during the "Pike" release the advertized NEXT_MIN versions   were set to: libvirt 1.3.1 and QEMU 2.5.0 -- but they weren't actually bumped for the "Queens" release.  So they will now be applied for the  "Rocky" release.  (Hmm, but note that libvirt 1.3.1 was released more  than 2 years ago[1].)  While at it, we should also discuss about what will be the NEXT_MIN    libvirt and QEMU versions for the "Solar" release.  To that end, I've  spent going through different distributions and updated the    DistroSupportMatrix Wiki[2].   Taking the DistroSupportMatrix into picture, for the sake of discussion,how about the following NEXT_MIN versions for "Solar" release: (a) libvirt: 3.2.0 (released on 23-Feb-2017)       This satisfies most distributions, but will affect Debian "Stretch",       as they only have 3.0.0 in the stable branch -- I've checked their    repositories[3][4].  Although the latest update for the stable    release "Stretch (9.4)" was released only on 10-March-2018, I don't    think they increment libvirt and QEMU versions in stable.  Is    there another way for "Stretch (9.4)" users to get the relevant    versions from elsewhere?   (b) QEMU: 2.9.0 (released on 20-Apr-2017)      This too satisfies most distributions but will affect Oracle Linux    -- which seem to ship QEMU 1.5.3 (released in August 2013) with    their "7", from the Wiki.  And will also affect Debian "Stretch" --    as it only has 2.8.0Can folks chime in here?[1] https://www.redhat.com/archives/libvirt-announce/2016-January/msg2.html[2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix[3] https://packages.qa.debian.org/libv/libvirt.html[4] https://packages.qa.debian.org/libv/libvirt.html-- /kashyap___OpenStack-operators mailing listopenstack-operat...@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
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][Tripleo] ipmitool issues HP machines

[Sanjay Upadhyay]

On Wed, Apr 4, 2018 at 6:09 PM, Dan Prince  wrote:

> Kind of a support question but figured I'd ask here in case there are
> suggestions for workarounds for specific machines.
>
> Setting up a new rack of mixed machines this week and hit this issue
> with HP machines using the ipmi power driver for Ironic. Curious if
> anyone else has seen this before? The same commands work great with my
> Dell boxes!
>
>
Are you using ILO Drivers?
https://docs.openstack.org/ironic/latest/admin/drivers/ilo.html
/sanjay

> -
>
> [root@localhost ~]# cat x.sh
> set -x
> # this is how Ironic sends its IPMI commands it fails
> echo -n password > /tmp/tmprmdOOv
> ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
>
> # this works great
> ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
>
> [root@localhost ~]# bash x.sh
> + echo -n password
> + ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
> power status
> Error: Unable to establish IPMI v2 / RMCP+ session
> + ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power
> status
> Chassis Power is on
>
> Dan
>
> __
> 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
>



-- 
Sanjay Upadhyay
IRC #saneax
__
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] [Ironic][Tripleo] ipmitool issues HP machines

[Dan Prince]

Kind of a support question but figured I'd ask here in case there are
suggestions for workarounds for specific machines.

Setting up a new rack of mixed machines this week and hit this issue
with HP machines using the ipmi power driver for Ironic. Curious if
anyone else has seen this before? The same commands work great with my
Dell boxes!

-

[root@localhost ~]# cat x.sh
set -x
# this is how Ironic sends its IPMI commands it fails
echo -n password > /tmp/tmprmdOOv
ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
power status

# this works great
ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status

[root@localhost ~]# bash x.sh
+ echo -n password
+ ipmitool -I lanplus -H 172.31.0.19 -U Adminstrator -f /tmp/tmprmdOOv
power status
Error: Unable to establish IPMI v2 / RMCP+ session
+ ipmitool -I lanplus -H 172.31.0.19 -U Administrator -P password power status
Chassis Power is on

Dan

__
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] RFC: Next minimum libvirt / QEMU versions for "Stein" release

[Kashyap Chamarthy]

On Sat, Mar 31, 2018 at 04:09:29PM +0200, Kashyap Chamarthy wrote:
> [Meta comment: corrected the email subject: "Solar" --> "Stein"]

Here's a change to get the discussion rolling:

https://review.openstack.org/#/c/558171/ -- [RFC] Pick next minimum
libvirt / QEMU versions for "Stein"

> On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote:

[...]

> > Taking the DistroSupportMatrix into picture, for the sake of discussion,
> > how about the following NEXT_MIN versions for "Solar" release:  
> >
> > 
> > (a) libvirt: 3.2.0 (released on 23-Feb-2017)   
> > 
> > This satisfies most distributions, but will affect Debian "Stretch",
> >
> > as they only have 3.0.0 in the stable branch -- I've checked their
> > repositories[3][4].  Although the latest update for the stable
> > release "Stretch (9.4)" was released only on 10-March-2018, I don't
> > think they increment libvirt and QEMU versions in stable.  Is
> > there another way for "Stretch (9.4)" users to get the relevant
> > versions from elsewhere?

I learn that there's Debian 'stretch-backports'[0], which might provide (but
doesn't yet) a newer stable version.

> > (b) QEMU: 2.9.0 (released on 20-Apr-2017)  
> > 
> > This too satisfies most distributions but will affect Oracle Linux
> > -- which seem to ship QEMU 1.5.3 (released in August 2013) with
> > their "7", from the Wiki.  And will also affect Debian "Stretch" --
> > as it only has 2.8.0
> > 
> > Can folks chime in here?

Answering my own questions about Debian --

From looking at the Debian Archive[1][2], these are the versions for
'Stretch' (the current stable release) and in the upcoming 'Buster'
release:

libvirt | 3.0.0-4+deb9u2 | stretch
libvirt | 4.1.0-2| buster

qemu| 1:2.8+dfsg-6+deb9u3| stretch
qemu| 1:2.11+dfsg-1  | buster

I also talked on #debian-backports IRC channel on OFTC network, where I
asked: 

"What I'm essentially looking for is: "How can 'stretch' users get
libvirt 3.2.0 and QEMU 2.9.0, even if via a different repository.
As they are proposed to be least common denominator versions across
distributions."

And two people said: Then the versions from 'Buster' could be backported
to 'stretch-backports'.  The process for that is to: "ask the maintainer
of those package and Cc to the backports mailing list."

Any takers?

[0] https://packages.debian.org/stretch-backports/
[1] https://qa.debian.org/madison.php?package=libvirt
[2] https://qa.debian.org/madison.php?package=qemu

-- 
/kashyap

__
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] [docs] Documentation meeting today

[Petr Kovar]

Hi all,

The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] [oslo.db] innodb OPTIMIZE TABLE ?

[Gorka Eguileor]

On 03/04, Jay Pipes wrote:
> On 04/03/2018 11:07 AM, Michael Bayer wrote:
> > The MySQL / MariaDB variants we use nowadays default to
> > innodb_file_per_table=ON and we also set this flag to ON in installer
> > tools like TripleO. The reason we like file per table is so that
> > we don't grow an enormous ibdata file that can't be shrunk without
> > rebuilding the database.  Instead, we have lots of little .ibd
> > datafiles for each table throughout each openstack database.
> >
> > But now we have the issue that these files also can benefit from
> > periodic optimization which can shrink them and also have a beneficial
> > effect on performance.   The OPTIMIZE TABLE statement achieves this,
> > but as would be expected it itself can lock tables for potentially a
> > long time.   Googling around reveals a lot of controversy, as various
> > users and publications suggest that OPTIMIZE is never needed and would
> > have only a negligible effect on performance.   However here we seek
> > to use OPTIMIZE so that we can reclaim disk space on tables that have
> > lots of DELETE activity, such as keystone "token" and ceilometer
> > "sample".
> >
> > Questions for the group:
> >
> > 1. is OPTIMIZE table worthwhile to be run for tables where the
> > datafile has grown much larger than the number of rows we have in the
> > table?
>
> Possibly, though it's questionable to use MySQL/InnoDB for storing transient
> data that is deleted often like ceilometer samples and keystone tokens. A
> much better solution is to use RDBMS partitioning so you can simply ALTER
> TABLE .. DROP PARTITION those partitions that are no longer relevant (and
> don't even bother DELETEing individual rows) or, in the case of Ceilometer
> samples, don't use a traditional RDBMS for timeseries data at all...
>
> But since that is unfortunately already the case, yes it is probably a good
> idea to OPTIMIZE TABLE on those tables.
>
> > 2. from people's production experience how safe is it to run OPTIMIZE,
> > e.g. how long is it locking tables, etc.
>
> Is it safe? Yes.
>
> Does it lock the entire table for the duration of the operation? No. It uses
> online DDL operations:
>
> https://dev.mysql.com/doc/refman/5.7/en/innodb-file-defragmenting.html
>
> Note that OPTIMIZE TABLE is mapped to ALTER TABLE tbl_name FORCE for InnoDB
> tables.
>
> > 3. is there a heuristic we can use to measure when we might run this
> > -.e.g my plan is we measure the size in bytes of each row in a table
> > and then compare that in some ratio to the size of the corresponding
> > .ibd file, if the .ibd file is N times larger than the logical data
> > size we run OPTIMIZE ?
>
> I don't believe so, no. Most things I see recommended is to simply run
> OPTIMIZE TABLE in a cron job on each table periodically.
>
> > 4. I'd like to propose this job of scanning table datafile sizes in
> > ratio to logical data sizes, then running OPTIMIZE, be a utility
> > script that is delivered via oslo.db, and would run for all innodb
> > tables within a target MySQL/ MariaDB server generically.  That is, I
> > really *dont* want this to be a script that Keystone, Nova, Ceilometer
> > etc. are all maintaining delivering themselves.   this should be done
> > as a generic pass on a whole database (noting, again, we are only
> > running it for very specific InnoDB tables that we observe have a poor
> > logical/physical size ratio).
>
> I don't believe this should be in oslo.db. This is strictly the purview of
> deployment tools and should stay there, IMHO.
>

Hi,

As far as I know most projects do "soft deletes" where we just flag the
rows as deleted and don't remove them from the DB, so it's only when we
use a management tool and run the "purge" command that we actually
remove these rows.

Since running the optimize without purging would be meaningless, I'm
wondering if we should trigger the OPTIMIZE also within the purging
code.  This way we could avoid innefective runs of the optimize command
when no purge has happened and even when we do the optimization we could
skip the ratio calculation altogether for tables where no rows have been
deleted (the ratio hasn't changed).

Ideally the ratio calculation and optimization code would be provided by
oslo.db to reduce code duplication between projects.

Cheers,
Gorka.


> > 5. for Galera this gets more tricky, as we might want to run OPTIMIZE
> > on individual nodes directly.  The script at [1] illustrates how to
> > run this on individual nodes one at a time.
> >
> > More succinctly, the Q is:
> >
> > a. OPTIMIZE, yes or no?
>
> Yes.
>
> > b. oslo.db script to run generically, yes or no?
>
> No. Just have Triple-O install galera_innoptimizer and run it in a cron job.
>
> Best,
> -jay
>
> > thanks for your thoughts!
> >
> >
> >
> > [1] https://github.com/deimosfr/galera_innoptimizer
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 

[openstack-dev] [cyborg]Weejky Team Meeting 2018.04.04

[Zhipeng Huang]

Hi Team,

As usual team meeting starting UTC1400 at #openstack-cyborg, initial agenda
as follows:

1. Status report from subteam
2. Critical spec patch review

Plz feel free to suggest more topics.

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [mistral] Bug Triage on Friday

[Dougal Matthews]

Hey all,

During the office hour on Friday, and maybe some time after it, I am going
to do some Mistral bug triage, planning and general tidying up on launchpad
and gerrit. If you are able and want to join, please do!

The slot is 8AM UTC - 9AM UTC. I'll be in #openstack-mistral

I hope to try and do these regularly at office hours, giving me time to do
some triage unless something else comes up to discuss.

For convenience I have created a calendar with the Mistral office hours, it
is just on my personal Google Calendar until I find a better place for it.
If you would find it useful, you can add it here:

iCal link:
https://calendar.google.com/calendar/ical/dougalmatthews.com_qmk1aiaao3b5ci30dp7t7e17es%40group.calendar.google.com/public/basic.ics
Google Link:
https://calendar.google.com/calendar?cid=ZG91Z2FsbWF0dGhld3MuY29tX3FtazFhaWFhbzNiNWNpMzBkcDd0N2UxN2VzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20
__
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