from:"Ben Nemec"

Re: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?

2018-11-30 Thread Ben Nemec




On 11/30/18 6:06 AM, Matthew Booth wrote:

I have a request to do $SUBJECT in relation to a V2V workflow. The use
case here is conversion of a VM/Physical which was previously powered
off. We want to move its data, but we don't want to be powering on
stuff which wasn't previously on.

This would involve an api change, and a hopefully very small change in
drivers to support it. Technically I don't see it as an issue.

However, is it a change we'd be willing to accept? Is there any good
reason not to do this? Are there any less esoteric workflows which
might use this feature?


I don't know if it qualifies as less esoteric, but I would use this for 
OVB[1]. When we create the "baremetal" VMs there's no need to actually 
power them on since the first thing we do with them is shut them down 
again. Their initial footprint is pretty small so it's not a huge deal, 
but it is another potential use case for this feature.


1: 
https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.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] [oslo] Next two meetings

2018-11-08 Thread Ben Nemec




On 11/7/18 2:19 PM, Ben Nemec wrote:

Hi,

Next week is summit and a lot of our contributors will be traveling 
there on Monday, so let's skip the meeting. The following week I will 
also be out, so if anyone wants to run the meeting please let me know. 
Otherwise we'll skip that one too and reconvene after Thanksgiving.


If you need your Oslo fix for next week, come see us in Berlin: 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22952/oslo-project-onboarding 



(I just noticed that is listed as a project onboarding - it's actually a 
project update. I'll look into getting that fixed)


This is fixed, so you can now find the session at 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22952/oslo-project-update


__
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] [oslo] Next two meetings

2018-11-07 Thread Ben Nemec


Hi,

Next week is summit and a lot of our contributors will be traveling 
there on Monday, so let's skip the meeting. The following week I will 
also be out, so if anyone wants to run the meeting please let me know. 
Otherwise we'll skip that one too and reconvene after Thanksgiving.


If you need your Oslo fix for next week, come see us in Berlin: 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22952/oslo-project-onboarding


(I just noticed that is listed as a project onboarding - it's actually a 
project update. I'll look into getting that fixed)


-Ben

__
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] [ceilometer][oslo.cache][oslo] ceilometer fails to publish to gnocchi

2018-11-06 Thread Ben Nemec




On 11/6/18 3:25 AM, Eyal B wrote:

Hi,
Because of this fix https://review.openstack.org/#/c/611369/ ceilometer 
which uses oslo.cache for redis fails to publish to gnocchi


see this log: 
http://logs.openstack.org/15/615415/1/check/vitrage-dsvm-datasources-py27/8d9e39e/logs/screen-ceilometer-anotification.txt.gz#_Nov_04_13_12_28_656863


Hmm, looks like the problem is that a memached-specific fix is also 
affecting the redis driver. We probably need to blacklist this release 
until we can come up with a fix: https://review.openstack.org/615935


I've opened a bug against oslo.cache as well: 
https://bugs.launchpad.net/oslo.cache/+bug/1801967


-Ben

__
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] [Openstack-sigs] Dropping lazy translation support

2018-11-05 Thread Ben Nemec




On 11/5/18 3:13 PM, Matt Riedemann wrote:

On 11/5/2018 1:36 PM, Doug Hellmann wrote:

I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.


Yeah maybe. And if so, I came across this in one of the blueprints:

https://etherpad.openstack.org/p/disable-lazy-translation

Which says that because of a critical bug, the lazy translation was 
disabled in Havana to be fixed in Icehouse but I don't think that ever 
happened before IBM developers dropped it upstream, which is further 
justification for nuking this code from the various projects.




It was disabled last-minute, but I'm pretty sure it was turned back on 
(hence why we're hitting issues today). I still see coercion code in 
oslo.log that was added to fix the problem[1] (I think). I could be 
wrong about that since this code has undergone significant changes over 
the years, but it looks to me like we're still forcing things to be 
unicode.[2]


1: https://review.openstack.org/#/c/49230/3/openstack/common/log.py
2: 
https://github.com/openstack/oslo.log/blob/a9ba6c544cbbd4bd804dcd5e38d72106ea0b8b8f/oslo_log/formatters.py#L414


__
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] Zuul Queue backlogs and resource usage

2018-11-01 Thread Ben Nemec

On 10/30/18 4:16 PM, Clark Boylan wrote:

On Tue, Oct 30, 2018, at 1:01 PM, Ben Nemec wrote:

On 10/30/18 1:25 PM, Clark Boylan wrote:

On Tue, Oct 30, 2018, at 10:42 AM, Alex Schultz wrote:

On Tue, Oct 30, 2018 at 11:36 AM Ben Nemec wrote:

Tagging with tripleo since my suggestion below is specific to that project.

On 10/30/18 11:03 AM, Clark Boylan wrote:

Hello everyone,

A little while back I sent email explaining how the gate queues work and how
fixing bugs helps us test and merge more code. All of this still is still true
and we should keep pushing to improve our testing to avoid gate resets.

Last week we migrated Zuul and Nodepool to a new Zookeeper cluster. In the
process of doing this we had to restart Zuul which brought in a new logging
feature that exposes node resource usage by jobs. Using this data I've been
able to generate some report information on where our node demand is going.
This change [0] produces this report [1].

As with optimizing software we want to identify which changes will have the
biggest impact and to be able to measure whether or not changes have had an
impact once we have made them. Hopefully this information is a start at doing
that. Currently we can only look back to the point Zuul was restarted, but we
have a thirty day log rotation for this service and should be able to look at a
month's worth of data going forward.

Looking at the data you might notice that Tripleo is using many more node
resources than our other projects. They are aware of this and have a plan [2]
to reduce their resource consumption. We'll likely be using this report
generator to check progress of this plan over time.

I know at one point we had discussed reducing the concurrency of the
tripleo gate to help with this. Since tripleo is still using >50% of the
resources it seems like maybe we should revisit that, at least for the
short-term until the more major changes can be made? Looking through the
merge history for tripleo projects I don't see a lot of cases (any, in
fact) where more than a dozen patches made it through anyway*, so I
suspect it wouldn't have a significant impact on gate throughput, but it
would free up quite a few nodes for other uses.

It's the failures in gate and resets. At this point I think it would
be a good idea to turn down the concurrency of the tripleo queue in
the gate if possible. As of late it's been timeouts but we've been
unable to track down why it's timing out specifically. I personally
have a feeling it's the container download times since we do not have
a local registry available and are only able to leverage the mirrors
for some levels of caching. Unfortunately we don't get the best
information about this out of docker (or the mirrors) and it's really
hard to determine what exactly makes things run a bit slower.

We actually tried this not too long ago
https://git.openstack.org/cgit/openstack-infra/project-config/commit/?id=22d98f7aab0fb23849f715a8796384cffa84600b
but decided to revert it because it didn't decrease the check queue backlog
significantly. We were still running at several hours behind most of the time.

I'm surprised to hear that. Counting the tripleo jobs in the gate at
positions 11-20 right now, I see around 84 nodes tied up in long-running
jobs and another 32 for shorter unit test jobs. The latter probably
don't have much impact, but the former is a non-trivial amount. It may
not erase the entire 2300+ job queue that we have right now, but it
seems like it should help.

If we want to set up better monitoring and measuring and try it again we can do
that. But we probably want to measure queue sizes with and without the change
like that to better understand if it helps.

This seems like good information to start capturing, otherwise we are
kind of just guessing. Is there something in infra already that we could
use or would it need to be new tooling?

Digging around in graphite we currently track mean in pipelines. This is
probably a reasonable metric to use for this specific case.

Looking at the check queue [3] shows the mean time enqueued in check during the rough
period window floor was 10 and [4] shows it since then. The 26th and 27th are bigger
peaks than previously seen (possibly due to losing inap temporarily) but otherwise a
queue backlog of ~200 minutes was "normal" in both time periods.

[3]
http://graphite.openstack.org/render/?from=20181015=20181019=scale(stats.timers.zuul.tenant.openstack.pipeline.check.resident_time.mean,%200.166)
[4]
http://graphite.openstack.org/render/?from=20181019=20181030=scale(stats.timers.zuul.tenant.openstack.pipeline.check.resident_time.mean,%200.166)

You should be able to change check to eg gate or other queue names and poke
around more if you like. Note the scale factor scales from milliseconds to
minutes.

Clark

Cool, thanks. Seems like things have been better for the past couple of
days, but I'll keep this in m

Re: [openstack-dev] [tripleo] reducing our upstream CI footprint

2018-10-31 Thread Ben Nemec




On 10/31/18 4:59 PM, Harald Jensås wrote:

On Wed, 2018-10-31 at 11:39 -0600, Wesley Hayutin wrote:



On Wed, Oct 31, 2018 at 11:21 AM Alex Schultz 
wrote:

Hey everyone,

Based on previous emails around this[0][1], I have proposed a
possible
reducing in our usage by switching the scenario001--011 jobs to
non-voting and removing them from the gate[2]. This will reduce the
likelihood of causing gate resets and hopefully allow us to land
corrective patches sooner.  In terms of risks, there is a risk that
we
might introduce breaking changes in the scenarios because they are
officially non-voting, and we will still be gating promotions on
these
scenarios.  This means that if they are broken, they will need the
same attention and care to fix them so we should be vigilant when
the
jobs are failing.

The hope is that we can switch these scenarios out with voting
standalone versions in the next few weeks, but until that I think
we
should proceed by removing them from the gate.  I know this is less
than ideal but as most failures with these jobs in the gate are
either
timeouts or unrelated to the changes (or gate queue), they are more
of
hindrance than a help at this point.

Thanks,
-Alex


I think I also have to agree.
Having to deploy with containers, update containers and run with two
nodes is no longer a very viable option upstream.  It's not
impossible but it should be the exception and not the rule for all
our jobs.


afaict in my local environment, the container prep stuff takes ages
when adding the playbooks to update them with yum. We will still have
to do this for every standalone job right?



Also, I enabled profiling for ansible tasks on the undercloud and
noticed that the UndercloudPostDeploy was high on the list, actually
the longest running task when re-running the undercloud install ...

Moving from shell script using openstack cli to python reduced the time
for this task dramatically in my environment, see:
https://review.openstack.org/614540. 6 and half minutes reduced to 40
seconds ...


Everything old is new again: 
https://github.com/openstack/instack-undercloud/commit/0eb1b59926c7dc46e321c56db29af95b3d755f34#diff-5602f1b710e86ca1eb7334cb0632f9ee


:-)




How much time would we save in the gates if we converted some of the
shell scripting to python, or if we want to stay in shell script we can
use the interactive shell or use the client-as-a-service[2]?

Interactive shell:
time openstack <<-EOC
server list
workflow list
workflow execution list
EOC

real0m2.852s
time (openstack server list; \
   openstack workflow list; \
   openstack workflow execution list)

real0m7.119s

The difference is significant.

We could cache a token[1], and specify the end-point on each command,
but doing so is still far from as effective as using the interactive.


There is an old thread[2] on the mailing list, which contain a
server/client solution. If we run this service in CI nodes and drop in
the replacement openstack command in /usr/local/bin/openstack we would
use ~1/5 of the time for each command.

(undercloud) [stack@leafs ~]$ time (/usr/bin/openstack network list -f
value -c ID; /usr/bin/openstack network segment list -f value -c ID;
/usr/bin/openstack subnet list -f value -c ID)


real0m6.443s
user0m2.171s
sys 0m0.366s

(undercloud) [stack@leafs ~]$ time (/usr/local/bin/openstack network
list -f value -c ID; /usr/local/bin/openstack network segment list -f
value -c ID; /usr/local/bin/openstack subnet list -f value -c ID)

real0m1.698s
user0m0.042s
sys 0m0.018s



I relize this is a kind of hacky approch, but it does seem to work and
it should be fairly quick to get in there. (With the Undercloud post
script I see 6 minutes returned, what can we get in CI, 10-15 minutes?
Then we could look at moving these scripts to python or use ansible
openstack modules which hopefully does'nt share the same issues with
loading as the python clients?


I'm personally a fan of using Python as then it is unit-testable, but 
I'm not sure how that works with the tht-based code so maybe it's not a 
factor.






[1] https://wiki.openstack.org/wiki/OpenStackClient/Authentication
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/092546.html



Thanks Alex

  

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html
[2]
https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged
)

___
___
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
bscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
WES HAYUTIN
ASSOCIATE MANAGER
Red Hat

whayu...@redhat.comT: +19194232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

Re: [openstack-dev] [tripleo] Zuul Queue backlogs and resource usage

2018-10-30 Thread Ben Nemec

On 10/30/18 1:25 PM, Clark Boylan wrote:

On Tue, Oct 30, 2018, at 10:42 AM, Alex Schultz wrote:

On Tue, Oct 30, 2018 at 11:36 AM Ben Nemec wrote:

Tagging with tripleo since my suggestion below is specific to that project.

On 10/30/18 11:03 AM, Clark Boylan wrote:

Hello everyone,

This seems like good information to start capturing, otherwise we are
kind of just guessing. Is there something in infra already that we could
use or would it need to be new tooling?

As for container image download times can we quantify that via docker logs?
Basically sum up the amount of time spent by a job downloading images so that we
can see what the impact is but also measure if changes improve that? As for other
ideas improving things seems like many of the images that tripleo use are quite
large. I recall seeing a > 600MB image just for rsyslog. Wouldn't it be
advantageous for both the gate and tripleo in the real world to trim the size of
those images (which should improve download times). In any case quantifying the
size of the downloads and trimming those if possible is likely also worthwhile.

Clark

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

Re: [openstack-dev] [tripleo] Zuul Queue backlogs and resource usage

2018-10-30 Thread Ben Nemec


Tagging with tripleo since my suggestion below is specific to that project.

On 10/30/18 11:03 AM, Clark Boylan wrote:

Hello everyone,

A little while back I sent email explaining how the gate queues work and how 
fixing bugs helps us test and merge more code. All of this still is still true 
and we should keep pushing to improve our testing to avoid gate resets.

Last week we migrated Zuul and Nodepool to a new Zookeeper cluster. In the 
process of doing this we had to restart Zuul which brought in a new logging 
feature that exposes node resource usage by jobs. Using this data I've been 
able to generate some report information on where our node demand is going. 
This change [0] produces this report [1].

As with optimizing software we want to identify which changes will have the 
biggest impact and to be able to measure whether or not changes have had an 
impact once we have made them. Hopefully this information is a start at doing 
that. Currently we can only look back to the point Zuul was restarted, but we 
have a thirty day log rotation for this service and should be able to look at a 
month's worth of data going forward.

Looking at the data you might notice that Tripleo is using many more node 
resources than our other projects. They are aware of this and have a plan [2] 
to reduce their resource consumption. We'll likely be using this report 
generator to check progress of this plan over time.


I know at one point we had discussed reducing the concurrency of the 
tripleo gate to help with this. Since tripleo is still using >50% of the 
resources it seems like maybe we should revisit that, at least for the 
short-term until the more major changes can be made? Looking through the 
merge history for tripleo projects I don't see a lot of cases (any, in 
fact) where more than a dozen patches made it through anyway*, so I 
suspect it wouldn't have a significant impact on gate throughput, but it 
would free up quite a few nodes for other uses.


*: I have no actual stats to back that up, I'm just looking through the 
IRC backlog for merge bot messages. If such stats do exist somewhere we 
should look at them instead. :-)




Also related to the long queue backlogs is this proposal [3] to change how Zuul 
prioritizes resource allocations to try to be more fair.

[0] https://review.openstack.org/#/c/613674/
[1] http://paste.openstack.org/show/733644/
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html
[3] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-October/000575.html

If you find any of this interesting and would like to help feel free to reach 
out to myself or the infra team.

Thank you,
Clark

__
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] [oslo] Project Update Etherpad

2018-10-30 Thread Ben Nemec

Good news! The Foundation found space for us to do a project update 
session, so now we need to figure out what to talk about. I've started 
an etherpad at 
https://etherpad.openstack.org/p/oslo-project-update-stein to list the 
possible topics. Please add or expand on the ones I've pre-populated if 
there's something you want to have covered. The current list is a five 
minute off-the-top-of-my-head thing, so don't assume it's complete. :-)


-Ben

__
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] Proposal for a process to keep up with Python releases

2018-10-26 Thread Ben Nemec

On 10/25/18 3:43 PM, Zane Bitter wrote:

On 25/10/18 1:38 PM, William M Edmonds wrote:

Zane Bitter  wrote on 10/22/2018 03:12:46 PM:
 > On 22/10/18 10:33 AM, Thomas Goirand wrote:
 > > On 10/19/18 5:17 PM, Zane Bitter wrote:

 > >> Integration Tests
 > >> -
 > >>
 > >> Integration tests do test, amongst other things, integration with
 > >> non-openstack-supplied things in the distro, so it's important 
that we
 > >> test on the actual distros we have identified as popular.[2] 
It's also
 > >> important that every project be testing on the same distro at 
the end of

 > >> a release, so we can be sure they all work together for users.
 > >
 > > I find very disturbing to see the project only leaning toward 
these only

 > > 2 distributions. Why not SuSE & Debian?
 >
 > The bottom line is it's because targeting those two catches 88% of our
 > users. (For once I did not make this statistic up.)
 >
 > Also note that in practice I believe almost everything is actually
 > tested on Ubuntu LTS, and only TripleO is testing on CentOS. It's
 > difficult to imagine how to slot another distro into the mix without
 > doubling up on jobs.

I think you meant 78%, assuming you were looking at the latest User 
Survey results [1], page 55. Still a hefty number.

I never know how to read those weird 3-way bar charts they have in the 
user survey, but that actually adds up to 91% by the looks of it (I 
believe you forgot to count RHEL). The numbers were actually slightly 
lower in the full-year data for 2017 that I used (from 
https://www.openstack.org/analytics - I can't give you a direct link 
because Javascript ).

It is important to note that the User Survey lumps all versions of a 
given OS together, whereas the TC reference [2] only considers the 
latest LTS/stable version. If the User Survey split out latests 
LTS/stable versions vs. others (e.g. Ubuntu 16.04 LTS), I expect we'd 
see Ubuntu 18.04 LTS + Centos 7 adding up to much less than 78%.

This is true, although we don't know by how much. (FWIW I can almost 
guarantee that virtually all of the CentOS/RHEL users are on 7, but I'm 
sure the same is not the case for Ubuntu 16.04.)

In this context I don't think the version matters though. The original 
question was why we are focusing our test efforts on Ubuntu and CentOS, 
and the answer is that ~90% of our users are on those platforms. The 
specific version they're on right now doesn't really matter - even if 
they're on an older one, chances are eventually they'll move to a newer 
release of that same OS.

[1] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[2] 
https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions 

__ 

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 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] [goals][upgrade-checkers] Week R-25 Update

2018-10-24 Thread Ben Nemec




On 10/23/18 9:55 PM, Adrian Turjak wrote:


On 24/10/18 2:09 AM, Ben Nemec wrote:



On 10/22/18 5:40 PM, Matt Riedemann wrote:

On 10/22/2018 4:35 PM, Adrian Turjak wrote:

The one other open question I have is about the Adjutant change [2]. I
know Adjutant is very new and I'm not sure what upgrades look like for
that project, so I don't really know how valuable adding the upgrade
check framework is to that project. Is it like Horizon where it's
mostly stateless and fed off plugins? Because we don't have an upgrade
check CLI for Horizon for that reason.

[1]
https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged)

[2]https://review.openstack.org/#/c/611812/


Adjutant's codebase is also going to be a bit unstable for the next few
cycles while we refactor some internals (we're not marking it 1.0 yet).
Once the current set of ugly refactors planned for late Stein are
done I
may look at building some upgrade checking, once we also work out what
out upgrade checking should look like. Probably mostly checking config
changes, database migration states, and plugin compatibility.

Adjutant already has a concept of startup checks at least, which while
not anywhere near as extensive as they should be, mostly amount to
making sure your config file looks 'mostly' sane regarding plugins
before starting up the service, and we do intend to expand on that,
plus
we can reuse a large chunk of that for upgrade checking.


OK it seems there is not really any point in trying to satisfy the
upgrade checkers goal for Adjutant in Stein then. Should we just
abandon the change?



Can't we just add a noop command like we are for the services that
don't currently need upgrade checks?



I mostly was responding to this in the review itself rather than on here.

We are probably going to have reason for an upgrade check in Adjutant,
my main gripe is, Adjutant is Django based and there isn't a good point
in adding a separate cli when we already expose 'adjutant-api' as a
proxy to manage.py and as such we should just register the upgrade check
as a custom Django admin command.

More so because all of the logic needed to actually run the check in
future will require Django settings to be configured. We don't actually
use any oslo libraries yet so the current code for the check doesn't
actually make sense in context.

I'm fine with a noop check, but we have to make it fit.


What I'm trying to avoid is creating any snowflake upgrade processes. It 
may not make sense for Adjutant to do this in isolation, but Adjutant 
doesn't exist in isolation. Also, if I understand correctly, you're 
proposing to add startup checks instead of upgrade checks. The downside 
I see there is that you have to have already restarted the service 
before the check runs so if there's a problem now you have downtime. 
With a standalone upgrade check you can run the check while the old 
version of the code is still running. If problems are found you fix them 
before doing the restart.


That said, I don't particularly care how the upgrade check is 
implemented. If 'adjutant-status upgrade check' just calls 'adjutant-api 
--check' or something else that returns 0 or non-0 appropriately that 
satisfies me. I don't want to cross the line into foolish consistency 
either. :-)


-Ben

__
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] [goals][upgrade-checkers] Week R-25 Update

2018-10-23 Thread Ben Nemec




On 10/23/18 9:58 AM, Matt Riedemann wrote:

On 10/23/2018 8:09 AM, Ben Nemec wrote:
Can't we just add a noop command like we are for the services that 
don't currently need upgrade checks?


We could, but I was also hoping that for most projects we will actually 
be able to replace the noop / placeholder check with *something* useful 
in Stein.




Yeah, but part of the reason for placeholders was consistency across all 
of the services. I guess if there are never going to be upgrade checks 
in adjutant then I could see skipping it, but otherwise I would prefer 
to at least get the framework in place.


__
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] [goals][upgrade-checkers] Week R-25 Update

2018-10-23 Thread Ben Nemec




On 10/22/18 5:40 PM, Matt Riedemann wrote:

On 10/22/2018 4:35 PM, Adrian Turjak wrote:

The one other open question I have is about the Adjutant change [2]. I
know Adjutant is very new and I'm not sure what upgrades look like for
that project, so I don't really know how valuable adding the upgrade
check framework is to that project. Is it like Horizon where it's
mostly stateless and fed off plugins? Because we don't have an upgrade
check CLI for Horizon for that reason.

[1]
https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged) 


[2]https://review.openstack.org/#/c/611812/


Adjutant's codebase is also going to be a bit unstable for the next few
cycles while we refactor some internals (we're not marking it 1.0 yet).
Once the current set of ugly refactors planned for late Stein are done I
may look at building some upgrade checking, once we also work out what
out upgrade checking should look like. Probably mostly checking config
changes, database migration states, and plugin compatibility.

Adjutant already has a concept of startup checks at least, which while
not anywhere near as extensive as they should be, mostly amount to
making sure your config file looks 'mostly' sane regarding plugins
before starting up the service, and we do intend to expand on that, plus
we can reuse a large chunk of that for upgrade checking.


OK it seems there is not really any point in trying to satisfy the 
upgrade checkers goal for Adjutant in Stein then. Should we just abandon 
the change?




Can't we just add a noop command like we are for the services that don't 
currently need upgrade checks?


__
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] [tc] [api] Paste Maintenance

2018-10-22 Thread Ben Nemec

On 10/22/18 10:32 AM, Morgan Fainberg wrote:
I can spin up the code and make it available. There is an example 
(highly-flask specific right now, but would be easy to make it generic) 
from keystone [0] has been implemented. Where should this code live? A 
new library? oslo.?  The aforementioned example would need 
"external middleware via config" loading capabilities, but that isn't 
hard to do, just adding an oslo.cfg opt and referencing it.

This seems pretty closely related to oslo.middleware, so maybe we could 
put it there? Everything in there now appears to be actual middleware, 
but a module to allow the use of that middleware isn't too much of a 
stretch.

[0] 
https://github.com/openstack/keystone/blob/master/keystone/server/flask/core.py#L93

Cheers,
--Morgan

On Mon, Oct 22, 2018 at 8:12 AM Sean McGinnis > wrote:

On Mon, Oct 22, 2018 at 07:49:35AM -0700, Morgan Fainberg wrote:
 > I should be able to do a write up for Keystone's removal of paste
*and*
 > move to flask soon.
 >
 > I can easily extract the bit of code I wrote to load our external
 > middleware (and add an external loader) for the transition away
from paste.
 >
 > I also think paste is terrible, and would be willing to help
folks move off
 > of it rather than maintain it.
 >
 > --Morgan
 >

Do I detect a volunteer to champion a cycle goal? :)

__
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 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] [oslo] Next meeting cancelled

2018-10-19 Thread Ben Nemec


Hi,

Sorry for the late notice, but I just found out I'm going to be 
travelling next week, which will mean I can't run the meeting. Since 
Doug is also out and it's really late to find someone else to run it, 
we're just going to skip it. We'll resume as normal the following week.


Also note that this means I may have somewhat limited availability on 
IRC next week. I'll try to keep up with emails, but I can't make any 
guarantees. If you need immediate assistance with Oslo, try ChangBo 
(gcb), Ken (kgiusti), or Stephen (stephenfin).


Thanks.

-Ben

__
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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

2018-10-18 Thread Ben Nemec




On 10/18/18 9:59 AM, Ken Giusti wrote:

Hi Renat,

The biggest issue with the blocking executor (IMHO) is that it blocks 
the protocol I/O while  RPC processing is in progress.  This increases 
the likelihood that protocol processing will not get done in a timely 
manner and things start to fail in weird ways.  These failures are 
timing related and are typically hard to reproduce or root-cause.   This 
isn't something we can fix as blocking is the nature of the executor.


If we are to leave it in we'd really want to discourage its use.


Since it appears the actual executor code lives in futurist, would it be 
possible to remove the entrypoint for blocking from oslo.messaging and 
have mistral just pull it in with their setup.cfg? Seems like they 
should be able to add something like:


oslo.messaging.executors =
  blocking = futurist:SynchronousExecutor

to their setup.cfg to keep it available to them even if we drop it from 
oslo.messaging itself. That seems like a good way to strongly discourage 
use of it while still making it available to projects that are really 
sure they want it.




However I'm ok with leaving it available if the policy for using 
blocking is 'use at your own risk', meaning that bug reports may have to 
be marked 'won't fix' if we have reason to believe that blocking is at 
fault.  That implies removing 'blocking' as the default executor value 
in the API and having applications explicitly choose it.  And we keep 
the deprecation warning.


We could perhaps implement time duration checks around the executor 
callout and log a warning if the executor blocked for an extended amount 
of time (extended=TBD).


Other opinions so we can come to a consensus?


On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov > wrote:


Hi Oslo Team,

Can we retain “blocking” executor for now in Oslo Messaging?


Some background..

For a while we had to use Oslo Messaging with “blocking” executor in
Mistral because of incompatibility of MySQL driver with green
threads when choosing “eventlet” executor. Under certain conditions
we would get deadlocks between green threads. Some time ago we
switched to using PyMysql driver which is eventlet friendly and did
a number of tests that showed that we could safely switch to
“eventlet” executor (with that driver) so we introduced a new option
in Mistral where we could choose an executor in Oslo Messaging. The
corresponding bug is [1].

The issue is that we recently found that not everything actually
works as expected when using combination PyMysql + “eventlet”
executor. We also tried “threading” executor and the system *seems*
to work with it but surprisingly performance is much worse.

Given all of that we’d like to ask Oslo Team not to remove
“blocking” executor for now completely, if that’s possible. We have
a strong motivation to switch to “eventlet” for other reasons
(parallelism => better performance etc.) but seems like we need some
time to make it smoothly.


[1] https://bugs.launchpad.net/mistral/+bug/1696469


Thanks

Renat Akhmerov
@Nokia
__
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



--
Ken Giusti  (kgiu...@gmail.com )

__
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-operators] [goals][upgrade-checkers] Week R-26 Update

2018-10-15 Thread Ben Nemec

On 10/15/18 3:27 AM, Jean-Philippe Evrard wrote:

On Fri, 2018-10-12 at 17:05 -0500, Matt Riedemann wrote:

The big update this week is version 0.1.0 of oslo.upgradecheck was
released. The documentation along with usage examples can be found
here
[1]. A big thanks to Ben Nemec for getting that done since a few
projects were waiting for it.

In other updates, some changes were proposed in other projects [2].

And finally, Lance Bragstad and I had a discussion this week [3]
about
the validity of upgrade checks looking for deleted configuration
options. The main scenario I'm thinking about here is FFU where
someone
is going from Mitaka to Pike. Let's say a config option was
deprecated
in Newton and then removed in Ocata. As the operator is rolling
through
from Mitaka to Pike, they might have missed the deprecation signal
in
Newton and removal in Ocata. Does that mean we should have upgrade
checks that look at the configuration for deleted options, or
options
where the deprecated alias is removed? My thought is that if things
will
not work once they get to the target release and restart the service
code, which would definitely impact the upgrade, then checking for
those
scenarios is probably OK. If on the other hand the removed options
were
just tied to functionality that was removed and are otherwise not
causing any harm then I don't think we need a check for that. It was
noted that oslo.config has a new validation tool [4] so that would
take
care of some of this same work if run during upgrades. So I think
whether or not an upgrade check should be looking for config option
removal ultimately depends on the severity of what happens if the
manual
intervention to handle that removed option is not performed. That's
pretty broad, but these upgrade checks aren't really set in stone
for
what is applied to them. I'd like to get input from others on this,
especially operators and if they would find these types of checks
useful.

[1] https://docs.openstack.org/oslo.upgradecheck/latest/
[2] https://storyboard.openstack.org/#!/story/2003657
[3]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
[4]
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html

Hey,

Nice topic, thanks Matt!

TL:DR; I would rather fail explicitly for all removals, warning on all
deprecations. My concern is, by being more surgical, we'd have to
decide what's "not causing any harm" (and I think deployers/users are
best to determine what's not causing them any harm).
Also, it's probably more work to classify based on "severity".
The quick win here (for upgrade-checks) is not about being smart, but
being an exhaustive, standardized across projects, and _always used_
source of truth for upgrades, which is complemented by release notes.

Long answer:

At some point in the past, I was working full time on upgrades using
OpenStack-Ansible.

Our process was the following:
1) Read all the project's releases notes to find upgrade documentation
2) With said release notes, Adapt our deploy tools to handle the
upgrade, or/and write ourselves extra documentation+release notes for
our deployers.
3) Try the upgrade manually, fail because some release note was missing
x or y. Find root cause and retry from step 2 until success.

Here is where I see upgrade checkers improving things:
1) No need for deployment projects to parse all release notes for
configuration changes, as tooling to upgrade check would be directly
outputting things that need to change for scenario x or y that is
included in the deployment project. No need to iterate either.

2) Test real deployer use cases. The deployers using openstack-ansible
have ultimate flexibility without our code changes. Which means they
may have different code paths than our gating. Including these checks
in all upgrades, always requiring them to pass, and making them
explicit about the changes is tremendously helpful for deployers:
- If config deprecations are handled as warnings as part of the same
process, we will output said warnings to generate a list of action
items for the deployers. We would use only one tool as source of truth
for giving the action items (and still continue the upgrade);
- If config removals are handled as errors, the upgrade will fail,
which is IMO normal, as the deployer would not have respected its
action items.

Note that deprecated config opts should already be generating warnings
in the logs. It is also possible now to use fatal-deprecations with
config opts:
https://github.com/openstack/oslo.config/commit/5f8b0e0185dafeb68cf04590948b9c9f7d727051

I'm not sure that's exactly what you're talking about, but those might
be useful to get us at least part of the way there.

In OSA, we could probably implement a deployer override (variable). It
would allow the deployers an explicit bypass of an upgrade failure. "I
know I am doing this!". It would be useful for

[openstack-dev] [oslo] Config Validator

2018-10-11 Thread Ben Nemec


Hi,

We recently merged a new feature to oslo.config and it was suggested 
that I publicize it since it addresses a longstanding pain point. It's a 
validator tool[1] that will warn or error on any entries in a config 
file that aren't defined in the service or are deprecated.


Previously this was difficult to do accurately because config opts are 
registered at runtime and you don't know for sure when all of the opts 
are present. This tool makes use of the less recently added 
machine-readable sample config[2], which should contain all of the 
available opts for a service. If any are missing, that is a bug and 
should be addressed in the service anyway. This is the same data used to 
generate sample config files and those should have all of the possible 
opts listed.


The one limitation I'm aware of at this point is that dynamic groups 
aren't handled, so options in a dynamic group will be reported as 
missing even though they are recognized by the service. This should be 
solvable, but for the moment it is a limitation to keep in mind.


So if this is something you were interested in, please try it out and 
let us know how it works for you. The latest release of oslo.config on 
pypi should have this tool, and since it doesn't necessarily have to be 
run on the live system you can install the bleeding edge oslo.config 
somewhere else and just generate the machine readable sample config from 
the production system. That functionality has been in oslo.config for a 
few cycles now so it's more likely to be available.


Thanks.

-Ben

1: https://docs.openstack.org/oslo.config/latest/cli/validator.html
2: 
https://docs.openstack.org/oslo.config/latest/cli/generator.html#machine-readable-configs


__
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][ci] Having more that one queue for gate pipeline at tripleo

2018-10-11 Thread Ben Nemec




On 10/11/18 8:53 AM, Felix Enrique Llorente Pastora wrote:
So for example, I don't see why changes at tripleo-quickstart can be 
reset if tripleo-ui fails, this is the kind of thing that maybe can be 
optimize.


Because if two incompatible changes are proposed to tripleo-quickstart 
and tripleo-ui and both end up in parallel gate queues at the same time, 
it's possible both queues could get wedged. Quickstart and the UI are 
not completely independent projects. Quickstart has roles for deploying 
the UI, which means there is a connection there.


I think the only way you could have independent gate queues is if you 
had two disjoint sets of projects that could be gated without any use of 
projects from the other set. I don't think it's possible to divide 
TripleO in that way, but if I'm wrong then maybe you could do multiple 
queues.




On Thu, Oct 11, 2018 at 1:17 PM Emilien Macchi > wrote:




On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora
mailto:ellor...@redhat.com>> wrote:

Hello there,

    After suffering a lot from zuul's tripleo gate piepeline
queue reseting after failures on patches I have ask myself what
would happend if we have more than one queue for gating tripleo.

    After a quick read here
https://zuul-ci.org/docs/zuul/user/gating.html, I have found the
following:

"If changes with cross-project dependencies do not share a
change queue then Zuul is unable to enqueue them together, and
the first will be required to merge before the second is enqueued."

    So it make sense to share zuul queue, but maybe only one
queue for all tripleo projects is too  much, for example sharing
queue between tripleo-ui and tripleo-quickstart, maybe we need
for example to queues for product stuff and one for CI, so
product does not get resetted if CI fails in a patch.

    What do you think ?

Probably a wrong example, as TripleO UI gate is using CI jobs
running tripleo-quickstart scenarios.
We could create more queues for projects which are really
independent from each other but we need to be very careful about it.
-- 
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



--
Quique Llorente

Openstack TripleO CI

__
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] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-10 Thread Ben Nemec




On 10/10/18 1:35 PM, Greg Hill wrote:


I'm not sure how using pull requests instead of Gerrit changesets would
help "core reviewers being pulled on to other projects"?


The 2 +2 requirement works for larger projects with a lot of 
contributors. When you have only 3 regular contributors and 1 of them 
gets pulled on to a project and can no longer actively contribute, you 
have 2 developers who can +2 each other but nothing can get merged 
without that 3rd dev finding time to add another +2. This is what 
happened with Taskflow a few years back. Eventually the other 2 gave up 
and moved on also.


As the others have mentioned, this doesn't need to continue to be a 
blocker. If the alternative is nobody working on the project at all, a 
single approver policy is far better. In practice it's probably not much 
different from having a general oslo core rubber stamp +2 a patch that 
was already reviewed by a taskflow expert.




Is this just about preferring not having a non-human gatekeeper like
Gerrit+Zuul and being able to just have a couple people merge whatever
they want to the master HEAD without needing to talk about +2/+W rights?


We plan to still have a CI gatekeeper, probably Travis CI, to make sure 
PRs past muster before being merged, so it's not like we're wanting to 
circumvent good contribution practices by committing whatever to HEAD. 
But the +2/+W rights thing was a huge PITA to deal with with so few 
contributors, for sure.


I guess this would be the one concern I'd have about moving it out. We 
still have a fair number of OpenStack projects depending on taskflow[1] 
to one degree or another, and having taskflow fully integrated into the 
OpenStack CI system is nice for catching problems with proposed changes 
early. I think there was some work recently to get OpenStack CI voting 
on Github, but it seems inefficient to do work to move it out of 
OpenStack and then do more work to partially bring it back.


I suppose the other option is to just stop CI'ing on OpenStack and rely 
on the upper-constraints gating we do for our other dependencies. That 
would be unfortunate, but again if the alternative is no development at 
all then it might be a necessary compromise.


1: 
http://codesearch.openstack.org/?q=taskflow=nope=requirements.txt=




If it's just about preferring the pull request workflow versus the
Gerrit rebase workflow, just say so. Same for just preferring the
Github
UI versus Gerrit's UI (which I agree is awful).


I mean, yes, I personally prefer the Github UI and workflow, but that 
was not a primary consideration. I got used to using gerrit well enough. 
It was mostly the  There's also a sense that if a project is in the 
Openstack umbrella, it's not useful outside Openstack, and Taskflow is 
designed to be a general purpose library. The hope is that just making 
it a regular open source project might attract more users and 
contributors. This may or may not bear out, but as it is, there's no 
real benefit to staying an openstack project on this front since nobody 
is actively working on it within the community.


Greg

__
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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Ben Nemec




On 10/9/18 10:19 AM, Doug Hellmann wrote:

Brian Rosmaita  writes:


On 10/8/18 11:59 PM, Matthew Thode wrote:

several projects have had problems with the new release, some have ways
of working around it, and some do not.  I'm sending this just to raise
the issue and allow a place to discuss solutions.

Currently there is a review proposed to blacklist 9.0.0, but if this is
going to still be an issue somehow in further releases we may need
another solution.

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


As indicated in the commit message on the above patch, 9.0.0 contains a
bug that's been fixed in oslo.messaging master, so I don't think there's
any question that 9.0.0 has to be blacklisted.


I've proposed releasing oslo.messaging 9.0.1 in
https://review.openstack.org/609030


I also included it in https://review.openstack.org/#/c/609031/ (which I 
see you found).




If we don't land the constraint update to allow 9.0.1 in, then there's
no rush to blacklist anything, is there?


Probably not. We'll want to blacklist it before we allow 9.0.1, but I 
suspect this is mostly a test problem since in production the transport 
would have to be set explicitly.





As far as the timing/content of 9.0.1, however, that may require further
discussion.

(In other words, I'm saying that when you say 'another solution', my
position is that we should take 'another' to mean 'additional', not
'different'.)


I'm not sure what that means.

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 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][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Ben Nemec




On 10/9/18 9:06 AM, Lance Bragstad wrote:
Keystone is failing because it's missing a fix from oslo.messaging [0]. 
That said, keystone is also relying on an internal implementation detail 
in oslo.messaging by mocking it in tests [1]. The notification work has 
been around in keystone for a *long* time, but it's apparent that we 
should revisit these tests to make sure we aren't testing something that 
is already tested by oslo.messaging if we're mocking internal 
implementation details of a library.


This is actually the same problem Cinder and Glance had, it's just being 
hidden because there is an exception handler in Keystone that buried the 
original exception message in log output. 9.0.1 will get Keystone 
working too.


But mocking library internals is still naughty and you should stop that. :-P



Regardless, blacklisting version 9.0.0 will work for keystone, but we 
can work around it another way by either rewriting the tests to not care 
about oslo.messaging specifics, or removing them if they're obsolete.


[0] https://review.openstack.org/#/c/608196/
[1] 
https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/common/test_notifications.py#n1343


On Mon, Oct 8, 2018 at 10:59 PM Matthew Thode > wrote:


several projects have had problems with the new release, some have ways
of working around it, and some do not.  I'm sending this just to raise
the issue and allow a place to discuss solutions.

Currently there is a review proposed to blacklist 9.0.0, but if this is
going to still be an issue somehow in further releases we may need
another solution.

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

-- 
Matthew Thode (prometheanfire)

__
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 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][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

2018-10-09 Thread Ben Nemec




On 10/9/18 8:22 AM, Brian Rosmaita wrote:

On 10/8/18 11:59 PM, Matthew Thode wrote:

several projects have had problems with the new release, some have ways
of working around it, and some do not.  I'm sending this just to raise
the issue and allow a place to discuss solutions.

Currently there is a review proposed to blacklist 9.0.0, but if this is
going to still be an issue somehow in further releases we may need
another solution.

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


As indicated in the commit message on the above patch, 9.0.0 contains a
bug that's been fixed in oslo.messaging master, so I don't think there's
any question that 9.0.0 has to be blacklisted.


Agreed.



As far as the timing/content of 9.0.1, however, that may require further
discussion.


I'll get the release request for 9.0.1 up today. That should fix 
everyone but Keystone. I'm not sure yet what is going to be needed to 
get that working. They are mocking a private function from 
oslo.messaging, but we didn't remove it so I'm not sure why those tests 
started failing.




(In other words, I'm saying that when you say 'another solution', my
position is that we should take 'another' to mean 'additional', not
'different'.)

cheers,
brian

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

2018-10-02 Thread Ben Nemec




On 10/2/18 9:37 AM, Mark Goddard wrote:



On Tue, 2 Oct 2018 at 14:03, Jay Pipes > wrote:


On 10/02/2018 08:58 AM, Mark Goddard wrote:
 > Hi,
 >
 > In the most recent Ironic meeting we discussed [1] tenks, and the
 > possibility of adding the project under Ironic governance. We
agreed to
 > move the discussion to the mailing list. I'll introduce the
project here
 > and give everyone a chance to ask questions. If things appear to
move in
 > the right direction, I'll propose a vote for inclusion under
Ironic's
 > governance.
 >
 > Tenks is a project for managing 'virtual bare metal clusters'. It
aims
 > to be a drop-in replacement for the various scripts and templates
that
 > exist in the Ironic devstack plugin for creating VMs to act as bare
 > metal nodes in development and test environments. Similar code
exists in
 > Bifrost and TripleO, and probably other places too. By focusing
on one
 > project, we can ensure that it works well, and provides all the
features
 > necessary as support for bare metal in the cloud evolves.
 >
 > That's tenks the concept. Tenks in reality today is a working
version
 > 1.0, written in Ansible, built by Will Miller (w-miller) during his
 > summer placement. Will has returned to his studies, and Will Szumski
 > (jovial) has picked it up. You don't have to be called Will to
work on
 > Tenks, but it helps.
 >
 > There are various resources available for anyone wishing to find
out more:
 >
 > * Ironic spec review: https://review.openstack.org/#/c/579583
 > * Documentation: https://tenks.readthedocs.io/en/latest/
 > * Source code: https://github.com/stackhpc/tenks
 > * Blog: https://stackhpc.com/tenks.html
 > * IRC: mgoddard or jovial in #openstack-ironic
 >
 > What does everyone think? Is this something that the ironic
community
 > could or should take ownership of?

How does Tenks relate to OVB?


https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html


Good question. As far as I'm aware, OVB is a tool for using an OpenStack 
cloud to host the virtual bare metal nodes, and is typically used for 
testing TripleO. Tenks does not rule out supporting this use case in 
future, but currently operates more like the Ironic devstack plugin, 
using libvirt/KVM/QEMU as the virtualisation provider.


Yeah, sounds like this is more a replacement for the kvm virtual 
environment setup in tripleo-quickstart. I'm adding the tripleo tag for 
their attention.


__
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] [oslo] PTG wrapup

2018-09-28 Thread Ben Nemec


A bit belated, but here goes:

Monday:
Had a good discussion in the Keystone room about oslo.limit with some 
Nova developers. There was quite a bit of discussion around how the 
callbacks should work for resource usage and cleanup, and the Nova 
developers took an action to do some prototyping. Also, there was 
general consensus in the room that user quotas were probably a thing 
that should go away and we didn't want to spend a lot of time trying to 
accommodate them. If you have a different viewpoint on that please let 
someone involved with this know ASAP.


In addition, for the first time the topic of how to migrate from 
project-specific quota code to oslo.limit got some serious discussion. 
The current proposal is to have projects support both methods for a 
cycle to allow migration of the data. A Nova spec is planned to detail 
how that will work.


https://etherpad.openstack.org/p/keystone-stein-unified-limits

In the afternoon there was also a productive discussion in the API sig 
room about the healthcheck middleware. Initially it was a lot of "we 
want this, but no one has time to work on it", but after some more 
digging into the existing oslo.middleware code it was determined that we 
might be able to reuse parts of that to reduce the amount of work needed 
to implement it. This also makes it an easier sell to projects since 
many already include the old healthcheck middleware and this would be an 
extension of it. Graham was going to hack on the implementation in his 
PTG downtime.


https://etherpad.openstack.org/p/api-sig-stein-ptg

Tuesday:
Our scheduled session day. The main points of the discussion were 
(hopefully) captured in 
https://etherpad.openstack.org/p/oslo-stein-ptg-planning


Highlights:
-The oslo.config driver work is continuing. One outcome of the 
discussion was that we decided to continue to defer the question of how 
to handle mutable config with drivers. If somebody asks for it then we 
can revisit.


-There was general agreement to proceed with the simple config 
validator: https://review.openstack.org/#/c/567950/ There is a 
significantly more complex version of that review out there as well, but 
it's so large that nobody has had time to review it. The plan is that 
the added features from that can be added to this simple version in 
easier-to-digest pieces once the base functionality is there.


-The config migration tool is awaiting reviews (I see Doug reviewed it 
today, thanks!), and then will proceed with phase 2 in which it will try 
to handle more complex migrations.


-oslo.upgradecheck is now a thing. If you don't know what that is, see 
Matt Riedemann's email updates on the upgrade checkers goal.


-There was some extensive discussion around how to add parallel 
processing to oslo.privsep. The main outcomes were that we needed to get 
rid of the eventlet dependency from the initial implementation, but we 
think the rest of the code should already deal with concurrent execution 
as expected. However, as we are still lacking deep expertise in 
oslo.privsep since Gus left (help wanted!), it is TBD whether we are 
right. :-)


-A pluggable policy spec and some initial patches are proposed and need 
reviews. One of these days I will have time to do that.


Wednesday:
Had a good discussion about migrating Oslo to Storyboard. As you may 
have noticed, that discussion has continued on the mailing list so check 
out the [storyboard] tagged threads for details on where that stands. If 
you want to kick the tires of the test import you can do so here: 
https://storyboard-dev.openstack.org/#!/story/list?project_group_id=74


Thursday:
Discussion in the TripleO room about integrating the config drivers 
work. It sounded like they had a plan to implement support for them when 
they are available, so \o/.


Friday:
Mostly continued work on oslo.upgradecheck in between some non-Oslo 
discussions.


I think that's it. If I missed anything or you have questions/comments 
feel free to reply.


Thanks.

-Ben

__
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] [goal][python3] week 7 update

2018-09-28 Thread Ben Nemec




On 9/28/18 1:38 PM, Jeremy Stanley wrote:

On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote:

Doug Hellmann  wrote on 09/26/2018 06:29:11 PM:


* We do not want to set the override once in testenv, because that
   breaks the more specific versions used in default environments like
   py35 and py36 (at least under older versions of tox).



I assume that something like
https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=fa64a93c965e6a6692711962ad6584534da81695
  should be a perfectly acceptable alternative in at least some cases.
Agreed?


I believe the confusion is that ignore_basepython_conflict didn't
appear in a release of tox until after we started patching projects
for this effort (in fact it was added to tox in part because we
discovered the issue in originally attempting to use basepython
globally).


Yeah, if you're okay with requiring tox 3.1+ then you can use that 
instead. We've been avoiding it for now in other projects because some 
of the distros aren't shipping tox 3.1 yet and some people prefer not to 
mix distro Python packages and pip ones. At some point I expect we'll 
migrate everything to the new behavior though.


__
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][castellan] Time for a 1.0 release?

2018-09-28 Thread Ben Nemec




On 9/28/18 3:59 AM, Thierry Carrez wrote:

Ade Lee wrote:

On Tue, 2018-09-25 at 16:30 -0500, Ben Nemec wrote:

Doug pointed out on a recent Oslo release review that castellan is
still
not officially 1.0. Given the age of the project and the fact that
we're
asking people to deploy a Castellan-compatible keystore as one of
the
base services, it's probably time to address that.

To that end, I'm sending this to see if anyone is aware of any
reasons
we shouldn't go ahead and tag a 1.0 of Castellan.



+ 1


+1
Propose it and we can continue the discussion on the review :)



Done: https://review.openstack.org/606108

__
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] [python3-first] support in stable branches

2018-09-27 Thread Ben Nemec




On 9/27/18 10:36 AM, Doug Hellmann wrote:

Dariusz Krol  writes:


Hello Champions :)


I work on the Trove project and we are wondering if python3 should be
supported in previous releases as well?

Actually this question was asked by Alan Pevec from the stable branch
maintainers list.

I saw you added releases up to ocata to support python3 and there are
already changes on gerrit waiting to be merged but after reading [1] I
have my doubts about this.


I'm not sure what you're referring to when you say "added releases up to
ocata" here. Can you link to the patches that you have questions about?


Possibly the zuul migration patches for all the stable branches? If so, 
those don't change the status of python 3 support on the stable 
branches, they just split the zuul configuration to make it easier to 
add new python 3 jobs on master without affecting the stable branches.





Could you elaborate why it is necessary to support previous releases ?


Best,

Dariusz Krol


[1] https://docs.openstack.org/project-team-guide/stable-branches.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



__
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] [storyboard] Prioritization?

2018-09-27 Thread Ben Nemec




On 9/27/18 4:17 AM, Thierry Carrez wrote:

Ben Nemec wrote:

On 9/25/18 3:29 AM, Thierry Carrez wrote:
Absence of priorities was an initial design choice[1] based on the 
fact that in an open collaboration every group, team, organization 
has their own views on what the priority of a story is, so worklist 
and tags are better ways to capture that. Also they don't really work 
unless you triage everything. And then nobody really looks at them to 
prioritize their work, so they are high cost for little benefit.


So was the storyboard implementation based on the rant section then? 
Because I don't know that I agree with/understand some of the 
assertions there.


First, don't we _need_ to triage everything? At least on some minimal 
level? Not looking at new bugs at all seems like the way you end up 
with a security bug open for two years *ahem*. Not that I would know 
anything about that (it's been fixed now, FTR).


StoryBoard's initial design is definitely tainted by an environment that 
has changed since. Back in 2014, most teams did not triage every bug, 
and were basically using Launchpad as a task tracker (you created the 
bugs that you worked on) rather than a bug tracker (you triage incoming 
requests and prioritize them).


I'm not sure that has actually changed much. Stemming from this thread I 
had an offline discussion around bug management and the gist was that we 
don't actually spend much time looking at the bug list for something to 
work on. I tend to pick up a bug when I hit it in my own environments or 
if I'm doing bug triage and it's something I think I can fix quickly. I 
would like to think that others are more proactive, but I suspect that's 
wishful thinking. I had vague thoughts that I might actually start 
tackling bugs that way this cycle since I spent a lot of last cycle 
getting Oslo bugs triaged so I might be able to repurpose that time, but 
until it actually happens it's just hopes and dreams. :-)


Unfortunately, even if bug triage is a "write once, read never" process 
I think we still need to do it to avoid the case I mentioned above where 
something important falls through the cracks. :-/




Storyboard is therefore designed primarily a task tracker (a way to 
organize work within teams), so it's not great as an issue tracker (a 
way for users to report issues). The tension between the two concepts 
was explored in [1], with the key argument that trying to do both at the 
same time is bound to create frustration one way or another. In PM 
literature you will even find suggestions that the only way to solve the 
diverging requirements is to use two completely different tools (with 
ways to convert a reported issue into a development story). But that 
"solution" works a lot better in environments where the users and the 
developers are completely separated (proprietary software).


[1] https://wiki.openstack.org/wiki/StoryBoard/Vision


[...]
Also, like it or not there is technical debt we're carrying over here. 
All of our bug triage up to this point has been based on launchpad 
priorities, and as I think I noted elsewhere it would be a big step 
backward to completely throw that out. Whatever model for 
prioritization and triage that we choose, I feel like there needs to 
be a reasonable migration path for the thousands of existing triaged 
lp bugs in OpenStack.


I agree, which is why I'm saying that the "right" answer might not be 
the "best" answer.




Yeah, I was mostly just +1'ing your point here. :-)

__
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] [storyboard][oslo] Fewer stories than bugs?

2018-09-26 Thread Ben Nemec


Okay, I found a few bugs that are in launchpad but not storyboard:

https://bugs.launchpad.net/python-stevedore/+bug/1784823
https://bugs.launchpad.net/pbr/+bug/1777625
https://bugs.launchpad.net/taskflow/+bug/1756520
https://bugs.launchpad.net/pbr/+bug/1742809

The latter three are all in an incomplete state, so maybe that's being 
ignored by the migration script? The first appears to be a completely 
missing project.  None of the stevedore bugs I've spot checked are in 
storyboard. Maybe it has to do with the fact that the project name is 
stevedore but the bug link is python-stevedore? I'm not sure why that 
is, but there may be something a little weird going on with that project.


On 9/25/18 1:22 PM, Kendall Nelson wrote:

Hey Ben,

I am looking into it! I am guessing that some of the discrepancy is bugs 
being filed after I did the migration. I might also have missed one of 
the launchpad projects. I will redo the migrations today and we can see 
if the numbers match up after (or are at least much closer).


We've never had an issue with stories not being created and there were 
no errors in any of the runs I did of the migration scripts. I'm 
guessing PEBKAC :)


-Kendall (diablo_rojo)

On Mon, Sep 24, 2018 at 2:38 PM Ben Nemec <mailto:openst...@nemebean.com>> wrote:


This is a more oslo-specific (maybe) question that came out of the test
migration. I noticed that launchpad is reporting 326 open bugs across
the Oslo projects, but in Storyboard there are only 266 stories
created.
While I'm totally onboard with reducing our bug backlog, I'm curious
why
that is the case. I'm speculating that maybe Launchpad counts bugs that
affect multiple Oslo projects as multiple bugs whereas Storyboard is
counting them as a single story?

I think we were also going to skip
https://bugs.launchpad.net/openstack-infra which for some reason
appeared in the oslo group, but that's only two bugs so it doesn't
account for anywhere near the full difference.

Mostly I just want to make sure we didn't miss something. I'm hoping
this is a known behavior and we don't have to start comparing bug lists
to find the difference. :-)

Thanks.

-Ben

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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 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] [storyboard] Prioritization?

2018-09-26 Thread Ben Nemec




On 9/25/18 3:29 AM, Thierry Carrez wrote:

Doug Hellmann wrote:

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.


Absence of priorities was an initial design choice[1] based on the fact 
that in an open collaboration every group, team, organization has their 
own views on what the priority of a story is, so worklist and tags are 
better ways to capture that. Also they don't really work unless you 
triage everything. And then nobody really looks at them to prioritize 
their work, so they are high cost for little benefit.


So was the storyboard implementation based on the rant section then? 
Because I don't know that I agree with/understand some of the assertions 
there.


First, don't we _need_ to triage everything? At least on some minimal 
level? Not looking at new bugs at all seems like the way you end up with 
a security bug open for two years *ahem*. Not that I would know anything 
about that (it's been fixed now, FTR).


I'm also not sure I agree with the statement that setting a priority for 
a blueprint is useless. Prioritizing feature work is something everyone 
needs to do these days since no team has enough people to implement 
every proposed feature. Maybe the proposal is for everyone to adopt 
Nova-style runways, but I'm not sure how well that works for smaller 
projects where many of the developers are only able to devote part of 
their time to it. Setting a time window for a feature to merge or get 
kicked to the back of line would be problematic for me.


That section also ends with an unanswered question regarding how to do 
bug triage in this model, which I guess is the thing we're trying to 
address with this discussion.




That said, it definitely creates friction, because alternatives are less 
convenient / visible, and it's not how other tools work... so the 
"right" answer here may not be the "best" answer.


[1] https://wiki.openstack.org/wiki/StoryBoard/Priority



Also, like it or not there is technical debt we're carrying over here. 
All of our bug triage up to this point has been based on launchpad 
priorities, and as I think I noted elsewhere it would be a big step 
backward to completely throw that out. Whatever model for prioritization 
and triage that we choose, I feel like there needs to be a reasonable 
migration path for the thousands of existing triaged lp bugs in OpenStack.


__
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] OVB 1.0 and Upcoming Changes

2018-09-26 Thread Ben Nemec

(this is a reprint of a blog post I just made. I'm sending it here 
explicitly too because most (maybe all) of the major users are here. See 
also http://blog.nemebean.com/content/ovb-10-and-upcoming-changes)


The time has come to declare a 1.0 version for OVB. There are a couple 
of reasons for this:


1. OVB has been stable for quite a while
2. It's time to start dropping support for ancient behaviors/clouds

The first is somewhat self-explanatory. Since its inception, I have 
attempted to maintain backward compatibility to the earliest deployments 
of OVB. This hasn't always been 100% successful, but when 
incompatibilities were introduced they were considered bugs that had to 
be fixed. At this point the OVB interface has been stable for a 
significant period of time and it's time to lock that in.


However, on that note it is also time to start dropping support for some 
of those earliest environments. The limitations of the original 
architecture make it more and more difficult to implement new features 
and there are very few to no users still relying on it. Declaring a 1.0 
and creating a stable branch for it should allow us to move forward with 
new features while still providing a fallback for anyone who might still 
be using OVB on a Kilo-based cloud (for example). I'm not aware of any 
such users, but that doesn't mean they don't exist.


Specifically, the following changes are expected for OVB 2.0:

* Minimum host cloud version of Newton. This allows us to default to 
using Neutron port-security, which will simplify the configuration 
matrix immensely.
* Drop support for parameters in environment files. All OVB 
configuration environment files should be using parameter_defaults now 
anyway, and some upcoming features require us to force the switch. This 
shouldn't be too painful as it mostly requires 
s/parameters:/parameter_defaults:/ in any existing environments.
* Part of the previous point is a change to how ports and networks are 
created. This means that if users have created custom port or network 
layouts they will need to update their templates to reflect the new way 
of passing in network details. I don't know that anyone has done this, 
so I expect the impact to be small.


The primary motivation for these changes is the work to support routed 
networks in OVB[1]. It requires customization of some networks that were 
hard-coded in the initial version of OVB, which means that making them 
configurable without breaking compatibility would be 
difficult/impossible. Since the necessary changes should only break very 
old style deployments, I feel it is time to make a clean cut and move on 
from them. As I noted earlier, I don't believe this will actually affect 
many OVB users, if any.


If these changes do sound like they may break you, please contact me 
ASAP. It would be a good idea to test your use-case against the 
routed-networks branch[1] to make sure it still works. If so, great! 
There's nothing to do. That branch already includes most of the breaking 
changes. If not, we can investigate how to maintain compatibility, or if 
that's not possible you may need to continue using the 1.0 branch of OVB 
which will exist indefinitely for users who still absolutely need the 
old behaviors and can't move forward for any reason. There is currently 
no specific timeline for when these changes will merge back to master, 
but I hope to get it done in the relatively near future. Don't 
procrastinate. :-)


Some of these changes have been coming for a while - the lack of 
port-security in the default templates is starting to cause more grief 
than maintaining backward compatibility saves. The routed networks 
architecture is a realization of the original goal for OVB, which is to 
deploy arbitrarily complex environments for testing deployment tools. If 
you want some geek porn, check out this network diagram[2] for routed 
networks. It's pretty cool to be able to deploy such a complex 
environment with a couple of configuration files and a single command. 
Once it is possible to customize all the networks it should be possible 
to deploy just about any environment imaginable (challenge accepted... 
;-). This is a significant milestone for OVB and I look forward to 
seeing it in action.


-Ben

1: 
https://github.com/cybertron/openstack-virtual-baremetal/tree/routed-networks

2: https://plus.google.com/u/0/+BenNemec/posts/5nGJ3Rzt2iL

__
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] [storyboard] why use different "bug" tags per project?

2018-09-26 Thread Ben Nemec




On 9/26/18 8:20 AM, Jeremy Stanley wrote:

On 2018-09-26 00:50:16 -0600 (-0600), Chris Friesen wrote:

At the PTG, it was suggested that each project should tag their bugs with
"-bug" to avoid tags being "leaked" across projects, or something
like that.

Could someone elaborate on why this was recommended?  It seems to me that
it'd be better for all projects to just use the "bug" tag for consistency.

If you want to get all bugs in a specific project it would be pretty easy to
search for stories with a tag of "bug" and a project of "X".


Because stories are a cross-project concept and tags are applied to
the story, it's possible for a story with tasks for both
openstack/nova and openstack/cinder projects to represent a bug for
one and a new feature for the other. If they're tagged nova-bug and
cinder-feature then that would allow them to match the queries those
teams have defined for their worklists, boards, et cetera. It's of
course possible to just hand-wave that these intersections are rare
enough to ignore and go ahead and use generic story tags, but the
recommendation is there to allow teams to avoid disagreements in
such cases.


Would it be possible to automate that tagging on import? Essentially tag 
every lp bug that is not wishlist with $PROJECT-bug and wishlists with 
$PROJECT-feature. Otherwise someone has to go through and re-categorize 
everything in Storyboard.


I don't know if everyone would want that, but if this is the recommended 
practice I would want it for Oslo.


__
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] [oslo][castellan] Time for a 1.0 release?

2018-09-25 Thread Ben Nemec

Doug pointed out on a recent Oslo release review that castellan is still 
not officially 1.0. Given the age of the project and the fact that we're 
asking people to deploy a Castellan-compatible keystore as one of the 
base services, it's probably time to address that.


To that end, I'm sending this to see if anyone is aware of any reasons 
we shouldn't go ahead and tag a 1.0 of Castellan.


Thanks.

-Ben

__
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] [storyboard][oslo] Fewer stories than bugs?

2018-09-24 Thread Ben Nemec

This is a more oslo-specific (maybe) question that came out of the test 
migration. I noticed that launchpad is reporting 326 open bugs across 
the Oslo projects, but in Storyboard there are only 266 stories created. 
While I'm totally onboard with reducing our bug backlog, I'm curious why 
that is the case. I'm speculating that maybe Launchpad counts bugs that 
affect multiple Oslo projects as multiple bugs whereas Storyboard is 
counting them as a single story?


I think we were also going to skip 
https://bugs.launchpad.net/openstack-infra which for some reason 
appeared in the oslo group, but that's only two bugs so it doesn't 
account for anywhere near the full difference.


Mostly I just want to make sure we didn't miss something. I'm hoping 
this is a known behavior and we don't have to start comparing bug lists 
to find the difference. :-)


Thanks.

-Ben

__
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] [storyboard] Prioritization?

2018-09-24 Thread Ben Nemec


Hi,

This came up in the Oslo meeting as a result of my initial look at the 
test Storyboard import. It appears all of the priority data from 
launchpad gets lost in the migration, which is going to make organizing 
hundreds of bugs somewhat difficult. I'm particularly not fond of it 
after spending last cycle whittling down our untriaged bug list. :-)


Work lists and tags were mentioned as possible priority management tools 
in Storyboard, so is there some way to migrate launchpad priorities into 
one of those automatically? If not, are there any plans to add that?


It sounded like a similar conversation is happening with a few other 
teams so we wanted to bring the discussion to the mailing list for 
visibility.


Thanks.

-Ben

__
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] [goals][upgrade-checkers] Week R-29 Update

2018-09-24 Thread Ben Nemec




On 09/22/2018 11:15 AM, Matt Riedemann wrote:

On 9/21/2018 4:19 PM, Ben Nemec wrote:
* The only two projects that I'm aware of with patches up at this 
point are monasca [2] and designate [3]. The monasca one is tricky 
because as I've found going through release notes for some projects, 
they don't really have any major upgrade impacts so writing checks is 
not obvious. I don't have a great solution here. What monasca has 
done is add the framework with a noop check. If others are in the 
same situation, I'd like to hear your thoughts on what you think 
makes sense here. The alternative is these projects opt out of the 
goal for Stein and just add the check code later when it makes sense 
(but people might forget or not care to do that later if it's not a 
goal).


My inclination is for the command to exist with a noop check, the main 
reason being that if we create it for everyone this cycle then the 
deployment tools can implement calls to the status commands all at 
once. If we wait until checks are needed then someone has to not only 
implement it in the service but also remember to go update all of the 
deployment tools. Implementing a noop check should be pretty trivial 
with the library so it isn't a huge imposition.


Yeah, I agree, and I've left comments on the patch to give some ideas on 
how to write the noop check with a description that explains it's an 
initial check but doesn't really do anything. The alternative would be 
to dump the table header for the results but then not have any rows, 
which could be more confusing.




+1 to "this page intentionally left blank", hopefully without the 
logical contradiction those pages always create. ;-)


__
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] [oslo] upgradecheck core list populated

2018-09-24 Thread Ben Nemec


Hey,

The oslo.upgradecheck core list is now populated. oslo-core and Matt 
Riedemann should have +2 rights on it, so review away! :-)


-Ben

__
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] [goals][upgrade-checkers] Week R-29 Update

2018-09-21 Thread Ben Nemec




On 09/21/2018 03:53 PM, Matt Riedemann wrote:

Updates for this week:

* As bnemec noted in the last update [1], he's making some progress with 
the oslo.upgradecheck library. He's retrofitting the nova-status upgrade 
check code to use the library and has a patch up for designate to use it.


* The only two projects that I'm aware of with patches up at this point 
are monasca [2] and designate [3]. The monasca one is tricky because as 
I've found going through release notes for some projects, they don't 
really have any major upgrade impacts so writing checks is not obvious. 
I don't have a great solution here. What monasca has done is add the 
framework with a noop check. If others are in the same situation, I'd 
like to hear your thoughts on what you think makes sense here. The 
alternative is these projects opt out of the goal for Stein and just add 
the check code later when it makes sense (but people might forget or not 
care to do that later if it's not a goal).


My inclination is for the command to exist with a noop check, the main 
reason being that if we create it for everyone this cycle then the 
deployment tools can implement calls to the status commands all at once. 
If we wait until checks are needed then someone has to not only 
implement it in the service but also remember to go update all of the 
deployment tools. Implementing a noop check should be pretty trivial 
with the library so it isn't a huge imposition.




* The reference docs I wrote for writing upgrade checks is published now 
[4]. As I've been answering some questions in storyboard and IRC, it's 
obvious that I need to add some FAQs into those docs because I've taken 
some of this for granted on how it works in nova, so I'll push a docs 
change for some of that as well and link it back into the story.


As always, feel free to reach out to me with any questions or issues you 
might have with completing this goal (or just getting started).


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134972.html 


[2] https://review.openstack.org/#/c/603465/
[3] https://review.openstack.org/#/c/604430/
[4] https://docs.openstack.org/nova/latest/reference/upgrade-checks.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-dev] [oslo] Storyboard test import done

2018-09-21 Thread Ben Nemec


Hi,

The test import of the Oslo projects is done (thanks Kendall!), so 
everyone from the Oslo team please take a look around and provide 
feedback on it. If we do the migration this cycle we want to do it 
earlier rather than later so we aren't dealing with migration fallout 
while trying to stabilize things at the end.


https://storyboard-dev.openstack.org/#!/project_group/oslo

Thanks.

-Ben

__
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] [goals][upgrade-checkers] Week R-30 update

2018-09-21 Thread Ben Nemec




On 09/15/2018 10:30 AM, Matt Riedemann wrote:

Just a couple of updates this week.

* I have assigned PTLs (for projects that have PTLs [1]) to their 
respective tasks in StoryBoard [2]. If someone else on your team is 
planning on working on the pre-upgrade check goal then please just 
reassign ownership of the task.


* I have started going through some project release notes looking for 
upgrade impacts and leaving notes in the task assigned per project. 
There were some questions at the PTG about what some projects could add 
for pre-upgrade checks so check your task to see if I've left any 
thoughts. I have not gone through all projects yet.


* Ben Nemec has extracted the common upgrade check CLI framework into a 
library [3] (thanks Ben!) and is working on getting that imported into 
Gerrit. It would be great if projects that start working on the goal can 
try using that library and provide feedback.


The library has been imported into Gerrit, so people can start consuming 
it from there. Note that there are quite a few pending patches to it 
already that we can't merge until the governance change goes in and I 
can populate the reviewer list.


I also pushed a patch to demonstrate how it would be integrated with the 
existing Nova code[1] and a patch to Designate to demonstrate how a 
completely new set of checks might be implemented[2]. The Designate 
check required some changes in the library config handling, but I think 
the patches proposed should work well now. I need to write some unit 
tests for it, but in my manual testing it has behaved as expected.


As Matt said, any feedback is welcome. I suggest working off the end of 
the series that includes [3] as there are some significant api changes 
there.


-Ben

1: https://review.openstack.org/#/c/603499
2: https://review.openstack.org/#/c/604430
3: https://review.openstack.org/#/c/604422/

__
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] [goals][upgrade-checkers] Week R-31 update

2018-09-13 Thread Ben Nemec




On 09/12/2018 01:57 PM, Doug Hellmann wrote:

Excerpts from Ben Nemec's message of 2018-09-12 13:51:16 -0600:


On 09/04/2018 06:49 PM, Matt Riedemann wrote:

On 9/4/2018 6:39 PM, Ben Nemec wrote:

Would it be helpful to factor some of the common code out into an Oslo
library so projects basically just have to subclass, implement check
functions, and add them to the _upgrade_checks dict? It's not a huge
amount of code, but a bunch of it seems like it would need to be
copy-pasted into every project. I have a tentative topic on the Oslo
PTG schedule for this but figured I should check if it's something we
even want to pursue.


Yeah I'm not opposed to trying to pull the nova stuff into a common
library for easier consumption in other projects, I just haven't devoted
the time for it, nor will I probably have the time to do it. If others
are willing to investigate that it would be great.



Okay, here's a first shot at such a library:
https://github.com/cybertron/oslo.upgradecheck

Lots of rough edges that would need to be addressed before it could be
released, but it demonstrates the basic idea I had in mind for this. The
upgradecheck module contains the common code, and __main__.py is a demo
use of the code.

-Ben



Nice! Let's get that imported into gerrit and keep iterating on it to
make it usable for the goal. Maybe we can get one of the projects most
interested in working on this goal early to help with testing and UX
feedback.



Okay, I got all the test jobs working and even added a few basic unit 
tests. I think it's about ready for import so I'll take a look at doing 
that soon.


__
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] [goals][upgrade-checkers] Week R-31 update

2018-09-12 Thread Ben Nemec




On 09/04/2018 06:49 PM, Matt Riedemann wrote:

On 9/4/2018 6:39 PM, Ben Nemec wrote:
Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo 
PTG schedule for this but figured I should check if it's something we 
even want to pursue.


Yeah I'm not opposed to trying to pull the nova stuff into a common 
library for easier consumption in other projects, I just haven't devoted 
the time for it, nor will I probably have the time to do it. If others 
are willing to investigate that it would be great.




Okay, here's a first shot at such a library: 
https://github.com/cybertron/oslo.upgradecheck


Lots of rough edges that would need to be addressed before it could be 
released, but it demonstrates the basic idea I had in mind for this. The 
upgradecheck module contains the common code, and __main__.py is a demo 
use of the code.


-Ben

__
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][cinder] about unified limits

2018-09-10 Thread Ben Nemec

We had an extensive discussion of this in the keystone room today: 
https://etherpad.openstack.org/p/keystone-stein-unified-limits


We had a couple of Nova people in the room, so if anyone from other 
teams can take a look at the outcomes on the etherpad and let us know if 
there are any issues with the current plan for other projects that would 
be good.


On 09/10/2018 09:25 AM, Ben Nemec wrote:
We had talked about Tuesday afternoon. I need to sync up with Lance and 
figure out exactly when will work best.


On 09/08/2018 10:58 AM, Jay S Bryant wrote:

Ben,

Ping me when you are planning on having this discussion if you think 
of it.  Since there is interest in this for Cinder I would like to try 
to be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if 
so that would be a good opportunity for some face-to-face discussion. 
I didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat 
enforcement [0]. During the Rocky PTG we sat down with other 
services and a few operators to explain the current status in 
keystone and if either developers or operators had feedback on the 
API specifically. Notes were captured in etherpad [1]. We spent the 
Rocky cycle fixing usability issues with the API [2] and 
implementing support for a hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as 
stable and it will likely stay that way until we have at least one 
project using unified limits. We can use that as an opportunity to 
do a final flush of any changes that need to be made to the API 
before fully supporting it. The keystone team expects that to be a 
quick transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is 
over it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the 
request claim is valid or not. There are patches up for this work, 
and reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services 
can officially pull it into their code as a dependency and we can 
work out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit 
API being experimental as we shake out usability issues in both 
pieces of software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between 
keystone, oslo, and service developers. I do have a patch up that 
adds a conceptual overview for developers consuming oslo.limit [5], 
which renders into [6].


To be honest, this is g

Re: [openstack-dev] [nova][cinder] about unified limits

2018-09-10 Thread Ben Nemec

We had talked about Tuesday afternoon. I need to sync up with Lance and 
figure out exactly when will work best.


On 09/08/2018 10:58 AM, Jay S Bryant wrote:

Ben,

Ping me when you are planning on having this discussion if you think of 
it.  Since there is interest in this for Cinder I would like to try to 
be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes 
were captured in etherpad [1]. We spent the Rocky cycle fixing 
usability issues with the API [2] and implementing support for a 
hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick 
transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is over 
it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the request 
claim is valid or not. There are patches up for this work, and 
reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work 
out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit API 
being experimental as we shake out usability issues in both pieces of 
software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we 
can use the first couple iterations to generate some well-written 
usage documentation. Any questions coming from developers in this 
phase should probably be answered in documentation if we want to 
enable folks to pick this up and run with it. Otherwise, I could see 
the handful of pe

Re: [openstack-dev] [nova][cinder] about unified limits

2018-09-07 Thread Ben Nemec

I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if that 
would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes were 
captured in etherpad [1]. We spent the Rocky cycle fixing usability 
issues with the API [2] and implementing support for a hierarchical 
enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick transition, 
as we don't want to keep the API hanging in an experimental state. It's 
really just a safe guard to make sure we have the opportunity to use it 
in another service before fully committing to the API. Ultimately, we 
don't want to prematurely mark the API as supported when other services 
aren't even using it yet, and then realize it has issues that could have 
been fixed prior to the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of oslo.limit 
is to abstract project and project hierarchy information away from the 
service, so that services don't have to reimplement client code to 
understand project trees, which could arguably become complex and lead 
to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not usage 
for that claim is valid. For example, here is a project ID, resource 
name, and resource quantity, tell me if this project is over it's 
associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and project 
hierarchies. Then it needs to reason about those things and calculate 
usage from the service in order to determine if the request claim is 
valid or not. There are patches up for this work, and reviews are always 
welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work out 
remaining bugs in both keystone and oslo.limit. Once we're confident in 
both the API and the library, we'll bump oslo.limit to version 1.0 at 
the same time we graduate the unified limits API from "experimental" to 
"supported". Note that oslo libraries <1.0 are considered experimental, 
which fits nicely with the unified limit API being experimental as we 
shake out usability issues in both pieces of software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we can 
use the first couple iterations to generate some well-written usage 
documentation. Any questions coming from developers in this phase should 
probably be answered in documentation if we want to enable folks to pick 
this up and run with it. Otherwise, I could see the handful of people 
pushing the effort becoming a bottle neck in adoption.


Hopefully this helps paint the landscape of where things are currently 
with respect to each piece. As always, let me know if you have any 
additional questions. If people want to discuss online, you can find me, 
and other contributors familiar with this topic, in #openstack-keystone 
or #openstack-dev on IRC (nic: lbragstad).


[0]

Re: [openstack-dev] [election] [tc] TC candidacy

2018-09-07 Thread Ben Nemec




On 09/07/2018 11:19 AM, Samuel Cassiba wrote:

On Fri, Sep 7, 2018 at 8:55 AM, Samuel Cassiba  wrote:

On Fri, Sep 7, 2018 at 6:22 AM, Matt Riedemann  wrote:

On 9/5/2018 2:49 PM, Samuel Cassiba wrote:


Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.



Are there specific initiatives you plan on pushing forward if on the TC? I'm
thinking about stuff from the laundry list here:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Other_Initiatives



Excellent question!

It's not in my nature to push specific agendas. That said, being in
the deploy space, constellations is something that does have a
specific gravity that would, no doubt, draw me in, whether or not I am
part of the TC. I've viewed projects in the deploy space, such aq

Furthering the adoption of secret management is another thing that
hits close to home


...and that would be where an unintended keyboard-seeking Odin attack
preemptively initiates a half-thought thought. It's hard to get upset
at this face, though. https://i.imgur.com/c7tktmO.jpg

To that point, projects like Chef have made use of encrypted secrets
since more or less the dawn of time, but not at all in a portable way.
Continuing the work to bring secrets under a single focus is something
that I would also be a part of, with or without being on the TC.


Just want to note that there is work underway in Oslo to address this. 
The base framework for it merged in Rocky and we plan to have 
integration with Castellan in Stein.


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



In both of these efforts, I envision having some manner of involvement
no matter what. At the strategic level, working to ensure the
disparate efforts are in alignment is where I would gravitate to.

Best,
Samuel

__
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] [stable][keystone] python3 goal progress and tox_install.sh removal

2018-09-06 Thread Ben Nemec




On 09/06/2018 03:01 PM, Lance Bragstad wrote:
I'm noticing some odd cases with respect to the python 3 community goal 
[0]. So far my findings are specific to keystone repositories, but I can 
imagine this affecting other projects.


Doug generated the python 3 reviews for keystone repositories, including 
the ones for stable branches. We noticed some issues with the ones 
proposed to stable (keystoneauth, python-keystoneclient) and master 
(keystonemiddleware). For example, python-keystoneclient's stable/pike 
[1] and stable/ocata [2] branches are both failing with something like [3]:


ERROR: You must give at least one requirement to install (see "pip help 
install")


We ran into this on the Oslo stable branches too. Instead of trying to 
migrate everything, we just tweaked tox_install.sh to avoid the problem: 
https://github.com/openstack/oslo.concurrency/commit/a009e7c86901473ac2273cb9ba604dc2a6b579d3




Both of those branches still use tox_install.sh [4][5]. Master, 
stable/rocky, and stable/queens do not, which passed fine. It was 
suggested that we backport patches to the failing branches that remove 
tox_install.sh (similar to [6]). I've attempted to do this for 
python-keystoneclient, keystonemiddleware, and keystoneauth.


The keystonemiddleware patches specifically are hitting a weird case, 
where they either fail tests due to issues installing keystonemiddleware 
itself, or pass tests and fail the requirements check. I'm guessing 
(because I don't really fully understand the whole issue yet) this is 
because keystonemiddleware has an optional dependency for tests and 
somehow the installation process worked with tox_install.sh and doesn't 
work with the new way we do things with pip and zuul.


I've attempted to remove tox_install.sh using several approaches with 
keystonemiddleware master [7]. None of which passed both unit tests and 
the requirements check.


I'm wondering if anyone has a definitive summary or context on 
tox_install.sh and removing it cleanly for cases like 
keystonemiddleware. Additionally, is anyone else noticing issues like 
this with their stable branches?


[0] https://governance.openstack.org/tc/goals/stein/python3-first.html
[1] https://review.openstack.org/#/c/597685/
[2] https://review.openstack.org/#/c/597679/
[3] 
http://logs.openstack.org/85/597685/1/check/build-openstack-sphinx-docs/4f817dd/job-output.txt.gz#_2018-08-29_20_49_17_877448
[4] 
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/pike
[5] 
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/ocata

[6] https://review.openstack.org/#/c/524828/3
[7] https://review.openstack.org/#/c/599003/


__
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] [oslo] PTG Schedule

2018-09-04 Thread Ben Nemec


Hi,

I've added some tentative times to the planning etherpad[1]. This is all 
subject to change but I wanted to get something out there for people to 
look at. If you have other project responsibilities that day please let 
me know if anything conflicts. As you can see we have a fair amount of 
flexibility in our timing.


And of course if you have any last-minute topic additions feel free to 
make those as well.


1: https://etherpad.openstack.org/p/oslo-stein-ptg-planning

-Ben

__
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] [goals][upgrade-checkers] Week R-31 update

2018-09-04 Thread Ben Nemec

Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo PTG 
schedule for this but figured I should check if it's something we even 
want to pursue.


On 09/04/2018 04:29 PM, Matt Riedemann wrote:

Just a few updates this week.

1. The story is now populated with a task per project that may have 
something to complete for this goal [1]. PTLs, or their liaison(s), 
should assign the task for their project to whomever is going to work on 
the goal. The goal document in governance is being updated with the 
appropriate links to storyboard [2].


2. While populating the story and determining which projects to omit 
(like infra, docs, QA were obvious), I left in the deployment projects 
but those likely can/should opt-out of this goal for Stein since the 
goal is more focused on service projects like keystone/cinder/glance. I 
have pushed a docs updated to the goal with respect to deployment 
projects [3]. For deployment projects that don't plan on doing anything 
with this goal, feel free to just invalidate the task in storyboard for 
your project.


3. I have a developer/contributor reference docs patch up for review in 
nova [4] which is hopefully written generically enough that it can be 
consumed by and used as a guide for other projects implementing these 
upgrade checks.


4. I've proposed an amendment to the completion criteria for the goal 
[5] saying that projects with the "supports-upgrade" tag should 
integrate the checks from their project with their upgrade CI testing 
job. That could be grenade or some other upgrade testing framework, but 
it stands to reason that a project which claims to support upgrades and 
has automated checks for upgrades, should be running those in their CI.


Let me know if there are any questions. There will also be some time 
during a PTG lunch-and-learn session where I'll go over this goal at a 
high level, so feel free to ask questions during or after that at the 
PTG as well.


[1] https://storyboard.openstack.org/#!/story/2003657
[2] https://review.openstack.org/#/c/599759/
[3] https://review.openstack.org/#/c/599835/
[4] https://review.openstack.org/#/c/596902/
[5] https://review.openstack.org/#/c/599849/



__
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] Bumping eventlet to 0.24.1

2018-08-31 Thread Ben Nemec

Just a heads up that for oslo.service we're going to need 
https://review.openstack.org/#/c/598384 and 
https://review.openstack.org/#/c/599032/1 for eventlet 0.24.1 
compatibility. There aren't any functional issues as far as I can tell, 
but some unit tests were broken by new behavior.


On 08/23/2018 09:50 AM, Matthew Thode wrote:

This is your warning, if you have concerns please comment in
https://review.openstack.org/589382 .  cross tests pass, so that's a
good sign... atm this is only for stein.



__
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] [oslo] No meeting next two weeks

2018-08-28 Thread Ben Nemec

Next week is a US holiday so a lot of the team will be off, and the week 
after is the PTG.  If you have anything to discuss in the meantime feel 
free to contact us in #openstack-oslo or here on the list.


-Ben

__
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] fluentd logging status

2018-08-24 Thread Ben Nemec




On 08/24/2018 04:17 AM, Juan Badia Payno wrote:
Recently, I did a little test regarding fluentd logging on the gates 
master[1], queens[2], pike [3]. I don't like the status of it, I'm still 
working on them, but basically there are quite a lot of misconfigured 
logs and some services that they are not configured at all.


I think we need to put some effort on the logging. The purpose of this 
email is to point out that we need to do a little effort on the task.


First of all, I think we need to enable fluentd on all the scenarios, as 
it is on the tests [1][2][3] commented on the beginning of the email. 
Once everything is ok and some automatic test regarding logging is done 
they can be disabled.


I'd love not to create a new bug for every misconfigured/unconfigured 
service, but if requested to grab more attention on it, I will open it.


The plan I have in mind is something like:
  * Make an initial picture of what the fluentd/log status is (from pike 
upwards).

  * Fix all misconfigured services. (designate,...)


For the record, Designate in TripleO is not considered production-ready 
at this time.  There are a few other issues that need to be resolved 
too.  I'll add this to my todo list though.



  * Add the non-configured services. (manila,...)
  * Add an automated check to find a possible unconfigured/misconfigured 
problem.


This would be good.  I copy-pasted the log config from another service 
but had no idea whether it was correct (apparently it wasn't :-).




Any comments, doubts or questions are welcome

Cheers,
Juan

[1] https://review.openstack.org/594836
[2] https://review.openstack.org/594838
[3] https://review.openstack.org/594840



__
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] [oslo] UUID sentinel needs a home

2018-08-23 Thread Ben Nemec




On 08/23/2018 12:25 PM, Doug Hellmann wrote:

Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500:

Do you mean an actual fixture, that would be used like:

  class MyTestCase(testtools.TestCase):
  def setUp(self):
  self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids

  def test_foo(self):
  do_a_thing_with(self.uuids.foo)

?

That's... okay I guess, but the refactoring necessary to cut over to it
will now entail adding 'self.' to every reference. Is there any way
around that?


That is what I had envisioned, yes.  In the absence of a global,
which we do not want, what other API would you propose?


If we put it in oslotest instead, would the global still be a problem? 
Especially since mock has already established a pattern for this 
functionality?


__
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] [barbican][oslo][release][requirements] FFE request for castellan

2018-08-21 Thread Ben Nemec

Because castellan is in global-requirements, we need an FFE from 
requirements too.  Can someone from the requirements team respond to the 
review?  Thanks.


On 08/16/2018 04:34 PM, Ben Nemec wrote:
The backport has merged and I've proposed the release here: 
https://review.openstack.org/592746


On 08/15/2018 11:58 AM, Ade Lee wrote:

Done.

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

Thanks,
Ade

On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote:


On 08/14/2018 01:56 PM, Sean McGinnis wrote:

On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the
following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break
anyone.

The castellan vault plugin is used behind barbican in the
barbican-
vault plugin.  We'd like to get this change into Rocky so that
we can
release Barbican with complete functionality on this backend
(along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a
function that
previously raised a NotImplemented exception.  However, with it
being so
late in the cycle I think we need the release team's input on
whether this
is possible.  Most of the release FFE's I've seen have been for
critical
bugs, not actual new features.  I've added that tag to this
thread so
hopefully they can weigh in.



As far as releases go, this should be fine. If this doesn't affect
any other
projects and would just be a late merging feature, as long as the
castellan
team has considered the risk of adding code so late and is
comfortable with
that, this is OK.

Castellan follows the cycle-with-intermediary release model, so the
final Rocky
release just needs to be done by next Thursday. I do see the
stable/rocky
branch has already been created for this repo, so it would need to
merge to
master first (technically stein), then get cherry-picked to
stable/rocky.


Okay, sounds good.  It's already merged to master so we're good
there.

Ade, can you get the backport proposed?

_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
cribe
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 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] [barbican][oslo][release] FFE request for castellan

2018-08-16 Thread Ben Nemec

The backport has merged and I've proposed the release here: 
https://review.openstack.org/592746


On 08/15/2018 11:58 AM, Ade Lee wrote:

Done.

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

Thanks,
Ade

On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote:


On 08/14/2018 01:56 PM, Sean McGinnis wrote:

On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the
following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break
anyone.

The castellan vault plugin is used behind barbican in the
barbican-
vault plugin.  We'd like to get this change into Rocky so that
we can
release Barbican with complete functionality on this backend
(along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a
function that
previously raised a NotImplemented exception.  However, with it
being so
late in the cycle I think we need the release team's input on
whether this
is possible.  Most of the release FFE's I've seen have been for
critical
bugs, not actual new features.  I've added that tag to this
thread so
hopefully they can weigh in.



As far as releases go, this should be fine. If this doesn't affect
any other
projects and would just be a late merging feature, as long as the
castellan
team has considered the risk of adding code so late and is
comfortable with
that, this is OK.

Castellan follows the cycle-with-intermediary release model, so the
final Rocky
release just needs to be done by next Thursday. I do see the
stable/rocky
branch has already been created for this repo, so it would need to
merge to
master first (technically stein), then get cherry-picked to
stable/rocky.


Okay, sounds good.  It's already merged to master so we're good
there.

Ade, can you get the backport proposed?

_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
cribe
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 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] [puppet] migrating to storyboard

2018-08-16 Thread Ben Nemec

Is there any plan to have a session where the current and future users 
of storyboard can get together and discuss how it's going?

On 08/16/2018 02:47 PM, Jay S Bryant wrote:

Hey,

Well, the attachments are one of the things holding us up along with 
reduced participation in the project and a number of other challenges.  
Getting the time to prepare for the move has been difficult.

I am planning to take some time before the PTG to look at how Ironic has 
been using Storyboard and take this forward to the team at the PTG to 
try and spur the process along.

Jay Bryant - (jungleboyj)

On 8/16/2018 2:22 PM, Kendall Nelson wrote:

Hey :)

Yes, I know attachments are important to a few projects. They are on 
our todo list and we plan to talk about how to implement them at the 
upcoming PTG[1].

Unfortunately, we have had other things that are taking priority over 
attachments. We would really love to migrate you all, but if 
attachments is what is really blocking you and there is no other 
workable solution, I'm more than willing to review patches if you want 
to help out to move things along a little faster :)

-Kendall Nelson (diablo_rojo)

[1]https://etherpad.openstack.org/p/sb-stein-ptg-planning

On Wed, Aug 15, 2018 at 1:49 PM Jay S Bryant > wrote:

On 8/15/2018 11:43 AM, Chris Friesen wrote:
> On 08/14/2018 10:33 AM, Tobias Urdin wrote:
>
>> My goal is that we will be able to swap to Storyboard during the
>> Stein cycle but
>> considering that we have a low activity on
>> bugs my opinion is that we could do this swap very easily anything
>> soon as long
>> as everybody is in favor of it.
>>
>> Please let me know what you think about moving to Storyboard?
>
> Not a puppet dev, but am currently using Storyboard.
>
> One of the things we've run into is that there is no way to
attach log
> files for bug reports to a story.  There's an open story on this[1]
> but it's not assigned to anyone.
>
> Chris
>
>
> [1] https://storyboard.openstack.org/#!/story/2003071

>
Cinder is planning on holding on any migration, like Manila, until
the
file attachment issue is resolved.

Jay
>
__

>
> 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 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] [oslo] Proposing Zane Bitter as oslo.service core

2018-08-15 Thread Ben Nemec

Since there were no objections, I've added Zane to the oslo.service core 
team.  Thanks and welcome, Zane!


On 08/03/2018 11:58 AM, Ben Nemec wrote:

Hi,

Zane has been doing some good work in oslo.service recently and I would 
like to add him to the core team.  I know he's got a lot on his plate 
already, but he has taken the time to propose and review patches in 
oslo.service and has demonstrated an understanding of the code.


Please respond with +1 or any concerns you may have.  Thanks.

-Ben

__
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] [barbican][oslo][release] FFE request for castellan

2018-08-15 Thread Ben Nemec




On 08/14/2018 01:56 PM, Sean McGinnis wrote:

On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break anyone.

The castellan vault plugin is used behind barbican in the barbican-
vault plugin.  We'd like to get this change into Rocky so that we can
release Barbican with complete functionality on this backend (along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a function that
previously raised a NotImplemented exception.  However, with it being so
late in the cycle I think we need the release team's input on whether this
is possible.  Most of the release FFE's I've seen have been for critical
bugs, not actual new features.  I've added that tag to this thread so
hopefully they can weigh in.



As far as releases go, this should be fine. If this doesn't affect any other
projects and would just be a late merging feature, as long as the castellan
team has considered the risk of adding code so late and is comfortable with
that, this is OK.

Castellan follows the cycle-with-intermediary release model, so the final Rocky
release just needs to be done by next Thursday. I do see the stable/rocky
branch has already been created for this repo, so it would need to merge to
master first (technically stein), then get cherry-picked to stable/rocky.


Okay, sounds good.  It's already merged to master so we're good there.

Ade, can you get the backport proposed?

__
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] Reminder about the weekly Cinder meeting ...

2018-08-14 Thread Ben Nemec


Okay, thanks.  There's no Sigyn in openstack-oslo so I think we're good. :-)

On 08/14/2018 10:37 AM, Jay S Bryant wrote:

Ben,

Don't fully understand why it was kicking me.  I guess one of the 
behaviors that is considered suspicious is trying to message a bunch of 
nicks at once.  I had tried reducing the number of people in my ping but 
it still kicked me and so I decided to not risk it again.


Sounds like the moral of the story is if sigyn is in the channel, be 
careful.  :-)


Jay


On 8/13/2018 4:06 PM, Ben Nemec wrote:



On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 
16:00 UTC.  I bring this up as I can no longer send the courtesy 
pings without being kicked from IRC.  So, if you wish to join the 
meeting please add a reminder to your calendar of choice.


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.




__
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] [barbican][oslo][release] FFE request for castellan

2018-08-14 Thread Ben Nemec




On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break anyone.

The castellan vault plugin is used behind barbican in the barbican-
vault plugin.  We'd like to get this change into Rocky so that we can
release Barbican with complete functionality on this backend (along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a function 
that previously raised a NotImplemented exception.  However, with it 
being so late in the cycle I think we need the release team's input on 
whether this is possible.  Most of the release FFE's I've seen have been 
for critical bugs, not actual new features.  I've added that tag to this 
thread so hopefully they can weigh in.


__
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] proposing Moisés Guimarães for oslo.config core

2018-08-13 Thread Ben Nemec




On 08/08/2018 08:18 AM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

Doug


Normally I would have added moguimar to the oslo-config-core team
today, after a week's wait. Funny story, though. There is no
oslo-config-core team.

oslo.config is one of a few of our libraries that we never set up with a
separate review team. It is managed by oslo-core. We could set up a new
review team for that library, but after giving it some thought I
realized that *most* of the libraries are fairly stable, our team is
pretty small, and Moisés is a good guy so maybe we don't need to worry
about that.

I spoke with Moisés, and he agreed to be part of the larger core team.
He pointed out that the next phase of the driver work is going to happen
in castellan, so it would be useful to have another reviewer there. And
I'm sure we can trust him to be careful with reviews in other repos
until he learns his way around.

So, I would like to amend my original proposal and suggest that we add
Moisés to the oslo-core team.

Please indicate support with +1 or present any concerns you have. I
apologize for the confusion on my part.


I'm good with this reasoning, so +1 from me.

__
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] Reminder about the weekly Cinder meeting ...

2018-08-13 Thread Ben Nemec




On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 
UTC.  I bring this up as I can no longer send the courtesy pings without 
being kicked from IRC.  So, if you wish to join the meeting please add a 
reminder to your calendar of choice.


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.


__
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] [oslo] Proposing Zane Bitter as oslo.service core

2018-08-03 Thread Ben Nemec


Hi,

Zane has been doing some good work in oslo.service recently and I would 
like to add him to the core team.  I know he's got a lot on his plate 
already, but he has taken the time to propose and review patches in 
oslo.service and has demonstrated an understanding of the code.


Please respond with +1 or any concerns you may have.  Thanks.

-Ben

__
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] How to debug no valid host failures with placement

2018-08-02 Thread Ben Nemec




On 08/01/2018 06:05 PM, Matt Riedemann wrote:

On 8/1/2018 3:55 PM, Ben Nemec wrote:
I changed disk_allocation_ratio to 2.0 in the config file and it had 
no effect on the existing resource provider.  I assume that is because 
I had initially deployed with it unset, so I got 1.0, and when I later 
wanted to change it the provider already existed with the default value. 


Yeah I think so, unless the inventory changes we don't mess with 
changing the allocation ratio.


That makes sense.  It would be nice if it were more explicitly stated in 
the option help, but I guess Jay's spec below would obsolete that 
behavior so maybe it's better to just pursue that.





  So in the past I could do the following:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler and/or nova-compute

Now it seems like I need to do:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler, nova-compute, and nova-placement (or some 
subset of those?)


Restarting the placement service wouldn't have any effect here.


Wouldn't I need to restart it if I wanted new resource providers to use 
the new default?




3) Use osc-placement to fix up the ratios on any existing resource 
providers


Yeah that's what you'd need to do in this case.

I believe Jay Pipes might have somewhere between 3 and 10 specs for the 
allocation ratio / nova conf / placement inventory / aggregates problems 
floating around, so he's probably best to weigh in here. Like: 
https://review.openstack.org/#/c/552105/




__
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] [oslo] PTL on PTO, no meeting next week

2018-08-02 Thread Ben Nemec

I'm out next week and I'm told Monday is a bank holiday in some places, 
so we're going to skip the Oslo meeting for August 6th.  Of course if 
you have issues you don't have to wait for a meeting to ask.  The Oslo 
team is pretty much always around in #openstack-oslo.


I should be back the following week so we'll resume the normal meeting 
schedule then.


-Ben

__
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] How to debug no valid host failures with placement

2018-08-01 Thread Ben Nemec




On 08/01/2018 02:22 PM, Matt Riedemann wrote:

On 8/1/2018 12:06 PM, Ben Nemec wrote:
To close the loop on the problem I was having, it looks like the 
allocation_ratio config opts are now just defaults, and if you want to 
change ratios after the initial deployment you need to do so with the 
client.


You mean how 
https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio 
defaults to 0.0 and that's used in the ResourceTracker to set the 
inventory?


https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/compute/resource_tracker.py#L120 



That should get defaulted to 1.0 if you didn't change the config option:

https://github.com/openstack/nova/blob/31e6e715e00571925b1163950ea028bdade60d76/nova/objects/compute_node.py#L207 



If you wanted 2.0, then you should set the disk_allocation_ratio config 
option to 2.0 on that host - I don't think that is a behavior change is it?


I changed disk_allocation_ratio to 2.0 in the config file and it had no 
effect on the existing resource provider.  I assume that is because I 
had initially deployed with it unset, so I got 1.0, and when I later 
wanted to change it the provider already existed with the default value. 
 So in the past I could do the following:


1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler and/or nova-compute

Now it seems like I need to do:

1) Change disk_allocation_ratio in nova.conf
2) Restart nova-scheduler, nova-compute, and nova-placement (or some 
subset of those?)

3) Use osc-placement to fix up the ratios on any existing resource providers





I will note that it's a little annoying that you have to specify all 
of the fields on this call.


I agree with you. The "openstack resource provider inventory set" 
command is similar in that it is a total overwrite of all inventory for 
the provider:


https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-set 



So if you want to add just one inventory class (or change one) then you 
have to repeat all of the existing inventory if you don't want to lose 
that. And I don't think "openstack resource provider inventory class 
set" lets you add new inventory classes, it only lets you update 
existing ones.


So we probably need something like an --amend option on both commands 
which are sort of meta commands to retain everything else about the 
inventory for the provider but only changes the fields that the user 
specifies.


We've mostly just been trying to get out *any* CLI support at all, so 
what is there now is basic functionality, warts and all, and we can 
iterate over time to make the tools more usable.


To track this, I've created an RFE bug in launchpad:

https://bugs.launchpad.net/placement-osc-plugin/+bug/1784932



Cool, thanks.

__
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] How to debug no valid host failures with placement

2018-08-01 Thread Ben Nemec




On 08/01/2018 11:23 AM, Chris Friesen wrote:

On 08/01/2018 09:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources 
of your cloud.

This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10

And you can explore placement state with other commands like openstack 
resource
provider list, resource provider inventory list, resource provider 
usage show.




Unfortunately this doesn't help figure out what the missing resources 
were *at the time of the failure*.


The fact that there is no real way to get the equivalent of the old 
detailed scheduler logs is a known shortcoming in placement, and will 
become more of a problem if/when we move more complicated things like 
CPU pinning, hugepages, and NUMA-awareness into placement.


The problem is that getting useful logs out of placement would require 
significant development work.


Yeah, in my case I only had one compute node so it was obvious what the 
problem was, but if I had a scheduling failure on a busy cloud with 
hundreds of nodes I don't see how you would ever track it down.  Maybe 
we need to have a discussion with operators about how often they do 
post-mortem debugging of this sort of thing?


__
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] How to debug no valid host failures with placement

2018-08-01 Thread Ben Nemec

Aha, thanks!  That explains why I couldn't find any client commands for 
placement before.


To close the loop on the problem I was having, it looks like the 
allocation_ratio config opts are now just defaults, and if you want to 
change ratios after the initial deployment you need to do so with the 
client.  This is what I used:


openstack resource provider inventory class set 
f931b646-ce18-43f6-8c95-bd3ba82fb9a8 DISK_GB --total 111 
--allocation_ratio 2.0


I will note that it's a little annoying that you have to specify all of 
the fields on this call.  To change allocation_ratio I also had to pass 
total even though I didn't want to change total.  MEMORY_MB is even 
worse because not passing max_unit and reserved as well will cause those 
to revert to max_int and 0, which I can't imagine ever being right.  I 
guess this isn't something that users would do a lot, but it could be a 
nasty surprise if they tried to update something, had reserved go to 
zero but didn't notice, and suddenly find they're overcommitting more 
than they intended.


Anyway, thanks again for the help.  I hope this thread will be useful to 
other people who are learning placement too.


-Ben

On 08/01/2018 10:58 AM, Andrey Volkov wrote:

Hi,

It seems you need first to check what placement knows about resources of 
your cloud.

This can be done either with REST API [1] or with osc-placement [2].
For osc-placement you could use:

pip install osc-placement
openstack allocation candidate list --resource DISK_GB=20 --resource 
MEMORY_MB=2048 --resource VCPU=1 --os-placement-api-version 1.10


And you can explore placement state with other commands like openstack 
resource provider list, resource provider inventory list, resource 
provider usage show.


[1] https://developer.openstack.org/api-ref/placement/
[2] https://docs.openstack.org/osc-placement/latest/index.html

On Wed, Aug 1, 2018 at 6:16 PM Ben Nemec <mailto:openst...@nemebean.com>> wrote:


Hi,

I'm having an issue with no valid host errors when starting instances
and I'm struggling to figure out why.  I thought the problem was disk
space, but I changed the disk_allocation_ratio and I'm still getting no
valid host.  The host does have plenty of disk space free, so that
shouldn't be a problem.

However, I'm not even sure it's disk that's causing the failures
because
I can't find any information in the logs about why the no valid host is
happening.  All I get from the scheduler is:

"Got no allocation candidates from the Placement API. This may be a
temporary occurrence as compute nodes start up and begin reporting
inventory to the Placement service."

While in placement I see:

2018-08-01 15:02:22.062 20 DEBUG
nova.api.openstack.placement.requestlog
[req-0a830ce9-e2af-413a-86cb-b47ae129b676
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
default default] Starting request: 10.2.2.201 "GET

/placement/allocation_candidates?limit=1000=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"

__call__

/usr/lib/python2.7/site-packages/nova/api/openstack/placement/requestlog.py:38
2018-08-01 15:02:22.103 20 INFO nova.api.openstack.placement.requestlog
[req-0a830ce9-e2af-413a-86cb-b47ae129b676
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e -
default default] 10.2.2.201 "GET

/placement/allocation_candidates?limit=1000=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1"

status: 200 len: 53 microversion: 1.25

Basically it just seems to be logging that it got a request, but
there's
no information about what it did with that request.

So where do I go from here?  Is there somewhere else I can look to see
why placement returned no candidates?

Thanks.

-Ben

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.


__
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] How to debug no valid host failures with placement

2018-08-01 Thread Ben Nemec


Hi,

I'm having an issue with no valid host errors when starting instances 
and I'm struggling to figure out why.  I thought the problem was disk 
space, but I changed the disk_allocation_ratio and I'm still getting no 
valid host.  The host does have plenty of disk space free, so that 
shouldn't be a problem.


However, I'm not even sure it's disk that's causing the failures because 
I can't find any information in the logs about why the no valid host is 
happening.  All I get from the scheduler is:


"Got no allocation candidates from the Placement API. This may be a 
temporary occurrence as compute nodes start up and begin reporting 
inventory to the Placement service."


While in placement I see:

2018-08-01 15:02:22.062 20 DEBUG nova.api.openstack.placement.requestlog 
[req-0a830ce9-e2af-413a-86cb-b47ae129b676 
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e - 
default default] Starting request: 10.2.2.201 "GET 
/placement/allocation_candidates?limit=1000=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1" 
__call__ 
/usr/lib/python2.7/site-packages/nova/api/openstack/placement/requestlog.py:38
2018-08-01 15:02:22.103 20 INFO nova.api.openstack.placement.requestlog 
[req-0a830ce9-e2af-413a-86cb-b47ae129b676 
fc44fe5cefef43f4b921b9123c95e694 b07e6dc2e6284b00ac7070aa3457c15e - 
default default] 10.2.2.201 "GET 
/placement/allocation_candidates?limit=1000=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A1" 
status: 200 len: 53 microversion: 1.25


Basically it just seems to be logging that it got a request, but there's 
no information about what it did with that request.


So where do I go from here?  Is there somewhere else I can look to see 
why placement returned no candidates?


Thanks.

-Ben

__
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] proposing Moisés Guimarães for oslo.config core

2018-08-01 Thread Ben Nemec


+1

On 08/01/2018 08:27 AM, Doug Hellmann wrote:

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

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 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][ci][metrics] Stucked in the middle of work because of RDO CI

2018-08-01 Thread Ben Nemec




On 07/31/2018 04:51 PM, Wesley Hayutin wrote:



On Tue, Jul 31, 2018 at 7:41 AM Sagi Shnaidman > wrote:


Hi, Martin

I see master OVB jobs are passing now [1], please recheck.

[1] http://cistatus.tripleo.org/


Things have improved and I see a lot of jobs passing however at the same 
time I see too many jobs failing due to node_failures.  We are tracking 
the data from [1].  Certainly the issue is NOT ideal for development and 
we need to remain focused on improving the situation.


I assume you're aware, but just to update the thread it looks like the 
OVB jobs are failing at a 50%+ rate again today (mostly unknown failures 
according to the tracking app).  Even with only two jobs that means your 
odds of getting them both to pass are pretty bad.




Thanks

[1] https://softwarefactory-project.io/zuul/api/tenant/rdoproject.org/builds



On Tue, Jul 31, 2018 at 12:24 PM, Martin Magr mailto:mm...@redhat.com>> wrote:

Greetings guys,

   it is pretty obvious that RDO CI jobs in TripleO projects are
broken [0]. Once Zuul CI jobs will pass would it be possible to
have AMQP/collectd patches ([1],[2],[3]) merged please even
though the negative result of RDO CI jobs? Half of the patches
for this feature is merged and the other half is stucked in this
situation, were nobody reviews these patches, because there is
red -1. Those patches passed Zuul jobs several times already and
were manually tested too.

Thanks in advance for consideration of this situation,
Martin

[0]

https://trello.com/c/hkvfxAdX/667-cixtripleoci-rdo-software-factory-3rd-party-jobs-failing-due-to-instance-nodefailure
[1] https://review.openstack.org/#/c/578749
[2] https://review.openstack.org/#/c/576057/
[3] https://review.openstack.org/#/c/572312/

-- 
Martin Mágr

Senior Software Engineer
Red Hat Czech


__
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




-- 
Best regards

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

--

Wes Hayutin

Associate MANAGER

Red Hat



w hayu...@redhat.com 
  T: +1919 4232509     IRC: 
weshay





Viewmycalendar and check my availability for meetings HERE 




__
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] [release] Github release tarballs broken

2018-07-30 Thread Ben Nemec




On 07/30/2018 02:04 PM, Sean McGinnis wrote:

On Mon, Jul 30, 2018 at 12:02:50PM -0500, Ben Nemec wrote:

According to https://bugs.launchpad.net/pbr/+bug/1742809 our github release
tarballs don't actually work.  It seems to be a github-specific issue
because I was unable to reproduce the problem with a tarball from
releases.openstack.org.

My best guess is that github's release process differs from ours and doesn't
work with our projects.  I see a couple of options for fixing that.  Either
we figure out how to make Github's release process DTRT for our projects, or
we figure out a way to override Github's release artifacts with our own.
I'm not familiar enough with this to know which is a better (or even
possible) option, so I'm sending this to solicit help.

Thanks.

-Ben



 From what I understand, GitHub will provide zip and tar.gz links for all source
whenever a tag is applied. It is a very basic operation and does not have any
kind of logic for correctly packaging whatever that deliverable is.

They even just label the links as "Source code".

I am not sure if there is any way to disable this behavior. One option I see is
we could link in the tag notes to the official tarballs.openstack.org location.
We could also potentially look at using the GitHub API to upload a copy of
those to the GitHub release page. But there's always a mirroring delay, and
GitHub really is just a mirror of our git repos, so using this as a
distribution point really isn't what we want.


Yeah, I talked a bit more about this with Monty on IRC, and it turns out 
there is already an RFE for Github to hide releases that were 
auto-generated from tags: 
https://github.community/t5/How-to-use-Git-and-GitHub/Tag-without-release/m-p/7906


Apparently from the github side "releases" already aren't created unless 
the project does so explicitly, but they show all tags on the release 
tab anyway so the user-visible difference is pretty much nil.  We 
decided to table this until we find out if Github is going to fix it for 
us.  It doesn't make sense to do a bunch of work and then turn around 
and not need it because Github rationalized their UI while we were 
trying to work around it.


__
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] [release] Github release tarballs broken

2018-07-30 Thread Ben Nemec

According to https://bugs.launchpad.net/pbr/+bug/1742809 our github 
release tarballs don't actually work.  It seems to be a github-specific 
issue because I was unable to reproduce the problem with a tarball from 
releases.openstack.org.


My best guess is that github's release process differs from ours and 
doesn't work with our projects.  I see a couple of options for fixing 
that.  Either we figure out how to make Github's release process DTRT 
for our projects, or we figure out a way to override Github's release 
artifacts with our own.  I'm not familiar enough with this to know which 
is a better (or even possible) option, so I'm sending this to solicit help.


Thanks.

-Ben

__
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] [oslo] PTL candidacy

2018-07-30 Thread Ben Nemec

You can find my statement at 
https://review.openstack.org/#/c/587096/1/candidates/stein/Oslo/openstack%2540nemebean.com


That's certainly not an exhaustive list of what I plan to do next cycle, 
but given the size of our team I thought my time was better spent doing 
those things than writing a flowery campaign speech that nobody would 
ever read. ;-)


-Ben

__
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] Setting swift as glance backend

2018-07-26 Thread Ben Nemec

It looks like Glance defaults to Swift, so you shouldn't need to do 
anything: 
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/glance-api.yaml#L96


On 07/26/2018 12:41 AM, Samuel Monderer wrote:

Hi,

I would like to deploy a small overcloud with just one controller and 
one compute for testing.

I want to use swift as the glance backend.
How do I configure the overcloud templates?

Samuel


__
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] [tripleo] Editable environments with resource registry entries

2018-07-25 Thread Ben Nemec


Hi,

This came up recently on my review to add an environment to enable 
Designate in a TripleO deployment.  It needs to set both resource 
registry entries and some user-configurable parameters, which means 
users need to make a copy of it that they can edit.  However, if the 
file moves then the relative paths will break.


The suggestion for Designate was to split the environment into one part 
that contains registry entries and one that contains parameters.  This 
way the file users edit doesn't have any paths in it.  So far so good.


Then as I was writing docs[1] on how to use it I was reminded that we 
have other environments that use this pattern.  In this case, 
specifically the ips-from-pool* (like [2]) files.  I don't know if there 
are others.


So do we need to rework all of those environments too, or is there 
another option?


Thanks.

-Ben

1: https://review.openstack.org/585833
2: 
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/ips-from-pool.yaml


__
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] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec




On 07/20/2018 02:06 PM, Emilien Macchi wrote:



On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec <mailto:openst...@nemebean.com>> wrote:


Okay, based on a private conversation this is coming off as way more
troll-ish than I intended.  I don't understand where this work is
going,
but I don't really need to so I'll step back from the discussion.
Apologies for any offense.


No offense here, Ben. In fact I hope we can still continue to have a 
productive discussion here.


I'm speaking on my own view now, and I'm happy to be wrong and learn but 
I wanted to explore how far we can bring the work around standalone 
architecture. If it was worth exploring making it "multi-node" somehow, 
what would be our technical challenges and more than anything else: what 
use-case we would enable.


I'm actually quite happy to see that people already looked at some of 
these challenges before (see what Giulio / James / Steve H. already 
worked on), so I guess it makes sense to continue the investigation.
We are not making any decision right now in what API we plan to use. The 
current production architecture is still undercloud + overcloud, and our 
day 2 operations are done by Mistral/Heat for now but as we transition 
more to Ansible I think we wanted to explore more options.


I hope this little background helped.


Yeah, I realize now that I invented some requirements that you didn't 
actually state in your original email.  Slap on the wrist to me for poor 
reading comprehension. :-)


__
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] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec




On 07/20/2018 02:53 PM, James Slagle wrote:

On Thu, Jul 19, 2018 at 7:13 PM, Ben Nemec  wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:


Today I played a little bit with Standalone deployment [1] to deploy a
single OpenStack cloud without the need of an undercloud and overcloud.
The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can
extend with remote compute nodes on the edge when needed."

We still have a bunch of things to figure out so it works out of the box,
but so far I was able to build something that worked, and I found useful to
share it early to gather some feedback:
https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream documentation
and re-using 100% what is in TripleO today. The only thing I'm doing is to
change the environment and the roles for the remote compute node.
I plan to work on cleaning the manual steps that I had to do to make it
working, like hardcoding some hiera parameters and figure out how to
override ServiceNetmap.

Anyway, feel free to test / ask questions / provide feedback.



What is the benefit of doing this over just using deployed server to install
a remote server from the central management system?  You need to have
connectivity back to the central location anyway.  Won't this become
unwieldy with a large number of edge nodes?  I thought we told people not to
use Packstack for multi-node deployments for exactly that reason.

I guess my concern is that eliminating the undercloud makes sense for
single-node PoC's and development work, but for what sounds like a
production workload I feel like you're cutting off your nose to spite your
face.  In the interest of saving one VM's worth of resources, now all of
your day 2 operations have no built-in orchestration.  Every time you want
to change a configuration it's "copy new script to system, ssh to system,
run script, repeat for all systems.  So maybe this is a backdoor way to make
Ansible our API? ;-)


I believe Emilien was looking at this POC in part because of some
input from me, so I will attempt to address your questions
constructively.

What you're looking at here is exactly a POC. The deployment is a POC
using the experimental standalone code. I think the use case as
presented by Emilien is something worth considering:


"As an operator, I want to deploy a single node OpenStack, that I can
extend with remote compute nodes on the edge when needed."


I wouldn't interpret that to mean much of anything around eliminating
the undercloud, other than what is stated for the use case. I feel
that  jumping to eliminating the undercloud would be an over
simplification. The goal of the POC isn't packstack parity, or even
necessarily a packstack like architecture.


Okay, this was the main disconnect for me.  I got the impression from 
the discussion up til now that eliminating the undercloud was part of 
the requirements.  Looking back at Emilien's original email I think I 
conflated the standalone PoC description with the use-case description. 
My bad.




One of the goals is to see if we can deploy separate disconnected
stacks for Control and Compute. The standalone work happens to be a
good way to test out some of the work around that. The use case was
written to help describe and provide an overall picture of what is
going on with this specific POC, with a focus towards the edge use
case.

You make some points about centralized management and connectivity
back to the central location. Those are the exact sorts of things we
are thinking about when we consider how we will address edge
deployments. If you haven't had a chance yet, check out the Edge
Computing whitepaper from the foundation:

https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf

Particularly the challenges outlined around management and deployment
tooling. For lack of anything better I'm calling these the 3 D's:
- Decentralized
- Distributed
- Disconnected

How can TripleO address any of these?

For Decentralized, I'd like to see better separation between the
planning and application of the deployment in TripleO. TripleO has had
the concept of a plan for quite a while, and we've been using it very
effectively for our deployment, but it is somewhat hidden from the
operator. It's not entirely clear to the user that there is any
separation between the plan and the stack, and what benefit there even
is in the plan.


+1.  I was disappointed that we didn't adopt the plan as more of a 
first-class citizen for cli deployments after it was implemented.




I'd like to address some of that through API improvements around plan
management and making the plan the top level thing being managed
instead of a deployment. We're already moving in this direction with
config-download and a lot of the changes we've made during Queens.

For better or worse, some other tools like Terraform call t

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec

Okay, based on a private conversation this is coming off as way more 
troll-ish than I intended.  I don't understand where this work is going, 
but I don't really need to so I'll step back from the discussion. 
Apologies for any offense.


-Ben

On 07/20/2018 12:20 PM, Ben Nemec wrote:



On 07/20/2018 01:18 AM, Bogdan Dobrelya wrote:

On 7/20/18 2:13 AM, Ben Nemec wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy 
a single OpenStack cloud without the need of an undercloud and 
overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I 
can extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I 
found useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream 
documentation and re-using 100% what is in TripleO today. The only 
thing I'm doing is to change the environment and the roles for the 
remote compute node.
I plan to work on cleaning the manual steps that I had to do to make 
it working, like hardcoding some hiera parameters and figure out how 
to override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need 
to have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly 
that reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, 
now all of your day 2 operations have no built-in orchestration.  
Every time you want to change a configuration it's "copy new script 
to system, ssh to system, run script, repeat for all systems.  So 
maybe this is a backdoor way to make Ansible our API? ;-)


Ansible may orchestrate that for day 2. Deploying Heat stacks is 
already made ephemeral for standalone/underclouds so only thing you'll 
need for day 2 is ansible really. Hence, the need of undercloud 
shrinks into having an ansible control node, like your laptop, to 
control all clouds via inventory.


So I guess the answer to my last question is yes. :-)

Are we planning to reimplement all of our API workflows in Ansible or 
are users expected to do that themselves?


__
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] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec




On 07/20/2018 01:18 AM, Bogdan Dobrelya wrote:

On 7/20/18 2:13 AM, Ben Nemec wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy 
a single OpenStack cloud without the need of an undercloud and 
overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can 
extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I 
found useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream 
documentation and re-using 100% what is in TripleO today. The only 
thing I'm doing is to change the environment and the roles for the 
remote compute node.
I plan to work on cleaning the manual steps that I had to do to make 
it working, like hardcoding some hiera parameters and figure out how 
to override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need 
to have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly 
that reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, now 
all of your day 2 operations have no built-in orchestration.  Every 
time you want to change a configuration it's "copy new script to 
system, ssh to system, run script, repeat for all systems.  So maybe 
this is a backdoor way to make Ansible our API? ;-)


Ansible may orchestrate that for day 2. Deploying Heat stacks is already 
made ephemeral for standalone/underclouds so only thing you'll need for 
day 2 is ansible really. Hence, the need of undercloud shrinks into 
having an ansible control node, like your laptop, to control all clouds 
via inventory.


So I guess the answer to my last question is yes. :-)

Are we planning to reimplement all of our API workflows in Ansible or 
are users expected to do that themselves?


__
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] prototype with standalone mode and remote edge compute nodes

2018-07-19 Thread Ben Nemec




On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy a 
single OpenStack cloud without the need of an undercloud and overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can 
extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I found 
useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream documentation 
and re-using 100% what is in TripleO today. The only thing I'm doing is 
to change the environment and the roles for the remote compute node.
I plan to work on cleaning the manual steps that I had to do to make it 
working, like hardcoding some hiera parameters and figure out how to 
override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need to 
have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly that 
reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, now 
all of your day 2 operations have no built-in orchestration.  Every time 
you want to change a configuration it's "copy new script to system, ssh 
to system, run script, repeat for all systems.  So maybe this is a 
backdoor way to make Ansible our API? ;-)


__
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] Disk space requirement - any way to lower it a little?

2018-07-19 Thread Ben Nemec

On 07/19/2018 11:55 AM, Paul Belanger wrote:

On Thu, Jul 19, 2018 at 05:30:27PM +0200, Cédric Jeanneret wrote:

Hello,

While trying to get a new validation¹ in the undercloud preflight
checks, I hit an (not so) unexpected issue with the CI:
it doesn't provide flavors with the minimal requirements, at least
regarding the disk space.

A quick-fix is to disable the validations in the CI - Wes has already
pushed a patch for that in the upstream CI:
https://review.openstack.org/#/c/583275/
We can consider this as a quick'n'temporary fix².

The issue is on the RDO CI: apparently, they provide instances with
"only" 55G of free space, making the checks fail:
https://logs.rdoproject.org/17/582917/3/openstack-check/legacy-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master/c9cf398/logs/undercloud/home/zuul/undercloud_install.log.txt.gz#_2018-07-17_10_23_46

So, the question is: would it be possible to lower the requirment to,
let's say, 50G? Where does that 60G³ come from?

Thanks for your help/feedback.

Cheers,

¹ https://review.openstack.org/#/c/582917/

² as you might know, there's a BP for a unified validation framework,
and it will allow to get injected configuration in CI env in order to
lower the requirements if necessary:
https://blueprints.launchpad.net/tripleo/+spec/validation-framework

³
http://tripleo.org/install/environments/baremetal.html#minimum-system-requirements

Keep in mind, upstream we don't really have control over partitions of nodes, in
some case it is a single, other multiple. I'd suggest looking more at:

https://docs.openstack.org/infra/manual/testing.html

And this isn't just a testing thing. As I mentioned in the previous
thread, real-world users often use separate partitions for some data
(logs, for example). Looking at the existing validation[1] I don't know
that it would handle multiple partitions sufficiently well to turn it on
by default. It's only checking /var and /, and I've seen much more
complex partition layouts than that.

1:
https://github.com/openstack/tripleo-validations/blob/master/validations/tasks/disk_space.yaml

As for downstream RDO, the same is going to apply once we start adding more
cloud providers. I would look to see if you actually need that much space for
deployments, and make try to mock the testing of that logic.

It's also worth noting that what we can get away with in ci is not
necessarily appropriate for production. Being able to run a
short-lived, single-use deployment in 50 GB doesn't mean that you could
realistically run that on a long-lived production cloud. Log and
database storage tends to increase over time. There should be a ceiling
to how large that all grows if rotation and db cleanup is configured
correctly, but that ceiling is much higher than anything ci is ever
going to hit.

Anecdotally, I bumped my development flavor disk space to >50 GB because
I ran out of space when I built containers locally. I don't know if
that's something we expect users to be doing, but it is definitely
possible to exhaust 50 GB in a short period of time.

Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)

2018-07-17 Thread Ben Nemec




On 07/17/2018 03:00 PM, Michele Baldessari wrote:

Hi Jarda,

thanks for these perspectives, this is very valuable!

On Tue, Jul 17, 2018 at 06:01:21PM +0200, Jaromir Coufal wrote:

Not rooting for any approach here, just want to add a bit of factors which 
might play a role when deciding which way to go:

A) Performance matters, we should be improving simplicity and speed of
deployments rather than making it heavier. If the deployment time and
resource consumption is not significantly higher, I think it doesn’t
cause an issue. But if there is a significant difference between PCMK
and keepalived architecture, we would need to review that.


+1 Should the pcmk take substantially more time then I agree, not worth
defaulting to it. Worth also exploring how we could tweak things
to make the setup of the cluster a bit faster (on a single node we can
lower certain wait operations) but full agreement on this point.


B) Containerization of PCMK plans - eventually we would like to run
the whole undercloud/overcloud on minimal OS in containers to keep
improving the operations on the nodes (updates/upgrades/etc). If
because PCMK we would be forever stuck on BM, it would be a bit of
pita. As Michele said, maybe we can re-visit this.


So I briefly discussed this in our team, and while it could be
re-explored, we need to be very careful about the tradeoffs.
This would be another layer which would bring quite a bit of complexity
(pcs commands would have to be run inside a container, speed tradeoffs,
more limited possibilities when it comes to upgrading/updating, etc.)


C) Unification of undercloud/overcloud is important for us, so +1 to
whichever method is being used in both. But what I know, HA folks went
to keepalived since it is simpler so would be good to keep in sync
(and good we have their presence here actually) :)


Right so to be honest, the choice of keepalived on the undercloud for
VIP predates me and I was not directly involved, so I lack the exact
background for that choice (and I could not quickly reconstruct it from git
history). But I think it is/was a reasonable choice for what it needs
doing, although I probably would have picked just configuring the extra
VIPs on the interfaces and have one service less to care about.
+1 in general on the unification, with the caveats that have been
discussed so far.


The only reason there even are vips on the undercloud is that we wanted 
ssl support, and we implemented that through the same haproxy puppet 
manifest as the overcloud, which required vips.  Keepalived happened to 
be what it was using to provide vips at the time, so that's what we 
ended up with.  There wasn't a conscious decision to use keepalived over 
anything else.





D) Undercloud HA is a nice have which I think we want to get to one
day, but it is not in as big demand as for example edge deployments,
BM provisioning with pure OS, or multiple envs managed by single
undercloud. So even though undercloud HA is important, it won’t bring
operators as many benefits as the previously mentioned improvements.
Let’s keep it in mind when we are considering the amount of work
needed for it.


+100


I'm still of the opinion that undercloud HA shouldn't be a thing.   It 
brings with it a whole host of problems and I have yet to hear a 
realistic use case that actually requires it.  We were quite careful to 
make sure that the overcloud can continue to run indefinitely without 
the undercloud during downtime.


*Maybe* sometime in the future when those other features are implemented 
it will make more sense, but I don't think it does right now.





E) One of the use-cases we want to take into account is expanind a
single-node deployment (all-in-one) to 3 node HA controller. I think
it is important when evaluating PCMK/keepalived


Right, so to be able to implement this, there is no way around having
pacemaker (at least today until we have galera and rabbit).
It still does not mean we have to default to it, but if you want to
scale beyond one node, then there is no other option atm.


HTH


It did, thanks!

Michele

— Jarda


On Jul 17, 2018, at 05:04, Emilien Macchi  wrote:

Thanks everyone for the feedback, I've made a quick PoC:
https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-default

And I'm currently doing local testing. I'll publish results when progress is 
made, but I've made it so we have the choice to enable pacemaker (disabled by 
default), where keepalived would remain the default for now.

On Mon, Jul 16, 2018 at 2:07 PM Michele Baldessari  wrote:
On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote:

On Mon, Jul 16, 2018 at 11:42 AM Dan Prince  wrote:
[...]


The biggest downside IMO is the fact that our Pacemaker integration is
not containerized. Nor are there any plans to finish the
containerization of it. Pacemaker has to currently run on baremetal
and this makes the installation of it for small dev/test setups a lot
less desirable. It can launch containers

[openstack-dev] [oslo][all] Heads up for the new oslo.policy release

2018-07-17 Thread Ben Nemec

I just wanted to send a quick note about the recent oslo.policy release 
which may impact some projects.  Some new functionality was added that 
allows a context object to be passed in to the enforcer directly, but as 
part of that we added a check that the type of the object passed in was 
valid for use.  This caused an issue in Glance's unit tests because they 
were mocking the context object and a Mock object didn't pass the type 
check.  This was fixed in [1], but if any other projects have a similar 
pattern in their unit tests it is possible it may affect them as well.


If you do run into any issues with this, please contact the Oslo team in 
#openstack-oslo or with the [oslo] tag on the mailing list so we can 
help resolve them.  Thanks.


-Ben

1: https://review.openstack.org/#/c/582995/

__
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] Reminder about Oslo feature freeze

2018-07-17 Thread Ben Nemec

And we are now officially in feature freeze for Oslo libraries.  Only 
bugfixes should be going in at this point.


I will note that the config drivers work is still in the process of 
merging because some of the later patches in that series got hung up on 
a unit test bug.  I'm holding off on doing final feature releases until 
that has all merged.


-Ben

On 07/05/2018 11:46 AM, Ben Nemec wrote:

Hi,

This is just a reminder that Oslo observes feature freeze earlier than 
other projects so those projects have time to implement any new features 
from Oslo.  Per the policy[1] we freeze one week before the non-client 
library feature freeze, which is coming in two weeks.  Therefore, we 
have about one week to land new features in Oslo.  Anything that misses 
the deadline will most likely need to wait until Stein.


Feel free to contact the Oslo team with any comments or questions.  Thanks.

-Ben

1: 
http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze.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] Fwd: [TIP] tox release 3.1.1

2018-07-13 Thread Ben Nemec




On 07/12/2018 04:29 PM, Eric Fried wrote:

Here it is for nova.

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


also don't love that immediately bumping the lower bound for tox is
going to be kind of disruptive to a lot of people.


By "kind of disruptive," do you mean:

  $ tox -e blah
  ERROR: MinVersionError: tox version is 1.6, required is at least 3.1.1
  $ sudo pip install --upgrade tox
  
  $ tox -e blah
  


Repeat for every developer on every project that gets updated.  And if 
you installed tox from a distro package then it might not be that simple 
since pip installing over distro packages can get weird.


No, it's not a huge deal, but then neither is the repetition in tox.ini 
so I'd just as soon leave it be for now.  But I'm not going to -1 any 
patches either.




?

Thanks,
efried

On 07/09/2018 03:58 PM, Doug Hellmann wrote:

Excerpts from Ben Nemec's message of 2018-07-09 15:42:02 -0500:


On 07/09/2018 11:16 AM, Eric Fried wrote:

Doug-

 How long til we can start relying on the new behavior in the gate?  I
gots me some basepython to purge...


I want to point out that most projects require a rather old version of
tox, so chances are most people are not staying up to date with the very
latest version.  I don't love the repetition in tox.ini right now, but I
also don't love that immediately bumping the lower bound for tox is
going to be kind of disruptive to a lot of people.

1: http://codesearch.openstack.org/?q=minversion=nope=tox.ini=


Good point. Any patches to clean up the repetition should probably
go ahead and update that minimum version setting, too.

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 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] [oslo] Stein PTG planning etherpad

2018-07-12 Thread Ben Nemec


All the cool kids are doing it, so here's one for Oslo:

https://etherpad.openstack.org/p/oslo-stein-ptg-planning

I've populated it with a few topics that I expect to discuss, but feel 
free to add anything you're interested in.


Thanks.

-Ben

__
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] Fwd: [TIP] tox release 3.1.1

2018-07-09 Thread Ben Nemec




On 07/09/2018 11:16 AM, Eric Fried wrote:

Doug-

How long til we can start relying on the new behavior in the gate?  I
gots me some basepython to purge...


I want to point out that most projects require a rather old version of 
tox, so chances are most people are not staying up to date with the very 
latest version.  I don't love the repetition in tox.ini right now, but I 
also don't love that immediately bumping the lower bound for tox is 
going to be kind of disruptive to a lot of people.


1: http://codesearch.openstack.org/?q=minversion=nope=tox.ini=



-efried

On 07/09/2018 11:03 AM, Doug Hellmann wrote:

Heads-up, there is a new tox release out. 3.1 includes some behavior
changes in the way basepython behaves (thanks, Stephen Finucan!), as
well as other bug fixes.

If you start seeing odd job failures, check your tox version.

Doug

--- Begin forwarded message from toxdevorg ---
From: toxdevorg 
To: testing-in-python , tox-dev 

Date: Mon, 09 Jul 2018 08:45:15 -0700
Subject: [TIP] tox release 3.1.1

The tox team is proud to announce the 3.1.1 bug fix release!

tox aims to automate and standardize testing in Python. It is part of
a larger vision of easing the packaging, testing and release process
of Python software.

For details about the fix(es),please check the CHANGELOG:
https://pypi.org/project/tox/3.1.1/#changelog

We thank all present and past contributors to tox. Have a look at
https://github.com/tox-dev/tox/blob/master/CONTRIBUTORS to see who
contributed.

Happy toxing,
the tox-dev team

--- End forwarded message ---

__
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 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] easily identifying how services are configured

2018-07-06 Thread Ben Nemec


(adding the list back)

On 07/06/2018 12:05 PM, Dan Prince wrote:

On Fri, Jul 6, 2018 at 12:03 PM Ben Nemec  wrote:




On 07/05/2018 01:23 PM, Dan Prince wrote:

On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:


I would almost rather see us organize the directories by service
name/project instead of implementation.

Instead of:

puppet/services/nova-api.yaml
puppet/services/nova-conductor.yaml
docker/services/nova-api.yaml
docker/services/nova-conductor.yaml

We'd have:

services/nova/nova-api-puppet.yaml
services/nova/nova-conductor-puppet.yaml
services/nova/nova-api-docker.yaml
services/nova/nova-conductor-docker.yaml

(or perhaps even another level of directories to indicate
puppet/docker/ansible?)


I'd be open to this but doing changes on this scale is a much larger
developer and user impact than what I was thinking we would be willing
to entertain for the issue that caused me to bring this up (i.e. how to
identify services which get configured by Ansible).

Its also worth noting that many projects keep these sorts of things in
different repos too. Like Kolla fully separates kolla-ansible and
kolla-kubernetes as they are quite divergent. We have been able to
preserve some of our common service architectures but as things move
towards kubernetes we may which to change things structurally a bit
too.


True, but the current directory layout was from back when we intended to
support multiple deployment tools in parallel (originally
tripleo-image-elements and puppet).  Since I think it has become clear
that it's impractical to maintain two different technologies to do
essentially the same thing I'm not sure there's a need for it now.  It's
also worth noting that kolla-kubernetes basically died because there
wasn't enough people to maintain both deployment methods, so we're not
the only ones who have found that to be true.  If/when we move to
kubernetes I would anticipate it going like the initial containers work
did - development for a couple of cycles, then a switch to the new thing
and deprecation of the old thing, then removal of support for the old thing.


Sometimes the old things are a bit longer lived though. And sometimes
the new thing doesn't work out the way you thought they would. Have an
abstraction layer where you can have more than new/old things is
sometimes very useful. I'd had to see us ditch it. Especially since
you can already sort of have the both right now by using the resource
registry files to setup a nice default for everything and gradually
switch to new stuff as your defaults.


I don't know that you lose that ability in either case though.  You can 
still point your resource registry at the -puppet versions of the 
services if you want to do that.  The only thing that changes is the 
location of the files.


Given that, I don't think there's actually a _huge_ difference between 
the two options.  I prefer the flat directory just because as I've been 
working on designate it's mildly annoying to have to navigate two 
separate directory trees to find all the designate-related service 
files, but I realize that's a fairly minor complaint. :-)






That being said, because of the fact that the service yamls are
essentially an API for TripleO because they're referenced in user
resource registries, I'm not sure it's worth the churn to move
everything either.  I think that's going to be an issue either way
though, it's just a question of the scope.  _Something_ is going to move
around no matter how we reorganize so it's a problem that needs to be
addressed anyway.


I feel like renaming every service template in t-h-t as part of
solving my initial concerns around identifying the 'ansible configured
services' is a bit of a sedge hammer though. I like some of the
renaming ideas proposed here too. I'm just not convinced that renaming
*some* templates is the same as restructuring the entire t-h-t
services hierarchy. I'd rather wait and let it happen more naturally I
guess, perhaps when we need to do something more destructive already.


My thought was that either way we're causing people grief because they 
have to update their files, but the big bang approach would mean they do 
it once and then it's done.  Except I realize now that's not true, 
because as more things move to ansible the filenames would continue to 
change.


Which makes me wonder if we should be encoding implementation details 
into the filenames in the first place.  Ideally, the interface would be 
"I want designate-api, so I set OS::TripleO::Services::DesignateApi: 
services/designate-api.yaml".  As a user I probably don't care what 
technology is used to deploy it, I just want it deployed.  Then if/when 
we change our default method, it just gets swapped out seamlessly and 
there's no need for me to change my configuration.


Obviously we'd still need the ability to have method-specific templates 
too, but maybe the default designate-api.yaml could be a symlink to 
whatever we consider the p

Re: [openstack-dev] [TripleO] easily identifying how services are configured

2018-07-06 Thread Ben Nemec




On 07/05/2018 01:23 PM, Dan Prince wrote:

On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:


I would almost rather see us organize the directories by service
name/project instead of implementation.

Instead of:

puppet/services/nova-api.yaml
puppet/services/nova-conductor.yaml
docker/services/nova-api.yaml
docker/services/nova-conductor.yaml

We'd have:

services/nova/nova-api-puppet.yaml
services/nova/nova-conductor-puppet.yaml
services/nova/nova-api-docker.yaml
services/nova/nova-conductor-docker.yaml

(or perhaps even another level of directories to indicate
puppet/docker/ansible?)


I'd be open to this but doing changes on this scale is a much larger
developer and user impact than what I was thinking we would be willing
to entertain for the issue that caused me to bring this up (i.e. how to
identify services which get configured by Ansible).

Its also worth noting that many projects keep these sorts of things in
different repos too. Like Kolla fully separates kolla-ansible and
kolla-kubernetes as they are quite divergent. We have been able to
preserve some of our common service architectures but as things move
towards kubernetes we may which to change things structurally a bit
too.


True, but the current directory layout was from back when we intended to 
support multiple deployment tools in parallel (originally 
tripleo-image-elements and puppet).  Since I think it has become clear 
that it's impractical to maintain two different technologies to do 
essentially the same thing I'm not sure there's a need for it now.  It's 
also worth noting that kolla-kubernetes basically died because there 
wasn't enough people to maintain both deployment methods, so we're not 
the only ones who have found that to be true.  If/when we move to 
kubernetes I would anticipate it going like the initial containers work 
did - development for a couple of cycles, then a switch to the new thing 
and deprecation of the old thing, then removal of support for the old thing.


That being said, because of the fact that the service yamls are 
essentially an API for TripleO because they're referenced in user 
resource registries, I'm not sure it's worth the churn to move 
everything either.  I think that's going to be an issue either way 
though, it's just a question of the scope.  _Something_ is going to move 
around no matter how we reorganize so it's a problem that needs to be 
addressed anyway.


-Ben

__
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] [tc] [all] TC Report 18-26

2018-07-06 Thread Ben Nemec

Red Hat OpenStack is based on RDO.  It's not pretty far from it, it's 
very close.  It's basically productized RDO, and in the interest of 
everyone's sanity we try to keep the downstream patches to a minimum.


In general I would be careful trying to take the distro analogy too far 
though.  The release cycles of the Red Hat Linux distros are very 
different from that of the OpenStack distros.  RDO would be more akin to 
CentOS in terms of how closely related they are, but the relationship is 
inverted.  CentOS is taking the RHEL source (which is based on whatever 
the current Fedora release is when a new major RHEL version gets 
branched) and distributing packages based on it, while RHOS is taking 
the RDO bits and productizing them.  There's no point in having a 
CentOS-like distro that then repackages the RHOS source because you'd 
end up with essentially RDO again.  RDO and RHOS don't diverge the way 
Fedora and RHEL do after they are branched because they're on the same 
release cycle.


So essentially the flow with the Linux distros looks like:

Upstream->Fedora->RHEL->CentOS

Whereas the OpenStack distros are:

Upstream->RDO->RHOS

With RDO serving the purpose of both Fedora and CentOS.

As for TripleO, it's been integrated with RHOS/RDO since Kilo, and I 
believe it has been the recommended way to deploy in production since 
then as well.


-Ben

On 07/05/2018 03:17 PM, Fox, Kevin M wrote:
I use RDO in production. Its pretty far from RedHat OpenStack. though 
its been a while since I tried the TripleO part of RDO. Is it pretty 
well integrated now? Similar to RedHat OpenStack? or is it more Fedora 
like then CentOS like?


Thanks,
Kevin

*From:* Dmitry Tantsur [dtant...@redhat.com]
*Sent:* Thursday, July 05, 2018 11:17 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [tc] [all] TC Report 18-26




On Thu, Jul 5, 2018, 19:31 Fox, Kevin M > wrote:


We're pretty far into a tangent...

/me shrugs. I've done it. It can work.

Some things your right. deploying k8s is more work then deploying
ansible. But what I said depends on context. If your goal is to
deploy k8s/manage k8s then having to learn how to use k8s is not a
big ask. adding a different tool such as ansible is an extra
cognitive dependency. Deploying k8s doesn't need a general solution
to deploying generic base OS's. Just enough OS to deploy K8s and
then deploy everything on top in containers. Deploying a seed k8s
with minikube is pretty trivial. I'm not suggesting a solution here
to provide generic provisioning to every use case in the datacenter.
But enough to get a k8s based cluster up and self hosted enough
where you could launch other provisioning/management tools in that
same cluster, if you need that. It provides a solid base for the
datacenter on which you can easily add the services you need for
dealing with everything.

All of the microservices I mentioned can be wrapped up in a single
helm chart and deployed with a single helm install command.

I don't have permission to release anything at the moment, so I
can't prove anything right now. So, take my advice with a grain of
salt. :)

Switching gears, you said why would users use lfs when they can use
a distro, so why use openstack without a distro. I'd say, today
unless you are paying a lot, there isn't really an equivalent distro
that isn't almost as much effort as lfs when you consider day2 ops.
To compare with Redhat again, we have a RHEL (redhat openstack), and
Rawhide (devstack) but no equivalent of CentOS. Though I think
TripleO has been making progress on this front...


It's RDO what you're looking for (equivalent of centos). TripleO is an 
installer project, not a distribution.



Anyway. This thread is I think 2 tangents away from the original
topic now. If folks are interested in continuing this discussion,
lets open a new thread.

Thanks,
Kevin


From: Dmitry Tantsur [dtant...@redhat.com ]
Sent: Wednesday, July 04, 2018 4:24 AM
To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26

Tried hard to avoid this thread, but this message is so much wrong..

On 07/03/2018 09:48 PM, Fox, Kevin M wrote:
 > I don't dispute trivial, but a self hosting k8s on bare metal is
not incredibly hard. In fact, it is easier then you might think. k8s
is a platform for deploying/managing services. Guess what you need
to provision bare metal? Just a few microservices. A dhcp service.
dhcpd in a daemonset works well. some pxe infrastructure. pixiecore
with a simple http backend works pretty well in practice. a

[openstack-dev] [oslo] Reminder about Oslo feature freeze

2018-07-05 Thread Ben Nemec


Hi,

This is just a reminder that Oslo observes feature freeze earlier than 
other projects so those projects have time to implement any new features 
from Oslo.  Per the policy[1] we freeze one week before the non-client 
library feature freeze, which is coming in two weeks.  Therefore, we 
have about one week to land new features in Oslo.  Anything that misses 
the deadline will most likely need to wait until Stein.


Feel free to contact the Oslo team with any comments or questions.  Thanks.

-Ben

1: 
http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze.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] [ironic] SOFT_REBOOT powers off/on the server

2018-06-25 Thread Ben Nemec

A soft reboot should allow the server to shut down gracefully.  A reset 
wouldn't do that, at least as I understand it.  A reset would be more 
appropriate for a hard reboot, although I see Dmitry had a couple of 
other concerns with implementing it as a reset on the review.


-Ben

On 06/25/2018 05:31 AM, Lenny Berkhovsky wrote:

Hi,

Is there a reason for powering off and on[1] instead of resetting server 
during SOFT_REBOOT?


I have a patchset[2] that resets the server instead of power cycling it.

[1] 
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/ipmitool.py#L820


   elif power_state == states.SOFT_REBOOT:

     _soft_power_off(task, driver_info, timeout=timeout)

     driver_utils.ensure_next_boot_device(task, driver_info)

     _power_on(task, driver_info, timeout=timeout)

[2] https://review.openstack.org/#/c/577748/

Lenny Verkhovsky

( aka lennyb )



__
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] [heat] Need new release of heat-translator library

2018-06-20 Thread Ben Nemec




On 06/20/2018 02:58 AM, Patil, Tushar wrote:

Hi,

Few weeks back, we had proposed a patch [1] to add support for translation of 
placement policies and that patch got merged.

This feature will be consumed by tacker specs [2] which we are planning to 
implement in Rocky release and it's implementation is uploaded in patch [3]. 
Presently, the tests are failing on patch [3] becoz it requires newer version 
of heat-translator library.

Could you please release a new version of heat-translator library so that we 
can complete specs[2] in Rocky timeframe.


Note that you can propose a release to the releases repo[1] and then you 
just need the PTL or release liaison to sign off on it.


1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

__
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] [oslo] Summit onboarding and project update slides

2018-05-30 Thread Ben Nemec


As promised in the sessions, here are the slides that were presented:

https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding

https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update

The font in the onboarding one got a little funny in the conversion, so 
if you want to see the original that is more readable let me know and I 
can send it to you.


-Ben

__
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] Eventlet + SSL + Python 3 = broken monkey patching leading to completely broken glance-api

2018-05-18 Thread Ben Nemec

This is a known problem: 
https://bugs.launchpad.net/oslo.service/+bug/1482633  There have been 
some discussions on what to do about it but I don't think we have a 
definite plan yet.


It also came up in the Python 3 support thread for some more context: 
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130274.html


On 05/18/2018 08:01 AM, Thomas Goirand wrote:

Hi,

It took me nearly a week to figure this out, as I'm not really an expert
in Eventlet, OpenSSL and all, but now I've pin-pointed a big problem.

My tests were around Glance, which I was trying to run over SSL and
Eventlet, though it seems a general issue with SSL + Python 3.

In the normal setup, when I do:
openstack image list

then I get:
Unable to establish connection to https://127.0.0.1:9292/v2/images:
('Connection aborted.', OSError(0, 'Error'))

(more detailed stack dump at the end of this message [1])

Though, with Eventlet 0.20.0, if in
/usr/lib/python3/dist-packages/eventlet/green/ssl.py line 352, I comment
out set_nonblocking(newsock) in the accept() function of the
GreenSSLSocket, then everything works.

Note that:
- This also happens with latest Eventlet 0.23.0
- There's no problem without SSL
- There's no commit on top of 0.23.0 relevant to the issue

The issue has been reported here 2 years ago:
https://github.com/eventlet/eventlet/issues/308

it's marked with "importance-bug" and "need-contributor", but nobody did
anything about it.

I also tried running with libapache2-mod-wsgi-py3, but then I'm hitting
another bug: https://bugs.launchpad.net/glance/+bug/1518431

what's going on is that glanceclient spit out a 411 error complaining
about content lenght. That issue is seen *only* when using Apache and
mod_wsgi.

So, I'm left with no solution here: Glance never works over SSL and
Python 3. Something's really wrong should be fixed. Please help!

This also pinpoints something: our CI is *not* covering the SSL case, or
mod_wsgi, when really, it should. We should be having tests with:
- mod_wsgi
- eventlet
- uwsgi
and all of the above with and without SSL, plus Python 2 and 3, plus
with file or swift backend. That's 24 possibility of problems, which we
should IMO all cover. We don't need to run all tests, but maybe just
make sure that at least the daemon works, which isn't the case at the
moment for most of these use cases. The only setup that works are:
- eventlet with or without SSL, using Python 2
- eventlet without SSL with Python 3
- apache with or without SSL without swift backend

As much as I understand, we're only testing with eventlet with Python 2
and 3 without SSL and file backend. That's 2 setups out of 24... Can
someone works on fixing this?

Cheers,

Thomas Goirand (zigo)

[1]

Unable to establish connection to https://127.0.0.1:9292/v2/images:
('Connection aborted.', OSError(0, 'Error'))
Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line
601, in urlopen
 chunked=chunked)
   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line
346, in _make_request
 self._validate_conn(conn)
   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line
852, in _validate_conn
 conn.connect()
   File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 326,
in connect
 ssl_context=context)
   File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 329,
in ssl_wrap_socket
 return context.wrap_socket(sock, server_hostname=server_hostname)
   File "/usr/lib/python3.5/ssl.py", line 385, in wrap_socket
 _context=self)
   File "/usr/lib/python3.5/ssl.py", line 760, in __init__
 self.do_handshake()
   File "/usr/lib/python3.5/ssl.py", line 996, in do_handshake
 self._sslobj.do_handshake()
   File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
 self._sslobj.do_handshake()
OSError: [Errno 0] Error

__
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] [docs] Automating documentation the tripleo way?

2018-05-16 Thread Ben Nemec




On 05/16/2018 10:39 AM, Petr Kovar wrote:

Hi all,

In the past few years, we've seen several efforts aimed at automating
procedural documentation, mostly centered around the OpenStack
installation guide. This idea to automatically produce and verify
installation steps or similar procedures was mentioned again at the last
Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).

It was brought to my attention that the tripleo team has been working on
automating some of the tripleo deployment procedures, using a Bash script
with included comment lines to supply some RST-formatted narrative, for
example:

https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2

The Bash script can then be converted to RST, e.g.:

https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/

Source Code:

https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs

I really liked this approach and while I don't want to sound like selling
other people's work, I'm wondering if there is still an interest among the
broader OpenStack community in automating documentation like this?


I think it's worth noting that TripleO doesn't even use the generated 
docs.  The main reason is that we tried this back in the 
tripleo-incubator days and it was not the silver bullet for good docs 
that it appears to be on the surface.  As the deployment scripts grow 
features and more complicated logic it becomes increasingly difficult to 
write inline documentation that is readable.  In the end, the 
tripleo-incubator docs had a number of large bash snippets that referred 
to internal variables and such.  It wasn't actually good documentation.


When we moved to instack-undercloud to drive TripleO deployments we also 
moved to a more traditional hand-written docs repo.  Both options have 
their benefits and drawbacks, but neither absolves the development team 
of their responsibility to curate the docs.  IME the inline method 
actually makes it harder to do this because it tightly couples your code 
and docs in a very inflexible way.


/2 cents

-Ben

__
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] [oslo] No meeting next two weeks

2018-05-14 Thread Ben Nemec

As discussed in the meeting this week, we plan to skip the Oslo meeting 
for the next two weeks.  The first is during Summit, and the second is 
the first full day back for many of us so it's unlikely there will be 
much new to talk about.  Meetings will resume as normal after that, and 
if anything comes up in the meantime we can adjust our plans if needed.


Thanks.

-Ben

__
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

1 2 3 4 5 6 7 8 >

1 - 100 of 733 matches

Mail list logo