[openstack-dev] [Nova] On idmapshift deprecation

[Michael Still]

Hi.

I'm working through the process of converting the libvirt driver in Nova to
privsep with the assistance of Tony Breeds. For various reasons, I started
with removing all the calls to the chown binary and am replacing them with
privsep equivalents. You can see this work at:

https://review.openstack.org/#/q/topic:hurrah-for-privsep

The one remaining use of chown in libvirt in that topic is now a tool
called idmapshift, which is used by the lxc container support to rearrange
file ownership for filesystems mapped into containers. The tool is a
separate binary, which the libvirt driver then runs as root.

This binary is relatively easy to replace with python code inside the main
nova binary in a privsep world -- its basically a refactor with low impact.
That would be nice because it means we could stop building and shipping an
extra binary.

However, that binary appears to do a whole bunch of extra things which nova
itself doesn't use.

So... Do we keep carrying a binary that we wouldn't be using because it
might be useful to someone? Do you throw away the unused bits of code and
just refactor the bit we use? Do I bravely run away? If we remove the
binary, do we do some form of deprecation first? Or because its "internal
only" just remove it?

Discuss.

Michael
__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Sean McGinnis]

On Fri, Jul 28, 2017 at 07:39:25PM +, Jeremy Stanley wrote:
> On 2017-07-28 15:32:01 -0400 (-0400), David Desrosiers wrote:
> [...]
> > I am very opposed to removing subsets of docs, including the install guide,
> > after the release goes eol upstream from consumers for exactly that reason.
> > 
> > Watermarking the upstream docs with series and version should reduce or
> > eliminate the need for people to incorrectly submit fixes, patches and PRs
> > for eol releases that the core team can no longer support, but that
> > shouldn't necessitate removal of the installation instructions.
> 
> Perhaps a compromise is to add very visible banners that explicitly
> remind the reader they're looking at installation instructions for
> an outdated version of the software, with a link to see the current
> installation instructions instead? Simply relying on newcomers to
> recognize release series names and inherently know whether they're
> reading the latest version is an issue.
> -- 
> Jeremy Stanley

+1 to this.

I think it would be useful to keep the older docs available, and having
something very visible letting folks know when they come across them
by chance, with pointers to the current info, seems like a good way to
handle things.

Sean

__
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] Proposing TommyLikeHu for Cinder core

[Mike Perez]

On 03:07 Jul 25, Sean McGinnis wrote:
> I am proposing we add TommyLike as a Cinder core.
> 
> DISCLAIMER: We work for the same company.
> 
> I have held back on proposing him for some time because of this conflict. But
> I think from his number of reviews [1] and code contributions [2] it's
> hopefully clear that my motivation does not have anything to do with this.
> 
> TommyLike has consistently done quality code reviews. He has contributed a
> lot of bug fixes and features. And he has been available in the IRC channel
> answering questions and helping out, despite some serious timezone
> challenges.
> 
> I think it would be great to add someone from this region so we can get more
> perspective from the APAC area, as well as having someone around that may
> help as more developers get involved in non-US and non-EU timezones.
> 
> Cinder cores, please respond with your opinion. If no reason is given to do
> otherwise, I will add TommyLike to the core group in one week.
> 
> And absolutely call me out if you see any in bias in my proposal.

+1

-- 
Mike Perez


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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Jeremy Stanley]

On 2017-07-28 15:37:07 -0400 (-0400), David Desrosiers wrote:
[...]
> You could compress the individual files, configure the webserver to send
> the correct encoding (Content-Encoding: gzip or deflate) to the client
> (assuming their browser sends the correct Accept-Encoding header) which can
> then correctly unpack the content for view.
> 
> Lots of ways to shave down the capacity of the data-at-rest on the server.

Agreed, but realistically we're one or two orders of magnitude away
from needing to worry about that at the moment so should focus on
more pressing issues.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Kevin Benton]

Maybe we could just ban search engines from indexing the releases using
robots.txt once they go EOL. That would solve the problem of losing old
information for people that still need it while preventing people stumbling
onto old docs when they search for something.

On Fri, Jul 28, 2017 at 12:39 PM, Jeremy Stanley  wrote:

> On 2017-07-28 15:32:01 -0400 (-0400), David Desrosiers wrote:
> [...]
> > I am very opposed to removing subsets of docs, including the install
> guide,
> > after the release goes eol upstream from consumers for exactly that
> reason.
> >
> > Watermarking the upstream docs with series and version should reduce or
> > eliminate the need for people to incorrectly submit fixes, patches and
> PRs
> > for eol releases that the core team can no longer support, but that
> > shouldn't necessitate removal of the installation instructions.
>
> Perhaps a compromise is to add very visible banners that explicitly
> remind the reader they're looking at installation instructions for
> an outdated version of the software, with a link to see the current
> installation instructions instead? Simply relying on newcomers to
> recognize release series names and inherently know whether they're
> reading the latest version is an issue.
> --
> Jeremy Stanley
>
> __
> 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] [all][ptl][stable][release] stable/pike branches created for most libraries

[Doug Hellmann]

As Thierry mentioned in his countdown email today, the release team has
now created the stable branches for most deliverables with type
"library".

We have 3 exceptions:

1. python-neutronclient had a late release, so I will be branching it
   shortly.
2. python-barbicanclient was skipped until they have a chance to resolve
   the critical bug they are working on.
3. tempest doesn't branch (we should probably reclassify that as
   something other than a library to avoid issues with the automation)

All libraries should have had updates for the .gitreview file in the new
branch, the constraints URL in the tox.ini file, and the reno
configuration (in master, if the project uses reno).

Landing any of the patches in the stable/pike branch will trigger a new
documentation build publishing to docs.o.o/$project/pike.

Please take over any of the bot-created patches that do not pass your
validation jobs and fix them so that they can land as soon as possible.

Doug

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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Jeremy Stanley]

On 2017-07-28 15:32:01 -0400 (-0400), David Desrosiers wrote:
[...]
> I am very opposed to removing subsets of docs, including the install guide,
> after the release goes eol upstream from consumers for exactly that reason.
> 
> Watermarking the upstream docs with series and version should reduce or
> eliminate the need for people to incorrectly submit fixes, patches and PRs
> for eol releases that the core team can no longer support, but that
> shouldn't necessitate removal of the installation instructions.

Perhaps a compromise is to add very visible banners that explicitly
remind the reader they're looking at installation instructions for
an outdated version of the software, with a link to see the current
installation instructions instead? Simply relying on newcomers to
recognize release series names and inherently know whether they're
reading the latest version is an issue.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[David Desrosiers]

On Thu, Jul 27, 2017 at 8:16 PM, Sean McGinnis 
wrote:

> I like this approach. With the size being manageable (large, but
> manageable), I would prefer we leave it until we need to free up
> some of the space


You could compress the individual files, configure the webserver to send
the correct encoding (Content-Encoding: gzip or deflate) to the client
(assuming their browser sends the correct Accept-Encoding header) which can
then correctly unpack the content for view.

Lots of ways to shave down the capacity of the data-at-rest on the server.
__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[David Desrosiers]

On Thu, Jul 27, 2017 at 6:07 PM, Jeremy Stanley  wrote:

> The current solution of not publishing installation guides for EOL
> releases seems like a
> good enough compromise there to me.
>

This then breaks fidelity for those operators who need to either reinstall
their existing environment, which may be based on an eol or LTS supported
version of OpenStack, or for those who need to fully document their
existing, running install.

I am very opposed to removing subsets of docs, including the install guide,
after the release goes eol upstream from consumers for exactly that reason.

Watermarking the upstream docs with series and version should reduce or
eliminate the need for people to incorrectly submit fixes, patches and PRs
for eol releases that the core team can no longer support, but that
shouldn't necessitate removal of the installation instructions.
__
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] [neutron] FFE for net-mtu-enh api extension requested

[Ihar Hrachyshka]

Hi PTL/all,

I would like to request an exception for inclusion of net-mtu-enh API
extension (with ML2 implementation) for Pike.

The patch is ready for review, it includes tempest tests and docs
update. There are several things in the patch that we will need to
follow up in the next release (hence a lot of TODOs), but those are
not because the patch is not complete, but because we need to
accommodate for rolling upgrades of controllers.

The RFE: https://launchpad.net/bugs/1671634
The patch: https://review.openstack.org/#/c/483518/

Best regards,
Ihar

__
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] Cleaning up inactive meetbot channels

[Andreas Jaeger]

A change to remove these channels is now up at
https://review.openstack.org/488544

I'll put this for one week in WIP to give teams the chance to -1 - and
will pop in their channels to tell them about this as well,

Andreas


On 2017-07-19 21:24, Jeremy Stanley wrote:
> For those who are unaware, Freenode doesn't allow any one user to
> /join more than 120 channels concurrently. This has become a
> challenge for some of the community's IRC bots in the past year,
> most recently the "openstack" meetbot (which not only handles
> meetings but also takes care of channel logging to
> eavesdrop.openstack.org and does the nifty bug number resolution
> some people seem to like).
> 
> I have run some rudimentary analysis and come up with the following
> list of channels which have had fewer than 10 lines said by anyone
> besides a bot over the past three months:
> 
> #craton
> #openstack-api
> #openstack-app-catalog
> #openstack-bareon
> #openstack-cloudpulse
> #openstack-community
> #openstack-cue
> #openstack-diversity
> #openstack-gluon
> #openstack-gslb
> #openstack-ko
> #openstack-kubernetes
> #openstack-networking-cisco
> #openstack-neutron-release
> #openstack-opw
> #openstack-pkg
> #openstack-product
> #openstack-python3
> #openstack-quota
> #openstack-rating
> #openstack-solar
> #openstack-swauth
> #openstack-ux
> #openstack-vmware-nsx
> #openstack-zephyr
> 
> I have a feeling many of these are either no longer needed, or what
> little and infrequent conversation they get used for could just as
> easily happen in a general channel like #openstack-dev or #openstack
> or maybe in the more active channel of their parent team for some
> subteams. Who would miss these if we ceased logging/using them? Does
> anyone want to help by asking around to people who might not see
> this thread, maybe by popping into those channels and seeing if any
> of the sleeping denizens awaken and say they still want to keep it
> around?
> 
> Ultimately we should improve our meetbot deployment to support
> sharding channels across multiple bots, but that will take some time
> to implement and needs volunteers willing to work on it. In the
> meantime we're running with the meetbot present in 120 channels and
> have at least one new channel that desires logging and can't get it
> until we whittle that number down.
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Eric K]

Thanks for the suggestion, Jeremy.

I¹ll look into that. Two key pieces will be needed:
1. Know ahead of time what user tempest tests would be run from (should be
determined by job setup?)
2. Have a way to specify in job/devstack to start congress using that user.

On 7/28/17, 6:30 AM, "Jeremy Stanley"  wrote:

>On 2017-07-27 20:37:49 -0700 (-0700), Eric K wrote:
>> A tempest test [1] launches additional instances of Congress using
>> subprocess.popen and tests the coordination between them and the
>>original
>> instance launched by devstack. The problem is, the new instances are
>> launched from the tempest test user rather than the user of the original
>> congress instance devstack created. As a result, the new instances fail
>> for being unable to access the encryption keys created by the original
>> congress instance (600 permission).[2]
>> 
>> Any suggestions for how to workaround this problem? Is it possible to
>> somehow configure the gate job to run tempest tests as SU or as the
>> stackuser that launches the original congress instance?
>[...]
>
>Could you flip this around and create the original instances with
>the tempest user? That seems less likely to violate base assumptions
>about the test environment.
>-- 
>Jeremy Stanley
>
>__
>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] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Eric K]

Thanks for your help and sketch of solution, Andrea!  -Eric

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

Date:  Friday, July 28, 2017 at 9:03 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [tempest][infra][congress] subprocess launched
in tempest test lacks file permission

> 
> 
> On Fri, Jul 28, 2017 at 4:38 AM Eric K  wrote:
>> A tempest test [1] launches additional instances of Congress using
>> subprocess.popen and tests the coordination between them and the original
>> instance launched by devstack. The problem is, the new instances are
>> launched from the tempest test user rather than the user of the original
>> congress instance devstack created. As a result, the new instances fail
>> for being unable to access the encryption keys created by the original
>> congress instance (600 permission).[2]
>> 
>> Any suggestions for how to workaround this problem? Is it possible to
>> somehow configure the gate job to run tempest tests as SU or as the
>> stackuser that launches the original congress instance? Thanks so much!
> 
> Unfortunately we don't have any facility in Tempest to control the user for
> subprocesses since Tempest is meant for API testing only. Starting a
> subprocess within the test sounds a bit outside of the scope of what you
> may want to do in a Tempest test.
>  
> If you want to use Tempest to verify HA type of scenarios you may want
> to move the orchestration bit outside of Tempest - you could have an ansible
> script that manages your services and run Tempest before and after certain
> actions to verify that things are still working.
> 
> If you want tests to run in parallel to things happening to your system you
> can do that but again you will need an external component to orchestrate
> this, and you don't know what kind of tempest test will be running unless
> you use a single long running scenario test designed for this purpose.
> 
> Andrea Frittoli (andreaf)
> 
>> 
>> [1]
>> https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
>> sts/scenario/congress_ha/test_ha.py.disabled#L117
>> > ts/scenario/congress_ha/test_ha.py.disabled#L117>  (currently disabled,
>> trying to re-enable)
>> 
>> [2]
>> http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
>> untu-xenial/607623d/logs/testr_results.html.gz
>> > ntu-xenial/607623d/logs/testr_results.html.gz>  (find: OSError: [Errno 13]
>> Permission denied: '/etc/congress/keys/aes_key¹)
>> 
>> 
>> 
>> __
>> 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] [nova] placement/resource providers update 30

[Jay Pipes]

On 07/28/2017 09:47 AM, Chris Dent wrote:

On Fri, 28 Jul 2017, Chris Dent wrote:


I thought there were going to be some changes to the resource tracker
made overnight, related to ensuring allocations on the source and
destination of a move are managed correctly, but I don't see them yet.
If they get pushed up today can someone followup here with links,
please? Or if it was decided that nothing was required can someone
explain why?


It's in progress and will be attached to this bug:

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


Fix up now: https://review.openstack.org/488510

Best,
-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

Re: [openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Andrea Frittoli]

On Fri, Jul 28, 2017 at 4:38 AM Eric K  wrote:

> A tempest test [1] launches additional instances of Congress using
> subprocess.popen and tests the coordination between them and the original
> instance launched by devstack. The problem is, the new instances are
> launched from the tempest test user rather than the user of the original
> congress instance devstack created. As a result, the new instances fail
> for being unable to access the encryption keys created by the original
> congress instance (600 permission).[2]
>
> Any suggestions for how to workaround this problem? Is it possible to
> somehow configure the gate job to run tempest tests as SU or as the
> stackuser that launches the original congress instance? Thanks so much!
>

Unfortunately we don't have any facility in Tempest to control the user for
subprocesses since Tempest is meant for API testing only. Starting a
subprocess within the test sounds a bit outside of the scope of what you
may want to do in a Tempest test.

If you want to use Tempest to verify HA type of scenarios you may want
to move the orchestration bit outside of Tempest - you could have an ansible
script that manages your services and run Tempest before and after certain
actions to verify that things are still working.

If you want tests to run in parallel to things happening to your system you
can do that but again you will need an external component to orchestrate
this, and you don't know what kind of tempest test will be running unless
you use a single long running scenario test designed for this purpose.

Andrea Frittoli (andreaf)


> [1]
> https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
> sts/scenario/congress_ha/test_ha.py.disabled#L117
> 
> (currently disabled,
> trying to re-enable)
>
> [2]
> http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
> untu-xenial/607623d/logs/testr_results.html.gz
> 
> (find: OSError: [Errno 13]
> Permission denied: '/etc/congress/keys/aes_key¹)
>
>
>
> __
> 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] [release] Release countdown for week R-4, July 28 - Aug 4

[Thierry Carrez]

Welcome to our regular release countdown email!

Development Focus
-

Focus should be on fixing release-critical bugs in order to produce the
first release candidates (for deliverables following the with-milestones
model) or final Pike releases (for deliverables following the
with-intermediary model), with the R-3 week as a target date (August 10).


General Information
---

For deliverables following the cycle-with-milestones model, we are now
past Feature Freeze. The focus should be on determining and fixing
release-critical bugs. At this stage only bugfixes should be approved
for merging in the master branches: feature work should only be
considered if explicitly granted a Feature Freeze exception by the team
PTL (after a public discussion on the mailing-list).

StringFreeze is now in effect, in order to let the I18N team do the
translation work in good conditions. The StringFreeze is currently soft
(allowing exceptions as long as they are discussed on the mailing-list
and deemed worth the effort). It will become a hard StringFreeze on
August 10.

The requirements repository is also frozen, until all
cycle-with-milestones deliverables have produced a RC1 and have their
stable/pike branches.

Note that deliverables that are not tagged for release by the
appropriate deadline will be reviewed to see if they are still active
enough to stay on the official project list.


Actions
---

A few cycle-with-milestones deliverables still haven't requested their
Pike-3 tag (X.0.0.0b3): heat networking-bagpipe networking-bgpvpn
networking-midonet networking-odl networking-ovn networking-sfc
neutron-dynamic-routing neutron-fwaas neutron and sahara. If nothing is
proposed by the end of the day, a tag will be forced at the current
master HEAD in order to mark the Feature Freeze.

stable/pike branches should be created soon for all non-already-branched
libraries. You should expect 2-3 changes to be proposed for each: a
.gitreview update, a reno update (skipped for projects not using reno),
and a tox.ini constraints URL update. Please review those in priority so
that the branch can be functional ASAP.

For cycle-with-intermediary deliverables, release liaisons should
consider releasing their latest version, and creating stable/pike
branches from it ASAP.

For cycle-with-milestones deliverables, release liaisons should wait
until R-3 week to create RC1 (to avoid having an RC2 created quickly
after). Review release notes for any missing information, and start
preparing "prelude" release notes as summaries of the content of the
release so that those are merged before the first release candidate.

For release-independent deliverables, release liaisons should check that
their deliverable file includes all the existing releases, so that they
can be properly accounted for in the releases.openstack.org website;

Finally, if you haven't done so already, remember to file Pike goal
completion information, as explained in:

https://governance.openstack.org/tc/goals/index.html#completing-goals


Upcoming Deadlines & Dates
--

RC1 target deadline (and HardStringFreeze): August 10
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

As usual come find us on #openstack-release IRC channel if you have any
questions or concerns.

-- 
Thierry Carrez (ttx)




__
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] CI Squad Meeting Summary (week 30) - holidays

[Attila Darazs]

If the topics below interest you and you want to contribute to the 
discussion, feel free to join the next meeting:


Time: Thursdays, 14:30-15:30 UTC
Place: https://bluejeans.com/4113567798/

Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

= Discussion topics =

Wes suggested to remove the verbose ansible logging from our CI runs and 
direct people to use ARA instead. This seems like a good solution after 
we get the upstream README file merged where we can explain the changes.


There was also a discussion about having the OVB related repo handled 
upstream instead of Ben's personal github account. Ronelle will start a 
thread about this.


We will need an upstream periodic job that runs tempest on containerized 
overcloud. I added a card to keep track of this[1].


The initramfs modification patches[2] from Sagi need some eyes, please 
review them if you have time.


= Who's working on what? =

This is not a comprehensive status, just highlights.

John is currently working on the 3 node multinode jobs, he already added 
a job in the CI check, but it's not passing yet. Pending a lot of 
changes to be merged for it.


Wes is testing the multinic libvirt runs, they are not passing yet.

Gabriele is fighting with the container promotion jobs on rdocloud, 
using DLRN API. It's a complex goal to achieve.


Sagi was doing a SOVA design meeting, and tried to include the RDO jobs 
in the output of it. Here's the status page if you don't know it[3].


Arx was working on Tempest related issues.

Ronelle did some BMC and devmode OVB fixes, thanks! Probably a lot more, 
but that's what I remember.


Attila is working on DLRN API reporting/promotion on RDO CI for now, 
later on other systems too.


= Announcements =

A heads up: next week a significant portion of the CI Squad will be on 
holiday. Sagi, John and Wes will be on PTO and Ronelle will be on 
meetings. Gabriele and I are still here as cores if you need reviews for 
tripleo-ci or quickstart.


That's it, have a nice weekend.

Best regards,
Attila

[1] 
https://trello.com/c/dvQOn9aK/297-create-an-upstream-tempest-job-that-runs-on-a-containerized-system

[2] https://review.openstack.org/#/q/topic:initramfs
[3] http://cistatus.tripleo.org/

__
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] Request to add neutron-server-[ovn/odl] to the tripleoupstream docker hub

[Numan Siddique]

Hello,

When we build the kolla images using the command [1], it builds
neutron-server-ovn and neutron-server-odl which are not in tripleoupstream
docker hub.

Is it possible to upload them ? I am not sure if it is done manually or a
script does it.
neutron-server-ovn image is required  to have a CI job for OVN docker
services The patches for OVN docker services are still under review and can
be found here [2].

[1] - kolla-build --base centos --type binary --namespace tripleoupstream
--registry 192.168.24.1:8787 --tag latest --template-override
/usr/share/tripleo-common/container-images/tripleo_kolla_template_overrides.j2
--push


[2] - https://review.openstack.org/#/c/468860/
   https://review.openstack.org/#/c/484376/


Thanks
Numan
__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-07-28 13:23:32 +:
> On 2017-07-28 08:34:18 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > I wasn't able to come up with a way to disable the link without
> > triggering a new build. I didn't want us to have to land a patch in each
> > repo as part of marking it EOL, but if we're going to do that to remove
> > the installation guide anyway then maybe we can disable the bug link at
> > the same time.
> 
> Could you have the buglink in the docs go to a centrally-managed,
> pattern-based redirect per series and then change that redirect to
> point them all to a page describing the EOL process later?

Oh, that's an interesting idea. We could do that in the openstack-manuals
repo and generate new redirects when we change the status of the
series there.

Doug

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

Re: [openstack-dev] [Cinder] Requirements for re-adding Gluster support

[Matt Riedemann]

On 7/26/2017 4:16 PM, Eric Harney wrote:

 From a technical point of view there are not a lot of steps involved
here, we can restore the previous gate jobs and driver code and I expect
things would still be in working order.

I can help coordinate these things with the new owner.


Note that the libvirt volume driver would also have to be added back to 
Nova, since we dropped that after Cinder dropped the volume driver.


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

--

Thanks,

Matt

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

Re: [openstack-dev] [nova] placement/resource providers update 30

[Chris Dent]

On Fri, 28 Jul 2017, Chris Dent wrote:


I thought there were going to be some changes to the resource tracker
made overnight, related to ensuring allocations on the source and
destination of a move are managed correctly, but I don't see them yet.
If they get pushed up today can someone followup here with links,
please? Or if it was decided that nothing was required can someone
explain why?


It's in progress and will be attached to this bug:

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

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Jeremy Stanley]

On 2017-07-27 20:37:49 -0700 (-0700), Eric K wrote:
> A tempest test [1] launches additional instances of Congress using
> subprocess.popen and tests the coordination between them and the original
> instance launched by devstack. The problem is, the new instances are
> launched from the tempest test user rather than the user of the original
> congress instance devstack created. As a result, the new instances fail
> for being unable to access the encryption keys created by the original
> congress instance (600 permission).[2]
> 
> Any suggestions for how to workaround this problem? Is it possible to
> somehow configure the gate job to run tempest tests as SU or as the
> stackuser that launches the original congress instance?
[...]

Could you flip this around and create the original instances with
the tempest user? That seems less likely to violate base assumptions
about the test environment.
-- 
Jeremy Stanley

__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Jeremy Stanley]

On 2017-07-28 08:34:18 -0400 (-0400), Doug Hellmann wrote:
[...]
> I wasn't able to come up with a way to disable the link without
> triggering a new build. I didn't want us to have to land a patch in each
> repo as part of marking it EOL, but if we're going to do that to remove
> the installation guide anyway then maybe we can disable the bug link at
> the same time.

Could you have the buglink in the docs go to a centrally-managed,
pattern-based redirect per series and then change that redirect to
point them all to a page describing the EOL process later?
-- 
Jeremy Stanley


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

Re: [openstack-dev] [neutron] Call for help with in-tree tempest scenario test failures

[Sławek Kapłoński]

Hello,

I will try to check QoS tests in this job.

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Jakub Libosvar  w dniu 
> 28.07.2017, o godz. 14:49:
> 
> Hi all,
> 
> as sending out a call for help with our precious jobs was very
> successful last time and we swept all Python 3 functional from Neutron
> pretty fast (kudos the the team!), here comes a new round of failures.
> 
> This time I'm asking for your help  poster here> with gate-tempest-dsvm-neutron-dvr-multinode-scenario
> non-voting job. This job has been part of check queue for a while and is
> very very unstable. Such job covers scenarios like router dvr/ha/legacy
> migrations, qos, trunk and dvr. I went through current failures and
> created an etherpad [1] with categorized failures and logstash queries
> that give you latest failures with given particular tests.
> 
> If you feel like doing troubleshooting and sending fixes for gates,
> please pick one test and write down your name to the test.
> 
> Thanks to all who are willing to participate.
> 
> Have a great weekend.
> Jakub
> 
> 
> [1]
> https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP
__
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] Proposing Bogdan Dobrelya core on TripleO / Containers

[Wesley Hayutin]

On Wed, Jul 26, 2017 at 7:39 AM, Jiří Stránský  wrote:

> On 21.7.2017 16:55, Emilien Macchi wrote:
>
>> Hi,
>>
>> Bogdan (bogdando on IRC) has been very active in Containerization of
>> TripleO and his quality of review has increased over time.
>> I would like to give him core permissions on container work in TripleO.
>> Any feedback is welcome as usual, we'll vote as a team.
>>
>> Thanks,
>>
>
+1


>
>>
> +1
>
>
> __
> 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] [neutron] Call for help with in-tree tempest scenario test failures

[Jakub Libosvar]

Hi all,

as sending out a call for help with our precious jobs was very
successful last time and we swept all Python 3 functional from Neutron
pretty fast (kudos the the team!), here comes a new round of failures.

This time I'm asking for your help  with gate-tempest-dsvm-neutron-dvr-multinode-scenario
non-voting job. This job has been part of check queue for a while and is
very very unstable. Such job covers scenarios like router dvr/ha/legacy
migrations, qos, trunk and dvr. I went through current failures and
created an etherpad [1] with categorized failures and logstash queries
that give you latest failures with given particular tests.

If you feel like doing troubleshooting and sending fixes for gates,
please pick one test and write down your name to the test.

Thanks to all who are willing to participate.

Have a great weekend.
Jakub


[1]
https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures


__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2017-07-28 12:29:29 +0200:
> On 07/28/2017 09:12 AM, Andreas Jaeger wrote:
> > On 2017-07-27 21:40, Doug Hellmann wrote:
> >> [...]
> >> Please encourage everyone there to explore options that require the
> >> least amount of effort. An ideal solution is one we can implement
> >> without heroic efforts or having to recruit an army of contributors.
> > 
> > I agree with the points made in general and want to stress we need
> > something that reduces our efforts.
> > 
> > Two more ideas:
> > 
> > 1) What about enhancing the openstackdocstheme to automatically add a
> > watermark if we publish a stable branch document?
> > Like on https://docs.openstack.org/mitaka/config-reference/ - which also
> > includes a warning that the branch is EOL. What about adding at *start*
> > of a branch a message to the index page like "This is the document for
> > the SERIES release. Please see https://releases.openstack.org/ whether
> > the SERIES release is still supported by the OpenStack community."
> 
> Or we can use a similar approach with repository badges, and include an image 
> with URL like https://releases.openstack.org/is-supported/ocata.png, which 
> will 
> turn red when ocata goes EOL.

Ooo, I like *that*. It lets us generate the updated status badge from a
repo that will always be active and isn't likely to get into a state
where we can't land patches, like some of our older stable branches have
a tendency to do.

Doug

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

Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2017-07-28 09:12:59 +0200:
> On 2017-07-27 21:40, Doug Hellmann wrote:
> > [...]
> > Please encourage everyone there to explore options that require the
> > least amount of effort. An ideal solution is one we can implement
> > without heroic efforts or having to recruit an army of contributors.
> 
> I agree with the points made in general and want to stress we need
> something that reduces our efforts.
> 
> Two more ideas:
> 
> 1) What about enhancing the openstackdocstheme to automatically add a
> watermark if we publish a stable branch document?
> Like on https://docs.openstack.org/mitaka/config-reference/ - which also
> includes a warning that the branch is EOL. What about adding at *start*
> of a branch a message to the index page like "This is the document for
> the SERIES release. Please see https://releases.openstack.org/ whether
> the SERIES release is still supported by the OpenStack community."

I like that. We could add that information to a sidebar or footer on
every page.

> 2) The openstackdocstheme has the report a bug link feature. We can
> disable this. If we EOL docs (so, push a change before we eol them), we
> could remove the setting so that "report a bug" does not work.

I wasn't able to come up with a way to disable the link without
triggering a new build. I didn't want us to have to land a patch in each
repo as part of marking it EOL, but if we're going to do that to remove
the installation guide anyway then maybe we can disable the bug link at
the same time.

Doug

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

Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of ironic integrated within openstack

[Sam Betts (sambetts)]

Information about the ironic deployment process including full workflows can be 
found here: 
https://docs.openstack.org/ironic/latest/user/index.html#deploy-process

Sam

On 28/07/2017, 12:49, "Waines, Greg" 
> wrote:

thanks Sam

What’s the 100,000 foot view of how ironic manages the configuration of a 
baremetal server when it is booting an end-user’s OS image ?

e.g. my best guess so far from looking at ironic documentation


· ironic first deploys the ironic-python-agent to the server

o   ironic-python-agent

§  cleans up the bare metal server, e.g. wiping non-root disks, etc

§  performs inventory of bare metal server’s resources ... disks, NICs, memory, 
cpu, etc., and
reports this back to ironic conductor

· ??? ironic builds up some sort of ‘config drive’  containing 
configuration of the bare metal server based on
ironic launch parameters (flavor, attached networks, etc.) and the discovered 
inventory ???

· ??? ironic conductors DHCP/Boot Server somehow attaches the ‘config 
drive’ to the end-user OS as part of the
network booting ???

· ??? the end-user OS boots ... and thru some standard mechanism uses 
the ‘config drive’ to configure the bare metal
server as desired by ironic ???

Greg.


From: "Sam Betts (sambetts)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, July 24, 2017 at 12:26 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hey Greg,

The Ironic deploy agent images are ramdisk images which include the 
ironic-python-agent https://docs.openstack.org/ironic-python-agent/latest/ 
Which is a tool build by the ironic team and used by ironic to deploy and 
cleanup the baremetal nodes.

The cirros images are just the default images loaded by devstack, I believe by 
default it downloads them from the cirros http://download.cirros-cloud.net

Sam

On 24/07/2017, 17:07, "Waines, Greg" 
> wrote:

Hey Lucas,

Thanks for the pointer to this ironic devstack setup using VMs as baremetal 
servers.
I was able to follow the recipe and get this working and play with ironic.

Of course I’ve got some follow up questions.


Questions on the images:
stack@devstack-ironic:~/devstack$ glance image-list
+--++
| ID   | Name   |
+--++
| 8091821f-a731-409c-a2fe-8986be444937 | cirros-0.3.5-x86_64-disk   |
| 087602b0-32b8-4b0d-823d-e3880614368f | cirros-0.3.5-x86_64-uec|
| 44bda48e-e1a2-4680-9067-ceb5a3b0d150 | cirros-0.3.5-x86_64-uec-kernel |
| 2027800b-4310-4bdc-a003-d4925e116f47 | cirros-0.3.5-x86_64-uec-ramdisk|
| a47a03ca-e504-4f3a-a464-3a4815b89709 | ir-deploy-agent_ipmitool.initramfs |
| 8ae53801-de05-44e6-88d4-0e04738da9b7 | ir-deploy-agent_ipmitool.kernel|
+--++
stack@devstack-ironic:~/devstack$


· so ‘cirros-0.3.5-x86_64-disk’ is the normal typical default cirros 
image for VMs in devstack

· the ironic devstack config/setup must have setup these other images,
QUESTIONS:

o   how were the ‘cirros-0.3.5-x86_64-uec...’ images created ?

§  were they generated from cirros-0.3.5-x86_64-disk image using glance or an 
external tool ?

· e.g. https://docs.openstack.org/diskimage-builder/latest/  ???

§  or

§  were they downloaded from some cirros distribution site ?






o   the ‘ir-deploy-agent_ipmitool.initramfs/kernel’ images

§  what is the role of these images ?

§  (feel free to point me to a description of this in ironic documentation)

§  e.g.

· is it specific to the “test” environment of using VMs as fake bare 
metal servers ?

· is this image generic regardless of specific end-user image (cirros, 
ubuntu, centos, ...) being put on the bare metal server ?

· is this image being used for preparing / cleaning the bare metal 
server (e.g. wiping non-root disks, etc) ...
prior to putting on the end-user image ?


Greg.



From: Lucas Alvares Gomes 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, July 20, 2017 at 10:52 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hi Greg,

> I’m an ironic newbie ...
>

First of, welcome to the community (-:

> where can I find a good / relatively-current (e.g. PIKE) demo of Ironic
> integrated within OpenStack ?
>

I would recommend deploying 

[openstack-dev] [nova] placement/resource providers update 30

[Chris Dent]

Placement Update 30

# What Matters Most

Claims in the scheduler has merged, but first there was much gnashing
of teeth and pulling of hair at the many twisted webs we've weaved in
the scheduler and the resource tracker. While the base functionality
is now in master, it's not certain that it perfectly manages
allocations, especially in the case of move operations. Gibi has
started some tests to explore this. So far they are revealing more
confusion:

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

So it would be fair to say that what matters most right now is
experimenting to see if the scheduler, resource tracker, and placement
service are doing the right things across a broad swathe of scenarios
and where possible writing functional tests that cover those
scenarios.

I thought there were going to be some changes to the resource tracker
made overnight, related to ensuring allocations on the source and
destination of a move are managed correctly, but I don't see them yet.
If they get pushed up today can someone followup here with links,
please? Or if it was decided that nothing was required can someone
explain why?

# What's Changed

Claims in the scheduler has merged:

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

The PlacementFixture now uses wsgi-intercept instead of spawning an
eventlet server. It's hoped this will help limit unpredictability in
tests:

https://review.openstack.org/486237

# Help Wanted

Areas where volunteers are needed.

* General attention to bugs tagged placement:
https://bugs.launchpad.net/nova/+bugs?field.tag=placement

* As stated above: schedule weird stuff, break things, report bugs,
  make functional tests.

# Main Themes

## Claims in the Scheduler

Merged, and now being exposed to the hard cold light of reality.

## Custom Resource Classes for Ironic

The spec is still pending, the work going ahead without it:

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

Updating flavors to include the resource class was merged, but then a
better place to do it was decided, that's here:

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

And a fix for a poorly behaving ironicclient:

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

## Traits

(This section is unchanged since last time, as claims wins the
priority race.)

The concept of traits now exists in the placement service, but
filtering resource providers on traits is in flux. With the advent
of /allocation_candidates as the primary scheduling interface, that
needs to support traits. Work for that is in a stack starting at

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

It's not yet clear if we'll want to support traits at both
/allocation_candidates and /resource_providers. I think we should,
but the immediate need is on /allocation_candidates.

There's some proposed code to get /resource_providers started:

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

## Shared Resource Providers

We decided that for the time being, /resource_providers should not
return shared_providers. A query against it is specifically about
providers that can satisfy the query in themselves.

Given that, there's nothing currently to do with this, other than the
general experimentation mentioned elsewhere. Notably, it's currently
unclear (in the sense that we don't have tests that prove it) whether
the resource tracker is wired up properly to not clobber allocations
the scheduler made which contain shared providers.

## Nested Resource Providers

Work is paused on nested resource providers.

 
https://review.openstack.org/#/q/status:open+topic:bp/nested-resource-providers

## Docs

Lots of placement-related api docs have merged or are in progress:

https://review.openstack.org/#/q/status:open+topic:cd/placement-api-ref

Much of this is ready to go and just looking for a +W or a final +2
and +W.

Setting up the official publishing job for the api ref is on hold
until the content has been migrated to the locations specified by the
docs migration that is currently in progress:


http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html

Some changes have been proposed to document the scheduler's
workflow, including visual aids, starting at:

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

# Other Code/Specs

* https://review.openstack.org/#/c/427200/
 Add a status check for legacy filters in nova-status.

* https://review.openstack.org/#/c/469048/
   Provide more information about installing placement

* https://review.openstack.org/#/c/468928/
   Disambiguate resource provider conflict message

* https://review.openstack.org/#/c/485209/
  gabbi tests for shared custom resource class

* https://review.openstack.org/#/c/483506/
Call _update fewer times in the resource tracker
I'm relatively certain we can't do this one because of the way the
code is structured.

* https://review.openstack.org/#/c/472378/
  A proposed fix to using multiple config locations with the
  placement wsgi 

Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of ironic integrated within openstack

[Waines, Greg]

thanks Sam

What’s the 100,000 foot view of how ironic manages the configuration of a 
baremetal server when it is booting an end-user’s OS image ?

e.g. my best guess so far from looking at ironic documentation


· ironic first deploys the ironic-python-agent to the server

oironic-python-agent

§  cleans up the bare metal server, e.g. wiping non-root disks, etc

§  performs inventory of bare metal server’s resources ... disks, NICs, memory, 
cpu, etc., and
reports this back to ironic conductor

· ??? ironic builds up some sort of ‘config drive’  containing 
configuration of the bare metal server based on
ironic launch parameters (flavor, attached networks, etc.) and the discovered 
inventory ???

· ??? ironic conductors DHCP/Boot Server somehow attaches the ‘config 
drive’ to the end-user OS as part of the
network booting ???

· ??? the end-user OS boots ... and thru some standard mechanism uses 
the ‘config drive’ to configure the bare metal
server as desired by ironic ???

Greg.


From: "Sam Betts (sambetts)" 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, July 24, 2017 at 12:26 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hey Greg,

The Ironic deploy agent images are ramdisk images which include the 
ironic-python-agent https://docs.openstack.org/ironic-python-agent/latest/ 
Which is a tool build by the ironic team and used by ironic to deploy and 
cleanup the baremetal nodes.

The cirros images are just the default images loaded by devstack, I believe by 
default it downloads them from the cirros http://download.cirros-cloud.net

Sam

On 24/07/2017, 17:07, "Waines, Greg" 
> wrote:

Hey Lucas,

Thanks for the pointer to this ironic devstack setup using VMs as baremetal 
servers.
I was able to follow the recipe and get this working and play with ironic.

Of course I’ve got some follow up questions.


Questions on the images:
stack@devstack-ironic:~/devstack$ glance image-list
+--++
| ID   | Name   |
+--++
| 8091821f-a731-409c-a2fe-8986be444937 | cirros-0.3.5-x86_64-disk   |
| 087602b0-32b8-4b0d-823d-e3880614368f | cirros-0.3.5-x86_64-uec|
| 44bda48e-e1a2-4680-9067-ceb5a3b0d150 | cirros-0.3.5-x86_64-uec-kernel |
| 2027800b-4310-4bdc-a003-d4925e116f47 | cirros-0.3.5-x86_64-uec-ramdisk|
| a47a03ca-e504-4f3a-a464-3a4815b89709 | ir-deploy-agent_ipmitool.initramfs |
| 8ae53801-de05-44e6-88d4-0e04738da9b7 | ir-deploy-agent_ipmitool.kernel|
+--++
stack@devstack-ironic:~/devstack$


· so ‘cirros-0.3.5-x86_64-disk’ is the normal typical default cirros 
image for VMs in devstack

· the ironic devstack config/setup must have setup these other images,
QUESTIONS:

o   how were the ‘cirros-0.3.5-x86_64-uec...’ images created ?

§  were they generated from cirros-0.3.5-x86_64-disk image using glance or an 
external tool ?

· e.g. https://docs.openstack.org/diskimage-builder/latest/  ???

§  or

§  were they downloaded from some cirros distribution site ?





o   the ‘ir-deploy-agent_ipmitool.initramfs/kernel’ images

§  what is the role of these images ?

§  (feel free to point me to a description of this in ironic documentation)

§  e.g.

· is it specific to the “test” environment of using VMs as fake bare 
metal servers ?

· is this image generic regardless of specific end-user image (cirros, 
ubuntu, centos, ...) being put on the bare metal server ?

· is this image being used for preparing / cleaning the bare metal 
server (e.g. wiping non-root disks, etc) ...
prior to putting on the end-user image ?


Greg.



From: Lucas Alvares Gomes 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, July 20, 2017 at 10:52 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hi Greg,

> I’m an ironic newbie ...
>

First of, welcome to the community (-:

> where can I find a good / relatively-current (e.g. PIKE) demo of Ironic
> integrated within OpenStack ?
>

I would recommend deploying it with DevStack on a VM and playing with it, you 
can follow this document in order to do it: 
https://docs.openstack.org/ironic/latest/contributor/dev-quickstart.html#deploying-ironic-with-devstack

Hope that helps,
Lucas

Re: [openstack-dev] [magnum] Interface configuration and assumptions for masters/minions launched by magnum

[Waines, Greg]

Thanks for the info Mark.

A dumb question ... can’t seem to find the answer in ironic documentation ...

· I understand how the interface over which the bare metal instance 
network boots/installs gets configured ...
i.e. thru DHCP response/configuration from the ironic conductor dhcp/boot server

· but how would other interfaces, get configured on the bare metal 
server by ironic ?


Greg.

From: Mark Goddard 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, July 28, 2017 at 5:08 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [magnum] Interface configuration and assumptions 
for masters/minions launched by magnum

Hi Greg,

Magnum clusters currently support using only a single network for all 
communication. See the heat templates[1][2] in the drivers.
.
On the bare metal side, currently ironic effectively supports using only a 
single network interface due to a lack of support for physical network 
awareness. This feature[3] will be added in the Pike release, at which point it 
will be possible to create bare metal instances with multiple ports.

[1] 
https://github.com/openstack/magnum/tree/master/magnum/drivers/k8s_fedora_atomic_v1/templates
[2] 
https://github.com/openstack/magnum/tree/master/magnum/drivers/k8s_coreos_v1/templates
[3] https://bugs.launchpad.net/ironic/+bug/1666009

Mark

On 17 July 2017 at 14:27, Waines, Greg 
> wrote:
When MAGNUM launches a VM or Ironic instance for a COE master or minion node, 
with the COE Image,
What is the interface configuration and assumptions for these nodes ?
e.g.
- only a single interface ?
- master and minion communication over that interface ?
- communication to Docker Registry or public Docker Hub over that interface ?
- public communications for containers over that interface ?

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] [Nova] Broken nova-lxd

[Sean Dague]

On 07/28/2017 12:58 AM, Tony Breeds wrote:
> On Fri, Jul 28, 2017 at 10:55:53AM +0800, ChangBo Guo wrote:
>> For the specific case with method "last_bytes",  it's also used  in other
>> projects [1], an alternative solution is that add this method in
>> oslo.utils.fileutils, then consume it from oslo.
>>
>> [1] http://codesearch.openstack.org/?q=last_bytes=nope==
> 
> That does look like a thing that a number of projects could use.
> 
> I'm not certain about the interaction with privsep
> (https://review.openstack.org/472229)  But it is something that worth
> looking at when we open again for queens.

I think it's also really important to set expectations though that the
internals of Nova are the internals of Nova. They are subject to change
and refactoring at any time. Just because a particular module has not
changed in 4 years, doesn't mean it's not being radically changed tomorrow.

Part of the reason to do the hard work of getting a Nova driver upstream
is that you don't have any of these issues, because the Nova team will
prevent things from breaking your driver (or fix it themselves).
Choosing to do a driver out of tree is not recommended and comes with
all of these risks.

-Sean

-- 
Sean Dague
http://dague.net

__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Dmitry Tantsur]

On 07/28/2017 09:12 AM, Andreas Jaeger wrote:

On 2017-07-27 21:40, Doug Hellmann wrote:

[...]
Please encourage everyone there to explore options that require the
least amount of effort. An ideal solution is one we can implement
without heroic efforts or having to recruit an army of contributors.


I agree with the points made in general and want to stress we need
something that reduces our efforts.

Two more ideas:

1) What about enhancing the openstackdocstheme to automatically add a
watermark if we publish a stable branch document?
Like on https://docs.openstack.org/mitaka/config-reference/ - which also
includes a warning that the branch is EOL. What about adding at *start*
of a branch a message to the index page like "This is the document for
the SERIES release. Please see https://releases.openstack.org/ whether
the SERIES release is still supported by the OpenStack community."


Or we can use a similar approach with repository badges, and include an image 
with URL like https://releases.openstack.org/is-supported/ocata.png, which will 
turn red when ocata goes EOL.




2) The openstackdocstheme has the report a bug link feature. We can
disable this. If we EOL docs (so, push a change before we eol them), we
could remove the setting so that "report a bug" does not work.

Andreas




__
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] [horizon] Pike-3, Feature Freeze, and next steps

[Rob Cresswell]

Hey everyone,

We tagged Horizons Pike-3 milestone about 12 hours, so I wanted to quickly run 
through the next steps for the release. At this point, we are in "Feature 
Freeze" and also "Soft String Freeze".

- Feature Freeze - No new features (blueprints or wishlist bugs) can be merged 
without the PTLs approval. We do this so that we can spend the next few weeks 
focusing on finding and fixing bugs in the existing content, to create a stable 
release.

- Soft String Freeze: No user-facing strings should be altered and new string 
additions in general are discouraged, although not blocked entirely. This is to 
give the translation teams some time to start working through the various 
string additions or changes this cycle. For example, when fixing bugs, try to 
reuse the existing error messages rather than alter them.

In 2 weeks time, around the 10th of August, we will tag RC1 (Release Candidate 
1) and move to "Hard String Freeze". At this point, all new strings are 
blocked, while the translation teams do their work. RC1 will become the new 
stable branch ("stable/pike" in this instance) and master branch will open for 
Queens-1.

Any bug fixes for further Pike RC's must then be merged to master and 
backported, as with standard stable policy. Horizon always has an RC2 for 
translation merges. If you'd like to learn more about the deadlines described 
here, https://releases.openstack.org/pike/schedule.html and 
https://docs.openstack.org/project-team-guide/release-management.html are 
useful references.

If you have any questions, please get in touch by replying here or pinging me 
on IRC (robcresswell) in the #openstack-horizon channel.

Rob

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

[openstack-dev] [ironic] PTG planning etherpad

[Dmitry Tantsur]

Hi all!

It was already announced on the meeting, but not on the ML.
Here is our planning etherpad for the PTG:
https://etherpad.openstack.org/p/ironic-queens-ptg

Please check "The Rules" section before proposing a topic. Please also add 
yourself to the list of potential attendees in the bottom.


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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Thierry Carrez]

Andreas Jaeger wrote:
> On 2017-07-27 21:40, Doug Hellmann wrote:
>> [...]
>> Please encourage everyone there to explore options that require the
>> least amount of effort. An ideal solution is one we can implement
>> without heroic efforts or having to recruit an army of contributors.
> 
> I agree with the points made in general and want to stress we need
> something that reduces our efforts.

Yes, agree on the general idea of keeping docs around "forever".

> Two more ideas:
> 
> 1) What about enhancing the openstackdocstheme to automatically add a
> watermark if we publish a stable branch document?
> Like on https://docs.openstack.org/mitaka/config-reference/ - which also
> includes a warning that the branch is EOL. What about adding at *start*
> of a branch a message to the index page like "This is the document for
> the SERIES release. Please see https://releases.openstack.org/ whether
> the SERIES release is still supported by the OpenStack community."

That would be a great way of ensuring that old content is not mistaken
for currently-maintained content, encouraging old users to migrate to
newer / better-supported versions.

> 2) The openstackdocstheme has the report a bug link feature. We can
> disable this. If we EOL docs (so, push a change before we eol them), we
> could remove the setting so that "report a bug" does not work.

Cheers,

-- 
Thierry Carrez (ttx)

__
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] [security][barbican] PTG room sharing

[Luke Hinds]

Hello Barbican Team,

I believe there were some discussions on room sharing between the security
project and barbican team.

We are still keen on this in the security project. How would you like to
work out logistics?

Should we share PTG planning etherpads?

We have 4 days between us, not sure if we will need all four, did you have
anything in mind here? So far I don't expect the security project will need
more then a day at max (if that).

p.s. I am plan to come onto the Barbican irc weekly meeting, if you prefer
to sketch out the details there.

Regards,

Luke
__
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] [magnum] Interface configuration and assumptions for masters/minions launched by magnum

[Mark Goddard]

Hi Greg,

Magnum clusters currently support using only a single network for all
communication. See the heat templates[1][2] in the drivers.
.
On the bare metal side, currently ironic effectively supports using only a
single network interface due to a lack of support for physical network
awareness. This feature[3] will be added in the Pike release, at which
point it will be possible to create bare metal instances with multiple
ports.

[1]
https://github.com/openstack/magnum/tree/master/magnum/drivers/k8s_fedora_atomic_v1/templates
[2]
https://github.com/openstack/magnum/tree/master/magnum/drivers/k8s_coreos_v1/templates
[3] https://bugs.launchpad.net/ironic/+bug/1666009

Mark

On 17 July 2017 at 14:27, Waines, Greg  wrote:

> When MAGNUM launches a VM or Ironic instance for a COE master or minion
> node, with the COE Image,
>
> What is the interface configuration and assumptions for these nodes ?
>
> e.g.
>
> - only a single interface ?
>
> - master and minion communication over that interface ?
>
> - communication to Docker Registry or public Docker Hub over that
> interface ?
>
> - public communications for containers over that interface ?
>
>
>
> 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

[openstack-dev] [tc] Technical Committee Status update, July 28th

[Thierry Carrez]

Hi!

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

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


== Recently-approved changes ==

* Declare plainly the current state of PostgreSQL in OpenStack [1]
* Clean up remaining 'big tent' mention in Licensing requirements [2]
* Queens goals updates: octavia
* New repositories: charm-deployment-guide
* Repositories moved to legacy: api-site, faafo
* Removed repositories: deb-mistral-dashboard

[1] https://review.openstack.org/#/c/427880/
[2] https://review.openstack.org/484607

The big item of the week is the final merge, after almost 6 months of
discussion, of the resolution declaring plainly the state of PostgreSQL
in OpenStack:

https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html

Additionally, the governance repository was tagged in preparation for
the PTL elections, to clearly define the teams and associated
repositories that will be considered.


== Open discussions ==

Flavio's resolution about allowing teams to host meetings in their own
IRC channels is still in the early days of discussion, and is likely to
need a few iterations to iron out:

https://review.openstack.org/485117

Discussion on John's resolution on how decisions should be globally
inclusive is entering the final stages. Please review it if you haven't yet:

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


== Voting in progress ==

The description of what upstream support means seems to be ready for voting:

https://review.openstack.org/440601


== TC member actions for the coming week(s) ==

Flavio still needs to incorporate feedback in the "Drop TC meetings"
proposal and produce a new patchset, or abandon it since we pretty much
already implemented the described change.

Thierry needs to reach out to existing WG to propose them to migrate to
the new SIG format.


== Need for a TC meeting next Tuesday ==

No initiative is currently stuck, so there is no need for a TC meeting
next week.


Cheers!

-- 
Thierry Carrez (ttx)

__
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][networking-sfc] Meters/Statistics for Networking-SFC

[Mohan Kumar]

Hi Rajeev,

The Chain Monitoring is the missing piece in networking-sfc . Vikram and
myself were discussed to introduce "SFC Manager" [1] (basically OAM tool )
few cycle before.

It'll continuously monitor an existing SFC chain,  when any SF VM goes down
or any packet drop. It'll trigger alert and capture corresponding logs .
But we haven't started any implementation on this. Feel free to discuss
with community, IMO  this feature will be great addition to networking-sfc

[1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368


IRC: #networking-sfc
Weekly Meeting:
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Thanks.,
Mohankumar.N







On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanaray...@wipro.com <
rajeev.satyanaray...@wipro.com> wrote:

> Hi Igor/Cathy/Gord,
>
>
>
> Sorry for the delay in replying.
>
>
>
> As part of monitoring the SFC, I think maintaining the details of “Number
> of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due
> to the policies at each Service Function entry/exit points or for the
> entire SFC” would be good to start with. I feel based on some of these
> details, an operator can know how much the virtual switch is loaded and
> take a call on whether to add a new SFC, or it could even help during
> debugging which service function has exactly caused the disruption to SFC.
>
> As a first step, I think it would be good to add meters to provide “number
> of packets/bytes hit due to policy at the ingress and egress of the entire
> SFC” and to realize that, we would need to add specific pollsters. We can
> use neutron_client API to fetch the ingress and egress port details and
> fetch the corresponding flows for those specific ports(also get flow_infos
> from flow_classifier and then use them to dump_flows matching those
> flow_infos) and fetch the no.of packets hit due to policy from them.
>
>
>
> I have just mentioned my idea on this. Can I please know your opinion on
> this and provide your comments?
>
>
>
> Thanks and Regards,
>
> Rajeev.
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Andreas Jaeger]

On 2017-07-27 21:40, Doug Hellmann wrote:
> [...]
> Please encourage everyone there to explore options that require the
> least amount of effort. An ideal solution is one we can implement
> without heroic efforts or having to recruit an army of contributors.

I agree with the points made in general and want to stress we need
something that reduces our efforts.

Two more ideas:

1) What about enhancing the openstackdocstheme to automatically add a
watermark if we publish a stable branch document?
Like on https://docs.openstack.org/mitaka/config-reference/ - which also
includes a warning that the branch is EOL. What about adding at *start*
of a branch a message to the index page like "This is the document for
the SERIES release. Please see https://releases.openstack.org/ whether
the SERIES release is still supported by the OpenStack community."

2) The openstackdocstheme has the report a bug link feature. We can
disable this. If we EOL docs (so, push a change before we eol them), we
could remove the setting so that "report a bug" does not work.

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Andreas Jaeger]

On 2017-07-27 21:40, Doug Hellmann wrote:
> [...]
> Regarding point 2, if we don't have the space to host the content
> indefinitely, then we need to set a fixed, but longer, retention
> period before deleting it.  Several years, at least. In the mean
> time, we could delete builds for intermediate versions (maybe if
> we have 10.0.0, 10.1.0, and 10.1.1 we only need to keep 10.1.1, for
> example).  The point is that there are ways to remove some content
> without removing it all. I know space used to be a real problem
> when we were hosting on CloudSites, but maybe someone from the infra
> team can give us some insight into how significant the space issue
> is today?

since we publish both versions like 10.0.0 and branches like
stable/ocata, i wonder whether we need both, so do we need the tagged
documents if we continously publish to branches?

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Andreas Jaeger]

On 2017-07-28 01:10, Doug Hellmann wrote:
> Excerpts from Doug Hellmann's message of 2017-07-27 19:05:16 -0400:
>> Excerpts from Jeremy Stanley's message of 2017-07-27 22:07:33 +:
>>> On 2017-07-27 15:40:22 -0400 (-0400), Doug Hellmann wrote:
>>> [...]
 Are we over-emphasizing the scale of the discovery problem?

 When I search for how to install a package on Ubuntu (or Red Hat
 or Debian for that matter), I find all sorts of references all over
 the web (including on the sites for those distros) and I have to
 sift through it all to find right command or package name to use
 for my version.  Usually the easiest way to do that is to put the
 version in the search query.

 Are our users incapable of finding the right version of a document
 if we clearly mark the version to which each document applies? Every
 URL now has a release series name or version tag in the path. The
 docs theme inserts the version number into every page as well. Is
 that sufficient to help a reader understand what version the info
 they're view is for?

 That's not to say we shouldn't do some work to make newer docs easy
 to find. If we can modify the sitemap to make them appear earlier
 in search results, that's good. The docs theme allows a project to
 include links to several older versions to switch between them,
 too, so users who land on the "wrong" version can switch. We could
 update that to include branches as well as tags, so that someone
 can easily move to the series they need without knowing the version
 number.
>>> [...]
>>>
>>> The biggest liability is people not realizing there are multiple
>>> "versions" of OpenStack finding an old install doc and using it
>>> because they don't know it's out of date, then seeking support
>>> upstream or just generally contributing to the number of deployments
>>> unnecessarily stuck on obsolete software. The current solution of
>>> not publishing installation guides for EOL releases seems like a
>>> good enough compromise there to me.
>>
>> That content will now live in the project trees. Perhaps part of marking
>> branches in those repos EOL needs to include deleting the install tree
>> from the docs? Now that the docs are in a standard location, that could
>> be part of an EOL script (although it means 2 phases, since we have to
>> land the patch and let the docs rebuild before we remove the branch).
>>
>> We could also update the openstack-manuals tree to not publish links
>> to the install guides (either removing the page or replacing it
>> with a placeholder that explains they should be trying to use a
>> newer version).
>>
>> Doug
>>
> 
> Today we're publishing series-specific (e.g., newton) and
> version-specific (e.g., 10.0.0) docs. I wonder if we should stop
> publishing docs when we tag repositories, and just stick to the
> series? There's no way to go back and update those version-specific
> builds after the fact, so we can't remove the installation guides
> and we can't rebuild them easily if there are security issues with
> the content.

Sorry, send my other email  before reading the whole thread. But reading
this, let me add one more line:

The publishing when tagging was needed for the client libraries that we
only published when tagging. Now we publish *all* docs after each merge.

So, I agree, we can remove the building at tag time,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] PTG Planning

[ChangBo Guo]

Just a reminder,  please add your name and topic in the etherpad if you
will join the discussion abouth Oslo at the PTG.

2017-07-10 21:48 GMT+08:00 ChangBo Guo :

> Hi Oslo folks,
>
> I created a planning etherpad[1] for topics for the next PTG in Denver.
> Please add any topics there,  then we can schedule the topics before the
> PTG.
>
> [1]https://etherpad.openstack.org/p/oslo-ptg-queens
>
> --
> ChangBo Guo(gcb)
>



-- 
ChangBo Guo(gcb)
__
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-ansible][security] To firewalld, or not to firewalld

[Markos Chandras]

On 07/26/2017 05:59 PM, Major Hayden wrote:
> 
> firewalld disadvantages
> ---
> 1) Different distributions have different base rule sets

Also different distributions offer different version of firewalld which
means different behavior and possibly bugs between them. The Ansible
module may not always 'mask' such things we either going to spend time
improving the module or workaround all these in our playbooks. Improving
the upstream module of course is a good thing but I just wanted to point
out the maintenance cost of that.

> 2) Medium/High complexity rules require --direct, which is like using 
> iptables anyway
> 3) It's another daemon to manage/monitor
> 4) We wouldn't be able to use firewalld's "zones" very heavily
> 5) Saving/restoring iptables rules is battle-tested already

I am slightly in favor of iptables (or even nftables) mostly because
they provide a stable known interface which can work for simple and
complex rules. As your 2nd point above correctly states, if we start
using the 'direct' rule feature of firewalld, then we will end up having
a mixture of pure firewalld and iptables rules which may not be the
cleaner option in terms of maintainability.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

__
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