Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Cédric Jeanneret]

On 08/16/2018 12:10 AM, Jason E. Rist wrote:
> On 08/15/2018 03:32 AM, Cédric Jeanneret wrote:
>> Dear Community,
>>
>> As you may know, a move toward Podman as replacement of Docker is starting.
>>
>> One of the issues with podman is the lack of daemon, precisely the lack
>> of a socket allowing to send commands and get a "computer formatted
>> output" (like JSON or YAML or...).
>>
>> In order to work that out, Podman has added support for varlink¹, using
>> the "socket activation" feature in Systemd.
>>
>> On my side, I would like to push forward the integration of varlink in
>> TripleO deployed containers, especially since it will allow the following:
>> # proper interface with Paunch (via python link)
>>
>> # a way to manage containers from within specific containers (think
>> "healthcheck", "monitoring") by mounting the socket as a shared volume
>>
>> # a way to get container statistics (think "metrics")
>>
>> # a way, if needed, to get an ansible module being able to talk to
>> podman (JSON is always better than plain text)
>>
>> # a way to secure the accesses to Podman management (we have to define
>> how varlink talks to Podman, maybe providing dedicated socket with
>> dedicated rights so that we can have dedicated users for specific tasks)
>>
>> That said, I have some questions:
>> ° Does any of you have some experience with varlink and podman interface?
>> ° What do you think about that integration wish?
>> ° Does any of you have concern with this possible addition?
>>
>> Thank you for your feedback and ideas.
>>
>> Have a great day (or evening, or whatever suits the time you're reading
>> this ;))!
>>
>> C.
>>
>>
>> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
>>
>>
>>
>>
>> __
>> 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
>>
> 
> How might this effect upgrades?

What exactly? addition of varlink, or the whole podman thingy? The
question was more about "varlink" than "podman" in fact - I should maybe
have worded things otherwise... ?

> 
> -J
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP 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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Tony Breeds]

On Thu, Aug 16, 2018 at 06:27:39AM +0200, Andreas Jaeger wrote:

> Ocata should be retired by now ;) Let's drop it...

*cough* extended maintenance *cough*  ;P

So we don't need the Ocata docs to be rebuilt with this version?

Yours Tony.


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

Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Andreas Jaeger]

On 2018-08-15 21:28, Tony Breeds wrote:

On Wed, Aug 15, 2018 at 09:10:18AM -0400, Doug Hellmann wrote:

Excerpts from Andreas Jaeger's message of 2018-08-15 09:28:51 +0200:

On 08/15/2018 07:25 AM, Tony Breeds wrote:

On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:


Now that https://review.openstack.org/#/c/591671/ has landed, we need
someone to propose the backports of the constraint updates to all of the
existing stable branches.


Done:
https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements

I'm not entirely convinced such a new release will work on older
branches but I guess that's what CI is for :)


openstackdocsstheme has:
sphinx!=1.6.6,!=1.6.7,>=1.6.2

So, we cannot use it on branches that constraint sphinx to an older version,

Sorry, can't check this right now from where I am,
Andreas


That's a good point. We should give it a try, though. I don't think
pip's constraints resolver takes version specifiers into account, so we
should get the older sphinx and the newer theme. If those do happen to
work together, it should be OK.

If not, we need another solution. We may have to do more work to
backport the theme change into an older version of the library to
make it work in the old branches.


The queens and pike backports have merged but ocata filed with[1]

ContextualVersionConflict: (pbr 1.10.0 
(/home/zuul/src/git.openstack.org/openstack/requirements/.tox/py27-check-uc/lib/python2.7/site-packages),
 Requirement.parse('pbr!=2.1.0,>=2.0.0'), set(['openstackdocstheme']))

So we can't use the rocky release on ocata.  I assume we need to do
something to ensure the docs are generated correctly.


Ocata should be retired by now ;) Let's drop it...

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

[openstack-dev] [release][qa][devstack][all] Pre-Notifiaction for DevStack branch cut for Rocky

[Ghanshyam Mann]

Hi All,

We are in process of cutting the Rocky branch for Devstack[1]. As per 
process[2], we need to wait for minimum set of project (which needed branch) 
used by Devstack to be branched first. As dhellmann mentioned on patch, All of 
the cycle-with-milestone projects are branched and we are waiting to hear go 
ahead from swift team. 

Other than Swift, if any other project needs more work or to be branched before 
we branched devstack, feel free to reply here or on gerrit patch. 

[1] https://review.openstack.org/#/c/591563/ 
[2] https://releases.openstack.org/reference/process.html#rc1

-gmann





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

[Wesley Hayutin]

On Wed, Aug 15, 2018 at 7:13 PM Alex Schultz  wrote:

> Please do not approve or recheck anything until further notice. We've
> got a few issues that have basically broken all the jobs.
>
> https://bugs.launchpad.net/tripleo/+bug/1786764
> https://bugs.launchpad.net/tripleo/+bug/1787226
> https://bugs.launchpad.net/tripleo/+bug/1787244
> https://bugs.launchpad.net/tripleo/+bug/1787268


https://bugs.launchpad.net/tripleo/+bug/1736950

w

>
>
> Thanks,
> -Alex
>
> __
> 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



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar 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

Re: [openstack-dev] [oslo] Proposing Zane Bitter as oslo.service core

[Davanum Srinivas]

Belated +1. Welcome Zane!

On Thu, Aug 16, 2018 at 5:35 AM Ben Nemec  wrote:

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


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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] ansible roles in tripleo

[Jill Rouleau]

On Wed, 2018-08-15 at 13:08 -0600, Alex Schultz wrote:
> On Tue, Aug 14, 2018 at 11:51 AM, Jill Rouleau 
> wrote:
> > 
> > Hey folks,
> > 
> > Like Alex mentioned[0] earlier, we've created a bunch of ansible
> > roles
> > for tripleo specific bits.  The idea is to start putting some basic
> > cookiecutter type things in them to get things started, then move
> > some
> > low-hanging fruit out of tripleo-heat-templates and into the
> > appropriate
> > roles.  For example, docker/services/keystone.yaml could have
> > upgrade_tasks and fast_forward_upgrade_tasks moved into ansible-
> > role-
> > tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and
> > the
> > t-h-t updated to
> > include_role: ansible-role-tripleo-keystone
> >   tasks_from: upgrade.yml
> > without having to modify any puppet or heat directives.
> > 
> Do we have any examples of what the upgrade.yml would be or what type
> of variables (naming conventions or otherwise) which would need to be
> handled as part of this transtion?  I assume we may want to continue
> passing in some variable to indicate the current deployment step.  Is
> there something along these lines that we will be proposing or need to
> handle?  We're already doing something similar with the
> host_prep_tasks for the docker registry[0] but we have a set_fact
> block to pass parameters in.   I'm assuming we'll need to define
> something similar.

The task file would look very much like the task as it exists in t-h-t
today.  For example if we took the FFU task out of
docker/services.keystone.yaml and write that to ansible-role-tripleo-
keystone/tasks/fast_forward_upgrade.yml, and update any necessary vars
(like steps) to be role vars, like tripleo_keystone_step.

Then docker/services.keystone.yaml could be updated like:
fast_forward_upgrade_tasks:
  include_role: 
    name: ansible-role-tripleo-keystone
    tasks_from: fast_forward_upgrade 
  vars:
    tripleo_keystone_step: step|int


- Jill

> 
> Thanks,
> -Alex
> 
> [0] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tre
> e/puppet/services/docker-registry.yaml#n54
> 
> > 
> > This would let us define some patterns for implementing these
> > tripleo
> > roles during Stein while looking at how we can make use of ansible
> > for
> > things like core config.
> > 
> > t-h-t and config-download will still drive the vast majority of
> > playbook
> > creation for now, but for new playbooks (such as for operations
> > tasks)
> > tripleo-ansible[1] would be our project directory.
> > 
> > So in addition to the larger conversation about how deployers can
> > start
> > to standardize how we're all using ansible, I'd like to also have a
> > tripleo-specific conversation at PTG on how we can break out some of
> > our
> > ansible that's currently embedded in t-h-t into more modular and
> > flexible roles.
> > 
> > Cheers,
> > Jill
> > 
> > [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/1
> > 3311
> > 9.html
> > [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
> > scribe
> > 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:unsubsc
> ribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc
Description: This is a digitally signed message part
__
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 is blocked

[Alex Schultz]

Please do not approve or recheck anything until further notice. We've
got a few issues that have basically broken all the jobs.

https://bugs.launchpad.net/tripleo/+bug/1786764
https://bugs.launchpad.net/tripleo/+bug/1787226
https://bugs.launchpad.net/tripleo/+bug/1787244
https://bugs.launchpad.net/tripleo/+bug/1787268

Thanks,
-Alex

__
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] [requirements] moved to [storyboard]

[Matthew Thode]

We've moved, please forward future correspondence to the following
location.

https://storyboard.openstack.org/#!/project/openstack/requirements

-- 
Matthew Thode (prometheanfire)


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] [TripleO] podman: varlink interface for nice API calls

[Jason E. Rist]

On 08/15/2018 03:32 AM, Cédric Jeanneret wrote:
> Dear Community,
> 
> As you may know, a move toward Podman as replacement of Docker is starting.
> 
> One of the issues with podman is the lack of daemon, precisely the lack
> of a socket allowing to send commands and get a "computer formatted
> output" (like JSON or YAML or...).
> 
> In order to work that out, Podman has added support for varlink¹, using
> the "socket activation" feature in Systemd.
> 
> On my side, I would like to push forward the integration of varlink in
> TripleO deployed containers, especially since it will allow the following:
> # proper interface with Paunch (via python link)
> 
> # a way to manage containers from within specific containers (think
> "healthcheck", "monitoring") by mounting the socket as a shared volume
> 
> # a way to get container statistics (think "metrics")
> 
> # a way, if needed, to get an ansible module being able to talk to
> podman (JSON is always better than plain text)
> 
> # a way to secure the accesses to Podman management (we have to define
> how varlink talks to Podman, maybe providing dedicated socket with
> dedicated rights so that we can have dedicated users for specific tasks)
> 
> That said, I have some questions:
> ° Does any of you have some experience with varlink and podman interface?
> ° What do you think about that integration wish?
> ° Does any of you have concern with this possible addition?
> 
> Thank you for your feedback and ideas.
> 
> Have a great day (or evening, or whatever suits the time you're reading
> this ;))!
> 
> C.
> 
> 
> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/
> 
> 
> 
> 
> __
> 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
> 

How might this effect upgrades?

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] podman: varlink interface for nice API calls

[Jay Pipes]

On 08/15/2018 04:01 PM, Emilien Macchi wrote:
On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi > wrote:


More seriously here: there is an ongoing effort to converge the
tools around containerization within Red Hat, and we, TripleO are
interested to continue the containerization of our services (which
was initially done with Docker & Docker-Distribution).
We're looking at how these containers could be managed by k8s one
day but way before that we plan to swap out Docker and join CRI-O
efforts, which seem to be using Podman + Buildah (among other things).

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to 
continue our containerization and investigate how we can improve our 
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run 
multiple container backends, and we're currently looking outside of 
Docker to see how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great 
community, focusing on some problems that we, TripleO have been facing 
since we containerized our services.


We're doing all of this in the open, so feel free to ask any question.


I appreciate your response, Emilien, thank you. Alex' responses to 
Jeremy on the #openstack-tc channel were informative, thank you Alex.


For now, it *seems* to me that all of the chosen tooling is very Red Hat 
centric. Which makes sense to me, considering Triple-O is a Red Hat product.


I don't know how much of the current reinvention of container runtimes 
and various tooling around containers is the result of politics. I don't 
know how much is the result of certain companies wanting to "own" the 
container stack from top to bottom. Or how much is a result of technical 
disagreements that simply cannot (or will not) be resolved among 
contributors in the container development ecosystem.


Or is it some combination of the above? I don't know.

What I *do* know is that the current "NIH du jour" mentality currently 
playing itself out in the container ecosystem -- reminding me very much 
of the Javascript ecosystem -- makes it difficult for any potential 
*consumers* of container libraries, runtimes or applications to be 
confident that any choice they make towards one of the other will be the 
*right* choice or even a *possible* choice next year -- or next week. 
Perhaps this is why things like openstack/paunch exist -- to give you 
options if something doesn't pan out.


You have a tough job. I wish you all the luck in the world in making 
these decisions and hope politics and internal corporate management 
decisions play as little a role in them as possible.


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

[openstack-dev] [nova] Stein subteam tracking etherpad now available

[melanie witt]

Hi all,

For those of us who use the global team etherpad for helping organize 
reviews for subteams, I just wanted to give a heads up that I've copied 
over the content from the Rocky etherpad [1] and created a new etherpad 
for us to use for Stein [2]. I've removed some things that appeared 
completely unused.


Please feel free to start using the Stein etherpad to help organize 
review for your subteam (note: this is separate from runways and is just 
a way for subteams to coordinate review of non-runway work, like bug 
fixes, etc). If you have a subteam or topic that is missing from the 
etherpad, feel free to add it and use the space for organizing your 
subteam reviews.


Let me know if you have any questions.

Best,
-melanie

[1] https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
[2] https://etherpad.openstack.org/p/stein-nova-subteam-tracking

__
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

[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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z

[Sean McGinnis]

On Tue, Aug 14, 2018 at 11:13:13AM -0500, Matthew Thode wrote:
> This is to warn and call out all those projects that do not have a
> stable/rocky branch yet.
> 
> If you are in the folloing list your project will need to realize that
> your master is testing against the requirements/constraints from stein,
> not rocky.  Any branching / tests you do will need to keep that in mind.
> 

I have just processed the branching request for the openstack/requirements
repo. Projects that have branched and have had the bot-proposed patch to update
the stable/rocky tox settings to use the stable/rocky upper constraints can now
approve those patches.

At the moment, requirements are matching between rocky and stein, but there's
usually only a small window where that is the case. If you have not branched
yet, be aware that at some point your testing could be running against the
wrong constraints.

__
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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z

[Matthew Thode]

On 18-08-14 11:13:13, Matthew Thode wrote:
> This is to warn and call out all those projects that do not have a
> stable/rocky branch yet.
> 
> If you are in the folloing list your project will need to realize that
> your master is testing against the requirements/constraints from stein,
> not rocky.  Any branching / tests you do will need to keep that in mind.
> 
> ansible-role-container-registry
> ansible-role-redhat-subscription
> ansible-role-tripleo-modify-image
> barbican-tempest-plugin
> blazar-tempest-plugin
> cinder-tempest-plugin
> cloudkitty-dashboard
> cloudkitty-tempest-plugin
> cloudkitty
> congress-tempest-plugin
> designate-tempest-plugin
> ec2api-tempest-plugin
> heat-agents
> heat-dashboard
> heat-tempest-plugin
> instack-undercloud
> ironic-tempest-plugin
> karbor-dashboard
> karbor
> keystone-tempest-plugin
> kuryr-kubernetes
> kuryr-libnetwork
> kuryr-tempest-plugin
> magnum-tempest-plugin
> magnum-ui
> manila-tempest-plugin
> mistral-tempest-plugin
> monasca-kibana-plugin
> monasca-tempest-plugin
> murano-tempest-plugin
> networking-generic-switch-tempest-plugin
> networking-hyperv
> neutron-tempest-plugin
> octavia-tempest-plugin
> os-apply-config
> os-collect-config
> os-net-config
> os-refresh-config
> oswin-tempest-plugin
> paunch
> python-tricircleclient
> sahara-tests
> senlin-tempest-plugin
> solum-tempest-plugin
> swift
> tacker-horizon
> tacker
> telemetry-tempest-plugin
> tempest-tripleo-ui
> tempest
> tripleo-common-tempest-plugin
> tripleo-ipsec
> tripleo-ui
> tripleo-validations
> trove-tempest-plugin
> vitrage-tempest-plugin
> watcher-tempest-plugin
> zaqar-tempest-plugin
> zun-tempest-plugin
> zun-ui
> zun
> 
> kolla-ansible
> kolla
> puppet-aodh
> puppet-barbican
> puppet-ceilometer
> puppet-cinder
> puppet-cloudkitty
> puppet-congress
> puppet-designate
> puppet-ec2api
> puppet-freezer
> puppet-glance
> puppet-glare
> puppet-gnocchi
> puppet-heat
> puppet-horizon
> puppet-ironic
> puppet-keystone
> puppet-magnum
> puppet-manila
> puppet-mistral
> puppet-monasca
> puppet-murano
> puppet-neutron
> puppet-nova
> puppet-octavia
> puppet-openstack_extras
> puppet-openstacklib
> puppet-oslo
> puppet-ovn
> puppet-panko
> puppet-qdr
> puppet-rally
> puppet-sahara
> puppet-swift
> puppet-tacker
> puppet-tempest
> puppet-tripleo
> puppet-trove
> puppet-vitrage
> puppet-vswitch
> puppet-watcher
> puppet-zaqar
> python-tripleoclient
> tripleo-common
> tripleo-heat-templates
> tripleo-image-elements
> tripleo-puppet-elements
> 
> So please branch :D
> 

we branched, also we are working on migrating to storyboard

-- 
Matthew Thode (prometheanfire)


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] [api] [cinder] backup restore in api v2

[Jay S Bryant]

On 8/15/2018 8:00 AM, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 07:52:47AM -0500, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem

Thanks for pointing that out Artem. That does appear to be a documentation bug.
The backup API has not changed, so v2 and v3 should be identical in that
regard. We will need to update our docs to reflect that.

Sean

Ah, we just did a really good job of hiding it:

https://developer.openstack.org/api-ref/block-storage/v2/index.html#restore-backup

I see the formatting for that document is off so that it actually appears as a
section under the delete documentation. I will get that fixed.

Artem and Sean,

Thanks for finding that and fixing it.

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

Re: [openstack-dev] [puppet] migrating to storyboard

[Jay S Bryant]

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-dev] [nova] Rocky blueprint burndown chart

[melanie witt]

Howdy everyone,

Keeping with the tradition of Matt's burndown charts from previous 
cycles [1][2], I have a burndown chart for the Rocky cycle [3] to share 
with you. Apologies for the gap in the data -- I had an issue keeping up 
with the count for that time period. I also focused on only Approved vs 
Completed counts this time. And finally, there are overlapping labels 
for "Spec Review Sprint" on June 5 and "r-2, spec freeze" on June 7 that 
are hard to read, and I didn't find a way to adjust their position in 
google sheets.


Comparing final numbers to Queens
-
Max approved for Queens: 53
Max approved for Rocky: 72
Final completed for Queens: 42
Final completed for Rocky: 59

Our completion percentage of approved blueprints in Queens was 79.2% and 
in Rocky it was 81.9%. We approved far more blueprints in Rocky than we 
did in Queens, but the completion rate was similar.


With runways, we were looking to increase our completion percentage by 
focusing on reviewing the same approved things at the same time but we 
simultaneously were more ambitious with what we approved. So we ended up 
with a similar completion percentage. This doesn't seem like a bad thing 
in that, we completed more blueprints than we did last cycle (and 
presumably got more done overall), but we're still having trouble with 
our approval rate of blueprints that we can realistically finish in one 
cycle.


I think part of the miss on the number of approvals might be because we 
extended the spec freeze date to milestone r-2 because of runways, 
thinking that if we completed enough things, we could approve more 
things. We didn't predict that accurately but with the experience, my 
hope is we can do better in Stein. We could consider moving spec freeze 
back to milestone s-1 or have rough criteria on whether to approve more 
blueprints close to s-2 (for example, if 30%? of approved blueprints 
have been completed, OK to approve more).


If you have feedback or thoughts on any of this, feel free to reply to 
this thread or add your comments to the Rocky retrospective etherpad [4] 
and we can discuss at the PTG.


Cheers,
-melanie

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121875.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127402.html
[3] 
https://docs.google.com/spreadsheets/d/e/2PACX-1vQicKStmnQFcOdnZU56ynJmn8e0__jYsr4FWXs3GrDsDzg1hwHofvJnuSieCH3ExbPngoebmEeY0waH/pubhtml?gid=128173249=true

[4] https://etherpad.openstack.org/p/nova-rocky-retrospective

__
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

[Chris Friesen]

On 08/04/2018 05:18 PM, Matt Riedemann wrote:

On 8/3/2018 9:14 AM, Chris Friesen wrote:

I'm of two minds here.

On the one hand, you have the case where the end user has accidentally
requested some combination of things that isn't normally available, and they
need to be able to ask the provider what they did wrong.  I agree that this
case is not really an exception, those resources were never available in the
first place.

On the other hand, suppose the customer issues a valid request and it works,
and then issues the same request again and it fails, leading to a violation of
that customers SLA.  In this case I would suggest that it could be considered
an exception since the system is not delivering the service that it was
intended to deliver.


As I'm sure you're aware Chris, it looks like StarlingX has a kind of
post-mortem query utility to try and figure out where requested resources didn't
end up yielding a resource provider (for a compute node):

https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-94f87e728df6465becce5241f3da53c8R330


But as you noted way earlier in this thread, it might not be the actual reasons
at the time of the failure and in a busy cloud could quickly change.


Just noticed this email, sorry for the delay.

The bit you point out isn't a post-mortem query but rather a way of printing out 
the rejection reasons that were stored (via calls to filter_reject()) at the 
time the request was processed by each filter.


Chris


__
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] podman: varlink interface for nice API calls

[Emilien Macchi]

On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi  wrote:

> More seriously here: there is an ongoing effort to converge the tools
> around containerization within Red Hat, and we, TripleO are interested to
> continue the containerization of our services (which was initially done
> with Docker & Docker-Distribution).
> We're looking at how these containers could be managed by k8s one day but
> way before that we plan to swap out Docker and join CRI-O efforts, which
> seem to be using Podman + Buildah (among other things).
>

I guess my wording wasn't the best but Alex explained way better here:
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52

If I may have a chance to rephrase, I guess our current intention is to
continue our containerization and investigate how we can improve our
tooling to better orchestrate the containers.
We have a nice interface (openstack/paunch) that allows us to run multiple
container backends, and we're currently looking outside of Docker to see
how we could solve our current challenges with the new tools.
We're looking at CRI-O because it happens to be a project with a great
community, focusing on some problems that we, TripleO have been facing
since we containerized our services.

We're doing all of this in the open, so feel free to ask any question.

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

[openstack-dev] OpenStack Diversity and Inclusion Survey

[Amy Marrich]

The Diversity and Inclusion WG is asking for your assistance. We have
revised the Diversity Survey that was originally distributed to the
Community in the Fall of 2015 and are looking to update our view of the
OpenStack community and it's diversity. We are pleased to be working with
members of the CHAOSS project who have signed confidentiality agreements in
order to assist us in the following ways:

1) Assistance in analyzing the results
2) And feeding the results into the CHAOSS software and metrics development
work so that we can help other Open Source projects

Please take the time to fill out the survey and share it with others in the
community. The survey can be found at:

https://www.surveymonkey.com/r/OpenStackDiversity

Thank you for assisting us in this important task!

Amy Marrich (spotz)
Diversity and Inclusion Working Group Chair
__
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Tony Breeds]

On Wed, Aug 15, 2018 at 09:10:18AM -0400, Doug Hellmann wrote:
> Excerpts from Andreas Jaeger's message of 2018-08-15 09:28:51 +0200:
> > On 08/15/2018 07:25 AM, Tony Breeds wrote:
> > > On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:
> > > 
> > >> Now that https://review.openstack.org/#/c/591671/ has landed, we need
> > >> someone to propose the backports of the constraint updates to all of the
> > >> existing stable branches.
> > > 
> > > Done:
> > > https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements
> > > 
> > > I'm not entirely convinced such a new release will work on older
> > > branches but I guess that's what CI is for :)
> > 
> > openstackdocsstheme has:
> > sphinx!=1.6.6,!=1.6.7,>=1.6.2
> > 
> > So, we cannot use it on branches that constraint sphinx to an older version,
> > 
> > Sorry, can't check this right now from where I am,
> > Andreas
> 
> That's a good point. We should give it a try, though. I don't think
> pip's constraints resolver takes version specifiers into account, so we
> should get the older sphinx and the newer theme. If those do happen to
> work together, it should be OK.
> 
> If not, we need another solution. We may have to do more work to
> backport the theme change into an older version of the library to
> make it work in the old branches.

The queens and pike backports have merged but ocata filed with[1]

ContextualVersionConflict: (pbr 1.10.0 
(/home/zuul/src/git.openstack.org/openstack/requirements/.tox/py27-check-uc/lib/python2.7/site-packages),
 Requirement.parse('pbr!=2.1.0,>=2.0.0'), set(['openstackdocstheme']))

So we can't use the rocky release on ocata.  I assume we need to do
something to ensure the docs are generated correctly.


Tony.

[1] 
http://logs.openstack.org/96/591896/1/check/requirements-tox-py27-check-uc/ff17c54/job-output.txt.gz#_2018-08-15_05_28_25_148515


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] [tripleo] ansible roles in tripleo

[Alex Schultz]

On Tue, Aug 14, 2018 at 11:51 AM, Jill Rouleau  wrote:
> Hey folks,
>
> Like Alex mentioned[0] earlier, we've created a bunch of ansible roles
> for tripleo specific bits.  The idea is to start putting some basic
> cookiecutter type things in them to get things started, then move some
> low-hanging fruit out of tripleo-heat-templates and into the appropriate
> roles.  For example, docker/services/keystone.yaml could have
> upgrade_tasks and fast_forward_upgrade_tasks moved into ansible-role-
> tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and the
> t-h-t updated to
> include_role: ansible-role-tripleo-keystone
>   tasks_from: upgrade.yml
> without having to modify any puppet or heat directives.
>

Do we have any examples of what the upgrade.yml would be or what type
of variables (naming conventions or otherwise) which would need to be
handled as part of this transtion?  I assume we may want to continue
passing in some variable to indicate the current deployment step.  Is
there something along these lines that we will be proposing or need to
handle?  We're already doing something similar with the
host_prep_tasks for the docker registry[0] but we have a set_fact
block to pass parameters in.   I'm assuming we'll need to define
something similar.

Thanks,
-Alex

[0] 
http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/puppet/services/docker-registry.yaml#n54

> This would let us define some patterns for implementing these tripleo
> roles during Stein while looking at how we can make use of ansible for
> things like core config.
>
> t-h-t and config-download will still drive the vast majority of playbook
> creation for now, but for new playbooks (such as for operations tasks)
> tripleo-ansible[1] would be our project directory.
>
> So in addition to the larger conversation about how deployers can start
> to standardize how we're all using ansible, I'd like to also have a
> tripleo-specific conversation at PTG on how we can break out some of our
> ansible that's currently embedded in t-h-t into more modular and
> flexible roles.
>
> Cheers,
> Jill
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/13311
> 9.html
> [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/
> __
> 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][qa][congress] tempest test conditioning on release version

[Eric K]

On Tue, Aug 14, 2018 at 8:59 PM, Ghanshyam Mann  wrote:
>   On Wed, 15 Aug 2018 06:40:57 +0900 Eric K  
> wrote 
>  > Anyone have an example handy of a tempest test conditioning on service
>  > release version (because new features not available in past versions)?
>  > Seems like it could get pretty messy and haphazard, so I'm curious to
>  > see best practices. Thanks lots!
>
> Thanks Eric for query. We do it in many times in Tempest and similar approach 
> can be adopt by tempest plugins. There are 2 ways we can handle  this-
>
> 1. Using feature flag. Tempest documentation is here [1].
>  Step1- This is simply adding a config options(feature flag) for new/old 
> feature.
>  Example- https://review.openstack.org/#/c/545627/   
> https://github.com/openstack/tempest/blob/6a8d495192632fd18dce4baf1a4b213f401a0167/tempest/config.py#L242
>  Step2- Based on that flag you can skip the tests where that feature is not 
> available.
>  Example-  
> https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/identity/base.py#L315
>  Step3- For gate, devstack plugin on project side (congress is your case [2]) 
> which is branch aware can set that flag to true and false based on which 
> branch that test is running. For tempest we do the same from 
> devstack/lib/tempest
>  Example - https://review.openstack.org/#/c/545680/
> https://github.com/openstack-dev/devstack/blob/8c1052001629d62f001d04c182500fa293858f47/lib/tempest#L308
>  Step4- For cloud testing(non-gate), tester can manually configure the those 
> flag based on what service version they are testing.
>
> 2. Detecting service version via version API
> - If you can get the service version info from API then you can use that 
> while skipping the tests.
> - One example if for compute where based on microversion, it can be detected 
> that test running against which release.
> - Example- 
> https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/compute/base.py#L114
>
>
> [1] 
> https://docs.openstack.org/tempest/latest/HACKING.html#branchless-tempest-considerations
> [2] 
> https://github.com/openstack/congress/blob/014361c809517661264d0364eaf1e261e449ea80/devstack/plugin.sh#L88
>
>  >
>  > Eric Kao

Thank you so much, Ghanshyam!

__
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Andreas Jaeger]

On 2018-08-15 10:33, Tony Breeds wrote:

On Wed, Aug 15, 2018 at 09:28:51AM +0200, Andreas Jaeger wrote:
  

openstackdocsstheme has:
sphinx!=1.6.6,!=1.6.7,>=1.6.2

So, we cannot use it on branches that constraint sphinx to an older version,

Sorry, can't check this right now from where I am,


Constraints
---
origin/master : Sphinx===1.7.6
origin/stable/newton  : Sphinx===1.2.3
origin/stable/ocata   : Sphinx===1.3.6
origin/stable/pike: Sphinx===1.6.3
origin/stable/queens  : Sphinx===1.6.5

Looks ok to me.



Great, thanks!

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] [puppet] migrating to storyboard

[Tom Barron]

On 15/08/18 10:43 -0600, 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.




Yeah, given that gerrit logs are ephemeral and given that users often 
don't have the savvy to cut and paste exactly the right log fragments 
for their issues I think this is a pretty big deal.  When I triage 
bugs I often ask for logs to be uploaded.  This may be less of a big 
deal for puppet than for projects like manila or cinder where there 
are a set of ongoing services in a custom configuration and there's no 
often no clear way for the bug triager to set up a reproducer.


We're waiting on resolution of [1] before moving ahead with Storyboard 
for manila.


-- Tom


Chris


[1] https://storyboard.openstack.org/#!/story/2003071

__
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

[Ade Lee]

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

Re: [openstack-dev] [puppet] migrating to storyboard

[Chris Friesen]

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

__
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

[Mohammed Naser]

It's a +1 from me.  I don't think there is anything linked specifically to it.

On Wed, Aug 15, 2018 at 11:22 AM, Emilien Macchi  wrote:
> On Tue, Aug 14, 2018 at 6:33 PM Tobias Urdin  wrote:
>>
>> Please let me know what you think about moving to Storyboard?
>
> Go for it. AFIK we don't have specific blockers to make that migration
> happening.
>
> Thanks,
> --
> 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
>



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.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

Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls

[Emilien Macchi]

Hi Jay,

On Wed, Aug 15, 2018 at 3:59 PM Jay Pipes  wrote:

> This was news to me. Is this just a triple-o thing?
>

It's in the newspapers!
https://www.serverwatch.com/server-news/red-hat-looks-beyond-docker-for-container-technology.html

More seriously here: there is an ongoing effort to converge the tools
around containerization within Red Hat, and we, TripleO are interested to
continue the containerization of our services (which was initially done
with Docker & Docker-Distribution).
We're looking at how these containers could be managed by k8s one day but
way before that we plan to swap out Docker and join CRI-O efforts, which
seem to be using Podman + Buildah (among other things).

The work done at this time (so far) is pure investigation, but feedback is
always welcome.
We're tracking our efforts here:
https://etherpad.openstack.org/p/tripleo-podman

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

Re: [openstack-dev] [puppet] migrating to storyboard

[Emilien Macchi]

On Tue, Aug 14, 2018 at 6:33 PM Tobias Urdin  wrote:

> Please let me know what you think about moving to Storyboard?
>
Go for it. AFIK we don't have specific blockers to make that migration
happening.

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

Re: [openstack-dev] [barbican][oslo][release] FFE request for castellan

[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] [TripleO] podman: varlink interface for nice API calls

[Jay Pipes]

On 08/15/2018 05:32 AM, Cédric Jeanneret wrote:

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.


This was news to me. Is this just a triple-o thing?

-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-dev] [oslo][castellan][python3][goal] need help debugging stable/queens failure in castellan functional tests

[Doug Hellmann]

The patch to add the zuul job settings to the castellan stable/queens
branch is failing the castellan-functional-devstack job. It looks like
the job fails to set up some of the services correctly (I see lots of
messages about services not responding or not starting).

When was that job added to castellan? Should it be running on
stable/queens?

If we need it, can someone familiar with the job look into the
failure and try to fix the problem?

Thanks,
Doug

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

__
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2018-08-15 09:28:51 +0200:
> On 08/15/2018 07:25 AM, Tony Breeds wrote:
> > On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:
> > 
> >> Now that https://review.openstack.org/#/c/591671/ has landed, we need
> >> someone to propose the backports of the constraint updates to all of the
> >> existing stable branches.
> > 
> > Done:
> > https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements
> > 
> > I'm not entirely convinced such a new release will work on older
> > branches but I guess that's what CI is for :)
> 
> openstackdocsstheme has:
> sphinx!=1.6.6,!=1.6.7,>=1.6.2
> 
> So, we cannot use it on branches that constraint sphinx to an older version,
> 
> Sorry, can't check this right now from where I am,
> Andreas

That's a good point. We should give it a try, though. I don't think
pip's constraints resolver takes version specifiers into account, so we
should get the older sphinx and the newer theme. If those do happen to
work together, it should be OK.

If not, we need another solution. We may have to do more work to
backport the theme change into an older version of the library to
make it work in the old branches.

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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-15 15:25:29 +1000:
> On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:
> 
> > Now that https://review.openstack.org/#/c/591671/ has landed, we need
> > someone to propose the backports of the constraint updates to all of the
> > existing stable branches.
> 
> Done:
> https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements
> 
> I'm not entirely convinced such a new release will work on older
> branches but I guess that's what CI is for :)
> 
> Yours Tony.

Thanks, Tony!

__
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] [api] [cinder] backup restore in api v2

[Sean McGinnis]

On Wed, Aug 15, 2018 at 07:52:47AM -0500, Sean McGinnis wrote:
> On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:
> > Hi all,
> > 
> > I have recently faced an interesting question: is there no backup restore
> > functionality in block-storage api v2? There is possibility to create
> > backup, but not to restore it according to
> > https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
> > Version v3 ref contain restore function. What is also interesting, that
> > cinderclient contain the restore function for v2. Is this just a v2
> > documentation bug (what I assume) or was it an unsupported function in v2?
> > 
> > Thanks,
> > Artem
> 
> Thanks for pointing that out Artem. That does appear to be a documentation 
> bug.
> The backup API has not changed, so v2 and v3 should be identical in that
> regard. We will need to update our docs to reflect that.
> 
> Sean

Ah, we just did a really good job of hiding it:

https://developer.openstack.org/api-ref/block-storage/v2/index.html#restore-backup

I see the formatting for that document is off so that it actually appears as a
section under the delete documentation. I will get that fixed.

> 
> __
> 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] [api] [cinder] backup restore in api v2

[Sean McGinnis]

On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:
> Hi all,
> 
> I have recently faced an interesting question: is there no backup restore
> functionality in block-storage api v2? There is possibility to create
> backup, but not to restore it according to
> https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
> Version v3 ref contain restore function. What is also interesting, that
> cinderclient contain the restore function for v2. Is this just a v2
> documentation bug (what I assume) or was it an unsupported function in v2?
> 
> Thanks,
> Artem

Thanks for pointing that out Artem. That does appear to be a documentation bug.
The backup API has not changed, so v2 and v3 should be identical in that
regard. We will need to update our docs to reflect that.

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

[openstack-dev] oracle rac on openstack: openfiler as shared storage

[Liviu Popescu]

 Hello,

regarding:

openstack for having "shared-storage" needed for Oracle RAC:


I have used openfiler in a vmware environment, for creating iscsi targets
and accessing iscsi luns on target machines with iscsi-initiator.
On db machines,  LUNs were used  via multipath.conf and udev rules,  to be
visible by Oracle RAC  nodes, for ASM (asm disks).



Please advice me  on how to get an openfiler image suitable for openstack,
in order to simulate a shared-storage.


Thank you!
__
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] podman: varlink interface for nice API calls

[Cédric Jeanneret]

Dear Community,

As you may know, a move toward Podman as replacement of Docker is starting.

One of the issues with podman is the lack of daemon, precisely the lack
of a socket allowing to send commands and get a "computer formatted
output" (like JSON or YAML or...).

In order to work that out, Podman has added support for varlink¹, using
the "socket activation" feature in Systemd.

On my side, I would like to push forward the integration of varlink in
TripleO deployed containers, especially since it will allow the following:
# proper interface with Paunch (via python link)

# a way to manage containers from within specific containers (think
"healthcheck", "monitoring") by mounting the socket as a shared volume

# a way to get container statistics (think "metrics")

# a way, if needed, to get an ansible module being able to talk to
podman (JSON is always better than plain text)

# a way to secure the accesses to Podman management (we have to define
how varlink talks to Podman, maybe providing dedicated socket with
dedicated rights so that we can have dedicated users for specific tasks)

That said, I have some questions:
° Does any of you have some experience with varlink and podman interface?
° What do you think about that integration wish?
° Does any of you have concern with this possible addition?

Thank you for your feedback and ideas.

Have a great day (or evening, or whatever suits the time you're reading
this ;))!

C.


¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/


-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP 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

[openstack-dev] [placement] extraction etherpad for PTG

[Chris Dent]

I've created an etherpad to prepare ideas and plans for a discussion
at the PTG about extracting placement to its own thing.

https://etherpad.openstack.org/p/placement-extract-stein

Right now it is in a fairly long form as it gathers ideas and
references. The goal is to compress it to something concise after
we've had plenty of input so we have a (small) series of discussion
points to resolve at the PTG.

If this is a topic you think is important or you have an interest
in, please add your thoughts to the etherpad.

--
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Tony Breeds]

On Wed, Aug 15, 2018 at 09:28:51AM +0200, Andreas Jaeger wrote:
 
> openstackdocsstheme has:
> sphinx!=1.6.6,!=1.6.7,>=1.6.2
> 
> So, we cannot use it on branches that constraint sphinx to an older version,
> 
> Sorry, can't check this right now from where I am,

Constraints
---
origin/master : Sphinx===1.7.6
origin/stable/newton  : Sphinx===1.2.3
origin/stable/ocata   : Sphinx===1.3.6
origin/stable/pike: Sphinx===1.6.3
origin/stable/queens  : Sphinx===1.6.5

Looks ok to me.

Yours Tony.


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

[openstack-dev] [api] [cinder] backup restore in api v2

[Artem Goncharov]

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem
__
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Andreas Jaeger]

On 08/15/2018 07:25 AM, Tony Breeds wrote:

On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:


Now that https://review.openstack.org/#/c/591671/ has landed, we need
someone to propose the backports of the constraint updates to all of the
existing stable branches.


Done:
https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements

I'm not entirely convinced such a new release will work on older
branches but I guess that's what CI is for :)


openstackdocsstheme has:
sphinx!=1.6.6,!=1.6.7,>=1.6.2

So, we cannot use it on branches that constraint sphinx to an older version,

Sorry, can't check this right now from where I am,
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

[openstack-dev] [watcher] weekly meeting

[Чадин Александр Сергеевич]

Greetings,

We’ll have meeting today at 8:00 UTC on #openstack-meeting-3 channel.

Best Regards,

Alex

__
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

[Tobias Urdin]

Hello Kendall,

Thanks for your reply, that sounds awesome!
We can then dig around and see how everything looks when all project 
bugs are imported to stories.


I see no issues with being able to move to Storyboard anytime soon if 
the feedback for

moving is positive.

Best regards
Tobias

On 08/14/2018 09:06 PM, Kendall Nelson wrote:

Hello!

The error you hit can be resolved by adding launchpadlib to your 
tox.ini if I recall correctly..


also, if you'd like, I can run a test migration of puppet's launchpad 
projects into our storyboard-dev db (where I've done a ton of other 
test migrations) if you want to see how it looks/works with a larger 
db. Just let me know and I can kick it off.


As for a time to migrate, if you all are good with it, we usually 
schedule for Friday's so there is even less activity. Its a small 
project config change and then we just need an infra core to kick off 
the script once the change merges.


-Kendall (diablo_rojo)

On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin > wrote:


Hello all incredible Puppeters,

I've tested setting up an Storyboard instance and test migrated
puppet-ceph and it went without any issues there using the
documentation
[1] [2]
with just one minor issue during the SB setup [3].

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?
If everybody is in favor of it we can request a migration to infra
according to documentation [2].

I will continue to test the import of all our project while people
are
collecting their thoughts and feedback :)

Best regards
Tobias

[1]
https://docs.openstack.org/infra/storyboard/install/development.html
[2] https://docs.openstack.org/infra/storyboard/migration.html

[3] It failed with an error about launchpadlib not being installed,
solved with `tox -e venv pip install launchpadlib`

__
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