Re: [openstack-dev] [Neutron] Stepping down from core

[reedip banerjee]

Hi Carl,
It was great working with you..
Wishing you the best of luck for your future endeavours

On Mon, Nov 21, 2016 at 3:56 PM, John Davidge 
wrote:

> It’s been a pleasure to work with you these past few years, Carl. I wish
> you all the best in whatever’s next for you. Hopefully we’ll meet again
> soon in the not so distant future.
>
> There will forever be a Carl-shaped hole in our codebase.
>
> John
>
> From: Carl Baldwin 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, November 17, 2016 at 6:42 PM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [Neutron] Stepping down from core
>
> Neutron (and Openstack),
>
> It is with regret that I report that my work situation has changed such
> that I'm not able to keep up with my duties as a Neutron core reviewer, L3
> lieutenant, and drivers team member. My participation has dropped off
> considerably since Newton was released and I think it is fair to step down
> and leave an opening for others to fill. There is no shortage of talent in
> Neutron and Openstack and I know I'm leaving it in good hands.
>
> I will be more than happy to come back to full participation in Openstack
> and Neutron in the future if things change again in that direction. This is
> a great community and I've had a great time participating and learning with
> you all.
>
> Well, I don't want to drag this out. I will still be around on IRC and
> will be happy to help out where I am able. Feel free to ping me.
>
> Carl
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Magnum] Question of k8s multiple master support.

[渥美 慶彦]

Hi Yatin, fengbeihong,

I'm using CoreOS to create Kubernetes CoreOS cluster.
Thank you so much.

Best regards,
On 2016/11/22 13:07, Yatin Karel wrote:

Hi Yoshihiko atsumi,

<<< I'm using CoreOS-1010.3.0, Magnum 2.0.1.
Is CoreOS used as a base OS or guest OS.

If You are using CoreOS to Create kubernetes CoreOS cluster, then

As you mentioned you are using Magnum 2.0.1(Mitaka),
In Mitaka, k8s-coreos cluster couldn't be created with multiple master, 
Creation of coreos cluster with multiple master is supported with newton 
release. Though, you can create multimaster kubernetes cluster with fedora 
image with Magnum 2.0.1.

If above is not correct, please share the Error and Logs as well and the 
Guide(or Steps) you followed for creating cluster.

Also, the steps mentioned by @fengbeihong are valid for newton(before newton i 
believe load balancer was enabled by default if neutron-lbaas is enabled in 
Openstack Setup), so those shared steps would not work with you.

You can also connect on IRC at #openstack-containers for further queries.


Thanks and Regards
Yatin Karel


From: 渥美 慶彦 [atsumi.yoshih...@po.ntts.co.jp]
Sent: Tuesday, November 22, 2016 7:40 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Question of k8s multiple master support.

Hi all,

Can I create the bay of Kubernetes which has multiple master?
I'm able to create the bay of Kubernetes single master, but failed in
creating the bay of Kubernetes multiple master.
I'm using CoreOS-1010.3.0, Magnum 2.0.1.

Best regards,

--

Yoshihiko Atsumi
atsumi.yoshih...@po.ntts.co.jp




__
OpenStack Development Mailing 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



--

NTTソフトウェア株式会社
クラウド＆セキュリティ事業部　第一事業ユニット
渥美 慶彦（Atsumi Yoshihiko）
〒220-0012
横浜市西区みなとみらい4-4-5 横浜アイマークプレイス13F
TEL：045-212-7539
FAX：045-212-9800
E-mail：atsumi.yoshih...@po.ntts.co.jp




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

Re: [openstack-dev] [Release-job-failures] Release of openstack/heat failed

[Tony Breeds]

On Tue, Nov 22, 2016 at 03:40:02AM +, jenk...@openstack.org wrote:
> Build failed.
> 
> - heat-docs-ubuntu-xenial 
> http://logs.openstack.org/71/71a4e63a6cf159a4e5e814a609eafaf5b447cf88/release/heat-docs-ubuntu-xenial/4f407d9/
>  : FAILURE in 3m 10s

This is a known issue for heat It's being worked[1] but the proposed fix is 
icky.

Yours Tony.

[1] https://review.openstack.org/#/c/400063/


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] [Magnum] Question of k8s multiple master support.

[Yatin Karel]

Hi Yoshihiko atsumi,

<<< I'm using CoreOS-1010.3.0, Magnum 2.0.1.
Is CoreOS used as a base OS or guest OS.

If You are using CoreOS to Create kubernetes CoreOS cluster, then

As you mentioned you are using Magnum 2.0.1(Mitaka),
In Mitaka, k8s-coreos cluster couldn't be created with multiple master, 
Creation of coreos cluster with multiple master is supported with newton 
release. Though, you can create multimaster kubernetes cluster with fedora 
image with Magnum 2.0.1.

If above is not correct, please share the Error and Logs as well and the 
Guide(or Steps) you followed for creating cluster.

Also, the steps mentioned by @fengbeihong are valid for newton(before newton i 
believe load balancer was enabled by default if neutron-lbaas is enabled in 
Openstack Setup), so those shared steps would not work with you.

You can also connect on IRC at #openstack-containers for further queries.


Thanks and Regards
Yatin Karel


From: 渥美 慶彦 [atsumi.yoshih...@po.ntts.co.jp]
Sent: Tuesday, November 22, 2016 7:40 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Magnum] Question of k8s multiple master support.

Hi all,

Can I create the bay of Kubernetes which has multiple master?
I'm able to create the bay of Kubernetes single master, but failed in
creating the bay of Kubernetes multiple master.
I'm using CoreOS-1010.3.0, Magnum 2.0.1.

Best regards,

--

Yoshihiko Atsumi
atsumi.yoshih...@po.ntts.co.jp




__
OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-21 15:12:45 -0500:
> On 18/11/16 16:47, Clint Byrum wrote:
> > Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> > I know Monty said this, but I want to say it again: gRPC is just HTTP/2
> > + protobufs. Meaning, it's available to virtually every programming
> > language in wide usage at this time (the limiting factor being protobuf
> > implementatoins):
> >
> > https://github.com/google/protobuf/blob/master/docs/third_party.md
> 
> I get that, but what I'm spending a lot of my time on is interactions 
> between OpenStack components, and that uses the OpenStack APIs because.. 
> well because they're the OpenStack APIs.
> 
> So maybe in the event of a failure occurring somewhere I want to spin up 
> some replacement resources, and then put things back how they were again 
> later, using a Mistral workflow. And say that oaktree will magically fix 
> some cross-cloud interop differences for me when I first spin up my app. 
> Now I'm faced with a bad choice: either I have to replicate the magic in 
> a second language, because OpenStack doesn't speak shade/oaktree, or I 
> have to give up on the magic and just implement everything myself, or I 
> have to give up on the idea of doing anything especially interesting at 
> runtime and hope my app just keeps working as deployed, or I have to 
> give up on ever deploying my app on more than one cloud.
> 
> The only thing that will avoid _all_ of those bad choices, and I realise 
> I am preaching to the choir here, is if we fix the APIs such that they 
> don't *need* magic to work well across clouds.
> 

So now that I understand what you're saying.. a pragmatic solution to
this might be to have Mistral and Heat use shade instead of the native
clients. An idealistic solution would be to start pushing the projects
to hide their implementation details better.

> >> I feel like the entire OpenStack project has, out of a desire not to be
> >> opinionated, consistently failed both our users and operators by
> >> encouraging all sorts of unnecessarily incompatible configurations. Not
> >> to pick on any particular project but e.g. can anyone tell me why
> >> Neutron doesn't automatically come, out of the box, with external
> >> networks called "internet" and "openstack" so that users can create
> >> floating IPs that talk to either the internet or just the control plane,
> >> respectively, on any OpenStack cloud with a single Heat template (or
> >> whatever) without having to paste UUIDs anywhere? What sane reason could
> >> there be to even allow, let alone force, all operators to solve these
> >> problems independently?
> >>
> >
> > Side note: As of right now, I'm pretty sure the only place where you
> > should have to use network UUID's pasted somewhere is Octavia.
> >
> > Also, many OpenStack clouds are not on the internet, and do not want to
> > give instances access to the control plane. So your example perhaps
> > needs more thought.
> 
> I'm not saying that you have to supply any IP addresses to the pool. 
> Just that only the wilfully contrary should call the internet anything 
> other than "internet", and that we should ensure this *in code* instead 
> of just hoping that everyone will coincidentally choose the same thing 
> (spoiler: they don't) so that both end users *and other OpenStack 
> projects* can rely on it.
> 
> (Also, the point of floating IPs with access to only the control plane 
> is not so instances can access the control plane; it's so that the 
> control plane can access the instances without everyone on the internet 
> - or whatever other external network you might connect to - necessarily 
> being able to do the same.)
> 

My point is that this is not cut and dry, and I think it deserves long,
hard thought. I _DO_ love the idea of having conventions which
application authors can begin to rely on.

> >> I'm sure the infra team can think of 100 pet annoyances like that. So
> >> carry on, but maybe y'all could make a list somewhere of all the
> >> interoperability problems that shade has had to work around and we could
> >> try to make it a priority as a community to address them?
> >>
> >
> > Shade is the python expression of those annoyances. Oaktree would be
> > exposing that as a gRPC API.
> 
> So what's the governance expression of those annoyances? :)
> 

I think community goals would be a way to address this. But we need to
first express exactly what we think is wrong with the API's now, and
then come up with a plan to normalize them. I believe the API WG and
Arch-WG might be good places to address this. The former, to address
the structure of each API, and the latter, to address the interactions
of the components.

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

[openstack-dev] [heat-translator][tosca-parser] No Weekly IRC meeting this week on Nov 24 - US holiday

[Sahdev P Zala]

Hello Team, 

A gentle reminder, as we discussed in the meeting last week, there will be 
no weekly meeting this week on Thursday Nov 24th due to Thanksgiving 
holiday in USA. 

Regards, 
Sahdev Zala

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

[openstack-dev] [Ironic] Inspect a physical node in Devstack

[Hui Wei]

Hi Rama，

Ironic inspector is a bit complicated. Different bridges are not a
problem, as log as there is layer 2
connection, and dhcp/tftp/http protocol are allowed.

I have some checkout for you.
1. Configure the baremetal  node pxe boot first in bios.
2. Make sure dnsmasq is running on the inspector node, and it provides
tftp server function.
3. checkout inspector node's iptable  rules, accept dhcp and tftp input.
4. copy deploy-kernel and deploy-ramdisk to tftp-server root directory.

Actually, do not care about inspector at first step, just power on the
baremetal node, seen if it can pxe boot successfully. After boot
successfully, test inspection.

It will very nice of you if you can update the documentation.

Thank you.

> Hi,
>
>
>
> I am attempting inspecting a physical node in a devstack environment with
> Ironic and Ironic Inspector. I have a two server setup with IPMI
> connectivity and IP addresses. My devstack environment setup is same as the
> one for Ironic/Ironic-Inspector in the docs with agent_ipmitool driver. I
> was able to build and use the deploy_kernel and deploy_ramdisk images for
> inspection on the VM nodes and see inspection data. I tried the same
> approach for the physical node. First, I created the physical node using
> "ironic node-create ..." and updated the node with the
> ir-deploy-agent_ipmitool.initramfs and ir-deploy-agent_ipmitool.kernel
> images. I was able to power cycle the node using "ironic
> node-set-power-state on/off". I tried inspecting the node and inspection
> timed out after the chassis went through power down and power up with a
> local boot.
>
>
>
> I am guessing the reason for Inspector not connecting to the node is due to
> the interfaces being on different bridges. I would appreciate your help in
> solving this issue. Once I successfully inspect the node, I will be able to
> update the documentation on this subject.
>
>
>
> Thanks very much.
>
> Rama.

__
OpenStack Development Mailing 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] [karbor] Karbor weekly irc meeting

[edison xiang]

Hi guys,

Karbor today's weekly irc meeting will be held at 09:00 UTC
#openstack-meeting.
Weclome to add your agenda at [1] and welcome to join the meeting.

[1] https://wiki.openstack.org/wiki/Meetings/Karbor

Best Regards,

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

[openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

Hi all,
I'm late in sending this announement, but I'm glad to see several projects
have already requested EOL releases to make it trivial and obvious where to
apply the tag.

I'm proposing to EOL all projects that meet one or more of the following
criteria:

- The project is openstack-dev/devstack, openstack-dev/grenade or
  openstack/requirements
- The project has the 'check-requirements' job listed as a template in
  project-config:zuul/layout.yaml
- The project gates with either devstack or grenade jobs
- The project is listed in governance:reference/projects.yaml and is tagged
  with 'stable:follows-policy'.


Some statistics:
All Repos  : 1493 (covered in zuul/layout.yaml)
Checked Repos  :  406 (match one or more of the above criteria)
Repos with liberty branches:  305
EOL Repos  :  171 (repos that match the criteria *and* have
   a liberty branch) [1]
NOT EOL Repos  :  134 (repos with a liberty branch but
   otherwise do not match) [2]
DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
   liberty branches)
Open Reviews   :   94 (reviews to close)


Please look over both lists by 2016-11-27 00:00 UTC and let me know if:
- A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing and
  why.  Note doing this will amost certainly reduce the testing coverage you
  have in the gate.
- A project is in list 2 that would like to opt *IN* to tagging/EOLing

Any projects that will be EOL'd will need all open reviews abandoned before it
can be processed.  I'm very happy to do this, or if I don't have permissios to
do it ask a gerrit admin to do it.

I'll batch the removal of the stable/liberty branches between Nov 28th and Dec
3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup zuul/layout.yaml
to remove liberty exclusions and jobs.

Yours Tony.

[1] 
https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L1
[2] 
https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L181


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] [Magnum] Question of k8s multiple master support.

[峰北红]

Hi atsumi,

Multiple masters must be created together with load balancer.

Create cluster template with `--master-lb-enabled`.

magnum cluster-template-create --name k8s-cluster-template --image-id
test.qcow2 \
  --keypair-id testkey \
  --external-network-id public \
  --dns-nameserver 8.8.8.8 \
  --flavor-id m1.medium \
  --coe k8s \
  --master-lb-enabled


And specify master count when you create cluster.

magnum cluster-create --name dcos-cluster --cluster-template
dcos-cluster-template --node-count 1 --master-count 3


Best regards,
fengbeihong

2016-11-22 10:10 GMT+08:00 渥美 慶彦 :

> Hi all,
>
> Can I create the bay of Kubernetes which has multiple master?
> I'm able to create the bay of Kubernetes single master, but failed in
> creating the bay of Kubernetes multiple master.
> I'm using CoreOS-1010.3.0, Magnum 2.0.1.
>
> Best regards,
>
> --
> 
> Yoshihiko Atsumi
> atsumi.yoshih...@po.ntts.co.jp
> 
>
>
>
> __
> OpenStack Development Mailing 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] [Magnum] Question of k8s multiple master support.

[渥美 慶彦]

Hi all,

Can I create the bay of Kubernetes which has multiple master?
I'm able to create the bay of Kubernetes single master, but failed in  
creating the bay of Kubernetes multiple master.

I'm using CoreOS-1010.3.0, Magnum 2.0.1.

Best regards,

--

Yoshihiko Atsumi
atsumi.yoshih...@po.ntts.co.jp




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

Re: [openstack-dev] [ironic] [stable] Proposing Jay Faulkner for ironic-stable-maint

[Tony Breeds]

On Wed, Nov 16, 2016 at 02:02:44PM +0100, Dmitry Tantsur wrote:
> Hi!
> 
> I'm formally proposing that the ironic-stable-maint team [1] adds Jay
> Faulkner. He's been consistently reviewing stable patches as shown by [2]. I
> fully trust that his operator experience will help his judgment on not
> landing dangerous things :)
> 
> So for those on the team already, please reply with a +1 or -1 vote.

Clearly not an ironic core but with the stable-maint-core hat on it's a +1 from
me!  Jay does good work on the ironic stable branches :)

Go Jay!

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] [swg] SWG meeting Thursday, 11/24 cancelled

[Colette Alexander]

Hi SWGers,

Due to the fact that most of the group will be away for the US
Thanksgiving holiday, I'm cancelling our SWG meeting in
#openstack-meeting-3. See you all on December 8th, at 1400 UTC, and
have a great holiday!

-colette/gothicmindfood

__
OpenStack Development Mailing 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] [swg][tc] An attempt to clarify/discuss: what exactly is the Stewardship Working Group, anyhow?

[Colette Alexander]

Hi OpenStackers!

At the last Stewardship Working Group (SWG) meeting[0], we discussed a lot
of the feedback that we received in our cross project session and our panel
discussion in Barcelona from people who were wondering what, exactly, the
Stewardship Working Group is and what they do.

I thought it might be appropriate to bring that discussion to the mailing
list, so... here we are.

So, what do we do exactly?

A lot of that is, like other OpenStack projects, kind of up to whoever
shows up.

But, the current history/summary of what has happened with people who've
showed up so far:

The SWG was founded[1] after some members of the TC and some members of the
community attended a leadership training in Ann Arbor, in June of 2016. The
two day workshop covered a variety of topics, including a few key concepts
that I felt mirrored our own values in the community: servant leadership,
visioning, and how to implement change successfully. Out of those two days,
a third day devoted to talking about what we learned and how it might apply
to OpenStack led us to think about forming the SWG. Anne Gentle wrote a
great summary for the OpenStack blog, covering some of these.[2]

When I first thought about the SWG during that day of discussion, I saw it
as having two potential areas of work: 1) researching and discussing ideas
around stewardship and leadership and assessing issues that might arise in
the community in order to make recommendations to the TC around governance,
leadership, and anything related to culture (including, especially,
documenting that culture). And 2) providing/organizing resources for
*anyone* in the entire OpenStack community who is interested in adding to
their leadership skills, or who needs help understanding a less-technical
problem, more-people-problem that comes up. (And I mean "understand"
through any mechanism: resources/training provided, discussions had on the
#openstack-swg IRC channel, in meetings, or in personal discussion) In my
wildest dreams, we would also provide support and learning pathways about
OpenStack's culture and leadership values to anyone in the community.

The major value of the training that was echoed by all participants was
that it wasn't run-of-the-mill "corporate" leadership training - it focused
in on concepts and skills that were far more applicable in our open
governance/open participation environment. Anything that is provided to the
community by the SWG should pass the same smell test.

I feel rather strongly (and have even said so even while being filmed[3])
that OpenStack can often suffer from an avoidance in its culture - people
will tend to look away/walk away/close tabs in another direction when faced
with something that potentially involves having a difficult conversation
with someone or multiple people (especially if those people are in
unfamiliar groups/work at unfamiliar companies). How might we all feel more
comfortable asking each other difficult questions and having constructive
debate that ultimately will lead to a healthier more sustainable and
diverse community? I hope that the SWG can provide a kind of "safe space"
(even just for your brain to think about a thing) to spark some of that
change.

What are the sorts of things you'd like to see tackled? Some thoughts were
thrown up in the etherpad during our cross project session in Barcelona[4]
that might start good discussion here.

Any thoughts/debate/ideas on where we should go and what we should do are
most welcome here or on the other standard channels. I'm currently in the
process of writing a draft vision for where we'd like the group to be and
what we'd like to accomplish before and during the PTG in Atlanta. I'd love
to get more people involved. On account of the US/Thanksgiving holiday, our
next meeting will be Dec. 8, 1400 UTC in #openstack-meeting-3 so please
join us in #openstack-swg in the meantime and say hello.

Thanks!

-colette/gothicmindfood


[0]
http://eavesdrop.openstack.org/meetings/openstack_swg/2016/openstack_swg.2016-11-08-15.04.log.txt
[1] https://governance.openstack.org/resolutions/20160705-stewardship.html
[2]
http://www.openstack.org/blog/2016/07/technical-committee-highlights-july-17-2016/
[3] https://www.youtube.com/watch?v=juGktZ3xabA=1430s
[4] https://etherpad.openstack.org/p/Barcelona-SWG-cp
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] Inspect a physical node in Devstack

[Yeleswarapu, Ramamani]

Hi,

I am attempting inspecting a physical node in a devstack environment with 
Ironic and Ironic Inspector. I have a two server setup with IPMI connectivity 
and IP addresses. My devstack environment setup is same as the one for 
Ironic/Ironic-Inspector in the docs with agent_ipmitool driver. I was able to 
build and use the deploy_kernel and deploy_ramdisk images for inspection on the 
VM nodes and see inspection data. I tried the same approach for the physical 
node. First, I created the physical node using "ironic node-create ..." and 
updated the node with the ir-deploy-agent_ipmitool.initramfs and 
ir-deploy-agent_ipmitool.kernel images. I was able to power cycle the node 
using "ironic node-set-power-state on/off". I tried inspecting the node and 
inspection timed out after the chassis went through power down and power up 
with a local boot.

I am guessing the reason for Inspector not connecting to the node is due to the 
interfaces being on different bridges. I would appreciate your help in solving 
this issue. Once I successfully inspect the node, I will be able to update the 
documentation on this subject.

Thanks very much.
Rama.
__
OpenStack Development Mailing 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] POC patch for using tripleo-repos for repo setup

[Alex Schultz]

On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec  wrote:
> Hi,
>
> I have a POC patch[1] up to demonstrate the use of the tripleo-repos tool
> [2] as a replacement for most of tripleo.sh --repo-setup.  It has now passed
> all of the CI jobs so I wanted to solicit some feedback.
>
> There are a few changes related to repo naming because the tool names repo
> files based on the repo name rather than always calling them something
> generic like delorean.repo.  I think it's less confusing to have the
> delorean-newton repo file named delorean-newton.repo, but I'm open to
> discussion on that.
>
> If no one has any major objections to how the tool looks/works right now,
> I'll proceed with the work to get it imported into the openstack namespace
> as part of TripleO.  We can always iterate on it after import too, of
> course, so this isn't a speak now or forever hold your peace situation. :-)
>

Why a python standalone application for the management of specifically
(and only?) tripleo repositories.  It seems we should be trying to
leverage existing tooling and not hiding the problem behind a python
app.  It's not that I enjoy the current method described in the spec
(3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
write 586 lines of python and tests might be the wrong approach.
Would it be better to just devote some time to rpm generation for
these and deliver it in discrete RPMs?  'yum install
http://tripleo.org/repos-current.rpm' seems way more straight forward.

Thanks,
-Alex

> 1: https://review.openstack.org/#/c/395813
> 2:
> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tripleo-repos.html
> (note that this spec was mistakenly submitted as a policy, it will be moving
> to the ocata directory soon)
>
> 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/21/2016 03:36 PM, Zane Bitter wrote:
> On 18/11/16 16:56, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for orchestration. How would I go about e.g. making
>>> sure that the servers are always connected to the networks I expect on a
>>> variety of different clouds? Would Oaktree figure out the networks and
>>> pass them in to the stack when creating it? (I don't believe shade has
>>> Heat support yet, but we should definitely add it & I don't foresee any
>>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>>
>>
>> If you're wanting to use Heat, you are a) already cutting off a large
>> quantity of interoperable clouds because many do not have Heat,
> 
> (Roughly one third, according to the user survey.) We have a mechanism
> to resolve that though (defcore), and I'm confident that that will
> happen in due course. I'm less confident that we have any mechanism for
> resolving these other questions.
> 
> Perhaps we could use defcore-required Tempest tests to drive alignment
> on some of those too. But we'd have to decide what we want to align on
> first.
> 
>> and b)
>> you already have provider templates to deal with the inconsistencies
>> across clouds.
> 
> Indeed, and environment files and conditionals as well.
> 
>> And Shade has had Heat support in some for or another for a long time:
>>
>> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import
>> heatclient.client
> 
> Oh, great! I knew it had been on the agenda for a while but I didn't
> know if it had actually happened or not, so I had a quick glance at
> http://docs.openstack.org/infra/shade/model.html and there was no mention.

Yah - the model documentation is new, and we're going through resource
by resource to make sure we've published exactly what attributes of what
resources we can commit to making sure are there, and which ones may or
may not be there based on underlying cloud differences.

>> To answer your other question, I don't think that's actually desirable or
>> realistic for interop expectations. If networking were one-size-fits-all
>> we wouldn't even need Neutron (we had a one-size-fits-all solution, it
>> was
>> nova-network). We have Neutron so you can construct what you need inside
>> the cloud.
> 
> I'd prefer that we treat Neutron as a way to construct a consistent set
> of abstractions that users can rely on to construct what they need,
> rather than a way to expose the implementation decisions of the operator
> to the user.
> 
> (Ditto for all OpenStack projects, actually.)

ZOMG yes.

>> Shade just normalizes the "how do I get to the instances from
>> outside the cloud" part, which has several different variants.
>>
>>> It sounds to me like the former approach would require all of the same
>>> work in the template that you'd need to handle it now (using
>>> conditionals), and the only real difference is that instead of providing
>>> your own environment file for each cloud you do a bit of oaktree
>>> integration and that figures it out for you instead.
>>>
>>> Adding Oaktree resource types to Heat to paper over isn't really a
>>> solution from my point of view.
>>>
>>
>> Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
>> Mostly just to avoid needing to grok Keystone and all of its glory.
>>
>> __
>>
>> OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/21/2016 03:25 PM, Kevin Benton wrote:
>>I'm not saying that you have to supply any IP addresses to the pool.
> Just that only the wilfully contrary should call the internet anything
> other than "internet", and that we should ensure this *in code* instead
> of just hoping that everyone will coincidentally choose the same thing
> (spoiler: they don't) so that both end users *and other OpenStack
> projects* can rely on it.
> 
> A big chunk of enterprise deployments I see don't have real Internet IPs
> available as floating IPs, they are just IP addresses reachable from the
> whole company network. They are available everywhere they need for their
> use cases so all tooling they use can effectively treat them as
> "Internet" addresses (reachable from everywhere in their corporate
> network), but they are not the real Internet. 
> 
> So either you force them to lie and call it "internet" to work with
> tooling that expects that, or they can't use any tooling built on this
> new concept of "internet". Pick your poison.

Yah. In shade we refer to these as "external" and the docs say
"externally routable" - which more specifically means "able to route to
things that are not on this cloud". (this is because of the very thing
you mention.

In general, there are a few network constructs that seem to come up a
lot but can easily get lost in bikeshedding our way towards perfection:

* This network can route packets to things that are not on this cloud
* This network can provide IPs to be used for NAT
* This network can provide IPs that can be used directly
* This network can be the destination of NAT

Also, clouds frequently have one or more of the following network
connection policies:

* Route traffic in and out of the cloud via NAT
* Route traffic in and out of the cloud directly
* Only route traffic to other instances in this cloud

AND - as if those are not enough, there is also:

* This cloud has IPv4 and IPv6
* This cloud only has IPv4
* This cloud only has IPv6

Because you can combine all of those in any way you want, you can end up
with:

* This cloud has a network that will directly attach IPv6 addresses that
can route traffic in and out of the cloud but will attach IPv4 addresses
that require NAT to get in and out of the cloud.

> On Mon, Nov 21, 2016 at 12:12 PM, Zane Bitter  > wrote:
> 
> On 18/11/16 16:47, Clint Byrum wrote:
> 
> Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> 
> On 15/11/16 09:56, Monty Taylor wrote:
> 
> Hey everybody!
> 
> At this past OpenStack Summit the results of the Interop
> Challenge were
> shown on stage. It was pretty awesome - 17 different
> people from 17
> different clouds ran the same workload. And it worked!
> 
> However, one of the reasons it worked is because they
> all used the
> Ansible modules we wrote that are based on the shade
> library that
> contains the business logic needed to hide vendor
> differences in clouds.
> That means that there IS a fantastic OpenStack
> interoperability story -
> but only if you program in Python. That's less awesome.
> 
> 
> So I don't want to criticise this effort, because I'm sure
> that it's
> very valuable and worthy 
> 
> But it does make me sad that we've so thoroughly given up on
> the concept
> of making the OpenStack APIs themselves interoperable that we're
> building an API for our APIs (Yo dawg!) to work around it.
> 
> 
> One could argue that this is just the natural order of things in
> a world
> where programmers are disciplined and practice separation of
> concerns.
> 
> 
> Sure, but the argument would be more convincing if having a bunch of
> interoperable clouds were not the *entire point* of OpenStack :)
> 
> Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
> simply be for multi-cloud users.
> 
> IMO, it's actually just sad, and I'd like for every project's
> API to be
> evolved for multi-cloud users. But seeing as I've seen so very
> little
> of that actually happening, splitting it out seems like a reasonable
> compromise.
> 
> 
> I think we're in agreement.
> 
> The problem is that to take advantage of the
> interoperability benefits
> you'll be locked in to a single orchestration tool
> (Ansible/shade). If
> you have a particular reason to use another tool (possibly,
> ahem, the
> one that is an official part of OpenStack and already
> available in 2/3
> of 

Re: [openstack-dev] [nova] Welcome Lee Yarwood to nova-stable-maint core

[Tony Breeds]

On Thu, Nov 17, 2016 at 07:53:46AM -0600, Matt Riedemann wrote:
> I've added Lee Yarwood to the nova-stable-maint core team:
> 
> https://review.openstack.org/#/admin/groups/540,members
> 
> Lee has done a great job the last few months of proposing backports and
> reviewing changes to nova on the stable branches. So please help me in
> welcoming and congratulating Lee on being added to the stable core team for
> Nova.

Congrats Lee!

Great to have you onboard!

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] [keystone] Pike PTL

[Rodrigo Duarte]

On Mon, Nov 21, 2016 at 5:22 PM, Lance Bragstad  wrote:

> Steve, thanks for all the hard work and dedication over the last 3 cycles.
> I hope you have a nice break and I look forward to working with you on Pike!
>

I could not say better! Thanks for everything Steve.


>
> Enjoy you're evenings :)
>

I'm sure they will be full of Harry! :)


>
>
>
> On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli 
> wrote:
>
>> one of these days i'll learn how to spell :)
>>
>> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli <
>> s.martine...@gmail.com> wrote:
>>
>>> Keystoners,
>>>
>>> I do not intend to run for the PTL position of the Pike development
>>> cycle. I'm sending this out early so I can work with folks interested in
>>> the role, If you intend to run for PTL in Pike and are interested in
>>> learning the ropes (or just want to hear more about what the role means)
>>> then shoot me an email.
>>>
>>> It's been an unforgettable ride. Being PTL a is very rewarding
>>> experience, I encourage anyone interested to put your name forward. I'm
>>> not going away from OpenStack, I just think three terms as PTL has been
>>> enough. It'll be nice to have my evenings back :)
>>>
>>> To *all* the keystone contributors (cores and non-cores), thank you for
>>> all your time and commitment. More importantly thank you for putting up
>>> with my many questions, pings, pokes and -1s. Each of you are amazing and
>>> together you make an awesome team. It has been an absolute pleasure to
>>> serve as PTL, thank you for letting me do so.
>>>
>>> stevemar
>>>
>>>
>>> 
>>>
>>> Thanks for the idea Lana [1]
>>> [1] http://lists.openstack.org/pipermail/openstack-docs/2016
>>> -November/009357.html
>>>
>>
>>
>> 
>> __
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.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-dev] [tripleo] POC patch for using tripleo-repos for repo setup

[Ben Nemec]

Hi,

I have a POC patch[1] up to demonstrate the use of the tripleo-repos 
tool [2] as a replacement for most of tripleo.sh --repo-setup.  It has 
now passed all of the CI jobs so I wanted to solicit some feedback.


There are a few changes related to repo naming because the tool names 
repo files based on the repo name rather than always calling them 
something generic like delorean.repo.  I think it's less confusing to 
have the delorean-newton repo file named delorean-newton.repo, but I'm 
open to discussion on that.


If no one has any major objections to how the tool looks/works right 
now, I'll proceed with the work to get it imported into the openstack 
namespace as part of TripleO.  We can always iterate on it after import 
too, of course, so this isn't a speak now or forever hold your peace 
situation. :-)


1: https://review.openstack.org/#/c/395813
2: 
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tripleo-repos.html 
(note that this spec was mistakenly submitted as a policy, it will be 
moving to the ocata directory soon)


Thanks.

-Ben

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Jeremy Stanley]

On 2016-11-21 15:12:45 -0500 (-0500), Zane Bitter wrote:
[...]
> (Also, the point of floating IPs with access to only the control plane is
> not so instances can access the control plane; it's so that the control
> plane can access the instances without everyone on the internet - or
> whatever other external network you might connect to - necessarily being
> able to do the same.)
[...]

Probably just my knee jerking over what seems like yet another
gratuitously unnecessary use of NAT here, but why not simply use
packet filtering (and if necessary, additional virtual NICs)?
-- 
Jeremy Stanley

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Steve Baker]

On Tue, Nov 22, 2016 at 9:36 AM, Zane Bitter  wrote:

> On 18/11/16 16:56, Clint Byrum wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for orchestration. How would I go about e.g. making
>>> sure that the servers are always connected to the networks I expect on a
>>> variety of different clouds? Would Oaktree figure out the networks and
>>> pass them in to the stack when creating it? (I don't believe shade has
>>> Heat support yet, but we should definitely add it & I don't foresee any
>>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>>
>>>
>> If you're wanting to use Heat, you are a) already cutting off a large
>> quantity of interoperable clouds because many do not have Heat,
>>
>
> (Roughly one third, according to the user survey.) We have a mechanism to
> resolve that though (defcore), and I'm confident that that will happen in
> due course. I'm less confident that we have any mechanism for resolving
> these other questions.
>
> Perhaps we could use defcore-required Tempest tests to drive alignment on
> some of those too. But we'd have to decide what we want to align on first.
>
> and b)
>> you already have provider templates to deal with the inconsistencies
>> across clouds.
>>
>
> Indeed, and environment files and conditionals as well.
>
> And Shade has had Heat support in some for or another for a long time:
>>
>> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import
>> heatclient.client
>>
>
> Oh, great! I knew it had been on the agenda for a while but I didn't know
> if it had actually happened or not, so I had a quick glance at
> http://docs.openstack.org/infra/shade/model.html and there was no mention.
>
>
Shade has decent heat support [1] which is behind the os_stack module
available in Ansible 2.2 [2]

My personal workflow involves a lot of ansible playbooks creating/updating
heat stacks then doing other things, and having the os_stack module has
made this much cleaner.

[1]
http://docs.openstack.org/infra/shade/usage.html#shade.OpenStackCloud.create_stack
etc
[2] https://docs.ansible.com/ansible/os_stack_module.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

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

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

1. portgroup: review code  
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1618754
2. attach/detach: review code (after sambetts updates): 
https://review.openstack.org/#/c/327046/
3. boot from volume: review volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231
4. next notifications: review code: 
https://review.openstack.org/#/q/topic:bug/1606520
5. getting tests out of tempest tree (jroll working on code, will update when 
there's things to land)
6. next driver comp patch (database foo) to review: 
https://review.openstack.org/396681
7. rolling upgrades spec needs reviews: https://review.openstack.org/#/c/299245/


Bugs (dtantsur)
===
- Stats (diff between 14 Nov 2016 and 21 Nov 2016)
- Ironic: 238 bugs (+5) + 220 wishlist items. 41 new (+6), 183 in progress 
(+2), 1 critical, 27 high and 23 incomplete
- Inspector: 13 bugs (+1) + 21 wishlist items. 2 new, 11 in progress (+1), 0 
critical, 2 high (+1) and 2 incomplete
- Nova bugs with Ironic tag: 11. 0 new, 0 critical, 1 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- yet another multitenancy spec update, configuration-related fields in 
portgroup objects - https://review.openstack.org/396610
- portgroups patches need reviews: 
https://review.openstack.org/#/q/topic:bug/1618754
- portgroup spec (in nova) needs approval before nova spec freeze deadline 
Nov 17: https://review.openstack.org/#/c/387534/ -- APPROVED

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- (lucasagomes): postgres jobs now runs with IPMI and Standard PXE, the job 
is current broken and the patch fixing it is: 
https://review.openstack.org/#/c/399485/
- dropping ironic from tempest code still in progress, have had some back 
and forth with qa team on how to handle a particular flag

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rollindg-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- spec was updated, needs reviews: https://review.openstack.org/299245
- Work is ongoing for enabling Grenade with multi-tenant: 
https://review.openstack.org/389268
- Discovered issue in project-config settings that ironic devstack 
plugin enabled twice.
- Fix proposed: https://review.openstack.org/396802 in project-config

Security groups (jroll)
===
* trello: 
https://trello.com/c/klty7VVo/30-security-groups-for-provisioning-cleaning-network
- status as of most recent weekly meeting:
- Very close to being merged needs reviews: 
https://review.openstack.org/#/c/361451/

Interface attach/detach API (sambetts)
==
* trello: https://trello.com/c/nryU4w58/39-interface-attach-detach-api
- status as of most recent weekly meeting:
- Spec merged and Nova BP approved
- Code patches need updates to align with most recent version of the spec. 
sambetts hopes to get the ironic patches updated today:
- Ironic - https://review.openstack.org/327046
- Nova - https://review.openstack.org/364413
- IronicClient - https://review.openstack.org/364420

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- reviews needed for volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- first patches are merged, still a few to review and more to write
- jroll agreed to help with API part in parallel

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- status as of most recent weekly meeting:
- patch for API/Conductor methods needs review: 
https://review.openstack.org/#/c/350831/

etags in the REST API (gzholtkevych)

* trello: https://trello.com/c/MbNA4geB/33-rest-api-etags
- status as of most recent weekly meeting:
- (gzholtkevych) spec needs review: 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 18/11/16 16:56, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:

So, say that I want to create my servers in Heat so that I can use Heat
software deployments for orchestration. How would I go about e.g. making
sure that the servers are always connected to the networks I expect on a
variety of different clouds? Would Oaktree figure out the networks and
pass them in to the stack when creating it? (I don't believe shade has
Heat support yet, but we should definitely add it & I don't foresee any
great obstacle.) Or would Heat have to add Oaktree resource types?



If you're wanting to use Heat, you are a) already cutting off a large
quantity of interoperable clouds because many do not have Heat,


(Roughly one third, according to the user survey.) We have a mechanism 
to resolve that though (defcore), and I'm confident that that will 
happen in due course. I'm less confident that we have any mechanism for 
resolving these other questions.


Perhaps we could use defcore-required Tempest tests to drive alignment 
on some of those too. But we'd have to decide what we want to align on 
first.



and b)
you already have provider templates to deal with the inconsistencies
across clouds.


Indeed, and environment files and conditionals as well.


And Shade has had Heat support in some for or another for a long time:

9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
heatclient.client


Oh, great! I knew it had been on the agenda for a while but I didn't 
know if it had actually happened or not, so I had a quick glance at 
http://docs.openstack.org/infra/shade/model.html and there was no mention.



To answer your other question, I don't think that's actually desirable or
realistic for interop expectations. If networking were one-size-fits-all
we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
nova-network). We have Neutron so you can construct what you need inside
the cloud.


I'd prefer that we treat Neutron as a way to construct a consistent set 
of abstractions that users can rely on to construct what they need, 
rather than a way to expose the implementation decisions of the operator 
to the user.


(Ditto for all OpenStack projects, actually.)

- ZB


Shade just normalizes the "how do I get to the instances from
outside the cloud" part, which has several different variants.


It sounds to me like the former approach would require all of the same
work in the template that you'd need to handle it now (using
conditionals), and the only real difference is that instead of providing
your own environment file for each cloud you do a bit of oaktree
integration and that figures it out for you instead.

Adding Oaktree resource types to Heat to paper over isn't really a
solution from my point of view.



Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
Mostly just to avoid needing to grok Keystone and all of its glory.

__
OpenStack Development Mailing 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] OpenStack Developer Mailing List Digest November 5-18

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/11/openstack-developer-mailing-list-digest-20161118/

SuccessBot Says
===
* mriedem: We’re now running neutron by default in Ocata CI jobs [1].
* stevemar: fernet token format is now the default format in keystone! thanks
  lbragstad samueldmq and dolphm for making this happen!
* Ajaegar: developer.openstack.org is now hosted by OpenStack infra.
* Tonyb: OpenStack requirements on pypi [2] is now a thing!
* All

Registration Open For the Project Teams Gathering
=
* The first OpenStack Project Teams Gathering event geared toward existing
  upstream team members, providing a venue for those project teams to meet,
  discuss and organize the development work for the Pike release.
* Where: Atlanta, GA
* When: The week of February 20, 2017
* Register and get more info [3]
* Read the FAQ for any questions. If you still have questions, contact Thierry
  (ttx) over IRC on free node, or email foundation staff at p...@openstack.org.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106995.html

Follow up on Barcelona Review Cadence Discussions
=
* Summary of concerns were Nova is a complex beast. Very few people know even
  most of it well.
* There are areas in Nova where mistakes are costly and hard to rectify later.
* Large amount of code does not merge quickly.
* Barrier of entry for Nova core is very high.
* Subsystem maintainer model has been pitched [4].
* Some believe this is still worth giving a try again in attempt to merge good
  code quickly.
* Nova today uses a list of experts [5] to sign off on various changes today.
* Nova PTL Matt Riedemann’s take:
  - Dislikes the constant comparison of Nova and the Linux kernel. Lets instead
say all of OpenStack is the Linux Kernel, and the subsystems are Nova,
Cinder, Glance, etc.
  - The bar for Nova core isn’t as high as some people make it out to be:
-- Involvement
-- Maintenance
-- Willingness to own and fix problems.
-- Helpful code reviews.
  - Good code is subjective. A worthwhile and useful change might actually
break some other part of the system.
  - Nova core Jay Pipes is supportive of the proposal of subsystems, but with
a commitment to gathering data about total review load, merge velocity, and
some kind of metric to assess code quality impact.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106858

Embracing New Languages in OpenStack

* Technical Committee member Flavio Percoco proposes a list of what the
  community should know/do before accepting a new language:
  - Define a way to share code/libraries for projects using the language
-- A very important piece is feature parity on the operator.
-- Oslo.config for example, our config files shouldn't change because of a 
different implementation language.
-- Keystone auth to drive more service-service interactions through the
   catalog to reduce the number of things an operator needs to configure
   directly.
-- oslo.log so the logging is routed to the same places and same format as
   other things.
-- oslo.messaging and oslo.db as well
-- Work on a basic set of libraries for OpenStack base services
-- Define how the deliverables are distributed
-- Define how stable maintenance will work
-- Setup the CI pipelines for the new language
-- Requirements management and caching/mirroring for the gate.
-- Longer version of this [6].
* Previous notes when the Golang discussion was started to work out questions
  [7].
* TC member Thierry Carrez says the most important in introducing the Go should
  not another way for some of our community to be different, but another way
  for our community to be one.
* TC member Flavio Percoco sees part of the community wide concerns that were
  raised originated from the lack of an actual process of this evaluation to be
  done and the lack of up front work, which is something trying to be addressed
  in this thread.
* TC member Doug Hellmann request has been to demonstrate not just that Swift
  needs Go, but that Swift is willing to help the rest of the community in the
  adoption.
  - Signs of that is happening, for example discussion about how oslo.config
can be used in the current version of Swift.
* Flavio has started a patch that documents his post and the feedback from the 
thread [8]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106877

API Working Group News
==
* Guidelines that have been recently merged:
  - Clarify why CRUD is not a great descriptor [9]
  - Add guidelines for complex queries [10]
  - Specify time intervals based filtering queries [11]
* Guidelines currently under review:
  - Define pagination guidelines [12]
  - WIP add 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Kevin Benton]

>I'm not saying that you have to supply any IP addresses to the pool. Just
that only the wilfully contrary should call the internet anything other
than "internet", and that we should ensure this *in code* instead of just
hoping that everyone will coincidentally choose the same thing (spoiler:
they don't) so that both end users *and other OpenStack projects* can rely
on it.

A big chunk of enterprise deployments I see don't have real Internet IPs
available as floating IPs, they are just IP addresses reachable from the
whole company network. They are available everywhere they need for their
use cases so all tooling they use can effectively treat them as "Internet"
addresses (reachable from everywhere in their corporate network), but they
are not the real Internet.

So either you force them to lie and call it "internet" to work with tooling
that expects that, or they can't use any tooling built on this new concept
of "internet". Pick your poison.

On Mon, Nov 21, 2016 at 12:12 PM, Zane Bitter  wrote:

> On 18/11/16 16:47, Clint Byrum wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
>>
>>> On 15/11/16 09:56, Monty Taylor wrote:
>>>
 Hey everybody!

 At this past OpenStack Summit the results of the Interop Challenge were
 shown on stage. It was pretty awesome - 17 different people from 17
 different clouds ran the same workload. And it worked!

 However, one of the reasons it worked is because they all used the
 Ansible modules we wrote that are based on the shade library that
 contains the business logic needed to hide vendor differences in clouds.
 That means that there IS a fantastic OpenStack interoperability story -
 but only if you program in Python. That's less awesome.

>>>
>>> So I don't want to criticise this effort, because I'm sure that it's
>>> very valuable and worthy 
>>>
>>> But it does make me sad that we've so thoroughly given up on the concept
>>> of making the OpenStack APIs themselves interoperable that we're
>>> building an API for our APIs (Yo dawg!) to work around it.
>>>
>>>
>> One could argue that this is just the natural order of things in a world
>> where programmers are disciplined and practice separation of concerns.
>>
>
> Sure, but the argument would be more convincing if having a bunch of
> interoperable clouds were not the *entire point* of OpenStack :)
>
> Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
>> simply be for multi-cloud users.
>>
>> IMO, it's actually just sad, and I'd like for every project's API to be
>> evolved for multi-cloud users. But seeing as I've seen so very little
>> of that actually happening, splitting it out seems like a reasonable
>> compromise.
>>
>
> I think we're in agreement.
>
> The problem is that to take advantage of the interoperability benefits
>>> you'll be locked in to a single orchestration tool (Ansible/shade). If
>>> you have a particular reason to use another tool (possibly, ahem, the
>>> one that is an official part of OpenStack and already available in 2/3
>>> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
>>> choose between whatever feature you wanted there and interoperability.
>>> That's taking "there IS a fantastic OpenStack interoperability story -
>>> but only if you program in Python" and kicking the can one step down the
>>> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
>>> underlying APIs then *everyone* benefits.
>>>
>>>
>> I know Monty said this, but I want to say it again: gRPC is just HTTP/2
>> + protobufs. Meaning, it's available to virtually every programming
>> language in wide usage at this time (the limiting factor being protobuf
>> implementatoins):
>>
>> https://github.com/google/protobuf/blob/master/docs/third_party.md
>>
>
> I get that, but what I'm spending a lot of my time on is interactions
> between OpenStack components, and that uses the OpenStack APIs because..
> well because they're the OpenStack APIs.
>
> So maybe in the event of a failure occurring somewhere I want to spin up
> some replacement resources, and then put things back how they were again
> later, using a Mistral workflow. And say that oaktree will magically fix
> some cross-cloud interop differences for me when I first spin up my app.
> Now I'm faced with a bad choice: either I have to replicate the magic in a
> second language, because OpenStack doesn't speak shade/oaktree, or I have
> to give up on the magic and just implement everything myself, or I have to
> give up on the idea of doing anything especially interesting at runtime and
> hope my app just keeps working as deployed, or I have to give up on ever
> deploying my app on more than one cloud.
>
> The only thing that will avoid _all_ of those bad choices, and I realise I
> am preaching to the choir here, is if we fix the APIs such that they don't
> *need* magic to work well across clouds.
>
> I feel like the entire 

Re: [openstack-dev] [ironic] Ironic-qa meeting canceled this week (Nov 23rd)

[Jim Rollenhagen]

On Mon, Nov 21, 2016 at 3:23 PM, Kurt Taylor  wrote:
> Hey everyone, due to projected low turnout for this weeks ironic-qa meeting,
> it will be canceled. I will update the wiki meeting page to reflect this.
>
> FYI, I brought up a proposal last week to merge this meeting back into the
> main Monday ironic meeting, and handle any work via sub team reports.
> Comments?

As a note, this was discussed in this morning's ironic meeting,
nobody was against it. We're waiting for John V's opinion before
cancelling it for real, but everyone's comments are welcome of
course.

// jim

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

[openstack-dev] [ironic] Ironic-qa meeting canceled this week (Nov 23rd)

[Kurt Taylor]

Hey everyone, due to projected low turnout for this weeks ironic-qa
meeting, it will be canceled. I will update the wiki meeting page to
reflect this.

FYI, I brought up a proposal last week to merge this meeting back into the
main Monday ironic meeting, and handle any work via sub team reports.
Comments?

Kurt Taylor (krtaylor)
__
OpenStack Development Mailing 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] [keystone] Pike PTL

[Lance Bragstad]

Steve, thanks for all the hard work and dedication over the last 3 cycles.
I hope you have a nice break and I look forward to working with you on Pike!

Enjoy you're evenings :)



On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli 
wrote:

> one of these days i'll learn how to spell :)
>
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli  > wrote:
>
>> Keystoners,
>>
>> I do not intend to run for the PTL position of the Pike development
>> cycle. I'm sending this out early so I can work with folks interested in
>> the role, If you intend to run for PTL in Pike and are interested in
>> learning the ropes (or just want to hear more about what the role means)
>> then shoot me an email.
>>
>> It's been an unforgettable ride. Being PTL a is very rewarding
>> experience, I encourage anyone interested to put your name forward. I'm
>> not going away from OpenStack, I just think three terms as PTL has been
>> enough. It'll be nice to have my evenings back :)
>>
>> To *all* the keystone contributors (cores and non-cores), thank you for
>> all your time and commitment. More importantly thank you for putting up
>> with my many questions, pings, pokes and -1s. Each of you are amazing and
>> together you make an awesome team. It has been an absolute pleasure to
>> serve as PTL, thank you for letting me do so.
>>
>> stevemar
>>
>>
>> 
>>
>> Thanks for the idea Lana [1]
>> [1] http://lists.openstack.org/pipermail/openstack-docs/2016
>> -November/009357.html
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] layer/source charm project-config changes

[Ryan Beisner]

Good day OpenStack Charmers,

Project-config change proposed, ready for review:
https://review.openstack.org/#/c/399299/

To address bug:
https://launchpad.net/bugs/1642981

Which is preventing landing of even trivial changes in the source/layer
repos:
https://review.openstack.org/#/q/topic:update-readme+owner:%22Ryan+Beisner%22+status:open

Please do have a very close look at what I'm redefining here.

Thanks in advance!

Ryan
__
OpenStack Development Mailing 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] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 18/11/16 16:47, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:

On 15/11/16 09:56, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.


So I don't want to criticise this effort, because I'm sure that it's
very valuable and worthy 

But it does make me sad that we've so thoroughly given up on the concept
of making the OpenStack APIs themselves interoperable that we're
building an API for our APIs (Yo dawg!) to work around it.



One could argue that this is just the natural order of things in a world
where programmers are disciplined and practice separation of concerns.


Sure, but the argument would be more convincing if having a bunch of 
interoperable clouds were not the *entire point* of OpenStack :)



Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
simply be for multi-cloud users.

IMO, it's actually just sad, and I'd like for every project's API to be
evolved for multi-cloud users. But seeing as I've seen so very little
of that actually happening, splitting it out seems like a reasonable
compromise.


I think we're in agreement.


The problem is that to take advantage of the interoperability benefits
you'll be locked in to a single orchestration tool (Ansible/shade). If
you have a particular reason to use another tool (possibly, ahem, the
one that is an official part of OpenStack and already available in 2/3
of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
choose between whatever feature you wanted there and interoperability.
That's taking "there IS a fantastic OpenStack interoperability story -
but only if you program in Python" and kicking the can one step down the
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
underlying APIs then *everyone* benefits.



I know Monty said this, but I want to say it again: gRPC is just HTTP/2
+ protobufs. Meaning, it's available to virtually every programming
language in wide usage at this time (the limiting factor being protobuf
implementatoins):

https://github.com/google/protobuf/blob/master/docs/third_party.md


I get that, but what I'm spending a lot of my time on is interactions 
between OpenStack components, and that uses the OpenStack APIs because.. 
well because they're the OpenStack APIs.


So maybe in the event of a failure occurring somewhere I want to spin up 
some replacement resources, and then put things back how they were again 
later, using a Mistral workflow. And say that oaktree will magically fix 
some cross-cloud interop differences for me when I first spin up my app. 
Now I'm faced with a bad choice: either I have to replicate the magic in 
a second language, because OpenStack doesn't speak shade/oaktree, or I 
have to give up on the magic and just implement everything myself, or I 
have to give up on the idea of doing anything especially interesting at 
runtime and hope my app just keeps working as deployed, or I have to 
give up on ever deploying my app on more than one cloud.


The only thing that will avoid _all_ of those bad choices, and I realise 
I am preaching to the choir here, is if we fix the APIs such that they 
don't *need* magic to work well across clouds.



I feel like the entire OpenStack project has, out of a desire not to be
opinionated, consistently failed both our users and operators by
encouraging all sorts of unnecessarily incompatible configurations. Not
to pick on any particular project but e.g. can anyone tell me why
Neutron doesn't automatically come, out of the box, with external
networks called "internet" and "openstack" so that users can create
floating IPs that talk to either the internet or just the control plane,
respectively, on any OpenStack cloud with a single Heat template (or
whatever) without having to paste UUIDs anywhere? What sane reason could
there be to even allow, let alone force, all operators to solve these
problems independently?



Side note: As of right now, I'm pretty sure the only place where you
should have to use network UUID's pasted somewhere is Octavia.

Also, many OpenStack clouds are not on the internet, and do not want to
give instances access to the control plane. So your example perhaps
needs more thought.


I'm not saying that you have to supply any IP addresses to the pool. 
Just that only the wilfully contrary should call the internet anything 
other than "internet", and that we should ensure this *in code* instead 
of just hoping that everyone will coincidentally 

Re: [openstack-dev] [keystone] Pike PTL

[Steve Martinelli]

one of these days i'll learn how to spell :)

On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli 
wrote:

> Keystoners,
>
> I do not intend to run for the PTL position of the Pike development cycle.
> I'm sending this out early so I can work with folks interested in the role,
> If you intend to run for PTL in Pike and are interested in learning the
> ropes (or just want to hear more about what the role means) then shoot me
> an email.
>
> It's been an unforgettable ride. Being PTL a is very rewarding experience,
> I encourage anyone interested to put your name forward. I'm not going
> away from OpenStack, I just think three terms as PTL has been enough. It'll
> be nice to have my evenings back :)
>
> To *all* the keystone contributors (cores and non-cores), thank you for
> all your time and commitment. More importantly thank you for putting up
> with my many questions, pings, pokes and -1s. Each of you are amazing and
> together you make an awesome team. It has been an absolute pleasure to
> serve as PTL, thank you for letting me do so.
>
> stevemar
>
>
> 
>
> Thanks for the idea Lana [1]
> [1] http://lists.openstack.org/pipermail/openstack-docs/
> 2016-November/009357.html
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][infra] How to handle doc in kolla and kolla-ansible

[Andreas Jaeger]

On 11/21/2016 08:25 PM, Steven Dake (stdake) wrote:
> Andreas,
> 
> Just thinking about all the documentation rework that would be necessary…  
> Perhaps it just confuses me ;)  I think the short term result would be mass 
> confusion as we sort out the next iteration of the documentation in this 
> structure since the docs are well tested at present and I’m a bit terrified 
> to change them ;)

;)

I haven't reviewed your docs to understand how much work it is.

Just one option:
Right now, while docs.openstack.org/developer/kolla-ansibles might get
published, that content is not linked to from anywhere. You could rework
and either not publish - or only not link to the content - and only once
the new kolla-ansible content is ready, point people to it.

Choose whatever option works best for your team ;)

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] [kolla][infra] How to handle doc in kolla and kolla-ansible

[Steven Dake (stdake)]

Andreas,

Just thinking about all the documentation rework that would be necessary…  
Perhaps it just confuses me ;)  I think the short term result would be mass 
confusion as we sort out the next iteration of the documentation in this 
structure since the docs are well tested at present and I’m a bit terrified to 
change them ;)

It may be possible to solve this via a massive reorg that is well reviewed and 
-2’ed until everything can merge in one go.

Regards
-steve




On 11/21/16, 5:43 AM, "Andreas Jaeger"  wrote:

>On 2016-11-21 13:24, Steven Dake (stdake) wrote:
>> Pete,
>> 
>> The main problem with that is publishing docs to docs.oo which would
>> then confuse the reader even more then they are already confused by
>> reading our docs ;)
>> 
>> Regards
>> -steve
>> 
>> 
>> From: Pete Birley >
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Date: Monday, November 21, 2016 at 5:11 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Subject: Re: [openstack-dev] [kolla] How to handle doc in kolla and
>> kolla-ansible
>> 
>> I think Jeffrey's raised a good point here. Though I agree we should
>> keep the development side under a single umbrella/namespace, to better
>> co-ordinate our efforts, I think it makes more sense to move the
>> end-user documentation and to the repo that it's associated with. I feel
>> this is the right approach as it makes it much less likely for users to
>> confuse/mix documents. With this in mind would it not make sense to spit
>> out the docs as follows?
>> 
>>   * Kolla: images (building/specs), contributing, development
>>   * Kolla-ansible: deployment via ansible, ansible specific specs
>>   * Kolla-kubernetes: deployment via k8s, k8s specific specs
>
>Why confusing Steve? The above sounds like a logical differentiation.
>
>You could have on the front-side of kolla an section "Deployment
>options" that links to kolla-ansible and kolla-kubernetes.
>
>And in kolla-ansible/kolla-kubernetes, you have a start file that links
>back for generic support.
>
>You can also start with one way and then change later on ;)
>
>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 Development Mailing 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][kubernetes] kolla channel in Kubernetes slack

[Ryan Hallisey]

The topic wasn't very clear.  Fixing that...

-Ryan

- Original Message -
From: "Ryan Hallisey" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, November 21, 2016 1:48:51 PM
Subject: [openstack-dev] [kolla][kubernetes] kolla slack channel

Hey folks,

I spoke with the Kubernetes community manager about the interop
between Openstack and Kubernetes with respect to Kolla.  We agreed
that it would make sense to have a channel in the Kubernetes Slack
group for kolla.

In addition, we talked about mirroring the slack and irc channels
essentially combining them into one. But, free slack has a group wide
10,000 message cache and Kolla has about 1-2 messages a minute. At
that rate, Kolla would consume about 20% of the total live message
cache.  Since that's large for a single channel, the channels won't
be mirrored at first, but the CNCF is looking at ways to solve this.

For now, can cores please join kolla's slack channel to get use to
having a foot in each community. Especially kolla-kubernetes cores :).

If you haven't used slack it's really easy to get started.  You
can make an account and join the Kubernetes group.  From there,
you'll find kolla listed as one of the channels.

Thanks,
-Ryan

__
OpenStack Development Mailing 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] [kolla][kubernetes] kolla slack channel

[Ryan Hallisey]

Hey folks,

I spoke with the Kubernetes community manager about the interop
between Openstack and Kubernetes with respect to Kolla.  We agreed
that it would make sense to have a channel in the Kubernetes Slack
group for kolla.

In addition, we talked about mirroring the slack and irc channels
essentially combining them into one. But, free slack has a group wide
10,000 message cache and Kolla has about 1-2 messages a minute. At
that rate, Kolla would consume about 20% of the total live message
cache.  Since that's large for a single channel, the channels won't
be mirrored at first, but the CNCF is looking at ways to solve this.

For now, can cores please join kolla's slack channel to get use to
having a foot in each community. Especially kolla-kubernetes cores :).

If you haven't used slack it's really easy to get started.  You
can make an account and join the Kubernetes group.  From there,
you'll find kolla listed as one of the channels.

Thanks,
-Ryan

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

Re: [openstack-dev] [All] Finish test job transition to Ubuntu Xenial

[Clark Boylan]

On Mon, Nov 14, 2016, at 03:30 PM, Clark Boylan wrote:
> On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:
> > Hello everyone,
> > 
> > The infra team would really like to get the Ubuntu Xenial for testing
> > transition completed early this cycle. We are planning to switch any
> > jobs that remain on Ubuntu Trusty but should be on Ubuntu Xenial on
> > December 6, 2016. That gives us about a month from today to more
> > gracefully migrate jobs while still getting it done early enough in the
> > cycle to fix any issues and put it behind us. Would be great for project
> > teams to test if their jobs run on Xenial and propose updates to
> > openstack-infra/project-config as necessary to switch to Ubuntu Xenial.
> 
> Just a friendly reminder that this is still happening. We will be
> updating any jobs running on Trusty that should be running on Xenial on
> December 6th. I have seen a few projects jump on this and start making
> the necessary changes. Thank you for doing that!
> 
> As always feel free to ask questions or ping us (the infra team) for
> help if you need it. 

Sorry for being a pest but Andreas wanted us to overcommunicate this so
here is your weekly reminder :)
Don't forget this is happening December 6th. That said I have been
really happy with the turnout on fixing these sorts of issues. Thank you
to everyone who has shown up to update their project job configs.

One thing that has occurred to me that would've been nice to have in
previous emails is if we use a common topic for these changes it may
help reviews get through quicker. Maybe we should try using "xenial" as
a common topic then reviewers can search for topic:xenial in gerrit.

Thank you,
Clark

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

[openstack-dev] [keytone] Pike PTL

[Steve Martinelli]

Keystoners,

I do not intend to run for the PTL position of the Pike development cycle.
I'm sending this out early so I can work with folks interested in the role,
If you intend to run for PTL in Pike and are interested in learning the
ropes (or just want to hear more about what the role means) then shoot me
an email.

It's been an unforgettable ride. Being PTL a is very rewarding experience,
I encourage anyone interested to put your name forward. I'm not going away
from OpenStack, I just think three terms as PTL has been enough. It'll be
nice to have my evenings back :)

To *all* the keystone contributors (cores and non-cores), thank you for all
your time and commitment. More importantly thank you for putting up with my
many questions, pings, pokes and -1s. Each of you are amazing and together
you make an awesome team. It has been an absolute pleasure to serve as PTL,
thank you for letting me do so.

stevemar




Thanks for the idea Lana [1]
[1]
http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/18/2016 04:56 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>> On 17/11/16 19:01, Monty Taylor wrote:
>>> On 11/17/2016 05:24 PM, Zane Bitter wrote:
 On 15/11/16 09:56, Monty Taylor wrote:
> Hey everybody!
>
> At this past OpenStack Summit the results of the Interop Challenge were
> shown on stage. It was pretty awesome - 17 different people from 17
> different clouds ran the same workload. And it worked!
>
> However, one of the reasons it worked is because they all used the
> Ansible modules we wrote that are based on the shade library that
> contains the business logic needed to hide vendor differences in clouds.
> That means that there IS a fantastic OpenStack interoperability story -
> but only if you program in Python. That's less awesome.

 So I don't want to criticise this effort, because I'm sure that it's
 very valuable and worthy 

 But it does make me sad that we've so thoroughly given up on the concept
 of making the OpenStack APIs themselves interoperable that we're
 building an API for our APIs (Yo dawg!) to work around it.
>>>
>>> Tell me about it. I share your sadness. In fact, that sadness has been
>>> my main state for several years now.
>>>
 The problem is that to take advantage of the interoperability benefits
 you'll be locked in to a single orchestration tool (Ansible/shade). If
 you have a particular reason to use another tool (possibly, ahem, the
 one that is an official part of OpenStack and already available in 2/3
 of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
 choose between whatever feature you wanted there and interoperability.
 That's taking "there IS a fantastic OpenStack interoperability story -
 but only if you program in Python" and kicking the can one step down the
 road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
 underlying APIs then *everyone* benefits.
>>>
>>> I seem to have communicated something very poorly if that's the take
>>> away you've gotten. Today, if you want cross-cloud interop, you pretty
>>> much need to use shade/ansible. That's not cool - because it's limiting
>>> to people wanting to work in python and people wanting to orchestrate in
>>> ansible. It should absolutely not be necessary to want to use those
>>> tools to get the interop story.
>>>
>>> So one of the main reasons to do this is precisely to provide that story
>>> to everyone - whether they're doing Juju and go, or puppet and ruby, or
>>> just programming in Fog or whatnot.
>>
>> So, say that I want to create my servers in Heat so that I can use Heat 
>> software deployments for orchestration. How would I go about e.g. making 
>> sure that the servers are always connected to the networks I expect on a 
>> variety of different clouds? Would Oaktree figure out the networks and 
>> pass them in to the stack when creating it? (I don't believe shade has 
>> Heat support yet, but we should definitely add it & I don't foresee any 
>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>
> 
> If you're wanting to use Heat, you are a) already cutting off a large
> quantity of interoperable clouds because many do not have Heat, and b)
> you already have provider templates to deal with the inconsistencies
> across clouds.
> 
> And Shade has had Heat support in some for or another for a long time:
> 
> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
> heatclient.client

Yah - we have the heat support. That said - so far shade is not in the
business of modifying your heat templates. (and I think we should likely
stay out of that business)

> To answer your other question, I don't think that's actually desirable or
> realistic for interop expectations. If networking were one-size-fits-all
> we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
> nova-network). We have Neutron so you can construct what you need inside
> the cloud. Shade just normalizes the "how do I get to the instances from
> outside the cloud" part, which has several different variants.
>
>> It sounds to me like the former approach would require all of the same 
>> work in the template that you'd need to handle it now (using 
>> conditionals), and the only real difference is that instead of providing 
>> your own environment file for each cloud you do a bit of oaktree 
>> integration and that figures it out for you instead.
>>
>> Adding Oaktree resource types to Heat to paper over isn't really a 
>> solution from my point of view.
>>
> 
> Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
> Mostly just to avoid needing to grok Keystone and all of its glory.

Well - I think at some point in the future we can/should revisit this,
but I agree that right now it's not a thing that should be on heat's
radar. If oaktree installations became at least as 

Re: [openstack-dev] [osc]: Support for allowed-address-pairs in osc?

[Dean Troyer]

On Mon, Nov 21, 2016 at 9:05 AM, Csatari, Gergely (Nokia -
HU/Budapest)  wrote:
> Is there any way to configure allowed-address-pairs in osc?

These options are under review in
https://review.openstack.org/#/c/356219/ and should be merged soon.

dt

-- 

Dean Troyer
dtro...@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] [neutron-lbaas][octavia] About running Neutron LBaaS

[Michael Johnson]

Hi Yipei,

That error means the controller worker process was not able to reach
the amphora REST API.

I am guessing this is the issue with diskimage-builder which we have
patches up for, but not all of them have merged yet [1][2].

Try running my script:
https://gist.github.com/michjohn/a7cd582fc19e0b4bc894eea6249829f9 to
rebuild the image and boot another amphora.

Also, could you provide a link to the docs you used that booted the
web servers on the lb-mgmt-lan?  I want to make sure we update that
and clarify for future users.

Michael

[1] https://review.openstack.org/399272
[2] https://review.openstack.org/399276

On Sat, Nov 19, 2016 at 9:46 PM, Yipei Niu  wrote:
> Hi, Micheal,
>
> Thanks a lot for your comments.
>
> Please find the errors of o-cw.log in link
> http://paste.openstack.org/show/589806/. Hope it will help.
>
> About the lb-mgmt-net, I just follow the guide of running LBaaS. If I create
> a ordinary subnet with neutron for the two VMs, will it prevent the issue
> you mentioned happening?
>
> Best regards,
> Yipei
>
> __
> OpenStack Development Mailing 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] [osc]: Support for allowed-address-pairs in osc?

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

Is there any way to configure allowed-address-pairs in osc?

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

Re: [openstack-dev] [mistral] Meeting Time

[Dougal Matthews]

On 7 November 2016 at 16:20, Dougal Matthews  wrote:

> Hi all,
>
> We want to make sure that the Mistral meeting time is as good as possible,
> so that everyone interested can attend. To do that, please add your
> name/nick and the times that suit you to this etherpad:
>
> https://etherpad.openstack.org/p/mistral-meeting-time
>
> If we are really lucky, we will find a time in that for everyone. if we
> are slightly lucky we will find two time slots that covers everyone and the
> meeting can alternate.
>
> We may find that the current time is best for everyone, but I wanted to
> make sure.
>
> Cheers,
> Dougal
>

Hey all,

Thanks to everyone that added their names to the etherpad. It looks like
the current time does work for most people. How else can we reach out and
increase participation?

I would like to propose that we alternate the meetings each week between
the normal time and a time later in the day. This assumes we have a
volunteer that is able to regularly attend this meeting and start it - if
not, we can just stick with the current meeting time. The other time should
be arranged so it suits rakhmerov, kong and m4dcode (at least).

Hopefully with two alternating meeting slots we can involve more people in
the meetings.

I'll bring this up today in the meeting too.

Thanks,
Dougal
__
OpenStack Development Mailing 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][infra] How to handle doc in kolla and kolla-ansible

[Jay Pipes]

On 11/21/2016 07:43 AM, Andreas Jaeger wrote:

On 2016-11-21 13:24, Steven Dake (stdake) wrote:

Pete,

The main problem with that is publishing docs to docs.oo which would
then confuse the reader even more then they are already confused by
reading our docs ;)

Regards
-steve


From: Pete Birley >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
Date: Monday, November 21, 2016 at 5:11 AM
To: "OpenStack Development Mailing List (not for usage questions)"
>
Subject: Re: [openstack-dev] [kolla] How to handle doc in kolla and
kolla-ansible

I think Jeffrey's raised a good point here. Though I agree we should
keep the development side under a single umbrella/namespace, to better
co-ordinate our efforts, I think it makes more sense to move the
end-user documentation and to the repo that it's associated with. I feel
this is the right approach as it makes it much less likely for users to
confuse/mix documents. With this in mind would it not make sense to spit
out the docs as follows?

  * Kolla: images (building/specs), contributing, development
  * Kolla-ansible: deployment via ansible, ansible specific specs
  * Kolla-kubernetes: deployment via k8s, k8s specific specs


Why confusing Steve? The above sounds like a logical differentiation.

You could have on the front-side of kolla an section "Deployment
options" that links to kolla-ansible and kolla-kubernetes.

And in kolla-ansible/kolla-kubernetes, you have a start file that links
back for generic support.

You can also start with one way and then change later on ;)


Yeah, I tend to agree with Andreas on this. I think general docs for 
Kolla should link to more specific docs about the Ansible or k8s 
deployments of Kolla. I don't think that is much of a burden on the user.


Best,
-jay

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

Re: [openstack-dev] [kolla][infra] How to handle doc in kolla and kolla-ansible

[Andreas Jaeger]

On 2016-11-21 13:24, Steven Dake (stdake) wrote:
> Pete,
> 
> The main problem with that is publishing docs to docs.oo which would
> then confuse the reader even more then they are already confused by
> reading our docs ;)
> 
> Regards
> -steve
> 
> 
> From: Pete Birley >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Date: Monday, November 21, 2016 at 5:11 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
>  >
> Subject: Re: [openstack-dev] [kolla] How to handle doc in kolla and
> kolla-ansible
> 
> I think Jeffrey's raised a good point here. Though I agree we should
> keep the development side under a single umbrella/namespace, to better
> co-ordinate our efforts, I think it makes more sense to move the
> end-user documentation and to the repo that it's associated with. I feel
> this is the right approach as it makes it much less likely for users to
> confuse/mix documents. With this in mind would it not make sense to spit
> out the docs as follows?
> 
>   * Kolla: images (building/specs), contributing, development
>   * Kolla-ansible: deployment via ansible, ansible specific specs
>   * Kolla-kubernetes: deployment via k8s, k8s specific specs

Why confusing Steve? The above sounds like a logical differentiation.

You could have on the front-side of kolla an section "Deployment
options" that links to kolla-ansible and kolla-kubernetes.

And in kolla-ansible/kolla-kubernetes, you have a start file that links
back for generic support.

You can also start with one way and then change later on ;)

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] [kolla][infra] How to handle doc in kolla and kolla-ansible

[Andreas Jaeger]

On 2016-11-21 13:00, Steven Dake (stdake) wrote:
> Yup this is a real challenge to sort out properly.  I’ve included infra for 
> their guidance (thanks people :).
> 
> Here is the issue
> 
> Each package should include enough docs that it stands alone after a git 
> checkout (IMO).  We also publish docs to docs.oo which should IMO contain one 
> set of docs for the entire kolla project in the /kolla namespace.
> 
> I guess the above if what I’d want in a star trek universe.  This provides 
> best of both worlds - kolla-ansible, kolla-kubernetes, kolla documentation 
> all with their respective repositories, but merged on the docs.oo site into 
> one document.  How do you do that?  No idea.

You can link from one to the other.

But having one document where you hit next, next, next will not work.
You will always have separate documents.

> So if that isn’t a possibility, putting all in kolla repo seems to make most 
> sense to me although it slows down reviews for kolla-ansible and 
> kolla-kkubernetes docs.  We could put a reference page in the docs of 
> kolla-ansible and kolla-kubernetes to “go reference kolla”.

Common stuff in kolla, specific stuff in kolla-ansible, kolla-kubernetes?

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] [Infra] Adding myself to networking-dpm gerrit groups

[Andreas Scheuring]

Hi infra team, 
would you mind adding myself (andreas.scheur...@de.ibm.com) to the
following gerrit groups?

- networking-dpm-core
- networking-dpm-release


Thanks a lot!

Andreas
IRC: andreas_s


__
OpenStack Development Mailing 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][infra] How to handle doc in kolla and kolla-ansible

[Steven Dake (stdake)]

Pete,

The main problem with that is publishing docs to docs.oo which would then 
confuse the reader even more then they are already confused by reading our docs 
;)

Regards
-steve


From: Pete Birley >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, November 21, 2016 at 5:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] How to handle doc in kolla and 
kolla-ansible

I think Jeffrey's raised a good point here. Though I agree we should keep the 
development side under a single umbrella/namespace, to better co-ordinate our 
efforts, I think it makes more sense to move the end-user documentation and to 
the repo that it's associated with. I feel this is the right approach as it 
makes it much less likely for users to confuse/mix documents. With this in mind 
would it not make sense to spit out the docs as follows?

  *   Kolla: images (building/specs), contributing, development
  *   Kolla-ansible: deployment via ansible, ansible specific specs
  *   Kolla-kubernetes: deployment via k8s, k8s specific specs

- Pete

On Mon, Nov 21, 2016 at 10:13 AM, Jeffrey Zhang 
> wrote:
Then what's the case of kolla-kubernetes?

On Mon, Nov 21, 2016 at 5:54 PM, Paul Bourke 
> wrote:
> Propose all docs stay under the kolla namespace
> (http://docs.openstack.org/developer/kolla).
>
> Steve mentioned that we should try to keep all components (e.g. mailing list
> tags) under the same umbrella which I agree with.
>
> On 21/11/16 08:05, Jeffrey Zhang wrote:
>>
>> After the split, we have two projects and two develop docs[0][1].
>> These two sites have lots of duplicated lines.
>>
>> So will we split the doc site?
>> if so, we need to remove the duplicated doc in the repos.
>> if not, we need to remove one site's doc.
>>
>> [0] http://docs.openstack.org/developer/kolla
>> [1] http://docs.openstack.org/developer/kolla-ansible/
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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



--

[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] [kolla] How to handle doc in kolla and kolla-ansible

[Pete Birley]

I think Jeffrey's raised a good point here. Though I agree we should keep
the development side under a single umbrella/namespace, to better
co-ordinate our efforts, I think it makes more sense to move the end-user
documentation and to the repo that it's associated with. I feel this is the
right approach as it makes it much less likely for users to confuse/mix
documents. With this in mind would it not make sense to spit out the docs
as follows?

   - Kolla: images (building/specs), contributing, development
   - Kolla-ansible: deployment via ansible, ansible specific specs
   - Kolla-kubernetes: deployment via k8s, k8s specific specs

- Pete

On Mon, Nov 21, 2016 at 10:13 AM, Jeffrey Zhang 
wrote:

> Then what's the case of kolla-kubernetes?
>
> On Mon, Nov 21, 2016 at 5:54 PM, Paul Bourke 
> wrote:
> > Propose all docs stay under the kolla namespace
> > (http://docs.openstack.org/developer/kolla).
> >
> > Steve mentioned that we should try to keep all components (e.g. mailing
> list
> > tags) under the same umbrella which I agree with.
> >
> > On 21/11/16 08:05, Jeffrey Zhang wrote:
> >>
> >> After the split, we have two projects and two develop docs[0][1].
> >> These two sites have lots of duplicated lines.
> >>
> >> So will we split the doc site?
> >> if so, we need to remove the duplicated doc in the repos.
> >> if not, we need to remove one site's doc.
> >>
> >> [0] http://docs.openstack.org/developer/kolla
> >> [1] http://docs.openstack.org/developer/kolla-ansible/
> >>
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

[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] [kolla][infra] How to handle doc in kolla and kolla-ansible

[Steven Dake (stdake)]

Yup this is a real challenge to sort out properly.  I’ve included infra for 
their guidance (thanks people :).

Here is the issue

Each package should include enough docs that it stands alone after a git 
checkout (IMO).  We also publish docs to docs.oo which should IMO contain one 
set of docs for the entire kolla project in the /kolla namespace.

I guess the above if what I’d want in a star trek universe.  This provides best 
of both worlds - kolla-ansible, kolla-kubernetes, kolla documentation all with 
their respective repositories, but merged on the docs.oo site into one 
document.  How do you do that?  No idea.

So if that isn’t a possibility, putting all in kolla repo seems to make most 
sense to me although it slows down reviews for kolla-ansible and 
kolla-kkubernetes docs.  We could put a reference page in the docs of 
kolla-ansible and kolla-kubernetes to “go reference kolla”.

Regards
-steve





On 11/21/16, 3:13 AM, "Jeffrey Zhang"  wrote:

>Then what's the case of kolla-kubernetes?
>
>On Mon, Nov 21, 2016 at 5:54 PM, Paul Bourke  wrote:
>> Propose all docs stay under the kolla namespace
>> (http://docs.openstack.org/developer/kolla).
>>
>> Steve mentioned that we should try to keep all components (e.g. mailing list
>> tags) under the same umbrella which I agree with.
>>
>> On 21/11/16 08:05, Jeffrey Zhang wrote:
>>>
>>> After the split, we have two projects and two develop docs[0][1].
>>> These two sites have lots of duplicated lines.
>>>
>>> So will we split the doc site?
>>> if so, we need to remove the duplicated doc in the repos.
>>> if not, we need to remove one site's doc.
>>>
>>> [0] http://docs.openstack.org/developer/kolla
>>> [1] http://docs.openstack.org/developer/kolla-ansible/
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>-- 
>Regards,
>Jeffrey Zhang
>Blog: http://xcodest.me
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

Dims, thanks!

On Mon, Nov 21, 2016 at 1:44 PM, Davanum Srinivas  wrote:

> Andrey, Folks,
>
> I've fast-tracked the black list:
> https://review.openstack.org/400183
>
> Thanks,
> Dims
>
>
>
> On Mon, Nov 21, 2016 at 6:00 AM, Andrey Kurilin 
> wrote:
> > hi folks!
> >
> > Neutron gates are broken again. New failure relates to issue with
> heatclient
> > [*] .
> >
> > [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507
> >
> >
> >
> > On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin 
> > wrote:
> >>
> >> Hi stackers!
> >>
> >> Imo, there is a better solution - just turn off telemetry services[*] :)
> >> Neutron jobs do not runs any ceilometer scenarios, so enabling all
> telemetry
> >> services looks redundant and takes some time while preparing environment
> >> (installing devstack).
> >>
> >>
> >> [*] - https://review.openstack.org/#/c/399212
> >>
> >> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka 
> >> wrote:
> >>>
> >>>
> >>> > On 17 Nov 2016, at 20:32, Armando M.  wrote:
> >>> >
> >>> > Hi folks,
> >>> >
> >>> > Please do not recheck rally failures.
> >>> >
> >>> > There was a breaking change introduced by aodh [0] that prevented
> rally
> >>> > to work on trusty. We are switching to xenial as we speak anyway
> [1], so the
> >>> > glitch should be short lived.
> >>>
> >>> To give an update, the switch to Xenial occurred, and I see jobs
> passing
> >>> just fine again.
> >>>
> >>> Ihar
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey Kurilin.
> >
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > 
> __
> > OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [neutron] rally failure in the gate

[Davanum Srinivas]

Andrey, Folks,

I've fast-tracked the black list:
https://review.openstack.org/400183

Thanks,
Dims



On Mon, Nov 21, 2016 at 6:00 AM, Andrey Kurilin  wrote:
> hi folks!
>
> Neutron gates are broken again. New failure relates to issue with heatclient
> [*] .
>
> [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507
>
>
>
> On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin 
> wrote:
>>
>> Hi stackers!
>>
>> Imo, there is a better solution - just turn off telemetry services[*] :)
>> Neutron jobs do not runs any ceilometer scenarios, so enabling all telemetry
>> services looks redundant and takes some time while preparing environment
>> (installing devstack).
>>
>>
>> [*] - https://review.openstack.org/#/c/399212
>>
>> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka 
>> wrote:
>>>
>>>
>>> > On 17 Nov 2016, at 20:32, Armando M.  wrote:
>>> >
>>> > Hi folks,
>>> >
>>> > Please do not recheck rally failures.
>>> >
>>> > There was a breaking change introduced by aodh [0] that prevented rally
>>> > to work on trusty. We are switching to xenial as we speak anyway [1], so 
>>> > the
>>> > glitch should be short lived.
>>>
>>> To give an update, the switch to Xenial occurred, and I see jobs passing
>>> just fine again.
>>>
>>> Ihar
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing 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] [stable][release] Final releases for stable/liberty and liberty-eol

[Ihar Hrachyshka]

> On 21 Nov 2016, at 12:38, Alan Pevec  wrote:
> 
>> 1. Final stable/liberty releases should happen next week, probably by
>> Thursday 11/17.
> 
> I see only Cinder did it https://review.openstack.org/397282
> and Nova is under review https://review.openstack.org/397841
> 
> Is that all or other project are not aware Liberty is EOL now?


neutron did liberty release lately, and we don’t have any CVEs in the branch, 
so we just skip this time.

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

[openstack-dev] [mistral] Team meeting reminder - 11/21/2016

[Renat Akhmerov]

Hi,

We’ll have a team meeting today at #openstack-mistral at 16.00 UTC as usually.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Custom Actions API update
Open discussion

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [stable][release] Final releases for stable/liberty and liberty-eol

[Alan Pevec]

> 1. Final stable/liberty releases should happen next week, probably by
> Thursday 11/17.

I see only Cinder did it https://review.openstack.org/397282
and Nova is under review https://review.openstack.org/397841

Is that all or other project are not aware Liberty is EOL now?

Cheers,
Alan

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

Re: [openstack-dev] [neutron] rally failure in the gate

[Andrey Kurilin]

hi folks!

Neutron gates are broken again. New failure relates to issue with
heatclient [*] .

[*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507



On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin 
wrote:

> Hi stackers!
>
> Imo, there is a better solution - just turn off telemetry services[*] :)
> Neutron jobs do not runs any ceilometer scenarios, so enabling all
> telemetry services looks redundant and takes some time while preparing
> environment (installing devstack).
>
>
> [*] - https://review.openstack.org/#/c/399212
>
> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka 
> wrote:
>
>>
>> > On 17 Nov 2016, at 20:32, Armando M.  wrote:
>> >
>> > Hi folks,
>> >
>> > Please do not recheck rally failures.
>> >
>> > There was a breaking change introduced by aodh [0] that prevented rally
>> to work on trusty. We are switching to xenial as we speak anyway [1], so
>> the glitch should be short lived.
>>
>> To give an update, the switch to Xenial occurred, and I see jobs passing
>> just fine again.
>>
>> Ihar
>> 
>> __
>> 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
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>



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

Re: [openstack-dev] [Neutron] Stepping down from core

[John Davidge]

It's been a pleasure to work with you these past few years, Carl. I wish you 
all the best in whatever's next for you. Hopefully we'll meet again soon in the 
not so distant future.

There will forever be a Carl-shaped hole in our codebase.

John

From: Carl Baldwin >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, November 17, 2016 at 6:42 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] How to handle doc in kolla and kolla-ansible

[Jeffrey Zhang]

Then what's the case of kolla-kubernetes?

On Mon, Nov 21, 2016 at 5:54 PM, Paul Bourke  wrote:
> Propose all docs stay under the kolla namespace
> (http://docs.openstack.org/developer/kolla).
>
> Steve mentioned that we should try to keep all components (e.g. mailing list
> tags) under the same umbrella which I agree with.
>
> On 21/11/16 08:05, Jeffrey Zhang wrote:
>>
>> After the split, we have two projects and two develop docs[0][1].
>> These two sites have lots of duplicated lines.
>>
>> So will we split the doc site?
>> if so, we need to remove the duplicated doc in the repos.
>> if not, we need to remove one site's doc.
>>
>> [0] http://docs.openstack.org/developer/kolla
>> [1] http://docs.openstack.org/developer/kolla-ansible/
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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

Re: [openstack-dev] [kolla] How to handle doc in kolla and kolla-ansible

[Paul Bourke]

Propose all docs stay under the kolla namespace 
(http://docs.openstack.org/developer/kolla).


Steve mentioned that we should try to keep all components (e.g. mailing 
list tags) under the same umbrella which I agree with.


On 21/11/16 08:05, Jeffrey Zhang wrote:

After the split, we have two projects and two develop docs[0][1].
These two sites have lots of duplicated lines.

So will we split the doc site?
if so, we need to remove the duplicated doc in the repos.
if not, we need to remove one site's doc.

[0] http://docs.openstack.org/developer/kolla
[1] http://docs.openstack.org/developer/kolla-ansible/



__
OpenStack Development Mailing 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] [charms] Barbican Hostname Config Params

[James Page]

Hi James

On Thu, 17 Nov 2016 at 20:05 James Beedy  wrote:

> Is there a specific reason the barbican charm doesn't have the
> os-{internal,private}-hostname config params?
>

The layers and charms.openstack don't currently have support for the
os-*-hostname configuration options yes  - barbican, aodh and designate are
all based off this stack of components so are a little different in
structure than some of the older charms.

We'll put these options on the TODO list (if they are not already there).

Cheers

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

[openstack-dev] [neutron][taas] IRC meeting canceled (week of 11/21/2016)

[Soichi Shigeta]

 Hi,

  TaaS IRC meeting on this week being canceled
  because of national holiday in Japan.

  Regards,
  Soichi



__
OpenStack Development Mailing 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] [documentation]guide on new project template

[joehuang]

Kolla project provides a good example on the documentation,

http://docs.openstack.org/developer/kolla

https://github.com/openstack/kolla/tree/master/doc


Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 17 November 2016 15:18
To: openstack-dev
Subject: [openstack-dev][documentation]guide on new project template

Hello,

Tricircle is just a new big-tent project, would like to know which 
documentation are necessary for the project and whether there are documentation 
templates.

I just find this page for new project, but no clue how to organize an new 
project's documentation.

Many thanks if someone can help.

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] [kolla] How to handle doc in kolla and kolla-ansible

[Jeffrey Zhang]

After the split, we have two projects and two develop docs[0][1].
These two sites have lots of duplicated lines.

So will we split the doc site?
if so, we need to remove the duplicated doc in the repos.
if not, we need to remove one site's doc.

[0] http://docs.openstack.org/developer/kolla
[1] http://docs.openstack.org/developer/kolla-ansible/

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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