Re: [openstack-dev] [k8s] OpenStack and Containers White Paper

[Pete Birley]

Chris,

I'd be happy to help out where I can, mostly related to OSH and LOCI. One
thing we should make clear is that both of these projects are agnostic to
each other: we gate OSH with both LOCI and kolla images, and conversely
LOCI has uses far beyond just OSH.

Pete

On Monday, April 2, 2018, Chris Hoge  wrote:

> Hi everyone,
>
> In advance of the Vancouver Summit, I'm leading an effort to publish a
> community produced white-paper on OpenStack and container integrations.
> This has come out of a need to develop materials, both short and long
> form, to help explain how OpenStack interacts with container
> technologies across the entire stack, from infrastructure to
> application. The rough outline of the white-paper proposes an entire
> technology stack and discuss deployment and usage strategies at every
> level. The white-paper will focus on existing technologies, and how they
> are being used in production today across our community. Beginning at
> the hardware layer, we have the following outline (which may be inverted
> for clarity):
>
> * OpenStack Ironic for managing bare metal deployments.
> * Container-based deployment tools for installing and managing OpenStack
>* Kolla containers and Kolla-Ansible
>* Loci containers and OpenStack Helm
> * OpenStack-hosted APIs for managing container application
>   infrastructure.
>* Magnum
>* Zun
> * Community-driven integration of Kubernetes and OpenStack with K8s
>   Cloud Provider OpenStack
> * Projects that can stand alone in integrations with Kubernetes and
>   other cloud technology
>* Cinder
>* Neutron with Kuryr and Calico integrations
>* Keystone authentication and authorization
>
> I'm looking for volunteers to help produce the content for these sections
> (and any others we may uncover to be useful) for presenting a complete
> picture of OpenStack and container integrations. If you're involved with
> one of these projects, or are using any of these tools in
> production, it would be fantastic to get your input in producing the
> appropriate section. We especially want real-world deployments to use as
> small case studies to inform the work.
>
> During the process of creating the white-paper, we will be working with a
> technical writer and the Foundation design team to produce a document that
> is consistent in voice, has accurate and informative graphics that
> can be used to illustrate the major points and themes of the white-paper,
> and that can be used as stand-alone media for conferences and
> presentations.
>
> Over the next week, I'll be reaching out to individuals and inviting them
> to collaborate. This is also a general invitation to collaborate, and if
> you'd like to help out with a section please reach out to me here, on the
> K8s #sig-openstack Slack channel, or at my work e-mail,
> ch...@openstack.org.
> Starting next week, we'll work out a schedule for producing and delivering
> the white-paper by the Vancouver Summit. We are very short on time, so
> we will have to be focused to quickly produce high-quality content.
>
> Thanks in advance to everyone who participates in writing this
> document. I'm looking forward to working with you in the coming weeks to
> publish this important resource for clearly describing the multitude of
> interactions between these complementary technologies.
>
> -Chris Hoge
> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

[image: Port.direct] 

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[MinWookKim]

Hello Ifat, 

 

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

 

But there are some limitations, so we have to think about it.

 

We also need to think about targets, scope, and so on.

 

The reason I do not think of tools like Zabbix, Nagios, and Prometheus as a
tool to run checks is because we need to configure an agent or an exporter.

 

I think it is not hard to configure an agent for monitoring objects such as
a physical host.

 

But the scope of the idea I think involves the VM's interior. 

 

Therefore, configuring the agent automatically inside the VM may not be
easy. (although we can use parameters like user-data)

 

If we exclude VM internal checks from scope, we can simply perform a check
via Zabbix. (Like Zabbix's remote command, history)

 

On the other hand, if we include the inside of a VM in a scope, and
configure each of them, we have a rather constant overhead.

 

The check service may incur temporary overhead, but the agent configuration
can cause constant overhead.

 

And Zabbix history can be another task for Vitrage.

 

If we configure the agents themselves and exclude the VM's internal checks,
we can provide functionality with simple code.

 

how is it?

 

Thank you.

 

Best regards,

Minwook.

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

 

Hi Minwook,

 

Thinking about it again, writing a new service for these checks might be an
unnecessary overhead. Have you considered using an existing tool, like
Zabbix, for running such checks? If you use Zabbix, you can define new
triggers that run the new checks, and whenever needed the user can ask to
open Zabbix and show the relevant metrics. The format will not be exactly
the same as in your example, but it will save a lot of work and spare you
the need to write and manage a new service. 

 

Some technical details: 

 

* The current information that Vitrage stores is not enough for
opening the right Zabbix page. We will need to keep a little more data, like
the item id, on the alarm vertex. But can be done easily. 

* A relevant Zabbix API is history.get [1]

* If you are not using Zabbix, I assume that other monitoring tools
have similar capabilities

 

What do you think? Do you think it can work with your scenario?

Or do you see a benefit to the user is viewing the data in the format that
you suggested?

 

 

[1]

https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get

 

Thanks,

Ifat

 

 

From: MinWookKim <  delightw...@ssu.ac.kr>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <

openstack-dev@lists.openstack.org>
Date: Monday, 2 April 2018 at 4:51
To: "'OpenStack Development Mailing List (not for usage questions)'" <

openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thank you for the reply. :)

 

It is my opinion only, so if I'm wrong, we can change the implementation
part at any time. (Even if it differs from my initial intention)

 

The same security issues arise as you say. But now Vitrage does not call
external APIs.

 

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms,
and RCA requests to Vitrage.

 

So if we add an API, it will have the following flow.

 

Vitrage-dashboard requests checks using the Vitrageclient library. ->
Vitrage receives the API.

 

-> api / controllers / v1 / checks.py is called. -> checks service is
called.

 

In accordance with the above flow, passing through the Vitrage API is the
purpose of data passing and function calls. 

 

I think Vitrage does not need to call external APIs.

 

If you do not want to go through the Vitrage API, we need to create a
function for the check action in the Vitrage-dashboard, and write code to
call the function.

 

If I think wrong, please tell me anytime. :)

 

Thank you.

 

Best regards,

Minwook.

 

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

 

Hi Minwook,

 

I understand your concern about the security issue. 

But how would that be different if the API call is passed through Vitrage
API? The authentication from vitrage-dashboard to vitrage API will work, but
then Vitrage will call an external API and you’ll have the same security
issue, right? I don’t understand what is the difference between calling the
external component 

[openstack-dev] [trove] Trove weekly meeting on April 4th, 2018 is cancelled

[赵超]

Hi,

Sorry for forgetting to discuss this on the last meeting, as here in China
we'll on a vacation for Qingming Festival from April 5th, some core members
may not be able to attend the meeting, so let's skip it, the next meeting
will be Wednesday, April 11th, 2018.

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

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

[Dan Prince]

On Thu, Mar 29, 2018 at 5:32 PM, Emilien Macchi  wrote:
> Greeting folks,
>
> During the last PTG we spent time discussing some ideas around an All-In-One
> installer, using 100% of the TripleO bits to deploy a single node OpenStack
> very similar with what we have today with the containerized undercloud and
> what we also have with other tools like Packstack or Devstack.
>
> https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
>
> One of the problems that we're trying to solve here is to give a simple tool
> for developers so they can both easily and quickly deploy an OpenStack for
> their needs.
>
> "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly
> and without complexity, reproducing the same exact same tooling as TripleO
> is using."
> "As a Neutron developer, I need to develop a feature in Neutron and test it
> with TripleO in my local env."
> "As a TripleO dev, I need to implement a new service and test its deployment
> in my local env."
> "As a developer, I need to reproduce a bug in TripleO CI that blocks the
> production chain, quickly and simply."
>
> Probably more use cases, but to me that's what came into my mind now.
>
> Dan kicked-off a doc patch a month ago:
> https://review.openstack.org/#/c/547038/
> And I just went ahead and proposed a blueprint:
> https://blueprints.launchpad.net/tripleo/+spec/all-in-one
> So hopefully we can start prototyping something during Rocky.

I've actually started hacking a bit here:

https://github.com/dprince/talon

Very early and I haven't committed everything yet. (Probably wouldn't
have announced it to the list yet but it might help some understand
the use case).

I'm running this on my laptop to develop TripleO containers with no
extra VM involved.

P.S. We should call it Talon!

Dan

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

Sorry dude. Already prototyping :)

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

__
OpenStack Development Mailing 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] [k8s] OpenStack and Containers White Paper

[Zhipeng Huang]

Hi Chris,

If it is possible to add Cyborg under  "Projects that can stand alone in
integrations with Kubernetes and
  other cloud technology" section, I would like to help on that content.

On Tue, Apr 3, 2018 at 5:30 AM, Hongbin Lu  wrote:

> Hi Chris,
>
> I can help with the Zun session.
>
> Best regards,
> Hongbin
>
> On Mon, Apr 2, 2018 at 4:59 PM, Chris Hoge  wrote:
>
>> Hi everyone,
>>
>> In advance of the Vancouver Summit, I'm leading an effort to publish a
>> community produced white-paper on OpenStack and container integrations.
>> This has come out of a need to develop materials, both short and long
>> form, to help explain how OpenStack interacts with container
>> technologies across the entire stack, from infrastructure to
>> application. The rough outline of the white-paper proposes an entire
>> technology stack and discuss deployment and usage strategies at every
>> level. The white-paper will focus on existing technologies, and how they
>> are being used in production today across our community. Beginning at
>> the hardware layer, we have the following outline (which may be inverted
>> for clarity):
>>
>> * OpenStack Ironic for managing bare metal deployments.
>> * Container-based deployment tools for installing and managing OpenStack
>>* Kolla containers and Kolla-Ansible
>>* Loci containers and OpenStack Helm
>> * OpenStack-hosted APIs for managing container application
>>   infrastructure.
>>* Magnum
>>* Zun
>> * Community-driven integration of Kubernetes and OpenStack with K8s
>>   Cloud Provider OpenStack
>> * Projects that can stand alone in integrations with Kubernetes and
>>   other cloud technology
>>* Cinder
>>* Neutron with Kuryr and Calico integrations
>>* Keystone authentication and authorization
>>
>> I'm looking for volunteers to help produce the content for these sections
>> (and any others we may uncover to be useful) for presenting a complete
>> picture of OpenStack and container integrations. If you're involved with
>> one of these projects, or are using any of these tools in
>> production, it would be fantastic to get your input in producing the
>> appropriate section. We especially want real-world deployments to use as
>> small case studies to inform the work.
>>
>> During the process of creating the white-paper, we will be working with a
>> technical writer and the Foundation design team to produce a document that
>> is consistent in voice, has accurate and informative graphics that
>> can be used to illustrate the major points and themes of the white-paper,
>> and that can be used as stand-alone media for conferences and
>> presentations.
>>
>> Over the next week, I'll be reaching out to individuals and inviting them
>> to collaborate. This is also a general invitation to collaborate, and if
>> you'd like to help out with a section please reach out to me here, on the
>> K8s #sig-openstack Slack channel, or at my work e-mail,
>> ch...@openstack.org.
>> Starting next week, we'll work out a schedule for producing and delivering
>> the white-paper by the Vancouver Summit. We are very short on time, so
>> we will have to be focused to quickly produce high-quality content.
>>
>> Thanks in advance to everyone who participates in writing this
>> document. I'm looking forward to working with you in the coming weeks to
>> publish this important resource for clearly describing the multitude of
>> interactions between these complementary technologies.
>>
>> -Chris Hoge
>> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] Replacing pbr's autodoc feature with sphinxcontrib-apidoc

[Zane Bitter]

On 28/03/18 10:31, Stephen Finucane wrote:

As noted last week [1], we're trying to move away from pbr's autodoc
feature as part of the new docs PTI. To that end, I've created
sphinxcontrib-apidoc, which should do what pbr was previously doing for
us by via a Sphinx extension.

   https://pypi.org/project/sphinxcontrib-apidoc/

This works by reading some configuration from your documentation's
'conf.py' file and using this to call 'sphinx-apidoc'. It means we no
longer need pbr to do this for.

I have pushed version 0.1.0 to PyPi already but before I add this to
global requirements, I'd like to ensure things are working as expected.
smcginnis was kind enough to test this out on glance and it seemed to
work for him but I'd appreciate additional data points. The
configuration steps for this extension are provided in the above link.
To test this yourself, you simply need to do the following:

1. Add 'sphinxcontrib-apidoc' to your test-requirements.txt or
   doc/requirements.txt file
2. Configure as noted above and remove the '[pbr]' and '[build_sphinx]'
   configuration from 'setup.cfg'
3. Replace 'python setup.py build_sphinx' with a call to 'sphinx-build'
4. Run 'tox -e docs'
5. Profit?

Be sure to let me know if anyone encounters issues. If not, I'll be
pushing for this to be included in global requirements so we can start
the migration.


Thanks Stephen! I tried it out with no problems:

https://review.openstack.org/558262

However, there are a couple of differences compared to how pbr did things.

1) pbr can generate an 'autoindex' file with a flat list of modules 
(this appears to be configurable with the autodoc_index_modules option), 
but apidoc only generates a 'modules' file with a hierarchical list of 
modules. This is easy to work around, but I guess it needs to be added 
to the instructions to check that you're not relying on it.


2) pbr generates a page per module; this plugin generates a page per 
package. This results in wy too much information on a page to be 
able to navigate it comfortably IMHO. To the point where it's easier to 
read the code. (It also breaks existing links, if you care about that 
kind of thing.) I sent you a PR to add an option to pass --separate:


https://github.com/sphinx-contrib/apidoc/pull/1

cheers,
Zane.

__
OpenStack Development Mailing 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] [glance] python-glanceclient release status

[Brian Rosmaita]

These need to be reviewed in master:
- https://review.openstack.org/#/c/50/
- https://review.openstack.org/#/c/556292/

Backports needing review:
- https://review.openstack.org/#/c/555436/

__
OpenStack Development Mailing 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] Last chance Vancouver Summit Early Birds!

[Mark Collier]

Hey Stackers,

You’ve got TWO DAYS left to snag an early bird ticket, which is $699 for a full 
access, week-long pass. That’s four days of 300+ sessions and workshops on 
OpenStack, containers, edge, CI/CD and HPC/GPU/AI in Vancouver May 21-24th.

The OpenStack Summit is my favorite place to meet and learn from smart, driven, 
funny people from all over the world. Will you join me in Vancouver May 21-24? 
OpenStack.org/summit  has the details.

Who else will you meet in Vancouver? 

- An OpenStack developer to discuss the future of the software?
- A Kubernetes expert in one of more than 60 sessions about Kubernetes?
- A Foundation member who can help you learn how to contribute code upstream at 
the Upstream Institute?
- Other enterprises & service providers running OpenStack at scale like 
JPMorgan Chase, Progressive Insurance, Google, Target, Walmart, Yahoo!, China 
Mobile, AT, Verizon, China Railway, and Yahoo! Japan?
- Your next employee… or employer?

Key links:
Register: openstack.org/summit  (Early bird 
pricing ends April 4 at 11:59pm Pacific Time / April 5 6:59 UTC)
Full Schedule: 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/#day=2018-05-21 

Hotel Discounts: https://www.openstack.org/summit/vancouver-2018/travel/ 

Sponsor: https://www.openstack.org/summit/vancouver-2018/sponsors/ 

Code of Conduct: 
https://www.openstack.org/summit/vancouver-2018/code-of-conduct/ 


See you at the Summit!

Mark
twitter.com/sparkycollier __
OpenStack Development Mailing 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] [k8s] OpenStack and Containers White Paper

[Hongbin Lu]

Hi Chris,

I can help with the Zun session.

Best regards,
Hongbin

On Mon, Apr 2, 2018 at 4:59 PM, Chris Hoge  wrote:

> Hi everyone,
>
> In advance of the Vancouver Summit, I'm leading an effort to publish a
> community produced white-paper on OpenStack and container integrations.
> This has come out of a need to develop materials, both short and long
> form, to help explain how OpenStack interacts with container
> technologies across the entire stack, from infrastructure to
> application. The rough outline of the white-paper proposes an entire
> technology stack and discuss deployment and usage strategies at every
> level. The white-paper will focus on existing technologies, and how they
> are being used in production today across our community. Beginning at
> the hardware layer, we have the following outline (which may be inverted
> for clarity):
>
> * OpenStack Ironic for managing bare metal deployments.
> * Container-based deployment tools for installing and managing OpenStack
>* Kolla containers and Kolla-Ansible
>* Loci containers and OpenStack Helm
> * OpenStack-hosted APIs for managing container application
>   infrastructure.
>* Magnum
>* Zun
> * Community-driven integration of Kubernetes and OpenStack with K8s
>   Cloud Provider OpenStack
> * Projects that can stand alone in integrations with Kubernetes and
>   other cloud technology
>* Cinder
>* Neutron with Kuryr and Calico integrations
>* Keystone authentication and authorization
>
> I'm looking for volunteers to help produce the content for these sections
> (and any others we may uncover to be useful) for presenting a complete
> picture of OpenStack and container integrations. If you're involved with
> one of these projects, or are using any of these tools in
> production, it would be fantastic to get your input in producing the
> appropriate section. We especially want real-world deployments to use as
> small case studies to inform the work.
>
> During the process of creating the white-paper, we will be working with a
> technical writer and the Foundation design team to produce a document that
> is consistent in voice, has accurate and informative graphics that
> can be used to illustrate the major points and themes of the white-paper,
> and that can be used as stand-alone media for conferences and
> presentations.
>
> Over the next week, I'll be reaching out to individuals and inviting them
> to collaborate. This is also a general invitation to collaborate, and if
> you'd like to help out with a section please reach out to me here, on the
> K8s #sig-openstack Slack channel, or at my work e-mail,
> ch...@openstack.org.
> Starting next week, we'll work out a schedule for producing and delivering
> the white-paper by the Vancouver Summit. We are very short on time, so
> we will have to be focused to quickly produce high-quality content.
>
> Thanks in advance to everyone who participates in writing this
> document. I'm looking forward to working with you in the coming weeks to
> publish this important resource for clearly describing the multitude of
> interactions between these complementary technologies.
>
> -Chris Hoge
> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>
>
> __
> OpenStack Development Mailing 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] container name in swift

[Jialin Liu]

Thanks Iury and John.

Best,
Jialin

On Mon, Apr 2, 2018 at 1:17 PM, Iury Gregory  wrote:

> According to Swift doc[1]
>
> Length of container names 256 bytes Cannot contain the / character.
> Length of object names 1024 bytes By default, there are no character
> restrictions.
>
> [1] https://docs.openstack.org/swift/latest/api/object_api_
> v1_overview.html
>
>
>
> 2018-04-02 17:00 GMT-03:00 Jialin Liu :
>
>> Hi John,
>> What is allowed in container name, but not in object name?
>> I need a way to distinguish their name..
>>
>> Best,
>> Jialin
>>
>> On Mon, Apr 2, 2018 at 11:56 AM, John Dickinson  wrote:
>>
>>> no
>>>
>>> On 2 Apr 2018, at 11:46, Jialin Liu wrote:
>>>
>>> > Hi,
>>> > Can a container name in openstack swift contains / ?
>>> > e.g.,
>>> > abc/111/mycontainer
>>> >
>>> >
>>> > Best,
>>> > Jialin
>>> > 
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
>
> *Att[]'sIury Gregory Melo Ferreira *
> *MSc in Computer Science at UFCG*
>
> *Part of the puppet-manager-core team in OpenStack*
> *Social*: https://www.linkedin.com/in/iurygregory
> *E-mail:  iurygreg...@gmail.com *
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [k8s] OpenStack and Containers White Paper

[Amy Marrich]

Chris,

Can't help with content but can volunteer as an editor.

Amy (spotz)

On Mon, Apr 2, 2018 at 3:59 PM, Chris Hoge  wrote:

> Hi everyone,
>
> In advance of the Vancouver Summit, I'm leading an effort to publish a
> community produced white-paper on OpenStack and container integrations.
> This has come out of a need to develop materials, both short and long
> form, to help explain how OpenStack interacts with container
> technologies across the entire stack, from infrastructure to
> application. The rough outline of the white-paper proposes an entire
> technology stack and discuss deployment and usage strategies at every
> level. The white-paper will focus on existing technologies, and how they
> are being used in production today across our community. Beginning at
> the hardware layer, we have the following outline (which may be inverted
> for clarity):
>
> * OpenStack Ironic for managing bare metal deployments.
> * Container-based deployment tools for installing and managing OpenStack
>* Kolla containers and Kolla-Ansible
>* Loci containers and OpenStack Helm
> * OpenStack-hosted APIs for managing container application
>   infrastructure.
>* Magnum
>* Zun
> * Community-driven integration of Kubernetes and OpenStack with K8s
>   Cloud Provider OpenStack
> * Projects that can stand alone in integrations with Kubernetes and
>   other cloud technology
>* Cinder
>* Neutron with Kuryr and Calico integrations
>* Keystone authentication and authorization
>
> I'm looking for volunteers to help produce the content for these sections
> (and any others we may uncover to be useful) for presenting a complete
> picture of OpenStack and container integrations. If you're involved with
> one of these projects, or are using any of these tools in
> production, it would be fantastic to get your input in producing the
> appropriate section. We especially want real-world deployments to use as
> small case studies to inform the work.
>
> During the process of creating the white-paper, we will be working with a
> technical writer and the Foundation design team to produce a document that
> is consistent in voice, has accurate and informative graphics that
> can be used to illustrate the major points and themes of the white-paper,
> and that can be used as stand-alone media for conferences and
> presentations.
>
> Over the next week, I'll be reaching out to individuals and inviting them
> to collaborate. This is also a general invitation to collaborate, and if
> you'd like to help out with a section please reach out to me here, on the
> K8s #sig-openstack Slack channel, or at my work e-mail,
> ch...@openstack.org.
> Starting next week, we'll work out a schedule for producing and delivering
> the white-paper by the Vancouver Summit. We are very short on time, so
> we will have to be focused to quickly produce high-quality content.
>
> Thanks in advance to everyone who participates in writing this
> document. I'm looking forward to working with you in the coming weeks to
> publish this important resource for clearly describing the multitude of
> interactions between these complementary technologies.
>
> -Chris Hoge
> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>
>
> __
> OpenStack Development Mailing 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] [k8s] OpenStack and Containers White Paper

[Chris Hoge]

Hi everyone,

In advance of the Vancouver Summit, I'm leading an effort to publish a
community produced white-paper on OpenStack and container integrations.
This has come out of a need to develop materials, both short and long
form, to help explain how OpenStack interacts with container
technologies across the entire stack, from infrastructure to
application. The rough outline of the white-paper proposes an entire
technology stack and discuss deployment and usage strategies at every
level. The white-paper will focus on existing technologies, and how they
are being used in production today across our community. Beginning at
the hardware layer, we have the following outline (which may be inverted
for clarity):

* OpenStack Ironic for managing bare metal deployments.
* Container-based deployment tools for installing and managing OpenStack
   * Kolla containers and Kolla-Ansible
   * Loci containers and OpenStack Helm
* OpenStack-hosted APIs for managing container application
  infrastructure.
   * Magnum
   * Zun
* Community-driven integration of Kubernetes and OpenStack with K8s
  Cloud Provider OpenStack
* Projects that can stand alone in integrations with Kubernetes and
  other cloud technology
   * Cinder
   * Neutron with Kuryr and Calico integrations
   * Keystone authentication and authorization

I'm looking for volunteers to help produce the content for these sections
(and any others we may uncover to be useful) for presenting a complete
picture of OpenStack and container integrations. If you're involved with
one of these projects, or are using any of these tools in
production, it would be fantastic to get your input in producing the
appropriate section. We especially want real-world deployments to use as
small case studies to inform the work.

During the process of creating the white-paper, we will be working with a
technical writer and the Foundation design team to produce a document that
is consistent in voice, has accurate and informative graphics that
can be used to illustrate the major points and themes of the white-paper,
and that can be used as stand-alone media for conferences and
presentations.

Over the next week, I'll be reaching out to individuals and inviting them
to collaborate. This is also a general invitation to collaborate, and if
you'd like to help out with a section please reach out to me here, on the
K8s #sig-openstack Slack channel, or at my work e-mail, ch...@openstack.org.
Starting next week, we'll work out a schedule for producing and delivering
the white-paper by the Vancouver Summit. We are very short on time, so
we will have to be focused to quickly produce high-quality content.

Thanks in advance to everyone who participates in writing this
document. I'm looking forward to working with you in the coming weeks to
publish this important resource for clearly describing the multitude of
interactions between these complementary technologies.

-Chris Hoge
K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead


__
OpenStack Development Mailing 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 Ken Giusti for oslo-core

[Ben Nemec]

It's been a week and no nacks, so welcome to oslo-core, Ken!

-Ben

On 03/26/2018 10:52 AM, Doug Hellmann wrote:

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.

Thanks,
Doug

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



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

Re: [openstack-dev] container name in swift

[Iury Gregory]

According to Swift doc[1]

Length of container names 256 bytes Cannot contain the / character.
Length of object names 1024 bytes By default, there are no character
restrictions.

[1] https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html



2018-04-02 17:00 GMT-03:00 Jialin Liu :

> Hi John,
> What is allowed in container name, but not in object name?
> I need a way to distinguish their name..
>
> Best,
> Jialin
>
> On Mon, Apr 2, 2018 at 11:56 AM, John Dickinson  wrote:
>
>> no
>>
>> On 2 Apr 2018, at 11:46, Jialin Liu wrote:
>>
>> > Hi,
>> > Can a container name in openstack swift contains / ?
>> > e.g.,
>> > abc/111/mycontainer
>> >
>> >
>> > Best,
>> > Jialin
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygreg...@gmail.com *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] container name in swift

[Jialin Liu]

Hi John,
What is allowed in container name, but not in object name?
I need a way to distinguish their name..

Best,
Jialin

On Mon, Apr 2, 2018 at 11:56 AM, John Dickinson  wrote:

> no
>
> On 2 Apr 2018, at 11:46, Jialin Liu wrote:
>
> > Hi,
> > Can a container name in openstack swift contains / ?
> > e.g.,
> > abc/111/mycontainer
> >
> >
> > Best,
> > Jialin
> > 
> __
> > OpenStack Development Mailing 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] container name in swift

[John Dickinson]

no

On 2 Apr 2018, at 11:46, Jialin Liu wrote:

> Hi,
> Can a container name in openstack swift contains / ?
> e.g.,
> abc/111/mycontainer
>
>
> Best,
> Jialin
> __
> OpenStack Development Mailing 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: 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] container name in swift

[Jialin Liu]

Hi,
Can a container name in openstack swift contains / ?
e.g.,
abc/111/mycontainer


Best,
Jialin
__
OpenStack Development Mailing 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] [Fwd: Barbican is Eligible to Migrate!]

[Kendall Nelson]

https://storyboard-dev.openstack.org/#!/project_group/27 shows the project
group that has all the barbican repos represented for tracking issues and
new features against.

https://storyboard-dev.openstack.org/#!/project/286 shows items
specifically related to the main barbican repo- its where the majority of
things exist right now after the migration.

Let me know if you have any questions!

-Kendall (diablo_rojo)


On Mon, Apr 2, 2018 at 6:54 AM Ade Lee  wrote:

> Hey Barbicaneers,
>
> Kendall has provided us a test migration to storyboard, and Barbican
> has apparently migrated smoothly.  You can see the test instance in his
> email (forwarded below).  The correct URL is actually https://storyboar
> d-dev.openstack.org/#!/project/286
>
> Any objections/ concerns about doing the migration?
>
> Ade
>
>
> -- Forwarded message --
> From: Kendall Nelson 
> To: Ade Lee 
> Cc:
> Bcc:
> Date: Thu, 29 Mar 2018 17:46:01 +
> Subject: Barbican is Eligible to Migrate!
> Hello!
>
> Long story short, hopefully you are aware that projects are in the process
> of migrating to StoryBoard. I've been working on another round of test
> migrations this week and Barbican test migrated without issue!
>
> If you would be willing to start the conversation with your team, we would
> love to migrate the project at your earliest convenience. The general
> migration process is outlined here[1].
>
> This blog has several posts related to why we are migrating, how Launchpad
> maps to StoryBoard, etc. [2]
>
> If you have any questions please let me know! Or feel free to ask in the
> #storyboard channel.
>
> If you are interested in seeing what the result of Barbican's test
> migration looks like you can see the result here[3]. I have a project group
> (named barbican) set up with the repos barbican has (based off those listed
> in projects.yaml in governance) and then ran the import from your Launchpad
> projects to migrate the bugs over. I only found three Launchpad projects
> (the python-barbicanclient, barbican, and castellan-ui which had nothing in
> it) associated with Barbican so if I missed any, please let me know and I
> can migrate them as well.
>
> Hope to hear from you soon!
>
> -Kendall (diablo_rojo)
>
> [1] https://docs.openstack.org/infra/storyboard/migration.html
> [2] https://storyboard-blog.io/
> [3] https://storyboard-dev.openstack.org/#!/project_group/27
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Prototyping dedicated roles with unique repositories for Ansible tasks in TripleO

[Alex Schultz]

On Thu, Mar 29, 2018 at 11:32 AM, David Moreau Simard
 wrote:
> Nice!
>
> I don't have a strong opinion
> about this but what I might recommend would be to chat with the
> openshift-ansible [1] and the kolla-ansible [2] folks.
>
> I'm happy to do the introductions if necessary !
>
> Their models, requirements or context might be different than ours but at
> the end of the day, it's a set of Ansible roles and playbooks to install
> something.
> It would be a good idea just to informally chat about the reasons why their
> things are set up the way they are, what are the pros, cons.. or their
> challenges.
>
> I'm not saying we should structure our things like theirs.
> What I'm trying to say is that they've surely learned a lot over the years
> these projects have existed and it's surely worthwhile to chat with them so
> we don't repeat some of the same mistakes.
>
> Generally just draw from their experience, learn from their conclusions and
> take that into account before committing to any particular model we'd like
> to have in TripleO ?

Yea it'd probably be a good idea to check with them on some of their
structure choices.  I think we do not necessarily want to use a
similar structure to those based on our experiences with oooq,
openstack-puppet-modules, etc.  I think this first iteration to get
some of the upgrade tasks out of the various */services/*.yaml will
help us build out a decent structure that might be reusable.  I did
notice that kolla-ansible has a main.yaml[0] that might be interesting
for us to consider when we start using the ansible roles directly
rather than importing the tasks themselves.

What I'd really like for us to work on is better cookiecutter/testing
structure for ansible roles themselves so we stop just merging ansible
bits that are only tested via full deployment tests (which we may not
even run).  As much as I hate rspec puppet tests, it is really nice
for testing the logic without having to do an actual deployment.

Thanks,
-Alex

[0] 
https://git.openstack.org/cgit/openstack/kolla-ansible/tree/ansible/roles/keystone/tasks/main.yml

>
> [1]: https://github.com/openshift/openshift-ansible
> [2]: https://github.com/openstack/kolla-ansible
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> On Thu, Mar 29, 2018, 12:34 PM David Peacock,  wrote:
>>
>> Hi everyone,
>>
>> During the recent PTG in Dublin, it was decided that we'd prototype a way
>> forward with Ansible tasks in TripleO that adhere to Ansible best practises,
>> creating dedicated roles with unique git repositories and RPM packaging per
>> role.
>>
>> With a view to moving in this direction, a couple of us on the TripleO
>> team have begun developing tooling to facilitate this.  Initially we've
>> worked on a tool [0] to extract Ansible tasks lists from
>> tripleo-heat-templates and move them into new formally structured Ansible
>> roles.
>>
>> An example with the existing keystone docker service [1]:
>>
>> The upgrade_tasks block will become:
>>
>> ```
>> upgrade_tasks:
>>   - import_role:
>>   name: tripleo-role-keystone
>>   tasks_from: upgrade.yaml
>> ```
>>
>> The fast_forward_upgrade_tasks block will become:
>>
>> ```
>> fast_forward_upgrade_tasks:
>>   - import_role:
>>   name: tripleo-role-keystone
>>   tasks_from: fast_forward_upgrade.yaml
>> ```
>>
>> And this role [2] will be structured:
>>
>> ```
>> tripleo-role-keystone/
>> └── tasks
>> ├── fast_forward_upgrade.yaml
>> ├── main.yaml
>> └── upgrade.yaml
>> ```
>>
>> We'd love to hear any feedback from the community as we move towards this.
>>
>> Thank you,
>> David Peacock
>>
>> [0]
>> https://github.com/davidjpeacock/openstack-role-extract/blob/master/role-extractor-creator.py
>> [1]
>> https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/keystone.yaml
>> [2] https://github.com/davidjpeacock/tripleo-role-keystone
>> __
>> OpenStack Development Mailing 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] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Martin André]

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake)  wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com) wrote:
>
> On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) 
> wrote:
>> My viewpoint is as all deployments projects are already on an equal
>> footing
>> when using Kolla containers.
>
> While I acknowledge Kolla reviewers are doing a very good job at
> treating all incoming reviews equally, we can't realistically state
> these projects stand on an equal footing today.
>
>
> At the very least we need to have kolla changes _gating_ on TripleO
> and OSH jobs before we can say so. Of course, I'm not saying other
> kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
> sure they would welcome the changes if someone volunteers for it, but
> right now when I'm approving a kolla patches I can only say with
> confidence that it does not break kolla-ansible. In that sense,
> kolla_ansible is special.
>
> Martin,
>
> Personally I think all of OpenStack projects that have a dependency or
> inverse dependency should cross-gate.  For example, Nova should gate on
> kolla-ansible, and at one point I think they agreed to this, if we submitted
> gate work to do so.  We never did that.
>
> Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and
> they will follow the standard mechanism used in OpenStack
> experimental->non-voting->voting (if people are on-call to resolve
> problems).  I don't think gating is relevant to equal footing.  TripleO for
> the moment has chosen to gate on their own image builds, which is fine.  If
> the gating should be enhanced, write the gates :)
>
> Here is a simple definition from the internet:
>
> "with the same rights and conditions as someone you are competing with"
>
> Does that mean if you want to split the kolla repo into 40+ repos for each
> separate project, the core team will do that?  No.  Does that mean if there
> is a reasonable addition to the API the patch would merge?  Yes.
>
> Thats right, deployment tools compete, but they also cooperate and
> collaborate.  The containers (atleast from my perspective) are an area where
> Kolla has chosen to collaborate.  FWIW I also think we have chosen to
> collobrate a bit in areas we compete (the deployment tooling itself).  Its a
> very complex topic.  Splitting the governance and PTLs doesn't change the
> makeup of the core review team who ultimately makes the decision about what
> is reasonable.

Collaboration is good, there is no question about it.
I suppose the question we need to answer is "would splitting kolla and
kolla-ansible further benefit kolla and the projects that consume
it?". I believe if you look at it from this angle maybe you'll find
areas that are neglected because they are lower priority for
kolla-ansible developers.

>> I would invite the TripleO team who did integration with the Kolla API to
>> provide their thoughts.
>
> The Kolla API is stable and incredibly useful... it's also
> undocumented. I have a stub for a documentation change that's been
> collecting dust on my hard drive for month, maybe it's time I brush it
>
> Most of Kolla unfortunately is undocumented.  The API is simple and
> straightforward enough that TripleO, OSH, and several proprietary vendors
> (the ones Jeffrey mentioned) have managed to implement deployment tooling
> that consume the API.  Documentation for any part of Kolla would be highly
> valued - IMO it is the Kolla project's biggest weakness.
>
>
> up and finally submit it. Today unless you're a kolla developer
> yourself, it's difficult to understand how to use the API, not the
> most user friendly.
>
> Another thing that comes for free with Kolla, the extend_start.sh
> scripts are for the most part only useful in the context of
> kolla_ansible. For instance, hardcoding path for log dirs to
> /var/log/kolla and changing groups to 'kolla'.
> In TripleO, we've chosen to not depend on the extend_start.sh scripts
> whenever possible for this exact reason.
>
> I don't disagree.  I was never fond of extend_start, and thought any special
> operations it provided belong in the API itself.  This is why there are
> mkdir operations and chmod/chown -R operations in the API.  The JSON blob
> handed to the API during runtime is where the API begins and ends.  The
> implementation (what set_cfg.py does with start.sh and extend_start.sh) are
> not part of the API but part of the API implementation.

One could argue that the environment variables we pass to the
containers to control what extend_start.sh does are also part of the
API. That's not my point. There is a lot of cruft in these scripts
that remain from the days where kolla-ansible was the only consumer of
kolla images.

> I don't think I said anywhere the API is perfectly implemented.  I'm not
> sure I've ever seen this mythical perfection thing in an API anyway :)
>
> Patches are welcome to improve the API to make it more general, as 

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Clark Boylan]

On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > According to a notice[1] posted to the pypa-announce and
> > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > is expected to be released in two weeks (over the April 14/15
> > weekend). We know it's at least going to start breaking[2] DevStack
> > and we need to come up with a plan for addressing that, but we don't
> > know how much more widespread the problem might end up being so
> > encourage everyone to try it out now where they can.
> > 
> 
> I'd like to suggest locking down pip/setuptools/wheel like openstack
> ansible is doing in 
> https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> 
> We could maintain it as a separate constraints file (or infra could
> maintian it, doesn't mater).  The file would only be used for the
> initial get-pip install.

In the past we've done our best to avoid pinning these tools because 1) we've 
told people they should use latest for openstack to work and 2) it is really 
difficult to actually control what versions of these tools end up on your 
systems if not latest.

I would strongly push towards addressing the distutils package deletion problem 
that we've run into with pip10 instead. One of the approaches thrown out that 
pabelanger is working on is to use a common virtualenv for devstack and avoid 
the system package conflict entirely.

Clark

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

Re: [openstack-dev] [tripleo] Blueprints for Rocky

[Alex Schultz]

On Tue, Mar 13, 2018 at 7:58 AM, Alex Schultz  wrote:
> Hey everyone,
>
> So we currently have 63 blueprints for currently targeted for
> Rocky[0].  Please make sure that any blueprints you are interested in
> delivering have an assignee set and have been approved.  I would like
> to have the ones we plan on delivering for Rocky to be updated by
> April 3, 2018.  Any blueprints that have not been updated will be
> moved out to the next cycle after this date.
>

Reminder this is tomorrow. I'll be going through the blueprints and
moving them out this week.

> Thanks,
> -Alex
>
> [0] https://blueprints.launchpad.net/tripleo/rocky

__
OpenStack Development Mailing 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] [infra][qa][requirements] Pip 10 is on the way

[Matthew Thode]

On 18-03-31 15:00:27, Jeremy Stanley wrote:
> According to a notice[1] posted to the pypa-announce and
> distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> is expected to be released in two weeks (over the April 14/15
> weekend). We know it's at least going to start breaking[2] DevStack
> and we need to come up with a plan for addressing that, but we don't
> know how much more widespread the problem might end up being so
> encourage everyone to try it out now where they can.
> 

I'd like to suggest locking down pip/setuptools/wheel like openstack
ansible is doing in 
https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt

We could maintain it as a separate constraints file (or infra could
maintian it, doesn't mater).  The file would only be used for the
initial get-pip install.

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

[Steven Dake (stdake)]

On April 2, 2018 at 6:00:15 AM, Martin André 
(m.an...@redhat.com) wrote:

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake)  wrote:
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.

At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

Martin,

Personally I think all of OpenStack projects that have a dependency or inverse 
dependency should cross-gate.  For example, Nova should gate on kolla-ansible, 
and at one point I think they agreed to this, if we submitted gate work to do 
so.  We never did that.

Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and they 
will follow the standard mechanism used in OpenStack 
experimental->non-voting->voting (if people are on-call to resolve problems).  
I don't think gating is relevant to equal footing.  TripleO for the moment has 
chosen to gate on their own image builds, which is fine.  If the gating should 
be enhanced, write the gates :)

Here is a simple definition from the internet:

"with the same 
rights and 
conditions
 as someone you are 
competing 
with"

Does that mean if you want to split the kolla repo into 40+ repos for each 
separate project, the core team will do that?  No.  Does that mean if there is 
a reasonable addition to the API the patch would merge?  Yes.

Thats right, deployment tools compete, but they also cooperate and collaborate. 
 The containers (atleast from my perspective) are an area where Kolla has 
chosen to collaborate.  FWIW I also think we have chosen to collobrate a bit in 
areas we compete (the deployment tooling itself).  Its a very complex topic.  
Splitting the governance and PTLs doesn't change the makeup of the core review 
team who ultimately makes the decision about what is reasonable.

|

> I would invite the TripleO team who did integration with the Kolla API to
> provide their thoughts.

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it

Most of Kolla unfortunately is undocumented.  The API is simple and 
straightforward enough that TripleO, OSH, and several proprietary vendors (the 
ones Jeffrey mentioned) have managed to implement deployment tooling that 
consume the API.  Documentation for any part of Kolla would be highly valued - 
IMO it is the Kolla project's biggest weakness.

up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

Another thing that comes for free with Kolla, the extend_start.sh
scripts are for the most part only useful in the context of
kolla_ansible. For instance, hardcoding path for log dirs to
/var/log/kolla and changing groups to 'kolla'.
In TripleO, we've chosen to not depend on the extend_start.sh scripts
whenever possible for this exact reason.

I don't disagree.  I was never fond of extend_start, and thought any special 
operations it provided belong in the API itself.  This is why there are mkdir 
operations and chmod/chown -R operations in the API.  The JSON blob handed to 
the API during runtime is where the API begins and ends.  The implementation 
(what set_cfg.py does with start.sh and extend_start.sh) are not part of the 
API but part of the API implementation.

I don't think I said anywhere the API is perfectly implemented.  I'm not sure 
I've ever seen this mythical perfection thing in an API anyway :)

Patches are welcome to improve the API to make it more general, as long as they 
maintain backward compatibility.


The other critical kolla feature we're making extensive use of in
TripleO is the ability to customize the image in any imaginable way
thanks to the template override mechanism. There would be no
containerized deployments via TripleO without it.


We knew people would find creative ways to use the plugin templating 
technology, and help drive adoption of Kolla as a standard...

Kolla is a great framework for building container images for OpenStack
services any project can consume. We could do a better job at
advertising it. I guess bringing 

[openstack-dev] [barbican] [Fwd: Barbican is Eligible to Migrate!]

[Ade Lee]

Hey Barbicaneers,

Kendall has provided us a test migration to storyboard, and Barbican
has apparently migrated smoothly.  You can see the test instance in his
email (forwarded below).  The correct URL is actually https://storyboar
d-dev.openstack.org/#!/project/286

Any objections/ concerns about doing the migration?

Ade --- Begin Message ---
Hello!

Long story short, hopefully you are aware that projects are in the process
of migrating to StoryBoard. I've been working on another round of test
migrations this week and Barbican test migrated without issue!

If you would be willing to start the conversation with your team, we would
love to migrate the project at your earliest convenience. The general
migration process is outlined here[1].

This blog has several posts related to why we are migrating, how Launchpad
maps to StoryBoard, etc. [2]

If you have any questions please let me know! Or feel free to ask in the
#storyboard channel.

If you are interested in seeing what the result of Barbican's test
migration looks like you can see the result here[3]. I have a project group
(named barbican) set up with the repos barbican has (based off those listed
in projects.yaml in governance) and then ran the import from your Launchpad
projects to migrate the bugs over. I only found three Launchpad projects
(the python-barbicanclient, barbican, and castellan-ui which had nothing in
it) associated with Barbican so if I missed any, please let me know and I
can migrate them as well.

Hope to hear from you soon!

-Kendall (diablo_rojo)

[1] https://docs.openstack.org/infra/storyboard/migration.html
[2] https://storyboard-blog.io/
[3] https://storyboard-dev.openstack.org/#!/project_group/27


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

Re: [openstack-dev] [barbican][nova-powervm][pyghmi][solum][trove] Switching to cryptography from pycrypto

[Ade Lee]

On Sat, 2018-03-31 at 18:24 -0500, Matthew Thode wrote:
> Here's the current status.  I'd like to ask the projects what's
> keeping
> them from removing pycrypto in facor of a maintained library.
> 
> Open reviews
> barbican:
>   - (merge conflict) https://review.openstack.org/#/c/458196
>   - (merge conflict) https://review.openstack.org/#/c/544873

There is still some pycrypto in the Dogtag plugin, which needs to be
switched out to cryptography. I'm aware of what needs to be done and
plan to get to it in this release.

> nova-powervm: no open reviews
>   - in test-requirements, but not actually used?
>   - made https://review.openstack.org/558091 for it
> pyghmi:
>   - (merge conflict) https://review.openstack.org/#/c/331828
>   - (merge conflict) https://review.openstack.org/#/c/545465
>   - (doesn't change the import) https://review.openstack.org/#/c/5451
> 82
> solum: no open reviews
>   - looks like only a couple of functions need changing
> trove: no open reviews
>   - mostly uses the random feature
> 
> _
> _
> 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] [Vitrage] New proposal for analysis.

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Thinking about it again, writing a new service for these checks might be an 
unnecessary overhead. Have you considered using an existing tool, like Zabbix, 
for running such checks? If you use Zabbix, you can define new triggers that 
run the new checks, and whenever needed the user can ask to open Zabbix and 
show the relevant metrics. The format will not be exactly the same as in your 
example, but it will save a lot of work and spare you the need to write and 
manage a new service.

Some technical details:


· The current information that Vitrage stores is not enough for opening 
the right Zabbix page. We will need to keep a little more data, like the item 
id, on the alarm vertex. But can be done easily.

· A relevant Zabbix API is history.get [1]

· If you are not using Zabbix, I assume that other monitoring tools 
have similar capabilities

What do you think? Do you think it can work with your scenario?
Or do you see a benefit to the user is viewing the data in the format that you 
suggested?


[1] https://www.zabbix.com/documentation/3.0/manual/api/reference/history/get

Thanks,
Ifat


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

Date: Monday, 2 April 2018 at 4:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 

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

Hello Ifat,

Thank you for the reply. :)

It is my opinion only, so if I'm wrong, we can change the implementation part 
at any time. (Even if it differs from my initial intention)

The same security issues arise as you say. But now Vitrage does not call 
external APIs.

The Vitrage-dashboard uses Vitrageclient libraries for Topology, Alarms, and 
RCA requests to Vitrage.

So if we add an API, it will have the following flow.

Vitrage-dashboard requests checks using the Vitrageclient library. -> Vitrage 
receives the API.

-> api / controllers / v1 / checks.py is called. -> checks service is called.

In accordance with the above flow, passing through the Vitrage API is the 
purpose of data passing and function calls.

I think Vitrage does not need to call external APIs.

If you do not want to go through the Vitrage API, we need to create a function 
for the check action in the Vitrage-dashboard, and write code to call the 
function.

If I think wrong, please tell me anytime. :)

Thank you.

Best regards,
Minwook.

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

Hi Minwook,

I understand your concern about the security issue.
But how would that be different if the API call is passed through Vitrage API? 
The authentication from vitrage-dashboard to vitrage API will work, but then 
Vitrage will call an external API and you’ll have the same security issue, 
right? I don’t understand what is the difference between calling the external 
component from vitrage-dashboard and calling it from vitrage.

Best regards,
Ifat.

From: MinWookKim >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, 29 March 2018 at 14:51
To: "'OpenStack Development Mailing List (not for usage questions)'" 
>
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

Hello Ifat,

Thanks for your reply.  : )
I wrote my opinion on your comment.

Why do you think the request should pass through the Vitrage API? Why can’t 
vitrage-dashboard call the check component directly?

Authentication issues:
I think the check component is a separate component based on the API.

In my opinion, if the check component has a separate api address from the 
vitrage to receive requests from the Vitrage-dashboard,
the Vitrage-dashboard needs to know the api address for the check component.

This can result in a request / response situation open to anyone, regardless of 
the authentication supported
by openstack between the Vitrage-dashboard and the request / response procedure 
of check component.

This is possible not only through the Vitrage-dashboard, but also with simple 
commands such as curl.
(I think it is unnecessary to implement a separate authentication system for 
the check component.)

This problem may occur if someone knows the api address for the check component,
which can cause the host and VM to execute system commands.

what should happen if the user closes the check window before the checks are 
over? I assume that the checks will finish, but the user won’t be able to see 
the results?

If the window is closed before the check is 

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Martin André]

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake)  wrote:
>
>
>
> On March 31, 2018 at 12:35:31 PM, Jeremy Stanley (fu...@yuggoth.org) wrote:
>
> On 2018-03-31 18:06:07 + (+), Steven Dake (stdake) wrote:
>> I appreciate your personal interest in attempting to clarify the
>> Kolla mission statement.
>>
>> The change in the Kolla mission statement you propose is
>> unnecessary.
> [...]
>
> I should probably have been more clear. The Kolla mission statement
> right now says that the Kolla team produces two things: containers
> and deployment tools. This may make it challenging for the team to
> avoid tightly coupling their deployment tooling and images, creating
> a stratification of first-class (those created by the Kolla team)
> and second-class (those created by anyone else) support for
> deployment tools using those images.
>
>
> The problems raised in this thread (tension - tight coupling - second class
> citizens - stratification) was predicted early on - prior to Kolla 1.0.
> That prediction led to the creation of a technical solution - the Kolla API.
> This API permits anyone to reuse the containers as they see fit if they
> conform their implementation to the API.  The API is not specifically tied
> to the Ansible deployment technology.  Instead the API is tied to the
> varying requirements that various deployment teams have had in the past
> around generalized requirements for making container lifecycle management a
> reality while running OpenStack services and their dependencies inside
> containers.
>
> Is the intent to provide "a container-oriented deployment solution
> and the container images it uses" (kolla-ansible as first-class
> supported deployment engine for these images) or "container images
> for use by arbitrary deployment solutions, along with an example
> deployment solution for use with them" (kolla-ansible on equal
> footing with competing systems that make use of the same images)?
>
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.
At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

> I would invite the TripleO team who did integration with the Kolla API to
> provide their thoughts.

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it
up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

Another thing that comes for free with Kolla, the extend_start.sh
scripts are for the most part only useful in the context of
kolla_ansible. For instance, hardcoding path for log dirs to
/var/log/kolla and changing groups to 'kolla'.
In TripleO, we've chosen to not depend on the extend_start.sh scripts
whenever possible for this exact reason.

The other critical kolla feature we're making extensive use of in
TripleO is the ability to customize the image in any imaginable way
thanks to the template override mechanism. There would be no
containerized deployments via TripleO without it.

Kolla is a great framework for building container images for OpenStack
services any project can consume. We could do a better job at
advertising it. I guess bringing kolla and kolla-kubernetes under
separate governance (even it the team remains mostly the same) is one
way to enforce the independence of kolla-the-images project and
recognize people may be interested in the images but not the
deployment tools.

One last though. Would you imagine a kolla PTL who is not heavily
invested in kolla_ansible?

Martin

> I haven't kept up with OSH development, but perhaps that team could provide
> their viewpoint as well.
>
>
> Cheers
>
> -steve
>
>
> --
> 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] [barbican][nova-powervm][pyghmi][solum][trove] Switching to cryptography from pycrypto

[Jim Rollenhagen]

On Sat, Mar 31, 2018 at 7:24 PM, Matthew Thode 
wrote:

> Here's the current status.  I'd like to ask the projects what's keeping
> them from removing pycrypto in facor of a maintained library.
>
> pyghmi:
>   - (merge conflict) https://review.openstack.org/#/c/331828
>   - (merge conflict) https://review.openstack.org/#/c/545465
>   - (doesn't change the import) https://review.openstack.org/#/c/545182


Looks like py26 support might be a blocker here. While we've brought
pyghmi into the ironic project, it's still a project mostly built and
maintained
by Jarrod, and he has customers outside of OpenStack that depend on it.
The ironic team will have to discuss this with Jarrod and find a good path
forward.

My initial thought is that we need to move forward on this, so
perhaps we can release this change as a major version, and keep a py26
branch that can be released on the previous minor version for the people
that need this on 2.6. Thoughts?

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

Re: [openstack-dev] [cinder][nova] about re-image the volume

[Gorka Eguileor]

On 29/03, Sean McGinnis wrote:
> >   This is the spec [0] about rebuild the volumed backed server.
> > The question raised in the spec is about how to bandle the root volume.
> > Finally,in Nova team,we think that the cleanest / best solution to this is 
> > to
> > add a volume action API to cinder for re-imaging the volume.Once that is
> > available in a new cinder v3 microversion, nova can use it. The reason I
> > ...
> >   So Nova team want Cinder to achieve the re-image api.But, I see a spec
> > about volume revert by snapshot[1].It is so good for rebuild operation.In
> > short,I have two ideas,one is change the volume revert by snapshot spec to
> > re-image spec,not only it can let the volume revert by snapshot,but also can
> > re-image the volume which the image's size is greater than 0;another idea is
> > add a only re-image spec,it only can re-image the volume which the image's
> > size is greater than 0.
> >
>
> I do not think changing the revert to snapshot implementation is appropriate
> here. There may be some cases where this can get the desired result, but there
> is no guarantee that there is a snapshot on the volume's base image state to
> revert to. It also would not make sense to overload this functionality to
> "revert to snapshot if you can, otherwise do all this other stuff instead."
>
> This would need to be a new API (microversioned) to add a reimage call. I
> wouldn't expect implementation to be too difficult as we already have that
> functionality for new volumes. We would just need to figure out the most
> appropriate way to take an already in-use volume, detach it, rewrite the 
> image,
> then reattach it.
>

Hi,

The implementation may be more complex that we think, as we have 4
create volume from image mechanisms we have to consider:

- When Glance is using Cinder as backend
- When using Glance image location to do cloning
- When using Cinder cache and we do cloning
- Basic case where we download the image, attach the volume, and copy
  the data.

The only simple, yet efficient, solution I can see is calling the
driver's delete volume method (without soft-deleting it from the DB),
clear the volume DB information of the image metadata, and then run the
create volume from image flow with the same volume information but the
new image metadata.

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

Cheers,
Gorka.


> Ideally, from my perspective, Nova would take care of the detach/attach 
> portion
> and Cinder would only need to take care of imaging the volume.
>
> 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 Development Mailing 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] [vitrage]

[Hanumantha Reddy]

__
OpenStack Development Mailing 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] [devstack][qa] Changes to devstack LIBS_FROM_GIT

[Ghanshyam Mann]

On Thu, Mar 29, 2018 at 5:21 AM, James E. Blair  wrote:
> Hi,
>
> I've proposed a change to devstack which slightly alters the
> LIBS_FROM_GIT behavior.  This shouldn't be a significant change for
> those using legacy devstack jobs (but you may want to be aware of it).
> It is more significant for new-style devstack jobs.
>
> The change is at https://review.openstack.org/549252
>
> In summary, when this change lands, new-style devstack jobs should no
> longer need to set LIBS_FROM_GIT explicitly.  Existing legacy jobs
> should be unaffected (but there is a change to the verification process
> performed by devstack).
>
>
> Currently devstack expects the contents of LIBS_FROM_GIT to be
> exclusively a list of python packages which, obviously, should be
> installed from git and not pypi.  It is used for two purposes:
> determining whether an individual package should be installed from git,
> and verifying that a package was installed from git.
>
> In the old devstack-gate system, we prepared many of the common git
> repos, whether they were used or not.  So LIBS_FROM_GIT was created to
> indicate that in some cases devstack should ignore those repos and
> install from pypi instead.  In other words, its original purpose was
> purely as a method of selecting whether a devstack-gate prepared repo
> should be used or ignored.
>
> In Zuul v3, we have a good way to indicate whether a job is going to use
> a repo or not -- add it to "required-projects".  Considering that, the
> LIBS_FROM_GIT variable is redundant.  So my patch causes it to be
> automatically generated based on the contents of required-projects.
> This means that job authors don't need to list every required repository
> twice.
>
> However, a naïve implementation of that runs afoul of the second use of
> LIBS_FROM_GIT -- verifying that python packages are installed from git.
>
> This usage was added later, after a typographical error ("-" vs "_" in a
> python package name) in a constraints file caused us not to install a
> package from git.  Now devstack verifies that every package in
> LIBS_FROM_GIT is installed.  However, Zuul doesn't know that devstack,
> tempest, and other packages aren't installed.  So adding them
> automatically to LIBS_FROM_GIT will cause devstack to fail.
>
> My change modifies this verification to only check that packages
> mentioned in LIBS_FROM_GIT that devstack tried to install were actually
> installed.  I realize that stated as such this sounds tautological,
> however, this check is still valid -- it would have caught the original
> error that prompted the check in the first case.
>
> What the revised check will no longer handle is a typo in a legacy job.
> If someone enters a typo into LIBS_FROM_GIT, it will no longer fail.
> However, I think the risk is worthwhile -- particularly since it is in
> service of a system which eliminates the opportunity to introduce such
> an error in the first place.
>
> To see the result in action, take a look at this change which, in only a
> few lines, implements what was a significantly more complex undertaking
> in Zuul v2:
>
> https://review.openstack.org/548331
>
> Finally, a note on the automatic generation of LIBS_FROM_GIT -- if, for
> some reason, you require a new-style devstack job to manually set
> LIBS_FROM_GIT, that will still work.  Simply define the variable as
> normal, and the module which generates the devstack config will bypass
> automatic generation if the variable is already set.

+1, thanks Jim. idea looks good to me as long as it still works for
non-zuulv3 users. ll check the patch.

-gmann

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

__
OpenStack Development Mailing 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] [kuryr] Cancelling this week's kuryr meeting

[Daniel Mellado]

Hi everyone!

As a lot of people are out of office due to Easter today's meeting is
cancelled.
If anything urgent comes up, feel free to use #openstack-kuryr.

Happy Easter!




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